Domain Dominance Attacks - Detection & Analysis

What is Domain Dominance

Refers to a stage in an adversary’s attack lifecycle where they gain control over a network's Active Directory (AD) domain or significant portions of it. This is a critical phase because AD is the backbone of identity and access management in most enterprise environments. Controlling an AD domain allows attackers to elevate privileges, persist in the environment, and move laterally across the network undetected.

---

Key Objectives of Domain Dominance Attacks

1. Privilege Escalation:

   • Attackers escalate their privileges to domain or enterprise administrator levels.

2. Persistence:

   • The attacker ensures continued access to the network by creating backdoors, new accounts, or modifying AD policies.

3. Lateral Movement:

   • Gaining access to other systems and resources within the domain using compromised credentials or stolen Kerberos tickets.

4. Data Exfiltration or Destruction:

   • Gaining access to sensitive data or deploying ransomware.

---

Techniques Used

Attackers employ a variety of techniques to achieve Domain Dominance:

1. Credential Dumping:

   • Tools like Mimikatz extract credentials from memory or domain controllers.

2. Pass-the-Hash:

   • Using hashed credentials to authenticate without knowing the plaintext password.

3. Golden Ticket Attack:

   • Forging Kerberos tickets using the KRBTGT account hash.

4. Silver Ticket Attack:

   • Forging service-specific Kerberos tickets.

5. DCSync Attack:

   • Simulating a domain controller to replicate AD data, including password hashes.

6. DCShadow Attack:

   • Registering a rogue domain controller to manipulate AD objects covertly.

7. SID History Injection:

   • Modifying the Security Identifier (SID) history attribute of accounts for privilege escalation.

8. Kerberoasting:

   • Requesting service tickets to crack service account passwords offline.

---

Indicators of Domain Dominance Attacks

Detecting domain dominance attacks involves monitoring specific actions and anomalies in Active Directory logs:

• Unauthorised modifications to AD groups, policies, or schema.

• Unusual logon activities (e.g., from unexpected IPs or hosts).

• Requests for sensitive AD attributes or files (NTDS.dit, SYSVOL).

• Elevated usage of administrative privileges.

• Abnormal Kerberos ticket requests or renewals.

---

Implications

If an attacker achieves Domain Dominance:

1. They can impersonate any user or service in the environment.

2. They can disable or bypass security controls like endpoint detection and response (EDR).

3. They can exfiltrate sensitive data or launch further attacks, such as ransomware.

---

Mitigations

1. Secure Privileged Accounts:

   • Use multi-factor authentication (MFA) and limit administrative access.

2. Implement Least Privilege:

   • Minimise privileges for all accounts and services.

3. Active Directory Hardening:

   • Enable logging and auditing for critical AD activities.

   • Regularly monitor for unauthorised AD object changes.

4. Use Tiered Administration:

   • Separate high-privileged accounts from standard accounts.

5. Patch Vulnerabilities:

   • Regularly update systems to mitigate exploitation of known AD vulnerabilities.

---

Defending Against Domain Dominance Attacks

This requires a multifaceted approach combining detection techniques, proactive defence mechanisms, and specialised tools. Below is an exploration of specific detection methods and tools to mitigate the risks of domain dominance attacks.

---

1. Detection Techniques

1.1 Log Monitoring and Analysis

Monitoring Active Directory and system logs for anomalies is critical.

• Kerberos Events:

  • Monitor events like Event ID 4769 (Service Ticket Request) and Event ID 4770 (Ticket Granted Renewed).

  • Look for unusual requests involving krbtgt or other critical service accounts.

• Account Modification Events:

  • Track Event ID 4732 (Add to Privileged Group) and Event ID 4728 (Add to Global Group).

• Replication Events:

  • Monitor Event ID 4662 (Access to Directory Services Objects) for unusual replication activities.

1.2 Anomaly-Based Detection

Detect deviations from normal user behaviour using behavioural analytics:

• Unusual logon hours or from new geographic locations.

• Large numbers of requests for sensitive AD attributes.

• Abnormal Kerberos ticket lifetimes or encryption types.

1.3 Honey Tokens

Deploy fake AD accounts or objects (e.g., decoy service principal names) to detect unauthorised attempts:

• Monitor for access attempts on decoy accounts.

• Track service ticket requests for decoy SPNs (useful for Kerberoasting detection).

1.4 PowerShell and Script Logging

Enable PowerShell Script Block Logging to detect malicious AD commands:

• Commands like Get-ADUser, Get-ADGroup, or replication-related commands (e.g., Repadmin.exe).

---

2. Tools for Defence

2.1 Active Directory Monitoring Tools

Specialised tools for monitoring and defending AD environments:

• BloodHound Enterprise:

  • Graph-based analysis to identify AD misconfigurations and attack paths.

  • Highlights privilege escalation paths and vulnerable accounts.

• Purple Knight:

  • Scans AD environments for weaknesses, such as excessive privileges or delegation risks.

• ADAudit Plus:

  • Tracks real-time changes to AD objects, including group memberships, GPOs, and permissions.

2.2 SIEM Platforms

Use a Security Information and Event Management (SIEM) solution to aggregate logs, detect anomalies, and trigger alerts:

