LOLBins Explained: Living Off the Land With Windows Binaries

The most effective malware on a modern Windows network is often not malware at all. It is rundll32.exe, mshta.exe, certutil.exe: tools Microsoft ships, signs, and trusts, bent to do the attacker's work. This is living off the land, and the tools are called LOLBins.

The appeal for an attacker is simple. Antivirus and endpoint detection lean heavily on the idea that malicious code looks different from legitimate code. A signed Microsoft binary looks exactly like what it is, because it is exactly what it is. Application allowlisting, which blocks unknown executables, waves it straight through. The attacker never has to smuggle a payload past your defenses if the payload is already installed.

What makes a binary a LOLBin

A LOLBin is a legitimate, pre-installed binary that has a secondary capability an attacker can abuse. Useful abuse capabilities include:

• Executing code, often through a signed proxy so the real logic runs under a trusted process.
• Downloading files from a remote server, turning a system tool into a delivery mechanism.
• Bypassing application control, because the trusted binary is on every allowlist.
• Persistence, credential access, or evasion, using the tool's normal features for abnormal ends.

The community-maintained LOLBAS project catalogues these binaries, scripts and libraries along with the exact functions that get abused. On the ATT&CK matrix, most of this activity sits under System Binary Proxy Execution (T1218) and Command and Scripting Interpreter (T1059).

The most abused Windows LOLBins

This is a defensive reference, framed at the detection level. The point is to recognise the abuse, not to reproduce it.

Binary	Legitimate job	How it gets abused	ATT&CK
rundll32.exe	Run functions exported by a DLL	Execute a malicious DLL or proxy a script	T1218.011
mshta.exe	Run HTML Applications	Execute inline or remote script with no browser sandbox	T1218.005
regsvr32.exe	Register COM DLLs	Fetch and run a remote scriptlet (Squiblydoo)	T1218.010
certutil.exe	Certificate management	Download files and decode base64 payloads	T1105, T1140
msbuild.exe	Compile projects	Run inline C# tasks from a crafted project file	T1127.001
wmic.exe	WMI command line	Execute a remote XSL stylesheet (Squiblytwo)	T1220
msiexec.exe	Install MSI packages	Install and run code from a remote URL	T1218.007
mmc.exe	Management consoles	Run script via a crafted console file (GrimResource)	T1218.014
bitsadmin.exe	Background transfers	Download payloads quietly over BITS	T1197

None of these tools is suspicious on its own. Your admins use several of them daily. That is precisely why the technique works and why static blocklists fail.

LOLBins and weaponised files travel together

A LOLBin rarely acts alone. In a typical intrusion the delivery is a file: a .lnk shortcut, an .hta, a scriptlet, a macro document. That file's only real job is to invoke a LOLBin, which then does the downloading and executing. The file is the trigger; the LOLBin is the engine.

This is why file-format defense and LOLBin defense are the same problem viewed from two ends. Our File-Format Abuse Atlas maps which formats wrap which LOLBin techniques, from LNK targets that call PowerShell to .sct scriptlets loaded by regsvr32. Read the two together and the delivery chain becomes obvious.

How to detect LOLBin abuse

Because the binaries are legitimate, detection has to focus on abnormal behaviour, not on the binary's presence. The highest-value signals:

• Parent-child process anomalies. winword.exe spawning mshta.exe, or mshta.exe spawning powershell.exe, is almost never legitimate. Office and script hosts launching LOLBins is a classic chain.
• Unusual command lines. regsvr32 or msiexec invoked with an http URL. certutil with decode or URL-fetch arguments. rundll32 with an export from a DLL in a user-writable path.
• Network activity from tools that rarely make connections. mshta, regsvr32 and msbuild reaching out to the internet deserve a hard look.
• Execution from suspicious paths. LOLBins driven by files in Downloads, Temp, or a freshly mounted archive.

Raising the cost

Detection tells you it happened. Control makes it harder in the first place:

1. Application control with LOLBin awareness. WDAC and AppLocker can block or constrain specific abused binaries. Microsoft's recommended block rules already cover many known LOLBins.
2. Remove or restrict what you do not need. If your endpoints never legitimately run mshta or wscript, changing the default handler or blocking them outright is cheap and effective.
3. Constrain PowerShell with Constrained Language Mode, script-block logging, and the AMSI interface enabled.
4. Egress control. Many LOLBin techniques depend on reaching a remote server. Restricting outbound connections from workstations breaks the download step.

Living off the land is popular because it turns your own trusted toolkit against you and leaves almost nothing for signature-based tools to find. The answer is to stop thinking about what a binary is and start watching what it does. A signed Microsoft tool doing something it has never done before is one of the strongest signals you have.

Why the technique works so well

It helps to name the specific defensive assumptions that LOLBin abuse defeats, because each one is a common pillar of an endpoint strategy.

The first assumption is that malicious code looks different from legitimate code. Signature-based antivirus and reputation systems are built on it. A LOLBin defeats it by definition, since the binary doing the work is a genuine, current, Microsoft-signed component with a spotless reputation. There is no novel file to fingerprint, because the file was already on the disk and trusted before the attacker arrived.

