AWS RAM share abuse: a cross-account foothold that hides from IAM
Sharing subnets and resolver rules to an attacker account creates network and DNS reach that never touches IAM trust policies. There is no token to revoke.
Most cross-account abuse shows up as a role assumption. Resource sharing gives an attacker reach into your environment without ever touching an IAM trust policy.
How the attack works
An attacker with ram:CreateResourceShare creates a resource share with allowExternalPrincipals enabled, then associates an attacker-controlled account outside the organization. They share production VPC subnets and Route 53 resolver rules, and the external account accepts the invitation and launches resources into the shared subnets, gaining network-level reach and internal DNS visibility. None of this looks like a role assumption, so it is a quiet foothold. CloudTrail records the CreateResourceShare and AssociateResourceShare events and the cross-account principal added. In ATT&CK terms this is T1199, Trusted Relationship, leading to cloud-account abuse (T1078.004).
Why it works
RAM is normally used to share within the organization, so an external share blends in. Over-broad ram permissions plus external sharing being allowed at the org level let any principal hand network and DNS access to an outside account. The root cause is unconstrained resource-sharing rights.
How to fix it
The non-obvious point is that there is no STS token or password to revoke; access flows through the share itself. Disassociate the external principal and the shared resources from the rogue share, then add a service control policy that denies ram:CreateResourceShare and external sharing so it cannot be recreated. Scope what was reached from CloudTrail by listing exactly which resources were shared and correlating the external account’s activity in the window; remember that network and DNS exposure is real confidentiality risk even with no object download. Then audit every share and accepted invitation org-wide, disable external sharing at the org level, and scope ram permissions to a small set of approved principals.
Practice it
We built this as a GraphLattice Range scenario so security teams can revoke a rogue share, add the SCP guardrail, and scope what an external account reached.