What Is a Privilege Escalation Attack?
MITRE ATT&CK defines Privilege Escalation as techniques adversaries use to gain higher-level permissions on a system or network. An attacker may begin with a normal user account, a low-privilege process or a constrained application role and then attempt to reach administrative, root/SYSTEM or otherwise more sensitive permissions.
Privilege escalation is not limited to operating systems. Web and API authorization failures can let one user act as another user or invoke administrator-only functions. The underlying security problem is the same: the system grants a capability that the current principal should not possess.
Vertical vs Horizontal Privilege Escalation
| Type | Meaning | Example |
|---|---|---|
| Vertical | Move to a more privileged role | Normal user reaches an administrator function |
| Horizontal | Reach another peer user’s data or actions | User A reads or modifies User B’s object |
| Process/host escalation | Low-privilege process gains OS-level rights | Service account process gains root/SYSTEM-like privileges |
| Cloud/workload escalation | Workload assumes broader cloud permissions | Compromised service identity obtains an overprivileged role |
Horizontal privilege escalation is frequently discussed as broken object-level authorization or IDOR in APIs. Vertical escalation usually targets administrative functions, role checks, elevation mechanisms or privileged execution paths.
Privilege Escalation vs Broken Access Control: Use the Terms Precisely
In web-application discussions, “horizontal privilege escalation” often means accessing another user’s data at the same nominal role, while “vertical privilege escalation” means gaining administrator or higher-role capabilities. OWASP generally treats both as authorization failures.
MITRE ATT&CK’s Privilege Escalation tactic is narrower: the adversary is trying to gain higher-level permissions on a system or network. An IDOR/BOLA flaw that exposes another customer’s object is serious broken access control even when it does not grant operating-system or administrator privileges.
| Scenario | Best description |
|---|---|
| User A reads User B’s invoice because object authorization is missing | Broken object-level authorization / horizontal access-control failure |
| Normal user invokes an admin-only API because function authorization is missing | Vertical authorization / privilege escalation in the application |
| Low-privilege process exploits a kernel/service vulnerability and becomes root/SYSTEM | Host privilege escalation |
| Workload assumes an unintended cloud administrator role | Cloud IAM privilege escalation |
Common Privilege Escalation Techniques
At a high level, attackers look for weaknesses that bridge privilege boundaries. Defensive teams should map these categories to their environment rather than focusing on a single exploit tool.
- Exploitation of kernel, driver, service or application vulnerabilities for elevation.
- Abuse of operating-system elevation mechanisms or misconfigured privileged helpers.
- Weak file, registry, service or task permissions that allow lower-privileged modification of code executed by a privileged context.
- Credential or token theft from higher-privileged users and processes.
- Broken role checks, insecure direct object references or hidden admin endpoints in web applications and APIs.
- Overly broad cloud IAM roles, service-account permissions or workload identity trust relationships.
- Container escape or host-interface exposure that turns workload compromise into host-level access.
Privilege Escalation Examples
API role bypass
A standard user sends a request to an administrator endpoint and the server checks only whether the user is authenticated, not whether the role is authorized.
Object-level escalation
A customer changes an object identifier and accesses another customer’s resource because ownership is not rechecked server-side.
Host elevation
A low-privilege service exploits an unpatched local component and gains a more privileged execution context.
Cloud permission chain
A compromised workload can assume a role that was intended only for a deployment system because the trust policy is too broad.
Across these scenarios, the key investigation question is the same: which privilege boundary was crossed, what control should have blocked the transition, and what telemetry proves the new authority was actually used?
How to Detect Privilege Escalation
MITRE ATT&CK emphasizes the transition into higher privilege. Detection therefore works best when telemetry can answer two questions: what authority did this identity/process have before the event, and what new authority did it gain or use afterward?
| Layer | High-value detection signals |
|---|---|
| Endpoint | Unexpected privileged process creation, elevation events, unusual parent/child lineage, driver or service changes |
| Linux/Unix | Unusual sudo/su activity, setuid execution, capability changes, privileged service modifications |
| Cloud/IAM | New role assumptions, policy attachment, trust-policy changes, privilege expansion from runtime workloads |
| API/application | Normal-role identity invoking admin functions, cross-tenant object access, role changes followed by sensitive actions |
Baseline by identity and workload role rather than treating every privileged action as suspicious. A deployment controller may legitimately create infrastructure; the same API call from an internet-facing application service should receive very different scrutiny.
Privilege Escalation Prevention and Mitigation
- Apply least privilege to user accounts, services, workloads and database roles.
- Patch operating systems, drivers, runtimes and privileged services promptly.
- Use explicit server-side authorization checks for every sensitive API operation and object.
- Separate administrative interfaces and management planes from normal user traffic.
- Harden elevation mechanisms, privileged service configurations and file permissions.
- Use sandboxing, application isolation and container security controls to limit blast radius.
- Protect privileged credentials with phishing-resistant MFA and dedicated admin workflows.
- Continuously review cloud IAM trust policies and eliminate wildcard permissions.
Privilege Escalation in APIs and Web Applications
API privilege escalation is usually an authorization problem rather than an authentication problem. A valid token proves who the caller is; the server must still decide whether that identity may perform the requested action on the requested object.
Perform authorization at the resource and function level on every request. Do not rely on the UI hiding buttons, a client-supplied role, predictable identifiers or a gateway route alone. See Ammune’s BOLA/IDOR guide, BOPLA guidance and authentication vs authorization.
Responding to Suspected Privilege Escalation
- Contain the affected identity, process or workload without destroying evidence.
- Preserve authentication, authorization, process, endpoint and cloud audit logs.
- Determine the original access level and the first unexpected privilege transition.
- Rotate or revoke credentials/tokens that may have been exposed.
- Patch the exploited weakness or remove the misconfiguration before restoring access.
- Hunt for persistence or lateral movement performed after elevation.
- Review why the account or service had access to the next privilege boundary.
Privilege Escalation in Cloud and Container Environments
Cloud and container platforms introduce privilege boundaries that look different from a traditional host but fail for similar reasons. A workload may have a narrow application role yet inherit broad cloud API permissions, access a node credential, mount a sensitive host path or reach a metadata/workload-identity service that grants stronger credentials.
For containers, avoid privileged mode, unnecessary Linux capabilities, writable host mounts and access to container-runtime sockets. In cloud IAM, constrain role trust relationships and separate deployment automation from runtime identities. A service that only reads one object store should not also be able to create IAM users, attach policies or assume unrelated roles.
- Continuously compare effective workload permissions with intended permissions.
- Alert when a runtime workload assumes an administrative or deployment role.
- Use admission/policy controls to block privileged container configurations.
- Keep management-plane credentials out of application containers and CI artifacts.
Authorization Regression Testing for APIs
Privilege boundaries change as endpoints, roles and microservices evolve. A useful regression suite treats authorization as a matrix rather than a single “logged in / not logged in” test.
- Role × endpoint: verify that standard users cannot call administrator or operator-only functions.
- User × object: verify ownership on every object lookup, update and delete, not only on list screens.
- Tenant × resource: confirm that identifiers from another tenant remain inaccessible even when the caller knows the identifier.
- Method × route: test GET, POST, PUT, PATCH and DELETE independently because middleware and policy coverage can differ.
- New feature × old role: add negative authorization tests whenever a route, role or privilege is introduced.
OWASP’s authorization guidance emphasizes server-side checks on every request. Automated negative tests help keep that rule true after refactoring and are especially valuable for BOLA/IDOR and function-level authorization regressions. Related Ammune guidance: BOLA/IDOR API security and broken object property-level authorization.
Runtime Visibility for Privileged API Behavior
Authorization must be enforced by the application on every relevant object and function. Ammune can complement that design by highlighting authenticated API behavior that deviates from normal privilege use—especially sensitive operations, unusual endpoint sequences or access patterns that merit investigation.
Privilege Escalation Security Checklist
- Inventory privileged roles, service accounts and administrative APIs.
- Enforce object- and function-level authorization server-side.
- Patch local privilege escalation vulnerabilities promptly.
- Harden privileged helpers, services and workload identities.
- Use separate privileged accounts and phishing-resistant MFA.
- Alert on unusual privilege grants, token changes and role assumptions.
- Correlate API, endpoint and cloud audit data during investigations.
- Regularly test vertical and horizontal authorization boundaries.
Frequently Asked Questions
What is privilege escalation?
Privilege escalation is gaining permissions beyond those originally assigned to an account, process or workload.
What is vertical privilege escalation?
Vertical escalation moves from a lower role to a higher role, such as a normal user reaching administrator capabilities.
What is horizontal privilege escalation?
Horizontal escalation accesses another peer user’s data or actions without necessarily becoming an administrator.
How can privilege escalation be detected?
Look for unexpected privilege transitions, new privileged processes or roles, unusual admin API access, cross-tenant object access and security-policy violations.
What is the most important prevention control?
Least privilege combined with explicit authorization at every privilege boundary is foundational, alongside patching and hardened elevation mechanisms.
Is IDOR a privilege escalation vulnerability?
IDOR is a broken access-control weakness. Exploiting it to reach another user’s object is often described as horizontal privilege escalation, while the root cause is missing object-level authorization.
Primary References
Detect Abnormal Privilege Use at the API Layer
Least privilege and authorization prevent many escalation paths. Ammune adds runtime visibility into unusual API behavior that may indicate broken authorization or post-authentication abuse.