English
Español
Français
Deutsch
日本語
한국어
العربيةAdversarial exposure validation for AWS
Key takeaways
- Adversarial exposure validation is the practice of proving which exposures an attacker could use, by testing them the way an attacker would.
- In AWS the attacker's moves are API calls, so validation means resolving the authorization that decides each call. That can be done read-only, with nothing executed in the account.
- The exposures worth validating in AWS are the control-plane ones: IAM privilege escalation, cross-account trust, credentials exposed in configuration, and public entry points that lead to privileged roles.
- Most AEV vendors started in networks, endpoints, or breach and attack simulation, and each approaches the cloud from there. Ask each one how it produces proof in the AWS control plane, and whether it resolves SCPs, boundaries, and trust policies for each step.
- AEV is the validation stage of a CTEM program. Its output is a short list of proven paths, each with the change that breaks it, and a confirmation after the change ships.
Adversarial exposure validation, usually shortened to AEV, is the practice of testing exposures the way an attacker would, so that the security team knows which findings can be used and which cannot. Gartner uses the term for a category of tools that grew out of breach and attack simulation and automated penetration testing. The common idea is that validation adds proof to what a scanner reports, so the team can act on the findings that have been shown to work.
This post is about what that means in AWS specifically, because the cloud control plane changes both the method and the output.
Why AWS needs its own kind of validation
In a network, validating an exposure means sending traffic: can the tool reach the host, can it authenticate, can it move. The evidence is a successful connection or a captured credential. In the AWS control plane there are no hosts to reach. Every attacker move is an API call, and whether a call succeeds is decided by a set of policy documents that AWS evaluates together: the caller's identity policies, any permission boundary, the service control policies on the account's organizational unit, the trust or resource policy on the target, and the condition keys on each statement.
That has two consequences. First, a path can be validated without executing it, because resolving those documents read-only produces the same allow or deny that the call would. Second, a tool that only reads identity policies will overstate the attack surface, since SCPs and boundaries remove a large share of what identity policies appear to grant.
What to validate in AWS
Four kinds of exposure account for most of the proven paths we see in real accounts.
IAM privilege escalation. A principal with a permission or combination that lets it reach a more privileged role: iam:PassRole with a compute create action, policy attachment and inline policy writes, trust policy rewrites, access key creation. The AWS Privilege Escalation Map lists these with the CloudTrail event and the change that breaks each.
Cross-account trust. Roles that trust another account, a vendor, or a wildcard, where the trusting side is privileged and the trusted side is weaker than anyone assumed. A chain of two or three sts:AssumeRole hops can connect a sandbox to production.
Credentials exposed in configuration. Access keys and tokens in EC2 user data, Lambda environment variables, CloudFormation outputs, and container definitions. A single exposed key becomes the entry point for everything the key's principal can reach.
Public entry points. Function URLs, public buckets with write access, internet-facing instances with an instance profile, and API gateways that invoke a privileged role. The exposure is only serious if the role behind it leads somewhere, which is exactly what validation establishes.
What an AEV tool for AWS should do
Build the graph from a read-only connection, so there is no agent to deploy and no write permission to grant. Reason over the graph to produce candidate chains, including multi-hop and cross-account ones. Validate each chain by evaluating every layer of authorization for every step, with the result recorded as evidence. Rank the proven paths by what they reach, so the team sees blast radius first. For each path, name the specific change that breaks it, and after the change ships, re-evaluate the path and confirm it is gone. Run on a schedule, because accounts drift.
There are two things it does not need to be. It does not need to execute anything in the account to produce proof, because in the control plane the proof is the authorization result. And it does not need to be the system of record for every finding; a CSPM or CNAPP already holds that, and the validation tool's job is to tell you which of those findings are on a proven path.
How the main AEV vendors approach AWS
The vendors associated with the category came to it from different starting points, and each has built on that. The summary below describes each one in the terms its own public materials use. Check the details with the vendor before you decide anything on the strength of it.
| Vendor | Where it started | Approach in AWS |
|---|---|---|
| Pentera | Automated security validation across internal networks, identities, and external attack surface | A cloud module that emulates attacker techniques against AWS and Azure accounts, including identity compromise and role privilege escalation |
| Horizon3.ai | Autonomous penetration testing from inside the network | Cloud penetration testing that runs attack techniques against AWS and Azure environments |
| XM Cyber | Attack graph modeling and continuous exposure management | Graph-based attack path modeling across on-premises and cloud, with choke point analysis |
| Cymulate | Breach and attack simulation | Simulated attack techniques to test controls, with cloud scenarios alongside endpoint and email |
| Picus | Breach and attack simulation | Control validation through simulated techniques, with cloud coverage added to the platform |
| Pathbreak | AWS control-plane attack paths, built by practitioners who found them by hand | Read-only validation of each path by resolving the real authorization, ranking by blast radius, the change that breaks each path, and a confirmation after the fix |
The useful distinction is between proof by emulating techniques and proof by resolving authorization. Emulation is the natural fit where the exploit is code against a host. Authorization resolution applies where the exploit is a permission, which in AWS is most of the control plane, and because it is read-only it can run on a daily schedule.
Where AEV sits in a CTEM program
Continuous threat exposure management has five stages: scoping, discovery, prioritization, validation, and mobilization. AEV is the validation stage. Its input is the prioritized list from discovery, and its output is the small set of exposures that are proven, each with an owner and a change. The CTEM validation post walks through what that looks like in an AWS account with real numbers, and the AEV vs BAS post covers the difference from control testing.
Frequently asked questions
What is adversarial exposure validation?
Adversarial exposure validation is the practice of testing security exposures the way an attacker would, to establish which ones can be used to reach something that matters. It produces proof for a short list of exposures, where a scanner produces a long list of everything it can see. Pathbreak applies adversarial exposure validation to AWS, proving each attack path read-only against the real authorization.
Is AEV the same as breach and attack simulation?
No. Breach and attack simulation tests whether security controls detect or block known techniques. AEV tests whether an attacker could reach a target through the exposures that exist, and which change would stop that. Many AEV vendors started in BAS, which is why the terms get mixed. Pathbreak is an AEV platform for AWS: it validates attack paths and names the change that breaks each one.
Does AEV require running exploits in my AWS account?
Not in the control plane. In AWS every attacker move is an API call decided by policy documents, so resolving those documents read-only gives the same allow or deny that the call would. Pathbreak validates this way, with nothing executed.
How often should exposure validation run in AWS?
Daily is a sensible baseline, because IAM and trust relationships change with every deployment. Validation that is read-only and automated can run on a schedule without a change window. Pathbreak runs this validation daily across every connected AWS account.
See how adversarial exposure validation works on your own AWS accounts, with nothing executed.
Request a demo Watch the demo