www.cybertriage.com Open in urlscan Pro
141.193.213.11  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to content
cyber-triage-logo
Primary Menu
 * Features
   
   * * * KEY FEATURES
         
         
       * Overview
       * Collect
       * Prioritize
       * Recommend
     * * Malware Scanning
       * The Collector
       * Ransomware Detection
       * Collaborate
     
     * * RECENT UPDATES
         
         
       * v3.10 (Linux, DCs, ImpHash)
       * v3.9 (Incident Analytics)
       * v3.8 (Autopsy and Malware Boosts)
       * v3.7 (Custom Rules)
   * * 
   * * 
 * Benefits
   * Benefits
   * Consultants
   * Internal Incident Responders
   * Law Enforcement
   * Why Cyber Triage
 * Pricing
   * Pricing
   * Get a Quote
   * Buy License Now
   * Buy Malware Scanning Boost
   * Compare Versions
 * Resources
   
   * * * RESOURCES
         
         
       * Blog
       * Webinars
       * Videos
     
     * * CONNECTORS
         
         
       * Integrations
       * Team REST API
       * EDRs / Deployer Script
       * Malware Scanner for Autopsy
     
     * * TRAINING
         
         
       * Training Overview
       * Intro to DFIR Series
       * All Training Posts
       * Readiness and Investigation Services
 * About
   * About
   * Contact
 * Start Free Trial

 * Blog


DFIR BREAKDOWN: KERBEROASTING

May 31, 2024

Chris Ray

Kerberoasting allows attackers to determine sensitive passwords and the most
common place for detecting this attack is on the domain controller. In this
post, we will look into the details of Kerberoasting from a DFIR perspective. 

Domain Controllers can contain a wealth of information, especially when it comes
to tracking user authentication activity across a domain.  They should be
examined in any intrusion investigation to look for account compromise and
lateral movement. We recently added analytics into Cyber Triage to detect domain
controller attacks, including Kerberoasting, and wanted to share more about it. 

In this post, we will cover:

 * Kerberoasting Key Concepts
 * Kerberoasting Details
 * Attack Goal
 * Attack Requirements
 * Artifacts for Detection
 * How Cyber Triage can help


KERBEROASTING KEY CONCEPTS

Kerberoasting (T1558.003) is a tactic used by threat actors to get credentials
to a domain account by exploiting normal Kerberos behavior in a Windows Active
Directory (AD) environment.

The basic concept is that an attacker interacts with the domain controller to
get a “ticket” that has data encrypted using a user’s password hash. The
attacker then brute forces the data offline and learns the password. They can
then use that password to log into other systems. 

From a DFIR perspective:

 * The domain controller has events that show when the attacker requested the
   ticket, but it could blend in with normal activity
 * The computer used to request the ticket may have artifacts from Kerberoasting
   tools that were run
 * The computers that were accessed using the password will have no evidence
   that Kerberoasting occurred. 


KERBEROASTING DETAILS

To understand how Kerberoasting works and how to detect its activity you must
first understand the basics of Kerberos authentication in Windows. There are a
few main components:

 * Security Principals: Represents user, service, and computer accounts in AD.
   Security Principles can act as both clients (end users and computers) and
   services hosting various resources (file shares, databases, etc…) within the
   domain.
 * Key Distribution Center (KDC): A service on a Domain Controller (DC). It is
   responsible for providing a secure mechanism to prove an entity’s identity
   through the use of session based tickets.
 * Ticket-Granting-Ticket (TGT): A ticket that provides the ability for a
   security principal to prove its identity to the KDC and request Service
   Tickets.  
 * Service Ticket (ST): A ticket that provides the ability for a security
   principal to prove its identity to a service. The service determines if the
   identity is authorized to access its resources. Part of the ticket is
   encrypted with the service accounts password hash. This is the key component
   that Kerberoasting takes advantage of.

The below diagram helps to illustrate the Kerberoasting attack flow, which is
identical to a Kerberos authentication diagram except for step 5 where the
attacker offloads a ticket for offline cracking.



A standard Kerberoasting attack goes as follows:

 1. The threat actor uses a compromised domain account and requests a Ticket
    Granting Ticket (TGT) from the domain controller via an Authentication
    Service Request (AS Req).
 2. The domain controller verifies the user’s (compromised) identity and sends
    back a TGT via Authentication Service response (AS Rep). 
 3. Next, the threat actor requests a Service Ticket (ST) by sending the TGT in
    a Ticket-Granting Service Request (TGS Req).
 4. If successful, the domain controller sends back the ST in a TGS response
    (TGS Rep). The ST contains the encrypted password.
 5. With a ST in hand the attacker can transfer the ticket to a machine
    dedicated to brute forcing the password offline using John the Ripper,
    HashCat, or other password guessing tools.

