← All posts

Living Off the Land: How Attackers Weaponize Signed Windows Binaries (LOLBins)

Rundll32, mshta, regsvr32 and other trusted Microsoft binaries let attackers run malicious code with no malware on disk. Here's how LOLBin abuse works on Windows, what to audit, and how to catch it.

Antivirus is built to answer one question: is this file bad? Living-off-the-land attacks refuse to play that game. Instead of dropping a malicious executable, the attacker uses a binary that is already on the machine, already signed by Microsoft, and already on every allowlist — and hands it a task it was never meant to do. There is nothing new on disk to scan, nothing unsigned to flag, and the process tree is full of names your tools have been trained to trust. This is the technique behind a large share of modern intrusions, and it is precisely the class of attack that a signature engine is structurally blind to.

The catalog of abusable binaries has a name — LOLBAS, the Living Off the Land Binaries, Scripts and Libraries project — and it runs to hundreds of entries. A senior engineer does not try to memorize all of them; they learn the handful that matter, understand why a signed tool becomes a weapon, and then audit for the conditions that let the abuse land in the first place.

1. Proxy execution: borrowing a trusted binary's reputation

The core move is proxy execution — asking a legitimate Microsoft binary to load and run attacker code, so the malicious logic executes under a name your defenses respect. A few workhorses show up again and again:

What makes these dangerous is not the binaries themselves — you cannot remove them without breaking Windows — but the fact that on most endpoints they run unmonitored, unconstrained, and with no reason to be talking to the internet. The tell is almost never the binary; it is the context: a Word document spawning mshta, or regsvr32 making an outbound HTTPS connection.

LOLBin abuse doesn't defeat your allowlist — it exploits the fact that your allowlist was the whole defense.

2. The parent-child tells that give it away

Because the binary is trusted, detection lives in process lineage, not file reputation. Office and browser processes almost never have a legitimate reason to spawn a script interpreter or a build tool, so those parent-child pairs are high-signal. You can hunt for them live on a host from the Sysmon or process-creation log:

# Recent process creations (Security 4688 must be enabled; or use Sysmon Event ID 1)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688 } -MaxEvents 500 -EA SilentlyContinue |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time   = $_.TimeCreated
      Parent = ($x.Event.EventData.Data | ? Name -eq 'ParentProcessName').'#text'
      Image  = ($x.Event.EventData.Data | ? Name -eq 'NewProcessName').'#text'
    }
  } | Where-Object {
    $_.Parent -match 'winword|excel|outlook|powerpnt|chrome|msedge' -and
    $_.Image  -match 'mshta|regsvr32|rundll32|powershell|cscript|wscript|msbuild'
  } | Format-Table -Auto

The same idea applies to a signed binary reaching out to the network: rundll32 or regsvr32 with an outbound connection is worth an alert every single time. Enabling command-line auditing (so 4688 records the full command line, or Sysmon captures it) is the difference between seeing rundll32.exe and seeing rundll32.exe javascript:... — the arguments are where the intent lives.

3. Shrink the ground they can live off

You cannot delete these binaries, but you can remove the conditions that make them useful. The defensible baseline is layered:

  1. Attack Surface Reduction rules. Microsoft Defender's ASR includes rules that specifically block Office apps from creating child processes and from spawning executable content — closing the most common LOLBin launch path outright.
  2. Application control. WDAC or AppLocker in a publisher- and path-aware configuration can constrain where and how these binaries run, and block the script hosts (mshta, wscript) that legitimate users rarely need.
  3. Egress and logging. Signed system binaries almost never need direct internet access; a host firewall rule plus command-line and script-block logging turns a silent proxy execution into a recorded, alertable event.
  4. Constrained Language Mode for PowerShell removes many of the primitives that in-memory LOLBin payloads depend on.

None of these is exotic — they are configuration you already own. The problem is knowing, on any given machine right now, which of them are actually in force and which quietly reverted after an update, a reimage, or a well-meaning "temporary" exclusion.

Make the audit continuous, not a one-time sweep

The reason LOLBin abuse works so often is that the defenses against it are settings — ASR rules, application-control policy, command-line auditing, script-block logging, PowerShell language mode — and settings drift. WinSentinel checks exactly these facts on the machine in front of you: whether process-creation and command-line auditing are on, whether PowerShell script-block logging is enabled, whether ASR rules and application-control policy are configured, and folds them into one posture score:

winsentinel audit
winsentinel score

Re-run it after any change and the score moves the moment a control lapses — so "are we still positioned to catch living-off-the-land activity?" becomes a fact you verify daily, not a memory of the day you turned logging on. It runs entirely on the local machine, free and unlimited across all 33 audit modules.

When one machine becomes a fleet

Checking auditing policy, ASR rules, and script-block logging by hand across 50 or 100 endpoints is exactly where this falls apart — and these are textbook settings that silently come back after a GPO change or a rebuild. That fleet-wide assurance is what WinSentinel Pro is for: lightweight agents report each machine's posture to a central node, so an endpoint that loses command-line auditing or has its ASR rules turned off surfaces as a drift alert instead of the blind spot an attacker walks through. The depth of each machine's audit is identical to the free single-machine scan; Pro adds the central console, fleet history, compliance rollups, and drift alerting you need to trust that dozens of machines are all still watching their own trusted binaries.

The takeaway

Living-off-the-land is the honest admission that file-based detection has a ceiling: when the malicious code runs inside rundll32, mshta, or msbuild, there is no bad file to find. The answer is to stop looking only at files and start looking at behavior and configuration — hunt the parent-child pairs that never happen legitimately, deny the binaries their network and their scripting hosts, and keep command-line and script-block logging on so intent is recorded. Every one of those is a setting you can audit. Verify them on the machine in front of you today, free and unlimited; extend that same verification fleet-wide with Pro when one machine becomes many. Attackers count on your trusted tools being unwatched — so watch them.