J.R.R. Tokens

This was almost a post about token theft, but before we talk about stealing things we should probably learn a little bit about them.

You may remember access tokens from our Kerberos marathon, but I would understand if you don't want to revisit that hour of your life.

Simply put, an access token contains the security information for a logon session. There's a bit more to it than that, but for our purposes we can just leave it at that. There are two types of access token: Primary and Impersonation. Primary Tokens can only be attached to processes, and Impersonation Tokens can only be attached to threads.

The access token created by the Local Security Authority Subsystem Service (LSASS), lsass.exe, when a user first authenticates to a system and is attached to the user's shell process, explorer.exe, by the logon service, winlogon.exe.

That was a lot of commas.

Every process started by the user on the user's behalf inherits the user's Primary Token, which allows processes to act as an extension of the user's will, as god and nature intended.

When the user bumps into an access control, LSASS will compare the ACL for the object to the access granted by the access token. If there's a match, access is granted.

But Primary Tokens are nothing without processes to attach to, and a process is pretty useless unless it's got threads.

One step deeper down the hole we go.

Processes and the Threads That Love Them

To start with, it's helpful to understand the difference between a process and a thread, which is something I never really cared about until I tried to write a post about token theft.

A process is like your job (e.g. cubicle jockey), while threads are the tasks you must perform to do your job (go to the meeting, fill in TPS report, etc.). Processes create threads to perform tasks.

When a process starts, it inherits the Primary Token of the process that started it. Threads created by that process inherit the access token of the process. This inherited token is known as an Impersonation Token.

Primary Tokens

So. The access token of the parent process is attached to a process when it is created, going all the way back to when the very fist access token was attached to explorer.exe.

Processes fire off threads to do various tasks, each of which receive an Impersonation Token.

Pretty straightforward.

Impersonation Tokens

An Impersonation Token is used when a process needs to become someone else for a little bit to carry out a task. With great power comes great responsibility and, since threads have no ethics, Impersonation Tokens have wisely been partitioned into different levels of privilege, which allows a more granular control of the token.

Anonymous grants the access of an anonymous user. This has never been implemented.
Identify is like showing your ID when you're buying alcohol. It's verifying that you are indeed behind the request.
Impersonate is like having the face of whoever you lend your ID to appear where your photo normally would. The thread can act on your behalf.
Delegate is like impersonation, except this face swapping thing extends to anyone holding your ID, not just the people you personally lend it to. In this case, the thread can impersonate you on remote systems. When it does this, the remote system has no way of knowing that you are being impersonated. Delegate-level impersonation requires Kerberos.

The client can specify which access level is granted when connecting to a remote system, but this isn't a dropdown box you're going to be able to select when connecting. It's largely up to whoever is writing the code for the software you're using.

For the sake of clarity, I'm going to refer to Impersonation Tokens at the Impersonate level as Impersonation Tokens and ones at the Delegate level as Delegate Tokens.

Impersonation Tokens are commonly created as a result of Type 3 (network) logons. Delegate Tokens are usually created as a result of interactive logons.

Of all the impersonation levels, Impersonate and Delegate are the most interesting.

Since Impersonation Tokens are typically created with our good friend, the network logon, there are no credentials associated with them. This is because, as we found out earlier, no credentials are sent to the target machine.

Because network logons are wonderful and Impersonation Tokens can't be used to authenticate to other systems (a scenario known as the double-hop), they're pretty useless from an attacker's standpoint.

This leaves us with Delegate Tokens, which can have credentials associated with them, can be used to access other systems, and are generally a billion times more interesting for an attacker.

A Brief Segue about Delegate-Level Impersonation

I had a serious headache trying to figure out what the Account is sensitive and cannot be delegated setting did in Active Directory. I'm still chewing on this one, but as near as I can tell this does not protect your Primary Tokens, because they are a feature, not a bug, and instead just hobbles your Delegate Tokens so they behave more like Impersonation Tokens.

When I tested this in my lab, here's what I found when using Incognito's impersonate_token:

Interactive Logon - No issues, can map a drive to DC.
PSExec Logon - System error 1223 has occurred when mapping drive.

I suspect there's a bit more to this, but for now it's a safe bet that you should be clicking this box on all of your privileged accounts.

ELI5

When a user logs on, a Primary Token gets attached to the Windows shell, explorer.exe, which in turn launches pretty much everything else.

Every process started by the user inherits this access token and every thread launched by that process receives an Impersonation Token.

Anywhere a user starts processes, or an application starts processes on behalf of the user, you'll find tokens.

If an attacker has administrative privileges to a system, they own your access tokens.

So what?

The only reason we care about this in any capacity is: With access to your tokens, an attacker can effectively become you.

Well that's something.