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

Why command-line matching breaks

The rule above matches strings in the command line, and command lines are the most easily manipulated field in Windows process telemetry. Knowing how they get manipulated determines how much you should trust that rule.

The common transformations, all of which produce a command line that executes identically and matches nothing:

Two responses, and you want both.

Normalise before matching. Strip carets and stray quotes, expand what you can, and decode -enc payloads at ingest so the rule sees the effective command line rather than the literal one. This is pipeline work rather than rule work, and it improves every command-line rule you own simultaneously — which makes it a better investment than tuning any single detection.

Stop relying on the command line as the primary signal. Obfuscation is cheap and normalisation is a race. The signals in the next section are properties of what the binary does, and they do not change when the arguments are rewritten.

The signals that survive obfuscation

These are the detections worth building first, because none of them can be evaded by changing how the command is spelled.

A renamed LOLBin is trivially detectable — and almost nobody checks. Sysmon’s process-creation event includes OriginalFileName, read from the PE version resource, which does not change when a file is copied to a different name. So:

Alert when OriginalFileName is CERTUTIL.EXE and Image does not end with \certutil.exe.

There is no legitimate reason for that mismatch. It is one of the highest-fidelity Windows detections available, it generalises across every LOLBin by substituting the name, and it catches the specific evasion that defeats every Image|endswith rule in your library. Build it for the whole set at once rather than per binary.

Network connections from binaries that should not make them. certutil.exe, regsvr32.exe, mshta.exe, and rundll32.exe establishing outbound connections (Sysmon Event ID 3) is enormously more suspicious than any argument string, because their legitimate uses are overwhelmingly local. Certificate operations against an internal CA are the notable exception and they are enumerable, which makes the allowlist short and stable.

A LOLBin writing an executable to disk. Event ID 11 showing certutil.exe creating a .exe, .dll, or .scr is the download-and-drop pattern regardless of how the download was expressed.

A LOLBin as the parent of a shell. mshta.exe or rundll32.exe spawning cmd.exe or powershell.exe is the payload executing, and the process tree records it whatever the arguments looked like.

An unusual parent. Office applications, browsers, PDF readers, and script hosts spawning any LOLBin is the initial-access pattern, and it is entirely independent of the command line.

The pattern across all five: detect the capability being used, not the syntax used to request it. A command line is a string an attacker fully controls; a network connection is an observation of what actually happened.

How do you build the allowlist?

Every LOLBin rule needs an allowlist, and guessing at it produces either a noisy rule or a suppressed one. The baselining method is mechanical:

1. Collect 30 days of process creation for the LOLBins you care about, across the whole estate.
2. Group by the triple (Image, ParentImage, normalised CommandLine) — normalised meaning variable paths, GUIDs, and temp filenames replaced with placeholders, so a thousand runs of the same deployment script collapse into one group.
3. Rank by distinct host count, ascending. Legitimate administrative and deployment tooling appears on many hosts. Attacker activity appears on one.
4. Review the long tail by hand. The groups appearing on one or two hosts are a short list, and working through it is the single most productive afternoon in this whole exercise.
5. Allowlist the high-count groups by parent and path, never by binary name alone.
6. Re-run quarterly. New deployment tooling appears, and an allowlist entry that matches nothing is an entry that stopped protecting anything without telling you.

Step 3 is why this works. You do not need to know what malicious use looks like — you need to know what common use looks like, and everything else is a candidate. That inverts the problem from enumerating badness, which is unbounded, to enumerating your own normal behaviour, which is finite.

Which LOLBins can you simply remove?

Detection is the fallback. For a meaningful share of these binaries, the better answer is that your environment does not need the capability at all.

• mshta.exe — HTML applications are a legacy technology. Most modern estates have no legitimate use, and blocking it removes an entire execution path.
• regsvr32.exe scriptlet loading — the remote .sct behaviour specifically, which legitimate software essentially never uses.
• cscript.exe / wscript.exe — many organisations still run VBScript logon scripts, and many have not needed them for years and have never checked.
• Legacy certutil download behaviour, where certificate operations are genuinely required but URL fetching is not.

Microsoft publishes a recommended block list for application control that covers binaries commonly abused to bypass allowlisting, and adopting it is far faster than deriving the list yourself. Pair it with the attack-surface-reduction rules that block Office applications from creating child processes, block obfuscated script execution, and block script hosts from launching downloaded content — each removes a common LOLBin invocation path at the point of initial access.

