Microsoft mitiga falha `YellowKey` que contorna BitLocker em sistemas Windows

A vulnerabilidade CVE-2026-45585 permite que um atacante com acesso físico use arquivos FsTx preparados para abrir um shell no WinRE e acessar dados em volume protegido por BitLocker.

Componente	BitLocker Device Encryption no Windows, com acionamento pelo Ambiente de Recuperação do Windows (WinRE) e pelo utilitário autofstx.exe associado a FsTx.
Vetor	Acesso físico ao computador, mídia USB ou partição EFI contendo arquivos FsTx especialmente criados, reinicialização para o WinRE e acionamento do fluxo mantendo CTRL pressionado.
Impacto	Desvio do recurso de segurança do BitLocker, com possibilidade de acesso irrestrito ao volume de sistema já protegido por criptografia quando as pré-condições do ataque são atendidas.
Prioridade	Aplicar a mitigação do fornecedor, remover autofstx.exe de BootExecute no hive montado do WinRE quando aplicável e migrar protetores TPM-only para TPM+PIN.
Versões	Windows 11 versão 26H1 para sistemas x64, Windows 11 versão 24H2 para sistemas x64, Windows 11 versão 25H2 para sistemas x64, Windows Server 2025 e Windows Server 2025 em instalação Server Core.
Artefatos	CVE-2026-45585, YellowKey, FsTx, WinRE, autofstx.exe, winpeshl.ini, BootExecute, REG_MULTI_SZ, TPM-only e TPM+PIN.
Mitigação	Configurar exigência de PIN na inicialização com Require additional authentication at startup e Configure TPM startup PIN definido para exigir PIN com TPM em dispositivos ainda não criptografados.

Resumo técnico

A Microsoft disponibilizou mitigação para a vulnerabilidade CVE-2026-45585, conhecida publicamente como YellowKey, uma falha de desvio de recurso de segurança no BitLocker. A vulnerabilidade recebeu pontuação CVSS 6.8 e não descreve quebra criptográfica direta do volume protegido. O ponto técnico central está no caminho de recuperação do Windows: um atacante que controle fisicamente a máquina pode induzir o WinRE a iniciar um shell em uma condição na qual o volume de sistema protegido por BitLocker fica acessível. O resultado prático é a perda da propriedade esperada de proteção contra leitura de dados em repouso quando o dispositivo está desligado, perdido, furtado ou temporariamente fora da custódia do proprietário.

O ataque exige condições locais e não é um vetor remoto. A exploração pública envolve a colocação de arquivos FsTx especialmente preparados em uma mídia USB ou em uma partição EFI, seguida de reinicialização para o Ambiente de Recuperação do Windows. Durante o fluxo, o uso da tecla CTRL aciona a abertura de um shell com acesso amplo ao volume protegido. Em ambientes corporativos, o risco se concentra em notebooks, estáções administrativas, dispositivos de campo, máquinas compartilhadas e servidores Windows expostos a acesso físico por operadores não confiáveis. A mitigação principal é reduzir a dependência de liberação automática baseada apenas em TPM, passando de TPM-only para TPM+PIN, e impedir que autofstx.exe seja iniciado automaticamente dentro da imagem de recuperação.

Fluxo técnico

O fluxo de exploração descrito para YellowKey começa fora do sistema operacional iniciado normalmente. O atacante prepara uma mídia removível com arquivos FsTx criados para interagir com o mecanismo de recuperação baseado em Transactional NTFS. Essa mídia é conectada ao computador que já possui proteção BitLocker ativada. Em seguida, o dispositivo é reinicializado para o WinRE. O ponto de falha está na forma como a recuperação processa esse material FsTx e no encadeamento que envolve o utilitário autofstx.exe. Quando o comportamento é acionado corretamente, a sequência interfere no caminho normal de inicialização da interface de recuperação e resulta na abertura de uma linha de comando.

