Windows Privilege Escalation: Vectors and Hardening for Defenders

Windows privilege escalation is one of the most consequential phases of a real intrusion, and yet it is also one of the most defensible. This article is written for blue teams, detection engineers, and system administrators who need to understand the mechanics in order to defend against them. We will describe, at a conceptual level, how an attacker who already has a low-privilege foothold tries to become SYSTEM or a domain administrator, which telemetry reveals those attempts, and how to harden a Windows estate so that the most common vectors simply do not exist. There are no ready-to-run payloads here: the goal is durable detection and mitigation, not a playbook for compromise.

What privilege escalation actually means

Privilege escalation is the transition from one security context to a more powerful one on the same host or in the same domain. Defenders usually split it into two families. Vertical escalation moves from a low-integrity or standard user to a high-privilege account such as NT AUTHORITY\SYSTEM, a local administrator, or a Domain Admin. Horizontal escalation moves sideways to another user of similar privilege in order to reach data or trust that the original account lacked. Escalation almost never happens in isolation: it sits between initial access and lateral movement in the attack lifecycle, and it is frequently the step where a nuisance infection becomes a full compromise. Because of that, detecting escalation attempts is high-value even when they fail, since a failed attempt still reveals a foothold you did not know about.

How Windows enforces privilege in the first place

To defend the boundary you have to know where it is. Windows assigns every process an access token that carries the user's SID, group SIDs, an integrity level (Low, Medium, High, System), and a set of privileges such as SeDebugPrivilege, SeImpersonatePrivilege, and SeBackupPrivilege. User Account Control (UAC) splits an administrator's logon into two tokens, a filtered medium-integrity token for everyday work and a full high-integrity token that only appears after an elevation prompt. Most escalation techniques are, at heart, attempts to obtain a token that the user was never supposed to hold, or to run code inside a process that already holds one. Understanding tokens, integrity levels, and privileges is therefore the shared vocabulary for every detection and every mitigation that follows.

The common vectors and where they live

Escalation vectors cluster into a handful of recurring misconfigurations, and naming them defensively lets you audit for their absence. Service misconfigurations are the classic case: a service that runs as SYSTEM but whose binary, or whose containing folder, is writable by unprivileged users lets an attacker replace what the service executes. Related is the unquoted service path problem, where a path with spaces and no quotes causes Windows to try higher-level executables first. Weak service permissions allow reconfiguring the service's binary path outright. On the installer side, the paired AlwaysInstallElevated policies let any user install packages as SYSTEM. Token abuse exploits accounts that hold impersonation privileges, common on web and database service accounts. DLL search-order hijacking plants a library where a privileged process will load it. Finally, credential theft from memory, the registry, or unattended-install files often lets an attacker skip escalation entirely by reusing an administrator's secret. You do not need attack tooling to find these; a configuration audit finds them first.

Detection: the telemetry that exposes escalation

Escalation is noisy if you are listening on the right channels. Enable and forward the Windows Security log together with Sysmon and your EDR, and center detection on a few durable signals. Event ID 4672 ("Special privileges assigned to new logon") fires when a session receives sensitive privileges such as SeDebugPrivilege; correlate it with the account and the parent process. Event 4673 and 4674 record privileged service and object operations. Service-based escalation surfaces through 7045 (a new service was installed) and 4697, plus Sysmon Event ID 1 (process creation) showing an unexpected parent-child chain such as services.exe spawning cmd.exe or a script host. Token manipulation and injection appear as Sysmon Event ID 8 (CreateRemoteThread) and 10 (ProcessAccess) targeting lsass.exe with suspicious access masks. Registry-based vectors like AlwaysInstallElevated show up as Sysmon Event ID 13 writes to the relevant keys. The strongest detections combine these: a medium-integrity process suddenly spawning a high-integrity child, a service binary modified minutes before the service restarts, or a non-interactive service account acquiring impersonation and then launching a shell.

Building detections that survive real environments

