YellowKey: o zero-day que burla o BitLocker no Windows

Imagine deixar um notebook corporativo trancado no carro por dez minutos. Está criptografado com BitLocker — protegido, certo? O CVE-2026-45585, apelidado de YellowKey, questiona exatamente essa premissa. O pesquisador Chaotic Eclipse publicou o PoC em 12 de maio e, oito dias depois, a Microsoft emitiu mitigações de emergência — ainda sem patch definitivo. Neste momento, qualquer dispositivo Windows afetado em modo TPM-only está vulnerável a quem tiver alguns minutos de acesso físico.

Como o YellowKey funciona

O ataque abusa de uma falha no Windows Recovery Environment (WinRE), o ambiente de recuperação que roda antes do sistema operacional principal carregar. O WinRE tem uma rotina chamada autofstx.exe que processa logs NTFS a partir de uma pasta chamada FsTx em um pen drive USB ou na partição EFI do dispositivo.

Ao reprocessar esses logs manipulados, o WinRE deleta o arquivo que normalmente bloqueia o shell de recuperação. Na próxima inicialização, o atacante cai num prompt de comando com o drive protegido pelo BitLocker já montado e legível — sem inserir a chave de recuperação, sem PIN, sem deixar rastro óbvio.

O ataque exige:

• Acesso físico ao dispositivo por poucos minutos
• Um pen drive com a estrutura FsTx especialmente criada
• Dois reboots para completar a sequência

O CVSS atribuído é 6.8 — moderado pelo padrão, mas enganoso: a exigência de acesso físico limita o escopo em servidores em datacenter, mas não elimina o risco em laptops que viajam.

Sistemas afetados

Segundo a Microsoft, o YellowKey afeta:

• Windows 11 versão 24H2 (x64)
• Windows 11 versão 25H2 (x64)
• Windows 11 versão 26H1 (x64)
• Windows Server 2025
• Windows Server 2025 (Server Core)

Versões mais antigas — Windows 10, Windows Server 2019 e 2022 — não foram listadas no advisory. A Microsoft não fechou explicitamente essa porta, mas o foco das mitigações é o Windows 11 recente e o Server 2025.

Como mitigar agora (sem esperar o patch)

A Microsoft disponibilizou duas opções de mitigação. Não são equivalentes em facilidade de implementação, mas ambas fecham o vetor de ataque confirmado.

Opção 1 — Mudar para TPM+PIN (recomendada)

O modo padrão do BitLocker usa apenas o chip TPM para liberar o drive automaticamente no boot. O YellowKey explora exatamente esse fluxo automático. Ao exigir um PIN adicional, você força o atacante a conhecer a senha mesmo tendo acesso físico completo ao hardware.

Para ativar via PowerShell (sessão elevada):

Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector

Via Group Policy: Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives, habilite "Require additional authentication at startup" e defina TPM startup PIN como Required.

Para frotas gerenciadas via Intune, a política equivalente fica em Endpoint Security → Disk Encryption. Se você quer monitorar o estado do BitLocker com scripts e gerar alertas quando o status de proteção muda, o post sobre auditoria de logs de segurança no Windows com PowerShell cobre a infraestrutura de monitoramento necessária.

Opção 2 — Remover autofstx.exe da imagem WinRE

Mais trabalhosa, indicada para ambientes que não podem exigir PIN no boot — kiosks, dispositivos compartilhados, terminais industriais. O processo envolve montar a imagem WinRE (winre.wim), montar o hive de registro da imagem e remover o valor autofstx.exe da chave:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

A Microsoft publicou o passo a passo completo no advisory. Siga a sequência à risca — errar a edição do BootExecute pode impedir o dispositivo de inicializar.

Por que o CVSS 6.8 subestima o risco real

O CVSS penaliza a pontuação quando o ataque exige acesso físico, o que faz sentido para servidores em datacenter com controle de acesso rigoroso. Mas laptops corporativos vivem em aeroportos, home offices, cafés e carros estacionados.

Um notebook esquecido num táxi. Um técnico que deixa o equipamento de um cliente por dez minutos. Um dispositivo furtado de uma mochila. O BitLocker existe exatamente para esses cenários — e o YellowKey o neutraliza com ferramentas triviais.

O padrão se repete: a superfície de ataque parece pequena até que o cenário certo apareça. O caso da Trellix, em que código-fonte de uma empresa de segurança foi roubado pelo grupo RansomHouse, mostrou que acesso a ativos internos pode ter consequências desproporcionais ao vetor inicial utilizado.

O patch definitivo ainda não tem data

O Patch Tuesday de maio de 2026 fechou 120 vulnerabilidades, mas o YellowKey não estava na lista — o PoC foi publicado depois da janela de corte do ciclo. A estimativa mais realista é que o fix apareça no Patch Tuesday de junho, segundo o Bleeping Computer.

Enquanto isso, o código de exploração está público no GitHub. Isso significa que qualquer pessoa com motivação e acesso físico ao dispositivo pode executar o ataque sem precisar de skill técnico avançado — basta seguir o repositório do pesquisador.

A lição que o YellowKey deixa

Criptografia de disco não é uma camada de segurança independente — ela depende de como o processo de boot é configurado. TPM-only sempre foi uma conveniência, não uma garantia; o PIN adicional existe como opção há anos. O YellowKey torna sua ausência indefensável para qualquer dispositivo que sai do perímetro físico controlado.

Para quem gerencia infraestrutura, a ação imediata é mapear quais dispositivos usam TPM-only e aplicar a política TPM+PIN com prioridade. Para usuários individuais em Windows 11, o comando abaixo mostra o modo ativo:

manage-bde -status C:

Verifique a linha Key Protectors: se aparecer apenas TPM sem PIN, o dispositivo está no modo vulnerável. Se quiser adicionar uma camada complementar de visibilidade na rede do dispositivo — monitoramento de DNS e bloqueio de destinos suspeitos — o post sobre segurança e privacidade com NextDNS cobre essa frente.

Se você gerencia endpoints e ainda não revisou a política de BitLocker depois desse disclosure, agora é a hora. Conta nos comentários: sua frota já usa TPM+PIN como padrão, ou ainda está no modo TPM-only por conveniência?