Mean Time to Prevent (MTTP): Why Detection Isn't Enough

Your SOC just got an alert. Again. Another mshta execution. Another wscript callback. Another RMM tool your IT team has never heard of. Your analyst clicks through the same workflow, runs the same playbook, investigates the same technique they investigated last Tuesday.

Meanwhile, across hundreds of organizations, adversaries are reaching for the same handful of tools because they work. Because they're already on the system. Because you let them run.

What if you didn't?

First time here? Learn how threat-driven application control blocks tool abuse before execution.
→ Allowlisting vs Blocking Abuse: The Two Paths to Application Control

The Detection Treadmill

Here's the industry's dirty secret: we've gotten exceptionally good at detecting attacks we could have prevented.

Every threat detection report tells the same story. Red Canary's 2025 analysis shows the same techniques dominating year after year - PowerShell, Windows Command Shell, Mshta, WMI, Ingress Tool Transfer. MITRE ATT&CK's top techniques aren't rotating. They're calcifying.

Adversaries aren't innovating. They don't have to. They reach for certutil.exe to download payloads because it works. They execute scripts through mshta.exe because it runs. They establish persistence with RMM tools your organization has never purchased because nothing stops them.

Your EDR catches it. Eventually. Your SIEM correlates it. Eventually. Your analyst investigates it. Eventually. Your SOAR playbook kicks off. Eventually.

But "eventually" means the adversary had time. Time to enumerate. Time to pivot. Time to exfiltrate. Time to deploy ransomware.

Detection isn't the finish line. It's the starting gun for the adversary's head start. Modern intrusions rely heavily on legitimate tools and scripts, which means malware-free attack prevention is becoming the real challenge for security teams.

Mean Time to Prevent: The Metric That Actually Matters

The industry obsesses over Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR). We measure how fast we notice the fire. How fast we grab the extinguisher. How fast we write the incident report.

Nobody asks why we keep letting people light matches.

Mean Time to Prevent (MTTP) flips the model. It reflects a shift toward prevention-first cybersecurity, where stopping execution matters more than detecting it. Instead of racing to detect techniques that are already executing, execution control stops them from executing at all. Instead of measuring how fast your SOC responds after initial access, you measure how fast you block the adversary's tooling before they achieve anything meaningful.

With enough endpoint attack surface reduction, MTTP approaches zero. Not zero seconds after detection - zero seconds after the attempted execution. The payload is denied. The script is blocked. The hands-on-keyboard session dies before the first command returns output.

Your first SOAR playbook never kicks off. Your analyst never clicks an alert. Your incident retrospective never happens.

Because there's no incident.

The Math: LOLBAS + LOLRMM = Nowhere to Go

Let's get specific about what "attack surface reduction" actually means in practice.

The LOLBAS Project catalogs 217 living-off-the-land binaries, scripts, and libraries that adversaries abuse, which makes them central to Living off the Land attack prevention strategies. These aren't exotic tools. They're signed Microsoft binaries. They ship with Windows. They're on every endpoint you manage right now.

And they show up in every major attack chain.

Red Canary's data shows that a handful of these techniques dominate real-world intrusions. Command and Scripting Interpreter (especially PowerShell and Windows Command Shell), Mshta, WMI, Ingress Tool Transfer - these aren't edge cases. They're the standard playbook.

Block these abuse patterns - the specific ways adversaries weaponize native binaries - and you've just made most commodity attacks fail immediately.

But we're not done.

Add LOLRMM to the equation. Remote Monitoring and Management tools are the persistence mechanism of choice for modern adversaries. Effective RMM abuse mitigation means preventing unauthorized remote access tools from executing before they establish persistence. ScreenConnect, AnyDesk, Atera, Splashtop - tools your organization doesn't use becoming the attacker's command-and-control channel.

CISA called this out explicitly. RMM abuse is endemic. It's the persistence play that bypasses traditional malware detection because these tools are "legitimate." Signed. Trusted. And completely unauthorized in your environment.

Now stack these controls:

LOLBAS blocking: No mshta execution. No certutil downloads. No wmic process calls. No regsvr32 proxy execution.

LOLRMM blocking: No unauthorized remote access tools. No ScreenConnect from IP addresses you've never seen. No AnyDesk installations that IT didn't deploy.

Where does the adversary go?

Cornered: What's Left After Real Attack Surface Reduction

