Como o APT41 ressuscitou o bootkit BlackLotus para atacar organizações diplomáticas na Ásia Central

Introdução

Em outubro de 2022, o Kaspersky GReAT investigava um anúncio peculiar em um fórum de hackers. Um cibercriminoso anunciava um bootkit UEFI, chamado BlackLotus, capaz de contornar o Secure Boot, por US$ 5.000. Como o preço pedido era considerado baixo para recursos tão poderosos, a comunidade de segurança cibernética inicialmente recebeu o anúncio com ceticismo. Além disso, como nenhuma amostra do BlackLotus havia sido encontrada em ambiente real, na época, ninguém podia confirmar o que dizia a publicação no fórum.

Anúncio do BlackLotus

No entanto, cerca de seis meses depois, em março de 2023, a ESET confirmou que o anúncio do BlackLotus não era falso. Os pesquisadores conseguiram localizar amostras desse bootkit e comprovar que ele de fato bypassa o Secure Boot por meio de uma vulnerabilidade chamada Baton Drop (CVE-2022-21894). Como essa vulnerabilidade ainda era explorável em 2023, a Microsoft precisou lançar várias atualizações de segurança para corrigi-la.

Desde o lançamento dessas atualizações, o bootkit BlackLotus saiu de cena. Não houve ataques publicamente conhecidos que o utilizassem. Porém, no início de 2026, descobrimos uma amostra de malware semelhante ao BlackLotus, usada em uma campanha de APT na Ásia Central. Neste relatório, compartilhamos os detalhes de nossas descobertas, incluindo novos payloads e a possível atribuição dessa campanha.

O retorno do notório bootkit

No início de 2026, identificamos um ataque complexo de APT contra órgãos diplomáticos do Tajiquistão, do Uzbequistão e do Turcomenistão, na Ásia Central. O ataque envolveu um bootkit UEFI, que batizamos de BlackX. Após examiná-lo, concluímos que ele é semelhante ao BlackLotus.

Os invasores vêm implantando o BlackX depois de comprometer as redes das vítimas e obter nelas privilégios de administrador. Para instalar o bootkit, observamos que eles gravam os seguintes arquivos no sistema:

• inst.exe, um executável de instalação;
• PVMDIJGKAX2, um arquivo sem extensão criptografado com RC4, que contém os arquivos e as strings necessários para a instalação.

O instalador foi iniciado com a linha de comando C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. O último argumento é a chave RC4 usada na descriptografia.

Curiosamente, o arquivo inst.exe não contém strings maliciosas nem blobs incorporados. Todos os arquivos necessários para instalar o código malicioso ficam dentro do PVMDIJGKAX2, para dificultar a recuperação dos componentes do bootkit pelas equipes de resposta a incidentes.

O pacote do instalador grava um conjunto de arquivos projetados para explorar a vulnerabilidade Baton Drop na partição do sistema e na partição UEFI. Observamos que a implementação do exploit é muito semelhante à usada no malware BlackLotus. Como no caso do BlackLotus, o objetivo do exploit é instalar Machine Owner Keys (MOK) personalizadas, para poder carregar quaisquer arquivos EFI nas máquinas-alvo e manipular o Secure Boot.

Embora a cadeia de exploração da vulnerabilidade tenha sido implementada de forma muito semelhante à do BlackLotus, identificamos diferenças entre os exploits encontrados no BlackLotus e no BlackX. Cabe lembrar que o código-fonte do bootkit BlackLotus nunca foi publicado na internet. Isso pode indicar que os invasores por trás do BlackX fizeram engenharia reversa do bootkit BlackLotus ou compraram seu código-fonte de cibercriminosos. De qualquer forma, trata-se de uma observação interessante, pois raramente vemos grupos de APT se apropriarem de ideias ou de código de grupos do cibercrime.

Payload executado pelo bootkit

O payload UEFI entregue durante a exploração do Baton Drop tem o objetivo clássico de um bootkit, que é injetar um driver malicioso no kernel do Windows. Esse driver é diferente do implantado pelo BlackLotus e é assinado com um certificado pertencente a uma organização chamada 温江区明宇网络技术服务工作室 (em inglês: Wenjiang District Mingyu Network Technology Service Studio). No momento da redação deste texto, esse certificado (número de série: 0bcdf5e0da32d68900b8b7638459d072) já foi revogado pelo emissor.

O objetivo desse driver é comprometer o funcionamento das soluções de segurança instaladas na máquina. Por exemplo, ele desativa callbacks de processos, threads e registro relacionados a esses produtos. Ele também manipula provedores ETW para que as soluções de segurança não tenham acesso à saída desses dados. Curiosamente, alguns dos procedimentos de adulteração foram projetados para serem executados somente se soluções da Kaspersky ou da Avast estiverem instaladas na máquina infectada. No entanto, ao realizar a análise dinâmica desse driver, observamos que esses procedimentos são inúteis. Eles não conseguem interferir de forma alguma nos produtos Kaspersky.

Outro ponto importante é que o driver protege os arquivos relacionados ao bootkit contra adulteração. Ele intercepta as solicitações do kernel para abrir esses arquivos e retorna um handle para o calc.exe em vez do handle do arquivo malicioso.

Payloads de segundo estágio em usermode

Além de comprometer as soluções de segurança, o driver é responsável por implantar um payload em usermode. Observamos em ambiente real dois payloads desse tipo, usados para ciberespionagem. Um deles é um RAT capaz de carregar payloads .NET de estágios posteriores. Esse RAT usa serviços de armazenamento em nuvem para a comunicação com o servidor C2. Observamos versões que utilizam Google Drive, OneDrive e Yandex.Disk. Depois de se conectar a um desses serviços, o RAT analisa os arquivos disponíveis nele e os interpreta de acordo com o sufixo do arquivo. A seguir, a lista de sufixos reconhecidos:

Além disso, observamos outro payload, que batizamos de OxiDLLRunner, entregue por meio do bootkit. Trata-se de uma DLL maliciosa ofuscada com OLLVM. Ela é carregada pelo arquivo legítimo googleupdate.exe (nome original do arquivo: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), também entregue pelo bootkit. A DLL descriptografa o conteúdo do arquivo v8_context_snapshot.bin, que fica na mesma pasta, e depois salta para o início do conteúdo descriptografado. Os dados descriptografados começam com um shellcode, seguido de um arquivo PE, que é um payload em Rust projetado para se comunicar com o servidor C2 www[.]archivetj[.]com. Durante a comunicação, esse payload foi projetado para receber arquivos DLL que exportam uma função chamada create_plugin. Essas DLLs são então executadas em threads separadas.

Atribuição

Com base nos fatos a seguir, atribuímos esse ataque ao threat actor APT41, com grau médio de confiança:

• Em junho de 2026, a ESET publicou um post no blog sobre ataques do threat actor FishMonger, que a comunidade supõe estar relacionado ao APT41. Esse post descreve um implante de kernel com um caminho PDB que começa com C:\Users\xdd\Desktop. Ao descrever a campanha, a ESET também sugere o possível uso de um componente de bootkit UEFI não identificado, que pode explorar a CVE‑2023‑24932. Observamos que o identificador “xdd” é usado várias vezes nos payloads do bootkit BlackX. Por isso, avaliamos que o BlackX é o bootkit UEFI citado no post de blog da ESET;
• Os payloads implantados pelo BlackX são carregados com o auxílio de um arquivo criptografado e de um executável legítimo, explorado por meio de DLL sideloading. Esse padrão é comumente usado por threat actors de língua chinesa;
• O arquivo OxiDLLRunner foi ofuscado com OLLVM, um ofuscador frequentemente usado por threat actors de língua chinesa.

Por que as organizações foram infectadas?

Ao realizar a análise inicial do BlackX, pensamos que os invasores tinham conseguido implantá-lo por negligência das organizações infectadas. O Baton Drop, a vulnerabilidade usada no ataque, foi divulgado em 2023 e corrigido, então a princípio concluímos que as máquinas infectadas não tinham as atualizações necessárias instaladas. No entanto, nossa investigação mostrou que estávamos enganados. As máquinas infectadas estavam totalmente atualizadas.

Na verdade, descobrimos que o problema estava no próprio patch. O patch da vulnerabilidade Baton Drop foi projetado para revogar o certificado “Windows Production PCA 2011”, usado para assinar componentes UEFI vulneráveis. No entanto, essa revogação não ocorre automaticamente após a instalação. O usuário precisa acioná-la manualmente. Para isso, é preciso seguir as etapas abaixo:

• Definir uma flag de registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
• Criar uma tarefa agendada chamada Secure-Boot-Update.

Esse patch foi projetado propositalmente para ser aplicado manualmente. Aplicá-lo automaticamente poderia, por exemplo, inutilizar sistemas de inicialização dupla que dependem do certificado “Windows Production PCA 2011” para inicializar. Ao mesmo tempo, essa prática de implantação do patch cria um problema, pois é extremamente incomum que um administrador de sistemas execute ações adicionais necessárias após instalar uma atualização. Normalmente, ao aplicar patches, os administradores de sistemas não tomam nenhuma outra providência relacionada a eles, a menos que ocorra uma falha na instalação. As instruções para ativar o patch ficam bem escondidas no site da Microsoft, e avaliamos que dificilmente seriam notadas por um administrador de TI.

Curiosamente, o plano da Microsoft para a implantação dos patches relacionados ao Baton Drop menciona uma “Fase de Imposição” (Enforcement Phase), que envolve revogar o certificado “Windows Production PCA 2011” automaticamente, sem interação do usuário. Até a publicação deste artigo, esta etapa ainda não havia sido implementada. O certificado expirou em 19 de outubro de 2026; no entanto, isso não impede o carregamento dos binários vulneráveis, a menos que o certificado conste em uma lista de bloqueio.

É provável que o threat actor por trás dessa campanha tenha levado em conta que poucas organizações percebiam a importância de ativar manualmente o patch do Baton Drop. Por isso, acreditamos que ele decidiu investir tempo em entender como o BlackLotus funciona e em criar uma cópia desse bootkit.

Conclusão

O gerenciamento de patches é importante para toda organização, pois as atualizações dos fornecedores ajudam a proteger software e hardware contra vulnerabilidades conhecidas. No entanto, às vezes os patches, depois de instalados, não protegem contra as falhas que deveriam corrigir. A história do BlackLotus que descrevemos não é um caso isolado. Em 2025, por exemplo, a Microsoft lançou uma atualização contra a vulnerabilidade ToolShell que também precisava ser aplicada manualmente.

Por outro lado, as soluções de segurança modernas são projetadas para levar em conta os casos em que os patches instalados não protegem contra falhas de segurança, por um motivo ou outro. Por exemplo, o componente Prevenção de exploits, disponível nos produtos da Kaspersky impedem a execução de exploits se o patch não tiver sido aplicado ou quando se trata de uma vulnerabilidade zero day, para a qual ainda não existe patch. Por isso, é fundamental equipar todas as máquinas de uma organização com soluções de segurança e monitorar constantemente os alertas que elas geram.