A condição crítica é que o volume protegido já esteja disponível no contexto de recuperação. Em uma configuração TPM-only, o TPM pode liberar a chave de proteção quando a sequência de inicialização aparenta cumprir as medições esperadas. O ataque não precisa descobrir o PIN do usuário, capturar a chave de recuperação de 48 dígitos nem executar código dentro de uma sessão autenticada do Windows. Ele explora uma janela de confiança entre a recuperação, o processamento de FsTx e a disponibilidade do volume. A presença ou remoção de winpeshl.ini é relevante porque esse arquivo controla a shell carregada em ambientes Windows PE e WinRE; quando o fluxo esperado falha, a recuperação pode cair em cmd.exe.

A mitigação indicada para o componente autofstx.exe altera esse caminho de execução. Ao remover o valor autofstx.exe da entrada BootExecute do Session Manager, armazenada como REG_MULTI_SZ no hive montado da imagem do WinRE, o administrador impede que o FsTx Auto Recovery Utility seja iniciado automaticamente quando a imagem de recuperação é carregada. Com isso, o replay transacional associado ao fluxo de FsTx deixa de produzir o mesmo efeito no arquivo winpeshl.ini. Essa mitigação deve ser tratada como alteração sensível de imagem de recuperação: após a modificação, é necessário restabelecer a confiança do BitLocker no WinRE e validar que a recuperação legítima continua funcional.

Superfície afetada

A superfície confirmada inclui Windows 11 versão 26H1 para sistemas x64, Windows 11 versão 24H2 para sistemas x64, Windows 11 versão 25H2 para sistemas x64, Windows Server 2025 e Windows Server 2025 em instalação Server Core. O cenário de maior exposição é a configuração em que o BitLocker usa protetor TPM-only, pois a liberação da chave depende apenas das medições aceitas pelo TPM e não de um fator digitado antes do desbloqueio. A presença de criptografia no disco, isoladamente, não elimina o risco se o ambiente de recuperação conseguir acessar o volume em um estado confiável para o sistema.

A vulnerabilidade afeta principalmente controles de proteção física e de dados em repouso. O atacante precisa interagir com o equipamento, conectar mídia ou manipular partição de inicialização, reiniciar a máquina e alcançar o WinRE. Isso reduz a exposição para ataques puramente remotos, mas aumenta o impacto em modelos de ameaça que incluem perda de notebook, acesso por terceiros em escritório, manutenção não supervisionada, ambientes de laboratório, quiosques, máquinas de uso compartilhado e equipamentos armazenados fora de sala controlada. Organizações que tratam BitLocker como compensação principal para roubo de dispositivo devem revisar a configuração dos protetores antes de considerar a exposição encerrada.

A configuração TPM+PIN muda a pré-condição de exploração porque exige entrada interativa antes da liberação da chave de inicialização. Em dispositivos já criptografados com TPM-only, a mudança pode ser feita por PowerShell, linha de comando ou painel de controle, desde que alinhada à política de gerenciamento de chaves e recuperação. Em dispositivos ainda não criptografados, a política deve ser definida antes da ativação para evitar que o parque seja provisionado com a configuração vulnerável por padrão.

• Windows 11 versão 26H1, 24H2 e 25H2 em sistemas x64.
• Windows Server 2025, incluindo instalação Server Core.
• Dispositivos com BitLocker habilitado e protetor TPM-only.
• Ambientes em que usuários ou terceiros conseguem iniciar WinRE com mídia removível conectada.

Hunting e telemetria

A detecção deve combinar inventário de configuração, telemetria de inicialização, sinais de recuperação e evidências de acesso físico. Como o vetor depende de presença local, não se deve esperar um IoC de rede universal. O primeiro ponto de hunting é identificar dispositivos com BitLocker ativo usando TPM-only, especialmente em grupos de alto valor, máquinas administrativas, estáções de engenharia, notebooks executivos e servidores Windows Server 2025 acessíveis por console. Em seguida, a equipe deve verificar se a imagem de WinRE contém a entrada autofstx.exe em BootExecute e se a mitigação foi aplicada de forma consistente.

