HybridPetya: imitador do ransomware Petya/NotPetya capaz de desativar o UEFI Secure Boot

A equipe de pesquisa da ESET descobriu o HybridPetya na plataforma de compartilhamento de amostras VirusTotal. Trata-se de um imitador do Petya/NotPetya, que acrescenta a capacidade de comprometer sistemas baseados em UEFI e explorar a vulnerabilidade CVE-2024-7344 para contornar o Secure Boot do UEFI em sistemas desatualizados.

Pontos-chave deste post:

• Novas amostras de ransomware, que denominamos HybridPetya e que se assemelham ao malware Petya/NotPetya, foram carregadas no VirusTotal em fevereiro de 2025.
• O HybridPetya cifra a tabela mestra de arquivos (MFT), que contém metadados importantes sobre todos os arquivos das partições formatadas em NTFS.
• Diferentemente do Petya/NotPetya original, o HybridPetya pode comprometer sistemas modernos baseados em UEFI, instalando um aplicativo EFI malicioso na partição do sistema EFI.
• Uma das variantes analisadas do HybridPetya explora a vulnerabilidade CVE-2024-7344 para contornar o UEFI Secure Boot em sistemas desatualizados, utilizando um arquivo cloak.dat especialmente criado para isso.
• A telemetria da ESET ainda não mostra indícios de que o HybridPetya esteja sendo usado em ataques in the wild; além disso, esse malware não apresenta a propagação agressiva em rede observada no NotPetya original.

Resumo

No final de julho de 2025, identificamos amostras suspeitas de ransomware enviadas ao VirusTotal a partir da Polônia, sob diversos nomes de arquivo, incluindo notpetyanew.exe e outros semelhantes, o que sugere uma conexão com o malware destrutivo que afetou a Ucrânia e muitos outros países em 2017. O ataque NotPetya é considerado o ciberataque mais destrutivo da história, com prejuízos estimados em mais de US$10 bilhões (cerca de R$53,5 bilhões). Apesar da semelhança do NotPetya com o ransomware Petya, descoberto pela primeira vez em março de 2016, o objetivo do NotPetya era puramente destrutivo, já que não era possível recuperar a chave de criptografia a partir da chave de instalação pessoal da vítima. Devido às características compartilhadas das amostras recentemente descobertas tanto com o Petya quanto com o NotPetya, denominamos essa nova descoberta de HybridPetya.

Embora a telemetria da ESET não indique nenhum uso ativo do HybridPetya in the wild, um detalhe importante nessas amostras chamou nossa atenção: ao contrário do NotPetya original (e também do ransomware Petya), o HybridPetya também é capaz de comprometer sistemas modernos baseados em UEFI, instalando um aplicativo EFI malicioso na partição do sistema EFI. A aplicação UEFI implantada é então responsável pela criptografia do arquivo Master File Table (MFT) relacionado ao NTFS, um arquivo crucial de metadados que contém informações sobre todos os arquivos da partição formatada em NTFS.

Após investigação mais aprofundada, descobrimos algo ainda mais interessante no VirusTotal: um arquivo que contém todo o conteúdo da partição do sistema EFI, incluindo uma aplicação UEFI do HybridPetya muito semelhante (desta vez incluída em um arquivo cloak.dat especialmente formatado e vulnerável à CVE-2024-7344, a falha de bypass do UEFI Secure Boot revelada por nossa equipe no início de 2025).

Curiosamente, embora os nomes dos arquivos no VirusTotal e o formato da nota de resgate nas amostras atuais sugiram que poderiam estar relacionados ao NotPetya, o algoritmo utilizado para a geração da chave de instalação pessoal da vítima, diferentemente do NotPetya original, permite que o operador do malware reconstrua a chave de descriptografia a partir das chaves de instalação pessoais da vítima. Assim, o HybridPetya pode atuar como um ransomware "normal" (mais próximo do Petya), em vez de ser apenas destrutivo como o NotPetya.

Além disso, em 9 de setembro de 2025, @hasherezade publicou sobre a existência de um PoC UEFI do Petya, com um vídeo que demonstrava a execução do malware mesmo com o Secure Boot do UEFI ativado. Embora a amostra exibida no vídeo seja obviamente diferente da apresentada neste post (mostrando a típica caveira em arte ASCII do Petya, ausente nas amostras que descobrimos), suspeitamos que possa haver alguma relação entre os dois casos, e que o HybridPetya também possa ser apenas uma prova de conceito desenvolvida por um pesquisador de segurança ou por um cibercriminoso desconhecido.

