Endpoint Security

LOLBin

Living Off the Land Binary — a legitimate, signed system tool repurposed beyond its original intent, typically by attackers seeking to evade detection.

#windows#evasion#endpoint
Updated

A LOLBin (“Living Off the Land Binary”) is a binary already present on a target system — typically signed and trusted by the operating system vendor — that an attacker can use to perform actions beyond its stated purpose: download code, execute scripts, evade detection, persist, or bypass policy.

The term comes from the broader “Living Off the Land” philosophy in offensive security: instead of bringing your own tools to a compromised system, you use what’s already there.

What qualifies a binary as a LOLBin

Three properties together:

  1. Pre-installed and trusted. Already present on a default OS install; signed by the vendor. AV and EDR generally allow it to run.
  2. Capability beyond stated purpose. The binary’s advertised function is narrow, but its actual capabilities (often via undocumented flags, scripting interfaces, or side effects) include things like arbitrary code execution, network I/O, or proxy execution.
  3. Documented misuse. Real-world threat actors have used it. The community curates this in the LOLBAS project — the canonical catalog of Windows LOLBins.

Why this matters for defense

Detection that focuses on “what was run” misses LOLBin abuse entirely — csc.exe, certutil.exe, and mshta.exe run constantly on legitimate Windows systems. The signal is context:

  • Where was the binary invoked from?
  • What were its arguments?
  • What did it do next?
  • Who launched it?

A csc.exe invocation from a developer’s IDE is normal. The same csc.exe invocation from a temp directory triggered by an Office macro is suspicious — same binary, completely different intent. That context is exactly what a portable detection like a Sigma rule encodes.

Common Windows LOLBins

  • csc.exe — the C# compiler. Compiles source code on the fly using a Microsoft-signed binary present on every default install with .NET Framework. Walked through end-to-end in Accidental LOLBin: Controlling Media Keys with csc.exe.
  • certutil.exe — supposed to handle certificates; can also download arbitrary files (certutil -urlcache) and decode base64.
  • mshta.exe — Microsoft HTML Application host; can execute JavaScript/VBScript inline or from a URL.
  • regsvr32.exe — registers DLLs; via /i:url flag, can fetch and execute remote .sct scripts (the “squiblydoo” trick).
  • rundll32.exe — runs functions from DLLs; widely abused for proxy execution.

Each of these is the entry point to its own family of techniques in MITRE ATT&CK.

Beyond Windows

The idea isn’t Windows-specific. GTFOBins catalogs Unix-like executables that can be abused to escape restricted shells, escalate privileges, or move files, and LOOBins does the same for built-in macOS tools. Wherever an operating system ships powerful, trusted utilities, attackers can live off them.

In practice

The technique is getting a new operator. At Ekoparty 2026, the AImaru C2 showed an LLM-driven command-and-control framework that writes obfuscated PowerShell on the fly and rewrites its payloads around legitimate binaries. The attacker still brings no malware; now a model also decides which built-in tool to abuse, and how.

Common misconceptions

  • “Signed means safe.” A signature proves who built the binary, not what it’s being used for. LOLBins are dangerous precisely because they’re trusted.
  • “Just block them.” Some can be blocked for users who never need them, and application control policies help. But many are part of normal administration and updates, and attackers simply move to the next binary on the list.
  • “It’s a Windows problem.” See GTFOBins and LOOBins: every platform has its own land to live off.

Retrieval prompts

Test recall before peeking. Spaced repetition beats re-reading.

Why do attackers prefer LOLBins over custom malware?

Four reasons: (1) vendor-signed system binaries are trusted by default, so they raise far fewer alerts than an unknown executable; (2) nothing is downloaded, so there's no suspicious file on disk; (3) they can slip past application allowlisting that trusts signed system files; (4) they blend into legitimate activity, which makes forensics harder.

Name three Windows LOLBins beyond csc.exe.

certutil.exe, mshta.exe, regsvr32.exe — all bundled with Windows, all signed, all capable of executing or downloading code beyond their stated purpose.

A detection rule alerts on every certutil.exe execution. Why is that a bad rule, and what's better?

It fires constantly on legitimate use, so analysts learn to ignore it. Detect the context instead: unusual flags (-urlcache, -decode), a parent process like an Office app or a script host, execution from a temp directory, or an outbound connection right after.