Privilege Escalation & Attack Paths

Understand how an apparently limited AWS identity may obtain a stronger capability through a sequence of permissions and relationships.

A principal does not need an administrator policy directly attached to become high risk. Sometimes the risk exists in the path.

Privilege escalation vs an attached permission

Consider a developer who can call iam:PassRole. That permission alone does not fully describe the security consequence. Now add the ability to create or modify a workload that can use a privileged execution role.

The important question is no longer:

Does the developer have AdministratorAccess?

It is:

Can the developer combine existing permissions to operate through a more privileged identity or capability?

Where to find escalation analysis

The current product view is named Privilege Escalation Paths. The view shows detected paths and lets the investigator examine the selected path as a source-to-target sequence. Depending on the path, the current result can include source entity, source entity type, target entity, path type, severity, escalation steps and remediation context.

Why the documentation uses “Attack Paths”

“Attack path” is a broader security concept describing a sequence through which a starting identity could reach a security-relevant outcome. Securitain currently surfaces this capability through the Privilege Escalation Paths product view.

For documentation purposes:

• Privilege Escalation describes the current product analysis.
• Attack Path Intelligence describes the broader security idea.

Securitain does not maintain two separate engines for these concepts.

A path is a chain, not a single alert

A traditional finding may say:

iam:PassRole is present.

A path-oriented investigation asks:

Who holds the permission?
  ↓
What can it be used with?
  ↓
Which role or capability is involved?
  ↓
What is the resulting target?

This allows security teams to reason about consequence.

Example: PassRole and an AWS service

A common conceptual pattern is:

iam:PassRole does not itself cause the service to execute. It allows an IAM principal to pass a role to supported AWS services when the rest of the AWS authorization and service requirements are satisfied. The resulting risk depends on which roles can be passed, what service operations the identity can perform, what the target role can do, resource constraints, policy conditions, and applicable boundaries and organization restrictions.

Example: permission mutation

Another class of escalation can occur when an identity is allowed to change permissions.

Limited Identity
  ↓
Permission Mutation Capability
  ↓
Broader Policy / Role Permission
  ↓
Expanded Access

Examples of relevant permission-management concepts can include changing a policy, attaching a policy, changing role trust, modifying credentials, or joining a more privileged access structure.

Source, steps and target

A Securitain escalation path should be interpreted as three major pieces.

• Source — the IAM user or role from which the path begins.
• Steps — the permissions or security transitions required by the path.
• Target — the stronger role or security-relevant capability the path may lead toward.

Severity

Escalation paths can carry different severity. Severity should reflect the security significance of the path based on the evidence available to the analysis. Relevant context can include target privilege, scope, policy restrictions, conditions and other mitigating constraints.

Relationship Graph vs Privilege Escalation

The graph provides structural context. Escalation analysis applies security reasoning to that context.

Effective Permissions vs Privilege Escalation

The two analyses should often be used together:

Effective Permissions
  ↓
Sensitive capabilities
  ↓
Escalation path
  ↓
Potential target

Investigating a detected path

1. 1

   Confirm the source identity

   Determine who or what uses the identity — human user, application role, deployment role, CI/CD identity, or federated role.

2. 2

   Review each step

   Do not jump directly from source to target. Inspect the permission represented by each step.

3. 3

   Review resource scope

   Determine whether the relevant action applies to all resources, a defined resource set, a specific role, or a specific service.

4. 4

   Review policy conditions

   Conditions can materially change whether the path is executable.

5. 5

   Review the target

   Determine the security consequence of the target role or capability.

6. 6

   Review related findings

   The same identity may have broad policies, credential issues, external trust, toxic permission combinations, or least-privilege opportunities.

7. 7

   Review remediation

   Prefer fixing the narrowest permission or trust relationship that breaks the unnecessary path while preserving legitimate application behavior.

Remediation principles

Escalation remediation may involve actions such as:

• narrowing iam:PassRole resources
• restricting service permissions
• reducing IAM mutation privileges
• tightening role trust
• applying permission boundaries
• removing unused capabilities
• separating deployment and administrative duties

The correct response depends on how the identity is used. Avoid generic instructions such as:

Remove all sensitive permissions.

Cloud security remediation must preserve legitimate workloads.

Evidence and limitations

Privilege-escalation analysis depends on the information available to the scan. A detected path is stronger evidence when the relevant identity permissions, target role, trust relationship, resource scope, constraints and conditions are available and can be correlated. However, AWS behavior can still depend on runtime request context and service-specific requirements.

Related guides

• IAM Relationship Graph
• Effective Permissions
• IAM Blast Radius
• Toxic Permission Combinations
• Cross-Account Access