Windows AD Attack Investigation – Velociraptor Cheatsheet
DFIR Cheatsheet
Table of Contents
Investigation Workflow
Initial Triage
Credential Attacks
Kerberos Attacks
Privilege Escalation
Lateral Movement
Persistence Mechanisms
Domain Controller Attacks
Golden/Silver Ticket Detection
Data Exfiltration
Investigation Workflow
Phase 1: Scope Definition
Identify compromised accounts/systems
Determine attack timeline
Define investigation scope (hosts, domain controllers, time range)
Phase 2: Data Collection
Deploy Velociraptor agents to target systems
Execute targeted artifact collection
Preserve evidence integrity
Phase 3: Analysis
Analyse collected artifacts
Correlate events across systems
Build attack timeline
Phase 4: Containment & Remediation
Document findings
Implement containment measures
Provide remediation recommendations
Initial Triage
Check System Status and Connections
Collect Windows Event Logs
Rapid Host Survey
Credential Attacks
Detect LSASS Access (Credential Dumping)
Artifacts to Use:
Windows.EventLogs.EvtxHunterWindows.Detection.ProcessCreationWindows.Memory.AcquisitionWindows.System.Handles
What to Look For:
Process Access to LSASS - Event ID 4656 showing processes opening handles to lsass.exe
Known Tool Names - Mimikatz, procdump, dumpert, pypykatz, comsvcs.dll
Suspicious Parent Processes - cmd.exe, powershell.exe spawning memory dump tools
Living-off-the-land - rundll32.exe calling comsvcs.dll (native Windows DLL for dumps)
Handle Count Anomalies - Unusual processes with handles to lsass.exe
Analysis Steps:
Check Security.evtx for Event ID 4656 targeting lsass.exe
Correlate with Event ID 4688 (process creation) to identify the attacking process
Look for crash dump files in unusual locations (not C:\Windows\Minidump)
Check for base64 encoded commands in PowerShell logs
Examine process command lines for
-ma lsass.exeor similar dump flagsVerify legitimacy - Some admin tools legitimately access LSASS (backup software, AV)
Red Flags:
Multiple failed LSASS access attempts followed by success
LSASS access from user workstations (rare in normal operations)
Process spawned from Office applications accessing LSASS
Recent file modifications in Temp folders with .dmp extension
Remote process creation followed immediately by LSASS access
Detect DCSync Attacks
Artifacts to Use:
Windows.EventLogs.EvtxHunter(on Domain Controllers)Windows.EventLogs.AlternateLogonWindows.System.UsersWindows.Forensics.Timeline
What to Look For:
Event ID 4662 - Directory Service Access with specific GUID properties
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2- DS-Replication-Get-Changes1131f6ad-9c07-11d1-f79f-00c04fc2dcd2- DS-Replication-Get-Changes-All89e95b76-444d-4c62-991a-0facbeda640c- DS-Replication-Get-Changes-In-Filtered-Set
Non-DC Sources - Replication requests from workstations/member servers
Tool Artifacts - Mimikatz DCSync module, Invoke-Mimikatz, secretsdump.py
Unusual User Accounts - Service accounts or standard users performing replication
Analysis Steps:
Check Source Host - Is it a legitimate Domain Controller? Query DC list from AD
Review User Context - Does this account normally perform replication operations?
Check Timing - Multiple replication requests in short timeframe = bulk dumping
Correlate with Network - Look for large data transfers to external IPs after replication
Review Account Privileges - Verify if account has "Replicating Directory Changes" permission
Check for Tool Execution - Look for PowerShell scripts, Python processes on the source
Red Flags:
Workstation hostname in SubjectMachineName field
Service account triggering replication outside maintenance windows
Replication requests for krbtgt account specifically
Multiple object types replicated in succession (users, computers, groups)
Replication followed by logoff and network disconnect
User account that shouldn't have replication rights performing DCSync
Legitimate vs Malicious:
Legitimate: DC-to-DC replication, scheduled backups, Azure AD Connect
Malicious: Single workstation, manual user context, after-hours, high volume
Password Spraying Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunterWindows.EventLogs.FailedLogonsCustom.Windows.EventLogs.PasswordSpray(create custom artifact)Windows.Network.NetstatEnriched
What to Look For:
Event ID 4625 - Failed logon attempts
Low Volume per Account - 1-3 attempts per username (staying below lockout threshold)
High Account Count - Many different usernames from same source IP
Time Clustering - Failed attempts within short time windows (5-30 minutes)
Common Passwords - Sequential testing of weak passwords (Password123!, Summer2024!)
Source Patterns - Single IP or small IP range targeting many accounts
Analysis Steps:
Aggregate by Source IP - Count unique usernames per source IP
Check Failure Rate - Look for 1-3 failures per account (below lockout threshold)
Examine Time Distribution - Spray attacks often occur in waves
Review Targeted Accounts - Random user accounts vs. privileged accounts
Check Logon Types - Type 3 (network) or Type 8 (NetworkClearText) common for sprays
Correlate Success - Did any accounts succeed? (Event ID 4624)
Review Source Location - Internal IP, external VPN, cloud services?
Red Flags:
50+ unique usernames from single IP within 1 hour
Failed attempts for disabled accounts (attacker doesn't know account status)
Alphabetical username pattern (attacker enumerated user list)
Failed attempts during off-hours (2 AM - 5 AM)
Source IP with no successful authentications ever
Attempts against service accounts that shouldn't authenticate interactively
Legitimate vs Malicious:
Legitimate: Help desk password resets, user typos (usually same user repeatedly)
Malicious: Many users, few attempts each, regular timing patterns
Thresholds to Set:
Low Confidence: 10+ accounts, 1-2 failures each, within 1 hour
Medium Confidence: 30+ accounts, 1-3 failures each, within 30 minutes
High Confidence: 50+ accounts, consistent timing, includes disabled accounts
AS-REP Roasting Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunter(on Domain Controllers)Windows.EventLogs.KerberosWindows.System.Users(check for accounts with pre-auth disabled)Windows.Detection.ProcessCreation
What to Look For:
Event ID 4768 - Kerberos TGT request with PreAuthType = 0 (no pre-authentication)
RC4 Encryption - TicketEncryptionType = 0x17 (weak encryption, easier to crack)
Account Enumeration Pattern - Sequential requests for multiple user accounts
Tool Signatures - Rubeus.exe, GetNPUsers.py (Impacket), PowerView commands
Unusual Source IPs - Non-standard workstations requesting TGTs
Analysis Steps:
BehaviourIdentify Vulnerable Accounts - Which accounts have "Do not require Kerberos preauthentication" set?
Baseline Normal Behaviour - Do these accounts normally authenticate? From where?
Check Request Volume - Single account or bulk enumeration?
Review Encryption Type - RC4 (0x17) indicates potential offline cracking target
Correlate with Process Creation - Look for Rubeus, PowerShell scripts on source host
Check Timing - After-hours requests more suspicious
Follow-up Activity - Did successful authentication occur later? (compromised password)
Red Flags:
Multiple user accounts queried in short timeframe (enumeration)
Requests from workstation that shouldn't perform authentication operations
PreAuthType = 0 for accounts that normally use pre-authentication
RC4 encryption requested when AES should be default
Requests followed by unusual authentication patterns days/weeks later
Service accounts with pre-auth disabled being targeted
Legitimate vs Malicious:
Legitimate: Some legacy applications require pre-auth disabled (rare)
Malicious: Bulk account queries, tools like Rubeus in command line, off-hours
Account Configuration Check:
powershell
Post-Exploitation Indicators:
Look for password changes on targeted accounts (attacker succeeded in cracking)
Unusual authentication patterns from targeted accounts after AS-REP roasting
New service principal names (SPNs) added to roasted accounts
Kerberos Attacks
Kerberoasting Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunter(on Domain Controllers)Windows.EventLogs.KerberosWindows.Detection.ProcessCreationWindows.Forensics.Timeline
What to Look For:
Event ID 4769 - Service ticket (TGS) requests with RC4 encryption (0x17)
High Volume Requests - Single user requesting tickets for many SPNs
Service Name Patterns - Non-standard services, SQL, HTTP, MSSQL SPNs
Tool Artifacts - Rubeus.exe, Invoke-Kerberoast, GetUserSPNs.py commands
Ticket Options - Look for 0x40810000 (forwardable, renewable flags)
Encryption Downgrade - RC4 when AES should be standard
Analysis Steps:
Identify Service Accounts - Which accounts have SPNs registered?
Baseline Ticket Requests - Normal users don't request tickets for many services
Check Request Pattern - 10+ service tickets in short timeframe = enumeration
Review Encryption Type - RC4 (0x17) makes offline cracking easier
Correlate with Account Activity - Check for subsequent authentication with cracked password
Examine Source Workstation - Look for offensive security tools
Timeline Analysis - Map service ticket requests to later suspicious activity
Red Flags:
Single user account requesting 10+ different service tickets within minutes
Service tickets requested for accounts that user doesn't normally access
RC4 encryption when domain policy requires AES
Ticket requests from developer/contractor accounts (common targets)
Requests for high-value SPNs (SQL servers, web services, admin accounts)
PowerShell process with Base64 commands around same timeframe
Service tickets requested but services never actually accessed
Legitimate vs Malicious:
Legitimate: Users accessing services they use (1-3 tickets), AES encryption
Malicious: Bulk requests, RC4 encryption, no actual service connection after
High-Value SPN Targets:
SQL Server accounts (MSSQL/hostname)
IIS web services (HTTP/hostname)
Exchange servers
Custom application service accounts
Accounts with AdminSDHolder protection
Post-Kerberoasting Indicators:
Password changes on service accounts shortly after roasting
Unusual authentication patterns from previously roasted accounts
New SPNs registered (attacker maintaining access)
Service account used for lateral movement
Golden Ticket Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunter(on Domain Controllers)Windows.EventLogs.KerberosWindows.Forensics.TimelineWindows.Registry.NTUser(check for cached tickets)
What to Look For:
Event ID 4768 - TGT requests with unusual characteristics
Anomalous Ticket Lifetime - Tickets valid for 10+ years (max allowed)
Encryption Downgrade - RC4 when AES is domain standard
Missing User Context - TGS (4769) without corresponding TGT (4768)
Impossible Timestamps - Ticket start dates in the past or far future
Privileged Account Activity - Domain Admin accounts authenticating from unusual locations
Ticket Renewal Patterns - Tickets that never expire or renew abnormally
Analysis Steps:
Check krbtgt Password History - When was it last changed? Golden tickets persist until password changed twice
Analyse TGT Characteristics - Look for tickets with 10-year lifetime (common Mimikatz default)
Review Ticket Timeline - Correlate TGT (4768) with TGS (4769) - should be sequential
Examine Encryption Type - Golden tickets often use RC4 for compatibility
Check Account Status - Is the authenticating account disabled? Golden ticket still works
Source IP Analysis - Does source IP match user's typical location?
Privilege Level - Are standard users suddenly accessing Domain Admin resources?
Red Flags:
TGT with StartTime before domain creation date
Ticket lifetime > 10 hours (default is 10 hours)
Event ID 4769 (service ticket) without prior Event ID 4768 (TGT)
Disabled account successfully authenticating
Account authenticating from multiple IPs simultaneously (ticket reuse)
TGT with TicketEncryptionType = 0x17 when domain uses AES
Administrator account from workstation IP (not typical admin workstation)
Authentication outside normal business hours for typically 9-5 accounts
Legitimate vs Malicious:
Legitimate: Standard ticket lifetime, AES encryption, normal user behaviour
Malicious: Extended lifetime, RC4 encryption, disabled accounts authenticating
Critical Checks:
krbtgt Account Status - Check last password change
powershell
Ticket Characteristics - Look for tickets with these anomalies:
TicketLifetime > 10 hours
RC4 encryption (0x17)
StartTime inconsistencies
Detection Strategies:
Orphaned TGS: Service tickets without TGT requests
Temporal Anomalies: Tickets used before they were issued
Account Anomalies: Disabled/deleted accounts still authenticating
Encryption Mismatches: Domain requires AES but ticket uses RC4
Post-Detection Actions:
Reset krbtgt password twice (requires 2 resets to invalidate all tickets)
Review all administrative account activity during suspected timeframe
Force password resets for compromised accounts
Audit Domain Admin group membership changes
Silver Ticket Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunterWindows.EventLogs.KerberosWindows.System.ServicesWindows.Network.NetstatEnriched
What to Look For:
Event ID 4769 - Service ticket requests with anomalous characteristics
Missing TGT Request - Service ticket without corresponding TGT (Event ID 4768)
Encryption Downgrade - RC4 (0x17) for service tickets
Ticket Options - Look for 0x40810000 or 0x40810010 flags
Service Account Compromise - Tickets for specific services (CIFS, HTTP, MSSQL, LDAP)
Direct Service Access - Access to resources without going through normal authentication flow
Analysis Steps:
Identify Target Service - Which service is being accessed? (CIFS for file shares, HTTP for web)
Check TGT Existence - Was there a TGT request before this service ticket?
Review Service Account - Does the service account hash appear compromised?
Analyse Access Pattern - Is this user's normal behaviour for accessing this service?
Check Ticket Lifetime - Silver tickets may have extended lifetimes
Correlate Network Activity - Is actual service traffic matching the ticket requests?
Examine Source Location - Does source IP match user's typical location?
Red Flags:
Event ID 4769 without prior Event ID 4768 from same user/IP
Service ticket encryption type RC4 when service supports AES
Service ticket requested but no actual service connection logged
Multiple different services accessed with silver tickets (indicates multiple service account compromises)
Service tickets for accounts that shouldn't access those services
Tickets with TicketOptions = 0x40810000 (forwardable + renewable)
Access to administrative shares (CIFS/server$) from non-admin accounts
Legitimate vs Malicious:
Legitimate: Normal ticket flow (TGT → TGS), AES encryption, expected service access
Malicious: TGS without TGT, RC4 encryption, unusual service access patterns
Service-Specific Indicators:
CIFS (File Share Access):
Look for Event ID 5140 (share access) matching ticket requests
Check if accessed shares align with user's job function
HTTP (Web Services):
Review IIS logs for actual web requests
Correlate with ticket request timing
MSSQL (Database):
Check SQL Server logs for authentication
Verify if user typically accesses this database
LDAP (Directory Services):
Review for unusual LDAP queries
Check for directory enumeration activity
Detection Strategies:
Orphaned Service Tickets - Service tickets without TGT
Service Account Monitoring - Track all service account password changes
Encryption Baseline - Identify services using RC4 vs AES
Access Patterns - Baseline normal service access per user
Post-Detection Actions:
Reset password for compromised service account
Review all authentication using that service account
Check for lateral movement from systems accessed via silver ticket
Audit service account permissions (principle of least privilege)
Privilege Escalation
Token Manipulation Detection
Detect Exploitation Frameworks
Lateral Movement
Pass-the-Hash Detection
Artifacts to Use:
Windows.EventLogs.EvtxHunterWindows.EventLogs.RDPAuthWindows.EventLogs.AlternateLogonWindows.System.UsersWindows.Network.NetstatEnriched
What to Look For:
Event ID 4624 Type 3 - Network logon using NTLM authentication
NTLM Authentication - AuthenticationPackageName = "NTLM" (not Kerberos)
Privileged Accounts - Local Administrator or Domain Admin accounts
Logon from Unusual Sources - IPs/hostnames not typically used by that account
Lateral Movement Pattern - Sequential logins across multiple systems
Workstation Name Anomalies - Hostname doesn't match user's assigned system
Analysis Steps:
Identify Logon Type - Type 3 = Network logon (SMB, WMI, etc.)
Check Authentication Package - NTLM indicates hash-based authentication
Review Account Type - Built-in Administrator or domain privileged accounts
Analyse Source IP - Cross-reference with DHCP/asset inventory
Check Logon Frequency - Multiple systems in short timeframe = lateral movement
Correlate with Process Creation - Look for remote execution tools (psexec, wmic)
Review Destination Systems - What systems are being targeted?
Red Flags:
Local Administrator account authenticating via network (Type 3) with NTLM
Same account authenticating to 5+ systems within 30 minutes
Account authenticating from IP it has never used before
LogonType = 3 with NTLM from non-Domain Controller
Computer account (ending in $) authenticating to other workstations
Authentication pattern: Workstation A → Workstation B → Workstation C (pivoting)
Built-in RID 500 Administrator account (should be disabled)
Legitimate vs Malicious:
Legitimate: Service accounts using NTLM, scheduled tasks, administrative scripts with Kerberos
Malicious: Interactive admin accounts using NTLM Type 3, rapid multi-host authentication
Key Fields to Analyse:
TargetUserName: Which account is being used?
WorkstationName: Source hostname
IpAddress: Source IP (often shows as "-" for local subnet)
LogonType: Type 3 = network, Type 9 = NewCredentials, Type 10 = RemoteInteractive
AuthenticationPackageName: NTLM (suspicious) vs Kerberos (normal)
LogonProcessName: Should be "NtLmSsp" for Pass-the-Hash
Detection Patterns:
Rapid Lateral Spread:
Privilege Escalation:
Standard user account suddenly authenticating as local admin
Domain user becoming local admin on multiple systems
Correlate with Other Artifacts:
Event ID 4672 - Special privileges assigned (admin rights)
Event ID 4688 - Process creation (psexec, wmic, powershell)
Event ID 5140 - Network share accessed (ADMIN,C, C ,C, IPC$)
Event ID 5145 - Detailed file share access
Tools Commonly Using Pass-the-Hash:
Mimikatz (sekurlsa::pth)
Impacket (psexec.py, wmiexec.py, smbexec.py)
CrackMapExec
Metasploit (psexec module)
PowerShell Empire
Cobalt Strike
Pass-the-Ticket Detection
Remote Execution Detection
SMB Lateral Movement
Persistence Mechanisms
Scheduled Tasks
Service Creation
Registry Persistence
WMI Persistence
Account Manipulation
Domain Controller Attacks
NTDS.dit Extraction Detection
DCShadow Detection
Skeleton Key Detection
Golden/Silver Ticket Detection
Comprehensive Ticket Analysis
Cross-Reference Ticket Activity
Data Exfiltration
Large Data Transfers
DNS Tunnelling Detection
Cloud Service Uploads
Hunt Queries
Generic Threat Hunting
Timeline Analysis
Response Actions
Isolation and Containment
Evidence Collection
Hunt Deployment Strategies
Key Event IDs Reference
Authentication Events
4624 - Successful logon
4625 - Failed logon
4634 - Logoff
4647 - User initiated logoff
4648 - Logon with explicit credentials
4672 - Special privileges assigned
4768 - Kerberos TGT requested
4769 - Kerberos service ticket requested
4771 - Kerberos pre-authentication failed
4776 - Domain controller authentication attempt
Account Management
4720 - User account created
4722 - User account enabled
4724 - Password reset attempt
4732 - Member added to security-enabled local group
4733 - Member removed from security-enabled local group
4756 - Member added to security-enabled universal group
Object Access
4656 - Handle to object requested
4663 - Attempt to access object
4662 - Operation performed on Active Directory object
System Events
7045 - New service installed
7036 - Service state change
7040 - Service startup type changed
Tips and Best Practices
Investigation Tips
Always establish a timeline - Use multiple event sources
Correlate across systems - Single host view may miss lateral movement
Check Domain Controllers first - They hold the most critical evidence
Look for cleanup activities - Attackers often try to cover tracks
Document everything - Chain of custody is critical
VQL Optimization
Use
WHEREclauses early to filter dataLimit time ranges when possible
Use
LIMITfor initial testingIndex frequently queried fields
Cache results of expensive queries using
LET
Common Mistakes to Avoid
Don't rely solely on single indicators
Don't ignore false positives without investigation
Don't forget to check for persistence mechanisms
Don't overlook legitimate admin activity
Don't modify evidence without proper documentation
Performance Considerations
Additional Resources
Velociraptor Built-in Artifacts
Windows.EventLogs.EvtxHunter- Hunt for specific event IDsWindows.Detection.Yara.Process- YARA scanningWindows.Forensics.Timeline- Comprehensive timelineWindows.System.Amcache- Execution historyWindows.Forensics.Usn- USN Journal analysisWindows.Registry.NTUser- User registry analysis
Log Locations
Note: Always test queries in a non-production environment first. Adjust time ranges, filters, and thresholds based on your specific environment and baseline.
Last updated