Em endpoints, procure reinicializações incomuns para recuperação, abertura inesperada de ambientes Windows PE, falhas ou alterações no fluxo de WinRE, montagem de mídias removíveis antes de boot de recuperação e alterações em arquivos associados à imagem de recuperação. Evidências pós-evento podem incluir lacunas de logs por desligamento abrupto, mudança de ordem de boot em firmware, uso recente de USB, registros de inventário indicando recuperação manual e discrepância entre o estado de proteção do BitLocker e o fluxo de autenticação pré-boot esperado. Em ambientes gerenciados, essas evidências devem ser correlacionadas com logs de EDR, inventário MDM, registros de suporte técnico e trilhas de custódia física.

A investigação de um dispositivo suspeito deve preservar o estado do equipamento antes de qualquer alteração de mitigação. Quando houver suspeita de acesso físico, trate o volume como potencialmente exposto mesmo sem sinal de login no Windows, pois o ataque ocorre fora da sessão normal do usuário. A equipe de DFIR deve registrar configuração de protetores, estado do WinRE, histórico de boot, dispositivos externos conectados, alterações de firmware e qualquer modificação em BootExecute, winpeshl.ini ou artefatos FsTx em volumes locais ou removíveis.

• Inventário de máquinas com BitLocker em modo TPM-only.
• Presença de autofstx.exe na entrada BootExecute do Session Manager na imagem de WinRE.
• Inicializações recentes em WinRE sem chamado de suporte ou manutenção autorizada.
• Uso de mídia USB antes de eventos de recuperação ou alteração de ordem de boot.
• Evidência de acesso a volume protegido sem autenticação normal do usuário no Windows.

Mitigação

A resposta deve começar pela priorização de ativos em que acesso físico e dados sensíveis se encontram no mesmo risco: notebooks corporativos, máquinas de administradores, estáções com segredos de desenvolvimento, equipamentos de resposta a incidentes e servidores Windows Server 2025 com console acessível. Para dispositivos já criptografados com TPM-only, a ação defensiva principal é migrar para TPM+PIN. Essa mudança força uma autenticação pré-boot e impede que a liberação do volume dependa apenas da confiança medida pelo TPM. A configuração deve ser aplicada por ferramenta de gerenciamento central quando disponível, para evitar exceções silenciosas em grupos remotos.

A segunda frente é aplicar a mitigação específica no WinRE. Administradores podem montar a imagem de recuperação, alterar o valor BootExecute de Session Manager removendo autofstx.exe do REG_MULTI_SZ e depois restabelecer a confiança do BitLocker na imagem modificada. Esse procedimento precisa ser testado em amostra controlada antes de ampla distribuição, pois qualquer erro no ambiente de recuperação pode afetar suporte, restauração e processos de recuperação operacional. A validação deve confirmar três pontos: o sistema inicializa normalmente, o WinRE ainda atende aos fluxos legítimos e o ataque baseado em FsTx não aciona shell com acesso ao volume.

Para dispositivos ainda não criptografados, defina a política antes de habilitar BitLocker. A opção Require additional authentication at startup deve ser habilitada, e Configure TPM startup PIN deve exigir PIN com TPM. Essa ordem evita provisionamento com o protetor mais fraco e reduz retrabalho posterior. Também é recomendável revisar controles físicos: bloquear boot por mídia externa onde o negócio permitir, proteger configuração de firmware, exigir senha de UEFI, limitar acesso a portas em ambientes compartilhados e reforçar procedimentos para perda, furto ou ausência temporária de equipamentos críticos. Após a mitigação, faça nova varredura de conformidade para confirmar que não restaram máquinas em TPM-only fora de exceções formalmente aprovadas.

• Migrar dispositivos já criptografados de TPM-only para TPM+PIN.
• Remover autofstx.exe de BootExecute no hive montado do WinRE quando a mitigação operacional for adotada.
• Restabelecer a confiança do BitLocker na imagem de recuperação após alterar o WinRE.
• Habilitar Require additional authentication at startup antes de criptografar novos dispositivos.
• Definir Configure TPM startup PIN como exigência de PIN com TPM.
• Revisar boot por mídia externa, senha de firmware e processo de resposta para dispositivos perdidos ou acessados fisicamente.