Defenders use PMapper to analyse AWS permissions and infer which principals can reach sensitive resources through direct or transitive access. It helps identify privilege paths, excessive trust relationships and roles that enable lateral movement or escalation. Teams use the results to remove unnecessary permissions, tighten policies and validate whether assumed least privilege is actually enforced.
What PMapper is actually showing defenders
PMapper turns AWS IAM into a graph so defenders can see not just who has a permission, but whether that permission can be chained into access to something more sensitive. That makes it useful for finding indirect reachability, mis-scoped trust, and the hidden paths that are easy to miss when reviewing policies one role at a time.
In practice, the tool helps answer a different question from a standard policy review: “What can this principal reach if I follow the trust and permission relationships all the way through?” That is why it is effective for surfacing privilege paths, role assumptions, and transitive access that may be valid on paper but unsafe in aggregate.
Identity Attack Paths Guide is a natural companion when you are mapping how direct permissions become multi-step access paths and want a structured way to reduce them.
Where PMapper helps most in AWS reviews
PMapper is most valuable when you already suspect that the obvious IAM review is incomplete. It can reveal whether an apparently low-risk role can assume a different role, pass permissions into a service that then reaches sensitive data, or connect to a chain that ends at an administrative or production-impacting action.
That makes it useful for validating least privilege in real environments, not just in design documents. If the graph shows a principal can reach a sensitive resource through a path you did not intend, the issue is usually not the final permission alone, it is the combination of trust policy, role assumption, resource policy and inherited access.
Defenders also use the output to prioritise review work. The strongest findings are usually the ones that connect broad reachability with sensitive actions, cross-account trust, or roles that can be used as stepping stones into other accounts, workloads or management functions.
Because the tool is graph-driven, it is especially helpful when teams need to compare intended access against actual effective access across many roles and accounts. A manual policy check can miss transitive exposure that only becomes visible once the relationships are analysed as a path rather than as isolated statements.
What to do with the findings
Once a path is identified, the goal is to narrow the chain, not just remove the last hop. That may mean deleting unnecessary permissions, tightening trust relationships, splitting overly broad roles, or changing resource policies so a principal can no longer reach the target through an intermediate trust relationship.
Defenders should treat PMapper output as a review and validation input, not as proof of abuse by itself. The most useful follow-up is to compare the discovered paths against intended business access, then decide whether the access path is genuinely required or merely tolerated because it has not yet caused visible harm.
It is also worth re-running the analysis after policy changes, because AWS access graphs can shift quickly when roles, trust policies or resource permissions are modified. A clean result at one point in time does not guarantee the same path will remain closed after the next deployment or integration change.
Risk and Threat Considerations
PMapper is valuable because the main AWS risk is often not a single overpermissive statement, but a chain of individually plausible relationships that together create sensitive reachability. Those chains can enable escalation, lateral movement, or unintended administrative access even when no single policy looks obviously dangerous.
Failure mechanism: A defender misses transitive privilege because the effective access only appears after role assumption, trust traversal, or resource-policy interaction is modelled as a path.
Impact: Sensitive resources remain reachable by principals that were assumed to be constrained, increasing the chance of privilege escalation, lateral movement, and broader blast radius after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | Models lateral movement through reachable access paths in cloud estates. |
| Recommendation — Map discovered AWS access chains to lateral-movement patterns and hunt for misuse of reachable admin paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | PMapper reveals excess effective access beyond intended job need. |
| AC-4 — Information Flow Enforcement | Transitive IAM reachability affects where principals can flow to sensitive resources. | |
| AU-6 — Audit Review, Analysis, and Reporting | Graph findings should be validated against logs and observed access behaviour. | |
| Recommendation — Reduce or remove permissions that create unnecessary effective access paths. Tighten trust and resource policies to block unauthorized access paths. Correlate discovered paths with audit evidence before treating them as active exposure. | ||
Practitioner Guidance
What to prioritise: Focus first on paths that end in production data, administrative actions, cross-account access, or roles that can be assumed by many principals. Those are the places where graph findings are most likely to translate into material exposure rather than theoretical noise.
What to verify: Confirm whether each discovered path is actually intended, whether the trust relationship is still required, and whether the principal needs the full chain or only a narrower permission. If the answer is “only for a migration” or “only for one service,” treat the access as temporary and reviewable.
Practitioner takeaway: The most useful output from PMapper is not a list of permissions, but a ranked view of where AWS access can be chained into reachability that the policy owner did not expect.
Related resources from NHI Mgmt Group
- What breaks when defenders rely on EDR alone against attackers who use living off the land or safe mode evasion?
- Why do malicious campaigns that use customized backdoors increase detection risk for enterprise defenders?
- Why do email ransomware campaigns that use first-stage payloads create a different risk profile for defenders?
- What happens when defenders use decoys to expose stealthy attackers?