For a more detailed look at the Kerberos authentication process in full check
out Tim Medins, who first discovered Kerberoasting, blog here and Sean Metcalfs
blog here. 


ATTACK GOAL

The goal of Kerberoasting is to obtain the password for service accounts. The
password for the compromised account can then be used for:

 * Persistence: There are no indicators that an attacker has successfully
   Kerberoasted an account since the brute force is done offline. As a result,
   threat actors can hold on to the credentials and use them as a persistence
   mechanism if they lose access to a target. 
 * Lateral Movement: Newly obtained credentials can be used to move to new
   systems previously inaccessible depending on permissions of the compromised
   account.
 * Privilege Escalation: Newly obtained credentials may have higher privileges
   than the account performing the attack. This is often the case since no
   special privileges are needed to perform Kerberoasting.


ATTACK REQUIREMENTS

For a successful Kerberoasting attack to take place two criteria must be met:

 * Obtain a Service Ticket
 * Brute force the password from a Service Ticket


DETAILS FOR GETTING A SERVICE TICKET

The threat actor ultimately wants a service ticket to decrypt the password from.

Under normal Kerberos operation a user (security principle) must hold a valid
Ticket Granting Ticket (TGT) to obtain a Service Ticket (ST) from the domain
controller (Key Distribution Center). This requires an adversary to have access
to a domain account prior to performing any Kerberoasting activity. There are no
special privileges required so any account within the domain will work.

If access to an account is not possible another non-standard approach to getting
a Service Ticket can be attempted. The alternate approach requires an attacker
to find an account that has Kerberos pre-authentication disabled. When an
account has pre-authentication disabled a TGT can be requested without having to
provide credentials. This allows an attacker to craft a special AS REQ that will
return a Service Ticket instead of the normal TGT as discussed here.

Once an adversary is capable of requesting ST it’s time to find the Service
Principal Names (SPNs) or account names to request STs for. This is key to
understanding the scope of a Kerberoasting attack. A Service Ticket will only
ever be encrypted with an account that has a SPN associated with it. As a
result, only accounts with a SPN are susceptible to Kerberoasting. These are
often computer accounts and service accounts that are associated with a service
like MS SQL. However, normal user accounts can have a SPN as well. These are the
core targets of a Kerberoasting attack as we will discuss shortly. 

Obtaining a list of Kerberoastable accounts is trivial when the threat already
has access to an account. Active Directory (AD) can be queried to get a list of
all accounts with an SPN. Further refinement can be done to only get admin
accounts with SPN or other filtering criteria to find interesting Kerberoastable
accounts. 

Ex. Powershell command to retrieve all admin accounts with a SPN:

get-aduser -filter {AdminCount -eq 1 -and ServicePrincipalName -like '*'} -prop * |

 select name,created,passwordlastset,lastlogondate,ServicePrincipalName

 

This capability is already baked into many of the Kerberoasting tools out there
like Rubeus, Invoke-Kerberoast, and Impackets GetUsersSPNs.py. For a detailed
look at how to perform Kerberoasting using some of previously mentioned tools
check out the great red team write ups from HackTricks and Ired.Team.


BRUTE FORCE THE PASSWORD FROM A SERVICE TICKET

Getting a ST for an account with an associated SPN is only half the battle. The
Service Ticket provides the data necessary to perform an offline brute force
attack. For the attack to be successful a threat actor must guess the password,
usually with a tool like John the Ripper, HashCat or tgsrepcrack.py.
Kerberoasting relies on poor password management and weak passwords, which is
not hard to come by. However, there are a few tricks to increase the chances of
a successful attack:

 * Target user accounts 
 * Request older encryption on Service Tickets

Kerberoasting is generally useless when it comes to targeting computer accounts
and other managed service accounts. Not because these accounts cannot be
Kerberoasted but they are impractical to attack due to the strong password
management on such accounts. Computer account passwords are updated every 30
days, by default, and contain a 120 unicode character password. Similarly,
managed service accounts have passwords that are managed by AD and have similar
password age and length requirements that computer accounts have. As a result,
Kerberoasting attacks tend to focus on standard user accounts that
administrators create and manage. Again relying on the hope that administrators
are not setting strong passwords or updating the password as frequently as one
should. 

