- Bootkitty é o primeiro bootkit UEFI PoC para Linux com suporte limitado e conexões com UEFI/GRUB.
- O BlackLotus explorou o CVE-2022-21894 para ignorar o Secure Boot e desabilitar as defesas no Windows.
- IoCs, MITRE ATT&CK e detecções Sigma ajudam a monitorar adulterações de inicialização e kernel.
Os bootkits UEFI tornaram -se um dos vetores mais preocupantes no cenário de ameaças moderno: eles são executados antes do sistema operacional, podem desativar defesas e alcançar persistência com privilégios elevados. Nos últimos anos, passamos de meras provas de conceito para casos reais e ativos, como o BlackLotus no Windows, e agora surgiu o primeiro projeto voltado para Linux, chamado Bootkitty, inaugurando uma nova era para o ecossistema de software livre.
Este artigo compila e organiza informações essenciais de diversas fontes confiáveis para explicar como os bootkits UEFI funcionam , o que diferencia o Bootkitty no Linux, por que o BlackLotus revolucionou o Windows, quais indicadores de comprometimento devem ser observados e quais medidas defensivas implementar. Também aborda casos relevantes como LoJax, ESPecter, MoonBounce e MosaicRegressor, além de regras de detecção relacionadas e táticas do MITRE ATT&CK.
O que é um bootkit UEFI e por que ele representa um risco sério?
Um bootkit UEFI é um código malicioso que é executado durante os estágios iniciais da inicialização, quando o firmware inicializa o dispositivo e antes que o sistema operacional assuma o controle. Ao operar em um nível tão baixo, ele pode desativar mecanismos como verificação de assinatura ou o carregamento de drivers legítimos, implantar payloads no modo kernel ou de usuário e permanecer oculto da maioria das contramedidas tradicionais.
É importante distinguir entre diferentes níveis de software malicioso de inicialização: implantes de firmware (por exemplo, LoJax em 2018) modificam diretamente a memória flash SPI, enquanto os bootkits geralmente residem na partição do sistema EFI (ESP), que é mais acessível, mas possui capacidades semelhantes para assumir o controle inicial do processo de inicialização.
A recente evolução das vulnerabilidades na UEFI e a falta de revogações oportunas de binários defeituosos no banco de dados de revogação (dbx) tornaram mais fácil para agentes maliciosos abusarem de componentes assinados, porém vulneráveis, para burlar a Inicialização Segura , como aconteceu com a exploração da CVE-2022-21894 (Baton Drop) no caso da BlackLotus.
Contexto histórico: de PoCs no Windows a casos na natureza
A primeira grande demonstração pública de um bootkit UEFI moderno data de 2012, quando Andrea Allievi documentou uma prova de conceito (PoC) capaz de operar em ambientes Windows com UEFI. Isso foi seguido por outros testes — EfiGuard, Boot Backdoor, UEFI-bootkit — que demonstraram a viabilidade técnica da abordagem.
Após essa fase experimental inicial, foram necessários anos para que ameaças ativas surgissem em sistemas reais. Em 2021, foram lançados o ESPecter (investigado pela ESET) e o bootkit FinSpy (analisado pela Kaspersky), e em 2023, surgiu o BlackLotus, o primeiro bootkit conhecido a burlar a Inicialização Segura UEFI em sistemas Windows 11 totalmente atualizados .
Até recentemente, todos esses casos compartilhavam uma característica comum: eram focados exclusivamente no Windows . Esse paradigma foi quebrado com a descoberta do Bootkitty, que é centrado no Ubuntu e, portanto, no mundo Linux.
Bootkitty: primeiro bootkit UEFI focado no Linux
Em novembro de 2024, um aplicativo UEFI desconhecido ( bootkit.efi ) apareceu no VirusTotal. A análise revelou que se tratava do Bootkitty, o primeiro bootkit UEFI projetado para Linux , especificamente para certas versões do Ubuntu. De acordo com a telemetria disponível, não há evidências de implantação em larga escala; tudo indica que se tratava de uma prova de conceito inicial , com múltiplos artefatos de desenvolvimento.
Atualização importante: No início de dezembro de 2024, foi confirmado que este era um projeto acadêmico desenvolvido por participantes do programa coreano Best of the Best (BoB). Seu objetivo declarado era aumentar a conscientização sobre os riscos e incentivar medidas proativas. Isso está de acordo com as observações dos analistas: um kit de inicialização funcional com suporte limitado e indícios de uma prova de conceito, não uma arma finalizada para campanhas em massa.
Compatibilidade, assinatura e sinais de PoC
O Bootkitty vem com um certificado autoassinado , portanto, não pode ser executado se a Inicialização Segura estiver ativada, a menos que os certificados do atacante sejam adicionados manualmente. Mesmo assim, sua lógica tenta permitir que o processo de inicialização do kernel continue normalmente , corrigindo funções de verificação na memória antes que o GRUB ceda o controle.
Sua compatibilidade é limitada. Para localizar funções a serem modificadas, ele usa padrões de bytes codificados que não abrangem várias versões do kernel ou do GRUB, tornando-o operacional apenas em configurações específicas e propenso a causar falhas se o deslocamento não corresponder à versão atual.
Entre os artefatos de prova de conceito, encontram-se duas rotinas que imprimem arte ASCII com o nome Bootkitty e uma lista de possíveis autores; além disso, na inicialização, exibe strings e referências específicas, como "BlackCat", sem relação com o grupo de ransomware ALPHV/BlackCat. O binário também sobrescreve a string e o banner da versão do Linux com o texto "BoB13".
Cadeia de execução e ganchos em UEFI e GRUB
Ao iniciar, o Bootkitty verifica o status do SecureBoot lendo a variável UEFI correspondente. Em seguida, instala hooks nos protocolos de autenticação UEFI — EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication e EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState — para forçar EFI_SUCCESS como resultado, anulando a avaliação real da integridade da imagem UEFI PE.
Em seguida, carrega um GRUB legítimo da partição ESP, localizado no caminho fixo /EFI/ubuntu/grubx64-real.efi (presumivelmente uma cópia inserida pelo atacante). Com o GRUB na memória, mas ainda não executado, o bootkit modifica e intercepta diversos pontos críticos, incluindo:
- peimage::start_image (embutido no GRUB), para interceptar o momento em que o stub EFI do kernel (vmlinuz.efi) é carregado na memória. A partir daí, o Bootkitty localiza e corrige a rotina responsável pela descompressão do kernel, provavelmente zstd_decompress_dctx dependendo da construção.
- inicialização do verificador de bloqueio de calço, parte do shim_lock no GRUB, embora o gancho aplicado seja irrelevante porque outro gancho impede que ele seja executado, e a modificação também introduz o sinalizador GRUB_VERIFY_FLAGS_SINGLE_CHUNK, que em teoria endurece verificação.
- grub_verifiers_open, que é alterado para retornar imediatamente sem invocar verificações de assinatura, neutralizando assim o fluxo normal de verificação no GRUB.
Gancho de descompressão do kernel e patches de memória
O gancho sobre a descompressão do kernel restaura temporariamente os bytes originais, permite que a função autêntica descompacte a imagem e, em seguida, aplica patches à memória do kernel agora expandido. Essa fase é crucial para desativar controles e preparar o carregamento de módulos ou binários adicionais.
Especificamente, a lógica observada reescreve a string de versão com “BoB13” , modifica a função module_sig_check para retornar 0 (portanto, o kernel aceita módulos não assinados mesmo com o Secure Boot ativado, com CONFIG_MODULE_SIG_FORCE ou com module.sig_enforce=1) e substitui a primeira variável de ambiente do processo init por “LD_PRELOAD=/opt/injector.so /init”.
A ideia por trás do LD_PRELOAD é forçar o carregamento prioritário de um arquivo ELF compartilhado para sobrescrever funções ou inserir lógica extra, uma técnica comum em ataques no espaço do usuário. A presença de “/init” no valor de LD_PRELOAD é notável; seu significado exato não é totalmente claro e reforça a interpretação de que se trata de um estágio inicial de desenvolvimento.
Durante os testes de laboratório, o sistema apresentou o kernel como corrompido após a inicialização com o Bootkitty; além disso, as strings modificadas e os rastros da variável LD_PRELOAD eram visíveis no dmesg, que também podiam ser vistos em /proc/1/environ . Em sistemas com o Secure Boot ativado, uma indicação empírica é que o kernel aceita o carregamento de um módulo não assinado em tempo de execução, o que não deveria acontecer sem a aplicação de patches prévios.
BCDropper e BCObserver: partes auxiliares associadas
Em paralelo, um módulo de kernel não assinado, apelidado de BCDropper , foi descoberto e enviado ao VirusTotal pelo mesmo remetente do bootkit. Ele contém referências a "BlackCat" em strings e caminhos de depuração, além de funcionalidade de ocultação de arquivos (filtrando nomes com prefixos como " injector ", em conformidade com LD_PRELOAD apontando para /opt/injector.so).
O BCDropper extrai um arquivo ELF embutido chamado BCObserver de /opt/observer e o executa usando /bin/bash. Ele também remove seus próprios rastros da lista de módulos carregados e fornece funções típicas de rootkit (ocultação de arquivos, processos e portas), embora o dropper não explore diretamente todas elas.
O BCObserver, por sua vez, aguarda o gerenciador de exibição gdm3 iniciar e, em seguida, tenta carregar /opt/rootkit_loader.ko usando a chamada de sistema finit_module , garantindo que o módulo seja injetado quando o sistema já tiver concluído a inicialização gráfica.
Não há certeza absoluta de que esses componentes sejam do mesmo autor do Bootkitty, mas a alteração do module_sig_check sugere que o objetivo era permitir o carregamento de módulos não assinados, o que está de acordo com o que o BCDropper/BCObserver faz.
IoCs e técnicas relevantes do MITRE ATT&CK
Os seguintes indicadores de engajamento e classificações podem auxiliar na busca por sinais iniciais em ambientes Linux onde a prova de conceito (PoC) pode ter sido testada:
| SHA-1 | Nome | Detecção | Descrição |
| 35ADF3AED60440DA7B80F3C452047079E54364C1 | bootkit.efi | EFI/Agente.A | Bootkitty Kit de inicialização UEFI. |
| BDDF2A7B3152942D3A829E63C03C7427F038B86D | conta-gotas.ko | Linux/Rootkit.Agent.FM | BCDropper. |
| E8AF4ED17F293665136E17612D856FA62F96702D | observador | Linux/Rootkit.Agent.FM | Observador BC. |
O mapeamento MITRE ATT&CK mais relevante para este conjunto de componentes e comportamentos observados, útil para um modelo básico de ameaças:
| Tática | ID | Nome | Descrição |
| Desenvolvimento de Recursos | T1587.001 | Desenvolver recursos: malware | Bootkitty é um Kit de inicialização UEFI novo. |
| T1587.002 | Desenvolver capacidades: Certificados de assinatura de código | Amostra assinada com certificado autoassinado. | |
| Execução | T1106 | API nativa | O BCObserver usa módulo_finit para carregar um LKM. |
| T1129 | Módulos compartilhados | Força Bootkitty LD_PRELOAD na inicialização. | |
| Persistência | T1574.006 | Fluxo de execução de sequestro: sequestro de vinculador dinâmico | Patching de ambiente o init com LD_PRELOAD. |
| T1542.003 | Inicialização pré-SO: Bootkit | Implantação no ESP. | |
| Evasão de Defesa | T1014 | Rootkit | BCDropper como LKM para ocultação. |
| T1562 | Prejudicar Defesas | Desabilitar verificação de empresas no GRUB e no kernel. | |
| T1564 | Ocultar artefatos | Oculte seu módulo da lista módulos do núcleo. |
Rastros em sistemas Linux e sugestões de mitigação
Em instalações do Ubuntu afetadas, foram observadas evidências forenses, como a string da versão do kernel alterada para BoB13 (visível com `uname -v`), modificações no banner de inicialização (`dmesg`) e a presença de `LD_PRELOAD` em `/proc/1/environ` . O kernel pode ser marcado como contaminado, um comportamento que não ocorre sem o bootkit.
Uma solução rápida quando o bootkit substitui o GRUB é restaurar o arquivo legítimo de /EFI/ubuntu/grubx64-real.efi para sua localização original em /EFI/ubuntu/grubx64.efi, para que o bootkit inicialize o GRUB correto. Lembre-se de que isso se aplica apenas ao cenário específico em que a implantação foi exatamente como descrita.
BlackLotus: o caso paradigmático no Windows
A BlackLotus ficou conhecida por sua capacidade de executar seu kit de inicialização UEFI mesmo em sistemas Windows 11 totalmente atualizados com a Inicialização Segura ativada. Estava disponível por US$ 5.000 (US$ 200 por atualização) a partir de outubro de 2022, com geolocalização para impedir o acesso a sistemas na Armênia, Bielorrússia, Cazaquistão, Moldávia, Romênia, Rússia e Ucrânia.
O instalador explorou a vulnerabilidade CVE-2022-21894 (Baton Drop) , corrigida pela Microsoft em janeiro de 2022, mas ainda explorável posteriormente, pois binários vulneráveis e assinados ainda não haviam sido adicionados à lista de revogação UEFI (dbx). O instalador introduz cópias assinadas validamente de bootloaders vulneráveis para obter persistência e burlar a Inicialização Segura.
Entre suas capacidades, ele podia desativar o BitLocker, a integridade da memória (HVCI) e o Microsoft Defender; implantar um driver de kernel que protegia os arquivos do bootkit na partição E/S; e executar um downloader HTTP em modo de usuário dentro do winlogon.exe , empregando técnicas anti-máquina virtual, anti-depuração e ofuscação. O tamanho do bootkit era pequeno (cerca de 80 KB), o que contribuiu para sua furtividade.
Códigos internos e artefatos curiosos foram documentados, como referências à série Higurashi em nomes de componentes e no certificado autoassinado, bem como mensagens ofuscadas não utilizadas. Esses detalhes não diminuem o perigo, mas fornecem contexto sobre seu desenvolvimento.
Como o Windows protege a inicialização: inicialização segura, inicialização confiável, ELAM e inicialização medida
No Windows, a cadeia de confiança de inicialização depende de várias camadas. A Inicialização Segura valida as assinaturas do firmware e do carregador de inicialização; a Inicialização Confiável verifica a integridade do kernel e dos componentes de inicialização; o ELAM prioriza o carregamento de um driver antimalware em relação a outros drivers de inicialização que não sejam da Microsoft; e a Inicialização Medida registra hashes no TPM para atestação remota.
Por padrão, os dispositivos certificados têm a Inicialização Segura ativada e confiam no certificado da Microsoft e em outros carregadores de inicialização aprovados. No entanto, manter a Autoridade Certificadora UEFI de terceiros da Microsoft ativada expande a superfície de ataque, permitindo a confiança em carregadores de inicialização de várias distribuições, incluindo aquelas com vulnerabilidades conhecidas. Muitos dispositivos com kernel protegido exigem a desativação da confiança nessa Autoridade Certificadora de terceiros para reforçar a segurança padrão .
Para permitir o uso do Linux em ambientes protegidos, a abordagem recomendada é adicionar explicitamente a assinatura do bootloader desejado ao banco de dados UEFI ou, como último recurso, desativar a Inicialização Segura — uma medida que reduz significativamente a proteção contra bootkits . Em ambos os casos, essas alterações exigem modificação manual do firmware e não podem ser automatizadas por software malicioso.
A verificação de inicialização medida permite que um servidor confiável avalie se um endpoint mantém uma cadeia de inicialização intacta. O TPM assina a evidência e, combinado com telemetria adicional, possibilita o isolamento de dispositivos comprometidos em redes de quarentena até a sua correção.
Regras proativas de detecção e vigilância
Além da instrumentação nativa do Windows, a comunidade publicou regras Sigma úteis para detectar atividades associadas a esses cenários. Isso inclui a criação de um arquivo de firmware em System32 por um processo que não é do sistema e a desativação da Integridade de Memória High-VCI usando chaves de registro (técnicas T1562 e T1112 do MITRE ATT&CK). Essas detecções são mapeadas para múltiplos sistemas SIEM/EDR/XDR.
Para Linux, é recomendável correlacionar eventos de inicialização (journald/dmesg), alterações nas variáveis de ambiente do PID 1 usando o comando `uname -vy` e verificar carregamentos de módulos não assinados ou operações ESP suspeitas . Integrar esses rastreamentos com regras de comportamento no EDR aumenta a probabilidade de detectar uma tentativa de persistência precoce.
Panorama geral: LoJax, ESPecter, MoonBounce, MosaicRegressor e novos sinais
O primeiro implante de firmware UEFI observado em ambiente real foi o LoJax (2018), seguido por campanhas com MosaicRegressor e MoonBounce, este último notável por elevar o nível de sofisticação dos rootkits UEFI . Em 2021, o ESPecter e o bootkit FinSpy demonstraram que o estágio pré-SO continuava sendo um alvo atraente para agentes avançados.
No contexto do Linux, o Bootkitty foi o primeiro teste funcional desse tipo, embora com escopo limitado. E já em 2025, surgiram referências ao " HybridPetya " como uma evolução da família Petya com recursos de bootkit UEFI, com amostras enviadas ao VirusTotal a partir da Polônia . Embora a análise ainda seja preliminar, serve como um lembrete de que essa categoria de ameaças continua a se expandir.
Recomendações práticas para reduzir riscos
Em ambientes Linux, manter a Inicialização Segura (Secure Boot) ativada, aplicar atualizações de firmware (UEFI) e kernel e garantir que a lista de revogação (dbx) esteja atualizada são pilares indispensáveis. Monitore se `module.sig_enforce` está definido como 1 ou se `CONFIG_MODULE_SIG_FORCE` está ativado quando apropriado e evite carregar módulos de fontes não confiáveis.
Audite regularmente a partição ESP em busca de alterações não autorizadas em caminhos como /EFI/ubuntu/grubx64.efi e verifique se não existem "cópias" suspeitas (grubx64-real.efi). Qualquer alteração no fluxo de verificação do GRUB deve ser investigada.
No Windows, além da Inicialização Segura, ele fortalece a Inicialização Confiável, habilita o HVCI quando suportado pelo hardware e adota a atestação remota baseada em TPM com políticas de acesso condicional . Ele minimiza a dependência de ACs de terceiros, se não for estritamente necessário, e acelera a adoção de revogações quando estas reportam falhas em componentes de inicialização.
Algumas soluções comerciais integram scanners UEFI capazes de analisar o firmware em busca de componentes maliciosos . A ESET afirma ser a única entre os 20 maiores fornecedores de soluções para endpoints em termos de receita a oferecer essa funcionalidade integrada aos seus clientes, uma abordagem que pode agregar valor à defesa de hardware em profundidade .
A trajetória das campanhas recentes deixa claro que o link de inicialização continua sendo um alvo principal. Com telemetria adequada , reforço da segurança do firmware/bootloader e verificações sistemáticas de integridade, é possível aumentar significativamente a dificuldade e tornar a vida muito mais difícil para os adversários.
O estado da arte dos bootkits UEFI confirma que a fronteira entre a Prova de Conceito (PoC) e a operação no mundo real está sendo cruzada cada vez mais rapidamente: o Bootkitty mostra que o Linux já está na mira, o BlackLotus solidificou sua viabilidade no Windows e o ecossistema de defesa deve priorizar a higiene de inicialização, atualizações do dbx, monitoramento de IoC e atestação remota para impedir qualquer tentativa de persistência pré-SO.