LOLBins: signed Windows binaries abused to deliver malware

Signed binaries are a class of problem defenders keep underestimating. Every campaign on this site that avoided PowerShell did it by abusing a binary that Windows ships with, that vendors whitelist, and that nobody monitors because it has a Microsoft signature. This page collects every LOLBin-heavy campaign I have analyzed, with the abuse pattern, the detection angle, and links to the full write-ups.

What are LOLBins?

LOLBins – “Living Off the Land Binaries” – are legitimate, signed executables that ship with Windows (or a common Microsoft product like OneDrive or Office) and can be repurposed by an attacker to download, execute, decode, or proxy malware. They are not inherently malicious. The problem is that they are trusted: application control solutions allow them, antivirus does not flag them, and process monitoring often ignores them because they appear in the parent-child tree of normal Windows activity.

The canonical reference is the LOLBAS project, which catalogs techniques and operand types for hundreds of built-in binaries.

Why attackers use signed binaries

Using a signed binary to execute code is not a clever trick – it is a deliberate decision to exploit the gap between what a defender allows and what an attacker needs. The core advantages:

Allowlist bypass. Application control rules that block unsigned or unknown executables do not block mshta.exe or finger.exe. They are in the approved list by default.
Parent-process laundering. Spawning a process from mshta.exe, WmiPrvSE.exe, or an IE COM object changes the parent-child relationship in the process tree, defeating detection rules that look for suspicious parents like winword.exe -> powershell.exe.
Signed transport. Binaries like curl.exe and tar.exe (both in-box since Windows 10 1803) can download and extract payloads without touching any unsigned code until the payload is already on disk.
Reduced AMSI surface. Running code inside a non-PowerShell interpreter (IronPython, Node.js, JScript via mshta) avoids the AMSI hooks that fire on PowerShell script loading.

The pattern is consistent across campaigns: use a signed binary for every stage where an unsigned binary would alert; only introduce unsigned code when there is no signed substitute.

LOLBins observed in our analysis

Binary	Abuse method	Campaign	Detection angle
`finger.exe`	TCP/79 payload delivery – fetches a batch script from the attacker’s server via the legacy finger protocol	7-stage ClickFix chain	EID 4688 for `finger.exe` – near-zero FP in any modern enterprise; Sysmon 3 for TCP/79 outbound
`curl.exe`	Renamed and used to download the IronPython runtime archive from GitHub	7-stage ClickFix chain	4688: `.com`-extension file in `%AppData%` executing with curl-style arguments
`tar.exe`	Extracts the downloaded IronPython zip (saved with a `.pdf` extension to evade extension-based controls)	7-stage ClickFix chain	4688: `tar.exe` with a `.pdf` source argument
`mshta.exe`	Downloads and executes a ZIP/MSIX polyglot file containing JScript and VBScript layers	ClickFix polyglot HTA loader	4688: `mshta.exe` with an HTTP/HTTPS argument – near-zero FP; 4104: RC4 AMSI bypass pattern
IE COM object	`mshta` instantiates an `InternetExplorer.Application` COM object to spawn PowerShell, parenting it to `iexplore.exe` instead of `mshta`	ClickFix polyglot HTA loader	Sysmon 1: `powershell.exe` parented to `iexplore.exe` when IE is not running
`wscript.exe`	Proxy-executes a GUID-named VBScript wrapper (`/e:vbscript /b`) to avoid direct script-host detection	Steganographic WMail beacon	4688: `wscript.exe` with `/e:vbscript` flag; 4104: decode-and-execute patterns in Script Block Logging
`WmiPrvSE.exe`	JScript uses `Win32_Process.Create` over WMI to spawn hidden PowerShell, parenting it to `WmiPrvSE.exe` rather than to the calling script host	WMI-launched PS1 beacon	WMI-Activity operational log: `WmiPrvSE.exe -> powershell.exe` parent-child anomaly
`OneDriveLauncher.exe`	A Microsoft-signed OneDrive executable is renamed and dropped alongside a trojanized `LoggingPlatform.dll`, triggering DLL sideloading	OneDrive DLL sideload	Authenticode digest mismatch on the co-loaded DLL; Microsoft-signed binary running from user-writable path

