Windows Local Privilege Escalation: Seven Paths
SeImpersonatePrivilege, service permissions, scheduled tasks, DLL search order, named pipes, UAC token filtering and COM hijacking, each with its precondition.
Local escalation on Windows usually comes down to one question: which identity does the next thing run as, and who is allowed to change what it points at.
SeImpersonatePrivilege
Some Windows services do not need a privileged user password to act in that user context. A token is enough. SeImpersonatePrivilege lets a process adopt client tokens in impersonation scenarios. IIS workers and service identities often receive this privilege. Potato-style exploit families abuse local authentication mechanisms to obtain a more privileged token and impersonate it. Viability changes across Windows versions. I confirm token privileges with whoami /priv, Windows version and process context before using any PoC. Having SeImpersonate does not guarantee SYSTEM. The attacker still needs a primitive that exposes or causes authentication from a suitable privileged principal.
1
2
whoami /priv
whoami /groups
Windows Service Privilege Escalation
A service may run as SYSTEM with protected configuration while executing a binary or directory a regular user can modify. Windows services have service ACLs, ImagePath, service accounts and filesystem permissions. Any of those relationships may create privilege escalation. Unquoted service paths depend on spaces and writable intermediate paths. Weak service ACLs may allow binPath or start configuration changes. I enumerate sc qc, service ACLs and icacls on every path component before touching the service. Restart permission may be required for an immediate trigger. Without it, reboot or later maintenance may be the missing condition.
1
2
sc.exe qc BackupService
icacls "C:\Program Files\Vendor\Backup\backup.exe"
Scheduled Tasks
A high-privileged Windows scheduled task is usually only as secure as the files, directories and arguments it consumes. Task Scheduler stores principals, triggers, actions and settings. Tasks may run as SYSTEM, a service account or a stored user identity. Writable scripts, executables, working directories and task ACLs create escalation paths. Credentials may exist depending on logon type. I list tasks in detail, identify the run-as identity and follow every action path with icacls. Being able to read task XML does not mean being able to modify the task. Testing should separate filesystem permission from the task object ACL.
1
schtasks /query /fo LIST /v
DLL Search Order Hijacking
An executable can be legitimate and signed. If it searches for a DLL by name in a writable directory, trust moves to the filesystem. The Windows loader has a search order influenced by SafeDllSearchMode, KnownDLLs, application directories and LoadLibrary behavior. Hijacking requires an expected DLL name, a controllable search path and a process running with more privilege than the attacker. I use Procmon to observe NAME NOT FOUND and Load Image events, then validate which writable directory appears before the legitimate DLL. Dropping a random DLL into System32 is not a method. The finding needs a real observed search and a writable directory inside that order.
1
2
3
Process Name is target.exe
Operation is CreateFile or Load Image
Result is NAME NOT FOUND
Named Pipes and Token Impersonation
A named pipe looks like simple local IPC until a service uses the connecting client identity as part of its work. Named pipes support security descriptors and impersonation levels. A server may call ImpersonateNamedPipeClient under appropriate conditions. Weak pipe ACLs may allow unauthorized connections or creation. Token impersonation becomes privilege escalation when a privileged client connects to an attacker-controlled pipe. I enumerate pipes, ACLs and creating processes, then observe who connects and which impersonation level is available in a lab. Knowing the pipe name alone does not provide a token. The attacker needs control of the server endpoint or an exploitable ACL and connection flow.
1
2
pipelist.exe
accesschk.exe -accepteula -w \\.\pipe\*
UAC and Integrity Levels
Membership in Administrators does not mean every current process is running with the full administrative token. UAC creates split tokens for interactive administrators. Medium integrity and High integrity represent different execution contexts. Remote UAC may also filter local-account tokens during remote access, affecting lateral movement. I confirm whoami /groups, integrity level, token elevation and account type before concluding privilege. UAC bypass should not be treated as privilege escalation from a normal user. It usually requires an existing administrative context.
1
2
whoami /groups
whoami /priv
COM Hijacking
COM resolves CLSIDs to registered components. When a writable path or per-user registration wins resolution, another process may load unexpected code. COM registration lives in HKLM and HKCU. Per-user classes may override resolution in some contexts. Hijacking depends on a CLSID used by an interesting process, missing or higher-precedence registration and actual load behavior. I observe Procmon and registry queries in a lab to identify a real CLSID before creating any temporary registration. The technique is highly contextual. Creating thousands of random CLSIDs proves nothing and may destabilize the profile.
1
reg query HKCU\Software\Classes\CLSID /s