Kerberoasting

Introduction

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

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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

Query 1

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

1. Identifies accounts requesting multiple TGS tickets within a short period.

2. Filters out service names that are commonly used and not likely to be malicious.

3. Identifies weak encryption types used in TGS tickets, which are more susceptible to cracking.

4. The results are combined to identify suspicious activity related to kerberoasting.

Query 2

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

1. Identifies TGS requests from non-service accounts, filtering out known service accounts to focus on potentially suspicious activity.

2. Filters TGS requests using weak encryption types, which are more susceptible to cracking.

3. 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.

Query 1

index=windows sourcetype=your_sourcetype
| eval TicketEncryptionType=case(TicketEncryptionType=="0x17", "RC4-HMAC", TicketEncryptionType=="0x18", "AES128-CTS-HMAC-SHA1-96")
| search EventCode=4769 TicketEncryptionType IN ("RC4-HMAC", "AES128-CTS-HMAC-SHA1-96")
| stats count by TargetUserName, ServiceName, TicketEncryptionType
| where count > 5
| table _time, TargetUserName, ServiceName, TicketEncryptionType, count
| sort -_time

Query performs the following steps:

1. Filters events to include only those with EventCode 4769, which corresponds to TGS ticket requests.

2. Evaluate the TicketEncryptionType to identify weak encryption types (RC4-HMAC and AES128-CTS-HMAC-SHA1-96).

3. Searches for TGS requests using these weak encryption types.

4. Aggregates the data to count the number of TGS requests per TargetUserName and ServiceName.

5. Filters the results to include only those with more than 5 requests.

6. Displays the results in a table format, sorted by time.

Query 2

index=sysmon sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
| eval TicketEncryptionType=case(TicketEncryptionType=="0x17", "RC4-HMAC", TicketEncryptionType=="0x18", "AES128-CTS-HMAC-SHA1-96")
| search EventCode=4769 TicketEncryptionType IN ("RC4-HMAC", "AES128-CTS-HMAC-SHA1-96")
| stats count by TargetUserName, ServiceName, TicketEncryptionType
| where count > 5
| table _time, TargetUserName, ServiceName, TicketEncryptionType, count
| sort -_time

Query performs the following steps:

1. Filters events to include only those from the Sysmon index with the specified sourcetype.

2. Evaluates the TicketEncryptionType to identify weak encryption types (RC4-HMAC and AES128-CTS-HMAC-SHA1-96).

3. Searches for TGS requests using these weak encryption types.

4. Aggregates the data to count the number of TGS requests per TargetUserName and ServiceName.

5. Filters the results to include only those with more than 5 requests.

6. Displays the results in a table format, sorted by time.

Query 3

index=windows (sourcetype="WinEventLog:Security" OR EventCode=4769)
| eval AccountName = mvindex(Account_Name, 1) 
| where Ticket_Encryption_Type = "0x17" OR Ticket_Encryption_Type = "0x12" 
| stats count BY AccountName, ServiceName, Client_Address, Ticket_Encryption_Type 
| where count > 20 
| rename AccountName AS "Target Account", ServiceName AS "SPN", Client_Address AS "Requesting Host", Ticket_Encryption_Type AS "Encryption Type" 
| table "Target Account", SPN, "Requesting Host", "Encryption Type", count
| sort - count
| search NOT [ | inputlookup allowed_kerberos_requests.csv ]

Explanation:

1. Index and Sourcetype:

   • Searches the Windows Security logs (adjust index as needed for your Splunk environment).

2. EventCode 4769:

   • This event code indicates a Kerberos service ticket was requested.

3. Encryption Types:

   • Looks for common encryption types used for Kerberoasting: RC4 (0x17) or AES (0x12).

4. Threshold:

   • Flags accounts with more than 20 service ticket requests. Adjust count > 20 based on your environment's normal behaviour.

5. Filters Known Behavior:

   • Excludes known safe activity by referencing an allowed_kerberos_requests.csv lookup table, which you can maintain with legitimate SPN requests.

Query 4

index=windows (sourcetype="WinEventLog:Security" OR EventCode=4769)
| eval AccountName = mvindex(Account_Name, 1), 
        ServiceName=coalesce(Service_Name, ServiceName), 
        ClientHost=coalesce(Client_Address, Client_Host), 
        EncryptionType=case(
            Ticket_Encryption_Type == "0x17", "RC4",
            Ticket_Encryption_Type == "0x12", "AES",
            true(), Ticket_Encryption_Type
        )
| where EncryptionType IN ("RC4", "AES")
| stats count AS RequestCount, values(ClientHost) AS RequestingHosts, dc(ClientHost) AS UniqueHosts 
        BY AccountName, ServiceName, EncryptionType
