Um Pendrive, Dois Minutos e Seu HD Inteiro Exposto

Imagina o cenário: você configura o BitLocker no seu notebook corporativo, ativa o TPM, dorme tranquilo achando que seus dados estão seguros. Aí alguém pluga um pendrive na USB, reinicia a máquina e, em menos de dois minutos, tem acesso total ao seu disco criptografado. Sem senha. Sem brute force. Sem nada sofisticado.

Parece ficção, mas é exatamente o que o exploit YellowKey faz — e o pesquisador que descobriu isso está convicto de que a Microsoft colocou essa brecha ali de propósito.

O que é o YellowKey

No dia 12 de maio de 2026, um pesquisador de segurança que opera sob o alias Nightmare-Eclipse no GitHub publicou o repositório YellowKey: um proof-of-concept que bypassa a criptografia do BitLocker no Windows 11, Windows Server 2022 e Windows Server 2025.

O pesquisador descreveu a descoberta como “uma das coisas mais insanas que já encontrei” — e quando você entende a mecânica do ataque, fica difícil discordar.

A falha explora um comportamento obscuro dentro do Windows Recovery Environment (WinRE), o ambiente de recuperação embutido no Windows. Um componente não documentado processa arquivos de transação NTFS (chamados FsTx) de drives externos e, ao fazer isso, desbloqueia o volume protegido pelo BitLocker sem exigir nenhuma autenticação.

Como o ataque funciona na prática

O fluxo é assustadoramente simples:

1. Preparar o pendrive

O atacante cria uma pasta específica no pendrive:

\System Volume Information\FsTx\

Dentro dela, arquivos crafted que exploram o mecanismo de replay de transações NTFS. Alternativamente, esses arquivos podem ser escritos direto na partição EFI do próprio computador — eliminando a necessidade de USB.

2. Reiniciar no WinRE

Basta plugar o pendrive e reiniciar a máquina no Windows Recovery Environment. Isso pode ser feito via Shift+Restart ou simplesmente interrompendo o boot duas vezes.

3. Segurar CTRL e ganhar shell

Uma vez no WinRE, o atacante segura a tecla CTRL durante o processo de recuperação. Em vez do menu normal de recuperação, o sistema dropa um prompt de comando irrestrito — com o volume BitLocker já desbloqueado e montado.

A partir daí, ferramentas como diskpart dão acesso completo a todos os arquivos do disco criptografado.

O processo inteiro leva menos de dois minutos em hardware real.

Transactional NTFS: a peça que ninguém lembra

Pra entender por que isso funciona, precisa voltar a 2007. O Windows Vista introduziu um recurso chamado Transactional NTFS (TxF) — basicamente, um sistema que torna operações de arquivo mais confiáveis gravando um log de transação antes de aplicar mudanças, do mesmo jeito que um banco de dados faz commit.

A ideia era boa: se o sistema crashar no meio de uma operação de arquivo, o TxF garante que nada fique num estado inconsistente. O problema? A Microsoft considerou o TxF deprecated em 2012, recomendou que ninguém usasse mais, mas nunca removeu o código.

E é aí que a coisa fica estranha.

O WinRE contém um componente que ativamente processa diretórios FsTx e “replaya” os logs de transação NTFS. Esse componente:

• Existe apenas no WinRE, não no Windows normal em execução
• Não tem documentação pública
• Não aparece em nenhuma referência técnica oficial

O pesquisador Will Dormann, conhecido na comunidade de segurança, confirmou a reprodução do exploit: “Bits de Transactional NTFS em um drive USB conseguem deletar o arquivo winpeshl.ini em OUTRO DRIVE (X:)”, resultando em acesso ao prompt de comando com o BitLocker desbloqueado.

A deleção do winpeshl.ini é a chave. Esse arquivo controla o que executa quando o WinRE inicia. Sem ele, o sistema fallback para um shell irrestrito — e nesse ponto o BitLocker já desbloqueou o volume porque o WinRE precisa de acesso para reparar o sistema.

Por que o pesquisador chama de backdoor

Eu sei o que você está pensando: “isso é só um bug, não um backdoor.” O Nightmare-Eclipse discorda, e os argumentos dele são interessantes.