Nesta publicação, vamos nos focar na análise técnica do HybridPetya.

Análise técnica do HybridPetya

Apresentamos uma análise técnica dos componentes do HybridPetya: o bootkit e seu instalador. Também examinamos separadamente uma versão do HybridPetya capaz de contornar o UEFI Secure Boot explorando a CVE-2024-7344. É importante notar que o HybridPetya é compatível tanto com sistemas legados quanto com sistemas baseados em UEFI; nesta publicação, focaremos na parte UEFI.

Interessantemente, o código responsável por gerar as chaves de instalação pessoais das vítimas parece ter sido inspirado no PoC RedPetyaOpenSSL. Conhecemos pelo menos outro PoC do NotPetya compatível com UEFI, chamado NotPetyaAgain, escrito em Rust; entretanto, esse código não tem relação com o HybridPetya.

Kit de boot UEFI

Identificamos duas versões do componente UEFI bootkit, ambas muito semelhantes, mas com algumas diferenças. Quando executado, o bootkit primeiro carrega sua configuração a partir do arquivo \EFI\Microsoft\Boot\config e verifica a flag de criptografia, que indica o estado atual da criptografia, assim como nas amostras originais do Petya/NotPetya, a flag de criptografia pode ter um dos seguintes valores:

• 0 – pronto para criptografar;
• 1 – já criptografado;
• 2 – resgate pago, disco descriptografado.

A execução continua com base na flag de estado da criptografia, conforme ilustrado na Figura 1.

Criptografia do disco

Se o valor do indicador de criptografia for 0, o bootkit extrai a chave de criptografia Salsa20 de 32 bytes e o nonce de 8 bytes a partir dos dados de configuração, e em seguida reescreve o arquivo de configuração, agora com a chave de criptografia zerada e o indicador de criptografia definido como 1. O bootkit continua com a criptografia do arquivo \EFI\MicrosoftBoot\verify usando o algoritmo Salsa20 com a chave e o nonce da configuração.

Antes de prosseguir com sua funcionalidade principal, a criptografia do disco, ele cria o arquivo \EFI\Microsoft\Boot\counter na partição do sistema EFI. A finalidade desse arquivo será explicada posteriormente. O processo de criptografia do disco começa com a identificação de todas as partições formatadas em NTFS. Como mostrado na Figura 2, a amostra faz isso obtendo a lista de handles dos dispositivos de armazenamento conectados, identificando as partições individuais verificando se EFI_BLOCK_IO_MEDIA->LogicalPartition é TRUE e conferindo se a partição está formatada em NTFS comparando os quatro primeiros bytes do setor inicial da partição com a assinatura NTFS.

Uma vez identificadas as partições NTFS, o bootkit continua com a criptografia do arquivo Master File Table (MFT), o arquivo de metadados essencial que contém informações sobre os demais arquivos e a localização de seus dados na partição NTFS. Como mostrado na Figura 3, durante a criptografia, o bootkit reescreve o conteúdo do arquivo \EFI\Microsoft\Boot\counter com o número de clusters de disco já criptografados e atualiza a falsa mensagem do CHKDSK que aparece na tela da vítima, mostrada na Figura 4, com informações sobre o estado atual da criptografia. Embora a mensagem sugira que o sistema está verificando erros no disco, na realidade o disco está sendo criptografado.

Depois de finalizar a criptografia, o bootkit reinicia a máquina.

Descriptografia do disco

Se o bootkit detectar que o disco já está criptografado, ou seja, que o valor do indicador de criptografia no arquivo de configuração é 1, ele exibe a nota de resgate mostrada na Figura 5 ou na Figura 6, dependendo da versão do bootkit, e solicita à vítima que insira a chave de descriptografia. Vale observar que, embora a nota de resgate do HybridPetya tenha o mesmo formato da do NotPetya original, mostrada na Figura 7, o valor do resgate, o endereço de Bitcoin e o endereço de e-mail do operador são diferentes. Além disso, a versão que contorna o UEFI Secure Boot utiliza um endereço de e-mail de contato diferente (wowsmith999999@proton[.]me) em relação à versão distribuída pelos instaladores obtidos (wowsmith1234567@proton[.]me). É importante mencionar que o endereço de Bitcoin é o mesmo em ambas as versões.

