Windows Privilege
Escalation

Access Tokens & the Privilege Hierarchy

Every process in Windows runs in the context of an access token — a kernel object that encapsulates the security identity of the thread or process. When a user logs in, the Local Security Authority Subsystem Service (LSASS) builds a token containing the user's SID, group SIDs, and privilege set. This token is then inherited by every process spawned in that session.

The privilege hierarchy flows from SYSTEM at the top, through high-integrity administrative processes, down to medium-integrity standard user processes, and finally to low-integrity sandboxed contexts like browser tabs and downloaded executables. Your job as a privilege escalation practitioner is to find the paths that allow movement between these levels.

• ▸Primary vs. impersonation tokens

  A primary token is assigned to a process at creation and represents its full security context. An impersonation token is a temporary token a thread adopts to act on behalf of another user — commonly used by services and RPC servers.

  From an attacker's perspective: if you can steal or duplicate an impersonation token with SecurityImpersonation or SecurityDelegation level, you can call ImpersonateLoggedOnUser() or SetThreadToken() to run code as that user.

  💡 Use GetTokenInformation(TokenType) to distinguish primary (1) vs impersonation (2) tokens at runtime.
• ▸Token privileges and their implications

  Privileges are per-token rights that gate specific system operations. They exist in three states: present, enabled, or enabled by default. Many dangerous privileges are present but disabled at medium integrity — elevation or bypass is needed to use them.

  • SeImpersonatePrivilege — impersonate any authenticated user (potato attacks)
  • SeDebugPrivilege — open any process including LSASS
  • SeAssignPrimaryTokenPrivilege — assign a primary token to a new process
  • SeTakeOwnershipPrivilege — take ownership of any object
  • SeLoadDriverPrivilege — load arbitrary kernel drivers

  ⚠ Even 'disabled' dangerous privileges can be re-enabled with AdjustTokenPrivileges() if the privilege is present in the token.
• ▸Session isolation and token inheritance

  Each interactive logon creates a unique session. Processes spawned within a session inherit the parent's token by default. Session 0 is reserved for services and runs in strict isolation from interactive user sessions since Windows Vista.

  Token inheritance matters for privilege escalation because spawning a child process with CreateProcess() clones the parent token. If you can inject into or manipulate a parent process before it spawns children, you may influence the inherited token.

  💡 CreateProcessWithTokenW() and CreateProcessAsUserW() allow explicitly specifying a different token for the new process — core to most token-based privesc techniques.
• ▸How restricted tokens work

  Restricted tokens are created via CreateRestrictedToken() and are a subset of a normal token — privileges and SIDs can only be removed, never added. They're used by sandboxes (Chrome, IE protected mode, AppContainers) to limit what a compromised process can do.

  As a pentester, restricted tokens are relevant when you're trying to escape a sandboxed context. The key insight: a restricted token cannot access objects that its restricting SIDs don't have access to, even if the base token would allow it.

  • Restricting SIDs add an extra DENY layer on top of normal access checks
  • SANDBOX_INERT flag — disables AppLocker and Software Restriction Policies in the child

How Windows Makes Authorization Decisions

When a process attempts to access a securable object — a file, registry key, process, thread, or named pipe — the Security Reference Monitor (SRM) performs an access check. It compares the SIDs in the calling thread's token against the Discretionary Access Control List (DACL) on the target object. Each ACE in the DACL either grants or denies specific access rights to a particular SID.

Understanding this flow is essential because most privilege escalation techniques are fundamentally about either modifying a DACL, impersonating a higher-privileged token, or placing attacker-controlled content somewhere that a higher-privileged process will execute it.

Mandatory Integrity Control (MIC)

Introduced in Windows Vista, MIC adds an additional layer on top of DACL-based access control. Every securable object and every process is assigned an integrity level — System, High, Medium, Low, or Untrusted. The No-Write-Up policy prevents a lower integrity process from writing to a higher integrity object, even if the DACL would otherwise permit it.

This is the primary mechanism that UAC bypass techniques are designed to circumvent. When you understand why MIC exists, the attack surface becomes obvious: the system must have auto-elevation pathways for legitimate use cases, and those pathways are the target.

SIDs, DACLs, and ACEs — The Building Blocks

A Security Identifier (SID) is a unique value that identifies a user, group, or computer account. Well-known SIDs like S-1-5-18 (SYSTEM) and S-1-5-32-544 (Administrators) appear constantly during enumeration and are worth memorizing. Every DACL is composed of Access Control Entries (ACEs), each specifying a SID and an access mask.

• ▸Well-known SIDs reference table

  Security Identifiers (SIDs) appear constantly during enumeration. Memorizing the most common well-known SIDs saves time and prevents misidentification during a live engagement.

  • S-1-5-18 — NT AUTHORITY\SYSTEM (local system account)
  • S-1-5-19 — NT AUTHORITY\LOCAL SERVICE
  • S-1-5-20 — NT AUTHORITY\NETWORK SERVICE
  • S-1-5-32-544 — BUILTIN\Administrators
  • S-1-5-32-545 — BUILTIN\Users
  • S-1-16-8192 — Medium Integrity Level
  • S-1-16-12288 — High Integrity Level
  • S-1-16-16384 — System Integrity Level
• ▸Reading ACEs with icacls and PowerShell

  icacls is the command-line tool for reading and modifying DACLs on files and directories. For registry keys, use Get-Acl in PowerShell or reg with appropriate flags.

  Key icacls permission flags to recognize during enumeration:

  • (F) — Full control (attacker can replace the binary)
  • (W) — Write (can modify content or append)
  • (M) — Modify (write + delete, often enough)
  • (RX) — Read & execute only (not exploitable via write)

  💡 PowerShell: (Get-Acl 'HKLM:\SYSTEM\CurrentControlSet\Services\vuln').Access — check IdentityReference and FileSystemRights on each ACE.
