Windows Privilege Escalation Techniques Guide: Detecting and Preventing Escalation on Windows

Almost every serious Windows intrusion needs a step from an ordinary user context to Administrator or SYSTEM, and that step is where defenders have their best chance to stop it. This guide is written for defenders and for authorised testers working under a signed scope; it describes techniques only at the level of the MITRE ATT&CK descriptions and contains no commands, exploit code or step-by-step procedures. It covers the main families of Windows privilege escalation in ATT&CK v20 (tactic TA0004), the telemetry that reveals each one, the hardening that removes the underlying weakness, and how to respond when escalation is detected. It is for endpoint engineers, SOC analysts, detection engineers and the people who scope and review penetration tests.

Key takeaways

• Escalation exploits configuration more often than code. Weak service permissions, writable paths, standing local admin rights and over-privileged service accounts are more common routes than kernel exploits, and they are fixable without waiting for a patch.
• Local admin is the real boundary. Microsoft describes User Account Control as reducing risk rather than as a hard barrier, so a user with admin group membership should be treated as already privileged.
• Kernel and driver exploits are a patching and driver-control problem. CISA's KEV catalogue lists several Windows elevation flaws used in ransomware, and the vulnerable driver blocklist plus HVCI closes the "bring your own vulnerable driver" route.
• The telemetry already exists. Events 4672, 4688, 4697, 4732 and 7045, plus EDR process lineage, cover most escalation families if they are collected and baselined.
• Service accounts are escalation targets. Services running as SYSTEM or a domain account, and tokens with SeImpersonatePrivilege, turn a foothold in an application into full control of the host.

How Windows privilege works and where it breaks

Windows authorises actions through access tokens. A token carries the user's SIDs, group memberships, privileges (such as SeDebugPrivilege or SeImpersonatePrivilege) and an integrity level. Microsoft's UAC documentation explains that an administrator signing in receives two tokens: a filtered standard user token used to start Explorer and the user's applications, and a full administrator token used only after elevation is approved. Lower integrity processes cannot modify higher integrity ones.

Privilege escalation means obtaining a token, or code execution under a token, with more rights than the attacker started with. On a Windows host the usual targets are, in rising order: a member of the local Administrators group running at high integrity, a service account with powerful privileges, and NT AUTHORITY\SYSTEM. From SYSTEM an attacker can read the SAM and LSASS memory, which often turns one host into domain-wide credential theft. That is why escalation is both an endpoint problem and an identity problem.

• Boundary that holds: standard user to administrator, provided the user has no admin rights, software is current and services are correctly permissioned.
• Boundary that is weak: admin in Admin Approval Mode to fully elevated admin. UAC prompts reduce accidental elevation but are not a substitute for removing admin rights.
• Boundary that matters most: administrator or service to kernel. Driver signing, HVCI and the vulnerable driver blocklist exist to protect it.

For background on tokens, integrity levels and the service control manager, see the Windows Internals for Defenders Guide.

Technique families mapped to ATT&CK v20

The table groups the Windows techniques under TA0004 Privilege Escalation by the weakness they rely on. Descriptions follow the ATT&CK technique pages; the detection and prevention columns are summarised from the sections that follow.

Note that in ATT&CK v20 the T1574 Hijack Execution Flow sub-techniques sit under the Stealth and Execution tactics rather than TA0004, but they remain a common path to SYSTEM on badly permissioned hosts, so they are included here. Always check the tactic mapping in the current ATT&CK release before writing detection content against it.

Exploitation of vulnerabilities and drivers

T1068 covers adversaries exploiting software vulnerabilities to elevate privileges, including through vulnerable signed drivers loaded into the kernel. The CISA Known Exploited Vulnerabilities catalogue is the best public signal of which Windows elevation flaws are used in the wild. Examples in the catalogue include CVE-2021-36934 (Windows SAM local privilege escalation, sometimes called HiveNightmare), CVE-2021-34527 (Print Spooler, PrintNightmare, marked as known ransomware use), CVE-2023-28252 (Common Log File System driver) and CVE-2024-21338 (Windows kernel exposed IOCTL).