Detection strategy

The common thread across all of these campaigns is that no individual stage looks alarming in isolation – the signal comes from context. Useful detection angles:

Process creation (EID 4688 / Sysmon 1):

finger.exe executing in any enterprise context – no legitimate use
mshta.exe with an HTTP/HTTPS URL argument
wscript.exe /e:vbscript or with a GUID-named script argument
Any process spawned from %AppData% or %LocalAppData% paths (especially interpreter binaries)

Parent-process anomalies:

WmiPrvSE.exe -> powershell.exe – PowerShell spawned via WMI
iexplore.exe -> powershell.exe – when no IE session is running
Any interpreter (python.exe, node.exe, renamed ipyw32.exe) parented to an unusual host

File creation (Sysmon 11):

Signed binaries written to user-writable paths (%AppData%, %LocalAppData%, C:\Windows\Temp)
Files with mismatched extensions (.pdf that is actually a .zip)
Drop directories named after legitimate tools (IronPython.3.4.2\ in AppData)

Script Block Logging (EID 4104):

[Convert]::FromBase64String + [Scriptblock]::Create in the same event
AMSI bypass patterns: amsiContext + Marshal]::WriteInt32, or RtlMoveMemory + VirtualAlloc in reflection calls
RC4 or XOR key material visible in decoded scripts

Network (Sysmon 3, proxy, firewall):

Outbound TCP/79 from workstations – essentially always anomalous
finger.exe, mshta.exe, wscript.exe making outbound connections
Domains appearing in campaign UUID paths or with campaign-specific URL patterns

Defensive controls

Application control is the highest-return control for LOLBin abuse, but it requires careful scoping:

Block unnecessary legacy binaries. finger.exe has no enterprise use. Block it via AppLocker, WDAC, or Defender ASR. Do the same for mshta.exe and wscript.exe in environments that do not depend on legacy scripts.
Path rules matter more than hash rules. Most campaigns abuse signed binaries by dropping them into user-writable paths. A rule that blocks execution from %AppData% and %LocalAppData% catches the renamed ipyw32.exe and the sideloaded OneDrive binary without needing a hash match.
Enable Script Block Logging (EID 4104). This captures decoded payloads before execution. For most campaigns here, the AMSI bypass and the decrypted payload both appear in 4104 events.
Constrained Language Mode. Breaks the reflection-based AMSI/ETW bypass patterns used in several campaigns here. The WMI beacon campaign self-destructs when CLM is active because the XOR-key gating depends on a reflection call that fails under CLM.
Log WMI activity. The WMI-Activity operational log (Microsoft-Windows-WMI-Activity/Operational) captures Win32_Process.Create calls including the command line. This is the primary telemetry source for catching the WmiPrvSE -> powershell parent-laundering pattern.
Verify Authenticode digests, not just signatures. DLL sideloading campaigns copy a legitimate Microsoft signature but the digest fails verification because the DLL content has been replaced. Tools that verify the full Authenticode chain (not just the presence of a signature) catch this.

Detection repo

YARA rules, Sigma detections, KQL queries, and IOC lists for campaigns on this site are published at:

github.com/BlueTeamCoolTeam/detections

The pilot folder covers the finger-lolbin-ironpython campaign in full:

campaigns/finger-lolbin-ironpython/

Additional campaign folders are being added progressively as new write-ups publish.

Practical takeaway

Every campaign here evaded detection at one or more stages by staying inside the “trusted binary” boundary. The pattern is not exotic – it is the default tradecraft for commodity loaders and crimeware trying to stay off the signature-detection radar. The defensive response is not one control but a stack: block the binaries that have no legitimate use, add path-based rules for the ones that do, and ensure your logging covers WMI activity, Script Block events, and process-creation telemetry with command lines. If you can see the parent-child chain and the command line, most of these campaigns become visible at stage 1 or 2, not stage 5 or 6.