Monitoring for Delegation Token Theft

Delegation is a powerful feature of Windows authentication which allows one remote system to effectively forward a user's credentials to another remote system. This is sometimes referred to as the "double-hop". This great power does not come without great risk however, as the delegation access tokens used for this purpose can be stolen by attackers and used for lateral movement. As such, it's important to be aware of this ability and to increase monitoring for malicious use of delegation.

In order to monitor delegation activity, you need to identify where delegation is occurring. Then from those in-scope systems where delegation occurs, look for suspicious activity, and potentially identify which users' accounts were actually delegated. I'll take you through these identification steps, but first let's start with a quick refresher on delegation. This should give you most of the background you need, although you can get even more details about the delegation process in my article on Safeguarding Access Tokens, including some screenshots showing token theft in action. There are also some updates on token protection in a more recent article, Restricted Admin and Protected Users.

Delegation Overview

Delegation is a powerful feature that allows a user's authentication and identity information to be forwarded from one system to another. The most common use of delegation is to enable multi-tier solutions, such as SharePoint. With SharePoint, the typical architecture is to have a front-end web server and a back-end database server. It's the web server that a user directly interacts with, giving the web-portal view of documents, calendars, lists, etc. However, the actual data (the documents, calendars, lists, etc.) reside on a back-end database server. As users directly connect to the front-end web server, the back-end database server also needs to know who the user is so that it can make decisions about which data the user is allowed to access. With delegation, the user authentication to the front-end server is effectively forwarded, or passed, to the back-end server so that it can have the same user identity information necessary to make access decisions. Here's a graphic illustrating this architecture:

A system "Trusted for Delegation" is able to create the "delegate-level" access token that can effectively be forwarded to another system in the domain. Because of the sensitive nature of delegation, most systems are unable to perform delegation. In the example above, however, this capability must be granted to the front-end web server so that it can forward the credentials to the back-end database server that holds the data.

Of course the big security risk here is that if attackers compromise the front-end web server, then they can steal delegate-level tokens of connecting users and use them to authenticate as those users to other systems in the domain. That's why, from a defensive perspective, it's important to know where delegation is occurring in your environment in order to increase monitoring for potentially malicious activity.

Locating Delegation Activity

Both computer accounts and user accounts have the ability to be "Trusted for Delegation". Fortunately, neither users nor computers (other than domain controllers) are trusted to perform delegation by default because this is a very sensitive (and risky) privilege. This privilege should only be granted in relatively rare circumstances. Here's a look at both the computer account "Delegation" tab and the user account "Delegation" tab (to see the Delegation tab for a user account, that user has to have a Service Principle Name (SPN) registered to it, as described here):

Although delegation should be enabled rarely, for a large organization with thousands of user and computer accounts, rare can still mean dozens of accounts with this ability. With this in mind, I recently spent some time trying to determine an effective way to sift through thousands of Active Directory accounts, both users and computers, in order to find which are trusted for delegation. What I found was a PowerShell module that could help determine these settings. Before showing you the PowerShell command, notice from the "Delegation" screenshots above that there are 3 ways to enable delegation:

1. Trust the computer/user for delegation to any service (Kerberos only)
2. Trust the computer/user for delegation to specified services with Kerberos only
3. Trust the computer/user for delegation to specified services with any authentication protocol

For #1 (Trust for delegation to any service-Kerberos only), there is a corresponding Active Directory attribute simply named "TrustedForDelegation". For #3 (Trust for delegation to specified service with any authentication protocol), it also has a corresponding AD attributed, named "TrustedToAuthForDelegation". For #2 (Trust for delegation to specified service with Kerberos only), I was unable to find a specific AD attribute. However, we can get at this by recognizing that in order to be trusted for delegation to a specified service, a Service Principle Name (SPN) must be registered to that account. That registration is stored in an attribute named "msDS-AllowedToDelegateTo". We can use this fact to infer when an account is trusted for delegation to a specified service with Kerberos only (#2).

Using a pair of PowerShell cmdlets from the "Active Directory Module for Windows PowerShell", we can query the properties of every domain account and return just those that are trusted for delegation. Here's what it looks like in the console:

In this screenshot, I have an example of each type of delegation setting:

1. SVILLE: This computer has setting #1 enabled because the "TrustedForDelegation" attribute is set to TRUE.
2. SEATTLE: This computer has setting #2 enabled. This is the one we have to infer. Since it has an SPN registered to it, but is not "TrustedToAuthForDelegation", it must be trusted for delegation to specified services with Kerberos only.
3. DENVER: This computer has setting #3 enabled because the "TrustedToAuthForDelegation" attribute is set to TRUE. (It also must have a registered SPN since it is for specific services only, thus it will also have one or more entries in the "msDS-AllowedToDelegateTo" attribute.)

For a large domain, it would be better to output this data to a file so you can manipulate it easier. Here's the command again, but this time output to CSV:

Get-ADComputer -Filter * -Properties Name,Description,msDS-AllowedToDelegateTo,TrustedForDelegation,TrustedToAuthForDelegation | Where-Object {$_.TrustedForDelegation -eq 'True' -or $_.TrustedToAuthForDelegation -eq 'True' -or $_.'msDS-AllowedToDelegateTo' -ne $null} | Select-Object Name,DNSHostName,Description,@{name='msDS-AllowedToDelegateTo';expression={$_.'msDS-AllowedToDelegateTo' -join ";"}},TrustedForDelegation,TrustedToAuthForDelegation | Export-Csv AdComputer-Delegation.csv

