Block LOLBAS: 60 Days of Data Say Most Don't Need to Run

Security teams have spent years writing detections for LOLBAS because the abuse is real. Attackers like these binaries because they are present, signed, trusted, and usually allowed. That combination turns normal operating system components into ready-made paths for execution, download, proxying, and bypass.

The industry default is still backwards. We allow the tool everywhere, write detections for the suspicious versions, send the alerts to the SOC, and hope analysts can tell business activity from adversary activity fast enough.

We pulled 60 days of production telemetry to find out. The numbers are clear, but the more useful finding is what they mean for policy: most of the LOLBAS catalog has no business reason to exist on a given endpoint.

The industry has spent years detecting these tools.

The data suggests it's time to start blocking them instead.

The 60-Day Receipt

We looked at 60 days of MagicSword production telemetry across customer environments, from April 18, 2026 through June 17, 2026.

The dataset contained 1,458,975 LOLBAS process telemetry sightings linked to 241 LOLBAS catalog entries. In this analysis, a process sighting is execution-focused process telemetry for an execution or enforcement attempt. That lens works for attack surface analysis, but it should not be read as "every sighting was successfully allowed."

Only 115 of those 241 catalog entries executed as processes during the window. The other 126 had zero process sightings, meaning 52.3% of the measured LOLBAS catalog did not execute as a process in the 60-day window.

Metric	Count
LOLBAS catalog entries measured	241
Entries with process executions	115
Entries with zero process executions	126
LOLBAS process telemetry sightings	1,458,975

Some native binaries are everywhere for a reason. conhost.exe, cmd.exe, sc.exe, rundll32.exe, and similar tools need careful handling because real software uses them. The data does not support a cartoon version of application control where every Microsoft binary gets blocked everywhere.

It does support a much more practical question: why should InstallUtil.exe, MSBuild.exe, Regasm.exe, Regsvcs.exe, or Forfiles.exe be allowed broadly when they had zero process executions in this 60-day customer-wide window? If a tool is not part of the business workflow, leaving it available gives the next attacker another signed way to execute code.

The Famous Tools Are Not Equally Needed

A few names deserve their own treatment because defenders recognize them immediately. They also show why a blanket "Microsoft signed, therefore allowed" posture is too loose.

Recent public research points at the same tools. Bitdefender Labs reported on May 19, 2026 that attackers still abuse mshta.exe across commodity stealers, loaders, and more persistent malware campaigns. AVLab's May 2026 in-the-wild malware test saw malware using certutil.exe, rundll32.exe, schtasks.exe, reg.exe, wscript.exe, and regsvr32.exe to download files, execute code, run commands, and communicate with attacker infrastructure. Splunk Security Content refreshed its Living Off The Land analytic story on May 13, 2026, including current detections for paths like mshta.exe spawning rundll32.exe or regsvr32.exe.

Here is the more useful view: customer-wide execution pressure next to public detection-engineering pressure.

LOLBAS	60-day process sightings	Detection corpus rows	What the data says
Rundll32.exe	3,534	288	Used enough to baseline by role, too abused to leave unconstrained.
Mshta.exe	92	201	Famous, still abused in 2026, and low enough to block outside proven workflows.
Regsvr32.exe	74	181	Heavy detection history, light measured process use.
Wmic.exe	80,875	158	Common in this window, so the right move is workflow-aware control, not blind trust.
Msiexec.exe	1,974	144	Legitimate install paths exist; broad allow should still be role-aware.
Schtasks.exe	4,451	109	Useful for administration and software, risky for persistence.
Certutil.exe	46	101	Rare process use compared with years of downloader and encode/decode detections.
Bitsadmin.exe	18	95	Low process use and a long abuse history make it a strong block candidate.
Reg.exe	22,504	92	Common enough to baseline, risky enough to watch and constrain.
Wscript.exe	0	200	No process sightings in the 60-day run despite huge detection coverage.
Cscript.exe	9	183	Rare script-host execution; keep only where a workflow proves it.
MSBuild.exe	0	61	No process sightings; it should not be broadly available outside build/dev use.
InstallUtil.exe	0	46	No process sightings; classic proxy-execution surface without measured need.
Regasm.exe	0	43	No process sightings; role-specific at most.
Regsvcs.exe	0	39	No process sightings; role-specific at most.
Forfiles.exe	0	39	No process sightings; another "why is this allowed everywhere?" candidate.
Cmstp.exe	17	39	Rare process use; test the business case, then scope or block.
Odbcconf.exe	9	34	Rare process use, documented proxy-execution history.
Msdt.exe	15	32	Rare process use and a well-known diagnostic-tool abuse history.
Mavinject.exe	513	13	Smaller detection footprint, but the behavior is sharp enough to control tightly.

The important number is not just the zero-use rows. It is the mismatch between how much the industry has had to detect these tools and how little many of them actually appear in production execution data. That is where policy earns its keep: keep the workflows you can prove, scope the ones that are real, and remove the execution paths that are only helping the next intrusion.

The 500-Endpoint Sample

We also pulled a deterministic random sample of 500 installed Windows endpoints and ran the same 60-day measurement.

The sample saw 146,144 LOLBAS process telemetry sightings. Of the same 241 LOLBAS catalog entries, 78 executed as processes and 163 had zero process sightings. In other words, 67.6% of the measured LOLBAS catalog did not execute as a process in the sample.

