Host Hunting Strategy — From Endpoint Telemetry to Fleet-Wide Patterns

Network hunting shows where the adversary is calling home. Host hunting shows what they’re doing when they get there. The two are complementary: a confirmed network beacon without a host hunt is an incomplete investigation.

Host Hunting vs. Alert Response

                    ALERT RESPONSE                          HOST HUNTING
                    ──────────────                          ────────────
Trigger:            Rule fires on known-bad pattern         Hypothesis about attacker TTP
Scope:              Single host (or alert context)          Fleet-wide (all endpoints)
Data:               Recent EDR telemetry around alert       Historical + live collection
Goal:               Confirm/deny the specific alert         Find pattern across fleet
Output:             Triage verdict on the alert             Confirmed finding OR null result
                    (TP/FP/benign)                          + detection rule candidate

Host hunting is proactive fleet interrogation, not reactive alert triage. The same tools (Sysmon, EDR, Velociraptor) serve both — but the question changes.

The Hunter’s Host Telemetry Map

Hunt Question	Telemetry Source	Key Fields
What processes ran?	Sysmon Event 1 / EDR process start	Image, ParentImage, CommandLine, User, IntegrityLevel
Was injection used?	Sysmon Event 8 (CreateRemoteThread)	SourceImage, TargetImage, TargetPID
Did a process call out?	Sysmon Event 3	Image, DestinationIp, DestinationPort
What DLLs loaded?	Sysmon Event 7	Image, ImageLoaded, Signed, SignatureStatus
What files were created?	Sysmon Event 11	Image, TargetFilename, CreationUtcTime
What registry changes?	Sysmon Event 12/13	Image, TargetObject, Details
What scheduled tasks?	Sysmon Event 1 (schtasks.exe) / WMI	CommandLine, task name, trigger

The Rarity Model — Finding Needles at Scale

The most powerful host hunting technique for novel threats: rarity analysis.

Intuition: In an enterprise, a legitimate application runs on many hosts. Malware runs on few.

Chrome.exe:         2,847 hosts  ← obviously legitimate
svchost.exe:        2,850 hosts  ← obviously legitimate
OneDriveStandaloneUpdater.exe from System32: 1,200 hosts ← legitimate
OneDriveStandaloneUpdater.exe from AppData:  1 host      ← hunt lead

Rarity query concept:

Step 1: Collect [process_name, image_path] from all endpoints (fleet hunt)
Step 2: Count unique hosts per (process_name, image_path) combination
Step 3: Flag entries with host_count == 1 (or ≤ N × 0.01 for large fleets)
Step 4: Investigate each — can you explain why only this host runs this binary from this path?

The rarity model catches:

Attacker tools masquerading as legitimate process names from wrong paths
Unique malware samples not in any signature database
DLL sideloading (signed binary loading unsigned DLL from same directory)

LOLBin Hunting Framework

LOLBins are used by attackers precisely because they’re trusted. Detection: focus on the invocation pattern, not the binary.

High-Value LOLBin Invocations

Binary          Suspicious Invocation                   Attacker Use
─────────────────────────────────────────────────────────────────────
certutil.exe    -urlcache -f http://...                 Payload download
certutil.exe    -decode <input> <output>                Deobfuscation
mshta.exe       http://... or file.hta                 HTML app execution (T1218.005)
regsvr32.exe    /s /i:http://... scrobj.dll            COM scriptlet execution
wmic.exe        process call create                     Process execution via WMI
rundll32.exe    javascript:...                          Scriptlet abuse
bitsadmin.exe   /transfer ...                           Background download
msiexec.exe     /quiet /i http://...                   Remote MSI install

Fleet hunt logic:

Hunt: certutil.exe with network activity
Filter: parent process is not a known software installer (MsiExec, setup.exe)
Flag: any certutil.exe that generated a network connection (Sysmon Event 3)

Each LOLBin has a small set of legitimate use cases in an enterprise. Everything outside those use cases is a hunt lead.

Hunt Scope: From Hypothesis to Fleet Query

A host hunt requires the same PEAK structure as a network hunt:

Hypothesize: "An attacker is maintaining persistence via a scheduled task that 
              runs a LOLBin (certutil or regsvr32) at logon, which will appear 
              in our environment as a schtasks.exe invocation with an unusual 
              binary path."

Data required: 
  - Sysmon Event 1 (process creation) — 30 days
  - Or Velociraptor artifact: Windows.System.TaskScheduler
  
Success criteria: 
  - Identify scheduled tasks with action binary not in approved software list
  - Action command line contains certutil, regsvr32, mshta, or similar LOLBin

Retrieval Practice

A fleet hunt finds that process 'OneDriveStandaloneUpdater.exe' runs on 1,200 hosts from C:\Program Files\Microsoft OneDrive\ but on 1 host from C:\Users\jsmith\AppData\Roaming\Microsoft\. What does this indicate and what are the next steps?

Reveal answer

This is a classic masquerading (T1036.005) indicator. The attacker copied a legitimate Microsoft binary name to an unusual path (AppData instead of Program Files) to blend in with legitimate process names. Next steps: (1) Pull the SHA256 hash of the binary from AppData — does it match the legitimate OneDrive binary? If hash differs, it's a fake. If hash matches, the attacker copied the real binary to execute alongside a malicious DLL (sideloading). (2) Check Sysmon Event 3 (network connections) from this process — legitimate OneDriveStandaloneUpdater.exe connects to Microsoft ASNs; a C2 implant connects elsewhere. (3) Check parent process — legitimate OneDrive processes spawn from OneDrive service or Task Scheduler with known task names; attacker persistence spawns from an unusual parent. (4) Pull the Sysmon Event 7 (DLL loads) for this PID — look for unsigned DLLs loaded from the same AppData directory (sideloading).

Retrieval Practice

Why is 'process name allowlisting' alone insufficient for LOLBin detection, and what additional dimension makes a LOLBin hunt effective?

Reveal answer

Process name allowlisting catches unknown process names but passes LOLBin abuse because the binary name (certutil.exe, mshta.exe) is legitimate and would be on any allowlist. LOLBin hunting requires two additional dimensions beyond process name: (1) Parent-child context — certutil spawned by a user interactively is unusual; certutil spawned by Word.exe or a scheduled task during off-hours is suspicious. (2) Command line arguments — certutil -urlcache -f http://... is a download operation that legitimate certutil usage (certificate management) never performs on workstations. (3) Network correlation — does this process generate an outbound connection? The combination of [known binary] + [unusual parent] + [download argument] + [network activity] forms a high-fidelity hunt signature that no allowlist catches and no single rule fires on.