From Detection to Prevention: The Audit-to-Enforce Loop

The Top 10 told you what to block. This shows you how to actually get there. Audit-then-enforce, cohort math, and the principle that three legacy holdouts don't stop you from blocking the other 1,997.

One endpoint doesn't get to vote on what happens to the other 1,997

That is the whole blog. Everything below is how to actually run it.

The Top 10 blog made the argument. The techniques haven't changed in a decade. Most are blockable today. Get off the rat wheel.

The follow-up question I get every time is always the same:

"How? I can't just flip mshta off across 2,000 endpoints. One HR app still uses it. I have a customer on a 4-year-old build of something I can't touch. What am I supposed to do, break the business to prove a point?"

No. You're supposed to run the loop.

Detection is not the enemy of prevention. Detection is the scout. Every audit hit on a Top 10 primitive is a free piece of intel telling you exactly what to block next, who's still using it, and why.

The detection-first crowd says write more detections, hire more analysts, tune more rules. Forever.

The prevention-first crowd says use detection to find the holdouts, fix the holdouts, then enforce.

This is the loop.

The Loop

Flowchart showing an application control decision process from observing risky system primitives in audit mode to identifying usage, deciding on upgrades or exceptions, enforcing controls, and re-auditing to reduce exposure over time.

That is the whole thing.

Observe. Put the primitive in audit mode. Don't block yet. Just watch.

Identify. When the audit fires, pull the metadata. Parent process. User. Endpoint. Department. How many endpoints triggered this in the last 30 days? One? Three? Two thousand?

Decide. This is the only step that takes judgment. The other three are mechanical. Decision surface below.

Enforce. Push the policy. Re-audit. Confirm the holdouts shrink, not grow.

Run the loop. Pick the next primitive. Run it again.

The worked example: mshta and the legacy HR app

Real scenario. Anonymized. You will recognize it.

You flip mshta.exe into audit mode across the fleet on a Monday. By Friday you have 47 audit events. That number looks scary.

Pull the metadata.

42 of 47 events: same parent process. AcmeBenefits.exe. Version 4.2.
3 endpoints triggered all 42. All HR. Specifically: benefits enrollment team.
5 of 47 events: random PowerShell parents. Probably noise. Maybe not. Flag for the SOC.

Now the question is no longer "should I block mshta?"

The question is: what does AcmeBenefits 5.x look like?

Five minutes on the vendor's release notes: 5.x dropped the HTA-based help dialogs in 2023. Three years ago. The 3 HR endpoints are sitting on a version that has been obsolete since before half your fleet was provisioned.

You have three options. Pick one.

Option A. Push AcmeBenefits 5.x to the 3 HR endpoints. Enforce mshta block fleet-wide tomorrow. Cost: 30 minutes of IT work.

Option B. Carve a narrow application control exception. Allow mshta to run only on those 3 specific endpoint IDs. Enforce the mshta block everywhere else. Cost: one policy rule.

Option C. Wait. Don't enforce. Keep auditing. Hope nothing bad happens. This is the option detection-first picks every time. Don't pick Option C.

The other 1,997 endpoints? Mshta has zero legitimate use on them. Block it. This week.

One legacy app on three endpoints does not get to vote on what happens to the other 1,997 endpoints.

That is the entire operating principle.

The decision surface

Plot every audit hit against two axes.

Cybersecurity endpoint management decision matrix showing how organizations should handle software upgrades, endpoint blocking, and migration strategies based on the number of affected endpoints and whether there is a legitimate business need. The 2x2 framework includes scenarios for few or many endpoints with or without legitimate need, recommending actions such as fleet-wide blocking, staged migration, narrow policy exceptions, endpoint enforcement waves, and audit-only controls for enterprise IT and security operations teams.

The trap is assuming every audit hit is the top-right quadrant by default. Most are not. Most are bottom-row. Bottom-row gets blocked this week. Top-left gets a narrow exception or a vendor upgrade. Only top-right earns a real project.

The detection-first instinct treats every audit hit as top-right and ships zero policies. The loop says most are not top-right. Block the easy quadrants this week and the alert volume on those primitives collapses by next month.

