Token Impersonation Attack

Token Impersonation is a way of impersonating a user access token, allowing you to effectively take over the user without even needing to know the user’s password. Subsequently, attackers are currently using this in the wild as a way to escalate privileges and move laterally across the network. However, without proper mitigation in place, it is relatively easy to perform.

The one caveat is that a token impersonation attack is a post-exploitation attack. This means you need to already have a shell on the device, with local administrator privileges to perform it.

What are Access Tokens?

Access Tokens are generated after a user Logs on to a Windows Domain or subsequently connects to a network share. These tokens are then used to perform checks when accessing securable objects or performing privileged actions across the domain.

The diagram below shows the process of an access check when a user is accessing a secure object, for example, a folder on a network share.

At a High level, think of access tokens like temporary keys that store all the user’s identity and privileges for the domain they currently have access too. Subsequentially, these tokens are part of the single sign-on process and allow users to access resources across the domain without you having to provide a password each time you wish to open a file.

Access tokens contain the following information:-

• The user’s SID (Security Identifier).
• SIDs for the groups of which the user is a member.
• A logon SID which identifies the current logon session.
• The user and group privileges.
• An owner SID.
• The SID for the primary group.
• The default DACL (Discretionary Access Control List) that the system uses when the user creates a securable object without specifying an explicit security descriptor.
• The source of the access token.
• A flag that indicates the type of token. (Primary \ Impersonation)
• List of restricting SIDs. (optional)
• Current impersonation levels.
• Other statistics.

Types of Access Token

There are two types of access tokens:

• Primary (sometimes called Delegate)
• Impersonation

Primary tokens get created when a user logs on to a Windows Domain. This can be physically sitting in front of a windows box or remotely via Remote Desktop.

Impersonation tokens typically, run something in a different security context to the process that started it. These non-interactive tokens are used for mounting network shares or domain logon scripts.

The Sysinternals tool logonSessions allows you to view all the currently active logon sessions and if you specify the -p options, the processes running in each session.

My LAB

My LAB contains a PFSense Firewall, Windows 10 workstation joined to a Windows server 2016 Domain Controller, and my Kali box.

Building a LAB is a bit out of scope for this tutorial. Considering this, one of my favorites is this one from 1337red. If you’re interested in a tutorial on how I set up my lab let me know in the comments below.

Also, check out this guide on disabling windows defender on the windows 10 workstation. It will make this tutorial run a lot smoother.

Getting a Shell as Local Administrator

As Token Impersonation is a post-exploitation attack we need to first have local administrator access to the device for the attack to work.

In this tutorial, I will be using the Psexec module in Metasploit to gain local administrator access to the workstation. Admittedly, Metersploit is not the only way to get local administrator access on a Windows Device.

However, I want to use the Incognito module in Metasploit as it makes Token Impersonation trivial.

If you’re interested in creating your own Meterpreter payload you should check out my tutorial Creating a Payload with MSFvenom.

• Start Metasploit by typing msfconsole, Once loaded fire up the Psexec exploit.

• Set the RHOSTS, SMBuser, SMBPass and Target.

These need to be the local administrator details for the windows device. Also, set the targets to Native upload.

• Check your options are correct.

• Set the payload you want to run after Metasploit fires off Psexec. Then set the LHOST. (LHOST stands for Local Host and is the address you want the payload to call back too).

• Type options to check all the options are correct

• Now type run to fire PSEXEC against your target.

Therefore, If everything goes well, you should now have a Meterpreter session connected to the windows PC.

Load Incognito Extension

Now you have a meterpreter session you need to load the Incognito Extension into your session. The Incognito extension, once loaded gives you all the token impersonation functionality from within our meterpreter session.

• To view all the different default extensions available in meterpreter type load -l

• Load the Incognito extension into your meterpreter session by typing load incognito. Once loaded, just type help to display all the incognito commands.

• Type list_tokens -u to list all the available tokens on the remote domain joined PC we have our meterpreter session on.

Tokens displayed will be of any user that has recently logged into the windows PC or any credentials used to access a share on the domain.

These Tokens stay available until the PC is rebooted. However, because of this, if you can get a shell on a File Server they become a virtual treasure trove of user tokens you can impersonate.

Luckily, in my LAB a Domain Administrator has logged into this PC recently. Specifically, allowing me to impersonate his token.

• Type impersonate_token (domain\\Username)

Remember to use a double backslash “\\” between the domain and the username. Otherwise, the impersonation will not work.

Testing the Impersonated user

Consequently, now we have Impersonated the Domain Administrator token, let’s test the permissions we now have.

• Drop into a shell and run a whoami command, confirming you are the user you have impersonated.

Since I am a Domain Administrator, I now have full access to the network, like for example, accessing admin shares directly on the domain controller.

I can also now even create my own Domain administrator account, In Active Directory.

Quickly check the new user you have just created with “net user <user> /domain” command.

As a result, I can now use this account to RDP directly onto the domain controller.

To conclude try out some of the other Icongnito commands mentioned earlier, like the snaff_hash command and let me know your expirance in the comments below.

Rev2self

In the event that you ever need to get back to your original user, use the rev2self command. This allows you to at any point to revert your access tokens back to your original user.

For example, you may find you have impersonated a user that may not be privileged like some users used by a system processes. Type rev2self at the meterpreter prompt to consequently, revert your tokens back to the user you originally connected as.

• At the meterpreter prompt type rev2self. Then dropping back into a shell type whoami to confirm your now back to your original user.

Other Options For Token Impersonation

Finally, The Incognito Module in Meterpreter is not the only way to perform Token Impersonation, Check out these other techniques below…

• PowerSploit – has a Token Impersonation module called Invoke-TokenManipulation.ps1
• Rotten Potato Exploit – Allows escalation from service level accounts to SYSTEM through Token Impersonation. See Foxglove Security’s writeup for more details.
• Mimikatz – The TOKEN module enables Mimikatz to interact with windows authentication tokens, including grabbing and impersonating access tokens.
• The Lonely Potato – Decoder.cloud has a great writeup on the exploit.

Mitigation

There is no way to disable access tokens in windows. However, to perform this technique an attacker must already have administrative level access.

Below is a list of mitigation techniques to help prevent the attack.

• Limit user / Group token creation permissions: Limit Permissions so that users and groups cannot create tokens. GPO: Computer Configuration > [Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment: Create a token object. Also, define who can create a process level token to only the local and network service in the Replace a process level token setting in the same location in the GPO.

• Account Tiering: If you split up administrator roles and only allow domain admins to access the domain controllers and a separate “workstation admins” to administrate the workstations. This essentially means the domain administrator is never exposed to this attack. As a result, never giving up the keys to the castle.

• Local Admin Restrictions: As this is a post-exploitation attack you need to have at least Local administrator Privileges on the windows device. The problem is most of the time this password is the same across all devices. This is where Microsoft LAPS (Local Administrator Password Solution) comes in to play, allowing you to randomly assign local administrator passwords to devices on the network which then can be viewed in Active Directory. Check out my detailed guide to installing LAPS.