• ▸Identifying misconfigured DACLs during enumeration

  Misconfigured DACLs are one of the most reliable escalation vectors in mature environments where patch levels are high. The key is finding objects that privileged processes interact with but that non-admin users can write to.

  Priority targets during DACL enumeration:

  • Service binary paths — can we overwrite the executable?
  • Service image path registry keys — can we change where the service binary points?
  • DLL directories in the service binary's path — can we plant a DLL?
  • Scheduled task action executables — same logic as services

  💡 Tool: accesschk.exe -uwcqv "Authenticated Users" * — Sysinternals AccessChk finds services writable by the current user.
• ▸SACL vs DACL — audit vs authorization

  The DACL (Discretionary ACL) controls who can access an object — it's the authorization layer. The SACL (System ACL) controls what access attempts get logged to the Security event log — it's the audit layer. SACLs require SeSecurityPrivilege to read or write.

  Operational significance: a target object might have a SACL that logs all access attempts. Modifying a service registry key or replacing a DLL without checking the SACL first can generate detectable audit events even if the DACL allows the write.

  ⚠ During an authorized engagement, always check whether sensitive registry keys and directories have SACLs before touching them. Unnecessary audit events complicate report writing and may trigger SOC alerts.

Enumeration Methodology

Effective privilege escalation starts with disciplined enumeration before any exploitation attempt. Rushing to a known technique without understanding the target environment leads to noise, failed attempts, and missed vectors. The goal of the enumeration phase is to build a complete picture of the attack surface and identify the highest-confidence path to escalation.

Enumeration falls into three categories: system configuration (OS version, patches, installed software), permission misconfigurations (services, files, registry), and credential exposure (cached credentials, configuration files, browser stores).

Service Misconfigurations

Windows services running as SYSTEM or a privileged account are prime escalation targets when their configuration is improperly secured. Three categories of service misconfigurations matter most: weak binary permissions (attacker can overwrite the executable), weak service permissions (attacker can modify the service config to point to a different binary), and unquoted service paths (attacker can plant an executable at a path that Windows will resolve first).

• ▸Unquoted service path exploitation

  When a Windows service's binary path contains spaces and is not enclosed in quotes, Windows resolves it using an ambiguous path traversal. For a path like C:\Program Files\My App\service.exe, Windows tries these in order:

  • C:\Program.exe
  • C:\Program Files\My.exe
  • C:\Program Files\My App\service.exe

  If an attacker can write to C:\Program Files\, they can plant My.exe and have it run as the service account (often SYSTEM) on next service start or system reboot.

  💡 Find candidates: wmic service get name,pathname,startmode | findstr /i auto | findstr /iv "\"" — no quotes = potential target.
• ▸Weak service DACL — sc sdshow analysis

  The service's DACL (accessible via sc sdshow <servicename>) controls who can modify the service configuration. If non-admin users have SERVICE_CHANGE_CONFIG or SERVICE_ALL_ACCESS, they can point the service binary at an attacker-controlled executable.

  SDDL string to look for in sc sdshow output: (A;;RPWP;;;WD) — this grants RP (start) and WP (write properties) to World (everyone). Any non-trivial write right to a privileged service is exploitable.

  💡 Change config: sc config <svc> binpath= "C:\\temp\\shell.exe" then sc start <svc>.
• ▸Binary path hijacking via icacls

  Even if the service DACL is locked down, if the service binary itself or its parent directory has weak permissions, the file can be overwritten directly. The service then executes the attacker's binary on next start.

  Check the binary: icacls "C:\path\to\service.exe" — look for (M), (W), or (F) for BUILTIN\Users or NT AUTHORITY\Authenticated Users.

  ⚠ Always back up the original binary before overwriting on authorized engagements. The service will be broken until restored.
• ▸AlwaysInstallElevated registry abuse

  When both HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated and the corresponding HKCU key are set to 1, any user can install MSI packages with SYSTEM privileges.

  Exploitation is trivial: generate a malicious MSI with msfvenom -p windows/exec CMD=cmd.exe -f msi > evil.msi and run it with msiexec /quiet /qn /i evil.msi. The installer runs as SYSTEM.

  💡 This is one of the first checks any automated tool runs — it's rare in modern environments but appears in legacy enterprise builds and dev machines.
• ▸Scheduled task permission abuse

  Scheduled tasks run under a configured user context. If the action executable or its directory is writable by the current user, replacing it achieves execution under the task's configured account (often SYSTEM or a privileged service account).

  Enumerate tasks: schtasks /query /fo LIST /v | findstr /i "task name\|run as user\|task to run". Then check the binary path permissions with icacls.

  💡 Also check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks for registry-based task definitions that may expose the action path directly.
• ▸Startup folder and autorun inspection

  Programs placed in startup folders or registered as autoruns execute under the logged-on user's context — useful for persistence but typically not direct privilege escalation unless the startup location itself is writable and a higher-privileged user logs in.

  Key autorun locations:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  • HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  • C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
  • C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Credential Hunting

Credentials stored or cached on the local system represent some of the highest-value findings during a privilege escalation assessment. Windows provides several locations where credentials accumulate: the SAM hive (local account hashes), DPAPI-protected credential blobs, Windows Credential Manager entries, and configuration files left by administrators or developers.

