Welcome to the world of Living off the Land Binaries (LoLBins), where threat actors skip custom malware and leverage the system's own trusted utilities to move silently through your environment. It's elegant, subversive, and devastatingly effective. This blog is your guide to spotting the ghosts in the machine: how to hunt down LoLBins before they compromise your network from the inside.
The Art of Going Unnoticed
LoLBins aren't new, but they've evolved from convenient side tools to starring roles in modern attack chains. Initially, they were simple utilities of opportunity: PowerShell, WMI, rundll32.exe. But attackers quickly realized something profound: detection rules have blind spots for trusted binaries. Why bother with custom payloads or complex C2 frameworks when you can use certutil, bitsadmin, or mshta to achieve the same objectives?
LoLBins are legitimate Windows tools (already trusted and digitally signed) that attackers repurpose post-exploitation to execute code, move laterally, and exfiltrate data without triggering traditional security alerts.
The threat landscape tells the story. APT29 (Cozy Bear for my CrowdStrikers out there) has weaponized LoLBins for years in their sophisticated campaigns. The Lazarus Group regularly abuses Windows utilities to maintain stealth. Even ransomware operators like FIN7 and (the probably dissolved) Black Basta embrace living off the land. These tools offer post-exploitation gold: built-in persistence mechanisms, lateral movement capabilities, and data exfiltration, all without lighting up your EDR.
Here's the challenge: most detection strategies focus heavily on initial access vectors. LoLBins thrive in the post-compromise phase, operating in the gray space where logging gaps and alert fatigue allow them to slip through undetected.
Let's change that.
Five Practical Threat Hunts for LoLBins
Let’s take visibility back and start hunting, shall we? I’ve put together five actionable LoLBin threat hunting hypotheses with example Splunk Search Processing Language (SPL) queries you can adapt for your environment.
Note: If you’re not a Splunk customer, fear not! Here’s a link to an SPL to KQL converter, and there are many others a quick Google away.
Remember: these aren't plug-and-play solutions. Effective threat hunting requires quality telemetry, understanding of baseline behavior, and iterative tuning. As a longstanding fan of the MITRE ATT&CK Framework, I’ve also included the associated MITRE TTP in case you’d like to map these hunts to a broader MITRE coverage strategy.
These follow a format we’ve covered a few times, namely the problem we’re hoping to solve, why the hunt matters and (of course) how to solve for potential false positives.
1. Suspicious Use of rundll32.exe for Script Execution
The Problem: Legitimate rundll32 usage rarely involves JavaScript or COM objects. When it does, investigation is warranted.
Hunt: Rundll32 executing scripts
index=endpoint_logs source="*Security" EventCode=4688
| where (ParentImage="*rundll32.exe") AND (CommandLine="*.js" OR CommandLine="*.vbs" OR CommandLine="*javascript*")
| stats count by User, CommandLine, ComputerName, _time
Why It Matters: rundll32 is basically a Swiss Army knife for executing arbitrary payloads while staying under the radar. Attackers love it because it can run malicious scripts that slip past basic logging and AV detection.
Tuning: Watch out for legacy apps that might use this legitimately. You'll want to baseline normal behavior and tune based on known software paths.
MITRE ATT&CK: T1218.011 (Rundll32)
2. When mshta.exe Gets Chatty
The Problem: mshta.exe is supposed to be boring. It handles HTML Applications for legitimate system functions. When it starts spawning from weird parent processes, that's your cue to investigate.
Hunt: Mshta misuse from uncommon parents
index=endpoint_logs EventCode=4688
| where CommandLine="*mshta.exe*"
| table _time, CommandLine, ParentImage, User
| where NOT (ParentImage IN ("*trusted_updater.exe", "*explorer.exe"))
Why It Matters: APT groups love abusing mshta to launch HTAs packed with malicious JavaScript because it looks so innocuous.
Tuning: Some helpdesk tools and OEM software do use mshta legitimately, so you'll need to validate what's normal in your environment before setting this loose.
MITRE ATT&CK: T1218.005 (Mshta)
3. certutil: The Sneaky Downloader
The Problem: Most people think certutil is just for certificate management. Attackers think of it as their personal wget.
Hunt: Certutil used as a downloader
index=endpoint_logs EventCode=4688
| where CommandLine="*certutil* --urlcache --split -f*"
| table _time, CommandLine, User, ComputerName
Why It Matters: certutil can pull payloads over HTTP/S without triggering the same firewall rules that would block curl or wget. It's native, it's trusted, and it flies under the radar.
Tuning: The good news is that legitimate use of certutil for external downloads is pretty rare outside of specific PKI operations.
MITRE ATT&CK: T1105 (Ingress Tool Transfer)
4. WMI Shenanigans
The Problem: WMI should be predictable and boring in most environments. When it's not, you've got problems.
Hunt: Excessive use of WMI commands
index=endpoint_logs EventCode=4688
| where CommandLine="*wmic*" OR CommandLine="*GetObject*"
| stats count by User, CommandLine, ComputerName, _time
| where count > 3
Why It Matters: Attackers use WMI for reconnaissance, remote code execution, and credential dumping. Tools like wmic.exe or COM+ scripts can enumerate your entire environment, trigger processes remotely, or harvest credentials, all while looking like legitimate admin activity.
Tuning: This one's tricky because plenty of IT tools use WMI for legitimate inventory and management tasks. Focus on separating user-initiated WMI calls from scheduled system tasks, and be aggressive with your tuning.
MITRE ATT&CK: T1047 (Windows Management Instrumentation)
5. The Background Bandwidth Bandits
The Problem: BITS was designed to transfer files quietly in the background without hogging bandwidth. Attackers figured out it's also perfect for covert payload delivery.
Hunt: Covert downloads via BITS or PowerShell
index=endpoint_logs EventCode=4688
| where CommandLine="*bitsadmin* /transfer*" OR CommandLine="*Invoke-WebRequest*"
| stats count by User, CommandLine, _time, ComputerName
Why It Matters: BITS transfers are throttled, blend in with normal system noise, and often slip past detection systems entirely. Meanwhile, Invoke-WebRequest shows up everywhere in DevOps scripts, making it perfect camouflage for malicious downloads.
Tuning: The key here is tuning for external versus internal URLs. Legitimate automation usually talks to internal systems, while threats often reach out to external infrastructure.
MITRE ATT&CK: T1105 (Ingress Tool Transfer)
Making These Hunts Actually Work
These queries aren't magic bullets you can copy-paste and call it a day. Here's what actually matters when it comes to hunting for malicious LoLBin activity.
Get your baseline right. These hunts only work when you understand what normal looks like in your environment. Run them passively for a few weeks and watch the patterns before you start alerting on anything. Jupyter Notebooks are your friends here (if you want to do additional baseline/statistical analysis).
Think in signals, not singles. LoLBins rarely work alone. They're part of larger attack chains. Correlate these detections with user behavior analytics, login anomalies, and suspicious file activity. A single hit might be nothing; multiple signals together tell a story.
Right-of-boom visibility is everything. Initial access detection might miss LoLBins entirely because they show up post-compromise. You need solid EDR coverage, Sysmon logging, and identity monitoring (like Okta/AD logs) to trace their movement through your environment.
Start small and iterate. Don't deploy all five hunts simultaneously and expect good results. Pick one, tune it until it's giving you actionable alerts, then use that experience to calibrate the others. Quality over quantity.
To keep things simple, I’ve gone ahead and created a summary table for these hunts (along with the risks). Feel free to use, tune and start hunting!
Final Thoughts
The scariest thing about LoLBins isn't that they're invisible, it's that they're boring. They masquerade as routine admin work, blend into the daily noise, and lull security teams into thinking everything's normal.
But somewhere in that benign-looking PowerShell session or routine rundll32 execution might be a nation-state actor turning your own infrastructure against you. The tools are already there, already trusted, already signed. All they need is someone clever enough to use them.
Stay secure and stay curious, my friends.
Damien