BlackX, bootkit UEFI, ataca missões diplomáticas do Tajiquistão, do Uzbequistão e do Turquemenistão

Nas primeiras semanas de 2026, organizações diplomáticas na Ásia Central, concretamente no Tajiquistão, no Uzbequistão e no Turquemenistão, foram atacadas com um novo bootkit UEFI que os investigadores da Kaspersky nomearam como BlackX. Segundo o relatório técnico publicado pela assinatura russa, o objetivo principal deste malware é minar as defesas de arranque do Windows e desativar ou contornar soluções de segurança de terceiros para manter acesso persistente e encoberto a equipamentos de alto valor.

Os fatos confirmados pela Kaspersky são os seguintes: BlackX atua a nível do firmware UEFI, instala componentes tanto na partição do sistema como na partição UEFI, explora uma vulnerabilidade conhecida no Secure Boot (CVE-2022-21894, a chamada "Baton Drop") e entrega um payload de kernel que injeta um driver assinado fraudulentamente e um conjunto de cargas úteis em espaço de usuário dedicadas a espionagem e controle remoto. A assinatura observou ficheiros específicos usados na instalação — por exemplo, um executável instalado em C:\ProgramData\Intel\inst.exe e um ficheiro encriptado usado como pacote — e procedimentos de execução com chaves RC4 que permitem a descompressão e escrita de componentes em disco.

Tecnicamente, BlackX retoma a mesma técnica que o bootkit BlackLotus: adicionar chaves (MOK, Machine Owner Keys) ou carregar binários EFI antes de o sistema operacional iniciar, de modo que o código malicioso seja executado com privilégios muito cedo e possa interferir com o Secure Boot e mecanismos antimalware. A exploração de CVE‐2022‐21894 permite precisamente carregar binários não autorizados nessa fase. É importante salientar que a exploração não é trivial: para implantar um bootkit amplamente o atacante precisa de privilégios administrativos na máquina ou acesso físico à equipe; portanto, o BlackX é usado como mecanismo de persistência e evasão após um compromisso inicial, não como vetor inicial, algo já apontado pela Microsoft quando se documentou o BlackLotus.

O que faz o código após a carga: O componente UEFI instala um driver do kernel assinado com um certificado pertencente a uma entidade que posteriormente foi revogada e tenta alterar o funcionamento de soluções de segurança no sistema (com rotinas específicas para produtos da Kaspersky e do Avast, que a Kaspersky considera ineficazes na amostra analisada). Além disso, o pacote inclui cargas em espaço de usuário: um troiano de acesso remoto que pode baixar módulos .NET e usar serviços legítimos de sincronização na nuvem como Google Drive, OneDrive e Yandex.Disk como canais de comando e controle para camuflar o tráfego, e um DLL maliciosa (sideloaded pelo Googleupdate.exe) que executa um binário em Rust que conta com um domínio remoto para receber plugins adicionais.

A atribuição técnica é parcial e cautelosa: Kaspersky liga a campanha a um ator com metodologias consistentes com ataques patrocinados pela China, e associa BlackX com APT41 com base em sobreposições técnicas e táticas e em análises cruzadas com relatos prévios. ESET, por sua vez, tem documentado famílias e operações sob o guarda-chuva de APT41 (FishMonger/Aquatic Panda) que usaram backdoors como SprySOCKS e, por vezes, componentes UEFI. Estas ligações são, no entanto, estimativas baseadas em indicadores e padrões de comportamento: a atribuição a um actor estatal continua a ser uma inferência forense, não um teste irrefutável.

Por que alguns sistemas continuam vulneráveis, mesmo que estejam "parcheados": a vulnerabilidade CVE‐2022‐21894 tem um adesivo, mas mitigações adicionais requerem passos manuais para adicionar e bloquear certificados na lista de bloqueio do Secure Boot (DBX). O Kaspersky indica que muitos administradores não realizaram essas ações manuais — por exemplo, adicionar a CA usada por certos binários à lista proibida — e por isso o BlackX pode continuar a ser efetivo mesmo em máquinas com atualizações aplicadas. Para detalhes sobre a proteção do processo de arranque e gestão do DBX, a Microsoft mantém documentação técnica de referência: Microsoft Secure Boot guidance.