Deploy all of it in audit mode first. Audit mode tells you exactly which of these your environment actually uses, which is both the migration plan and, frequently, a surprise.

Why application control beats detection here

Worth stating directly, because this guide has spent most of its length on detection.

LOLBAS catalogues hundreds of binaries and techniques, and it grows. You cannot write and maintain a rule for each, your environment contains a different subset than mine, and the ones with no rule are exactly the ones an attacker with the same catalogue will select. Detection here is structurally a game you play from behind.

WDAC changes the shape of the problem. A properly enforced application-control policy does not care whether a technique is catalogued: code that is not permitted does not execute, whether it arrived through mshta, a novel LOLBin published next month, or a binary nobody has documented yet. It converts an open-ended enumeration problem into a closed one.

The honest tradeoffs, because it is not free:

• It is a programme, not a project. Inventory, policy authoring, audit mode, exception handling, and ongoing maintenance as software changes.
• It is disruptive if rushed, and a policy rolled back after breaking a business application is worse than never having started, because it becomes politically difficult to attempt again.
• Managed installer and path rules are where policies get weak. A policy trusting a user-writable path has a hole shaped exactly like the attack.
• The payoff is disproportionate. It simultaneously addresses LOLBins, ransomware payload execution, and untrusted binaries generally — which is why it appears in the hardening section of several unrelated guides on this site.

The practical recommendation: build the behavioural detections in this guide, because you need coverage now and they are a few days of work. Then start application control in audit mode as a parallel programme, because that is what eventually makes this category of attack uninteresting rather than merely monitored.

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.

Which LOLBins should you cover first?

The catalogue is large and your time is not. Rank by two properties: what the binary enables, and whether it appears in real intrusions rather than only in research.

Start at rows one and two. Between them they cover the download-and-execute pattern that precedes most of what follows, and they are the binaries with the clearest abuse signatures relative to their legitimate use.

Row three deserves a specific note. Compilation on an endpoint is a strong signal in most environments and a completely normal one on developer machines — which means the rule is high-fidelity almost everywhere and unusable on the population most likely to be targeted. Segment the rule by endpoint role rather than trying to find a threshold that works for both, and accept that developer workstations need the parent-process and network conditions to carry the weight.

Check what is actually present before writing anything. A rule for a binary that does not exist on your image is a rule that will never fire and will still sit in your library being maintained. Inventorying which LOLBAS entries exist in your standard build takes an afternoon and typically removes a third of the candidate list — and it occasionally finds something on the image that has no business being there, which is a better finding than the rule would have been.

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.
• Matching command-line strings without normalising them. Caret escaping, quote insertion, environment-variable substrings, and PowerShell concatenation all defeat a literal match while executing identically.
• Keying only on Image. An attacker copies certutil.exe to another name and every Image|endswith rule stops matching.
• Not using OriginalFileName. The PE version resource survives renaming, so a mismatch between it and Image is near-zero-false-positive and catches the evasion above outright.
• Ignoring network connections from LOLBins. certutil or mshta making an outbound connection is far stronger evidence than any argument string, and it cannot be obfuscated away.
• Building the allowlist by guessing. Baseline 30 days, group by image, parent and normalised command line, and review the long tail — the rare groups are the candidates.
• Never re-running the baseline. Deployment tooling changes, and an allowlist entry matching nothing has silently stopped suppressing whatever it was written for.
• Trying to cover the whole LOLBAS catalogue. It is hundreds of entries and it grows; cover what exists in your environment and invest the remaining effort in application control.
• Rolling out WDAC without audit mode. A policy reverted after breaking a business application is worse than one never attempted, because the second attempt is politically much harder.

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.
9. Normalise command lines at ingest — strip carets and stray quotes, decode -enc payloads — so every command-line rule you own improves at once.
10. Alert on OriginalFileName mismatching Image, which catches every renamed LOLBin with essentially no false positives.
11. Alert on network connections and executable file writes from LOLBins, which survive any argument obfuscation.
12. Start WDAC in audit mode as a parallel programme, because it is what eventually makes this whole category uninteresting rather than merely monitored.

Items 10 and 11 are the highest return per hour of work on this list. Both are built once, cover every binary in the catalogue rather than one at a time, and remain correct when an attacker changes how the command is spelled — which is the property the argument-matching rules lack and the reason they need constant maintenance.

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.