Attack Path Management Comes to AWS

At SpecterOps, we have been hard at work modeling identity providers in our BloodHound Enterprise platform. Everything from Active Directory to Okta and Github, we focused on the hybrid technologies that matter most to the enterprise identity security. Today, we are announcing a new addition that breaks the mold and provides insight into one of the most critical cloud resource providers used by virtually every enterprise organization: Amazon Web Services.

With the latest extension, SpecterOps brings the attack path mindset to AWS identities, permissions, trust relationships, organization structure, and a whole suite of AWS resources. We are providing a solution to answer the simple questions of who *really* has access to this resource and what can this AWS role *actually* do?

Cloud privilege is ubiquitous

AWS is not a niche platform. It is the de facto cloud resource provider of the modern, hybrid enterprise. As of May 2026, AWS holds 26% of the cloud hosting market share globally. It is the single most common provider that organizations run production workloads, data storage, and utilize non-human identities.

And the scale of identity inside those environments is staggering. A mature organization does not simply have one AWS account, it has an entire AWS Organization. Hundreds, even thousands, of accounts, each with its own identity access management (IAM) boundary with users, roles, and policies. A single role compromise in a single account may be sufficient to compromise the entire AWS organization. Many such roles carry permissions their authors never intended and certainly never enumerated. Considering the non-human services, workloads, CI-CD pipeline, and compute instances that assume roles, changes are happening rapidly, thousands of times a day, in ways that authors never intended.

The result is an authorization surface that no human can reason with by simply reading policy documents. The policy language is arduously expressive, and the policy evaluation pipeline is complex. Identity policies, resource policies, service control policies, permission boundaries, and trust policies are all intertwined with expressive conditions to make manual analysis a daunting task. Ultimately, organizations drift away from intent and the expressive controls conflict, compound, and even obscure the paths that they create.

The AWS IAM attack path problem

Most AWS security tooling asks a configuration question:

Is this policy overly permissive?

Is this bucket public?

Does this role violate best practice?

Those are undoubtedly useful questions, but they are also incomplete for understanding real compromise risk.

The question an attacker asks is different. An attacker does not care whether a policy is “overly permissive.” They care whether the one they compromised, via an exposed EC2 instance, lambda function, or CI/CD compromise, can reach a sensitive resource. Can they reach the role with an administrator policy? The lambda function with production credentials? They care about the chain, not just about the control

BloodHound Enterprise now has a solution for that AWS question. It evaluates the full AWS authorization model—identity, resource, trust, permission boundary, SCP and RCP policies together—and renders it as traversable attack paths. Meticulous consideration for the policy evaluation pipeline produces real, accurate edges that give a clear picture of who can do what.

AWS attack path management features supported at release

At launch, the AWS collector models the AWS services where privilege escalation and lateral movement are used most frequently on our own AWS engagements:

• IAM – Users, groups, roles, policies, and federated identity providers.
• AWS Organizations – The full account hierarchy, service control policies and resource control policies that govern permissions across the organization
• STS – Role assumption and federation including ‘AssumeRole’, SAML, and web identity federation
• S3 – Buckets, bucket policies, ACLs, and object level access
• KMS – Keys, key policies, grants, and aliases
• Lambda – Functions and resource policies
• EC2 – Instances and instance profiles
• CloudFormation – Stacks and StackSets
• EKS – Clusters, node groups, and access entries, including IRSA and Pod Identity role assumption
• SSM – Parameters and managed instances

Together, these span more than 20 AWS resource types and over 150 distinct relationships, from IAM privilege escalation to PassRole abuse to cross-account trust, are all derived from a policy engine that reasons about permissions the way AWS itself does.

Who can actually assume a privileged role?

Role assumption is the connective tissue of AWS. It is also a commonly misunderstood boundary. A trust policy that says “trust this account” can in practice mean “trust every principal in that account”, including ones that did not exist when the policy was written.

And internal roles aren’t the only roles mapped. The AWS collector can identify external role trusts that provide inbound access from third-party vendors and contractors. Understanding the risk of a third-party compromise is crucial for providing the complete posture picture for an AWS environment.

In BloodHound Enterprise, these relationships are a first class consideration. Which principals can assume which roles, which roles trust external accounts, and which trust policies can be edited by an attacker to grant themselves access they don’t yet have. The AWS collector models role assumption through every avenue AWS offers: direct ‘AssumeRole’, SAML and web-identity, session and federation tokens, and self-serve escalations.

Who can escalate to an administrator?

Some AWS permissions are administrator access wearing a disguise. The ability to attach a policy, create a new access key on another user, edit your own inline policy, or create-and-pass a role to a service you control are all, effectively, administrator actions. They are simply obscured away by a title and a few modifications.

BloodHound Enterprise goes through extensive analysis to produce such escalation edges, ensuring that false positives are kept to near zero. If a compromised, low-priviled identity can reach the admin in one hop or 10, the graph will show it with the permissions that enabled it and the policy that contributed to the action.

Who can reach your keys, secrets, and data?

Attack paths do not always end at an identity. They can end at the things that matter the most, like sensitive data, encryption keys, or CI/CD secrets.

The graph connects principals to the resources they can reach: Who can decrypt with a KMS key or give themselves the ability to do so? Who can read or overwrite an S3 bucket? Who can pull a secret out of an SSM parameter and authenticate as a non-human identity? This is more than who is configured to access a resource, this is answering who in my organization, through some combination of role chaining and privilege abuse, can access this resource? BloodHound Enterprise’s ability to provide comprehensive answers to such questions will continue to play an outsized role in the AWS landscape, illuminating true access to the critical resources that organizations ultimately need to defend.

What can the outsider do?

The AWS Organization is where cloud attack paths become hybrid, enterprise attack paths. A role trusted by an external account, an SCP that fails to constrain a child account, a “confused deputy” relationship with a third-party vendor. Each is an opportunity for an attacker to move through your org and potentially compromise it from the root management account down.

Because BloodHound Enterprise collects and analyzes all of your AWS accounts all at once together, extremely complex cross-account relationships are built and mapped, highlighting each route to your most critical AWS accounts. These chains can traverse dozens of accounts, showing the real blast radius of a compromised vendor, contractor, or AWS development account.

What’s next

BloodHound Enterprise and AWS don’t stop at the services listed above. The SpecterOps team is working to add additional services such as Bedrock, RDS, ECR, and more. This will be a living, ongoing pursuit of illuminating every corner of the AWS environment that matters.