Primeiro: o componente que processa os arquivos FsTx existe apenas no WinRE. Ele está presente nas imagens de instalação padrão do Windows, mas lá ele não exibe o comportamento de bypass do BitLocker. Só no WinRE a mágica acontece.

Segundo: depois que o exploit roda, os arquivos FsTx desaparecem do pendrive. Como o próprio pesquisador descreveu, “self-cleaning exploit” — uma característica que você esperaria de uma ferramenta forense, não de um bug acidental.

Terceiro: o mecanismo usa uma feature deprecated há 14 anos que a Microsoft nunca removeu, dentro de um ambiente que tem acesso privilegiado ao volume criptografado.

Nas palavras do pesquisador: “Eu simplesmente não consigo pensar em uma explicação além do fato de que isso foi intencional.”

Backdoor ou não, a realidade é que o exploit existe, funciona e está público. A distinção filosófica importa menos do que o fato de que qualquer pessoa com acesso físico ao seu notebook pode ler tudo no seu disco.

TPM+PIN não salva? Depende

Aqui tem um detalhe importante. O exploit como publicado ataca a configuração padrão do BitLocker no Windows 11: TPM-only, sem autenticação pre-boot, desbloqueio transparente no boot.

É assim que a maioria dos notebooks corporativos vem configurada. O Windows 11 ativa o BitLocker automaticamente com TPM-only, e a maioria dos admins de TI nem sabe que existe outra opção.

O pesquisador afirmou que “TPM+PIN não ajuda, o problema ainda é explorável”, mas até agora não publicou um PoC para essa configuração. Pesquisadores independentes não conseguiram reproduzir o bypass em sistemas com TPM+PIN ativo.

Na prática:

# Verificar sua configuração atual
manage-bde -status C:

# Adicionar protetor TPM+PIN (recomendado)
Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector

Se o seu BitLocker só mostra “TPM” como protetor, você está vulnerável. Se mostra “TPM and PIN”, provavelmente não — mas “provavelmente” não é garantia quando se trata de criptografia de disco.

Quem é o Nightmare-Eclipse

O pesquisador por trás do YellowKey não é um desconhecido. Usando os aliases Chaotic Eclipse e Nightmare-Eclipse, ele já publicou pelo menos cinco zero-days da Microsoft:

O que chama atenção é que nenhum desses foi corrigido pela Microsoft até o momento. Segundo a empresa de segurança Huntress, os PoCs do RedSun e UnDefend foram rapidamente incorporados em ataques reais após a publicação.

A motivação do pesquisador? Frustração. Ele alega que a Microsoft corrigiu vulnerabilidades anteriores dele “silenciosamente” — sem advisories, sem créditos, sem bug bounty. Em um post, mencionou que a Microsoft o deixou “sem casa e sem nada.”

É o tipo de situação que a indústria de segurança debate há décadas: full disclosure vs. responsible disclosure. Quando a empresa dona do software ignora o pesquisador, ele tem direito moral de soltar tudo publicamente? A resposta varia dependendo de quem você pergunta.

GreenPlasma: o segundo zero-day do pacote

Junto com o YellowKey, o Nightmare-Eclipse soltou outro exploit: o GreenPlasma. Esse é uma escalação de privilégios que explora o CTFMON (Collaborative Translation Framework Monitor), um componente do Windows que gerencia entrada de texto alternativa.

O GreenPlasma permite que um usuário sem privilégios crie objetos de seção de memória arbitrários em caminhos privilegiados, potencialmente obtendo um shell com permissões de SYSTEM.

A boa notícia (relativa) é que o PoC publicado está incompleto — falta o código final para obter o shell SYSTEM. A má notícia é que qualquer pesquisador competente consegue completar o que falta.

O pesquisador prometeu “uma grande surpresa” para o Patch Tuesday de junho de 2026. Considerando o histórico, não seria exagero esperar mais zero-days.

O que fazer agora: mitigações práticas

Não existe patch. A Microsoft reconheceu o problema dizendo que “tem compromisso com os clientes de investigar problemas de segurança reportados e atualizar dispositivos impactados”, mas não deu prazo.

Enquanto isso, aqui está o que você pode fazer:

1. Ativar TPM+PIN imediatamente

# Via Group Policy
# Computer Configuration > Administrative Templates >
# Windows Components > BitLocker Drive Encryption >
# Operating System Drives > Require additional authentication at startup
# Selecionar: Require startup PIN with TPM