• Microsoft Sentinel:

  • Query-based detection for domain dominance techniques using KQL.

  • Integration with Azure AD for comprehensive monitoring.

• Splunk:

  • Use SPL queries for detailed analysis of AD-related logs.

2.3 Endpoint Detection and Response (EDR)

Deploy EDR solutions to detect lateral movement and credential theft:

• Microsoft Defender for Identity:

  • Detects DCSync, Pass-the-Hash, and other domain dominance techniques.

  • Provides real-time alerts for suspicious AD activities.

• CrowdStrike Falcon:

  • Monitors endpoint activity for credential dumping and ticket forgery attempts.

2.4 Threat Intelligence Platforms

Integrate IoC feeds and threat intelligence tools to detect known adversary tactics:

• ThreatConnect or Recorded Future:

  • Feeds for detecting IoCs associated with domain dominance tools like Mimikatz or Impacket.

---

3. Proactive Defence Strategies

3.1 Active Directory Hardening

• Disable unused accounts and services.

• Use Protected Users group to prevent credential theft for privileged accounts.

• Enforce strong password policies and use tools like LAPS (Local Administrator Password Solution).

3.2 Privilege Management

• Implement Tiered Administrative Model:

  • Separate high-privilege accounts from daily-use accounts.

  • Use jump servers for administrative access.

• Restrict Replication Rights:

  • Limit Replicating Directory Changes to only required accounts.

3.3 Multi-Factor Authentication (MFA)

Deploy MFA for all privileged accounts, including service accounts.

3.4 Network Segmentation

• Segment the network to limit lateral movement.

• Use firewalls or endpoint protection to restrict access to domain controllers.

3.5 Kerberos Configuration

• Set shorter Kerberos ticket lifetimes.

• Enable PAC (Privilege Attribute Certificate) validation.

---

4. Threat Hunting Examples

Note: Always test and evaluate queries, as not all will work in an environment and will depend on the log sources that are collected and monitored.

4.1 Kerberoasting Detection

Hunt for abnormal Kerberos ticket requests:

Defender/Sentinel

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType in ("0x12", "0x17")
| summarize count() by ClientAddress, ServiceName, bin(TimeGenerated, 1h)

Splunk

index=windows 
sourcetype=WinEventLog:Security
EventCode=4769
| eval is_suspicious=if((TicketEncryptionType!="0x12" AND TicketEncryptionType!="0x17") OR (ClientAddress!="<expected_IP_ranges>"), 1, 0)
| stats count by TimeGenerated, TargetUserName, ServiceName, TicketEncryptionType, ClientAddress, is_suspicious
| where is_suspicious=1
| table TimeGenerated, TargetUserName, ServiceName, TicketEncryptionType, ClientAddress
| sort - TimeGenerated

4.2 DCSync Detection

Hunt for directory replication service attempts:

Defender/Sentinel

SecurityEvent
| where EventID == 4662
| where Properties has "Replicating Directory Changes"
| summarize count() by SubjectUserName, TargetAccount, bin(TimeGenerated, 1h)

Splunk

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
ObjectServer=DS
| search Properties="Replicating Directory Changes" OR Properties="Replicating Directory Changes All"
| stats count by _time, SubjectAccountName, TargetObject, ObjectName, Properties
| rename SubjectAccountName as "AccountName", TargetObject as "Target", ObjectName as "ObjectAccessed"
| sort - _time

4.3 Abnormal Logons

Identify unexpected logon patterns:

Defender/Sentinel

SecurityEvent
| where EventID == 4624
| where LogonType in (2, 3) // Interactive or Network logon
| where AccountName !in ("<known service accounts>")
| summarize count() by IpAddress, AccountName, bin(TimeGenerated, 1h)

Splunk

index=windows 
sourcetype=WinEventLog:Security
EventCode=4624
| eval LogonTypeDescription=case(
    LogonType=="2", "Interactive",
    LogonType=="3", "Network",
    LogonType=="4", "Batch",
    LogonType=="5", "Service",
    LogonType=="7", "Unlock",
    LogonType=="8", "NetworkCleartext",
    LogonType=="9", "NewCredentials",
    LogonType=="10", "RemoteInteractive",
    LogonType=="11", "CachedInteractive",
    true(), "Other"
)
| eval IsSuspicious=if(
    (IpAddress!="<known_ip_range>" AND UserName!="<excluded_service_accounts>") OR 
    (LogonType=="10" AND IpAddress!="<expected_RDP_ip_ranges>") OR
    (Date_Wday NOT IN ("Monday", "Tuesday", "Wednesday", "Thursday", "Friday") AND Date_Hour NOT IN (9, 10, 11, 12, 13, 14, 15, 16)),
    "Yes", "No"
)
| where IsSuspicious="Yes"
| stats count by _time, UserName, IpAddress, WorkstationName, LogonTypeDescription
| sort - _time

---

Types of Domain Dominance Attacks and Detection Queries

Typically associated with adversaries attempting to gain control over an Active Directory (AD) domain to extend their influence and persist in a compromised environment. Below is an overview of some key techniques and how to detect them using KQL queries:

---

1. Credential Dumping

