As falhas YellowKey e GreenPlasma envolvem abuso do ambiente de recuperação do Windows, objetos transacionais de NTFS e criação arbitrária de seções de memória com possível impacto em privilégios locais.
| Componente | Windows Recovery Environment (WinRE), BitLocker, Windows Collaborative Translation Framework (CTFMON) e objetos de seção de memória do Windows. |
| Vetor | YellowKey exige interação com o fluxo de recuperação do Windows e uso de arquivos FsTx especialmente preparados em mídia USB ou partição EFI; GreenPlasma parte de uma conta local sem privilégio para criar objetos de seção em diretórios controlados por SYSTEM. |
| Impacto | YellowKey pode expor um prompt cmd.exe com o volume BitLocker desbloqueado dentro do ambiente de recuperação; GreenPlasma pode abrir caminho para manipulação de serviços ou drivers privilegiados que confiem em caminhos criados sob contexto elevado. |
| Prioridade | Tratar máquinas Windows com acesso físico possível como expostas, revisar uso de WinRE, validar controles de pré-inicialização, monitorar alterações em partições EFI e acompanhar correções oficiais para as falhas ainda sem identificador público confirmado. |
| Versões | YellowKey foi descrita como afetando Windows 11 e Windows Server 2022/2025. O contexto público não informa versões específicas vulneráveis para GreenPlasma. |
| Artefatos | FsTx, \System Volume Information\FsTx, winpeshl.ini, cmd.exe, bootmgfw.efi, objetos de seção de memória e diretórios graváveis por SYSTEM. |
| Mitigação | Restringir acesso físico, controlar boot por USB, revisar Secure Boot e certificados de inicialização, migrar para CA 2023 quando aplicável, revogar confiança antiga em PCA 2011 conforme orientação operacional e aplicar atualizações assim que disponibilizadas. |
Duas falhas zero-day foram detalhadas em componentes distintos do Windows e ampliam a superfície de risco em estáções e servidores que dependem de BitLocker, recuperação local e isolamento de privilégios do sistema operacional. A primeira, chamada YellowKey, envolve um desvio de proteção no fluxo do Windows Recovery Environment (WinRE) quando arquivos FsTx preparados são introduzidos por USB ou pela partição EFI antes da inicialização em modo de recuperação. A condição descrita permite chegar a um shell cmd.exe em um estado no qual o volume protegido por BitLocker já está acessível, reduzindo a efetividade esperada da criptografia de disco quando o adversário consegue interagir com o processo de boot e recuperação.
A segunda falha, chamada GreenPlasma, afeta o Windows Collaborative Translation Framework (CTFMON) e foi descrita como uma escalada de privilégio local baseada em criação arbitrária de objetos de seção de memória. A prova de conceito pública é incompleta para obter diretamente um shell com SYSTEM, mas o primitivo exposto é relevante: um usuário sem privilégio pode criar objetos de seção dentro de diretórios nos quais o contexto SYSTEM possui escrita, o que pode ser explorado contra serviços, drivers ou fluxos privilegiados que assumam incorretamente a integridade desses locais. O risco principal não está em execução remota, mas na combinação entre presença local, confiança indevida em namespaces do Windows e caminhos privilegiados usados por componentes do sistema.
YellowKey se apoia em uma sequência de pré-inicialização. O operador prepara arquivos FsTx em uma mídia USB ou em uma partição EFI, conecta a mídia ao computador Windows com BitLocker habilitado e força a entrada no WinRE. Durante a inicialização do ambiente de recuperação, a reprodução de metadados transacionais relacionados a NTFS cria uma condição inesperada: dados em \System Volume Information\FsTx de um volume passam a afetar conteúdo em outro volume, incluindo o arquivo winpeshl.ini usado pelo ambiente de recuperação para controlar o shell inicial. Quando o fluxo é acionado, a sessão pode terminar em cmd.exe em vez da experiência esperada de recuperação, com o volume protegido já desbloqueado.
O detalhe mais sensível é que o problema não se limita a uma configuração fraca de BitLocker baseada apenas em TPM. A descrição pública da falha afirma que a combinação TPM com PIN não elimina a condição explorável para YellowKey, o que torna inadequado tratar o PIN como mitigação isolada para essa falha específica até que a causa raiz seja corrigida. A implicação técnica é que o defeito está no processamento do ambiente de recuperação e na interação entre volumes, não apenas na política de liberação de chave. Para defesa, isso desloca a prioridade para reduzir acesso físico, bloquear inicialização por mídia externa, endurecer o caminho de recuperação e acompanhar correção de fornecedor.
GreenPlasma segue outro modelo de exploração. Em vez de atacar o boot, a falha fornece a uma conta local sem privilégio a capacidade de criar objetos de seção de memória em diretórios que normalmente são controlados por processos privilegiados. Objetos de seção são usados pelo Windows para mapear regiões de memória compartilhada ou arquivos em memória entre processos. Quando um componente privilegiado confia em um caminho ou namespace sem validar corretamente origem, permissões e propriedade, um objeto criado por usuário comum pode interferir em uma operação executada por SYSTEM. A prova de conceito pública não entrega a cadeia completa de exploração, mas o primitivo é suficiente para justificar análise de serviços locais, drivers e agentes de segurança que utilizem objetos nomeados ou diretórios de objetos com permissões amplas.
O conjunto de divulgações também se conecta a falhas anteriores em produtos de segurança da Microsoft. Três zero-days do Defender, conhecidos como BlueHammer, RedSun e UnDefend, haviam sido divulgados anteriormente pelo mesmo pesquisador; BlueHammer recebeu o identificador CVE-2026-33825 e foi corrigido, enquanto RedSun teria sido ajustado sem boletim público associado. Como algumas dessas falhas anteriores foram relatadas em exploração ativa, equipes de defesa devem separar a análise em dois blocos: vulnerabilidades com correção publicada e vulnerabilidades ainda sem cadeia de exploração completa confirmada. Essa distinção evita tanto subestimação do risco quanto criação de indicadores artificiais.
A superfície mais crítica para YellowKey inclui endpoints Windows 11, servidores Windows Server 2022 e Windows Server 2025 que usam BitLocker e mantêm WinRE acessível para recuperação local. Ambientes corporativos com notebooks, estáções de administradores, quiosques, laboratórios, máquinas compartilhadas, filiais e equipamentos em locais sem controle físico rigoroso merecem avaliação prioritária. A exploração descrita depende de interação com o processo de inicialização e de capacidade para introduzir mídia ou alterar partição EFI; portanto, o risco aumenta quando a organização permite boot por USB, mantém firmware sem senha administrativa, não controla ordem de boot ou deixa portas físicas acessíveis a usuários não confiáveis.
Para GreenPlasma, a exposição está em sistemas nos quais usuários locais não privilegiados podem executar código e interagir com namespaces do Windows usados por CTFMON e por componentes que consomem objetos de seção. Ambientes multiusuário, servidores com sessões interativas, hosts de desenvolvimento, máquinas de help desk, estáções VDI e servidores com agentes locais são candidatos à revisão. O impacto depende da existência de serviço, driver ou processo privilegiado que aceite ou abra objetos em caminhos manipuláveis. Sem esse elo adicional, a falha expõe um primitivo; com ele, pode virar escalada para SYSTEM.
Há ainda um vetor relacionado a BitLocker já corrigido em julho de 2025, identificado como CVE-2025-48804, que usa downgrade do gerenciador de boot para desviar a criptografia em Windows 11 corrigido quando uma versão vulnerável de bootmgfw.efi, ainda assinada por certificado confiável, é carregada. Nessa cadeia, o carregador valida a integridade de um WIM legítimo, mas inicializa outro WIM controlado por atacante a partir de uma tabela modificada em um arquivo SDI. O WIM controlado pode conter uma imagem WinRE adulterada com cmd.exe, executando com o volume BitLocker descriptografado. Esse caso exige acesso físico e difere de YellowKey, mas reforça que criptografia de disco depende também da cadeia de boot, de revogação de certificados antigos e de política de pré-inicialização.
- Windows 11 e Windows Server 2022/2025 com BitLocker e
WinREhabilitado devem ser inventariados para exposição aYellowKey. - Hosts que permitem boot por USB, alteração de ordem de boot ou acesso não supervisionado ao firmware têm risco operacional maior.
- Sistemas multiusuário com execução local por contas comuns devem ser avaliados para abuso de objetos de seção associado a
GreenPlasma. - Ambientes que ainda confiam em binários de boot antigos assinados pela PCA 2011 devem revisar a migração para certificados mais recentes e revogação da cadeia antiga.
A detecção de YellowKey deve começar pela correlação entre eventos de boot, uso de WinRE, presença de mídia removível e alterações em partições EFI. Como a exploração ocorre antes do sistema operacional principal estar plenamente carregado, a visibilidade tradicional de EDR pode ser limitada. Equipes devem reforçar telemetria de firmware, logs de BitLocker, eventos de recuperação, inventário de configuração de Secure Boot, registros de alteração em volumes EFI e qualquer evidência de acesso físico fora de janela operacional. Em notebooks de alto valor, uma inicialização inesperada em ambiente de recuperação seguida de acesso administrativo local deve ser tratada como evento de investigação, não como simples suporte técnico.
Em endpoints Windows, procurar artefatos relacionados a \System Volume Information\FsTx em mídia removível, alterações incomuns de winpeshl.ini, uso inesperado de cmd.exe a partir do ambiente de recuperação e mudanças de estado do BitLocker pode ajudar a reconstruir a linha do tempo. O objetivo é identificar a condição de pré-inicialização e o momento em que o volume foi montado desbloqueado. Como parte da coleta, preservar imagem da partição EFI, lista de dispositivos USB conectados, estado de Secure Boot, protetores BitLocker configurados e histórico de recuperação reduz o risco de perder evidência volátil.
Para GreenPlasma, o hunting deve se concentrar em criação anômala de objetos de seção, falhas ou reinicializações de serviços privilegiados, cargas inesperadas por drivers e processos que executam sob SYSTEM abrindo objetos nomeados criados por usuários comuns. Logs nativos do Windows podem não expor todos os detalhes necessários, então ambientes com Sysmon, EDR ou sensores de núcleo devem buscar eventos de criação de seção, manipulação de handles, acesso a namespaces de objetos e relacionamento entre processo de baixa integridade e processo privilegiado. O indicador mais útil é comportamental: uma conta sem privilégio produzindo objetos usados logo depois por serviço elevado.
A análise deve evitar dependência exclusiva de IoCs estáticos, porque o material analisado não inclui hashes, endereços IP, domínios, payloads finais ou binários específicos. Para essas falhas, a telemetria de cadeia de execução é mais valiosa do que uma lista fixa de artefatos. Em resposta a possível exploração, preservar memória, handles abertos, árvore de processos, objetos nomeados ativos e estado de serviços permite confirmar se o primitivo foi apenas testado ou se foi combinado com outro erro para obter execução elevada.
- Inicialização inesperada em
WinRE, principalmente em máquinas com BitLocker e presença recente de mídia USB. - Diretórios
\System Volume Information\FsTxem volumes removíveis ou partições manipuláveis antes da recuperação. - Alteração, exclusão ou comportamento incomum envolvendo
winpeshl.inie execução decmd.exeno ambiente de recuperação. - Criação de objetos de seção por processos de usuário comum em namespaces ou diretórios posteriormente acessados por processos
SYSTEM. - Uso de
bootmgfw.efiantigo ou incompatível com o estado esperado de correção e cadeia de certificados do ambiente.
A resposta deve separar controles imediatos de correções definitivas. Para YellowKey, enquanto não houver correção pública específica associada à causa raiz, a ação principal é reduzir a possibilidade de exploração física e endurecer o caminho de boot. Isso inclui desabilitar boot por USB quando não for necessário, exigir senha administrativa no firmware, validar a ordem de inicialização, manter Secure Boot ativo, restringir acesso físico a máquinas de alto valor e revisar quando WinRE precisa permanecer habilitado. Em ambientes com suporte remoto maduro e inventário controlado, desabilitar ou limitar recursos de recuperação local pode ser considerado, desde que a organização mantenha procedimento confiável para recuperação operacional.
Para a cadeia de downgrade relacionada a CVE-2025-48804, a prioridade é confirmar aplicação das correções lançadas em julho de 2025, migrar o gerenciador de boot para a cadeia CA 2023 quando aplicável e remover confiança operacional em binários antigos assinados pela PCA 2011. Como Secure Boot pode aceitar um binário antigo se o certificado ainda for confiável, a validação precisa ir além de verificar se Secure Boot está ligado. A equipe deve confirmar a versão efetivamente carregada de bootmgfw.efi, o estado das revogações e a política de atualização de bootloaders em imagens corporativas, mídias de recuperação e processos de provisionamento.
GreenPlasma exige mitigação focada em redução de superfície local e revisão de confiança entre processos. Contas comuns não devem ter permissões desnecessárias em diretórios ou namespaces usados por serviços privilegiados. Serviços internos, agentes, drivers e ferramentas de administração que consomem objetos nomeados precisam validar propriedade, ACLs, integridade e origem antes de abrir objetos de seção. Onde houver EDR ou controle de aplicação, bloquear execução de provas de conceito não é suficiente; a defesa precisa identificar o padrão de criação de objetos e o caminho de consumo por processos elevados.
Após aplicação de controles, a validação deve incluir testes de inicialização, auditoria de BitLocker, revisão de chaves de recuperação, conferência de política de firmware, simulação controlada de recuperação e verificação de telemetria. Se houver suspeita de exploração, a organização deve tratar o host como potencialmente comprometido: coletar evidências, preservar partição EFI e logs, rotacionar segredos acessíveis ao equipamento, revisar sessões administrativas usadas na máquina e reinstalar a partir de mídia confiável quando a integridade do boot não puder ser demonstrada. Em servidores, a decisão deve considerar exposição física do datacenter, acesso de operadores, console remoto e qualquer mecanismo de montagem de mídia virtual.
- Bloquear boot por USB e proteger configuração de firmware com senha administrativa em equipamentos sensíveis.
- Revisar necessidade de
WinRElocal e controlar rigorosamente mídias de recuperação corporativas. - Confirmar aplicação de correções para
CVE-2025-48804e validar a versão real debootmgfw.efiusada na inicialização. - Migrar para a cadeia CA 2023 e revogar confiança em PCA 2011 conforme o plano de atualização do ambiente.
- Auditar ACLs e namespaces usados por serviços
SYSTEM, drivers e agentes que abrem objetos de seção. - Monitorar criação de objetos de seção por usuários comuns e correlacionar com acesso subsequente por processos privilegiados.
- Acompanhar atualizações oficiais para
YellowKeyeGreenPlasmae aplicar correções em janelas priorizadas para ativos com acesso físico possível.
0 Comentários