Microsoft starts removing WMIC tool used by cybercriminals

# Microsoft Finally Kills WMIC — Ransomware Gangs Lose a Decade-Old Skeleton Key

For years, the ransomware operator's pre-encryption checklist had a reliable second step: run wmic shadowcopy delete. Shadow Volume Copies gone, recovery options evaporated, ransom demand dispatched. One command. Signed by Microsoft. Trusted by Windows. Blocked by almost nothing.

That command no longer works on new Windows 11 installs.

Microsoft confirmed this week that the Windows Management Instrumentation Command-line tool — WMIC — has been removed from Windows 11 versions 24H2 and 25H2, and from current beta builds. It's not hidden. It's not disabled. It's not a setting you can flip. It's gone.

## A Decade of Deprecation, Finally Landing

To call this a surprise would be generous. Microsoft first deprecated WMIC in Windows Server 2012 back in 2016. It followed up on the client side in 2021 with Windows 10 21H1. By 2022, WMIC had been demoted to a Feature on Demand in Windows 11 22H2 — technically still available, but no longer installed by default. January 2024 brought the formal announcement that removal was coming with 25H2.

And yet: the tool outlived three generations of "we're deprecating this" notices. Organizations kept depending on it. Scripts kept calling it. Attackers kept loving it.

The reason attackers loved WMIC isn't complicated. It's a LOLBIN — a living-off-the-land binary, meaning a Microsoft-signed, legitimately installed executable that threat actors abuse for malicious purposes. The appeal is obvious: security tools traditionally trusted signed Windows components. WMIC let attackers query installed security software, uninstall AV products, add exclusions to Microsoft Defender, and — that shadow copy deletion trick — disable recovery before triggering the encryptor. All of it wrapped in a tool that looked like an IT administrator doing their job.

## What Ransomware Operators Actually Did With It

The shadow copy deletion use case gets the most ink, but the full picture is worse. A typical ransomware intrusion in the WMIC era looked something like this:

WMIC wasn't a nice-to-have for attackers. For commodity ransomware operators especially — groups running affiliate models with less technically sophisticated affiliates — it was a reliable, well-documented, widely-scripted attack tool. The removal won't cripple sophisticated threat actors, but it raises the floor on what even moderately capable attackers can automate without custom tooling.

## The Part Microsoft Is Careful to Say

Microsoft is clear that WMI itself is not going anywhere. The command-line wrapper is dead; the underlying Windows Management Instrumentation system — the COM API, the .NET libraries, the PowerShell cmdlets like Get-WmiObject and Get-CimInstance — all remain fully functional.

That's the right call. WMI is deeply embedded in enterprise Windows administration. Removing the API would break thousands of legitimate tools and automation pipelines. What Microsoft is killing is the lowest-friction path to WMI for someone who found their way into a box and wants to run a quick command without writing code.

For IT administrators running WMIC-dependent scripts, Microsoft's recommendation is straightforward: migrate to PowerShell. The Get-WmiObject, Get-CimInstance, and Invoke-WmiMethod cmdlets cover the same ground. The migration is mechanical if not always fast.

## The Obvious Successor Problem

Here's what none of the Microsoft press materials say plainly: PowerShell is also a LOLBIN.

PowerShell has its own rich history as an attacker-preferred post-exploitation tool — Empire, PowerSploit, countless commodity loaders. Microsoft has spent years hardening PowerShell logging, adding Constrained Language Mode, improving Script Block Logging and AMSI integration. Those improvements are real and meaningful.

But redirecting administrators — and inevitably, attacker documentation — toward PowerShell doesn't eliminate the LOLBIN problem. It moves it. The question isn't whether WMIC gets removed; it's whether the replacement environment is meaningfully more defensible. For sophisticated attackers, the WMIC removal is a minor inconvenience. For the affiliate-model ransomware operator running commodity toolkits, it genuinely raises costs.

## What the Timeline Tells You About Microsoft's Pace

The gap between "deprecated in 2016" and "removed in 2026" is exactly ten years. During that decade, WMIC was used in hundreds of documented ransomware campaigns, countless intrusions, and untold numbers of commodity malware infections.

This is a structural problem with how legacy removal works at Microsoft's scale. The installed base is enormous. Enterprise dependencies are deep and often undocumented. Legal and support obligations create inertia. So tools stick around long past their security expiration date, and adversaries are very good at reading Microsoft's own deprecation notices and exploiting the long tail.

The slower the cleanup, the longer the attack surface lives. Ten years is a long time to sign a threat actor's paycheck.

---

## HackWire Analysis

The WMIC removal is being covered as a security win — and it is — but the framing undersells the bigger story, which is about how LOLBins work as a class of problem.

Living-off-the-land techniques emerged as a dominant attacker strategy precisely because signature-based detection and allowlisting were becoming more effective against custom malware. If you're running Microsoft-signed binaries in ways that look like legitimate administration, you're invisible to a large percentage of deployed security controls. WMIC was close to perfect: ubiquitous, trusted, well-documented, and capable of reaching deep into Windows internals.

The removal matters most at the low end of the attacker sophistication spectrum. The most dangerous threat actors — nation-state groups, sophisticated ransomware developers — wrote their own WMI interfaces years ago, or use PowerShell with enough obfuscation to sidestep logging. What WMIC removal actually does is break the commodity playbooks: the affiliate who copied a Cobalt Strike tutorial, the script kiddie running a leaked ransomware builder, the lower-tier intrusion that depends on cut-and-paste WMIC commands from a threat actor forum post.

That's still worth doing. A lot of the real-world damage in corporate ransomware incidents comes from exactly these operators.

But defenders shouldn't mistake WMIC removal for a structural solution. Every Windows environment still has PowerShell, certutil, mshta, regsvr32, and a roster of other signed tools that appear in attacker TTPs weekly. The Blue Report data cited in Microsoft's own coverage is instructive: once attackers are operating with valid credentials, only 37% of their subsequent actions are blocked. WMIC removal clips one branch. The tree is still standing.

The right defensive response to this news isn't celebration — it's auditing your existing WMIC-dependent scripts before 25H2 forces the issue, and investing in behavioral detection for the PowerShell patterns that will take WMIC's place in the commodity toolkit.

— HackWire Editorial

---

## Related Coverage