Quando uma chave com o comprimento correto (32 caracteres) é inserida e a vítima confirma pressionando Enter, o bootkit procede à verificação da chave. Como mostrado na Figura 8, a validade da chave é determinada tentando descriptografar o arquivo \EFI\Microsoft\Boot\verify com a chave fornecida e verificando se o texto plano contém apenas bytes com valor 0x07. É importante notar que a variante do bootkit distribuída por meio do bypass do UEFI Secure Boot realiza o hash da chave fornecida com um algoritmo provavelmente baseado em SPONGENT-256/256/16, utilizando esse valor hash como chave de descriptografia. Já o bootkit distribuído pelos instaladores obtidos utiliza a entrada do usuário diretamente.

Se a chave correta for inserida, o bootkit atualiza o arquivo de configuração com o valor 2 no indicador de criptografia e também preenche a chave de descriptografia. Em seguida, ele lê o conteúdo do arquivo \EFI\Microsoft\Boot\counter, que contém o número de clusters do disco previamente criptografados, e prossegue com a descriptografia do disco.

Para a descriptografia, o bootkit realiza um processo muito semelhante ao da identificação das partições NTFS e descriptografia do MFT. O processo de criptografia e descriptografia com Salsa20 é o mesmo, conforme descrito na seção de Criptografia do disco. A descriptografia é interrompida quando o número de clusters descriptografados é igual ao valor registrado no arquivo contador.

Durante a descriptografia do MFT, o bootkit exibe o status atual do processo na tela da vítima, conforme mostrado na Figura 9.

Em seguida, o bootkit procede à restauração dos bootloaders legítimos \EFI\Microsoft\Boot\bootmgfw.efi e \EFI\Boot\bootx64.efi a partir do arquivo de backup criado previamente durante o processo de instalação: \EFI\Microsoft\Boot\bootmgfw.efi.old.

Finalmente, uma vez concluído o processo de descriptografia e restaurados os bootloaders legítimos, o bootkit solicita à vítima que reinicie o dispositivo, conforme mostrado na Figura 10. Se tudo ocorrer corretamente, o dispositivo deverá inicializar o sistema operacional com sucesso após a reinicialização.

Implantação do componente UEFI bootkit

Nesta seção, focamos na funcionalidade de instalação do bootkit pelos instaladores do HybridPetya descobertos. Vale ressaltar que os instaladores que conseguimos obter não consideram o UEFI Secure Boot. No entanto, como explicado na seção sobre exploração da vulnerabilidade CVE-2024-7344, é provável que exista uma variante com essa melhoria.

Para determinar se o sistema é baseado em UEFI, o instalador recupera as informações do disco (IOCTL_DISK_GET_DRIVE_LAYOUT_EX), verifica se o esquema de particionamento utilizado é GPT (PARTITION_STYLE_GPT) e percorre as partições até localizar aquela em que PARTITION_INFORMATION_GPT.PartitionType está definido como PARTITION_SYSTEM_GUID, que é o identificador da partição do sistema EFI. Depois de localizar a partição do sistema EFI, o instalador prossegue com a instalação.

• Remover o bootloader UEFI de reserva, armazenado em \EFI\Boot\Bootx64.efi.
• Gravar uma configuração relacionada à criptografia do disco, juntamente com a flag de criptografia, no arquivo \EFI\Microsoft\Boot\config na partição do sistema EFI. A configuração de criptografia contém a chave de criptografia Salsa20, um nonce de 8 bytes e a chave de instalação pessoal da vítima, todos codificados em Base58.
• Inserir uma matriz de verificação de criptografia de 0x200 bytes com valor 0x07 no arquivo \EFI\Microsoft\Boot\verify da partição do sistema EFI. Essa matriz é posteriormente criptografada pelo bootkit usando a mesma chave Salsa20 utilizada para a criptografia do disco. O objetivo dessa matriz é verificar se a vítima inseriu uma chave de descriptografia válida, descriptografando a matriz com a chave fornecida e conferindo se o texto plano contém um array de bytes com valor 0x07.
• Criar um backup de \EFI\Microsoft\Boot\bootmgfw.efi, o bootloader padrão dos sistemas Windows, copiando-o para \EFI\Microsoft\Boot\bootmgfw.efi.old.

Depois disso, ele provoca um travamento do sistema (Blue Screen Of Death, BSOD) utilizando o mesmo método do Petya, invocando a API NtRaiseHardError com o parâmetro ErrorStatus definido como 0xC0000350 (STATUS_HOST_DOWN) e ResponseOption definido como 6 (OptionShutdownSystem), resultando no desligamento do sistema.

