Detecting 2026 LOLBins and Living-off-the-Land with Sigma

A post-incident review of any recent ransomware intrusion tends to show the same pattern: no exotic malware, no unknown binary, just signed Microsoft tools that ship natively on every Windows host, repurposed for something they were never meant to do. MSBuild compiling a code fragment delivered by email. Regsvr32 fetching a scriptlet from a remote server. Rundll32 loading a DLL dropped in a temp folder. This is the technique tracked under T1218 (System Binary Proxy Execution) and T1036 (Masquerading), and by 2026 it shows up in nearly every intrusion chain observed right before encryption.

The hard part is not knowing these binaries exist, everyone does. The hard part is detecting the abuse without also flagging (or worse, blocking) the legitimate use. MSBuild runs on every developer workstation. Regsvr32 gets called by business installers. Rundll32 is invoked constantly by Windows itself. A rule that fires on the binary name alone generates a false positive storm and gets disabled within days, which is worse than having no rule at all.

Why command line, never binary name

Here is the principle that everything below is built on: these executables are signed by Microsoft, present by default, and legitimate in the overwhelming majority of contexts. Targeting them by Image alone is like trying to catch a burglary by watching who owns a screwdriver. What separates legitimate use from abuse is context: the arguments passed on the command line, the process that launched the execution, and sometimes the working directory.

A developer compiling a project launches MSBuild against a .csproj sitting in a normal build path, from a terminal or an IDE. An attacker running inline .NET through MSBuild passes an .xml or .csproj file sitting outside any recognized build path, and critically, the parent process is almost never a terminal: it is often Outlook, Word, or Explorer, following the opening of an attachment or a shortcut.

MSBuild.exe: inline .NET execution with nothing dropped to disk

MSBuild accepts inline tasks defined directly inside an XML project file. That legitimate feature (compiling code as part of a build task) becomes an execution technique the moment an attacker embeds arbitrary C# in a file that was never meant to be a real build project.

title: Suspicious MSBuild execution from an unusual parent
id: 8f2c1a4e-3b7d-4e91-9a2f-6d5c8b1e0f3a
status: experimental
description: >
  Detects MSBuild.exe launched by an atypical parent process (mail client,
  browser, Explorer) targeting a file outside known build paths.
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\MSBuild.exe'
  selection_parent_suspect:
    ParentImage|endswith:
      - '\OUTLOOK.EXE'
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\explorer.exe'
      - '\wscript.exe'
      - '\powershell.exe'
  filter_build_path:
    CommandLine|contains:
      - '\obj\'
      - '\bin\Debug\'
      - '\bin\Release\'
      - 'Program Files\dotnet\'
  condition: selection_image and selection_parent_suspect and not filter_build_path
falsepositives:
  - Build scripts orchestrated from an automation tool not listed above
  - Internal CI/CD pipeline invoking MSBuild through a legitimate PowerShell wrapper
level: high

The build-path filter (filter_build_path) is what separates this rule from a plain alert on the parent's name: without it, every CI run would trip the alert.

Regsvr32 and rundll32: classic proxy execution, still effective

regsvr32.exe with the /i:http (or /i:https) option fetches a remote scriptlet and executes it without ever writing an executable file to disk. rundll32.exe loads a DLL passed as an argument, and the most common abuse points it at a DLL dropped in %TEMP% or %APPDATA%, two directories no legitimate Windows component uses as a library source.

title: Regsvr32 proxy execution via remote scriptlet
id: 4d6e9f21-7a3c-4b58-9e0d-1f2a3b4c5d6e
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains:
      - '/i:http'
      - 'scrobj.dll'
  condition: selection
falsepositives:
  - Internal software deployment using a signed, internally hosted scriptlet
level: high
---
title: Rundll32 loading a DLL from a user-writable directory
id: 1a2b3c4d-5e6f-4708-9a0b-1c2d3e4f5a6b
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\rundll32.exe'
  selection_path:
    CommandLine|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
  condition: selection_image and selection_path
falsepositives:
  - Third-party packaged applications that install their DLLs under the user profile
level: medium

The strong signal: shadow copy deletion before encryption

Unlike the two techniques above, deleting local backups is almost never legitimate outside a documented, scheduled maintenance window. Seeing vssadmin delete shadows, wmic shadowcopy delete, or wbadmin delete catalog on a user workstation or an application server outside a maintenance window is a signal of imminent encryption, to be treated as a critical alert, not just one indicator among many.

title: Shadow copy deletion, pre-ransomware signal
id: 9c8b7a6d-5e4f-4321-8a9b-0c1d2e3f4a5b
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'resize shadowstorage'
  selection_wmic:
    Image|endswith: '\WMIC.exe'
    CommandLine|contains: 'shadowcopy delete'
  selection_wbadmin:
    Image|endswith: '\wbadmin.exe'
    CommandLine|contains:
      - 'delete catalog'
      - 'delete backup'
  condition: 1 of selection_*
falsepositives:
  - Scheduled maintenance script running under an identified service account
level: critical

Here, the exception is granted by service account and documented time window, never by disabling the rule. That is the distinction between a team that manages its false positives and a team that has simply switched detection off.

Anti false-positive discipline: baseline, exclude, never disable

Facing a recurring false positive, the temptation is to kill the rule. That is the mistake that reopens the blind spot. The right discipline runs in three steps:

1. Baseline legitimate admin usage: scheduled backup scripts, CI/CD orchestration, internal software deployments. Every case should be identified by name, not assumed.
2. Exclude by path or by account, never by global disable: a filter on the backup service account or on the legitimate build script's path closes the false positive without reopening the attack window.
3. Document the exclusion with its justification and date, so it gets reviewed rather than forgotten when the environment changes.

The engine: what has to be enabled before the rule does anything

These rules depend on Sysmon Event ID 1 (Process Creation) and rely on three fields: CommandLine, ParentImage, CurrentDirectory. Without the right configuration, those fields are empty or missing, and the rule detects nothing, silently.

# Confirm process creation auditing is active
auditpol /get /subcategory:"Process Creation"
 
# Confirm the command line is actually included in process creation events
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled

Two non-negotiable prerequisites: the "Process Creation" audit policy must be enabled via group policy, and "Include command line in process creation events" must be turned on. Without that, Sysmon still receives the event, but the CommandLine field stays empty, and every rule above goes silent without ever raising a visible error.

Before and after: same intrusion, two outcomes

Before (rule on binary name alone):

detection:
  selection:
    Image|endswith: '\regsvr32.exe'
  condition: selection

This rule fires on every regsvr32 call, including the ones triggered by legitimate software installers several times a day across a fleet of a few hundred endpoints. Result: dozens of daily alerts, none of them prioritized, and the rule disabled within a week by the team that can no longer keep up.

After (CommandLine plus context): the rule shown earlier, scoped to /i:http and scrobj.dll, only fires on the actual proxy execution pattern. Run against several weeks of production logs from a live fleet, it produced zero alerts on the catalogued admin usage, and correctly caught the remote call during an intrusion simulation exercise.

In summary

Detecting living-off-the-land is not won by knowing the list of binaries to watch, that list is public and everyone already knows it. It is won by the discipline of detecting execution context: the full command line, the parent process, the target path. That baselining and documented exclusion work, not disabling the rule, is what keeps these detections active over time without burning out the team running them.

That is exactly the discipline behind the ThreatClaw Sigma feed: every LOLBins rule is built on CommandLine and ParentImage, tested against a corpus of legitimate admin usage before publication, and shipped with its exclusion conditions documented rather than a plain binary name to ban.