Privilege Escalation Techniques

Privilege escalation is a core attack class within offensive security engagements, describing the methods by which an attacker or authorized tester moves from a lower-privilege foothold to a higher-privilege position within a target system or network. The techniques documented here span both local and domain-level escalation paths and are referenced extensively in professional penetration testing frameworks including MITRE ATT&CK and NIST SP 800-115. Understanding the classification and mechanics of privilege escalation is essential to interpreting penetration test findings, scoping assessments accurately, and satisfying compliance obligations under frameworks such as PCI DSS v4.0 and FedRAMP. This page covers the penetration testing services landscape as it relates to escalation-focused engagements.

Definition and scope

Privilege escalation refers to the exploitation of a vulnerability, misconfiguration, or design flaw that allows a principal operating at one access level to acquire permissions belonging to a higher-privileged account, role, or process. The MITRE ATT&CK framework catalogues privilege escalation as tactic TA0004, provider over 60 discrete techniques and sub-techniques as of its publicly maintained enterprise matrix.

The scope of privilege escalation as a penetration testing discipline divides into two primary classes:

• Vertical privilege escalation — elevation from a lower-privilege account (e.g., a standard user) to a higher-privilege account (e.g., local administrator, SYSTEM, or root). This is the most commonly targeted escalation path in internal network assessments.
• Horizontal privilege escalation — lateral movement to a different account at the same privilege level, typically to access data or systems that belong to another user. Horizontal escalation is particularly relevant in multi-tenant applications and shared infrastructure environments.

Both classes are treated as in-scope findings under NIST SP 800-115, which defines penetration testing as assessors mimicking real-world attacks to identify methods for circumventing security features. The Computer Fraud and Abuse Act (18 U.S.C. § 1030) draws a direct legal boundary around these techniques: execution without written authorization constitutes unauthorized computer access regardless of the technical method used.

How it works

Privilege escalation follows a structured attack chain within a penetration test engagement. The general sequence recognized by NIST SP 800-115 and operationalized within the PTES (Penetration Testing Execution Standard) proceeds across five phases:

1. Initial access and foothold establishment — The tester gains entry to the target environment with minimal privileges, typically through phishing simulation, credential reuse, or exploitation of an exposed service.
2. Local enumeration — Automated and manual enumeration tools (e.g., LinPEAS for Linux, WinPEAS for Windows) inventory running processes, scheduled tasks, installed software versions, SUID/SGID binaries, unquoted service paths, and token privileges.
3. Vulnerability identification — Findings from enumeration are cross-referenced against known privilege escalation vectors. On Windows systems, common targets include misconfigured service binaries, weak ACLs on registry keys, and AlwaysInstallElevated policy settings. On Linux, setuid misconfigurations, writable cron jobs, and kernel exploits are primary targets.
4. Exploitation — The identified vector is actively exploited. This may involve replacing a service binary, injecting a DLL into a privileged process, abusing a token impersonation capability (e.g., SeImpersonatePrivilege in Windows), or invoking a kernel vulnerability such as a Dirty COW-class flaw on unpatched Linux kernels.
5. Verification and documentation — The escalated privilege is confirmed, the access level is documented with evidence, and the tester proceeds with the engagement under the new privilege context.

The purpose and scope of penetration testing directories reflects this phased methodology, with tester qualifications — including familiarity with post-exploitation tooling — a primary differentiator in provider selection.

Common scenarios

Privilege escalation appears across a range of real-world penetration testing contexts. The four scenarios below represent the most commonly documented escalation paths in professional engagements:

Unquoted service paths (Windows) — When a Windows service executable path contains a space and is not enclosed in quotation marks, an attacker with write access to an intermediate provider network can place a malicious binary that the Service Control Manager executes under SYSTEM context. This misconfiguration is endemic to legacy Windows environments and corporate endpoint fleets.

Sudo misconfiguration (Linux) — Overly permissive sudoers entries — such as granting a user the ability to run a text editor, scripting interpreter, or file manager as root — allow direct shell escalation. The GTFOBins project, maintained publicly at gtfobins.github.io, catalogues over 200 Unix binaries exploitable in this manner.

Active Provider Network Kerberoasting — In Windows domain environments, any authenticated domain user can request service tickets (TGS) for accounts with registered Service Principal Names (SPNs). Offline cracking of the resulting RC4 or AES-encrypted tickets can yield plaintext credentials for service accounts, which frequently hold elevated or domain-level privileges. MITRE ATT&CK documents this as sub-technique T1558.003.

Token impersonation — Windows access tokens determine the security context of running processes. When a service running as a low-privilege user can interact with tokens belonging to higher-privilege processes — a condition enabled by SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege — the tester can impersonate the higher-privilege token. This technique, formalized under MITRE ATT&CK T1134, was the underlying mechanism in the Potato family of exploits (RottenPotato, JuicyPotato, PrintSpoofer).

Decision boundaries

Penetration testers and their clients face a set of classification decisions that determine which escalation techniques are authorized, documented, and acted upon within a given engagement.

In-scope vs. out-of-scope escalation paths — Engagement rules of engagement (RoE) typically enumerate specific target systems and define whether domain controller compromise is an authorized objective. Escalation to production credentials or systems outside the defined target range requires explicit client authorization, a requirement enforced under the Computer Fraud and Abuse Act (18 U.S.C. § 1030) and reinforced by PCI DSS v4.0 Requirement 11.4, which mandates documented penetration testing scope.

Exploit-based vs. configuration-based escalation — Testers must distinguish between escalation achieved through kernel or software exploits (which carry system stability risk and may be prohibited on production hosts) and configuration-based escalation (which involves no binary exploitation and generally carries lower operational risk). Mature RoE documents segment these categories explicitly.

Automated vs. manual escalation — Automated post-exploitation frameworks such as Metasploit's local exploit suggester enumerate potential paths rapidly but may generate false positives or miss context-dependent vectors. Manual review — particularly of ACLs, group policy settings, and custom application configurations — is required to validate findings before reporting. NIST SP 800-115 characterizes this hybrid approach as standard for comprehensive assessments.

Reporting classification — Privilege escalation findings are typically rated using the CVSS (Common Vulnerability Scoring System) base scoring model. A local privilege escalation with high attack complexity and no network exposure may score between 6.0 and 7.8, while an unauthenticated remote escalation path may reach 9.8. The how to use this penetration testing resource page provides additional framing on interpreting finding severity within professional reports.

PCI DSS v4.0, FedRAMP, and CMMC 2.0 all require that penetration testing findings — including privilege escalation paths — be remediated and retested within defined windows, with Level 2 CMMC requirements (32 CFR Part 170) mandating third-party assessor verification for organizations handling Controlled Unclassified Information.