Let's walk through the adversary's day after landing in an environment with intelligence-driven application control:

Initial access succeeds. Maybe phishing worked. Maybe they exploited a vulnerability. They're on the endpoint.

Execution attempt: blocked. They try to run mshta.exe to execute their payload. Denied. WDAC policy blocks the abuse pattern.

Download attempt: blocked. They try certutil -urlcache to pull down their second-stage tooling. Denied.

Persistence attempt: blocked. They try to install ScreenConnect for long-term access. Denied. Unauthorized RMM tool.

Alternative execution: blocked. They try wscript.exe with a malicious script. Denied.

WMI execution: blocked. They attempt lateral movement through wmic process call create. Denied.

What's left? Maybe they poke around with net.exe commands. Maybe they enumerate local users. Maybe they try to read files they shouldn't access.

But here's the thing: they just made a lot of noise accomplishing nothing.

Every one of those blocked attempts generated an event. Your security team sees the pattern: failed execution, failed download, failed persistence, failed lateral movement. All within seconds of each other. All from the same compromised user.

You know exactly where the adversary is. You know they're stuck. You know they have no viable path forward.

And your MTTP? Under 10 seconds from initial access. Not under 10 seconds to detect. Under 10 seconds to functionally end the intrusion.

"But What About..."

We get this question constantly: "What if the adversary finds something you don't block?"

Sure. Maybe they run net user to enumerate accounts. Maybe they read some files. Maybe they try some discovery commands that aren't on the block list.

Three responses:

First, the data doesn't support the "sophisticated adversary" fantasy. Real-world attacks overwhelmingly use the same techniques because those techniques work and adversaries are lazy. The LOLBAS project exists because adversaries keep reaching for the same binaries. Block those, and you've blocked what actually shows up in incidents.

Second, the noise-to-impact ratio inverts completely. Without their standard toolkit, adversaries have to get creative. Creative means slow. Creative means trial and error. Creative means more noise per unit of actual impact. Every failed attempt is another signal that something is very wrong.

Third, even if they find something - so what? They've lost their execution mechanisms. They've lost their persistence mechanisms. They've lost their tooling delivery mechanisms. What are they going to do? Enumerate users manually and hope you don't notice?

The adversary who needs 47 attempts to accomplish what normally takes 3 is an adversary who's about to get caught.

Left of Boom - Except There Is No Boom

Security teams love talking about "left of boom" - the idea of catching attackers before the explosion. Before the ransomware detonates. Before the exfiltration completes. Before the damage is done.

Here's the better question: what if there's no boom at all?

With sufficient attack surface reduction, the adversary's attack chain breaks so early that there's nothing to detect in the traditional sense. No lateral movement to trace. No payload to analyze. No C2 traffic to block at the network edge. No incident to respond to.

The boom doesn't happen because the fuse got wet.

Your MTTD is zero because nothing bad happened to detect. Your MTTR is zero because nothing bad happened to respond to. Your incident count is zero because nothing bad happened to investigate.

The attack fell flat. It was denied. It's over. The adversary never meaningfully landed.

Stop Detecting the Same Attacks Over and Over

Your SOC will investigate PowerShell abuse today. And tomorrow. And next week. And next month.

Unless you stop letting PowerShell abuse succeed in the first place.

Your threat hunters will find RMM tool installations that don't match IT's inventory. They'll escalate. They'll investigate. They'll discover the same pattern of unauthorized remote access they discovered last quarter.

Unless you block unauthorized RMM tools before they install.

The question isn't whether you can detect these techniques. You can. You have been. You'll continue to.

The question is why you're still detecting them instead of preventing them.

Mean Time to Prevent is the metric that matters.

Threat-driven application control blocks the abuse patterns that show up in real attacks, and you've reduced your attack surface to the point where adversaries have nowhere meaningful to go. They can poke around. They can enumerate. They can fail loudly and repeatedly.

But they can't execute. They can't persist. They can't move. They can't accomplish their objectives.

That's not detection. That's prevention. And prevention wins.

Want to see what MTTP looks like in practice? Book a demo and we'll show you exactly how intelligence-driven blocking stops the techniques that actually matter - before your SOAR playbook ever kicks off.

Keep up with how modern attacks actually work and how to prevent them. Subscribe to the MagicSword newsletter for practical research, real-world attack tradecraft, and prevention-focused intelligence.