Who goes first: the attack surface heatmap

The other thing detection gives you for free is an attack surface heatmap.

Not every endpoint deserves the same prevention priority on day one. Some endpoints get punched in the face by phishing 50 times a day. Some endpoints have not seen an inbound email in a year.

If you have to roll prevention out in waves, the waves are obvious.

Cybersecurity rollout roadmap infographic showing a three-wave phishing and attack-surface reduction strategy for enterprise security teams. Wave 1 (Week 1) focuses on highest-risk departments including Finance & AP, Customer Support, HR, Executive Assistants, and Help Desk due to invoice fraud, phishing, vishing, and impersonation threats. Wave 2 (Month 1) targets privileged access users such as Domain Admins, Cloud Admins, DevOps with production access, and employees holding long-lived API tokens to prevent phish-to-domain-admin escalation. Wave 3 expands security enforcement to general staff, engineering workstations, and locked-down kiosks as residual cyber risk decreases. Flowchart design with red, yellow, and green stages connected by downward arrows, illustrating phased enterprise cyber defense implementation and identity security prioritization.

Wave 1 is the cohort where the loop should run fastest and tightest. Finance opens vendor invoices. That is their job. AP cannot stop opening attachments from people they have never heard of because the business depends on them opening attachments from people they have never heard of.

The seats with the highest inbound email volume and the highest phishing exposure are the seats where audit-to-enforce should run on a weekly cadence, not quarterly. Strict LOLBAS enforcement. Strict LOLRMM enforcement. Cert Graveyard blocking on. Driver blocklist on.

The CHATTY SPIDER case in the Top 10 blog landed on a help-desk seat via Microsoft Quick Assist and went from initial access to attempted exfil in four minutes. The help desk is Wave 1, not Wave 3. Treat it accordingly.

Detection-first runs the same alert volume on every endpoint regardless of attack surface. Prevention-first triages by exposure and shrinks the riskiest cohort first.

Related: AI Makes Getting In Easy. What Happens Next Is the Real Problem

Why this drives MTTP down (and keeps it down)

Every time you close the loop on one primitive, you have done three things at once.

You shrunk the attack surface for that primitive across most of the fleet.
You built the muscle memory to close the loop faster on the next primitive.
You taught your enforcement plane that audit-then-enforce is the default, not the exception.

The first time you run the loop on mshta, it might take 2 weeks. Pull metadata, find the legacy app, push the upgrade, deploy the policy, re-audit, confirm.

The second time, on wscript, takes 5 days. You already know how to pull the cohort. You already trust the audit data. You already have the exception template. You already have the change-management process baked.

By the time you are running the loop on the 15th primitive, time-to-enforce is hours, not weeks.

That is MTTP dropping in real time.

Every closed loop is a permanent reduction in the time it takes to prevent the next thing. MTTD does not compound. MTTP does. The loop you ran on mshta makes the wscript loop cheaper, which makes the regsvr32 loop cheaper, which makes the rundll32 loop cheaper, which makes the RMM cohort cheaper.

The detection-first model has no compounding. Every new technique starts the analytic, tuning, and false-positive cycle from scratch. Same workflow. Same alerts. Same Tuesday-morning ticket. Forever.

Related: Stop Detecting. Start Preventing. The Case for Mean Time to Prevent (MTTP)

What detection is actually for

Detection still matters. It just stops being the thing carrying the weight.

Once the loop has run across the Top 10, the audit volume on those primitives collapses. Run the loop on mshta, wscript, regsvr32, rundll32, and the unsanctioned RMM cohort, and the signal-to-noise ratio inverts. The alerts that survive are not the same alerts your SOC was drowning in last quarter. They are the residue. The novel persistence. The creative tradecraft that earned its way through the blocklist. The actually-hard problems.

That is the work detection engineers were hired to do in the first place.

The closing question

If you are auditing your Top 10 primitives right now, and you can name the parent process, user count, and endpoint count for every audit hit: you are already on the loop. Go pick the easy quadrant and ship a policy this week.
If you cannot name those things, here is the only question that matters:

Pick one primitive from the Top 10. Put it in audit mode today. By Monday morning, what is the parent process, the user cohort, and the endpoint count for every audit event, and which quadrant does each hit land in?

If the answer is "we don't have audit mode," that is the tooling gap. If the answer is "we have audit mode but no one looks at it," that is the workflow gap. If the answer is "we look at it but never enforce," that is the courage gap.

Each one is fixable. Each one is what MTTP measures.

One endpoint does not get to vote.

Run the loop.

Want to see audit-to-enforce running on real fleets? Book a demo and we'll show you the cohort view, the decision surface, and the policy push, on actual customer data.

Keep up with how modern attacks actually work and how to prevent them. Subscribe to the MagicSword newsletter.

Summary

Detection is not the opposite of prevention, it is the scout for it. Every audit hit on a Top 10 LOTL primitive (mshta, wscript, regsvr32, RMM tools, vulnerable drivers) tells you exactly what to block next, who is still using it, and why. This post walks the iterative audit-to-enforce loop: observe in audit mode, identify the parent process and endpoint cohort, decide whether to push a vendor upgrade, carve a narrow WDAC exception, or block fleet-wide, then enforce and re-audit. It introduces the operating principle that a 3-endpoint legacy holdout does not get to veto prevention on the other 1,997 endpoints, and shows how to prioritize enforcement by attack surface so the highest-risk seats (finance, AP, HR, executive assistants, help desk) get protected first. Run the loop and Mean Time to Prevent (MTTP) drops with every iteration.

FAQ's

What is the difference between Mean Time to Detect (MTTD) and Mean Time to Prevent (MTTP), and why does MTTP compound while MTTD does not?

MTTD measures how fast you notice an attack that's already happening. MTTP measures how fast you eliminate the conditions that allow it to start. MTTD doesn't compound, every new technique resets the detection cycle from scratch. MTTP compounds because every primitive you block makes the next block cheaper, faster, and easier to enforce. The loop you ran on mshta makes the wscript loop cheaper, which makes the regsvr32 loop cheaper, and so on.

How does an audit-then-enforce workflow with Application Control actually work in practice when rolling out a LOLBAS block (for example, mshta.exe) across a fleet?

Put the primitive in audit mode, don't block yet. Collect events for 30 days. Pull the parent process, user, department, and endpoint count for every hit. Identify whether the use is legitimate or residual. Block everywhere there's no legitimate use. Carve a narrow exception or push a vendor upgrade for the small cohort that needs it. Enforce, re-audit, confirm holdouts are shrinking. Pick the next primitive and repeat.

How do I identify which application is generating mshta, wscript, or regsvr32 audit events on my endpoints, and what metadata should I be pulling on every audit hit?

Every audit event should give you the parent process name and path, the user account, the endpoint name, the department, and a timestamp. If 42 of 47 events share the same parent process, that's your legitimate use case and it's almost certainly a legacy app running on a handful of endpoints. That parent process name tells you exactly which vendor to call and which version drops the dependency.

When a small cohort of endpoints has a legitimate need for a LOTL primitive, how do you write a narrow application control exception without weakening fleet-wide enforcement?

Scope the exception as tightly as possible by specific endpoint ID, specific parent process path, and specific signing certificate. An exception that says "allow mshta only when launched by AcmeBenefits.exe on these 3 endpoints" is not a gap. A blanket exception that allows mshta anywhere a certain app is installed is. The narrower the exception, the smaller the blast radius if that cohort is targeted.

Which user cohorts have the highest attack surface for LOTL and phishing-driven intrusions, and why should prevention be enforced on those endpoints first?

Finance and accounts payable open vendor invoices all day, that's their job and attackers know it. Customer support handles high attachment volume constantly. HR receives unsolicited files by design. Executive assistants are targeted for VIP impersonation. Help desk is targeted for vishing and Quick Assist abuse, CHATTY SPIDER went from a Quick Assist session to attempted exfiltration in four minutes. These seats get the tightest enforcement first, on a weekly audit cadence, not quarterly.