> whoami && echo 'user' → whoami && echo 'SYSTEM'_
A tester compromises a web application through an SQL injection vulnerability. They can read the application database — customer names, email addresses, hashed passwords. It's a serious finding. But the application runs as a low-privilege service account with no access to other systems, no domain credentials, and no network route beyond the database server. The blast radius is contained.
Now the tester escalates. A misconfigured sudo rule on the application server allows the service account to execute a single command as root. That root access reveals a plaintext database connection string containing a domain service account's credentials. That service account has local admin rights on three servers. One of those servers has a Domain Admin session cached in memory. Within two hours, the SQL injection — a single application-layer vulnerability — has become a full domain compromise.
The SQL injection didn't change. Its CVSS score is the same. But its real-world impact expanded from "read one database" to "control the entire organisation" — because privilege escalation connected it to the domain through a chain of stepping stones that no scanner would ever map.
This is why privilege escalation matters more than any individual vulnerability. It's the mechanism that determines whether a compromise stays local or goes global. And it's the phase of the pen test that most directly answers the question the board actually cares about: if someone gets in, how bad does it get?
Privilege escalation is the process of gaining a higher level of access than currently held — moving from standard user to local administrator, from local admin to Domain Admin, from application user to root, from a read-only role to full control. Every step up the privilege ladder expands what the attacker can see, do, and destroy.
Privilege escalation moves in two directions, and both are tested systematically during a penetration test. Vertical escalation is what most people picture — climbing the privilege ladder. Horizontal escalation is subtler, often more impactful, and far more commonly overlooked.
| Vertical Escalation | Horizontal Escalation | |
|---|---|---|
| Definition | Gaining a higher privilege level than your current role — standard user to admin, user to root, employee to Domain Admin. | Accessing resources at the same privilege level but belonging to a different user or context — User A accessing User B's data, one department's employee accessing another department's systems. |
| Typical example | A standard domain user exploits a misconfigured service to gain local admin, then extracts cached credentials to reach Domain Admin. | A customer changes an account ID in a URL and retrieves another customer's invoices, medical records, or personal information. |
| Why it matters | Vertical escalation expands the attacker's capability — what they can do. An admin can install software, change configurations, access all data, deploy malware, and cover their tracks. | Horizontal escalation expands the attacker's reach — whose data they can access. One compromised customer account becomes access to every customer's account. The capability stays the same; the damage scales to the entire user base. |
| Detection difficulty | Moderate — vertical escalation often leaves traces: new processes running as SYSTEM, authentication to privileged endpoints, modifications to security-sensitive configurations. | Very difficult — the attacker is performing the same actions as a legitimate user, just against a different user's resources. The request is syntactically identical to normal usage. |
| Scanner detection | Limited — scanners can identify some privilege escalation prerequisites (misconfigured permissions, known CVEs) but cannot execute the multi-step process of actually escalating. | Near zero — the scanner has no concept of data ownership. It cannot distinguish "my data" from "someone else's data" in the response. |
Both directions are equally important. A vertical escalation to Domain Admin is catastrophic but visible — the finding demands immediate action. A horizontal escalation across 50,000 customer accounts is equally catastrophic but can persist undetected for months because it looks like normal application usage.
Windows environments present a rich set of privilege escalation opportunities because they're complex, configured by humans, and rely on layered permissions that accumulate exceptions over years of operation. Here are the paths we encounter and exploit most frequently.
| Escalation Path | How It Works | How Common |
|---|---|---|
| Unquoted service paths | A Windows service binary path contains spaces but isn't enclosed in quotes. Windows attempts to resolve the path sequentially, and the attacker places a malicious binary at the first resolution point. When the service restarts, it executes the attacker's code — as SYSTEM. | Found in approximately 30% of internal tests. Often multiple instances per environment. Exploitation requires write access to a specific directory but the misconfiguration is trivially identified. |
| Weak service permissions | A Windows service is configured so that standard users can modify its binary path or start/stop it. The attacker changes the binary path to point to their own executable. The next time the service restarts, it runs the attacker's code with the service's privileges — typically SYSTEM or a high-privilege service account. | Found in approximately 20% of internal tests. Third-party software installations are the most common source — the installer sets permissive ACLs on the service configuration. |
| AlwaysInstallElevated | A Group Policy setting that allows any user to install MSI packages with SYSTEM privileges. The attacker generates a malicious MSI that executes arbitrary code during installation. It runs as SYSTEM because the policy explicitly grants that privilege. | Less common (approximately 10% of internal tests) but trivially exploitable when present. A single GPO misconfiguration grants SYSTEM to every user on every machine where the policy applies. |
| Token impersonation | If the attacker has SeImpersonatePrivilege (standard for service accounts), they can impersonate any token available on the system — including SYSTEM tokens. Tools like PrintSpoofer, GodPotato, and JuicyPotato automate this. A web shell running as a service account becomes SYSTEM in seconds. | Applicable whenever the initial foothold is a service account context — which includes most web application compromises, SQL Server command execution, and IIS application pool identities. |
| Cached credentials | Windows caches domain credentials in memory (LSASS) for any user who has logged in interactively. If a privileged user — a Domain Admin, a server administrator — has logged into the compromised machine, their credentials may still be in memory. The attacker extracts them with Mimikatz or equivalent. | The single most impactful escalation path on internal tests. If DA has ever logged into a workstation and the attacker gains local admin on that workstation, the domain is compromised. |
Linux privilege escalation tends to exploit configuration mistakes rather than software vulnerabilities — misconfigured permissions, overly permissive sudo rules, and credentials left in places they shouldn't be. The paths are different from Windows but the principle is identical: a small misconfiguration creates a bridge to the highest privilege level.
| Escalation Path | How It Works | How Common |
|---|---|---|
| Sudo misconfigurations | The user can run specific commands as root via sudo. Many commands that seem harmless can be abused: sudo vim (escape to shell), sudo find (execute arbitrary commands), sudo python (spawn root shell), sudo env (bypass restrictions). GTFOBins catalogues hundreds of these. |
Found in approximately 40% of Linux escalation assessments. The most common path. Often introduced by administrators granting specific utility access without understanding the escape routes. |
| SUID binaries | A binary with the SUID bit set executes with the file owner's privileges (typically root) regardless of who runs it. Custom or outdated SUID binaries may allow the attacker to read protected files, write to restricted locations, or spawn a root shell. | Found in approximately 25% of assessments. Custom SUID binaries are the highest risk — they're rarely audited and frequently contain command injection or path traversal vulnerabilities. |
| Credentials in files | Plaintext passwords in configuration files, bash history, environment variables, cron jobs, backup scripts, or application config files. Database credentials that happen to match the root password. SSH keys with no passphrase stored in home directories. | Found in approximately 50% of assessments. The most reliably present escalation vector. Organisations that rotate passwords on interactive accounts often forget service credentials in config files. |
| Writable cron jobs / systemd timers | A scheduled task runs as root but the script it executes is writable by the current user. The attacker modifies the script to include their payload. The next time the task runs, it executes the attacker's code as root. | Found in approximately 15% of assessments. Often in legacy environments where cron scripts were written by administrators who assumed only they would have access. |
| Kernel exploits | An unpatched kernel vulnerability allows a local user to gain root. Exploits for specific kernel versions are publicly available and often reliable. The attacker confirms the kernel version and runs the appropriate exploit. | Less common in well-maintained environments but still present where patching cadence is slow. Container escape via kernel exploitation is an emerging variant. |
Active Directory privilege escalation is the single most consequential category of escalation in most enterprise environments. Domain Admin is the ultimate objective — it grants unrestricted control over every domain-joined system, every user account, every Group Policy, and every piece of data on the network. The paths to DA are numerous, and we find exploitable ones in the vast majority of internal assessments.
The critical insight is that these aren't vulnerabilities in the traditional sense — they're features of Active Directory being used in ways the environment wasn't designed to withstand. Kerberoasting is Kerberos working as designed. BloodHound paths are legitimate permissions chained together. The "vulnerability" is the configuration, not the protocol.
Cloud environments introduce a different privilege model — identity and access management (IAM) policies replace traditional file permissions, and the blast radius of a single escalation can span hundreds of services across an entire cloud estate.
| Escalation Path | How It Works | Impact |
|---|---|---|
| IAM role chaining | A user with permission to assume one IAM role discovers that the target role can assume another, which can assume another — each with broader permissions. The chain terminates at a role with administrative access. The original user had minimal permissions; the final role has full control. | Complete cloud estate compromise from a low-privilege starting position. The permission chain exists because each individual role assumption was "justified" in isolation — nobody mapped the transitive path. |
| Instance metadata exploitation | An SSRF or command execution on a cloud instance allows the attacker to query the metadata service (169.254.169.254) and retrieve temporary IAM credentials. If the instance role is over-permissive, those credentials grant access far beyond the application's needs. | The instance role becomes the attacker's role. If the role has S3 read access across all buckets, the attacker has S3 read access across all buckets. Instance roles are routinely over-provisioned because "it needed access to one bucket, and it was easier to grant access to all." |
| Lambda / function privilege abuse | A user who can create or modify serverless functions can assign an execution role with higher privileges than their own. The function executes with the elevated role's permissions, effectively laundering the privilege escalation through a legitimate service. | Serverless functions are often assigned broad roles for convenience. A user with Lambda create permissions can escalate to any role that Lambda is allowed to assume — which is often every role in the account. |
| Cross-account trust abuse | Organisation A trusts Organisation B's IAM roles for a legitimate integration. A compromised account in Organisation B can assume a role in Organisation A — crossing the organisational boundary through the trust relationship. | Supply chain compromise via cloud trust. The victim organisation's security posture is irrelevant if a trusted partner's credentials are compromised and the trust relationship doesn't restrict which principals can assume the cross-account role. |
| Entra ID role escalation | A user with Application Administrator can grant application consent, create credentials for service principals, or modify enterprise applications — effectively escalating to Global Admin through the application layer without directly holding the Global Admin role. | Entra ID (Azure AD) has over 80 built-in roles. Many roles that appear administrative-but-limited actually provide indirect paths to full tenant control through application management, conditional access modification, or authentication policy changes. |
Web application privilege escalation deserves separate treatment because its patterns are distinct from infrastructure escalation — and because it's the category most commonly missed by organisations that believe their access control testing is covered by a vulnerability scanner.
| Pattern | How It Works | Example |
|---|---|---|
| Parameter tampering | The application accepts a role or privilege identifier in the request and trusts it without server-side validation. The attacker modifies the parameter to claim a higher privilege. | A registration form includes a hidden field role=user. Changing it to role=admin before submission creates an admin account. The server accepts whatever the client sends. |
| JWT manipulation | The JWT token contains a role claim that the server trusts without proper signature verification. The attacker modifies the claim and re-signs with a weak secret, or sets the algorithm to none. |
The JWT payload contains {"role": "user"}. The attacker changes it to {"role": "admin"} and sets "alg": "none". The server accepts the unsigned token and grants admin access. |
| Forced browsing to admin functions | Admin endpoints exist and are functional but are only "hidden" by the UI — no server-side authorisation check prevents a lower-privilege user from calling them directly. | The admin dashboard is at /admin/dashboard. The navigation menu doesn't show it for standard users. But navigating directly to the URL returns the full admin interface — because nobody enforced access control on the route. |
| Multi-step process bypass | The application enforces privilege checks at Step 1 of a multi-step process (e.g. loading the admin form) but not at Step 3 (submitting it). The attacker skips to Step 3 and submits the action directly. | The "create user" form is restricted to admins. But the POST endpoint that processes the form submission doesn't check privileges — any authenticated user who sends the right parameters creates a new user. |
| API version discrepancy | The application has migrated to API v2 with proper access controls, but v1 is still accessible and lacks the restrictions. The attacker discovers v1 through documentation, directory brute-forcing, or JavaScript source analysis. | The /api/v2/users endpoint requires admin authentication. The legacy /api/v1/users endpoint is still live, still functional, and has no authorisation check at all. |
In practice, privilege escalation rarely happens in a single step. It's a chain of incremental gains — each step granting slightly more access, slightly more capability, until the attacker reaches the objective. Understanding the chain is what makes escalation testing valuable beyond just identifying the individual weaknesses.
Five steps. Three hours. A SQL injection in a search field becomes complete domain compromise. Every individual step is well-documented and individually addressable — but the chain only becomes visible when a human tester walks it end to end, making the decisions at each step that determine the next one.
A vulnerability assessment enumerates individual weaknesses and rates each one in isolation. A penetration test with escalation answers a fundamentally different question: what is the actual consequence of these weaknesses when an attacker chains them together?
| Without Escalation Testing | With Escalation Testing | |
|---|---|---|
| Finding | "Kerberoastable service account identified. CVSS: 5.4 (Medium)." | "Kerberoastable service account cracked in 7 minutes. Account is member of Backup Operators. Used to extract NTDS.dit and achieve Domain Admin. CVSS: 5.4 individually; chain impact: Critical." |
| Remediation priority | Medium — sits in the backlog behind the high-severity findings. | Highest priority — breaking this chain is the most efficient way to prevent domain compromise. |
| Board message | "We have 4 highs and 12 mediums. No critical findings." | "A tester achieved full domain control in 3 hours from an application vulnerability. The escalation chain can be broken by changing one service account password and removing Backup Operators membership." |
| Risk understanding | Abstract — the report lists weaknesses but the organisation doesn't know which ones actually lead to compromise. | Concrete — the report demonstrates the exact path from entry point to objective, with timing, evidence, and specific remediation at each step. |
| Defensive value | Fix the findings individually, hope the combinations are covered. | Fix the chain links strategically: break the most dangerous paths first, add detection at each escalation step, and verify the chain no longer works during the retest. |
The most effective defence against privilege escalation is defence in depth — controls at every level that each independently limit how far an attacker can progress. No single control will stop a determined adversary, but layered controls ensure they have to bypass multiple barriers, each of which creates an opportunity for detection.
| Defence Layer | What It Prevents | Implementation |
|---|---|---|
| Least privilege | Prevents unnecessary permissions from creating escalation paths. Service accounts that don't need DA shouldn't have it. Users that don't need local admin shouldn't have it. | Audit all service accounts, remove DA membership where not required, implement LAPS for unique local admin passwords per workstation, remove users from local admin groups, enforce just-in-time privileged access. |
| Credential hygiene | Prevents credential-based escalation — pass-the-hash, Kerberoasting, cached credential extraction. | Enforce 25+ character passwords on all service accounts, rotate regularly, implement gMSAs where possible, disable NTLM where feasible, configure Credential Guard on endpoints, never log in to workstations with DA credentials. |
| Network segmentation | Prevents lateral movement between compromised systems. Even with valid credentials, the attacker can't reach the target if the network blocks the connection. | Segment server VLANs from workstation VLANs. Restrict RDP, SMB, and WinRM between workstations. Isolate management interfaces. Enforce jump box / PAW architecture for server administration. |
| AD hardening | Eliminates the most common AD escalation paths: Kerberoasting, delegation abuse, ACL misconfiguration, GPP passwords. | Audit and remediate Kerberoastable accounts, disable unconstrained delegation, audit ACLs on sensitive objects, remove GPP password files from SYSVOL, implement tiered administration, protect the DA tier. |
| Detection and alerting | Doesn't prevent escalation but ensures it's detected — giving the SOC the opportunity to respond before the attacker reaches the objective. | Alert on Kerberoasting (high-volume TGS requests), LDAP enumeration (BloodHound signatures), lateral movement (anomalous authentication patterns), credential dumping (LSASS access), and privilege changes (new DA membership). |
Privilege escalation is the mechanism that transforms a contained compromise into an organisational catastrophe. A SQL injection with no escalation path is a database breach. The same SQL injection with escalation to Domain Admin is a complete domain compromise with ransomware, data exfiltration, and regulatory notification.
Testing escalation — not just identifying individual vulnerabilities but actively chaining them to demonstrate how far an attacker can go — is the highest-value activity in a penetration test. It reveals the real-world impact that no scanner can assess, produces findings that drive immediate remediation, and answers the question the board is actually asking: how bad can this get?
The answer, more often than organisations expect, is: very bad indeed. But the escalation chain also provides the roadmap for fixing it — because every chain has a weakest link, and breaking one link is enough to prevent the attacker from reaching the end.
Our penetration tests don't stop at identifying vulnerabilities — we escalate, chain, and demonstrate the real-world impact of every finding, giving you the evidence to prioritise remediation where it matters most.