• ▸SAM and SYSTEM hive extraction methodology

  The SAM hive stores local account NTLM password hashes. It's encrypted using a key derived from the SYSTEM hive. Both are locked by the OS while running, but can be extracted using Volume Shadow Copies or registry export with SYSTEM privileges.

  With SYSTEM access: reg save HKLM\SAM sam.bak and reg save HKLM\SYSTEM system.bak. Then use secretsdump.py or mimikatz offline to extract the hashes.

  ⚠ VSS-based extraction: vssadmin create shadow /for=C: then copy the hive from the shadow copy path — bypasses the file lock without needing direct SAM access.
• ▸DPAPI master key location and decryption flow

  DPAPI (Data Protection API) encrypts secrets on behalf of users and processes. The encryption key chain flows: secret → DPAPI blob → master key → user password (or domain backup key). Master keys live in %APPDATA%\Microsoft\Protect\{SID}\.

  DPAPI blobs are used by: Chrome/Edge saved passwords, Windows Credential Manager, RDP credentials, WiFi passwords, and certificate private keys. If you have the user's password or SYSTEM access, you can decrypt all of them.

  💡 mimikatz: dpapi::masterkey /in:<path> /password:<user_pass> then dpapi::cred /in:<blob> /masterkey:<hex>
• ▸Credential Manager — cmdkey enumeration

  Windows Credential Manager stores saved credentials for network shares, RDP sessions, and web logins. Enumerate with cmdkey /list — this shows what's stored but not the plaintext. If you have SYSTEM or the user's context, you can extract them.

  Types of stored credentials:

  • Windows credentials — domain/server credentials (NTLM hashes extractable)
  • Certificate-based credentials — PKI auth materials
  • Generic credentials — application-specific (often plaintext-recoverable via DPAPI)

  💡 RunAs with saved credentials: runas /savecred /user:DOMAIN\admin cmd.exe — if an admin has saved credentials, a lower-priv user may be able to use them.
• ▸PowerShell history, .rdp files, unattend.xml

  These files are low-hanging fruit that appear frequently in real engagements — especially in environments where admins work interactively on servers.

  • PSReadLine history: %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt — admins frequently type credentials directly into PS commands
  • .rdp files: May contain saved usernames; passwords are DPAPI-encrypted but recoverable
  • unattend.xml / sysprep.xml: Deployment config files that sometimes contain plaintext or base64-encoded local admin passwords
  • web.config / app.config: Application configs with database connection strings

  ⚠ Always grep recursively: findstr /si password *.xml *.txt *.config *.ini — catches custom credential storage patterns.

Token Impersonation Fundamentals

Token impersonation allows a process or thread to temporarily adopt the security context of another user. Windows provides this mechanism for legitimate use cases — a server process needs to act on behalf of a client, for example. The impersonation level determines how far the impersonation can propagate: Identification allows inspection but no resource access, Impersonation allows local resource access, and Delegation allows resource access across the network.

From an attacker's perspective, the goal is to obtain a SYSTEM-level impersonation token and use it to either spawn a new process or perform privileged actions directly. The SeImpersonatePrivilege right is the critical enabler — if a process holds it, token impersonation attacks become viable.

SeImpersonatePrivilege and Potato-Family Attacks

Service accounts (IIS AppPool, mssql, network service) typically hold SeImpersonatePrivilege by design. Potato-family attacks exploit the way Windows authenticates COM activation requests — by coercing the SYSTEM account to authenticate to an attacker-controlled endpoint and capturing its token in the process. JuicyPotato, RoguePotato, and GodPotato represent successive iterations of this technique as Microsoft patched each variant.

• ▸How COM activation coercion works

  COM activation goes through the COM Service Control Manager (RPCSS). When a client requests a COM object via CoCreateInstance(), RPCSS authenticates the request using NTLM. Potato attacks force SYSTEM to authenticate to an attacker-controlled endpoint in this flow, capturing a SYSTEM-level token in the process.

  The coercion works because certain COM activations are triggered as SYSTEM internally — the attacker doesn't need to coerce a user, they set up a fake endpoint and wait for the OS to connect to it as part of normal COM infrastructure operation.

• ▸CLSID selection for JuicyPotato variants

  JuicyPotato requires a CLSID that can be activated from the target service account's context. Not all CLSIDs work on all OS versions. The original JuicyPotato GitHub lists hundreds of tested CLSIDs by OS version.

  If a CLSID fails, rotate through alternatives for the target OS. Common reliable ones for Windows Server 2019: {F7FD3FD6-9994-452D-8DA7-9A8FD87AEEF4}. For Windows 10 1903+, use RoguePotato or GodPotato instead.

  ⚠ JuicyPotato does not work on Windows 10 1809+ or Server 2019+ due to DCOM authentication hardening. Use RoguePotato or GodPotato for modern targets.
• ▸RoguePotato — bypassing the JuicyPotato patch

  RoguePotato adapts the potato technique to work post-JuicyPotato patch by using a fake OXID resolver (a component in the DCOM infrastructure) rather than directly abusing RPCSS. It spins up a local fake OXID resolver on a configurable port and redirects DCOM activation through it.

  Usage requires a redirector on the attacking machine (or port forwarding) to relay traffic from port 135 to the fake OXID port on the target. Works on Windows Server 2019 and Windows 10 20H2.

  💡 RoguePotato is more infrastructure-intensive than GodPotato. Prefer GodPotato on modern targets unless you have specific reasons to use Rogue.