# Ou via PowerShell direto
$SecureString = ConvertTo-SecureString "SeuPIN" -AsPlainText -Force
Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector -Pin $SecureString

2. Desabilitar o WinRE

# Verificar status
reagentc /info

# Desabilitar
reagentc /disable

Isso sacrifica o ambiente de recuperação, mas elimina o vetor de ataque. Em ambientes corporativos onde a TI faz reimaging, geralmente não faz falta.

3. Configurar BIOS/UEFI

• Definir senha de BIOS/UEFI
• Restringir boot apenas para o drive interno
• Ativar Secure Boot
• Desabilitar boot por USB

4. Monitorar boots em WinRE

Em ambientes enterprise, configure alertas para boots inesperados no WinRE. Qualquer máquina que entre em modo de recuperação sem motivo aparente deve ser investigada.

5. Considerar alternativas ao BitLocker

Para dados realmente sensíveis, soluções como VeraCrypt com volumes ocultos oferecem camadas adicionais de proteção que não dependem do WinRE.

O elefante na sala: acesso físico

Uma contra-argumentação comum é: “se o atacante tem acesso físico, já era de qualquer jeito.” Isso é verdade em muitos cenários, mas não deveria ser verdade para criptografia de disco completo. O propósito inteiro do BitLocker é proteger dados quando alguém tem acesso físico — notebook roubado, apreendido em fronteira, esquecido no aeroporto.

Se a criptografia de disco pode ser bypassada com um pendrive e dois minutos, ela não está cumprindo seu propósito fundamental.

Comparando com outros ataques ao BitLocker:

O YellowKey é, de longe, o ataque mais acessível já documentado contra o BitLocker. Não precisa de hardware especializado, não precisa de conhecimento profundo, não precisa de nada além de um pendrive formatado corretamente.

Microsoft e o padrão de silêncio

Essa não é a primeira vez que a Microsoft é acusada de lidar mal com vulnerabilidades. O caso do Nightmare-Eclipse é sintomático de um problema maior: a relação cada vez mais tensa entre pesquisadores de segurança independentes e big techs.

O programa de bug bounty da Microsoft — o MSRC (Microsoft Security Response Center) — paga recompensas que variam de $500 a $250.000 dependendo da severidade. Mas pesquisadores frequentemente reclamam de:

• Respostas que demoram meses
• Patches silenciosos sem crédito
• Classificação de severidade mais baixa do que o bug merece
• Bugs simplesmente ignorados

Quando um pesquisador sente que seu trabalho foi desvalorizado, a tentação de fazer full disclosure é enorme. E quando isso acontece, quem sofre são os usuários.

Quem deveria se preocupar

Se você usa Windows 11 com BitLocker em qualquer uma dessas situações, preste atenção:

• Notebooks corporativos com dados sensíveis
• Equipamentos de compliance (LGPD, HIPAA, SOX)
• Máquinas de desenvolvedores com chaves SSH, tokens de API, credenciais
• Laptops que viajam — especialmente para conferências ou cruzando fronteiras
• Servidores Windows em colocation ou data centers compartilhados

A combinação de acesso físico + dois minutos + pendrive é um cenário realista demais para ignorar.

O que esperar da Microsoft

O próximo Patch Tuesday é em 10 de junho de 2026. O pesquisador prometeu mais surpresas nessa data, então é provável que a Microsoft esteja correndo para corrigir o YellowKey antes disso.

Mas mesmo que o patch venha, fica uma questão maior: como um componente não documentado que processa transações NTFS deprecated há 14 anos conseguiu sobreviver dentro do WinRE por tanto tempo? Foi negligência? Foi intencional? Foi um caso de “ninguém audita código legado”?

A resposta provavelmente nunca vai sair da Microsoft. Mas independente da motivação, o resultado é o mesmo: milhões de máquinas com Windows 11 estão vulneráveis a um ataque que precisa de menos sofisticação técnica do que instalar o próprio Windows.

Se você ainda não ativou TPM+PIN no seu BitLocker, esse é o momento. Não espera o patch. Não espera a próxima surpresa do Nightmare-Eclipse. Faz agora.

—

Fonte de inspiração: A security researcher says Microsoft secretly built a backdoor into BitLocker, releases an exploit to prove it — TechSpot