Note: Always test and evaluate queries, as not all will work in an environment and will depend on the log sources that are collected and monitored.

Adversaries dump credentials from domain controllers or other AD-related hosts using tools like Mimikatz or techniques such as DCSync.

Defender/Sentinel

SecurityEvent
| where EventID in (4662, 4672, 4723, 4738, 4740)
| where TargetObject contains "NTDS.dit" or ObjectClass == "directory service access"
| extend AccountUsed = iff(EventID == 4662, SubjectUserName, TargetUserName)
| summarize count() by EventID, AccountUsed, bin(TimeGenerated, 1h)

Splunk

1. Credential Dumping via LSASS

Detect suspicious access to the lsass.exe process:

index=windows
sourcetype=WinEventLog:Security
EventCode=4688
| where NewProcessName="C:\\Windows\\System32\\lsass.exe" OR ParentProcessName="C:\\Windows\\System32\\lsass.exe"
| stats count by _time, NewProcessName, ParentProcessName, ProcessId, SubjectUserName, SubjectLogonId
| rename NewProcessName as "Executed Process", ParentProcessName as "Parent Process"
| sort - _time

Key Indicators:

• Unusual processes spawning or accessing lsass.exe, such as Mimikatz or malicious scripts.

---

2. Credential Dumping via NTDS.dit Access

Detect access to the Active Directory database file (NTDS.dit):

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectName="C:\\Windows\\NTDS\\NTDS.dit"
| stats count by _time, SubjectUserName, AccessMask, ObjectName, ProcessName
| rename SubjectUserName as "Accessing Account", ObjectName as "Accessed Object", ProcessName as "Executing Process"
| sort - _time

Key Indicators:

• Unauthorized access to NTDS.dit using AccessMask values that indicate read or dump operations.

---

3. SAM Database Access

Detect unauthorised access to the Security Account Manager (SAM) database:

index=windows
sourcetype=WinEventLog:Security
EventCode=4663
| where ObjectName="C:\\Windows\\System32\\config\\SAM"
| stats count by _time, SubjectUserName, AccessMask, ObjectName, ProcessName
| rename SubjectUserName as "Accessing Account", ObjectName as "Accessed Object", ProcessName as "Executing Process"
| sort - _time

Key Indicators:

• Processes accessing C:\\Windows\\System32\\config\\SAM that are not part of routine system operations.

---

4. Tools like Mimikatz

Detect the use of suspicious tools known for credential dumping:

index=windows
sourcetype=WinEventLog:Security
EventCode=4688
| where NewProcessName IN ("C:\\Users\\*\\Desktop\\mimikatz.exe", "C:\\Windows\\Temp\\*")
| stats count by _time, NewProcessName, CommandLine, SubjectUserName, ParentProcessName
| rename NewProcessName as "Suspicious Process", CommandLine as "Executed Command"
| sort - _time

Key Indicators:

• Unusual processes like mimikatz.exe, or those spawned from temporary directories.

---

5. Unusual Dump File Creations

Detect suspicious file dumps, such as those created using the procdump tool:

index=windows
sourcetype=WinEventLog:Security
EventCode=4663
| where ObjectName matches ".*\\.dmp"
| stats count by _time, SubjectUserName, ObjectName, AccessMask, ProcessName
| rename SubjectUserName as "Accessing Account", ObjectName as "Dump File Created", ProcessName as "Executing Process"
| sort - _time

Key Indicators:

• Creation of .dmp files in suspicious directories, often indicative of credential dumping.

---

6. Suspicious DLL Loading

Detect malicious DLLs loaded for credential dumping:

index=windows
sourcetype=WinEventLog:Security
EventCode=7045
| where ImagePath IN ("C:\\Windows\\System32\\lsass.exe", "C:\\Windows\\System32\\samlib.dll")
| stats count by _time, ServiceName, ImagePath, SubjectUserName
| rename ServiceName as "Service", ImagePath as "DLL Path"
| sort - _time

7. Follow-Up Actions

1. Investigate Accessing Accounts:

   • Verify if the SubjectUserName is authorised for such actions.

2. Correlate with Other Logs:

   • Look for privilege escalation (EventCode=4672) or abnormal logons (EventCode=4624).

3. Alerting:

   • Set up Splunk alerts for these queries to notify the SOC of potential credential dumping.

2. DCSync Attack

Adversaries use the Replicating Directory Changes permission to retrieve credentials from domain controllers.

Defender/Sentinel

SecurityEvent
| where EventID == 4662
| where ObjectServer == "DS" and Properties has "Replicating Directory Changes"
| summarize count() by TargetAccount, SubjectUserName, bin(TimeGenerated, 1h)

Splunk

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND (Properties="Replicating Directory Changes" OR Properties="Replicating Directory Changes All")
| stats count by _time, SubjectAccountName, ObjectName, Properties, OperationType
| rename SubjectAccountName as "Account Performing Action", ObjectName as "Accessed Object", Properties as "Permissions Used", OperationType as "Action"
| sort - _time

---

Explanation of the Query

1. Filter by Event Code:

   • EventCode=4662: Indicates access to directory service objects.

2. Monitor Replication Permissions:

   • Look for the use of Replicating Directory Changes or Replicating Directory Changes All, which are necessary for AD replication and are often abused in DCSync attacks.

