homepage
Open menu
Go one level top
  • Train and Certify
    • Overview
    • Get Started in Cyber
    • Courses
    • GIAC Certifications
    • Training Roadmap
    • OnDemand
    • Live Training
    • Summits
    • Cyber Ranges
    • College Degrees & Certificates
    • Scholarship Academies
    • NICE Framework
    • Specials
  • Manage Your Team
    • Overview
    • Group Purchasing
    • Why Work with SANS
    • Build Your Team
    • Hire Cyber Talent
    • Team Development
    • Private Training
    • Security Awareness Training
    • Leadership Training
    • Industries
  • Resources
    • Overview
    • Internet Storm Center
    • White Papers
    • Webcasts
    • Tools
    • Newsletters
    • Blog
    • Podcasts
    • Posters & Cheat Sheets
    • Summit Presentations
    • Security Policy Project
  • Focus Areas
    • Cyber Defense
    • Cloud Security
    • Digital Forensics & Incident Response
    • Industrial Control Systems
    • Cyber Security Leadership
    • Offensive Operations
  • Get Involved
    • Overview
    • Join the Community
    • Work Study
    • Teach for SANS
    • CISO Network
    • Partnerships
    • Sponsorship Opportunities
  • About
    • About SANS
    • Our Founder
    • Instructors
    • Mission
    • Diversity
    • Awards
    • Contact
    • Frequently Asked Questions
    • Customer Reviews
    • Press
  • SANS Sites
    • GIAC Security Certifications
    • Internet Storm Center
    • SANS Technology Institute
    • Security Awareness Training
  • Search
  • Log In
  • Join
    • Account Dashboard
    • Log Out
  1. Home >
  2. Blog >
  3. Monitoring for Delegation Token Theft
370x370_Mike-Pilkington.jpg
Mike Pilkington

Monitoring for Delegation Token Theft

March 30, 2015

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:

image.png

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):

image.png image.png


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:

image.png

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:

image.png

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
image.png

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:

image.png image.png

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:

image.png

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:

image.png image.png

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.

Share:
TwitterLinkedInFacebook
Copy url Url was copied to clipboard
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kingdom of Saudi Arabia
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

Tags:
  • Digital Forensics and Incident Response

Related Content

Blog
SANS_DFIR_Justify_Your_Training.png
Digital Forensics and Incident Response
January 20, 2022
SANS DFIR courses - Justify your training
Use these justification letter templates to share the key details of this training and certification opportunities with your boss.
Viv_Ross_370x370.png
Viviana Ross
read more
Blog
Untitled_design-43.png
Digital Forensics and Incident Response, Cybersecurity and IT Essentials, Industrial Control Systems Security, Purple Team, Open-Source Intelligence (OSINT), Penetration Testing and Ethical Hacking, Cyber Defense, Cloud Security, Security Management, Legal, and Audit
December 8, 2021
Good News: SANS Virtual Summits Will Remain FREE for the Community in 2022
They’re virtual. They’re global. They’re free.
Emily Blades
read more
Blog
Digital Forensics and Incident Response
June 4, 2010
WMIC for incident response
Earlier this week, I posted about using psexec during incident response. I mentioned at the end of that post that I've been using WMIC in place of psexec and that I'd have more on that later. This post, is a follow up to the psexec post. WMIC Prompted by the excellent work of Ed Skoudis and his...
370x370_Mike-Pilkington.jpg
Mike Pilkington
read more
  • Register to Learn
  • Courses
  • Certifications
  • Degree Programs
  • Cyber Ranges
  • Job Tools
  • Security Policy Project
  • Posters & Cheat Sheets
  • White Papers
  • Focus Areas
  • Cyber Defense
  • Cloud Security
  • Cyber Security Leadership
  • Digital Forensics
  • Industrial Control Systems
  • Offensive Operations
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kingdom of Saudi Arabia
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe
  • © 2022 SANS™ Institute
  • Privacy Policy
  • Contact
  • Careers
  • Twitter
  • Facebook
  • Youtube
  • LinkedIn