Datadog Security Labs has released pathrunner, a framework for testing paths from one AWS IAM identity to another identity’s credentials. Its October 20 release includes more than 80 exploit modules. For teams defending AWS accounts, the question is whether a credential already available to an operator or intruder has permissions that lead to a more powerful identity.
Datadog demonstrates that transition with credentials for an initial IAM user, a selected module and a target identity. In its example, the framework captures the target’s credentials, switches identities and validates access. The demonstration illustrates the consequence for an account where the same permissions are present: the target identity’s authority determines what the operator could do next.
An IAM principal becomes another
Pathrunner builds on Datadog’s catalog of IAM privilege-escalation paths. A path begins with an identity whose credentials the tester already holds. The operator selects a module that identity has permission to use and a target identity it can reach. In the demonstration, the resulting credentials become the next working identity. Subsequent AWS API requests can be made as that target, with its permissions.
Datadog says the framework supports multiple payloads for a module, so the visible actions can vary even when the intended destination is the same identity. Some routes may involve a workload; others move between credentials without a workload-to-workload network connection. Treat the starting principal, reachable target and API actions as separate parts of the investigation. A network-only search for a new host connection can miss an identity change carried entirely by AWS service calls.
Test a starting principal whose credentials an operator or workload actually holds. Check which modules its permissions allow and whether any reachable target has greater authority.
The report predicts CloudTrail events
After a controlled exercise, Datadog says pathrunner’s workspace report lists resources created or changed and a table of CloudTrail events the tool thinks its actions triggered, with timestamps and descriptions. Use that table as a search plan. A predicted event becomes useful detection evidence when you find the corresponding record in the account’s CloudTrail data and match the time, principal and action. Account for any test-created resources before closing the exercise.
AWS’s CloudTrail guide says Event history provides 90 days of management events, queried per account and Region. It excludes data, Insights and network activity events, and it does not aggregate an organization. For a cross-account exercise, inspect the relevant account and Region for each part of the path; use your configured trail or event data store for the event types and retention your investigation requires. If a predicted event is missing from one Region’s Event history, search the other relevant accounts, Regions and configured telemetry before deciding what the test generated.
Narrow the permission path
Start with identities whose credentials are accessible to workloads and operators, and the higher-privilege roles or users they could reach. Review the permissions and trust relationships on the specific path, then remove the unnecessary grants or restrict them with policy conditions and guardrails. AWS’s IAM guidance recommends temporary role credentials for workloads and federated human users, least-privilege permissions, regular removal of unused identities and credentials, policy conditions, and permissions boundaries for delegated administration. These controls reduce both the starting credentials available to steal and the authority a stolen identity can reach.
If your team conducts a sanctioned test, use a sandbox or a tightly scoped account with named starting and target identities, approved change and cleanup owners, and CloudTrail collection in the relevant Regions. Record the initial identity, tested permission path, target identity and expected actions. Then compare the framework’s event predictions against actual CloudTrail records. Remove test-created resources and repeat the access test after changing the policy: the previously reachable target should now be inaccessible through that path, while the intended workload access still works. This checks the control at the permission decision, where the escalation occurred.
Verify access after changing policy
Remove unnecessary permissions from the starting IAM principal or narrow the target role’s trust policy. Repeat the same sanctioned source-to-target access test: the unwanted route should fail while intended workload calls still succeed. Compare the report’s predicted API actions with actual CloudTrail records in each relevant account and Region, matching the principal, action and time. Keep those records with the policy change for detection engineering, and remove resources created during the test.