Here’s a fun way to start a Monday: you fire up a PowerShell script you’ve run many times — maybe it provisions a batch of AD accounts, maybe it sweeps stale GPOs — and it simply vanishes. No error dialog. No event log entry. Quarantine warnings not provided, either. The file is just gone, like it offended someone. Which, as it turns out, it did.

The culprit? Recent changes to Microsoft Defender’s Attack Surface Reduction (ASR) rules — specifically, tightened enforcement arrived with Windows 11 23H2. And it has only grown more aggressive in 24H2/25H2. If you manage Windows endpoints for a living, this one deserves some notice.

How and Why Windows Defender May Delete PowerShell Scripts

Microsoft has been steadily ratcheting up ASR rules over the past couple of years. Two rules in particular have become dramatically more assertive: “Block execution of potentially obfuscated scripts” and the newer “Block execution from known script interpreter paths” (rule GUID 9e6c4e5a-1037-4377-92f4-2db0f7e629e7). The latter now matches elevated execution paths that have nothing to do with user shell startup, which means your perfectly legitimate admin scripts can get caught in this net.

Here’s the insidious part. Starting with the 23H2 and 24H2 Defender sensor updates, script-blocking ASR rules are now enforced at the kernel driver layer (via WdFilter.sys, Defender’s minifilter drive) — before process creation even occurs. That means scripts launched via WMI, COM+, or scheduled tasks can be silently killed or quarantined without generating an event log entry. You get no breadcrumbs. The script just doesn’t run, and the script file itself may disappear.

This has caused a wave of false positives hitting legitimate PowerShell scripts, SCOM monitoring agents, Active Directory management tools, and enterprise deployment scripts. If you experienced déjà vu reading that, you’re not wrong. In January 2023, a faulty Defender signature update (builds 1.381.2134.0 through 1.381.2163.0) caused the “Block Win32 API calls from Office macro” ASR rule to go haywire and mass-delete Start menu and taskbar shortcuts across enterprises. Microsoft had to ship a dedicated recovery script (AddShortcuts.ps1) and a taskbar repair utility to clean up the mess. Consider this the sequel — quieter but just as disruptive.

How to Recover Deleted or Quarantined Files

If Defender has eaten your scripts, don’t panic. Work through these steps in order:

1. Check Defender’s quarantine via the GUI. Open Windows Security → Virus & threat protection → Protection history. Filter by “Quarantined Items.” If your script is there, select it and choose Restore.
2. Browse the quarantine folder directly. Quarantined files live in C:\ProgramData\Microsoft\Windows Defender\Quarantine. They’re encrypted, but they show that Defender took them.
3. Use PowerShell for deeper inspection. Run Get-MpThreatDetection and Get-MpThreat to list recent detections and see exactly which ASR rule fired. To restore from the command line, use MpCmdRun.exe -Restore -ListAll followed by MpCmdRun.exe -Restore -Name <ThreatName>.
4. Add targeted exclusions. Use Add-MpPreference -ExclusionPath “C:\Scripts” or configure per-rule exclusions via Intune or Group Policy to prevent recurrence.
5. Restore from backup. If the file is gone from quarantine entirely, fall back to File History, system restore points, or your backup solution of choice.
6. For enterprise environments: check the Microsoft 365 Defender portal’s quarantine and Action Center — detections from managed endpoints often surface there even when local logs stay silent.

That leads to what I’ll call a “Pro tip” for admins to consider. Before enabling any new or aggressive ASR rule, set it to Audit mode first (value 2) rather than Block mode (value 1). Audit mode logs what would be blocked without actually deleting anything. Run it for a week or two, review the results in Event Viewer under Microsoft → Windows → Windows Defender → Operational (Event IDs 1121 and 1122), and then flip to Block. This single practice would have prevented most of the heartburn described above.

You Win Some, You Lose Some…

Let me be clear: Defender’s tighter ASR rules are genuinely good for security. Blocking script execution at the kernel level before a process even spawns is a meaningful defense against fileless malware and living-off-the-land attacks. But Microsoft badly needs to improve logging transparency when scripts get blocked at the kernel driver layer. Silent enforcement with no audit trail isn’t “defense in depth” — it’s “debugging in the dark.”

Until that gets fixed, the playbook is straightforward: keep good backups, audit before you block,  and test ASR changes in a staging ring before pushing to production. Remember: your antimalware solution is only as smart as its latest signature update. As the January 2023 shortcut debacle proved, even Microsoft’s own rules can bite the hand that feeds them. I think these just bit me. Don’t let it happen to you!

But Wait! There’s More…

In my usual ElevenForum readover this weekend, I stumbled on a thread that mentioned scripts — and an encrypted password file — disappearing from the poster’s Windows 11 PC. As I responded to that thread “This is deeply disturbing.” It just doesn’t seem right that Defender can cause scripts (and more) to vanish via rule enforcement. You need to steer around this pothole until it gets filled. Not an unfamiliar strategy, alas, here in Windows-World.