Microsoft apaga o WMIC do Windows e derruba aliado do ransomware

Microsoft confirmou a remoção definitiva do WMIC do Windows, e a mudança chega com a atualização 26H2. Além disso, a empresa fecha o último caminho que ainda trazia o utilitário de volta. Ou seja, o pacote opcional que reinstalava a ferramenta some junto. Portanto, quem mantém scripts antigos precisa abrir o inventário agora.

O WMIC, sigla para Windows Management Instrumentation Command line, nasceu como atalho para consultar hardware, sistema e processos direto do prompt. Durante anos, ele foi a resposta rápida para descobrir número de série, discos, serviços e software instalado. Hoje, porém, ele carrega mais risco do que utilidade.

Microsoft aposentou o WMIC em quatro etapas ao longo de dez anos

A remoção aconteceu em etapas. Primeiro, em 2016, o utilitário perdeu o status de recurso ativo nas versões de servidor. Depois, o Windows 10 na atualização 21H1 marcou a ferramenta como descontinuada para consumidores, e o suporte oficial parou ali. Em seguida, o Windows 11 25H2 tirou o acesso direto do usuário comum. Ainda assim, traços do WMIC continuaram no sistema, porque a empresa mantinha um pacote de compatibilidade sob demanda. Agora, com o 26H2, esse pacote também desaparece. A atualização segue em fase de Insider Release Preview, então há uma janela curta para agir.

Um binário assinado que virou ferramenta de trabalho do ransomware

A empresa cita dois motivos centrais: baixa utilidade e superfície de ataque. O segundo pesa mais para quem trabalha com segurança. Afinal, o wmic.exe é um binário assinado, presente por padrão e com permissão para consultar e alterar o sistema. Por isso, ele aparece com frequência em cadeias de ataque do tipo living off the land.

Na prática, operadores de ransomware usavam o utilitário para mapear o antivírus instalado, apagar cópias de sombra, criar processos remotos e mover comandos entre máquinas. Além disso, a técnica tem entrada própria no MITRE ATT&CK, sob o identificador T1047. Como resultado, times de detecção passaram anos escrevendo regras para um binário que a própria fabricante já considerava morto.

Microsoft aponta o PowerShell como substituto direto

O caminho oficial de migração passa pelos cmdlets CIM. Assim, cada consulta antiga ganha um equivalente moderno. Veja os casos mais comuns do dia a dia.

wmic bios get serialnumber
Get-CimInstance Win32_BIOS | Select-Object SerialNumber

wmic os get caption,version
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version

wmic logicaldisk get name,size,freespace
Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID, Size, FreeSpace

wmic process list brief
Get-CimInstance Win32_Process | Select-Object Name, ProcessId, CommandLine

wmic qfe list
Get-HotFix

wmic csproduct get uuid
(Get-CimInstance Win32_ComputerSystemProduct).UUID

wmic service where "state='Running'" get name
Get-CimInstance Win32_Service -Filter "State='Running'" | Select-Object Name

Vale um alerta sobre a classe Win32_Product. Ela dispara reconfiguração de pacotes MSI a cada consulta, portanto prefira ler as chaves de desinstalação no registro. Outro ponto merece atenção: o Get-WmiObject saiu do PowerShell 7, logo migre direto para o Get-CimInstance e evite retrabalho.

O WMI continua vivo, e essa diferença define o tamanho do seu esforço

A infraestrutura WMI segue viva no Windows, com repositório, provedores e classes intactos. O que sai de cena é a interface de linha de comando herdada. Dessa forma, seu código em C#↳C#68 conteúdosNovidades do C# 8.0: Default Interface MembersDev (Back & Front) · jun 2019C# 8.0 – Conheça suas novas funcionalidadesDev (Back & Front) · mai 2019Novidades do C# 8.0: Switch ExpressionsDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) →, Python, Go ou PowerShell que conversa com o WMI via API continua funcionando normalmente. Já os scripts .bat e .cmd que chamam wmic.exe falham na primeira execução.

Essa distinção importa na hora de estimar esforço. Afinal, o trabalho se concentra em automação legada, e não na stack de aplicação.

Microsoft deixa um passivo escondido em instaladores e pipelines

Grande parte das quebras aparece longe do terminal do administrador. Instaladores antigos, por exemplo, chamam o wmic para checar arquitetura, licença ou versão do sistema. Agentes de RMM e MDM fazem o mesmo para montar inventário de hardware.

Scripts de logon em GPO também entram na lista, assim como imagens de máquina e runners de CI que rodam em Windows. Inclusive, ferramentas de remoção de antivírus de terceiros costumam depender do utilitário. Como consequência, a falha aparece em produção, e não no ambiente do time.

Microsoft dá uma janela curta, então comece a caça hoje

Comece pela varredura de repositórios com o Select-String em busca do termo wmic. Em seguida, estenda a busca para imagens de VM, runners de CI e pacotes de instalação.

Select-String -Path .\**\*.ps1,.\**\*.bat,.\**\*.cmd -Pattern "wmic" -List

Depois, ative a auditoria de criação de processos e caçe o evento 4688 com wmic.exe na linha de comando. O Sysmon com evento 1 cumpre o mesmo papel e entrega mais contexto. Assim, você descobre quem ainda chama a ferramenta em produção.

Por fim, reescreva cada chamada com Get-CimInstance e valide em um anel de Insider antes do rollout geral. Cobre também os fornecedores de software que rodam no seu parque, porque muitos ainda não publicaram correção.

Microsoft segue podando o legado, e a conta chega para quem mantém código antigo

A limpeza do WMIC entra em um movimento maior de poda do legado no Windows. Executivos da empresa reconheceram publicamente as críticas sobre desempenho, e a resposta veio na forma de cortes em recursos antigos. Para quem escreve automação, o recado fica claro: código que depende de utilitários descontinuados tem prazo de validade. Portanto, trate a migração como dívida técnica com data marcada.

Acompanhe nosso perfil no Instagram!