Consequências práticas: a presença de um bootkit como BlackX em um ambiente diplomático significa controle persistente abaixo do sistema operacional, dificuldade superior para detectar a intrusão com ferramentas tradicionais, e risco real de espionagem contínua (recopilação de arquivos, exfiltração discreta, movimentos laterais com credenciais comprometidas). Além disso, se os binários maliciosos estiverem inscritos no firmware ou se adicionaram chaves MOK, uma simples reinstalação do sistema operacional não garante a remediação; a infecção pode sobreviver a uma formatação sem intervenção a nível do firmware.

O que é seguro e o que não está confirmado: é confirmado que Kaspersky observou a campanha contra missões diplomáticas nos países citados e que o bootkit reutiliza a técnica de BlackLotus para evadir Secure Boot. É uma estimativa razoável, apoiada por análise da ESET, que atores associados a APT41 estão atrás, mas a atribuição completa pode conter incertezas e depende de correlações de indicadores e metodologias. Também se desconhece publicamente se o código original de BlackLotus foi comprado ou replicado por engenharia inversa; ambos os cenários são plausível e mencionados pelos especialistas.

Recomendações concretas e imediatas para administradores e responsáveis pela segurança:

1) Auditar e aplicar a mitigação de DBX/Forbidden List: Além de instalar todos os adesivos do Windows, execute os passos manuais recomendados pela Microsoft para gerir a lista de certificados bloqueados no Secure Boot e garantir que os certificados autorizados não permitam a carga de binários maliciosos (ver guia da Microsoft acima).

2) Rever a integridade do firmware e partições UEFI: Use ferramentas forenses e de integridade como CHIPSEC (https://github.com/chipsec/chipsec) para detectar modificações na partição EFI, chaves adicionadas (MOK) ou binários inesperados no arranque.

3) Se houver suspeita de compromisso, isolar e forensear antes de reparar: Imagens de disco offline, carregadas de memória e análises da partição UEFI devem preceder qualquer reinstalação. Em ambientes diplomáticos de alto risco, considere reflasheo de firmware por fornecedores confiáveis e reinstalação completa de meios verificados.

4) Rever privilégios e vetores de acesso inicial: Como a implantação requer privilégios elevados ou acesso físico, investigue como os atacantes obtiveram esses privilégios (phishing, credenciais expostas, exploração de serviços, acesso físico) e aplique mitigações: rotação de senhas, autenticação multifator, segmentação de redes, revisão de contas com privilégios e controle de acesso físico.

5) Monitorizar o tráfego de saída e atividades invulgares em serviços na nuvem: BlackX usa serviços legítimos de sincronização como C2; audite uso de contas no Google Drive, OneDrive e Yandex.Disk, e estabeleça políticas de controle e alertas para acessos não habituais.

As ameaças ao nível da UEFI aumentam a lista técnica da resposta e obrigam as organizações de alta exposição a reverem os seus processos de governação sobre firmware, adesivos e listas de confiança. Para compreender o contexto e antecedentes técnicos do vetor original BlackLotus, convém revisar a análise do ESET publicada em 2023 sobre esse bootkit: ESET — BlackLotus analysis. Para referências de CVE e detalhes técnicos das vulnerabilidades citadas, consulte as fichas oficiais em NVD: CVE‐2022‐21894 e CVE‐2023‐24932.

Em suma, BlackX é um ressurgimento e adaptação de uma técnica de alto impacto que obriga a deixar de lado soluções superficiais (apenas aplicar o adesivo) e a assumir uma abordagem forense e de firmware completo. Para organizações diplomáticas e outras instituições críticas, a prioridade deve ser verificar a integridade do arranque e fechar os vetores que permitiram o ingresso inicial do atacante.