The second assumption is that application allowlisting stops unapproved software. Allowlisting decides what may run by identity, and a signed system binary is on every sensible allowlist. Blocking it wholesale would break the operating system. The attacker exploits the gap between "this binary is allowed to run" and "this binary is allowed to do anything it is capable of", which allowlisting on its own does not close.

The third assumption is that a payload has to be delivered. Traditional detection watches for something arriving: a dropped executable, a written file, a new service binary. Living off the land minimises what touches disk. The malicious logic can live in a command line, a registry value, a script block held in memory, or a remote resource fetched at runtime, so the usual "new file appeared" tripwires never fire.

The fourth assumption is that trust is a property of the process. Many tools treat a signed, well-known process as inherently safe and reduce their scrutiny of it. Proxy execution weaponises exactly that trust: the attacker's code runs inside or through the trusted process, inheriting its reputation and often its network and filesystem latitude.

A worked example of the delivery chain

Following one representative chain end to end shows how the pieces fit, without needing any working payload. Picture a phishing email carrying an archive. Inside is a file that looks like a document but is a shortcut, a .lnk. The victim double-clicks it expecting a document to open.

The shortcut's target is not a document. It is a command line that invokes a script host, passing arguments that reach out to a remote server and pull down a small stage. At no point has the attacker delivered an executable that antivirus could scan on arrival, because the shortcut is a tiny text-like artifact and the script host is a trusted system component.

That first stage then reaches for a second LOLBin to do the heavier lifting. It might call a certificate utility to download a larger encoded payload and decode it in one step, or a registration utility to fetch and execute a remote scriptlet so the logic runs under a signed process. Each hop uses a different trusted binary for a different capability: one to execute, one to download, one to decode, one to proxy the final run past application control.

The result is an intrusion where every individual action was performed by a legitimate, signed Windows tool. There is no malware file to find, no unsigned binary to block, and no single event that looks obviously wrong in isolation. What gives it away is the shape of the whole chain: a document handler spawning a script host, a script host spawning a certificate tool, a certificate tool making an outbound connection to an unfamiliar host. Read as a sequence, the story is unmistakable, and that sequence is what modern detection is built to catch.

Detection signals in depth

The high-value signals listed earlier deserve to be broken down into the concrete indicators a hunt or a detection rule keys on.

Process lineage is the richest source. A LOLBin is suspicious mainly because of who launched it and what it launches in turn. Office applications, PDF readers, browsers, and mail clients spawning script hosts or system utilities is a chain that almost never occurs in legitimate work. Likewise, a script host spawning a compiler, a certificate tool, or another script host is a strong lineage signal. Capturing the full parent and grandparent chain, rather than just the immediate parent, catches attackers who insert a benign-looking intermediary to break the obvious link.

Command-line content is the second source. The abused capabilities show up as recognisable argument patterns: a registration or install utility handed an address that starts with a web protocol, a certificate tool invoked with decode or url-fetch verbs, a DLL runner pointed at a library sitting in a user-writable directory, a compiler asked to build a project from a path in a temporary folder. Logging full command lines is the single most important prerequisite for this, since a bare process name with no arguments hides exactly the detail that separates abuse from routine use.

Network behaviour is the third. Several LOLBins make outbound connections only in the rarest legitimate circumstances. A tool whose normal job is local, suddenly resolving and connecting to an external host, is worth a hard look, especially when the destination has no reputation or history in your environment. Pairing the network event with the process that made it turns a vague connection alert into a specific "this signed utility just called home" finding.

Execution context is the fourth. Where the invocation was launched from matters. LOLBins driven by content in a downloads folder, a temporary directory, a freshly mounted archive or image, or a user profile path are far more likely to be abuse than the same tools run from an administrative script in a controlled location.

Common mistakes in defending against LOLBins

Teams that struggle with this technique tend to make the same handful of errors.

The first is trying to block the binaries outright. It is tempting to simply forbid a much-abused tool, but many LOLBins are load-bearing parts of Windows or of common software, and blanket blocking breaks legitimate functionality and generates enough pain that the block gets rolled back. The workable path is targeted: constrain the specific abused invocations, remove handlers your fleet never legitimately uses, and lean on curated block rules rather than banning core components.

The second is logging process names without command lines. A detection strategy that records that a certificate utility ran, but not the arguments it ran with, has thrown away the exact evidence that distinguishes a routine certificate operation from a payload download. Full command-line logging is the foundation the rest of the strategy stands on.

The third is treating a signed binary as automatically safe and excluding it from scrutiny. Some environments carve out trusted system processes from monitoring to reduce noise, which is precisely the gap proxy execution is designed to slip through. Signed and trusted describes the binary, and the behaviour is what needs watching.

The fourth is ignoring the delivery side. LOLBin abuse and weaponised file formats are two halves of one chain. A program that hunts hard for anomalous process behaviour but never examines the shortcuts, script files, and documents that trigger it is watching only the second act. Instrumenting the delivery formats gives you an earlier and often cleaner detection point.

