You dump credentials, you crack hashes, you spray passwords. But the thing that actually controls what you can do on a Windows system isn't a password. It's a kernel object called an access token. Every process and every thread has one. It dictates who you are, what groups you belong to, and what privileges you hold.
Most operators treat tokens as something that happens in the background. You run whoami and move on. But understanding tokens is the difference between getting stuck at "access denied" and owning the box.
Two Types of Tokens
Windows has two token types, and confusing them is where most people get tripped up.
Here's the key insight: when Windows checks your access to a resource, it looks at the thread token first. If the thread has an impersonation token, that's what gets checked. If it doesn't, it falls back to the process token. This is why impersonation is so powerful. You don't need to change who you are. You just need to change who the current thread is pretending to be.
Why whoami Lies to You
whoami shows the process token. Always. If your thread is impersonating a domain admin but the process is running as a service account, whoami still shows the service account. You might have domain admin access and not know it.
Impersonation Levels
Not all impersonation tokens are equal. Windows defines four levels, and the level determines what you can actually do with the token.
| Level | What You Can Do | Useful? |
|---|---|---|
| Anonymous | Nothing. Can't identify the client. | NO |
| Identification | Read identity and privileges, but can't act as them. | RECON ONLY |
| Impersonation | Act as the client on local resources. | YES |
| Delegation | Act as the client on local and remote resources. | JACKPOT |
Impersonation level lets you access local resources as that user. Delegation level lets you hop to other machines as that user. When you steal a token from a process, check the impersonation level. A delegation token from a domain admin is a lateral movement goldmine. An identification token is worthless for anything beyond reading their username.
Stealing Tokens
Every process on the box has a token. If you have the right privileges (SeDebugPrivilege, or SYSTEM), you can open any process, duplicate its token, and use it. This is what tools like steal_token and impersonate do under the hood.
The Token Hunting Workflow
On any compromised box, the process list is a menu of available identities. List processes, check who owns each one, and decide whose token you want.
ps in your C2, or tasklist /v natively. Look for processes running as domain users, service accounts, or privileged accounts.Make Token: No Process Needed
If you have plaintext credentials but no process running as that user, you can forge a token from scratch using LogonUserW(). This creates a new logon session and gives you a primary token without needing an interactive logon, an RDP session, or a running process to steal from.
LOGON32_LOGON_NEW_CREDENTIALS (type 9) is the magic flag. It creates a token that uses the supplied credentials for network access but keeps your current identity for local access. This is what every C2's make_token command does under the hood.
The Takeaway
Passwords get you in. Tokens let you move. Every lateral movement technique, every privilege escalation, every impersonation attack comes back to tokens. The operator who understands token types, impersonation levels, and when to steal vs when to forge will always move faster than the one who just runs hashdump and hopes for the best.
Token behaviour described here applies to Windows 10/11 and Server 2016+. API availability may vary on older platforms.