I used WMIC last week during a client engagement. Something like this, to clear an old redistributable off a batch of machines:
wmic product where "name like 'Microsoft Visual C++ 2010 Redistributable%%'" call uninstall /nointeractive
That command no longer has a future. Microsoft has removed WMIC from new installations of Windows 11 versions 24H2 and 25H2, and it is no longer available as a Feature on Demand. This is the end of a long goodbye: deprecated in Windows Server 2012 back in 2016, deprecated again in Windows 10 21H1, demoted to an optional feature in Windows 11 22H2, and now gone.
If you have muscle memory for these commands, you are not alone and you are not wrong to have used them. But the machines your scripts run on are changing underneath you, and the sensible response is to find out where WMIC still appears in your estate before a 25H2 rollout finds out for you.
Why it is going: the living-off-the-land problem
WMIC is a signed Microsoft binary that ships with Windows and can query, modify and execute. That combination is exactly what an attacker wants, because it means the interesting part of an intrusion can be carried out by a tool the defender already trusts and the allow list already permits. In the trade it is a living-off-the-land binary, and WMIC has been one of the most reliably useful for years.
The tactics are well documented and depressingly consistent.
Destroying recovery options before encryption. Ransomware routinely deletes Volume Shadow Copies so that the victim cannot simply roll back, and WMIC has long been one of the ways it is done. If your backup strategy assumes shadow copies will be there afterwards, it was never a backup strategy.
Finding out what is watching. Querying the SecurityCenter2 namespace lists installed antivirus products by name. From the attacker’s point of view, that is reconnaissance: know the product, know its weaknesses, know whether it is worth attempting to disable.
Weakening the defences that remain. Adding exclusions so that a payload lands in a directory nothing scans, or uninstalling protection outright.
Reconnaissance in general. Operating system version, installed patches, running processes, logged-on users, hardware identifiers, network configuration. All of it available, all of it fast, none of it requiring a tool to be brought onto the machine.
Remote execution and lateral movement. WMIC can create processes on remote machines given credentials, which makes it a straightforward way to move sideways without dropping anything new on disk.
Removing the binary breaks the convenience of all of that. It does not break the capability.
The honest bit: WMI is not going anywhere
Here is the part that will be skipped in most coverage of this change. WMIC is being removed. WMI is not.
Everything WMIC did, the underlying Windows Management Instrumentation service still does, and it remains reachable through PowerShell, through the COM interface, through .NET, and through any scripting language that can talk to either. An attacker who used wmic shadowcopy delete can achieve the same outcome with a couple of lines of PowerShell, or by calling the same interface directly from their own tooling. Mature malware has been doing exactly that for years, precisely because WMIC’s deprecation has been signposted since 2016.
So this is a genuine security improvement of a specific and limited kind: it removes a convenient path used by commodity malware, scripts copied from forums, and attackers who are not particularly sophisticated. That is a real population and it is worth inconveniencing. It is not a defensive control, and anyone selling it to you as one is padding a newsletter.
The useful consequence for defenders is different, and better. Once WMIC is gone from your estate, its appearance becomes a signal. A process called wmic.exe executing on a machine that shipped without it means somebody brought it there. That is a far cleaner detection than trying to distinguish legitimate WMIC use from malicious use, which was always the problem with monitoring it.
What replaces it
PowerShell, and specifically the CIM cmdlets. The mapping is more direct than it looks.
| What you ran in WMIC | PowerShell equivalent |
|---|---|
wmic os get caption,version | Get-CimInstance Win32_OperatingSystem |
wmic qfe list | Get-HotFix |
wmic process list brief | Get-CimInstance Win32_Process |
wmic process call create "cmd.exe" | Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine='cmd.exe'} |
wmic logicaldisk get name,freespace | Get-CimInstance Win32_LogicalDisk |
wmic nic get name,macaddress | Get-CimInstance Win32_NetworkAdapter |
wmic csproduct get uuid | Get-CimInstance Win32_ComputerSystemProduct |
wmic service where started=true get name | Get-Service | Where-Object Status -eq 'Running' |
wmic useraccount get name,sid | Get-LocalUser or Get-CimInstance Win32_UserAccount |
wmic /node:HOST ... | New-CimSession -ComputerName HOST, then pass with -CimSession |
wmic product get name | See below, and do not use Win32_Product |
The uninstall command, done properly
The direct translation of what I ran works:
Get-CimInstance -ClassName Win32_Product -Filter "Name LIKE 'Microsoft Visual C++ 2010 Redistributable%'" |
Invoke-CimMethod -MethodName Uninstall
Two notes on it. In a batch file you double the percent sign, as in my original command; at an interactive prompt or in PowerShell you use one. That single difference has cost more people more time than the entire deprecation will.
More importantly: avoid Win32_Product where you can, and that applies equally to the WMIC command I opened with. Enumerating that class triggers a consistency check against every installed MSI package, which is slow and can cause Windows Installer to begin repairing products you never asked it to touch. It is one of those things Windows administrators learn once, usually at an inconvenient moment.
The better approach reads the uninstall registry keys instead:
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths |
Where-Object DisplayName -like 'Microsoft Visual C++ 2010 Redistributable*' |
Select-Object DisplayName, PSChildName, UninstallString
Check what that returns, then uninstall by product code:
Start-Process msiexec.exe -ArgumentList '/x','{PRODUCT-CODE-HERE}','/qn','/norestart' -Wait
Slower to write, considerably faster to run, and it does not provoke Windows Installer into repairing half the estate.
Search your scripts, scheduled tasks, build images, task sequences and remote management tooling for the string wmic before 25H2 reaches your estate. Rewrite what you find using the CIM cmdlets. Then treat any later appearance of wmic.exe as something to investigate, because on a modern build it did not arrive by itself.
Where this bites in practice
The breakage will not come from administrators typing commands. It will come from things nobody has looked at in years: a login script written in 2014, a task sequence in your deployment tooling, a monitoring check in a remote management platform, a vendor’s installer that shells out to WMIC to detect prerequisites, an inventory script that quietly returns nothing rather than failing loudly.
That last one is the real risk. A WMIC command on a machine without WMIC does not produce a useful error in the middle of a script; it produces an empty result. Inventory that silently returns nothing looks identical to inventory that found nothing wrong.
If your organisation relies on scripted management, this is worth an afternoon now rather than a puzzled fortnight later.
The wider point
WMIC is the third or fourth thing in recent memory to be removed from Windows because attackers used it more effectively than administrators did. That is the direction of travel, and it is broadly correct: reducing what is available by default reduces what can be abused by default.
It also means the ground moves under anyone whose configuration was written once and never revisited. Which is the same argument as keeping systems patched within 14 days, and the same argument behind hardening settings that Microsoft ships disabled: a build that was correct three years ago is not necessarily correct now, and nothing tells you except looking.
If you would rather someone independent looked at what your estate is actually running, get in touch or call 01722 445972.