• Prioritise by exploitation, not score: treat any KEV-listed local elevation flaw on Windows as an emergency change, even if its CVSS base score is lower than a remote flaw. See the Patch Tuesday Guide and the Risk-Based Vulnerability Management Guide.
• Remove the attack surface: disable services that are not needed on the role. The Print Spooler is the standard example: domain controllers and most servers do not need it.
• Control drivers: Microsoft's vulnerable driver blocklist targets third-party drivers with known vulnerabilities that can be used to elevate privileges in the kernel. It is on by default on Windows 11 2022 update and later, and is enforced when HVCI (memory integrity), Smart App Control or S mode is active. Microsoft updates it quarterly and through monthly servicing, and recommends deploying the latest list through App Control for Business after testing in audit mode.
• Turn on memory integrity: HVCI moves kernel code integrity checks into a virtualisation-protected environment and is on by default for most new Windows 11 devices. Test older hardware and drivers before enforcing it on existing fleets.

Misconfiguration paths: services, paths, tasks and installers

The configuration families are where authorised penetration tests most often find escalation, and where defenders can make the most permanent progress. Each one is a case of a privileged process trusting something a lower privileged user can change.

• Service permissions: if a standard user can change a service's configuration or replace its binary, the service becomes a way to run code as its run-as account. Audit service DACLs and the ACLs on service binaries and their folders, and alert on changes to the ImagePath value under HKLM\SYSTEM\CurrentControlSet\Services.
• Unquoted and writable paths: a service path with spaces and no quotes, or a privileged process that loads DLLs from a user-writable folder, lets a planted file run with higher rights. Fix by quoting paths, keeping software under Program Files with default ACLs, and removing user write access from folders added to the system PATH.
• Scheduled tasks: tasks that run as SYSTEM but call scripts in writable locations are a quiet escalation path. Inventory task principals and the ACLs on the files they execute.
• Installer policies: the Group Policy setting "Always install with elevated privileges" (AlwaysInstallElevated) makes Windows Installer packages run with system rights for any user. It should be disabled in both computer and user configuration unless there is a documented exception.
• Stored credentials: unattended installation files, scripts, Group Policy Preferences passwords and saved credentials are T1552 Unsecured Credentials territory rather than TA0004, but they frequently hand an attacker an admin password. Search for and remove them.

Hardening baselines cover most of these settings. See the Windows Endpoint Hardening Guide and the Windows Server Hardening Guide.

Where identity fits: local admin, service accounts and tokens

Privilege escalation on Windows is largely an identity problem. The token is the identity, and the accounts that hold powerful tokens are usually non-human: services, scheduled tasks, IIS application pools, SQL Server and backup agents.

• Standing local admin: users who are permanent members of the local Administrators group have nothing left to escalate to except SYSTEM, which UAC does not robustly protect. Move to standard user accounts plus elevation on demand. See the Endpoint Privilege Management Guide.
• Shared local admin passwords: the same built-in Administrator password across hosts turns one escalation into lateral movement (T1078.003). Windows LAPS rotates a unique password per device. See the LAPS Guide.
• Service account privileges: SeImpersonatePrivilege and SeAssignPrimaryTokenPrivilege are granted to service identities by design, which is why compromise of a web application or database often leads to SYSTEM through token abuse (T1134). Run services as virtual accounts or group managed service accounts with only the rights they need. See the gMSA Guide and the Service Account Security Guide.
• Domain admins on workstations: any domain admin logon to an ordinary workstation leaves credentials that a local escalation can harvest. Enforce tiered administration and privileged access workstations.

Detection: telemetry and analytics

Detection should focus on the transitions that escalation produces: a process gaining a higher integrity level or a different user than its parent, a privileged process starting from an unusual location, and changes to the objects privileged processes trust. The table lists the core Windows sources.

Conceptual analytics that work across products:

1. Integrity jump without consent: a high integrity process whose parent ran at medium integrity, with no corresponding consent or credential prompt, is a strong UAC bypass signal.
2. Service to shell: a command interpreter or scripting host whose parent is a service host, web server worker or database process, running as SYSTEM.
3. New privileged persistence: service, task or driver creation on a server outside a change window, correlated by Logon ID with the creating account's 4624 logon.
4. Privileged group change: any change to local Administrators on servers, or to Domain Admins, raised as high severity.
5. Driver anomalies: a driver loaded that is rare across the fleet, especially shortly after a user logon.

Event details and collection are covered in the Windows Event Log Guide and the Endpoint Telemetry Guide. D3FEND techniques that apply include D3-PSA Process Spawn Analysis, D3-LAM Local Account Monitoring and D3-SJA Scheduled Job Analysis.

Prevention and hardening by control area

Rollout order:

1. Measure first: inventory local admin membership, services running as SYSTEM or domain accounts, unquoted service paths, writable service binaries and the AlwaysInstallElevated setting across the fleet.
2. Quick wins: deploy Windows LAPS, disable AlwaysInstallElevated, disable Print Spooler where not needed, and patch every KEV-listed elevation flaw.
3. Pilot ring: remove local admin from an IT pilot group, provide elevation on request, and run App Control and the driver blocklist in audit mode. Collect the audit events for two to four weeks.
4. Broad rollout: expand by ring, converting audit policies to enforce once false positives are resolved. Keep a documented break-glass process for elevation.
5. Rollback: keep the previous policy version for App Control and HVCI in your management tool so a ring can revert within one change; for admin removal, a time-bound group membership restores access while the issue is fixed.
6. Verify: ask an authorised tester or purple team to exercise each family against the hardened baseline. See the Purple Teaming Guide.

Small versus large organisations: a small business on Microsoft 365 Business Premium can get most of the value from LAPS, standard user accounts, Defender attack surface reduction rules and default HVCI. Large estates with legacy line-of-business software usually need endpoint privilege management to broker elevation per application, and a longer audit phase for application control.

Response when escalation is detected

• Contain the host: isolate through EDR before the attacker uses SYSTEM access to dump credentials or move laterally.
• Assume credential exposure: any account that had an interactive or service logon on the host since the escalation should be treated as exposed. Reset local admin passwords through LAPS and rotate service account secrets.
• Preserve evidence: collect memory, the Security, System and Sysmon logs, service and task configuration, and new files in service folders before reimaging. See the Windows Forensic Artefacts Guide.
• Find the root cause: map the escalation to its ATT&CK family and fix the class of weakness fleet-wide, not just on the one host.
• Feed detection: turn the confirmed path into a tested analytic and add it to the purple team backlog.

Common failure patterns

• Treating UAC as the control: organisations leave users in the local Administrators group and rely on prompts. Users approve prompts, and UAC bypass techniques do not need approval.
• Collecting 4688 without command lines or lineage: process creation without parent, integrity level and command line cannot distinguish escalation from normal admin work.
• Patching by CVSS alone: local elevation flaws score lower than remote ones and slip down the queue, even when CISA lists them as exploited by ransomware groups.
• Over-privileged service accounts: domain accounts with admin rights everywhere, used to run a single service, turn one compromised application server into domain compromise.
• Driver blocklist disabled for compatibility: HVCI or the blocklist is switched off for one device driver and never revisited.
• Findings fixed per host: a penetration test reports an unquoted service path on one server and only that server is fixed, while the same software image is deployed across hundreds.

Framework mapping

Measuring progress

• Standing admin rate: percentage of users with permanent local admin rights, trending towards zero outside documented exceptions.
• LAPS coverage: percentage of Windows devices with a LAPS-managed local admin password rotated within policy.
• KEV elevation patch time: median days to remediate KEV-listed Windows elevation flaws.
• Driver protection coverage: percentage of devices with HVCI and the vulnerable driver blocklist enforced.
• Misconfiguration count: unquoted service paths, writable service binaries and AlwaysInstallElevated settings found per scan.
• Detection coverage: share of the technique families in this guide with a tested analytic, validated by the last purple team exercise.

Practitioner checklist

• Remove permanent local admin rights and provide audited elevation on request.
• Deploy Windows LAPS to every workstation and member server.
• Patch KEV-listed Windows elevation flaws on an emergency timeline.
• Enforce HVCI and the vulnerable driver blocklist after an audit period.
• Audit service DACLs, service binary ACLs, unquoted paths and scheduled task principals on every image.
• Disable AlwaysInstallElevated and remove stored credentials from scripts and unattend files.
• Enable 4688 with command lines, 4672, 4697, 4698 and group change auditing, and forward them centrally.
• Run services under virtual accounts or gMSAs with only the privileges they need.
• Validate each technique family with an authorised purple team exercise under a written scope.

Standards and references

• MITRE ATT&CK: Privilege Escalation (TA0004)
• MITRE ATT&CK: Exploitation for Privilege Escalation (T1068)
• MITRE ATT&CK: Bypass User Account Control (T1548.002)
• Microsoft Learn: How User Account Control works
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: 4672(S) Special privileges assigned to new logon
• Microsoft Learn: 4697(S) A service was installed in the system
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Linux Privilege Escalation Techniques Guide · Penetration Testing Guide · Red Teaming Guide · Penetration Test Scoping Checklist · Privileged Access Management Guide