Try in Splunk Security Cloud

Description

The following analytic identifies potential Kerberos ticket forging attacks, specifically the Diamond Ticket attack. This is detected when a user logs into a host and the GroupMembership field in event 4627 indicates a privileged group (e.g., Domain Admins), but the user does not actually belong to that group in the directory service. The detection leverages Windows Security Event Log 4627, which logs account logon events. The analytic cross-references the GroupMembership field from the event against a pre-populated lookup of actual group memberships. Its crucial to note that the accuracy and effectiveness of this detection heavily rely on the users diligence in populating and regularly updating this lookup table. Any discrepancies between the events GroupMembership and the lookup indicate potential ticket forging. Kerberos ticket forging, especially the Diamond Ticket attack, allows attackers to impersonate any user and potentially gain unauthorized access to resources. By forging a ticket that indicates membership in a privileged group, an attacker can bypass security controls and gain elevated privileges. Detecting such discrepancies in group memberships during logon events can be a strong indicator of this attack in progress, making it crucial for security teams to monitor and investigate. If validated as a true positive, this indicates that an attacker has successfully forged a Kerberos ticket and may have gained unauthorized access to critical resources, potentially with elevated privileges.

  • Type: TTP
  • Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud

  • Last Updated: 2023-10-06
  • Author: Mauricio Velazco, Splunk
  • ID: 10381f93-6d38-470a-9c30-d25478e3bd3f

Annotations

ATT&CK

ATT&CK

ID Technique Tactic
T1558 Steal or Forge Kerberos Tickets Credential Access
Kill Chain Phase
  • Exploitation
NIST
  • DE.CM
CIS20
  • CIS 10
CVE
1
2
3
4
5
6
7
 `wineventlog_security`  EventCode=4627 LogonType=3 NOT TargetUserName IN ("*$", "SYSTEM", "DWM-*","LOCAL SERVICE","NETWORK SERVICE", "ANONYMOUS LOGON", "UMFD-*") 
| where match(GroupMembership, "Domain Admins") 
| lookup domain_admins username as TargetUserName OUTPUT username 
| fillnull value=NotDA username 
| search username = "NotDA" 
| stats  count by _time, TargetUserName, GroupMembership, host 
| `windows_domain_admin_impersonation_indicator_filter`

Macros

The SPL above uses the following Macros:

:information_source: windows_domain_admin_impersonation_indicator_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

Lookups

The SPL above uses the following Lookups:

Required fields

List of fields required to use this analytic.

  • _time,
  • EventCode
  • LogonType
  • TargetUserName
  • GroupMembership

How To Implement

To successfully implement this search, you need to be ingesting Authentication events across all endpoints and ingest Event Id 4627. Specifically, the Audit Group Membership subcategory within the Logon Logooff category needs to be enabled. Its crucial to note that the accuracy and effectiveness of this detection heavily rely on the users diligence in populating and regularly updating this lookup table.

Known False Positives

False positives may trigger the detections certain scenarios like directory service delays or out of date lookups. Filter as needed.

Associated Analytic Story

RBA

Risk Score Impact Confidence Message
80.0 80 100 $TargetUserName$ may be impersonating a Domain Administrator through a forged Kerberos ticket.

:information_source: The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

Reference

Test Dataset

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

source | version: 1