Privilege Escalation Techniques

Privilege escalation is a core phase of offensive security engagements, representing the mechanism by which an attacker or authorized tester advances from a limited initial foothold to higher-level system or domain control. This page covers the definition and classification of privilege escalation techniques, the operational mechanics that underpin each variant, the scenarios in which escalation is most frequently observed during penetration testing, and the decision criteria that distinguish escalation paths from one another. The subject is directly relevant to compliance-mandated testing under frameworks including NIST, PCI DSS, and HIPAA.


Definition and scope

Privilege escalation describes the set of techniques by which an attacker who has already gained access to a system at one permission level elevates that access to a higher level — typically from a standard or guest account to administrator, root, SYSTEM, or domain administrator. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment classifies privilege escalation as a post-exploitation activity that occurs after an initial access vector has been successfully used.

The scope of privilege escalation spans two primary classification boundaries:

These two categories are structurally distinct: vertical escalation increases the depth of access within a single system; horizontal escalation increases the breadth of access across a trust boundary. Within penetration testing engagements, both are documented separately in penetration testing reporting because they carry different remediation implications and different risk ratings under the Common Vulnerability Scoring System (CVSS).

Regulatory frameworks that mandate penetration testing — including PCI DSS v4.0 Requirement 11.4 and HIPAA Security Rule 45 CFR § 164.308(a)(8) — require that assessors demonstrate actual exploitation of vulnerabilities, making privilege escalation a required component of any compliant penetration test, not an optional extension.


How it works

Privilege escalation follows a structured sequence within a penetration test. The tester begins from an established low-privilege foothold — obtained through exploitation techniques — and then systematically identifies misconfigurations, vulnerabilities, or credential exposure that permits elevation.

The operational mechanics typically proceed through the following phases:

  1. Enumeration — The tester catalogs the current account's permissions, group memberships, running processes, scheduled tasks, installed software versions, and accessible file paths. Tools such as Metasploit Framework include post-exploitation modules specifically designed for this enumeration step.
  2. Vulnerability identification — The tester identifies one or more escalation vectors: unpatched kernel vulnerabilities, misconfigured sudo rules, SUID/SGID binaries on Linux, weak service permissions on Windows, stored credentials in configuration files, or token impersonation opportunities.
  3. Exploitation — A specific technique is applied to exploit the identified vector. On Windows systems, this commonly involves abusing SeImpersonatePrivilege through techniques such as Potato exploits. On Linux systems, kernel exploits (e.g., Dirty COW, CVE-2016-5195) or misconfigured cron jobs are frequent vectors.
  4. Verification — The tester confirms the elevated privilege level by executing commands or accessing resources that were previously restricted, then documents the full escalation chain.
  5. Documentation — The vector, steps taken, and resulting access level are recorded for inclusion in the formal report.

The MITRE ATT&CK Framework catalogs privilege escalation as Tactic TA0004, listing over 60 discrete techniques and sub-techniques across Windows, Linux, macOS, and cloud environments. ATT&CK is the authoritative public taxonomy used by penetration testers and defenders to classify and communicate escalation findings.


Common scenarios

Privilege escalation surfaces across all major penetration testing engagement types. The following scenarios represent the most frequently documented escalation contexts in professional assessments:

Unpatched operating system vulnerabilities — A known kernel or OS component vulnerability allows a local user to execute code in a privileged context. The National Vulnerability Database (NVD), maintained by NIST, lists kernel privilege escalation vulnerabilities with CVSS base scores routinely exceeding 7.0 out of 10.0.

Misconfigured service permissions (Windows) — Services running under high-privilege accounts with writable binary paths allow an attacker to replace the service executable. This is a documented Windows-specific vector covered under MITRE ATT&CK Sub-Technique T1574.010.

Sudo misconfigurations (Linux) — Overly permissive /etc/sudoers entries — for example, granting a non-root user unrestricted sudo access to a text editor or scripting interpreter — provide a direct path to root. GTFOBins, a public reference maintained by security researchers, documents over 150 Unix binaries that can be abused for privilege escalation when invoked with elevated permissions.

Token impersonation (Windows) — Attackers abuse Windows access tokens when a high-privilege service or process is running in the same session context. The SeImpersonatePrivilege right, commonly present on service accounts used in IIS or SQL Server deployments, is a well-documented escalation vector.

Credential exposure in files or registries — Hardcoded or cached credentials in configuration files, registry hives, or unattended installation answer files (e.g., unattend.xml) provide direct account takeover without exploiting a vulnerability.

Cloud environment misconfigurations — In cloud environments, overly permissive IAM roles or instance metadata service (IMDS) misconfigurations allow an attacker to retrieve credentials granting escalated permissions. This vector is increasingly prominent in cloud penetration testing engagements.


Decision boundaries

Determining which escalation path to pursue — and what scope limitations apply — requires the tester to evaluate several structured criteria before proceeding.

Vertical vs. horizontal priority — In most engagements, vertical escalation to SYSTEM, root, or domain administrator is the primary objective, as it demonstrates maximum impact. Horizontal escalation is pursued when cross-account data access is in scope (e.g., testing for tenant isolation failures in multi-tenant applications).

In-scope authorization — The rules of engagement for the engagement must explicitly authorize privilege escalation activity. Escalating to domain administrator without authorization constitutes unauthorized access under the Computer Fraud and Abuse Act (18 U.S.C. § 1030). Authorization boundaries must be verified before any escalation attempt.

Destructive vs. non-destructive techniques — Some escalation techniques — particularly kernel exploits — carry a risk of system instability. Professional testers follow the Penetration Testing Execution Standard (PTES) guidance to prefer non-destructive proof-of-concept exploitation over techniques that may crash or corrupt production systems.

Automated vs. manual escalation — Automated tools (e.g., WinPEAS, LinPEAS, BeRoot) can enumerate escalation vectors rapidly, but manual verification is required to confirm exploitability and eliminate false positives. The distinction between automated enumeration and confirmed exploitation is significant for report classification under NIST SP 800-115.

Compliance-driven scope requirements — Under PCI DSS v4.0 Requirement 11.4.1, penetration tests must include attempts to exploit identified vulnerabilities — meaning testers operating in cardholder data environments are expected to attempt escalation when plausible vectors are found, not merely report them as theoretical risks.


References

📜 2 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site