• ▸GodPotato — Windows 10/11 and Server 2019/2022

  GodPotato is the current state-of-the-art potato variant, working against Windows Server 2012-2022 and Windows 8-11. It abuses the ImpersonateNamedPipeClient() flow via a new COM activation coercion path that wasn't patched with previous potato mitigations.

  It requires SeImpersonatePrivilege (standard for IIS, MSSQL, WCF service accounts) and produces a SYSTEM-level token reliably without external infrastructure.

  💡 Basic usage: GodPotato.exe -cmd "cmd /c whoami > C:\\temp\\proof.txt". EDR detection is high — obfuscate or use the technique manually via the documented API calls for stealth.
• ▸PrintSpoofer as an alternative impersonation path

  PrintSpoofer abuses the Windows Print Spooler service to coerce SYSTEM authentication to a named pipe the attacker controls, then calls ImpersonateNamedPipeClient() to capture the SYSTEM token. It does not use COM/DCOM and therefore evades some potato-specific signatures.

  Works on: Windows 10 (all versions), Server 2016/2019. Requires SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege.

  ⚠ PrintSpoofer may not work if the Print Spooler service is disabled — increasingly common in hardened environments since PrintNightmare. Verify: sc query spooler.
• ▸Identifying which potato applies to target OS version

  Quick reference for technique selection based on target OS:

  • Server 2008 / Win 7: RottenPotato or JuicyPotato
  • Server 2012 R2 / Win 8.1: JuicyPotato (most CLSIDs work)
  • Server 2016 / Win 10 pre-1809: JuicyPotato or PrintSpoofer
  • Server 2019 / Win 10 1809+: RoguePotato, GodPotato, or PrintSpoofer
  • Server 2022 / Win 11: GodPotato (most reliable)

  💡 Always check winver or systeminfo | findstr /B /C:"OS Name" /C:"OS Version" first.

Named Pipe Impersonation

Named pipe impersonation is a lower-noise alternative to potato attacks when the environment is heavily monitored. An attacker creates a named pipe server and convinces a higher-privileged process to connect as a client. Once connected, the server calls ImpersonateNamedPipeClient() to assume the client's security context. This technique is particularly effective when you have code execution in a service account context and can trigger a privileged process to touch your pipe.

