Privilege Escalation

Description

Privilege escalation occurs when a user or process gains access rights beyond what was originally authorized. In the context of CWE-269 (Improper Privilege Management), the root cause is either a failure to enforce role boundaries or a flaw that allows a lower-privileged identity to assume a higher-privileged one. The attack may be vertical — a regular user gaining administrator access — or horizontal — one user accessing another user's resources at the same privilege tier.

This vulnerability class sits at the core of A01:2021 — Broken Access Control and is among the most damaging findings in a penetration test. Once an attacker achieves privilege escalation, the entire confidentiality, integrity, and availability posture of the application or infrastructure collapses. The resulting access is typically used to exfiltrate data, establish persistence, move laterally, or fully compromise the platform.

Privilege escalation surfaces across every layer of a modern stack: web applications, APIs, mobile apps, operating systems, cloud IAM policies, and container orchestration platforms. A misconfigured IAM role in AWS, a missing authorization check in a REST endpoint, or a SUID binary on Linux can all result in the same outcome — unauthorized elevation.

How It Works

Vertical privilege escalation exploits missing or bypassable authorization checks. A classic example is a parameter manipulation attack where a user changes their role in a request:

POST /api/account/update HTTP/1.1
Host: app.example.com
Authorization: Bearer <user_token>
Content-Type: application/json

{
  "email": "attacker@example.com",
  "role": "admin"
}

If the server accepts and persists the role field without validating that the caller is authorized to change it, the attacker has escalated to administrator. This intersects with mass assignment (CWE-915) but the authorization failure is the critical element.

Horizontal privilege escalation is simpler: replace an object identifier with another user's ID. If the response contains that user's data, authorization is entirely absent.

On operating systems and cloud platforms, escalation paths include:

• SUID/SGID binaries — on Linux, find / -perm -4000 -type f reveals binaries that run as root. GTFOBins documents dozens of abusable binaries (e.g., sudo vim, python with sudo).
• Misconfigured sudo rules — sudo -l reveals commands a user can run as root. A rule like (ALL) NOPASSWD: /usr/bin/python3 allows immediate shell escalation.
• Cloud IAM overpermissioning — an IAM role with iam:PassRole and ec2:RunInstances can create a new EC2 instance with an admin role attached, effectively inheriting those permissions.
• Token impersonation — in Windows environments, a process with SeImpersonatePrivilege can leverage tools like PrintSpoofer or JuicyPotato to impersonate SYSTEM.

Impact

• Full administrative takeover — attacker gains platform or application admin rights, enabling account creation, data access, and configuration changes.
• Data exfiltration — elevated access exposes all user data, including PII, credentials, and proprietary records.
• Persistence — admins can create backdoor accounts, install rootkits, or modify audit logging to hide activity.
• Lateral movement — administrative credentials are often reused across systems, enabling broader network compromise.
• Infrastructure destruction — in cloud environments, an admin can delete databases, terminate instances, or incur runaway costs.
• Compliance breach — privilege escalation in systems handling PCI-DSS, HIPAA, or SOC 2 data triggers mandatory incident reporting.

Detection

1. Enumerate exposed role/permission parameters in all API requests — both request bodies and headers. Attempt to set role, isAdmin, permissions, group, or privilege fields to elevated values and observe server responses.
2. Test horizontal access by capturing authenticated requests for your own resources, then systematically replace object IDs with sequential or enumerated values belonging to other accounts.
3. Audit sudo and SUID on Linux hosts — run sudo -l and find / -perm -4000 -type f 2>/dev/null. Cross-reference results with GTFOBins.
4. Review cloud IAM policies — use tools such as Prowler, ScoutSuite, or Pacu to enumerate overpermissive IAM roles. Specifically check for iam:PassRole, sts:AssumeRole, iam:CreateAccessKey, and wildcard resource policies.
5. Check JWT and session token claims — decode tokens with jwt.io or jwt_tool and attempt to modify role claims, then re-sign or replay with the modified token.
6. Test administrative endpoints directly — send requests to /admin, /api/v1/admin/*, and management endpoints using low-privileged tokens. A 200 response confirms missing function-level access control.

Remediation

Enforce authorization on every request. Never derive permissions solely from client-supplied data. All privilege decisions must be made server-side based on the authenticated identity stored in a trusted session or token.

Implement role-based access control (RBAC) or attribute-based access control (ABAC). Define roles explicitly and enforce them in middleware — do not scatter if user.role == "admin" checks throughout business logic.

Apply the principle of least privilege. Every user, service account, and cloud role should have only the minimum permissions required. In AWS, use IAM Access Analyzer to identify and remediate overpermissive policies. In Linux, audit and remove unnecessary SUID binaries and sudo rules.

Validate role changes server-side. When updating user profiles, explicitly strip any fields that affect authorization (e.g., role, isAdmin) before persisting. Use an allowlist of modifiable fields rather than a blocklist.

Log and alert on privilege changes. Every role modification, privilege grant, and administrative action should generate an audit log entry. Alert on anomalies such as self-service role elevation.