Raw event IDs generate noise, so shape them into behavior-based rules. Alert on integrity-level transitions: a process tree where a Medium-integrity parent produces a High or System child without a legitimate UAC consent event is worth investigating. Baseline your legitimate services and alert when 7045 installs a service with a binary path in C:\Users, C:\Windows\Temp, or another user-writable location. Watch for the pairing of SeImpersonatePrivilege-holding accounts spawning interactive shells. Map each rule to MITRE ATT&CK techniques under the Privilege Escalation tactic (TA0004) so coverage gaps are visible, and validate the rules with an authorized purple-team exercise rather than assuming they fire. Feed the alerts into a triage workflow that captures the token, the parent chain, and the modified artifact, because those three facts usually reconstruct the whole technique.

Mitigation and hardening that removes the vectors

The best escalation detection is a vector that no longer exists. Enforce least privilege: standard users should never be local administrators, and service accounts should be Group Managed Service Accounts scoped to exactly what they need. Audit and correct file and folder ACLs on every service binary path so that non-administrators cannot write to them, and resolve every unquoted service path. Set both AlwaysInstallElevated values to disabled through Group Policy. Remove sensitive privileges such as SeImpersonatePrivilege from accounts that do not require them, and where modern Windows supports it, isolate credentials with Credential Guard and enable LSA protection (RunAsPPL) to blunt memory theft. Keep systems patched, since many escalation exploits target known local vulnerabilities. Deploy application control (WDAC or AppLocker) so that a planted binary cannot execute even if an ACL slips. Finally, apply attack-surface-reduction rules and monitor for driver-loading abuse, because signed-but-vulnerable drivers are an increasingly common escalation bridge.

Pitfalls that weaken an otherwise good program

Several recurring mistakes hollow out an escalation defense. The first is logging without forwarding: the events exist on the endpoint but never reach the SIEM, so the attacker who wipes the local log erases the only evidence. The second is alert fatigue from raw 4672 events, which fire for legitimate administrators constantly; without baselining, analysts learn to ignore the one that matters. A third is over-trusting UAC as a security boundary — Microsoft itself does not treat default UAC as one, so an environment that relies on the consent prompt alone is exposed. Fourth is stale service ACLs introduced by third-party installers long after the initial hardening pass, which is why auditing must be continuous, not one-time. Finally, teams often forget scheduled tasks and startup folders, which offer the same writable-artifact-runs-as-privileged-user pattern as services and deserve the same scrutiny.

A practical hardening and detection checklist

Use this as a recurring audit rather than a single project. 1) Confirm no standard user is a local administrator and inventory who is. 2) Enumerate service binary paths and verify none are writable by non-administrators. 3) Resolve every unquoted service path. 4) Verify both AlwaysInstallElevated registry values are disabled. 5) Review which accounts hold SeImpersonatePrivilege, SeDebugPrivilege, and SeBackupPrivilege, and strip the unneeded. 6) Enable Credential Guard and LSA protection where supported. 7) Deploy WDAC or AppLocker in enforce mode. 8) Ship Security, Sysmon, and EDR logs to the SIEM and confirm ingestion. 9) Alert on integrity-level jumps, suspicious 7045 paths, and lsass.exe access. 10) Validate the whole chain with an authorized purple-team test each quarter.

Frequently asked questions

Is disabling UAC ever acceptable to reduce prompts? No. Even though Microsoft does not classify default UAC as a formal security boundary, it still raises the cost of many escalation techniques and provides the consent event that several detections depend on. Reduce prompts through proper application packaging and least privilege, never by turning UAC off.

Do we still need host detections if we have a strong EDR? Yes. EDR is powerful but not omniscient, and layering Sysmon plus forwarded Security logs gives you an independent evidence source that survives an attacker who tampers with the agent. Defense in depth applies to your own visibility, not just to the attacker's path.

Conclusion

Windows privilege escalation looks intimidating because it has many named techniques, but from the defender's chair it collapses into a small set of preventable misconfigurations and a small set of high-value signals. Remove writable service binaries, unquoted paths, needless privileges, and the AlwaysInstallElevated policy, and you eliminate most of the estate's exposure outright. Forward the Security log with Sysmon and your EDR, alert on integrity-level transitions and suspicious service installs, and validate the coverage with authorized testing, and you will see the attempts that remain. Understanding the offense is only useful here insofar as it makes the defense concrete — and on Windows, the defense is well within reach.