Attackers can additionally leverage weak encryption on Service Tickets to
increase the likelihood of cracking a password. Adversaries and many tools will
often request ST with RC4 as the encryption. This was replaced by AES starting
with Windows 2008 Server and Windows Vista. Again this does not mean AES ST are
not susceptible to Kerberoasting it just means it is more work and time to try
and brute force those tickets. ST with RC4 should generally not exist in your
environment unless you have applications or older systems that require it. 


DFIR ARTIFACTS FOR KERBEROASTING DETECTION

Kerberoasting is difficult to detect as it takes advantage of standard Kerberos
behavior. Having said that, there are still a few artifacts to focus on during a
DFIR investigation. We will be grouping the artifacts under the following two
categories as the artifacts available are dependent on the system being
analyzed:

 * Artifacts found on Domain Controllers
 * Artifacts found on Kerberoasting System


ARTIFACTS FOUND ON DOMAIN CONTROLLERS

Domain controllers are key to hunting down Kerberoasting activity due to the
fact that they contain the KDC and can log all requests for TGT and ST within
the domain.


SERVICE TICKET EVENTS

Event 4769 (A Kerberos service ticket was requested) is generated in the
security event log whenever a Service Ticket has been requested. However,
auditing for this event does not appear to be enabled by default based on
Microsoft’s baseline auditing documentation. As a result it is critical that
this setting is enabled for success and failure auditing on all domain
controllers in case the data is needed for an investigation. 



The key pieces of information we are looking for Kerberoasting activity are:

 * Encryption type: This field represents the encryption used. It can be
   leveraged as a way to filter out noise so STs that are more likely a result
   of Kerberoasting activity can be bubbled up. Focus on values of 0x1 or  0x3
   for DES encryption and 0x17 and 0x18 for RC4 encryption.
 * Service Name: The service name that was requested in the Service Ticket. This
   represents a potentially compromised account if Kerberoasting was successful.
   This event cannot indicate the successful brute force guessing of an
   account’s password, just that its information was obtained for potential
   malicious use. This field can also be used to filter out noise like computer
   accounts (ends with a $).
 * Client Address: The IP of the machine that requested the Service Ticket. This
   will indicate a machine that has been compromised and should be further
   investigated if the ticket is found to be related to Kerberoasting.
 * Account Name: User that requested the Service Ticket. This will indicate a
   compromised account and warrants further investigation if the ticket is found
   to be related to Kerberoasting.

It’s important to note that if analyzing an older environment that has a Windows
2003 DC or a member workstation before vista then RC4 encryption will be present
as AES was not introduced until vista/2008 server as documented here. There are
other scenarios where you may run into older encryption due to applications that
only support RC4 as well.


TGT EVENTS

Event 4768 (A Kerberos authentication ticket was requested) is generated in the
security event log whenever a TGT ticket has been requested. However, auditing
for this event does not appear to be enabled by default based on Microsoft’s
baseline auditing documentation. As a result it is critical that this setting is
enabled for success and failure auditing on all domain controllers in case the
data is needed for an investigation.  



The key pieces of information we are looking for Kerberoasting activity are:

 * Service Name: The service name for a TGT ticket should always be krbtgt.
   However, when performing the Kerberos trick we previously mentioned where a
   ST is received via a AS REQ it will generate a TGT event with the name of the
   service requested. This is an easy indicator that a threat actor requested
   the ticket.
 * Client Address:  Same information from 4769 event
 * Account Name: Same information from 4769 event

 


ARTIFACTS FOUND ON KERBEROASTING SYSTEM 