Once the results are brought into a spreadsheet and cleaned up a bit, it will look something like this:

The previous command (Get-ADComputer) will check computer accounts in the domain. A similar command (Get-ADUser) will check user accounts:

Get-ADUser -Filter * -Properties Name,Description,msDS-AllowedToDelegateTo,whenCreated,PasswordLastSet,SamAccountName,ServicePrincipalNames,TrustedForDelegation,TrustedToAuthForDelegation | where {$_.TrustedForDelegation -eq 'True' -or $_.TrustedToAuthForDelegation -eq 'True' -or $_.'msDS-AllowedToDelegateTo' -ne $null} | Select-Object Name,SamAccountName,Description,whenCreated,PasswordLastSet,@{name='ServicePrincipalNames';expression={$_.'ServicePrincipalNames' -join ";"}},@{name='msDS-AllowedToDelegateTo';expression={$_.'msDS-AllowedToDelegateTo' -join ";"}},TrustedForDelegation,TrustedToAuthForDelegation | Export-Csv AdUser-Delegation.csv

With the output from these two commands, you can determine which accounts are trusted for delegation. This goes most of the way to answering our first question: Where can delegation occur? From the commands above, we have a set of computer accounts that are trusted for delegation, so we'd want to enable enhanced monitoring on those computers. But what about the user accounts? Do we have to enhance monitoring on every computer those accounts are used? It depends. For accounts that are trusted to delegate only for specific services, the direct way to answer this is by utilizing the registered SPNs for the user account.

In my example just above, the "Service Account" user is trusted for delegation, but where is that delegation occurring? It is occurring for sharepoint on seattle, as indicated by the SPN in the msDS-AllowedToDelegateTo attribute. By definition, the Service Principle Name specifies a named service on a named computer (or computer alias). As such, we can use this fact to identify where the user is performing delegation. Back to the example, even if the computer account SEATTLE doesn't show up as a computer trusted for delegation, we now know that we should increase monitoring on that computer because there is a service account allowed to perform delegation on that machine.

So that works well for user accounts that are trusted to delegate for specific services. When user accounts are trusted for delegation to any service, then you'll need to analyze the usage of those accounts to determine when, where, and how they are used. These accounts are typically used to run services, so look for computers where these users perform Type 5 logons, found in Event ID 4624 event logs.

Monitoring Delegation in Event Logs

Simply knowing where delegation is occurring is a big piece of the puzzle. I'd recommend gathering event logs and application logs (such as SharePoint logs and antivirus logs) from relevant computers for both real-time alerting of suspicious activity and historic events for forensic purposes.

As far as determining exactly which accounts were delegated, that really wasn't possible prior to Windows 8 and Server 2012. There was no simple way to determine if a delegation token was created for a user when they logged onto a machine.

Fortunately, that has been resolved starting with Windows 8 and Server 2012. Event ID 4624 now specifies the impersonation type that was created when a user logs on. This can be important for both proactively assessing the types of accounts that are performing delegation (i.e., are there any highly privileged accounts being delegated?), as well as forensically analyzing accounts that may have been exposed during a compromise. Here's a look at the updated 4624 event logs:

What if delegation is occurring on older operating systems, such as Windows Server 2008? In that case, we cannot determine specifically which accounts were delegated. However, you can still infer which accounts were delegated based on the fact that the computer performs delegation. Ideally you would tie application logs to event logs to show that not only did a user of interest logon, but also the user utilized a service that is performing delegation (such as SharePoint). Even without the application logs though, simply knowing that an account of interest connected to a compromised server that performs delegation can be enough to follow the lead of credential theft and lateral movement.

Finally, we should be on the lookout for suspicious activity that could indicate delegate-level token theft. Like many things in this field, this can be as much an art as it is a science. There could be any number of attacker tools that have this capability, so essentially you want to look for unusual activity on the computers performing delegation. That said, I'm only aware of two openly available tools that perform token theft: Incognito.exe by Luke Jennings and the incognito module for Metasploit. For incognito.exe, it runs as a service, so this can be a useful thing to watch out for in event logs, particularly the System event log that records changes to Windows services. Here's an example from running incognito.exe on a Windows 8.1 host:

When testing the incognito module for Metasploit, I did not see an incognito service created or anything else to specifically indicate the use of incognito. However, there were other suspicious event logs that should raise concern in an investigation. For example, while using Metasploit's meterpreter payload to run various commands, including the incognito module, the following pseudo-randomly named service and process were created:

By the way, the "Process Command Line" shown above is an added feature to Process Tracking event logs that has been available in Windows 8.1 and Server 2012R2 from the beginning and was just recently made available in Windows 7/8 and Server 2008R2/2012. This is a very useful feature update. For more information, see Microsoft Security Advisory 3004375. Keep in mind though, this would be a security risk for processes run with passwords included in the command line parameters. This could apply to batch scripts and other administrative tools that might inadvertently record sensitive passwords in the event logs.

Conclusion

Delegation is a very powerful and useful feature, though it comes with an equal amount of risk. Therefore, it is important to use delegation sparingly, and where it is in use, apply additional monitoring and detection capabilities. As discussed in this article, you'll want to scope the systems in your environment that are trusted for delegation and then be on the lookout for suspicious activities from these systems. As discussed in the previous articles on this topic, also make sure your highly privileged accounts are explicitly disabled for delegation.

Mike Pilkington is a Sr. Information Security Consultant and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS instructor teaching FOR408 and FOR508. Find Mike on Twitter @mikepilkington.