Depois de instalar o patch cumulativo KB5051989 (fev/2025) no Windows 11 23H2, muitos administradores relataram que o AppLocker passou a permitir a execução de arquivos renomeados – um risco crítico em quiosques corporativos. Saiba o que mudou, como mitigar e quais canais seguir até a correção oficial.
Visão geral do problema
Ambiente afetado: Windows 11 23H2 (build 22631.4890) configurado como kiosk multi‑app.
Sintoma observado: após instalar o KB5051989, copiar cmd.exe para um diretório de usuário e renomeá‑lo para msedge.exe faz com que o binário seja executado, mesmo com regras do AppLocker que deveriam bloqueá‑lo.
Comportamento pré‑patch: o mesmo teste era corretamente barrado.
Reprodutibilidade: confirmada em imagem de instalação já slip‑streamed com o KB e em VMs limpas.
Por que o AppLocker falha?
Os indícios apontam para uma regressão no motor de validação baseado em caminho (Path Rules). Ao que tudo indica, o binário é avaliado com base no nome após a cópia, sem revalidar o hash ou o editor digital original. Assim, qualquer executável renomeado para um título implicitamente “permitido” (msedge.exe, notepad.exe, etc.) obtém passagem livre.
Problemas semelhantes já ocorreram em versões antigas do Windows quando se dependia apenas de regras de caminho. A Microsoft, inclusive, recomenda há anos que ambientes de alta segurança migrem para políticas de hash, editor ou, idealmente, para o Windows Defender Application Control (WDAC), que valida assinaturas a nível de kernel e reduz brechas de bypass.
Impacto em ambientes de quiosque
- Escalada de privilégio local: usuários podem chamar
cmd.exe,powershell.exeou qualquer utilitário CLI renomeando‑os para nomes “confiáveis”. - Persistência de malware: aplicações mal‑intencionadas, uma vez renomeadas, executam livremente mesmo sob perfis restritos.
- Quebra de conformidade: setores sujeitos a normas (PCI‑DSS, ISO 27001, LGPD) podem ficar em não‑conformidade, já que controles compensatórios ficam comprometidos.
Cronograma da investigação
| Data | Evento |
|---|---|
| 12 fev 2025 | Lançamento do KB5051989 (patch Tuesday). |
| 13–17 fev 2025 | Relatos iniciais em fóruns técnicos e Feedback Hub. |
| 18 fev 2025 | Equipe de suporte da Microsoft confirma limitação do fórum, encaminhando o caso à engenharia. |
| 20 fev 2025 | Tópico transferido para Microsoft Learn – seção Windows / Kiosk & AppLocker. |
| Atual | Aguardando confirmação oficial de correção ou hotfix. |
Mitigações provisórias
Até a publicação de um patch oficial, as seguintes ações reduzem o risco:
- Adiar ou bloquear o KB5051989 em dispositivos de quiosque. Use WSUS/Intune para aplicar rings de atualização ou políticas de retenção.
- Reverter para a build anterior (
22631.4721) caso o impacto seja crítico e o rollback seja operacionalmente viável. - Trocar regras de caminho por regras de hash ou editor digital. Exemplos:
<FileHashRule Id="{GUID}" Name="Bloquear cmd.exe" Hash="SHA256:..."...<PublisherRule Id="{GUID}" Name="Permitir Microsoft Edge" PublisherName="O=Microsoft Corporation, L=Redmond, S=Washington, C=US"... - Piloto de WDAC em paralelo, começando por dispositivos de teste. WDAC aplica políticas na inicialização e ignora renomeações.
- Monitoramento reforçado: configure alertas no Defender for Endpoint para processos inesperados (
cmd.exe,powershell.exe) disparados em contas restritas.
Como notificar e acompanhar
A própria Microsoft recomenda duas frentes de comunicação:
- Feedback Hub: inclua capturas de tela, Event Logs (ID 800x – AppLocker) e gerações de política (
Get-AppLockerPolicy -Effective -Xml). - Microsoft Learn Community: publique na categoria Windows / Kiosk & AppLocker. Engenheiros e MVPs costumam consolidar casos e pressionar pela correção.
Boas práticas de Application Control
A falha expôs um ponto fraco conhecido: a dependência de regras de caminho. Reforce seu stack de segurança com estas recomendações:
- Regra “deny‑by‑default”: bloqueie tudo que não esteja explicitamente permitido.
- Assinaturas fortes: valide editor e hash; evite
\\\.exegenéricos. - Segmentação de perfis: quiosques não devem ter ferramentas administrativas nem acesso a unidades locais.
- Auditoria contínua: habilite modo “Audit Only” em WDAC para identificar dependências antes de impor a política.
- Testes de regressão a cada Patch Tuesday: scripts automatizados (PowerShell + Pester) podem validar bloqueios essenciais.
Exemplo rápido de política WDAC mínima
<Policy xmlns="urn:schemas-microsoft-com:wdat">
<RuleCollection Type="Denial">
<FileNameRule Action="Deny" Id="{GUID1}" UserOrGroupSid="S-1-1-0">\.exe</FileNameRule>
</RuleCollection>
<RuleCollection Type="Allow">
<SignerRule Action="Allow" Id="{GUID2}" Issuer="CN=Microsoft Windows"></SignerRule>
<FileHashRule Action="Allow" Id="{GUID3}" FileName="Browser.exe" Hash="SHA256:..." />
</RuleCollection>
</Policy>Mesmo em laboratório, a política acima nega qualquer executável desconhecido, liberando apenas itens assinados pela Microsoft ou com hash explícito.
Planejamento de reversão
Caso opte por remover o KB5051989:
- Abra Configurações > Windows Update > Histórico de atualizações > Desinstalar atualizações.
- Selecione Atualização cumulativa 2025‑02 para Windows 11 para sistemas baseados em x64 (KB5051989).
- Reinicie o equipamento.
- Bloqueie a reinstalação do patch via Show or hide updates ou política de exclusão de KB no WSUS/Intune.
Observação: a desinstalação pode deixar a máquina sem correções críticas de segurança para outras vulnerabilidades de fevereiro. Avalie o risco residual antes de prosseguir.
Efeitos colaterais conhecidos da reversão
- Rollbacks de driver – alguns drivers certificados na build 4890 podem não carregar na build anterior.
- Falha de login no quiosque – se a conta de quiosque foi provisionada após o patch, certifique‑se de recriá‑la.
Quando esperar uma correção?
O ciclo típico de correções para falhas introduzidas no Patch Tuesday é:
- Hotfix sob demanda (out‑of‑band) – 1 a 3 semanas, se o impacto for classificado como service‑blocking.
- Preview (C) release – quarta semana do mês seguinte (mar/2025).
- Próximo Patch Tuesday – 11 mar 2025, caso não haja hotfix.
A recomendação é acompanhar as notas do painel Health Dashboard do Windows 11 e testar imediatamente qualquer build disponibilizada no Insider Release Preview Channel.
Checklist pós‑correção
- Aplicar update em ambiente de staging e repetir o teste de renomear
cmd.exe. - Auditar logs de AppLocker (
Microsoft‑Windows‑AppLocker/EXE and DLL) para confirmar event IDs 8002 (permitido) e 8003 (negado). - Atualizar documentação de segurança e playbooks de resposta.
- Reimplantar WDAC ou regras de caminho, se tiverem sido alteradas como mitigação temporária.
Conclusão
A falha introduzida pelo KB5051989 reforça uma lição conhecida: o controle de aplicações não deve depender apenas de nomes ou caminhos. Enquanto a Microsoft trabalha em uma correção, suspender o patch e endurecer as políticas com hash, editor ou WDAC são as melhores defesas. Aproveite o episódio para rever seus processos de homologação de atualizações e garantir testes automatizados que detectem regressões semelhantes no futuro.