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. O que o APT28 explorou em dezembro de 2025Segundo 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. 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 corrigiuA 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. Por que a correção foi incompletaAo 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.