Windows AD Attack Investigation – Velociraptor Cheatsheet

DFIR Cheatsheet

Table of Contents

  1. Investigation Workflow

  2. Initial Triage

  3. Credential Attacks

  4. Kerberos Attacks

  5. Privilege Escalation

  6. Lateral Movement

  7. Persistence Mechanisms

  8. Domain Controller Attacks

  9. Golden/Silver Ticket Detection

  10. Data Exfiltration


Investigation Workflow

Phase 1: Scope Definition

  1. Identify compromised accounts/systems

  2. Determine attack timeline

  3. Define investigation scope (hosts, domain controllers, time range)

Phase 2: Data Collection

  1. Deploy Velociraptor agents to target systems

  2. Execute targeted artifact collection

  3. Preserve evidence integrity

Phase 3: Analysis

  1. Analyse collected artifacts

  2. Correlate events across systems

  3. Build attack timeline

Phase 4: Containment & Remediation

  1. Document findings

  2. Implement containment measures

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

  • Windows.Detection.ProcessCreation

  • Windows.Memory.Acquisition

  • Windows.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:

  1. Check Security.evtx for Event ID 4656 targeting lsass.exe

  2. Correlate with Event ID 4688 (process creation) to identify the attacking process

  3. Look for crash dump files in unusual locations (not C:\Windows\Minidump)

  4. Check for base64 encoded commands in PowerShell logs

  5. Examine process command lines for -ma lsass.exe or similar dump flags

  6. Verify 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.AlternateLogon

  • Windows.System.Users

  • Windows.Forensics.Timeline

What to Look For:

  • Event ID 4662 - Directory Service Access with specific GUID properties

    • 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 - DS-Replication-Get-Changes

    • 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 - DS-Replication-Get-Changes-All

    • 89e95b76-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:

  1. Check Source Host - Is it a legitimate Domain Controller? Query DC list from AD

  2. Review User Context - Does this account normally perform replication operations?

  3. Check Timing - Multiple replication requests in short timeframe = bulk dumping

  4. Correlate with Network - Look for large data transfers to external IPs after replication

  5. Review Account Privileges - Verify if account has "Replicating Directory Changes" permission

  6. 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.EvtxHunter

  • Windows.EventLogs.FailedLogons

  • Custom.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:

  1. Aggregate by Source IP - Count unique usernames per source IP

  2. Check Failure Rate - Look for 1-3 failures per account (below lockout threshold)

  3. Examine Time Distribution - Spray attacks often occur in waves

  4. Review Targeted Accounts - Random user accounts vs. privileged accounts

  5. Check Logon Types - Type 3 (network) or Type 8 (NetworkClearText) common for sprays

  6. Correlate Success - Did any accounts succeed? (Event ID 4624)

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

  • Windows.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:

  1. BehaviourIdentify Vulnerable Accounts - Which accounts have "Do not require Kerberos preauthentication" set?

  2. Baseline Normal Behaviour - Do these accounts normally authenticate? From where?

  3. Check Request Volume - Single account or bulk enumeration?

  4. Review Encryption Type - RC4 (0x17) indicates potential offline cracking target

  5. Correlate with Process Creation - Look for Rubeus, PowerShell scripts on source host

  6. Check Timing - After-hours requests more suspicious

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

  • Windows.Detection.ProcessCreation

  • Windows.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:

  1. Identify Service Accounts - Which accounts have SPNs registered?

  2. Baseline Ticket Requests - Normal users don't request tickets for many services

  3. Check Request Pattern - 10+ service tickets in short timeframe = enumeration

  4. Review Encryption Type - RC4 (0x17) makes offline cracking easier

  5. Correlate with Account Activity - Check for subsequent authentication with cracked password

  6. Examine Source Workstation - Look for offensive security tools

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

  • Windows.Forensics.Timeline

  • Windows.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:

  1. Check krbtgt Password History - When was it last changed? Golden tickets persist until password changed twice

  2. Analyse TGT Characteristics - Look for tickets with 10-year lifetime (common Mimikatz default)

  3. Review Ticket Timeline - Correlate TGT (4768) with TGS (4769) - should be sequential

  4. Examine Encryption Type - Golden tickets often use RC4 for compatibility

  5. Check Account Status - Is the authenticating account disabled? Golden ticket still works

  6. Source IP Analysis - Does source IP match user's typical location?

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

  1. krbtgt Account Status - Check last password change

powershell

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

  1. Reset krbtgt password twice (requires 2 resets to invalidate all tickets)

  2. Review all administrative account activity during suspected timeframe

  3. Force password resets for compromised accounts

  4. Audit Domain Admin group membership changes

Silver Ticket Detection

Artifacts to Use:

  • Windows.EventLogs.EvtxHunter

  • Windows.EventLogs.Kerberos

  • Windows.System.Services

  • Windows.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:

  1. Identify Target Service - Which service is being accessed? (CIFS for file shares, HTTP for web)

  2. Check TGT Existence - Was there a TGT request before this service ticket?

  3. Review Service Account - Does the service account hash appear compromised?

  4. Analyse Access Pattern - Is this user's normal behaviour for accessing this service?

  5. Check Ticket Lifetime - Silver tickets may have extended lifetimes

  6. Correlate Network Activity - Is actual service traffic matching the ticket requests?

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

  1. Orphaned Service Tickets - Service tickets without TGT

  2. Service Account Monitoring - Track all service account password changes

  3. Encryption Baseline - Identify services using RC4 vs AES

  4. Access Patterns - Baseline normal service access per user

Post-Detection Actions:

  1. Reset password for compromised service account

  2. Review all authentication using that service account

  3. Check for lateral movement from systems accessed via silver ticket

  4. 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.EvtxHunter

  • Windows.EventLogs.RDPAuth

  • Windows.EventLogs.AlternateLogon

  • Windows.System.Users

  • Windows.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:

  1. Identify Logon Type - Type 3 = Network logon (SMB, WMI, etc.)

  2. Check Authentication Package - NTLM indicates hash-based authentication

  3. Review Account Type - Built-in Administrator or domain privileged accounts

  4. Analyse Source IP - Cross-reference with DHCP/asset inventory

  5. Check Logon Frequency - Multiple systems in short timeframe = lateral movement

  6. Correlate with Process Creation - Look for remote execution tools (psexec, wmic)

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

  1. Always establish a timeline - Use multiple event sources

  2. Correlate across systems - Single host view may miss lateral movement

  3. Check Domain Controllers first - They hold the most critical evidence

  4. Look for cleanup activities - Attackers often try to cover tracks

  5. Document everything - Chain of custody is critical

VQL Optimization

  • Use WHERE clauses early to filter data

  • Limit time ranges when possible

  • Use LIMIT for initial testing

  • Index 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 IDs

  • Windows.Detection.Yara.Process - YARA scanning

  • Windows.Forensics.Timeline - Comprehensive timeline

  • Windows.System.Amcache - Execution history

  • Windows.Forensics.Usn - USN Journal analysis

  • Windows.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