27 abr Mesmo após correção, Windows ainda esconde vulnerabilidade grave
Um patch lançado pela Microsoft em fevereiro de 2026 para corrigir uma vulnerabilidade explorada pelo grupo russo APT28 não resolveu completamente o problema. Pesquisadores da Akamai identificaram que a correção deixou para trás uma falha separada, capaz de roubar credenciais de rede sem nenhuma interação do usuário.
A nova vulnerabilidade recebeu o identificador CVE-2026-32202 e foi corrigida apenas no Patch Tuesday de abril de 2026. A Microsoft sinalizou no comunicado que a falha já foi explorada em ataques reais, sem detalhar os incidentes.
Ambiente de testes montado pelos pesquisadores da Akamai para reproduzir a CVE-2026-32202: à esquerda, uma máquina Kali Linux simulando o servidor do atacante; à direita, uma VM com Windows 11 Pro Build 26100.2840 rodando sobre Hyper-V, a mesma configuração usada para demonstrar a autenticação NTLM zero-click. Imagem: Akamai.
O que o APT28 explorou em dezembro de 2025
Segundo a Akamai, o APT28, também conhecido como Fancy Bear, Forest Blizzard e Sofacy, conduziu uma campanha em dezembro de 2025 contra a Ucrânia e países da União Europeia. O grupo encadeou duas vulnerabilidades dentro de um único arquivo LNK, os atalhos do Windows com extensão .lnk.
A primeira era a CVE-2026-21513, uma falha no framework MSHTML que permite manipular a forma como o navegador e o Windows Shell processam conteúdo. A segunda era a CVE-2026-21510, uma falha no mecanismo de namespace do shell do Windows.
Essa vulnerabilidade permitia carregar uma biblioteca DLL maliciosa a partir de um servidor remoto usando um caminho UNC, o formato de endereçamento de rede utilizado em ambientes Windows para acessar recursos compartilhados.
O CControlPanelFolder::GetUIObjectOf aciona GetModuleMapped, que por sua vez chama PathFileExistsW, a função responsável por resolver o caminho UNC e disparar a conexão SMB com o servidor do atacante antes de qualquer verificação de segurança. Imagem: Akamai.
Basicamente, o arquivo LNK armado enganava o Windows Explorer para que ele carregasse um componente do Painel de Controle diretamente de um servidor controlado pelo atacante, sem que o SmartScreen ou o Mark of the Web fizessem qualquer verificação de segurança.
O que o patch de fevereiro corrigiu
A Microsoft resolveu a CVE-2026-21510 introduzindo um novo objeto COM chamado ControlPanelLinkSite, que funciona como uma ponte entre o caminho de execução de arquivos CPL e o mecanismo de verificação de confiança do ShellExecute.
A correção forçava o SmartScreen a verificar a assinatura digital e a zona de origem do arquivo antes de permitir sua execução. O caminho de execução remota de código foi efetivamente bloqueado, mas não foi suficiente.
O novo objeto ControlPanelLinkSite é instanciado em _ShellExecCplApplet e passado ao ShellExecuteExW, garantindo que o SmartScreen verifique a assinatura e a zona de origem do arquivo CPL antes da execução. A correção, porém, só age nesse estágio final da cadeia. Imagem: Akamai.
Por que a correção foi incompleta
Ao testar o patch, os pesquisadores da Akamai notaram que a máquina da vítima continuava autenticando no servidor do atacante mesmo após a correção. Isso porque a verificação de confiança introduzida pela Microsoft só era acionada no final da cadeia de execução, em uma chamada tardia do ShellExecute.
Antes disso, em um estágio anterior da cadeia, o Windows Explorer já havia feito contato com o servidor remoto. Isso ocorre quando o Explorer tenta renderizar o conteúdo de uma pasta que contém o arquivo LNK malicioso.
Para exibir o ícone associado ao item do Painel de Controle, o shell32 resolve o caminho UNC embutido no arquivo. Essa resolução dispara automaticamente uma conexão SMB com o servidor do atacante.
O CPL_Open chega ao ShellExecuteExW (destacado em vermelho) sem passar por nenhum objeto de verificação de confiança. A ausência do ControlPanelLinkSite nesse fluxo é exatamente o que a CVE-2026-21510 explorava para executar código remoto sem validação do SmartScreen. Imagem: Akamai.
A conexão SMB aciona um handshake de autenticação NTLM automático. O resultado é que o hash Net-NTLMv2 da vítima é enviado ao atacante sem nenhum clique. Esse hash pode ser usado posteriormente em ataques de relay NTLM ou para quebra de senha offline.
Zero-click sem nenhuma interação
A natureza zero-click da CVE-2026-32202 a torna especialmente perigosa. A vítima não precisa abrir o arquivo, executar nada ou confirmar qualquer prompt de segurança. Basta navegar até a pasta que contém o LNK malicioso para que o Windows inicie a autenticação com o servidor do atacante.
O campo LinkTargetIDList contém três entradas IDList, sendo a terceira o caminho UNC para o servidor do atacante. O arquivo não inclui nenhum caminho Windows convencional — toda a carga maliciosa está embutida na estrutura binária do atalho. Imagem: Akamai.
A Akamai reportou a descoberta ao Microsoft Security Response Center antes de divulgar publicamente os detalhes, o que é o motivo pelo qual a empresa havia omitido a CVE-2026-21510 de publicações anteriores sobre a campanha do APT28.
Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.