Kerberoasting targets user objects configured with a Service Principal Name (SPN). When a user object has an SPN, any other object, including unprivileged users, can request its Ticket Granting Service (TGS) ticket from a Domain Controller. By design, this functionality allows user objects to interact with services. The TGS ticket is encrypted with the user object's password hash. Malicious actors can capture this ticket and attempt to crack the password hash offline to reveal the plaintext password. If successful, they can authenticate as the user object, gaining access to its permissions and potentially escalating their privileges within the network.
Detection
Detecting Kerberoasting can be challenging because this technique mimics legitimate Active Directory activity. User objects request Ticket Granting Service (TGS) tickets when accessing services in the domain, and the events generated for this legitimate activity are the same as those generated by Kerberoasting. This makes it possible for Kerberoasting to be overlooked among the numerous legitimate events that are logged. One method to detect Kerberoasting is to analyse TGS request events (Event ID 4769) and identify instances where TGS requests are made for multiple user objects configured with Service Principal Names (SPNs) within a short timeframe. Kerberoasting typically involves simultaneously retrieving TGS tickets for all user objects with SPNs. TGS ticket request events (Event ID 4769) for numerous user objects with SPNs in a brief period may indicate that Kerberoasting has occurred. Another method for detecting Kerberoasting is to analyse unusual TGS requests for services. For example, this could include TGS requests for services not typically accessed by the requesting user or computer object, such as a backup server that is usually only accessed by other servers.
Events that detect Kerberoasting:
EventID: 4738, 5136
Source: Domain Controller (DC)
Description: Events are generated when a user account is changed. Malicious actors can modify user objects and add an SPN to retrieve the Kerberos service ticket.
EventID: 4769
Source: Domain Controller
Description: The event is generated when a TGS ticket is requested. When malicious actors execute Kerberoasting, event 4769 is generated for each TGS ticket requested for a user object.
Mitigation
To mitigate Kerberoasting attacks, organisations should enforce strong, complex passwords for service accounts and regularly rotate them. Additionally, using managed service accounts (MSAs) or group managed service accounts (gMSAs) can help reduce the risk, as these accounts automatically manage password changes. Limiting the number of accounts with SPNs and applying the principle of least privilege can also reduce the attack surface.
Tools
Security Information and Event Management (SIEM) Tools
SIEMs aggregate and analyze logs from multiple sources, making them ideal for Kerberoasting detection.
Splunk: Use queries (like the ones we discussed) to detect suspicious Kerberos service ticket requests. Leverage Splunk's correlation rules and dashboards for real-time monitoring.
Microsoft Sentinel: Offers prebuilt analytics rules and hunting queries that can identify Kerberoasting attempts.
QRadar: Includes detection rules for unusual Kerberos ticket requests and provides correlation capabilities.
Elastic Stack (ELK): Analyse logs for anomalies in Kerberos traffic, particularly using Event ID 4769.
Endpoint Detection and Response (EDR) Tools
These tools provide endpoint-level telemetry to detect suspicious processes or activities.
Microsoft Defender for Endpoint (Defender XDR):
Detects Kerberoasting by monitoring for processes like Rubeus or PowerShell-based attacks.
Provides alerts for suspicious ticket requests and encryption-type anomalies.
CrowdStrike Falcon: Monitors processes and logs related to Kerberos service tickets and flags potential abuse.
SentinelOne: Detects suspicious behaviour indicative of credential dumping or Kerberoasting.
Sysmon (System Monitor)
Sysmon: Collects detailed process and network telemetry, including Event ID 13 (Kerberos Service Ticket Requests). It's particularly useful for tracking unusual service ticket requests directly from endpoints.
Threat-Hunting Tools
These tools assist in proactive hunting for kerberoasting attempts by analysing logs and events.
Velociraptor: A powerful DFIR and threat-hunting tool. Custom Velociraptor queries (VQL) can analyse Kerberos-related activities.
Kusto Query Language (KQL): Used in Microsoft Sentinel to write detailed queries for analysing Kerberos ticket requests.
Network Traffic Analysis Tools
These tools monitor Kerberos network traffic for anomalies.
Wireshark: Analyses network packets and can capture Kerberos traffic to spot unusual service ticket requests.
Zeek (formerly Bro): Provides network visibility and can flag anomalous Kerberos activity.
Penetration Testing and Adversary Simulation Tools
These tools simulate attacks, test defences, and detect kerberoasting signatures.
Rubeus: Often used by attackers for kerberoasting, its activity can be detected via behavioural analysis in logs and SIEMs.
Impacket: Tools like GetUserSPNs.py are commonly used for kerberoasting; monitor their execution to detect misuse.
Atomic Red Team: Provides simulations of Kerberoasting techniques (e.g., T1558.003 in the MITRE ATT&CK framework) to validate detection capabilities.
Identity and Access Management (IAM) Tools
Azure Active Directory (Azure AD): Monitors and alerts on unusual service ticket requests and account activity.
Ping Identity/Okta: Tracks authentication-related activities, helping to detect anomalies indicative of kerberoasting.
Detection Rules and Threat Intelligence
MITRE ATT&CK Framework: Provides a knowledge base (e.g., T1558.003) to help identify indicators of kerberoasting.
Sigma Rules: Open-source detection rules that can be converted to SIEM-specific queries (e.g., Splunk or Elastic).
YARA Rules: Useful for detecting known kerberoasting tools and scripts.
Cloud Security Monitoring Tools
AWS GuardDuty, Azure Security Center, GCP Security Command Center:
Detect kerberoasting-like activity in cloud environments, especially if attackers target cloud-hosted Windows domains.
Best Practices for Using These Tools
Baseline Normal Behavior: Establish what "normal" Kerberos activity looks like in your environment.
Integrate Tools: Use SIEMs alongside EDR and network monitoring tools for comprehensive detection.
Regular Updates: Ensure detection rules are updated with the latest indicators of compromise (IOCs) and attack techniques.
Simulations: Regularly test detection capabilities using adversary simulation tools.
KQL Detection Query
// Define the time range for the query
let startTime = ago(7d);
let endTime = now();
// Define a whitelist of service names to exclude from the results
let whitelistServiceNames = dynamic(["krbtgt", "svc_", "admin_", "backup_"]);
// Step 1: Identify accounts requesting multiple TGS tickets within a short period
let suspiciousAccounts = SecurityEvent
| where TimeGenerated between (startTime .. endTime)
| where EventID == 4769 // TGS ticket request
| parse EventData with * 'ServiceName">' ServiceName '<' * 'TargetUserName">' TargetUserName '<' *
| where ServiceName !in (whitelistServiceNames)
| summarize ticketCount = count() by TargetUserName, bin(TimeGenerated, 1h)
| where ticketCount > 5;
// Step 2: Identify weak encryption types used in TGS tickets
let weakEncryptionTypes = SecurityEvent
| where TimeGenerated between (startTime .. endTime)
| where EventID == 4769 // TGS ticket request
| parse EventData with * 'TicketEncryptionType">' TicketEncryptionType '<' *
| where TicketEncryptionType in ("0x17", "0x18") // RC4-HMAC and AES128-CTS-HMAC-SHA1-96
| summarize ticketCount = count() by TargetUserName, bin(TimeGenerated, 1h)
| where ticketCount > 5;
// Step 3: Combine the results to identify suspicious activity
suspiciousAccounts
| join kind=inner (weakEncryptionTypes) on TargetUserName
| project TimeGenerated, TargetUserName, ticketCount
| order by TimeGenerated desc
Query performs the following steps:
Identifies accounts requesting multiple TGS tickets within a short period.
Filters out service names that are commonly used and not likely to be malicious.
Identifies weak encryption types used in TGS tickets, which are more susceptible to cracking.
The results are combined to identify suspicious activity related to kerberoasting.
// Define the time range for the query
let startTime = ago(7d);
let endTime = now();
// Define a list of known service accounts to exclude from the results
let knownServiceAccounts = dynamic(["krbtgt", "svc_", "admin_", "backup_"]);
// Step 1: Identify TGS requests from non-service accounts
let tgsRequests = SecurityEvent
| where TimeGenerated between (startTime .. endTime)
| where EventID == 4769 // TGS ticket request
| parse EventData with * 'ServiceName">' ServiceName '<' * 'TargetUserName">' TargetUserName '<' *
| where ServiceName !in (knownServiceAccounts)
| summarize requestCount = count() by TargetUserName, ServiceName, bin(TimeGenerated, 1h)
| where requestCount > 5;
// Step 2: Identify TGS requests using weak encryption types
let weakEncryptionRequests = SecurityEvent
| where TimeGenerated between (startTime .. endTime)
| where EventID == 4769 // TGS ticket request
| parse EventData with * 'TicketEncryptionType">' TicketEncryptionType '<' *
| where TicketEncryptionType in ("0x17", "0x18") // RC4-HMAC and AES128-CTS-HMAC-SHA1-96
| summarize requestCount = count() by TargetUserName, ServiceName, bin(TimeGenerated, 1h)
| where requestCount > 5;
// Step 3: Combine the results to identify suspicious activity
tgsRequests
| join kind=inner (weakEncryptionRequests) on TargetUserName, ServiceName
| project TimeGenerated, TargetUserName, ServiceName, requestCount
| order by TimeGenerated desc
Query performs the following steps:
Identifies TGS requests from non-service accounts, filtering out known service accounts to focus on potentially suspicious activity.
Filters TGS requests using weak encryption types, which are more susceptible to cracking.
Combines the results to identify suspicious activity related to Kerberoasting.
Splunk Detection Query
Note: Choose the appropriate index and sourcetype; these are often different in organisations.