Um pesquisador solo lançou 8 zero-days contra a Microsoft em 10 semanas. Cada um cronometrado para o Patch Tuesday. A campanha, batizada de Nightmare Eclipse, expôe falhas estruturais no ecossistema de segurança do Windows que vão além de patches individuais. Nós acompanhamos cada disclosure e a lição é clara: aplicar patches não é o mesmo que ter cobertura defensiva.
Os 8 zero-days — o que cada um faz
A campanha cobre uma superfície de ataque ampla: escalação de privilégio, bypass de criptografia de disco, degradação de antivírus e re-exploração de falhas antigas. Segundo o pesquisador, estes são os detalhes:
- BlueHammer (3 de abril): LPE para SYSTEM via Defender Engine. CVE-2026-33825. Patchado no Patch Tuesday de abril.
- RedSun (16 de abril): LPE para SYSTEM via Defender Engine. CVE-2026-41091. Patchado no Patch Tuesday de junho.
- UnDefend (16 de abril): degradação do Defender + bloqueio de atualização de assinaturas. CVE-2026-45498. Patchado em junho.
- YellowKey (13 de maio): bypass do BitLocker via WinRE. CVE-2026-50507. Patchado em junho.
- GreenPlasma (13 de maio): LPE para SYSTEM via CTFMON. CVE-2026-45586. Patchado em junho.
- MiniPlasma (13-14 de maio): re-exploração de CVE-2020-17103 (cldflt.sys), falha original do Google Project Zero. Segundo o pesquisador, o patch de 2020 aparentemente nunca foi aplicado corretamente. Patchado em junho.
- RoguePlanet (10 de junho): TOCTOU no pipeline de scan/quarantine do Defender → SYSTEM em Windows 11 totalmente patchado, incluindo KB5094126 do Patch Tuesday de junho. Race condition com confiabilidade variável — 100% em algumas máquinas, inconsistente em outras. Não funciona em Windows Server. Sem CVE. Sem patch.
- GreatXML (11 de junho): bypass do BitLocker via artefatos de offline scan do Defender na partição de recuperação. Requer acesso administrativo prévio — é persistência pós-comprometimento, não acesso inicial. Sem CVE. Sem patch. Segundo Will Dormann, analista de vulnerabilidades respeitado, não foi possível reproduzir o bypass como descrito. O pesquisador pediu ajuda para encontrar um trigger alternativo. A confiabilidade prática é questionada.
Exploração ativa — quando o zero-day deixa de ser teórico
Três dessas vulnerabilidades já foram observadas em intrusões reais. Segundo a Huntress Labs, BlueHammer, RedSun e UnDefend foram usados em ataques documentados em 17 de abril — antes mesmo de muitos administradores saberem que os PoCs existiam. Segundo a CISA, BlueHammer foi adicionado ao Known Exploited Vulnerabilities (KEV) catalog em 22 de abril. Segundo a Kaspersky, MiniPlasma estava em exploração ativa desde 10 de abril.
A velocidade é o que importa. O pesquisador publicou BlueHammer em 3 de abril. A Huntress documentou exploração em 17 de abril. A CISA adicionou ao KEV em 22 de abril. Do disclosure ao catálogo federal: 19 dias. Para organizações que dependem de ciclos mensais de patching, isso é uma eternidade.
RoguePlanet — o zero-day que funciona em Windows 11 patchado
RoguePlanet é o mais relevante para quem defende estações Windows hoje. A Microsoft endureceu o Defender silenciosamente em meados de maio, patchando a API mpengine!SysIO* que bloqueava ataques via junction. O pesquisador reescreveu o exploit em aproximadamente 3 semanas para contornar o hardening. A assinatura do Defender (Exploit:Win32/DfndrRugPlnt.BB) detecta apenas o binário compilado, não a técnica subjacente.
Isso significa que a técnica permanece viável mesmo com a assinatura ativa. Um atacante que recompile o exploit ou modifique o binário bypassa a detecção. A race condition no pipeline de scan/quarantine é uma classe de vulnerabilidade, não um bug isolado — e classes de vulnerabilidade não se resolvem com assinaturas.
Segundo a Picus Security, o insight central é: "Patch parity is not coverage parity." Aplicar patches não equivale a ter cobertura defensiva contra a classe de técnica subjacente. A Microsoft fechou uma porta de junction attack em maio; o RoguePlanet abriu outra. O Patch Tuesday de junho corrigiu GreenPlasma e YellowKey; deixou o caminho do RoguePlanet aberto.
A tensão entre pesquisa de segurança e responsabilidade corporativa
Segundo reportes da comunidade de segurança, a Microsoft ameaçou ação criminal em 28 de maio contra o pesquisador. Após reação negativa significativa da comunidade de segurança, a empresa recuou, declarando que não tem intenção de processar indivíduos que publicam pesquisa de segurança, segundo a Microsoft. O pesquisador, no entanto, afirma que a Microsoft entrou com ação legal. Segundo reportes da comunidade de segurança, GitHub e GitLab removeram os repositórios sob pressão. O pesquisador migrou para git auto-hospedado.
Esse episódio revela uma tensão estrutural: quando o fornecedor de segurança é também o alvo, a dinâmica entre disclosure e accountability muda. A comunidade de segurança precisa de pesquisa independente para identificar falhas que o vendor não encontrou — ou não priorizou. Criminalizar essa pesquisa não elimina as vulnerabilidades; apenas as mantém invisíveis.
O que fazer agora
Na Tech86, nossa posição é direta: segurança por camadas não é opcional quando o próprio Defender é o vetor de ataque. Um EDR independente com telemetria própria não depende do mesmo engine que está sendo explorado. Quando o Defender é cego — por crash via UnDefend, por escalação via RedSun, ou por race condition via RoguePlanet — o EDR continua detectando.
Verifique se Engine está em 1.1.26040.8+ e Platform em 4.18.26040.7+, segundo a Microsoft. Monitore Event IDs 2001/2002/2003 para falhas de atualização e 4672 para escalação de privilégio. Audite as políticas de BitLocker e a proteção da partição WinRE. E nunca assuma que um endpoint totalmente patchado está seguro — RoguePlanet provou que patchado não é o mesmo que protegido.