As alterações mencionadas garantem que, em sistemas Windows configurados como sistema operacional principal, o binário do bootkit será executado assim que o dispositivo for ligado novamente.

Exploração da CVE-2024-7344

Nesta seção, analisamos um arquivo que descobrimos no VirusTotal e que contém uma variante do bootkit UEFI descrito na seção de bootkit UEFI, mas desta vez incluído em um arquivo cloak.dat especialmente formatado, relacionado à CVE-2024-7344, a vulnerabilidade de bypass do UEFI Secure Boot que nossa equipe revelou publicamente no início de 2025.

Uma lista dos arquivos presentes no arquivo, juntamente com seu conteúdo, sugere que essa partição do sistema EFI foi copiada de um sistema já criptografado por essa variante imitadora do Petya/NotPetya. Vale observar que não obtivemos o instalador responsável por distribuir essa versão com o bypass do UEFI Secure Boot, mas com base no conteúdo do arquivo, mostrado na Figura 11, o processo seria bastante semelhante ao descrito na seção anterior. Especificamente, o arquivo contém:

• \EFI\Microsoft\Boot\counter, um arquivo que já contém um valor diferente de zero, representando o número de clusters do disco previamente criptografados pelo bootkit.
• \EFI\Microsoft\Boot\config, um arquivo com o valor da flag de criptografia definido como 1, indicando que o disco já deve estar criptografado e que o bootkit deve prosseguir exibindo a nota de resgate.
• \EFI\Microsoft\Boot\bootmgfw.efi.old, um arquivo com os primeiros 0x400 bytes XORed com o valor 0x07.
• \EFI\Microsoft\Boot\bootmgfw.efi, uma aplicação UEFI legítima, porém vulnerável (CVE-2024-7344), assinada pela Microsoft (revogada no dbx da Microsoft desde janeiro de 2025). Nesta seção, nos referiremos a esse arquivo pelo nome original reloader.efi.
• \EFI\Microsoft\Boot\cloak.dat, um arquivo especialmente projetado, carregável através do reloader.efi, que contém o binário XORed do bootkit.

Como descrito em nosso relatório de janeiro de 2025, o mecanismo de exploração é bastante simples. O arquivo cloak.dat contém dados especialmente formatados que incluem uma aplicação UEFI. Quando o binário reloader.efi (implantado como bootmgfw.efi) é executado durante a inicialização, ele verifica a presença do arquivo cloak.dat na partição do sistema EFI e carrega a aplicação UEFI embutida a partir do arquivo de maneira muito insegura, ignorando completamente qualquer verificação de integridade e contornando assim o UEFI Secure Boot.

Vale observar que nosso post de janeiro de 2025 não detalhava a exploração; portanto, é provável que o autor do malware tenha reconstruído o formato correto do arquivo cloak.dat por conta própria, com base em engenharia reversa da aplicação vulnerável.

A vulnerabilidade não pode ser explorada em sistemas que tenham aplicado a atualização dbx de janeiro de 2025 da Microsoft. Para orientações sobre como proteger seu sistema e verificar se ele está exposto a essa vulnerabilidade, consulte a seção Proteção e Detecção em nossa publicação de janeiro de 2025.

Conclusão

O HybridPetya é agora pelo menos o quarto exemplo conhecido publicamente de um bootkit UEFI real ou de prova de conceito com funcionalidade de bypass do UEFI Secure Boot, juntando-se ao BlackLotus (que explora a CVE-2022-21894), BootKitty (que explora o LogoFail) e o PoC Hyper-V Backdoor (que explora a CVE-2020-26200). Isso demonstra que contornar o Secure Boot não é apenas possível, mas cada vez mais comum e interessante tanto para pesquisadores quanto para cibercriminosos.

Embora o HybridPetya não esteja se propagando ativamente, suas capacidades técnicas, especialmente a criptografia do MFT, a compatibilidade com sistemas UEFI e o bypass do Secure Boot, tornam-no relevante para o monitoramento de ameaças futuras.

Para qualquer dúvida sobre nossas pesquisas publicadas no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.

Indicadores de Comprometimento

Você pode encontrar uma lista completa de indicadores de comprometimento (IoCs) e amostras em nosso repositório no GitHub.

Arquivos

Técnicas ATT&CK do MITRE

Esta tabela foi criada utilizando a versão 17 do framework MITRE ATT&CK.