How LOLBins compare to bringing your own tools

It clarifies the technique to contrast it with the older approach of an attacker bringing custom malware onto a host.

Aspect	Living off the land (LOLBins)	Bringing custom tooling
Files on disk	Minimal, often none new	A dropped binary or driver
Signature detection	Little to nothing to match	A hash and code to fingerprint
Application allowlisting	Bypassed via trusted binaries	Blocked if the tool is unknown
Attribution	Harder, tools are shared and generic	Easier, custom code carries traits
Primary defensive answer	Behaviour and lineage detection	File and reputation detection
Cost to the attacker	Low, tools are already present	Higher, must build and deliver code

The trade for the attacker is real. Custom tooling can do more and be more tailored, and it leaves more behind for defenders and threat intel to find. Living off the land does less on its own and leans on chaining several borrowed tools, and in exchange it leaves almost nothing for signature-based defence and reputation systems to catch. For commodity intrusions the low cost and low visibility of LOLBins are usually the deciding factors, which is why the technique has become a default rather than an exception.

Baseline before you hunt

The reason behavioural detection produces manageable noise is that most environments have a stable, learnable pattern of legitimate LOLBin use. A given fleet tends to run the same handful of system utilities from the same management tooling, the same scheduled jobs, and the same software installers, day after day. Spending time up front to record that normal pattern pays back every time a rule fires.

Build a baseline by collecting, over a representative period, which LOLBins run in your environment, what parents launch them, and what command-line shapes they use. Most of that activity resolves into a short list of benign sources: a patch-management agent invoking an installer utility, a monitoring tool calling a script host with a fixed set of arguments, an imaging process using a certificate tool during provisioning. Once those known-good chains are documented, a detection can suppress them explicitly and alert only on the residue, which is where the genuinely unusual invocations live.

Baselining also surfaces binaries you do not need at all. Many fleets discover that entire categories of endpoints never legitimately run certain script hosts or legacy utilities. Those are the cheapest wins available: removing or restricting a handler your users never invoke costs almost nothing and closes a technique outright. The baseline turns an abstract catalogue of abusable tools into a concrete map of what your specific environment uses, tolerates, and can safely lock down.

How the technique evolved

Repurposing built-in tools is an old idea. Administrators have always used system utilities to move files, run scripts, and automate tasks, and attackers have always noticed that those same utilities make excellent cover. What changed is that defence caught up with dropped malware. As antivirus, reputation systems, and application allowlisting made it costly to bring a new executable onto a host, the relative value of using tools that were already present rose sharply.

The community response was to catalogue the abuse systematically. The LOLBAS project turned scattered tradecraft into a structured, public reference that lists each binary, script, and library alongside the exact functions that get misused and the ATT&CK techniques they map to. That catalogue cuts both ways: attackers use it as a menu, and defenders use it as a coverage checklist. For a blue team, walking the list and asking "would we see this, and do we need this binary enabled at all" is one of the most direct ways to turn the technique's own documentation into a hardening plan.

Frequently asked questions

Are LOLBins vulnerabilities that can be patched? No. A LOLBin is a legitimate tool used within its designed capabilities, so there is usually no flaw to fix and no update that removes the behaviour. The defence is control and detection, applied to how and when the tool runs, rather than patching.

What does living off the land mean? It describes an attacker operating with tools already present on the target system instead of bringing their own. The binaries are the land, and the attacker lives off them, borrowing trusted software rather than smuggling in malware.

Is PowerShell a LOLBin? PowerShell is a scripting environment that is frequently abused in the same way, and it sits alongside the classic LOLBins in most discussions. It is worth hardening specifically with Constrained Language Mode, script-block logging, and the anti-malware scan interface enabled, since its power and ubiquity make it a favourite.

Can antivirus stop LOLBin abuse? Traditional signature-based antivirus struggles, because the binaries are trusted and there is often no malicious file to match. Behaviour-based endpoint detection that watches process lineage, command lines, and network activity is far more effective, and application control raises the cost further.

What is the LOLBAS project? It is a community-maintained catalogue of Windows binaries, scripts, and libraries that can be abused, documenting the specific functions attackers use and the ATT&CK techniques they correspond to. It serves as both a reference for defenders building detections and a checklist for hardening.

Do LOLBins only exist on Windows? The term is most associated with Windows because of its rich set of signed system utilities, but the same idea applies elsewhere. Unix-like systems have their own catalogue of built-in binaries that can be repurposed, and the defensive principle of watching behaviour rather than presence carries across platforms.

What is the single most valuable detection to start with? Watching for office and document-handling processes spawning script hosts or system utilities catches a large share of commodity intrusions at their earliest stage. It is a narrow, high-signal chain that rarely occurs in legitimate work, which makes it a strong first rule.

Related guides

• Living Off the Land Attacks Explained
• YARA Rules Explained
• Sigma Rules Explained
• Threat Hunting Guide
• What Is Fileless Malware