3. Aggregate and Analyse:

   • stats groups results by key attributes like the account performing the action, the object accessed, and the permissions used.

4. Sort Results:

   • Sort events by _time to display the most recent activities.

---

Enhanced Query with Anomalies

To refine the detection, include conditions for unexpected accounts and suspicious IP addresses:

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND (Properties="Replicating Directory Changes" OR Properties="Replicating Directory Changes All")
| eval IsSuspicious=if(AccountName!="<authorized_replication_account>" OR IpAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectAccountName, ObjectName, Properties, IpAddress
| rename SubjectAccountName as "Account Performing Action", ObjectName as "Accessed Object", Properties as "Permissions Used", IpAddress as "Source IP"
| sort - _time

---

Key Indicators of a DCSync Attack

1. Account Used:

   • Check if the account (SubjectAccountName) is authorized for replication activities. DCSync often abuses standard user accounts with elevated permissions.

2. Permissions:

   • Look for replication-specific permissions: Replicating Directory Changes and Replicating Directory Changes All.

3. Accessed Object:

   • Monitor for objects like CN=DomainDnsZones or sensitive AD attributes, such as msDS-KeyVersionNumber.

4. Source IP:

   • Verify if the request originates from a trusted domain controller or unexpected systems.

---

Follow-Up Actions

1. Investigate Accounts:

   • Confirm whether the SubjectAccountName belongs to legitimate replication accounts or privileged users.

2. Validate Source IP:

   • Check if the request originates from trusted domain controllers or anomalous systems.

3. Correlate with Other Events:

   • Look for associated authentication events (EventCode=4624) or privilege escalations (EventCode=4672).

4. Set Alerts:

   • Configure Splunk alerts for this query to notify your SOC in realtime.

---

3. Golden Ticket Attack

Attackers use stolen KRBTGT account credentials to forge Kerberos tickets.

Defender/Sentinel

SecurityEvent
| where EventID == 4769
| where ServiceName contains "krbtgt"
| extend IsSuspicious = ClientAddress !in ("<Known IP ranges>")
| summarize count() by ClientAddress, ServiceName, bin(TimeGenerated, 1h)

Splunk

index=windows
sourcetype=WinEventLog:Security
EventCode=4769
| where ServiceName="krbtgt"
| eval IsSuspicious=if(ClientAddress!="<trusted_ip_range>" OR TicketOptions="0x40810010" OR TicketEncryptionType!="0x12", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ServiceName, ClientAddress, TicketOptions, TicketEncryptionType
| rename SubjectUserName as "Requesting Account", ServiceName as "Service Name", ClientAddress as "Source IP", TicketOptions as "Ticket Flags", TicketEncryptionType as "Encryption Type"
| sort - _time

---

Explanation of the Query

1. Filter by Kerberos Service Ticket Requests:

   • EventCode=4769: Indicates a Kerberos service ticket request.

   • ServiceName="krbtgt": Focuses on requests involving the Kerberos Ticket Granting Service (krbtgt), often targeted in Golden Ticket attacks.

2. Evaluate Suspicious Patterns:

   • ClientAddress: Check if the source IP is outside <trusted_ip_range>.

   • TicketOptions="0x40810010": Common flag used in Golden Tickets.

   • TicketEncryptionType!="0x12": Indicates non-standard encryption types.

3. Highlight Suspicious Events:

   • Use eval to flag anomalies and filter suspicious events with where IsSuspicious="Yes".

4. Aggregate and Display Key Information:

   • stats groups results by time, requesting account, source IP, and ticket details.

---

Enhanced Query for Authentication Ticket Requests

Golden Tickets may also generate anomalies in TGT (Ticket Granting Ticket) requests (Event ID 4768):

index=windows
sourcetype=WinEventLog:Security
EventCode=4768
| where ServiceName="krbtgt"
| eval IsSuspicious=if(TicketEncryptionType!="0x12" OR ClientAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ServiceName, ClientAddress, TicketEncryptionType
| rename SubjectUserName as "Requesting Account", ServiceName as "Service Name", ClientAddress as "Source IP", TicketEncryptionType as "Encryption Type"
| sort - _time

---

Key Indicators of a Golden Ticket Attack

1. Unusual krbtgt Service Requests:

   • Multiple requests involving the krbtgt account.

2. Non-Standard Encryption Types:

   • Golden Tickets often use custom or unusual encryption types.

3. Abnormal Source IP:

   • Requests from unexpected systems or IP ranges.

4. Long-Lived Tickets:

   • Golden Tickets may have unusually long lifetimes.

---

Follow-Up Actions

1. Investigate Requesting Account:

   • Verify if the account is authorized to request tickets involving the krbtgt service.

2. Validate Source IP:

   • Confirm if the IP is within trusted ranges or corresponds to known systems.

3. Correlate with Other Events:

   • Check for abnormal logons (EventCode=4624) or privilege escalation (EventCode=4672).

4. Set Alerts:

   • Configure alerts to notify the SOC for any flagged events.

---

4. Silver Ticket Attack

Adversaries forge Kerberos tickets for services other than krbtgt.

Defender/Sentinel

SecurityEvent
| where EventID == 4769
| where ServiceName !contains "krbtgt"
| summarize count() by TargetAccount, ClientAddress, bin(TimeGenerated, 1h)

Splunk

Detect Silver Ticket Activity

index=windows
sourcetype=WinEventLog:Security
EventCode=4769
| where ServiceName!="krbtgt" AND (ServiceName="CIFS" OR ServiceName="HTTP" OR ServiceName="LDAP")
| eval IsSuspicious=if(ClientAddress!="<trusted_ip_range>" OR TicketEncryptionType!="0x12", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ServiceName, ClientAddress, TicketEncryptionType
| rename SubjectUserName as "Requesting Account", ServiceName as "Kerberos Service", ClientAddress as "Source IP", TicketEncryptionType as "Encryption Type"
| sort - _time

---

Explanation of the Query

1. Filter for Kerberos Service Ticket Requests:

   • EventCode=4769: Logs related to Kerberos service ticket requests.

   • ServiceName!="krbtgt": Exclude TGT-related requests (used in Golden Ticket attacks).

   • Focus on services often targeted by Silver Tickets, like CIFS, HTTP, or LDAP.

2. Identify Suspicious Patterns:

   • ClientAddress!="<trusted_ip_range>": Detect requests from unusual or external IP addresses.

   • TicketEncryptionType!="0x12": Non-standard Kerberos encryption types can indicate forged tickets.

3. Aggregate Suspicious Events:

   • Use stats to group results by key attributes like ServiceName and ClientAddress.

4. Display Key Details:

   • Rename fields for clarity, such as SubjectUserName (the account requesting the ticket) and ClientAddress (source IP).

---

Enhanced Query with Anomaly Detection

For environments with known patterns, use statistical baselines to detect anomalies:

index=windows
sourcetype=WinEventLog:Security
EventCode=4769
| where ServiceName!="krbtgt"
| stats count by SubjectUserName, ServiceName, ClientAddress, TicketEncryptionType
| eventstats avg(count) as avg_count, stdev(count) as stdev_count by ServiceName
| eval IsAnomalous=if(count > avg_count + (2 * stdev_count), "Yes", "No")
| where IsAnomalous="Yes"
| table _time, SubjectUserName, ServiceName, ClientAddress, count, avg_count, stdev_count, TicketEncryptionType

---

Indicators of a Silver Ticket Attack

1. Unusual Service Names:

   • Tickets for sensitive services (CIFS, HTTP, LDAP) not typically accessed by the detected account.

2. Anomalous Encryption Types:

   • Non-standard TicketEncryptionType values, especially those differing from your environment's norms (e.g., 0x12).

3. Suspicious Client Addresses:

   • Requests from IPs outside known ranges (ClientAddress not matching <trusted_ip_range>).

---

Follow-Up Actions

1. Investigate Requesting Accounts:

   • Verify if SubjectUserName is authorized to access the targeted service.

2. Validate Source IP Addresses:

   • Confirm whether ClientAddress originates from a legitimate host or unexpected location.

3. Correlate with Other Events:

   • Look for concurrent privilege escalations (EventCode=4672) or unusual logons (EventCode=4624).

4. Alerting and Automation:

   • Configure alerts for flagged events to notify SOC teams in realtime.

---

5. Pass-the-Hash (PtH)

Attackers use hashed credentials to authenticate without knowing the plaintext password.

Defender/Sentinel

SecurityEvent
| where EventID == 4624
| where LogonType == 3 and AuthenticationPackageName == "NTLM"
| summarize count() by TargetUserName, IpAddress, LogonType, bin(TimeGenerated, 1h)

Splunk

Detect Pass-the-Hash Activity

index=windows
sourcetype=WinEventLog:Security
EventCode=4624
| where LogonType=3 AND AuthenticationPackageName="NTLM"
| eval IsSuspicious=if(LogonType=3 AND AuthenticationPackageName="NTLM" AND (IpAddress!="<trusted_ip_range>" OR AccountName!="<known_service_accounts>"), "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, AccountName, IpAddress, WorkstationName, AuthenticationPackageName, LogonType
| rename AccountName as "Targeted Account", IpAddress as "Source IP", WorkstationName as "Destination Host", AuthenticationPackageName as "Auth Method", LogonType as "Logon Type"
| sort - _time

---

Explanation of the Query

1. Filter for Logon Events:

   • EventCode=4624: Indicates successful logons.

   • LogonType=3: Focus on network logons (often targeted by PtH attacks).

   • AuthenticationPackageName="NTLM": Identifies NTLM-based authentication.

2. Identify Suspicious Patterns:

   • Non-standard IpAddress: Detect requests from IPs outside <trusted_ip_range>.

   • Unusual AccountName: Flag accounts not in <known_service_accounts>.

3. Aggregate Suspicious Events:

   • Group results by time, account name, IP address, and destination host.

4. Display Key Details:

   • Provide a clear overview of Targeted Account, Source IP, and Auth Method.

---

Enhanced Query with High-Frequency Detection

Pass-the-Hash attacks often involve multiple logon attempts across different systems.

index=windows
sourcetype=WinEventLog:Security
EventCode=4624
| where LogonType=3 AND AuthenticationPackageName="NTLM"
| stats count by AccountName, IpAddress, WorkstationName
| where count > 10
| sort - count

---

Indicators of a Pass-the-Hash Attack

1. Unusual Accounts:

   • Use of privileged accounts like Administrator from unknown systems.

2. Unexpected IPs:

   • Requests originating from external or untrusted IP addresses.

3. High-Frequency Attempts:

   • Multiple NTLM-based authentication requests from the same IP or account within a short time.

---

Follow-Up Actions

1. Investigate Account Activity:

   • Confirm whether the Targeted Account is legitimate and authorized.

2. Validate Source IPs:

   • Check whether the Source IP belongs to known systems.

3. Correlate with Other Events:

   • Look for privilege escalation attempts (EventCode=4672) or unusual administrative activities.

4. Configure Alerts:

   • Set up alerts for flagged events to notify your SOC in realtime.

---

6. Pass-the-Ticket (PtT)

Adversaries use valid Kerberos tickets to authenticate to systems.

Defender/Sentinel

SecurityEvent
| where EventID == 4768
| where TicketEncryptionType in ("0x12", "0x17")
| extend IsSuspicious = IssuingServer !in ("<Known Kerberos Servers>")
| summarize count() by TicketEncryptionType, IssuingServer, bin(TimeGenerated, 1h)

Splunk

Query to Detect Pass-the-Ticket Activity

index=windows
sourcetype=WinEventLog:Security
EventCode=4769
| eval IsSuspicious=if((TicketEncryptionType!="0x12" AND TicketEncryptionType!="0x17") OR ClientAddress!="<trusted_ip_range>" OR AccountName!="<known_service_accounts>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ServiceName, TicketEncryptionType, ClientAddress, LogonGuid
| rename SubjectUserName as "Account", ServiceName as "Kerberos Service", TicketEncryptionType as "Encryption Type", ClientAddress as "Source IP"
| sort - _time

---

Explanation of the Query

1. Filter by Kerberos Service Ticket Requests:

   • EventCode=4769: Monitors for Kerberos service ticket (TGS) requests.

2. Identify Suspicious Patterns:

   • Non-standard encryption types (TicketEncryptionType not 0x12 or 0x17).

   • Requests from unexpected IPs (ClientAddress not in <trusted_ip_range>).

   • Anomalous accounts (AccountName not in <known_service_accounts>).

3. Aggregate Suspicious Events:

   • Use stats to group results by key attributes such as ServiceName, Encryption Type, and Source IP.

4. Display Key Details:

   • Show Account, Kerberos Service, Source IP, and encryption type.

---

Enhanced Query for TGT Requests

Pass-the-Ticket attacks might also exploit Ticket Granting Tickets (TGTs). Use the following query for monitoring TGT activity (EventCode=4768):

index=windows
sourcetype=WinEventLog:Security
EventCode=4768
| eval IsSuspicious=if(TicketEncryptionType!="0x12" OR ClientAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ServiceName, TicketEncryptionType, ClientAddress
| rename SubjectUserName as "Account", ServiceName as "Kerberos Service", TicketEncryptionType as "Encryption Type", ClientAddress as "Source IP"
| sort - _time

---

Indicators of Pass-the-Ticket Attacks

1. Unusual Ticket Encryption Types:

   • Common Kerberos encryption types are 0x12 (AES256) and 0x17 (AES128). Any deviation could indicate ticket forgery.

2. Suspicious Source IPs:

   • Requests originating from untrusted or external IP addresses.

3. Abnormal Accounts:

   • Privileged accounts (e.g., Administrator) used unexpectedly or from unauthorized hosts.

4. High-Frequency Events:

   • Multiple TGS or TGT requests in a short period.

---

Follow-Up Actions

1. Investigate Accounts:

   • Validate whether the SubjectUserName corresponds to authorized users or services.

2. Verify Source IPs:

   • Check if the ClientAddress belongs to trusted systems.

3. Correlate with Other Logs:

   • Look for associated logon events (EventCode=4624) or privilege escalation attempts (EventCode=4672).

4. Alerting:

   • Configure real-time alerts for flagged events to notify your SOC team.

7. DCShadow Attack

An attacker uses rogue domain controller replication to manipulate AD objects.

Defender/Sentinel

SecurityEvent
| where EventID == 4662
| where ObjectClass == "domainDNS" and Properties has "msDS-KeyVersionNumber"
| summarize count() by SubjectUserName, ObjectName, bin(TimeGenerated, 1h)

Splunk

Detect DCShadow Attack

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND (Properties="Replicating Directory Changes" OR Properties="Replicating Directory Changes All")
| eval IsSuspicious=if(AccountName!="<authorized_replication_account>" OR ClientAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, AccountName, ClientAddress, ObjectName, Properties
| rename SubjectUserName as "Performing Account", AccountName as "Target Account", ClientAddress as "Source IP", ObjectName as "Modified Object", Properties as "Replication Permissions"
| sort - _time

---

Explanation of the Query

1. Monitor Access to Directory Services Objects:

   • EventCode=4662: Captures directory replication activities.

2. Focus on Replication Permissions:

   • Detect use of replication-specific permissions such as:

     • Replicating Directory Changes

     • Replicating Directory Changes All

3. Evaluate Suspicious Patterns:

   • Flag events involving unexpected accounts (AccountName).

   • Identify source IPs outside the <trusted_ip_range>.

4. Aggregate Suspicious Events:

   • Use stats to group and display results by attributes like ObjectName and ClientAddress.

5. Display Key Details:

   • Present clear information about the Performing Account, Source IP, and Modified Object.

---

Enhanced Query for Shadow Domain Controller Registration

Detect potential shadow domain controllers by monitoring changes to the msDS-Behavior-Version attribute (schema version):

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND ObjectName="CN=Schema,CN=Configuration,DC=<your_domain>"
| eval IsSuspicious=if(Properties="msDS-Behavior-Version", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, ClientAddress, ObjectName, Properties
| rename SubjectUserName as "Performing Account", ClientAddress as "Source IP", ObjectName as "Modified Object", Properties as "Attribute Modified"
| sort - _time

---

Indicators of a DCShadow Attack

1. Unusual Accounts:

   • Unauthorized accounts attempting replication or schema changes.

2. Unexpected Source IPs:

   • Requests originating from systems that are not domain controllers.

3. Modification of Critical Attributes:

   • Changes to sensitive AD attributes like msDS-Behavior-Version, msDS-KeyVersionNumber, or AdminSDHolder.

---

Follow-Up Actions

1. Investigate Performing Accounts:

   • Verify whether the SubjectUserName is authorized to perform replication or schema changes.

2. Check Source IP:

   • Validate the ClientAddress against known domain controllers or trusted systems.

3. Correlate with Other Events:

   • Look for additional replication-related logs (EventCode=4662) or privilege escalations (EventCode=4672).

4. Set Alerts:

   • Configure Splunk alerts to notify SOC teams of any flagged events in realtime.

---

8. SID History Injection

Adversaries inject Security Identifier (SID) histories into accounts for privilege escalation.

Defender/Sentinel

SecurityEvent
| where EventID == 4670
| where Properties has "SIDHistory"
| summarize count() by TargetAccount, SubjectUserName, bin(TimeGenerated, 1h)

Splunk

Detect SID History Injection

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND Properties="SIDHistory"
| eval IsSuspicious=if(AccountName!="<trusted_admin_account>" OR ClientAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, AccountName, ClientAddress, ObjectName, Properties
| rename SubjectUserName as "Performing Account", AccountName as "Target Account", ClientAddress as "Source IP", ObjectName as "Modified Object", Properties as "Modified Attribute"
| sort - _time

---

Explanation of the Query

1. Monitor Access to Directory Services Objects:

   • EventCode=4662: Indicates access or changes to directory objects.

2. Focus on the SIDHistory Attribute:

   • The Properties="SIDHistory" filter specifically targets modifications to the SIDHistory attribute.

3. Evaluate Suspicious Patterns:

   • AccountName!="<trusted_admin_account>": Exclude authorized accounts such as domain administrators.

   • ClientAddress!="<trusted_ip_range>": Exclude requests from known or trusted IP ranges.

4. Aggregate Suspicious Events:

   • Use stats to group events by attributes such as ObjectName and ClientAddress.

5. Display Key Details:

   • Provide insights into the Performing Account, Target Account, and Modified Attribute.

---

Enhanced Query for Monitoring Attribute Changes

If you want to monitor additional sensitive attribute changes, extend the query to include attributes like AdminCount or PrimaryGroupID:

index=windows
sourcetype=WinEventLog:Security
EventCode=4662
| where ObjectServer=="DS" AND (Properties="SIDHistory" OR Properties="AdminCount" OR Properties="PrimaryGroupID")
| eval IsSuspicious=if(AccountName!="<trusted_admin_account>" OR ClientAddress!="<trusted_ip_range>", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, SubjectUserName, AccountName, ClientAddress, ObjectName, Properties
| rename SubjectUserName as "Performing Account", AccountName as "Target Account", ClientAddress as "Source IP", ObjectName as "Modified Object", Properties as "Modified Attribute"
| sort - _time

---

Indicators of SID History Injection

1. Unauthorised Accounts:

   • Use of non-admin or unexpected accounts to modify SIDHistory.

2. Suspicious IPs:

   • Modifications originating from systems outside your trusted domain controller or admin networks.

3. High-Frequency Changes:

   • Repeated changes to SIDHistory within a short time frame.

---

Follow-Up Actions

1. Investigate Performing Accounts:

   • Verify whether the Performing Account has legitimate access to modify SIDHistory.

2. Validate Source IP:

   • Confirm whether the Source IP corresponds to a trusted admin workstation or system.

3. Correlate with Other Events:

   • Look for privilege escalations (EventCode=4672) or unusual logons (EventCode=4624) related to the same account.

4. Set Alerts:

   • Configure alerts in Splunk to notify the SOC of any flagged SIDHistory modifications.

---

General Guidance

1. Enable Advanced Auditing: Ensure auditing is configured for sensitive AD activities, especially replication, credential access, and privilege escalation attempts.

2. Monitor Kerberos Events: Track unusual Kerberos ticket requests and errors.

3. Analyze Administrative Activity: Focus on changes to sensitive groups like Domain Admins and changes to KRBTGT accounts.

4. Threat Hunting: Regularly search for anomalies in your AD logs using the above KQL queries.

---

Automating the Detection

1. Set Up Detection Rules

Detection rules trigger alerts when specific patterns are detected. The following is an example of configuring a detection rule in Microsoft Sentinel.

Steps to Configure:

1. Navigate to Sentinel:

   • Go to Microsoft Sentinel in your Azure portal.

   • Select your workspace.

2. Create a New Analytics Rule:

   • Under the Configuration section, select Analytics.

   • Click + Create and choose Scheduled query rule.

3. Define the Rule Settings:

   • Name: Choose a descriptive name, e.g., "Detect DCSync Attack."

   • Description: Provide a detailed description of the attack being detected.

   • Severity: Assign a severity level (e.g., High for DCSync or Golden Ticket attacks).

   • Tactics and Techniques: Map the rule to MITRE ATT&CK tactics and techniques (e.g., TA0004: Privilege Escalation, T1003: Credential Dumping).

4. Paste the KQL Query:

   • Copy and paste one of the KQL queries from the previous sections.

   • Test the query to ensure it returns meaningful results.

5. Set Scheduling:

   • Choose how often the query should run (e.g., every 5 minutes, every hour).

   • Configure the lookback period for log analysis (e.g., Last 1 Hour).

6. Define Alerts:

   • Set thresholds for triggering an alert based on query results.

   • For instance, trigger an alert if the count exceeds 1 for specific Event IDs.

---

2. Create Automated Responses

Automated responses reduce manual effort in investigating and remediating the detection. Use Playbooks in Sentinel to orchestrate actions.

Example Playbook Actions:

1. Notify Analysts:

   • Send email or Teams notifications with details of the alert.

2. Block Threats:

   • Isolate compromised accounts or block IP addresses using Azure AD Conditional Access or firewall rules.

3. Enrich Alerts:

   • Use integrations with threat intelligence services to enrich IoCs.

---

3. Continuous Threat Hunting

Even with detection rules in place, periodic threat hunting ensures you catch what rules might miss.

Golden Ticket or Silver Ticket Attacks:

Defender/Sentinel

SecurityEvent
| where EventID in (4769, 4770)
| where ServiceName matches regex @"krbtgt|svc.*"
| where ClientAddress not in ("<Known IP ranges>")
| extend SuspiciousActivity = iff(ClientAddress != "<Expected Addresses>", "Yes", "No")
| summarize count(), min(TimeGenerated), max(TimeGenerated) by ClientAddress, ServiceName

Advanced KQL Query for Golden and Silver Ticket Attacks

SecurityEvent
| where EventID in (4768, 4769) // Kerberos Ticket Events
| extend EventDescription = case(
    EventID == 4768, "Kerberos TGT Request",
    EventID == 4769, "Kerberos Service Ticket Request",
    "Other")
| extend IsGoldenTicket = case(
    ServiceName == "krbtgt" and ClientAddress !in ("<Known IP ranges>"), "Yes", "No")
| extend IsSilverTicket = case(
    ServiceName != "krbtgt" and ServiceName in ("CIFS", "HTTP", "LDAP") and ClientAddress !in ("<Known IP ranges>"), "Yes", "No")
| extend SuspiciousActivity = case(
    IsGoldenTicket == "Yes" or IsSilverTicket == "Yes", "Yes", "No")
| summarize 
    TotalRequests = count(), 
    FirstSeen = min(TimeGenerated), 
    LastSeen = max(TimeGenerated),
    DistinctAccounts = dcount(TargetUserName),
    DistinctServices = dcount(ServiceName)
    by ClientAddress, ServiceName, SuspiciousActivity, IsGoldenTicket, IsSilverTicket
| where SuspiciousActivity == "Yes"
| sort by LastSeen desc

Splunk

index=windows
sourcetype=WinEventLog:Security
EventCode=4769
| where ServiceName="krbtgt"
| eval IsSuspicious=if(ClientAddress!="<trusted_ip_range>" OR TicketOptions="0x40810010" OR TicketEncryptionType!="0x12", "Yes", "No")
| where IsSuspicious="Yes"
| stats count by _time, ServiceName, ClientAddress, TargetUserName, TicketEncryptionType, TicketOptions
| rename ServiceName as "Kerberos Service", ClientAddress as "Source IP", TargetUserName as "Account Targeted"
| sort - _time

---

4. Configure Dashboards

Create a dashboard in Sentinel to visualize detection metrics and patterns for Domain Dominance attacks.

Suggested Widgets:

• Event Trends: Display a timeline of detections for each attack type.

• Top Targeted Accounts: Show frequently targeted accounts (e.g., Admins, KRBTGT).

• Suspicious IP Addresses: Highlight unusual IPs from Kerberos authentication logs.

---

5. Testing and Tuning

Regularly test the rules by simulating attacks using tools like:

• Mimikatz: To test credential dumping detections.

• BloodHound: For identifying DCSync-like activities.

• Kerberoasting Scripts: To test Kerberos-related rules.