| eval SuspiciousSPN = if(RequestCount > 10 AND UniqueHosts > 3, 1, 0) 
| join type=left [ 
    search index=windows (sourcetype="WinEventLog:Security" EventCode=4624)
    | stats count AS LogonCount, values(IpAddress) AS LogonIPs 
      BY AccountName
    | eval RareAccount = if(LogonCount < 5, 1, 0)
]
| eval ThreatScore = SuspiciousSPN + RareAccount
| where ThreatScore > 0
| table AccountName, ServiceName, EncryptionType, RequestCount, RequestingHosts, UniqueHosts, LogonCount, LogonIPs, SuspiciousSPN, RareAccount, ThreatScore
| sort - ThreatScore
| search NOT [ | inputlookup known_safe_accounts.csv ]

Key Enhancements:

1. Field Normalisation:

   • Coalesces and normalizes fields for ServiceName and ClientHost to handle variations in log data.

2. Dynamic Encryption Type Labeling:

   • Translates Ticket_Encryption_Type codes into human-readable encryption types (RC4 or AES).

3. Multi-Factor Evaluation:

   • Adds new fields to assess:

     • Suspicious SPNs: Based on a high number of requests and multiple requesting hosts.

     • Rare Accounts: Based on low logon activity from the account being targeted.

4. Threat Scoring:

   • Calculates a ThreatScore based on whether the SPN is suspicious and if the account is rare.

   • Scores above 0 indicate potentially malicious activity.

5. Logon Correlation:

   • Joins with Event ID 4624 (successful logons) to identify if the targeted account is rarely used.

6. Filtering Legitimate Activity:

   • Excludes known safe accounts using a known_safe_accounts.csv lookup file.

7. Result Presentation:

   • Provides a concise table for SOC analysts with key details like account, SPN, encryption type, request count, unique hosts, and threat score.

Recommended Usage:

• Custom Thresholds: Adjust thresholds for RequestCount, UniqueHosts, and LogonCount based on your environment's baseline.

• Continuous Learning: Regularly update known_safe_accounts.csv with legitimate accounts and SPNs.

• Alerting & Dashboard: Set up alerts for high ThreatScore values or create dashboards for continuous monitoring.

Query 5

index=sysmon EventCode=13
| eval TargetAccount = AccountName, 
        EncryptionType = case(
            Ticket_Encryption_Type == "0x17", "RC4",
            Ticket_Encryption_Type == "0x12", "AES",
            true(), Ticket_Encryption_Type
        ),
        RequestingHost = coalesce(WorkstationName, ComputerName)
| stats count AS RequestCount, values(RequestingHost) AS Hosts, dc(RequestingHost) AS UniqueHosts 
        BY TargetAccount, ServiceName, EncryptionType
| eval SuspiciousSPN = if(RequestCount > 10 AND UniqueHosts > 3, 1, 0)
| join type=left [
    search index=sysmon EventCode=4648
    | stats count AS AuthenticationAttempts, values(SourceProcessGUID) AS Processes 
      BY TargetAccount
    | eval RareTarget = if(AuthenticationAttempts < 5, 1, 0)
]
| eval ThreatScore = SuspiciousSPN + RareTarget
| where ThreatScore > 0
| table TargetAccount, ServiceName, EncryptionType, RequestCount, UniqueHosts, Hosts, AuthenticationAttempts, RareTarget, ThreatScore
| sort - ThreatScore
| search NOT [ | inputlookup known_sysmon_accounts.csv ]

Explanation of the Query:

1. Sysmon EventCode 13:

   • Focuses on Kerberos Service Ticket Request events logged by Sysmon.

2. Field Normalisation:

   • Maps and normalise fields for TargetAccount, EncryptionType, and RequestingHost.

3. Dynamic Encryption Detection:

   • Translates encryption codes into human-readable formats (RC4 and AES).

4. Activity Analysis:

   • Counts ticket requests (RequestCount) and identifies the number of unique requesting hosts (UniqueHosts).

   • Flags accounts as suspicious if they have a high request count and are accessed from multiple unique hosts.

5. Cross-Event Correlation:

   • Joins with Event ID 4648 (explicit logon attempts) to detect rare accounts with low activity.

6. Threat Scoring:

   • Calculates a ThreatScore based on suspicious SPN activity and rarity of the target account.

7. Filtering Safe Activity:

   • Uses a lookup table (known_sysmon_accounts.csv) to exclude known legitimate activity.

8. Output Table:

   • Provides a SOC-friendly view with details such as account, SPN, encryption type, request count, unique hosts, and threat score.

Thresholds and Recommendations:

• Adjust Thresholds: Fine-tune RequestCount > 10 and UniqueHosts > 3 to match your environment's baseline.

• Lookup Maintenance: Keep known_sysmon_accounts.csv up to date with legitimate SPN requests and accounts.

• Dashboard/Alert Integration: Create alerts for high ThreatScore values or visualise results in dashboards for ongoing monitoring.

Reference

• Microsoft Identity and Access documentation
• Detecting and mitigating Active Directory compromises
• Best Practices for Securing Active Directory
• Securing Domain Controllers Against Attack
• Top 25 Active Directory Security Best Practices
• Active Directory Security Best Practices