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
1 comentários
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”? ;)