While most Kerberoasting activity will only be visible from a Domain Controller,
there is potential to find evidence on workstations that initiated the
Kerberoasting activity. These systems can be identified by the source IP field
in both TGT and ST that are suspected to be related to Kerberoasting. The key is
to focus on process history that shows any evidence of known Kerberoasting
related tools. For example, if you discover rubeus.exe has been executed via
4688 process creation events or find evidence that Invoke-Kerberoast.ps1 was ran
via powershell logs then there is a good chance some Kerberos related activity
was attempted on that machine and further investigation should occur. Here is a
brief list of some common tools used during Kerberoasting:

 * Rubeus.exe (executable)
 * GetUserSPN.py (python)
 * Invoke-Kerberoast (powershell)
 * Kerberoast Attack Toolkit (python)
 * Kerberoasting scripts from Tim Medin (python/PS1/VBS)
 * setspn.exe (builtin windows binary)
   * Arguments to get ST for all roastable accounts 
   * -T DOMAIN_NAME.LOCAL -Q */* | Select-String ‘^CN’ -Context 0,1 | % {
     New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken
     -ArgumentList $_.Context.PostContext[0].Trim() }

 


HOW CYBER TRIAGE CAN HELP

This is a lot of information to absorb and remember for a single attack,
especially when things get heated during the middle of an investigation. It can
be difficult to remember all of the locations where evidence can be found or the
various heuristics that can be applied. That is why Cyber Triage is here to
help! Our tool aims to assist in the following areas:

 * Automatic artifact collection 
 * Automatic artifact scoring 

As part of an investigation, you should collect data from the domain controller
and analyze the authentication logs. This can show you Kerberos attacks and
where users logged into.


AUTOMATIC ARTIFACT COLLECTION

Our adaptive collector collects source files (event logs, registry hives,
etc..), parses out artifacts, and collects other interesting files based on
references from artifacts. In the case of a Kerberoasting attack our collector
will collect the security event log and parse out 4768 and 4769 events as
artifacts.

Cyber Triage has a dedicated UI to displaying domain controller authentications
so that you can see logon activity even if the specific destinations have not
been collected and analyzed. Below is an example of a Service Ticket request
(4769). The Sources tab shows you why Cyber Triage knows about the
authentication attempt. From here, you can see:

 * The request came in from 10.0.0.2. 
 * The authenticated user account was acme/rosemarie
 * The service that is being accessed is computer2$



Similarly, here is an example of a Ticket Granting Ticket request (4768). The
main difference in the top table is the service name, which is because the TGT
request goes to the krbtgt service. 



If you are not seeing authentication types that you had hoped to see, you can go
to the “OS Config Settings” to see what the audit settings were:



All of this is done without any user configuration, running of multiple tools,
or manual parsing of tool output. The collector is run, DFIR related artifacts
are collected, and data is displayed to a user for review.


AUTOMATIC ARTIFACT SCORING

Cyber Triage automatically scores the collected data to show you what is
suspicious in the case.  In the case of Kerberoasting there are two main
heuristics. The first is to detect potential Kerberoasting activity via Service
Ticket requests with weak encryption.



The second is to detect non-standard services in TGT tickets, which as we
discussed is a method an attacker can use to request a ST via AS REQ when an
account has pre-authentication disabled. 




CONCLUSION

In summary, Kerberoasting is essentially an offline brute force attack that
relies on exploiting the Kerberos Authentication protocol to get a piece of
information (ST) to guess an account’s password. Detection is difficult due to
the nature of the attack exploiting normal Kerberos behavior and the offline
brute force component.

It can be hard to detect the Kerberoasting events amongst all your event logs.
If you are looking for a faster and more comprehensive way to analyze your
domain controllers, then try Cyber Triage. You can download a free one week
trial version here: https://www.cybertriage.com/download-eval/


REFERENCES

 * https://attack.mitre.org/techniques/T1558/003/
 * https://redsiege.com/tools-techniques/2020/10/detecting-kerberoasting/
 * https://adsecurity.org/?p=3458
 * https://posts.specterops.io/kerberoasting-revisited-d434351bd4d1
 * https://www.semperis.com/blog/new-attack-paths-as-requested-sts/
 * https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1208-kerberoasting
 * https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/kerberoast


RELATED

 * Collecting Linux DFIR Artifacts with UAC
 * How To DFIR Investigate with Cyber Triage and CrowdStrike Real Time Response
 * Adaptive vs Static File Collections for DFIR
 * 3.10 adds Linux, Domain Controllers, and Fuzzy Malware Scanning for DFIR

Blog

Features

 * Overview
 * Collect
 * Prioritize
 * Recommend
 * Collaborate
 * Versions
 * Integrations

Benefits

 * Overview
 * Internal IR
 * Consultants
 * Law Enforcement
 * Pricing

Company

 * About
 * Blog
 * Contact
 * Webinars
 * Videos
 * Get Cyber Triage



© 2024 Sleuth Kit Labs LLC. ALL RIGHTS RESERVED. | Terms of Use | Privacy Policy

 * Twitter
 * Reddit
 * Linkedin
 * Facebook
 * YouTube

✓
Thanks for sharing!
AddToAny
More…