Detecting Living-off-the-Land Binaries

Detecting living-off-the-land binaries is a false-positive problem, not a discovery problem. The binaries — certutil.exe, regsvr32.exe, mshta.exe, rundll32.exe — are legitimate, signed Microsoft tools that run constantly for valid reasons. Attackers abuse them to download payloads and execute code without dropping new malware, which defeats signature antivirus. The detection is not “did this binary run” but “did it run with arguments and a parent that only abuse produces.” This guide ships that behavioral approach.

LOLBin abuse maps to MITRE ATT&CK T1218 — System Binary Proxy Execution and the broader T1059 — Command and Scripting Interpreter. The LOLBAS project is the community reference for which binaries are abusable and how.

What are living-off-the-land binaries?

LOLBins are legitimate executables already present on Windows that provide functionality an attacker can repurpose: certutil can download files, regsvr32 can execute a remote scriptlet, mshta can run inline HTML applications, rundll32 can call exported functions. None of these is malware; all of them are signed by Microsoft and trusted by the OS. That is exactly why attackers reach for them — “living off the land” means using what is already there, leaving no new file for antivirus to catch.

The defensive consequence is that you cannot block your way out (these tools have valid uses) and you cannot rely on signatures (the file is trusted). You detect the behavior: the specific abuse pattern that legitimate use does not produce.

Which LOLBins are most commonly abused?

The pattern across all of them: a trusted binary, an argument set specific to abuse, and a parent process that has no business spawning it (a browser, an Office app, a script host). That triad is the detection.

How to detect LOLBin abuse

The rule keys on a LOLBin running with abuse-specific arguments. Tune it with an allowlist of your known-legitimate invocations.

title: LOLBin Abuse via Suspicious Arguments
id: 8f4c2a91-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  certutil:
    Image|endswith: '\certutil.exe'
    CommandLine|contains|all: ['-urlcache', 'http']
  regsvr32:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains: ['/i:http', 'scrobj.dll']
  mshta:
    Image|endswith: '\mshta.exe'
    CommandLine|contains: ['http', 'javascript:', 'vbscript:']
  condition: certutil or regsvr32 or mshta
falsepositives:
  - Software deployment/admin scripts using these tools (allowlist by parent/path)
level: high

How to test your LOLBin detection

On a lab machine you own:

1. Run a benign LOLBin abuse pattern (e.g. certutil -urlcache -f http://lab/test.txt against a host you control) and confirm the rule fires.
2. Run a legitimate admin invocation and confirm your allowlist suppresses it.
3. Spawn a LOLBin from a simulated Office parent and confirm the parent condition escalates it.
4. Cross-check coverage against the LOLBAS catalog for the binaries in your environment.

How to prevent LOLBin abuse

• Constrained-language-mode PowerShell and disabled script hosts shrink the LOLBin surface.
• Block Office child processes (an ASR rule) — a top LOLBin spawn path.
• Baseline legitimate use so the allowlist is accurate and the rule stays quiet.

Common LOLBin detection mistakes

• Alerting on the binary, not the behavior. Floods the SOC and gets muted.
• No parent-process context. Misses the highest-fidelity discriminator.
• No command-line logging. Without Sysmon EID 1 cmdlines, the rule is blind.
• Blanket blocking. Breaks admin work and gets reverted.

LOLBins detection checklist

1. Collect process-creation command lines (Sysmon Event ID 1).
2. Build rules from the LOLBAS catalog for binaries present in your environment.
3. Key on abuse-specific arguments, not mere execution.
4. Add parent-process conditions (Office/browser/script-host → LOLBin).
5. Baseline and allowlist legitimate admin/deployment invocations.
6. Apply WDAC/AppLocker and least functionality to restrict invocation.
7. Add the ASR rule blocking Office child processes.
8. Test each rule with a benign abuse pattern and a legitimate invocation.

The takeaway

Detecting LOLBins is behavioral, not signature-based: flag trusted binaries running with abuse-specific arguments from anomalous parents, built from the LOLBAS catalog and tuned with an allowlist, and backed by application control. The binary is trusted; the behavior is not. Continue with Sysmon configuration and LSASS credential dumping detection, or browse the full Detection Engineering pillar.