Pesquisador de segurança diz que a Microsoft criou um backdoor no BitLocker e divulga exploit
(techspot.com)- O pesquisador de segurança Nightmare-Eclipse divulgou o YellowKey, afirmando que ele consegue contornar a criptografia de volume completo do BitLocker sem senha
- O YellowKey pode ser reproduzido copiando a pasta FsTx para um pendrive com sistema de arquivos compatível com Windows e seguindo uma sequência específica no WinRE
- Após a conclusão do procedimento, um shell de comando é aberto, permitindo navegar, copiar e realizar operações em arquivos no volume protegido pelo BitLocker
- Nightmare-Eclipse afirma que o comportamento de bypass aparece apenas em imagens oficiais do WinRE, levantando a possibilidade de um backdoor intencional
- Os sistemas afetados seriam Windows 11, Server 2022 e Server 2025, enquanto o Windows 10 não seria impactado
Condições de funcionamento do YellowKey
- O pesquisador de segurança Nightmare-Eclipse divulgou o YellowKey, afirmando que ele pode contornar completamente a criptografia de volume completo do BitLocker
- O YellowKey pode ser reproduzido copiando a pasta FsTx incluída para um pendrive formatado com um sistema de arquivos compatível com Windows, como NTFS, FAT32 ou exFAT
- Também foi relatado que ele pode funcionar sem pendrive, ao copiar os arquivos FsTx para a partição EFI do Windows e desconectar temporariamente o disco criptografado do sistema
- Em seguida, é preciso reiniciar o sistema protegido pelo BitLocker, entrar no Windows Recovery Environment (WinRE) e seguir uma sequência específica de entradas
- Se o procedimento for concluído corretamente, um shell de comando aparece, permitindo navegar e copiar o volume protegido pelo BitLocker sem senha, além de realizar outras operações com arquivos
Base da suspeita de backdoor
- Nightmare-Eclipse afirma que o YellowKey é anômalo para ser considerado uma falha de segurança até então desconhecida e levanta a possibilidade de que a Microsoft tenha inserido um backdoor legítimo no sistema de proteção de dados do BitLocker
- A base para isso é que o componente que causa o problema é encontrado apenas em imagens oficiais do WinRE
- Embora o mesmo componente também exista em imagens padrão de instalação do Windows, o comportamento real de bypass do BitLocker observado em sistemas não aparece nelas
- Nightmare-Eclipse declarou: “Não consigo pensar em outra explicação além do fato de isso ter sido intencional”, acrescentando que o Windows 10 não é afetado, e que Windows 11, Server 2022 e Server 2025 são os únicos impactados
Verificação externa e divulgação adicional
- Foi relatado que pesquisadores terceiros confirmaram que o YellowKey funciona da forma descrita no material do GitHub de Nightmare-Eclipse
- Nightmare-Eclipse também divulgou um segundo exploit, GreenPlasma, que seria capaz de escalonamento de privilégios
- O GreenPlasma não divulgou um código completo de prova de conceito para obter acesso em nível SYSTEM, mas sugeriu que pode revelar mais detalhes antes da Patch Tuesday do próximo mês
Direções de mitigação
- Foi apontado que a mitigação para a suspeita de comportamento de backdoor do YellowKey é relativamente simples
- Especialistas em segurança recomendam não depender apenas de um único sistema de criptografia e avaliar também alternativas bem revisadas de criptografia completa de disco
- Como exemplo, foi citado o VeraCrypt
2 comentários
Opiniões no Lobste.rs
Dizem que esse backdoor só funciona se o WinRE conseguir desbloquear a unidade (post anterior), e, se a unidade estiver protegida por senha, imagino que ainda seria preciso digitar essa senha
O alvo real provavelmente é o BitLocker transparente, que confia apenas no TPM e não usa senha de criptografia de disco. Como o Windows completo já iniciou, a chave de criptografia já está na memória e só a tela de login está bloqueando o acesso, isso não é seguro, exatamente como parece
Como o atacante já está dentro do Windows, a superfície de ataque é enorme, e já houve vários bugs que permitiram contornar a tela de login, além do “bugdoor” do OP. Também é possível farejar o barramento do TPM ou extrair a chave da memória com um ataque de cold boot
Claro, ainda é algo preocupante, mas parece ser a forma de uso recomendada do BitLocker, e usuários comuns não são devidamente alertados sobre os riscos de não usar uma senha real para a criptografia de disco. Ainda assim, eu diria que essa vulnerabilidade só se aplica a quem já estava usando o BitLocker de uma forma que, no fundo, não era segura, e apenas torna ataques já existentes um pouco mais fáceis
Claro, se o WinRE puder magicamente abrir até unidades criptografadas por senha, aí a conversa muda, mas nesse caso alguém provavelmente já teria percebido isso anos atrás
“Em segundo lugar, não, TPM+PIN também não ajuda. Isso continua explorável. Eu também me perguntei ‘será que funciona em ambientes TPM+PIN?’, e a resposta é sim. Só não vou divulgar a PoC. Acho que o que já foi divulgado já é ruim o bastante”
Em outras palavras, no momento em que Paul Le Roux foi preso por tráfico e assassinato e começou a cooperar com as autoridades, os usuários do TrueCrypt foram direcionados para um software com backdoor
Segundo a Wikipedia, Le Roux foi preso em 2012, então essa linha do tempo não parece bater
https://news.ycombinator.com/item?id=7812133
Colocando um chapéu de teórico da conspiração cada vez mais justificável, pedidos de chave na nuvem podem deixar registro e talvez até exigir autorização judicial
No fim de abril, depois de instalar uma atualização do Windows, eu simplesmente não conseguia mais descriptografar um volume do BitLocker com PIN. O código de recuperação funcionava, mas mesmo redefinindo o PIN várias vezes, ele continuava dizendo que estava errado
No fim, não consegui descobrir a causa e reinstalei o Windows. Foi um bug bem irritante e uma coincidência engraçada
Se eu postar em algum lugar que há um backdoor no ECDSA, isso não viraria notícia, a menos que fosse um site caça-cliques
Suspeitar que seja um backdoor intencional também não é um salto tão grande, mas isso ainda é especulação
A parte sem evidência é a alegação de que também é possível contornar o BitLocker configurado separadamente com PIN. Isso não apareceu na matéria
Essa pessoa parece ter um histórico bem bom de encontrar vulnerabilidades no Windows, então me parece uma alegação que vale acompanhar mesmo sem PoC
Nem deveria ser preciso dizer, mas qualquer coisa que precise ser protegida contra roubo nunca deveria ficar no Windows. Você não deveria usar Windows para banco, investimentos, impostos, e-mail, hospedagem, compras ou assuntos particulares
O Windows só deveria ser usado para (i) jogos e (ii) builds para Windows
Comentários do Hacker News
Pelo post do pesquisador Nightmare-Eclipse que encontrou essa vulnerabilidade, parece que isso vem se desenrolando há quase uma semana
Na terça-feira, 12 de maio de 2026, ele disse: “Desta vez são duas vulnerabilidades [YellowKey] [GreenPlasma] [...] na próxima Patch Tuesday a Microsoft vai ter uma grande surpresa”, e na quarta-feira, 13 de maio, escreveu: “Quando eu puder contar a história toda, as pessoas vão ver que meu surto foi bastante razoável, e também não vai pegar nada bem para a Microsoft”
Blog do autor: https://deadeclipse666.blogspot.com/
No primeiro post de março de 2026, há algo como: “Alguém quebrou nosso acordo, eu fiquei sem nada e perdi minha casa. Eles me apunhalaram pelas costas sabendo que isso aconteceria. Essa não foi minha decisão, foi a deles”
Não sei bem como interpretar isso, mas soa quase como se um insider estivesse basicamente “vazando” algo, e parece que outras pessoas também conseguem reproduzir o resultado
Se isso é um backdoor ou não, no fim depende de como você normalmente enxerga a velha discussão “bug ou backdoor”, e não é uma história simples do tipo que a imprensa de tecnologia adora, algo como “Microsoft = 1, BitLocker hackeado”
O ponto central é um bug no recurso de replay do log transacional NTFS do Windows Recovery Environment WinRE, que permite ler o log transacional NTFS de um volume externo e aplicá-lo ao sistema de arquivos montado. Isso permite que um atacante contorne a autenticação do WinRE
No BitLocker sem PIN ou senha, qualquer bypass de autenticação acaba virando bypass da criptografia de disco. Isso porque o bootloader já fez o unsealing do disco, e essa “falha” estrutural também existe no Linux com a mesma configuração. Por exemplo, acontece o mesmo quando se usa a caixa de seleção Hardware Disk Encryption adicionada relativamente há pouco tempo no instalador do Ubuntu
Sem evidências adicionais, se o problema do log transacional NTFS foi um backdoor plantado ou apenas um bug de enumeração depende do nível de teoria da conspiração comum no desenvolvimento de exploits. Pessoalmente, isso me parece um bug plausível, e a fragilidade do unsealing no boot é bem conhecida e óbvia, então eu não vejo isso como uma revelação que vai abalar o mundo, mas continua sendo um bug interessante
Um resumo melhor: https://infosec.exchange/@wdormann/116565129854382214
O exploit divulgado não afeta o BitLocker com PIN. Sem PIN, o BitLocker já não é seguro de qualquer forma
O autor original afirma ter um exploit que funciona mesmo com PIN, mas ainda não apresentou provas disso
Nunca vi empresa exigir PIN no BitLocker
Fonte: https://infosec.exchange/@wdormann/116565129854382214
“Uma sessão WinRE típica tem o diretório X:\Windows\System32 e, dentro dele, um arquivo winpeshl.ini”
“Mas no exploit YellowKey, parece que fragmentos de Transactional NTFS em um drive USB conseguem deletar o arquivo winpeshl.ini de outro drive”
Interessante. Não conheço bem esse ambiente, mas seria ingenuamente um problema de criar ou repassar file handles? Se for isso, então por que seria preciso entrada do teclado durante o reboot do WinRE?
Também fico curioso sobre o quanto isso é corrigível. Não vai dar para mexer em inúmeros drives USB de WinRE já existentes, então será que dá para atualizar permissões do lado do BitLocker? Seria necessário descriptografar/recriptografar? Parece que ainda vem muita coisa por aí
Por isso esse ataque precisa do WinRE, em vez de simplesmente inicializar com algo como um live CD do Ubuntu
E também não é necessário corrigir todos os drives USB de WinRE já existentes. Se a assinatura do Secure Boot for revogada, ela não vai passar na validação do TPM e, portanto, não conseguirá descriptografar disco nenhum
“Especialistas em segurança geralmente recomendam não depender de um único sistema de criptografia e avaliar alternativas de criptografia completa de disco bem auditadas, como o VeraCrypt”
Se colocaram um backdoor no FDE, faria mais sentido dizer às pessoas para pararem de usar Windows de vez e migrarem para Linux
Se colocaram um backdoor no FDE, é de se presumir que o próprio sistema operacional não tenha só um backdoor também. Software proprietário não deveria ser confiado de forma alguma, e nem open source sem auditoria adequada
Isso parece menos um problema exclusivo do BitLocker e mais um bypass de login. Se você depende de TPM sem PIN, a descriptografia acontece automaticamente
Em condições normais, o atacante ainda não deveria conseguir passar da tela de login, então deveria estar tudo bem, mas esse exploit aparentemente mostra como obter um shell irrestrito no ambiente de recuperação
O pesquisador afirma ter um jeito de contornar também o PIN, mas ainda não divulgou isso
Em que momento os especialistas em segurança vão começar a rejeitar vagas de “segurança de produtos Microsoft”? Eu já cheguei nesse ponto
Segurança de produtos Microsoft é só um trabalho corrido até tudo desabar de novo na próxima onda de dívida técnica insana e ganância da MS. Agora tem até backdoor
Eles cumpriram todas as regras de compliance e seguiram as “boas práticas” influenciadas pela MS, então, aconteça o que acontecer, não será culpa deles
Dá para ativar o ADP para backups com criptografia ponta a ponta, mas isso talvez não ajude muito, porque provavelmente seus interlocutores não ativaram
Não estou tentando defender a Microsoft, só dizendo que todas essas empresas fizeram parte do PRISM
Vamos falar de por que, quando uma versão do Windows NT foi lançada acidentalmente com símbolos de debug ativados, o nome de uma chave que a Microsoft dizia ser “chave auxiliar” era ..._NSAKEY
Houve uma única vez, exatamente uma vez, em que o Windows saiu com símbolos de debug ativados, e justo o nome da chave criptográfica era “NSAKEY”
Claro, quem segue fazendo vista grossa para os erros do Estado vai dizer que isso é totalmente normal e vai repetir a desculpa cuidadosamente produzida pela Microsoft na época, de que “não é um backdoor”
Investigando um pouco mais o exploit, ele mira o BitLocker em modo somente TPM, ou seja, sem autenticação pré-boot
Se o Secure Boot valida a cadeia de inicialização, o TPM libera a chave de criptografia por conta própria. Com acesso físico, isso não faz tanta diferença
Você pode inicializar com um USB contendo o exploit e obter um shell de emergência, ou comprar um microcontrolador de 5 dólares e soldar em pinos específicos da placa-mãe para farejar a chave do TPM
A Microsoft está vendendo algo inseguro de forma geral como se fosse criptografia completa de disco. Alguém capaz de colocar o exploit num pendrive, obter um shell e vasculhar/copiar arquivos também é capaz de comprar um microcontrolador e seguir um vídeo de solda no YouTube
Então o problema não é o “exploit” em si, e sim a falsa sensação de segurança que a Microsoft vende
Farejar a chave do TPM soldando um microcontrolador de 5 dólares em pinos específicos só é possível em dTPM. fTPM não é vulnerável a isso e é muito mais usado do que dTPM
Digitar uma passphrase no boot já é memória muscular, e oferece uma segurança simples em que dá para confiar
Você consegue recuperar os dados mesmo sem a placa-mãe
Para uso diário, talvez um modelo híbrido faça sentido: usar um slot com Secure Boot+TPM+passphrase para se proteger de ataque evil maid e manter mais um slot de passphrase de backup
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
Isso parece menos um ataque ao BitLocker e mais um ataque à cadeia do Secure Boot
O valor do desbloqueio sem PIN existe quando o modelo de ameaça está limitado a descarte do disco, remoção do disco, ou separação entre TPM e disco
Se vários usuários usam o dispositivo regularmente, exigir PIN pode ser incômodo ou inviável. Então a verificação de acesso acaba sendo delegada a componentes confiáveis do sistema operacional
Alguém lembra da frase “Usar TrueCrypt não é seguro e pode conter problemas de segurança não corrigidos”? ;)