Living off the Land Attacks: Why Your AV Won't See Them

Living off the Land Attacks: Why Your AV Won't See Them

A living-off-the-land (LotL) attack uses tools already present on the target system — PowerShell, WMI, certutil, regsvr32, mshta — instead of dropping malware. The attacker's payload is a sequence of legitimate commands. Because each individual binary is signed by Microsoft and runs legitimately a thousand times a day in normal IT operations, signature-based antivirus can't reliably block them.

This is no longer the exotic, nation-state pattern it was a decade ago. LotL is now the dominant tradecraft in mid-tier criminal intrusions and most advanced campaigns. Every SOC needs a behavioral detection model for it.

Why LotL works

Three structural reasons LotL has displaced traditional malware-heavy intrusion paths:

1. Signed binaries bypass most signature-based controls. PowerShell.exe, certutil.exe, mshta.exe — all signed by Microsoft. AV products designed to flag unsigned executables or known-bad hashes have nothing to alert on.

2. Legitimate use cases create noise the attacker hides in. Every Windows endpoint runs PowerShell legitimately. Every IT team uses WMI to query remote systems. Behavioral models that aren't tuned to the specific environment's normal usage produce too many false positives, so they get muted, and the real detection signal disappears with them.

3. The toolset is documented, free, and reliable. The LOLBAS project (Living Off The Land Binaries, Scripts and Libraries) catalogs every native Windows binary that can be abused for malicious purposes. Attackers don't need to develop custom tools; they need to understand which sequence of native commands achieves their objective without triggering modern EDR.

The most-abused binaries

The current top of the LotL list — the binaries we hunt across customer telemetry every shift:

PowerShell — the workhorse. Encoded commands (-EncodedCommand), bypassed execution policies, downloads via Invoke-WebRequest or Net.WebClient, in-memory script execution via IEX.

WMI / wmic.exe — remote process execution, persistence via WMI event subscriptions, lateral movement.

certutil.exe — used legitimately for certificate operations; abused for downloading payloads (certutil -urlcache) and base64 decoding.

regsvr32.exe — abused via "Squiblydoo" technique to execute remote scriptlets, bypassing application allow-listing.

mshta.exe — executes HTML applications including remote URLs, often used in phishing follow-up.

bitsadmin.exe — file transfers via Background Intelligent Transfer Service, evades many proxy controls because BITS traffic is treated as trusted Windows Update traffic.

rundll32.exe — executes DLL exports; LotL technique uses it to execute attacker DLLs without writing a separate executable.

schtasks.exe — scheduled task creation for persistence; T1053.005.

InstallUtil.exe — .NET installer utility abused for AppLocker bypass.

The detection model that works

LotL is the case study for why behavioral EDR replaced signature AV. The detection logic centers on three signals:

Signal 1 — Parent-child process anomalies

Office binaries (winword.exe, excel.exe, outlook.exe) launching PowerShell or WMI is a strong anomaly. So is browser binaries spawning script interpreters. Build a baseline of normal parent-child relationships per binary, alert on anomalies.

This is the bread and butter of CrowdStrike Falcon's Indicators of Attack, Cybereason's MalOps, SentinelOne's Storyline. Every modern EDR has some version of it.

Signal 2 — Anomalous command-line arguments

PowerShell -EncodedCommand should trigger a look. Long base64-encoded command lines in any binary should trigger a look. certutil -urlcache -split -f is so commonly abused it's nearly a signature on its own. Static command-line analysis catches a meaningful fraction of LotL on its own.

Signal 3 — Behavioral sequences

The single command might be plausible. The sequence is the giveaway. Examples:

• whoami → net user /domain → nltest /dclist: (reconnaissance)
• certutil download → regsvr32 execution → outbound C2 (multi-stage payload delivery)
• vssadmin delete shadows → wbadmin delete catalog → ransomware encryption (pre-encryption preparation)

Detection systems that can correlate sequence — SIEM-driven, EDR with built-in Storyline-equivalent, or both — catch LotL where single-event detection misses.

The QMasters take: the SOCs that catch LotL well are the ones that committed to behavioral detection three years ago and tuned aggressively. The ones still using signature AV with optional EDR alerts are catching maybe 30% of LotL activity. The technical gap is small — the operational gap is large.

What about application allow-listing?

Application allow-listing (AppLocker, Windows Defender Application Control, ThreatLocker, etc.) is the most effective preventive control against LotL — but only if it's deployed properly.

The challenge is that most LotL binaries are signed Microsoft tools allow-listing wouldn't block by default. Effective LotL prevention requires going beyond default allow-listing to specifically restrict execution of high-risk native binaries (regsvr32 from non-system paths, certutil network operations, PowerShell with encoded commands) — which is a non-trivial tuning effort.

We deploy this for customers who have the operational maturity to maintain it. For most mid-market customers, behavioral EDR + SOC-tier detection on LotL patterns gets 80% of the value with 20% of the operational cost.

Soft CTA

If your endpoint stack is signature-based AV plus optional EDR alerts that nobody reviews, LotL activity is happening in your environment and you don't see it. Book an EDR readiness assessment and we'll run a 30-day retroactive hunt for LotL patterns in your telemetry.

FAQ

Q: Which Windows binaries are most commonly abused in LotL attacks?

A: PowerShell, WMI (wmic.exe), certutil.exe, regsvr32.exe, mshta.exe, bitsadmin.exe, rundll32.exe, schtasks.exe, and InstallUtil.exe. The LOLBAS project maintains an authoritative list.

Q: Why doesn't traditional AV catch LotL?

A: Traditional AV is signature-based, looking for known-bad files. LotL uses signed Microsoft binaries with no known-bad signature. The maliciousness is in how the binary is used, not in the binary itself.

Q: How does behavioral EDR detect LotL?

A: Modern EDR builds process-tree models of normal behavior, then alerts on anomalies — PowerShell launched by Word, certutil downloading from a non-Microsoft domain, regsvr32 executing remote scriptlets. The pattern catches LotL even when signature matching fails.

Q: Does application allow-listing solve LotL?

A: Only if you go beyond default allow-listing to specifically restrict high-risk native binary usage patterns. Default allow-listing trusts Microsoft-signed tools, which is exactly what LotL abuses.

Talk to QMasters

If you want to see what LotL hunting looks like across 240+ customer environments, contact our SOC team. We'll walk through real (anonymized) examples from the past 90 days.

For more context, start at QMasters, review our threat intelligence program, or check out continuous threat exposure management.

---

Author · QMasters SOC Team

Last updated · 2026-01-28

Reading time · 7 min