Metric	Count
Sample size	500 endpoints
LOLBAS catalog entries measured	241
Entries with process executions	78
Entries with zero process executions	163
LOLBAS process telemetry sightings	146,144

The zero-execution list included names defenders know well: InstallUtil.exe, MSBuild.exe, Regasm.exe, Regsvcs.exe, Forfiles.exe, Wscript.exe, Makecab.exe, and more.

That changes the decision from a philosophical debate about whether a binary can ever be legitimate to an operational question:

Does this endpoint, role, department, or workload actually use it?

If the answer is no, the safer default is to remove the execution path and monitor the block path.

Microsoft Already Said the Quiet Part

Microsoft's App Control guidance says that some software can allow other code to run by design and that, unless those applications are business critical, you should block them in your App Control policy.

That guidance lines up with the data. LOLBAS documents the living-off-the-land catalog. Microsoft's recommended App Control block rules acknowledge that bypass-capable applications are a real control problem. MITRE ATT&CK's System Binary Proxy Execution page lists sub-techniques for InstallUtil, Mshta, Regsvr32, Rundll32, Mavinject, MMC, and more, and its mitigations include application control for binaries that are susceptible to abuse and not required in the environment.

Atomic Red Team turns the same idea into executable tests. The T1218 atomics include examples for mavinject.exe, Register-CimProvider.exe, InfDefaultInstall.exe, Microsoft.Workflow.Compiler.exe, wuauclt.exe, and other proxy-execution paths. This tradecraft is documented, scripted, and repeatable. The data shows many of the same tools are also unnecessary in large parts of real customer environments.

Detection Has Already Proved the Point

We pulled down the local Security-Detections-MCP corpus and indexed public detection content from Sigma, Splunk ESCU, Elastic, KQL, Sublime, and CrowdStrike CQL. The local index contained 8,818 detection rows. Of those, 2,433 distinct detection rows referenced at least one LOLBAS catalog item.

Source	Detection rows indexed
Sigma	3,271
Splunk ESCU	2,102
Elastic	1,761
Sublime	1,058
KQL	461
CrowdStrike CQL	165
Total	8,818

Some examples:

LOLBAS	Detection rows referencing it
Rundll32.exe	288
Mshta.exe	201
Regsvr32.exe	181
Wmic.exe	158
Msiexec.exe	144
Schtasks.exe	109
Certutil.exe	101
Bitsadmin.exe	95
MSBuild.exe	61
InstallUtil.exe	46

Years of detection engineering have already told us these tools matter. Attackers use them because they are trusted, present, signed, and allowed, so defenders keep writing rules that try to separate legitimate use from abuse after execution.

Detection still matters. It gives you the evidence to make better control decisions. But once the data shows MSBuild.exe is not used in a given endpoint cohort, treating every future MSBuild.exe execution as another detection problem is wasteful.

A block turns the question from "Which of these 5,000 msbuild.exe executions are bad?" into "Why did this endpoint try to run a binary we do not use?"

The payoff is less SIEM consumption, less detection tuning, and less analyst time spent rediscovering what policy could have prevented.

The Block Is The Signal

There is a difference between detecting an allowed execution and investigating a denied tool.

Allowed execution forces the SOC to reconstruct intent after the fact. Was mshta.exe launched by a business app? A phishing document? A child process from Office? A remote scriptlet? A LOLBAS chain?

A block starts from a narrower and more useful premise: this endpoint was not supposed to use that binary. One block may be a policy exception request. Repeated blocks may be a broken workflow. Repeated blocks from suspicious parents may be an intrusion trying to continue operations without its normal toolkit.

Either way, the defender is no longer watching the adversary use the tool. The execution path was denied, and the remaining signal is easier to reason about.

Threat-Driven Application Control

MagicSword is built for this shift: threat-driven application control instead of old-school allowlisting where every policy change feels like surgery. Start with known abused paths like LOLBAS, LOLRMM, LOLDrivers, vulnerable tools, signed proxy-execution binaries, and the techniques that keep showing up in the same breach reports year after year. Observe what actually runs, identify the holdouts, exception the real business need, and block the rest.

That audit-to-enforce loop is the same model we wrote about in One Endpoint Doesn't Get to Vote. The Top 10 techniques post made the broader point: the techniques have not changed in a decade, and most of them are blockable today. This dataset makes the point more concrete because most LOLBAS did not execute as processes in the measured window.

Reduce the Attack Surface, Before It Reduces You

The prevention argument is not "never detect." Keep detections for drift, exceptions, true business use, and block events that should not be happening twice. The mistake is confusing detection coverage with risk reduction.

Risk reduction happens when the adversary loses the execution path. No mshta.exe where mshta.exe is not used. No InstallUtil.exe where InstallUtil.exe is not used. No MSBuild.exe where MSBuild.exe is not used. No free proxy execution just because the binary is signed by Microsoft.

Never say never. Say "prove it." Prove the endpoint needs the binary, prove the workflow uses it, and prove the business breaks without it. Until then, block it.

Reduce the attack surface, before it reduces you.

Want to see prevention in action?
Sign up free - Free up to 100 endpoints
Book a demo - Try Enterprise free for 14 days