What UAC Actually Does (and Doesn't)

User Account Control is a consent and credential prompting mechanism — it is not a security boundary in the same sense as a kernel exploit mitigation. Microsoft's own documentation acknowledges this. UAC's job is to prevent accidental privilege use and to make privilege escalation visible to the user. A determined local attacker with code execution can almost always bypass it.

The attack surface exists because Windows must support auto-elevation for a subset of trusted, Microsoft-signed binaries. These binaries are allowed to elevate without a UAC prompt because they are trusted to know what they're doing. The bypass techniques in this module all involve abusing the context in which those auto-elevating binaries execute.

The Auto-Elevation Mechanism

When a process marked as autoElevate in its manifest runs from a trusted directory (typically System32 or Program Files), Windows elevates it without prompting. The Application Information service (appinfo.dll) is responsible for this decision. It checks the binary's manifest, verifies its signature, confirms the path, and if all checks pass, creates a high-integrity process without user interaction.

The bypass opportunities arise in the gaps: auto-elevating binaries that load COM objects from HKCU (which is writable at medium integrity), binaries that resolve DLLs through a path the attacker controls, and binaries that execute child processes whose command line the attacker can influence via environment variables or registry values.

• ▸autoElevate manifest flag mechanics

  The autoElevate element in an application manifest signals to Windows that the binary should be elevated without a UAC prompt when run by an administrator. This flag is only honored for executables signed by Microsoft and located in trusted directories (System32, Program Files, etc.).

  You can inspect any binary's manifest with: sigcheck.exe -m C:\Windows\System32\fodhelper.exe (Sysinternals) or extract it with mt.exe. Look for <autoElevate>true</autoElevate> in the output.

  💡 All auto-elevating binaries are attack surface. Each one that reads from HKCU or loads DLLs from user-writable paths is a potential bypass.
• ▸appinfo.dll decision flow

  The Application Information service (appinfo.dll, running in svchost.exe) handles UAC elevation requests. Its decision flow for auto-elevation:

  • Is the calling user a local admin? (token contains Administrators SID)
  • Is the executable signed by Microsoft?
  • Is the executable in a trusted directory?
  • Does the manifest declare autoElevate?

  All four must be true. The bypass strategies all attack what happens after the process is spawned at high integrity — specifically, what DLLs it loads and what registry keys it reads in its elevated context.

• ▸Trusted installer vs. auto-elevation

  TrustedInstaller is a separate service account (NT SERVICE\TrustedInstaller) above SYSTEM in the Windows object hierarchy. It owns core system files and registry keys that even SYSTEM cannot modify. Auto-elevation elevates to Administrator level (high integrity), not TrustedInstaller.

  Reaching TrustedInstaller requires token manipulation techniques beyond auto-elevation — typically by enabling SeDebugPrivilege from a SYSTEM context and duplicating the TrustedInstaller service's token.

  ⚠ Most privesc chains stop at SYSTEM. TrustedInstaller is only needed for patching protected system files — rarely required in penetration test scenarios.
• ▸Why path verification matters and where it fails

  appinfo.dll verifies the binary's location is in a trusted directory using a path normalization check. The check can be bypassed by creating a junction or directory structure that makes an untrusted path appear trusted — but this is generally mitigated on modern Windows.

  The more common failure point is what the verified binary does after it's elevated: if it reads HKCU for COM CLSIDs, resolves DLL paths using user-controlled environment variables, or writes to paths the attacker controls, the path verification becomes irrelevant.

  💡 Process Monitor with admin rights shows every registry and file access a binary makes at high integrity. Filter on NAME NOT FOUND + HKCU path to find hijackable reads.

fodhelper UAC Bypass

fodhelper.exe is a Windows binary (Optional Features manager) that auto-elevates and reads from HKCU\Software\Classes\ms-settings\ before executing. Since HKCU is writable at medium integrity, an attacker can plant a shell command in that registry path and have it executed at high integrity when fodhelper reads it. This technique has been in the wild since 2017 and is flagged by most EDR products — its value today is primarily educational for understanding the COM hijack pattern.

COM Object Hijacking for UAC Bypass

The more generalizable pattern is COM object hijacking. Many auto-elevating binaries instantiate COM objects using CoCreateInstance. Windows resolves COM CLSIDs by checking HKCU\Software\Classes\CLSID first, before the machine-wide HKLM. If the attacker registers a malicious COM server under the target CLSID in HKCU, the auto-elevating binary will load the attacker's DLL at high integrity.

• ▸COM activation resolution order (HKCU before HKLM)

  When a process calls CoCreateInstance(CLSID), Windows resolves the CLSID to a server executable or DLL using this lookup order:

  • HKCU\Software\Classes\CLSID\{guid} (user hive — writable at medium integrity)
  • HKCR\CLSID\{guid} (merged view of HKCU + HKLM)
  • HKLM\SOFTWARE\Classes\CLSID\{guid} (machine hive — requires admin)

  Since HKCU is checked first and is writable without elevation, any auto-elevating binary that calls CoCreateInstance() is potentially vulnerable — the elevated process will load the CLSID definition the attacker planted in HKCU.

• ▸Identifying vulnerable CLSIDs via Process Monitor

  The methodology for finding UAC bypass targets with Process Monitor:

  • Run Process Monitor as admin, then trigger the auto-elevating binary
  • Filter: Process Name is fodhelper.exe (or target binary)
  • Filter: Result is NAME NOT FOUND
  • Filter: Path begins with HKCU

  Any HKCU registry key the elevated binary tries to read and doesn't find is a potential hijack point — plant a CLSID registration there and it will be loaded at high integrity.

  💡 Save the ProcMon filter as a .pmc file for reuse across different target binaries.
• ▸InprocServer32 vs LocalServer32 hijacking

  InprocServer32 specifies a DLL to load in-process into the calling process. LocalServer32 specifies an EXE to launch as an out-of-process COM server. For UAC bypass, InprocServer32 is preferred because:

  • The DLL loads into the elevated process's address space directly
  • The payload runs at the elevated process's integrity level
  • No separate process is spawned (lower detection surface)

  Planting a LocalServer32 launches a new process which may not inherit the full elevated context and is more visible in process telemetry.

• ▸CMSTPLUA COM hijack technique

  CMSTPLUA ({3E5FC7F9-9A51-4367-9063-A120244FBEC7}) is a well-known UAC bypass target. The cmstp.exe binary (auto-elevating) instantiates this COM object. By hijacking the CLSID in HKCU, a payload DLL is loaded at high integrity.

  CMSTPLUA is older and heavily signatured by modern EDR. Its value is primarily educational — understanding the pattern lets you apply the same methodology to find novel, unsignatured targets via ProcMon analysis on a target system.

  ⚠ CMSTPLUA bypass is detected by Windows Defender with default signatures. Use only in lab environments or develop novel targets via the ProcMon methodology above.

Detection Signatures

• ▸Event 4688 — Process creation from auto-elevating binary

  Security Event 4688 logs process creation with creator process info when process creation auditing is enabled. A UAC bypass via auto-elevation produces a distinctive chain: medium integrity process → fodhelper.exe → high integrity child process.

  Key fields to correlate: Creator Process Name (should be an expected parent for the auto-elevating binary) and Token Elevation Type (%%1937 = full token / elevated, %%1938 = limited). An elevated child spawned from an unexpected parent is high signal.

  💡 Enable: auditpol /set /subcategory:"Process Creation" /success:enable
• ▸Sysmon Event 13 — HKCU\Software\Classes\CLSID writes

  Sysmon Event ID 13 (RegistryEvent — Value Set) captures registry writes when configured to monitor HKCU paths. A COM hijack for UAC bypass always involves writing to HKCU\Software\Classes\CLSID\{guid}\InprocServer32.

  Detection query (Elastic): registry.path: *\\Software\\Classes\\CLSID\\*\\InprocServer32 AND registry.data.strings: *.dll — correlate with subsequent auto-elevating binary execution within a short time window.

• ▸Sysmon Event 7 — DLL load from non-standard path

  Sysmon Event ID 7 (ImageLoaded) logs every DLL load when enabled (high volume — filter carefully). A UAC bypass loads a payload DLL from a user-writable path (temp, AppData, etc.) into an elevated process.

  Detection: Image: *\\fodhelper.exe AND ImageLoaded: *\\AppData\\* — an auto-elevating system binary should never load DLLs from user AppData directories.

  ⚠ Sysmon Event 7 generates enormous volume. Use targeted filtering and baseline known-good DLL loads before enabling broadly.
• ▸Defender: Behavior:Win32/UACBypass

  Windows Defender has behavioral detections for common UAC bypass patterns including fodhelper, eventvwr, sdclt, and CMSTPLUA-based techniques. The detection fires on the behavioral sequence (registry write + auto-elevating binary + elevated child process) rather than signatures.

  Evasion approaches (for authorized red team use): novel auto-elevating binary targets identified via ProcMon (no existing Defender signature), in-memory COM registration without touching the registry, or tampering with the elevation chain at the API level via hooking.

DLL Search Order Hijacking

Windows resolves DLL names to paths using a predictable search order: the application directory first, then System32, then the Windows directory, then the current working directory, and finally directories listed in the PATH. If an attacker controls any directory earlier in this order than where a legitimate DLL lives, they can plant a malicious DLL that gets loaded instead.

Phantom DLL hijacking targets DLLs that Windows or applications attempt to load but that don't exist on the system — the load fails silently, but if an attacker plants a DLL at a location in the search path, it gets loaded. Process Monitor with a NAME NOT FOUND filter on .dll extensions is the standard tool for finding these opportunities.

• ▸Standard DLL search order (SafeDllSearchMode)

  With SafeDllSearchMode enabled (default since Windows XP SP2), the DLL search order is:

  • The application's own directory
  • The system directory (C:\Windows\System32)
  • The 16-bit system directory (C:\Windows\System)
  • The Windows directory (C:\Windows)
  • The current working directory
  • Directories in the PATH environment variable

  Without SafeDllSearchMode (legacy apps), the current working directory moves to position 2 — a much larger attack surface. Check for this flag: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode.

• ▸KnownDLLs list — what's protected

  The KnownDLLs registry key (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) lists DLLs that Windows loads from a protected cache rather than the search path. These DLLs cannot be hijacked via standard search order manipulation.

  Common KnownDLLs: ntdll.dll, kernel32.dll, kernelbase.dll, advapi32.dll, user32.dll, gdi32.dll. Any DLL not on this list is potentially hijackable if it appears in a process's import table and isn't in System32.

  💡 Enumerate the full list: reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"
• ▸Identifying hijack opportunities with ProcMon

  Process Monitor is the definitive tool for DLL hijack discovery. The workflow:

  • Open ProcMon as admin → Add filter: Result is NAME NOT FOUND
  • Add filter: Path ends with .dll
  • Add filter: Process Name is target.exe
  • Run the target application and observe failed DLL loads
  • For each failed load, check if the search path directory is user-writable

  A failed load from a writable directory (AppData, temp, or a misconfigured PATH entry) is a confirmed hijack opportunity.

  💡 Automation: procmon /quiet /minimized /backingfile out.pml then parse the PML file programmatically with the ProcMon SDK or a Python parser.
• ▸Writable PATH directories — a common misconfiguration

  If any directory in the system PATH is writable by non-admin users, all processes that fail to load a DLL from earlier positions will attempt to load from the attacker-controlled directory. This is particularly impactful because it affects any process, not just a specific target.

  Check: for %A in ("%path:;="" "%") do icacls "%~A" 2>nul | findstr /i "(M) (W) (F) :users :everyone :authenticated"

  ⚠ Enterprise environments with poorly-maintained application installs are frequent offenders — custom PATH entries added by 3rd party software installers sometimes point to directories in Program Files that weren't locked down properly.
• ▸Phantom DLL hunting methodology

  Phantom DLLs are DLLs that applications attempt to load but that don't exist on the system. The load silently fails, but if an attacker plants a DLL at a searched location, it gets loaded. These are particularly valuable because they don't require displacing a legitimate DLL.

  Discovery: run ProcMon on a test system → filter for NAME NOT FOUND + .dll extension → for each candidate, verify the DLL doesn't exist anywhere on the system → check if any search path location is writable.

  Common phantom DLL targets appear in older software, legacy APIs, and print/fax subsystems.

• ▸Trusted path DLL planting (C:\Windows\Temp edge cases)

  C:\Windows\Temp is writable by all authenticated users by default (SYSTEM and admins write here frequently). If any privileged process fails to load a DLL and searches C:\Windows\Temp in its path resolution, a DLL planted there will be loaded at that process's privilege level.

  This is rare on properly maintained systems but appears in:

  • Misconfigured installer frameworks that temporarily add Temp to PATH
  • Poorly-written services that set CWD to Temp
  • Installation scripts that run privileged operations from Temp with a writable working directory

  💡 Monitor during software installs: ProcMon during an installer run frequently reveals temporary PATH manipulation and DLL loads from writable locations.

Registry Permission Abuse

Service image paths, autorun values, and COM registrations stored in the registry become escalation vectors when their ACLs allow write access to non-administrative users. This is less common on modern, properly configured systems but appears frequently in legacy enterprise environments and on machines where software has been installed carelessly.

Simulated Engagement Scenario

Starting condition: code execution as a standard domain user, member of local Administrators, running at medium integrity on a Windows 10 22H2 target. No EDR present but Windows Defender is active. Goal: SYSTEM shell.

Step 1 — Enumeration

Run local_enum.py from Module 2. Key findings to look for: AlwaysInstallElevated (both hives), unquoted service paths with writable directories, and any credential files. Also run token_inspector.py to confirm current integrity level and identify which dangerous privileges are present or disabled.

Step 2 — UAC Bypass to High Integrity

If the user is a local admin but running at medium integrity, apply the COM hijack technique from Module 4 to spawn a high-integrity process. Confirm the elevated context by re-running token_inspector.py and verifying integrity level is now High.

Step 3 — Token Abuse to SYSTEM

From the high-integrity context, apply token_dup.cpp from Module 3 to duplicate the SYSTEM token from winlogon.exe and spawn a cmd.exe as SYSTEM. Alternatively, if SeImpersonatePrivilege is available, apply the appropriate potato variant for the target OS version.

Step 4 — Cleanup and Reporting

Remove all planted registry keys, delete any temporary DLL payloads, and restore any modified service configurations. Document each step with timestamped screenshots or command output. A well-documented privilege escalation finding in a report includes: starting context, technique applied, root cause, evidence, and remediation recommendation.

• ▸Registry artifact cleanup checklist

  After a privilege escalation chain involving registry modifications (especially COM hijacks and service path changes), a clean engagement leaves no persistence artifacts. Work through this checklist before declaring the host clean:

  • Remove all HKCU\Software\Classes\CLSID entries planted during the engagement
  • Restore any service ImagePath values that were modified
  • Delete AlwaysInstallElevated keys if you set them for testing
  • Remove any Run/RunOnce autorun entries added for testing
  • Verify with reg query that keys are actually gone (not just logically deleted)

  ⚠ On real engagements, document every registry change before making it and restore immediately after proving the finding. Never leave modified service configs that could crash the host after your session ends.
• ▸Event log forensics — what did we leave?

  After a privilege escalation chain, review what was logged before handing back the system. Key sources to check:

  • Security log 4688: Every process we spawned is logged with parent/child relationship
  • Security log 4698/4702: Scheduled task creation/modification if we touched tasks
  • System log 7045: New service installation if we registered a service
  • Sysmon 1, 7, 11, 12, 13: Process, DLL, file, and registry events

  On authorized engagements, you generally do NOT clear logs — document what was generated and include it in the report as evidence of detection opportunities.

• ▸Report writing: from findings to recommendations

  A privilege escalation finding in a pentest report needs five components:

  • Title: Concise, specific (e.g., 'UAC Bypass via COM Object Hijacking — fodhelper.exe')
  • Severity: CVSS score or qualitative rating with justification
  • Description: What the vulnerability is and why it exists
  • Evidence: Screenshots, command output, or log excerpts proving exploitation
  • Recommendation: Specific, actionable remediation steps

  💡 Avoid vague recommendations like 'fix permissions'. Write specific steps: 'Remove WRITE_DAC from Authenticated Users on C:\Program Files\VulnApp\ and set icacls inheritance from the parent directory.'
• ▸Mapping the chain to MITRE ATT&CK for report appendix

  Most enterprise clients expect MITRE ATT&CK mapping in pentest deliverables. For a complete foothold → SYSTEM chain, the ATT&CK coverage looks like:

  • T1082 — System Information Discovery (enumeration phase)
  • T1083 — File and Directory Discovery (binary/path enumeration)
  • T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control
  • T1134.001 — Access Token Manipulation: Token Impersonation/Theft
  • T1574.001 — Hijack Execution Flow: DLL Search Order Hijacking
  • T1012 — Query Registry
  • T1112 — Modify Registry

  💡 Use the MITRE ATT&CK Navigator (attack.mitre.org/matrices/enterprise/) to generate a visual heatmap of techniques used — clients love including it in their board-level summaries.

ETW and Event Log Coverage by Technique

Elastic ES|QL Detection Rules

The following detection logic targets the UAC COM hijack pattern specifically — the highest-signal technique from this course given its registry footprint.

Defensive Recommendations by Technique

• ▸Enable Sysmon with SwiftOnSecurity baseline config

  Sysmon (System Monitor) from Sysinternals provides granular telemetry that Windows event logs don't capture by default. The SwiftOnSecurity config (github.com/SwiftOnSecurity/sysmon-config) is a well-maintained, production-ready baseline that covers the most important events without generating unmanageable volume.

  Key event IDs enabled by the baseline: 1 (process create), 3 (network connect), 7 (DLL load — filtered), 10 (process access), 11 (file create), 12/13 (registry events), 22 (DNS query).

  💡 Deploy via GPO: push sysmon64.exe and the config XML to all endpoints, install with sysmon64.exe -accepteula -i sysmonconfig.xml. Updates are non-disruptive: sysmon64.exe -c newconfig.xml.
• ▸Audit HKCU\Software\Classes\CLSID writes via registry auditing

  Enable SACL-based auditing on the HKCU COM registration path to generate Security event 4657 (registry value modified) whenever a COM hijack is planted. Configure via Group Policy: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Registry.

  Add a SACL to the key: HKEY_USERS\*\Software\Classes\CLSID — audit Set Value for Everyone. The resulting 4657 events combined with a subsequent auto-elevating binary execution make a high-confidence detection.

• ▸Configure UAC to 'Always Notify' — removes auto-elevation surface

  Setting UAC to 'Always Notify' (the highest setting) disables the auto-elevation mechanism that all UAC bypass techniques depend on. Every elevation requires an explicit user consent prompt — there is no auto-elevate path for the attacker to abuse.

  Configure via GPO: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode → Prompt for credentials on the secure desktop.

  ⚠ This significantly increases friction for administrators who perform frequent privileged operations. Evaluate user experience impact before deploying broadly — dedicated admin workstations (PAWs) are a better long-term architecture.
• ▸Review service binary ACLs quarterly with AccessChk

  Sysinternals AccessChk automates the process of finding services with misconfigured permissions. Run quarterly as part of a vulnerability management cycle, especially after new software installations.

  Key commands:

  • accesschk.exe -uwcqv "Authenticated Users" * — services writable by any authenticated user
  • accesschk.exe -uwdq "C:\Program Files" — directories writable by standard users
  • accesschk.exe -uwks "Authenticated Users" HKLM\System\CurrentControlSet\Services — registry-level service key permissions
• ▸Deploy Credential Guard to protect LSASS token material

  Credential Guard uses Hyper-V virtualization to isolate LSASS credential material in a protected virtual trust level (VTL 1) that even SYSTEM cannot access directly. NTLM hashes and Kerberos TGTs are protected from sekurlsa::logonpasswords-style extraction.

  Requirements: 64-bit Windows 10/11 Enterprise or Server 2016+, UEFI with Secure Boot, Hyper-V enabled. Enable via GPO: Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security.

  💡 Credential Guard does not protect against golden ticket attacks (if the KDC is compromised) or against attacks that operate via legitimate Kerberos flows. It specifically closes the LSASS dump attack path.
• ▸Audit writable directories in system PATH

  Any directory in the system PATH that non-admin users can write to is a persistent DLL hijack risk. Run this audit after every software installation that modifies PATH:

  for %A in ("%path:;="" "%") do icacls "%~A" 2>nul | findstr /i "(M) (W) (F)"

  For any finding, correct the permissions: icacls "C:\vuln\path" /inheritance:r /grant:r "BUILTIN\Administrators:(F)" "NT AUTHORITY\SYSTEM:(F)" — removes inherited permissions and sets explicit admin-only control.

• ▸Restrict SeImpersonatePrivilege to service accounts that require it

  SeImpersonatePrivilege is the prerequisite for all potato-family attacks. By default it's granted to LOCAL SERVICE, NETWORK SERVICE, and IIS/MSSQL service accounts. It should never be granted to interactive user accounts or development accounts.

  Audit who has it: whoami /priv from each service account context, or use Get-LocalGroupMember to inspect group membership that grants the privilege. Remove it from any account that doesn't explicitly need to perform server-side impersonation.

  💡 If removing the privilege breaks an application, investigate why it needs impersonation — it may indicate a design flaw that should be addressed architecturally rather than just accepted.
• ▸Enable Windows Defender Attack Surface Reduction rules

  ASR rules are policy-based mitigations that block specific attack behaviors regardless of AV signature state. Relevant rules for the techniques in this course:

  • 75668C1F-... — Block Office applications from creating child processes
  • D4F940AB-... — Block all Office applications from creating child processes
  • 92E97FA1-... — Block Win32 API calls from Office macros
  • BE9BA2D9-... — Block executable content from email client and webmail

  Enable via GPO or Intune: Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction.

  ⚠ Always deploy ASR rules in Audit mode first (AuditMode=2) and review the generated events before switching to Block mode — false positives can break legitimate applications.

Background — What Is an Arbitrary Write?

An arbitrary write vulnerability occurs when a privileged process (running as SYSTEM or Administrator) writes to a file or directory path that a lower-privileged user can influence or redirect. On its own, a SYSTEM process writing to C:\ProgramData is not immediately dangerous — but if a standard user can manipulate what that write targets, the write primitive becomes a powerful escalation tool.

CVE-2024-50804 was discovered in MSI Center Pro 2.1.37.0 — software shipped on MSI-branded laptops — and was responsibly disclosed, acknowledged, and patched by MSI's PSIRT team. The patch shipped in version 2.1.41.0 on November 14, 2024. This module walks through the full discovery-to-exploitation methodology so you understand the technique generically, not just for this specific CVE.

The discovery approach that found this CVE — ProcMon observation of SYSTEM writes to ProgramData — is directly applicable to auditing any software installation on any Windows machine.

Step 1 — Discovery with ProcMon

The vulnerability was found the same way most arbitrary write bugs are found: open ProcMon, launch the target application, and watch for a SYSTEM-level process writing to a path where a standard user has influence over the file contents or name.

In this case, C:\Program Files (x86)\MSI\One Dragon Center\MSI.CentralServer.exe — running as SYSTEM — was observed writing to C:\ProgramData\MSI\One Dragon Center\Data\Data\. Specifically, it was performing a two-step file operation:

• 1 Writing data into Device_DeviceID.dat.bak
• 2 Renaming Device_DeviceID.dat.bak → Device_DeviceID.dat

The ProgramData directory inherits permissive ACLs — standard users can read and write files there by default. This meant the .bak file was a target we could manipulate before the SYSTEM process touched it.

Step 2 — The Symlink/Junction Chain

Windows provides two types of filesystem redirection primitives that standard users can create without elevation: directory junctions (redirect a directory path to another directory) and Object Manager symbolic links (redirect a file path to another file, operating at the kernel object level below Win32). Chaining them together is the core of this technique.

The attack chain has two phases:

The Target — EdgeUpdate Directory

The privileged target chosen for this exploit is C:\Program Files (x86)\Microsoft\EdgeUpdate\. This directory is writable only by Administrators under normal conditions — a standard user cannot place files there. By using the arbitrary write primitive to land a custom DLL in this directory, and then triggering the EdgeUpdate scheduled task, we get our DLL loaded as SYSTEM.

The principle generalizes: any directory containing an executable run by a scheduled task at elevated privileges is a viable target. EdgeUpdate is reliable because its scheduled task runs regularly and automatically.

The Exploit Code — Object Manager Symlink Chain

The critical code snippet that creates the two Object Manager RPC control symbolic links is what makes the arbitrary write work. The first symlink redirects the .bak filename to the attacker's payload DLL. The second symlink redirects the renamed .dat filename to the target file path in the privileged directory. When SYSTEM performs the rename, it follows the symlink chain and lands the payload in the protected location.

Step 3 — The Payload DLL and Task Scheduler Execution

With the arbitrary write primitive delivering our DLL into the EdgeUpdate directory, the final step is triggering execution. The EdgeUpdate scheduled task runs automatically at system intervals and loads DLLs from its own directory. A DLL placed there with the right name gets loaded by a SYSTEM process — completing the escalation from standard user to NT AUTHORITY\SYSTEM.

The payload DLL follows the same pattern as Module 5's DLL hijack template: a DllMain that fires on DLL_PROCESS_ATTACH and spawns an elevated shell or calls back to a C2 listener.

The Responsible Disclosure Timeline

This CVE is also a case study in professional vulnerability disclosure. The full timeline from discovery to patch: