A Microsoft publicou uma mitigação para uma vulnerabilidade de omissão de segurança de BitLocker conhecida como YellowKey (CVE-2026-45585), depois de seu teste de conceito ser divulgado publicamente e rompier o processo de divulgação coordenada. A falha, com uma pontuação CVSS de 6.8, permite a um atacante com acesso físico usar arquivos especialmente manipulados ("FsTx") numa unidade USB ou na partição EFI, reiniciar a máquina no Ambiente de Recuperação do Windows (WinRE) e provocar a execução de uma utilidade que, segundo o pesquisador, abre uma shell com acesso irrestrito ao volume criptografado por BitLocker.
É importante sublinhar que este ataque requer acesso físico e a capacidade de forçar o arranque em WinRE a partir de meios externos, o que limita parcialmente o rádio de ameaça a cenários de roubo de equipamentos, acesso a salas de servidor ou ambientes com políticas de arranque laxas. No entanto, a existência de um PoC público aumenta o risco operacional: adversários com conhecimentos técnicos e acesso físico poderão automatizar testes de compromisso sem necessidade de investigar a vulnerabilidade a partir de zero. Para uma cobertura técnica adicional e acompanhamento jornalístico, coberturas como BleepingComputer documentaram a divulgação e a resposta da Microsoft: BleepingComputer sobre YellowKey.

A Microsoft descreveu uma mitigação baseada na modificação do WinRE: a imagem do WinRE deve ser montada, carregando o seu hive de registo, removendo a entrada "autofstx.exe" do valor BootExecute de Session Manager, guardar e baixar a hive, e re comprometer a imagem no dispositivo. Isto evita que o utilitário FsTx seja executado automaticamente no arranque do WinRE. Além disso, a empresa recomenda alterar os protetores de BitLocker de TPM-only a TPM+PIN, para que o desbloqueio do volume exija um PIN no arranque e não dependa apenas do módulo TPM. A documentação oficial do BitLocker na Microsoft pode ajudar a planejar essas mudanças: Documentação do BitLocker no Microsoft Docs.
Para equipes e administradores, as implicações práticas são duplas: primeiro, há que aplicar a mitigação nas imagens WinRE e provê-la amplamente; segundo, há que rever políticas de arranque e segurança física. Mudar para TPM+PIN reduz drasticamente a eficácia de YellowKey porque mesmo com WinRE comprometido o atacante não poderá decifrar a unidade sem conhecer o PIN. A Microsoft descreve opções para impor este requisito a partir de Intune ou Políticas de Grupo ("Require additional authentication at startup" e "Configure TPM startup PIN").

Não basta apenas atenuar o nível de software: reforço do controlo físico e do firmware É crucial. Eu recomendo desativar o arranque de USB quando não for necessário, proteger o firmware UEFI/BIOS com senha, forçar o Secure Boot e registrar quem tem acesso físico a máquinas críticas. Estas medidas reduzem as oportunidades de um atacante inserir meios manipulados ou reinicie servidores para invocar WinRE com meios externos.
No plano operacional, as organizações devem priorizar a identificação e o adesivo de imagens WinRE usados pela frota, integrar verificações no ciclo de gestão de imagens e automatizar a modificação proposta pela Microsoft para prevenir erros humanos. Também é conveniente rever procedimentos de resposta a incidentes: confirmar a integridade de winpeshl.ini e procurar sinais de que utilidades não autorizadas foram executados em WinRE. Para guias práticas de gerenciamento de BitLocker e ferramentas como manage-bde e PowerShell, a documentação da Microsoft oferece comandos e exemplos para mudar protetores e implantar políticas de arranque seguro.
Finalmente, o balanço da segurança e da operacional é fundamental. TPM+PIN introduz fricção(recuperação do PIN, suporte do utilizador), por isso é necessário preparar suporte e processos de recuperação (rotação de chaves, armazenamento seguro de informação de recuperação). A mitigação técnica deve ser acompanhada de consciência do pessoal, controles físicos e revisões periódicas das imagens de recuperação para fechar rapidamente vetores semelhantes no futuro.
Relacionadas
Mas notícias do mesmo assunto.

Jovem ucraniano de 18 anos lidera uma rede de infostealers que violou 28.000 contas e deixou perdas de 250 mil dólares
As autoridades ucranianas, em coordenação com agentes dos EUA. Os EUA puseram o foco numa operação. infostealer que, segundo a Polícia Cibernética da Ucrânia, teria sido adminis...

RAMPART e Clarity redefinem a segurança dos agentes da IA com testes reprodutíveis e governança desde o início
A Microsoft apresentou duas ferramentas de código aberto, RAMPART e Clarity, que visam alterar a forma como a segurança dos agentes da IA é testada: uma máquina de computador e ...

A assinatura digital está em jaque: Microsoft desmantela um serviço que tornou malware em software aparentemente legítimo
A Microsoft anunciou a desarticulação de uma operação de "malware‐signing‐as‐a-service" que explorava seu sistema de assinatura de artefatos para converter código malicioso em b...

Um único token de workflow do GitHub abriu a porta para a cadeia de fornecimento de software
Um único token de workflow do GitHub falhou na rotação e abriu a porta. Essa é a conclusão central do incidente em Grafana Labs após a recente onda de pacotes maliciosos publica...

Webworm 2025: o malware que se esconde em Discord e Microsoft Graph para evitar a detecção
As últimas observações de pesquisadores em cibersegurança apontam uma mudança de táticas preocupantes de um ator ligado à China conhecido como Webworm: Em 2025, ele introduziu p...

A identidade já não basta: a verificação contínua do dispositivo para uma segurança em tempo real
A identidade continua sendo a coluna vertebral de muitas arquiteturas de segurança, mas hoje essa coluna está se agride sob novas pressões: phishing avançado, kits que proxyam a...

A matéria escura da identidade está mudando as regras da segurança corporativa
O relatório Identity Gap: Snapshot 2026 publicado por Orchid Security coloca números a uma tendência perigosa: a "matéria escura" de identidade —contas e credenciais que não se ...