un imitador del ransomware Petya/NotPetya que anula UEFI Secure Boot

ESET Research ha descubierto HybridPetya en la plataforma de intercambio de muestras VirusTotal. Se trata de un imitador del infame malware Petya/NotPetya, que añade la capacidad de comprometer sistemas basados en UEFI y utilizar CVE-2024-7344 para eludir el arranque seguro de UEFI en sistemas obsoletos.

Puntos clave de este blogpost:

• Nuevas muestras de ransomware, que denominamos HybridPetya, parecidas al infame malware Petya/NotPetya, fueron subidas a VirusTotal en febrero de 2025.
• HybridPetya cifra la tabla maestra de archivos, que contiene metadatos importantes sobre todos los archivos de las particiones con formato NTFS.
• A diferencia del Petya/NotPetya original, HybridPetya puede comprometer sistemas modernos basados en UEFI instalando una aplicación EFI maliciosa en la partición del sistema EFI.
• Una de las variantes de HybridPetya analizadas explota CVE-2024-7344 para eludir el arranque seguro UEFI en sistemas obsoletos, aprovechando un archivo cloak.dat especialmente diseñado.
• La telemetría de ESET aún no muestra indicios de que HybridPetya se esté utilizando in the wild; este malware no muestra la agresiva propagación en red que se observa en el NotPetya original.

Resumen

A finales de julio de 2025, encontramos muestras sospechosas de ransomware, subidas a VirusTotal desde Polonia, bajo varios nombres de archivo, incluyendo notpetyanew.exe y otros similares, lo que sugiere una conexión con el infame malware destructivo que afectó a Ucrania y muchos otros países en 2017. Se cree que el ataque NotPetya es el ciberataque más destructivo de la historia, con más de 10.000 millones de dólares en daños totales. A pesar de la similitud de NotPetya con el ransomware Petya, descubierto por primera vez en marzo de 2016, el propósito de NotPetya era la pura destrucción, ya que la recuperación de la clave de cifrado a partir de la clave de instalación personal de la víctima no era posible. Debido a las características compartidas de las muestras descubiertas actualmente tanto con Petya como con NotPetya, hemos denominado al nuevo descubrimiento HybridPetya.

Aunque la telemetría de ESET no muestra ningún uso activo de HybridPetya in the wild, un detalle importante en estas muestras nos llamó la atención: a diferencia del NotPetya original (y también del ransomware Petya), HybridPetya también es capaz de comprometer sistemas modernos basados en UEFI instalando una aplicación EFI maliciosa en la partición del sistema EFI. La aplicación UEFI desplegada es entonces responsable del cifrado del archivo de tabla maestra de archivos (MFT) relacionado con NTFS, un importante archivo de metadatos que contiene información sobre todos los archivos de la partición formateada con NTFS.

Después de indagar un poco más, descubrimos algo aún más interesante en VirusTotal: un archivo que contiene todo el contenido de la partición del sistema EFI, incluyendo una aplicación UEFI HybridPetya muy similar, pero esta vez incluida en un archivo cloak.dat especialmente formateado, vulnerable a CVE-2024-7344 – la vulnerabilidad de elusión de arranque seguro UEFI – que nuestro equipo reveló a principios de 2025.

Curiosamente, a pesar de que los nombres de los archivos en VirusTotal y el formato de la nota de rescate en las muestras actuales sugieren que podrían estar relacionados con NotPetya, el algoritmo utilizado para la generación de la clave de instalación personal de la víctima, a diferencia del NotPetya original, permite al operador del malware reconstruir la clave de descifrado a partir de las claves de instalación personales de la víctima. Así, HybridPetya puede servir como ransomware normal (más parecido a Petya), en lugar de ser únicamente destructivo como NotPetya.

Curiosamente, el 9 de septiembre de 2025, @hasherezade publicó un post sobre la existencia de un PoC UEFI de Petya, con un vídeo que demostraba la ejecución del malware con el arranque seguro UEFI activado. Aunque la muestra del vídeo es obviamente diferente de la presentada en este blogpost (mostrando la típica calavera de arte ASCII de Petya, que no está presente en las muestras que descubrimos), sospechamos que podría haber alguna relación entre los dos casos, y que HybridPetya también podría ser sólo una prueba de concepto desarrollada por un investigador de seguridad o un actor de amenazas desconocido.

En esta entrada nos centraremos en el análisis técnico de HybridPetya.

Análisis técnico de HybridPetya

En esta sección, ofrecemos un análisis técnico de los componentes de HybridPetya: el bootkit y su instalador. También diseccionamos por separado una versión de HybridPetya que es capaz de eludir UEFI Secure Boot explotando CVE 2024 7344. Hay que tener en cuenta que HybridPetya es compatible tanto con sistemas heredados como con sistemas basados en UEFI; en esta entrada nos centraremos en la parte UEFI.

Curiosamente, el código responsable de generar las claves de instalación personales de las víctimas parece estar inspirado en el PoC RedPetyaOpenSSL. Conocemos al menos otro PoC de NotPetya compatible con UEFI, llamado NotPetyaAgain, que está escrito en Rust; sin embargo, ese código no está relacionado con HybridPetya.

Kit de arranque UEFI

Obtuvimos dos versiones distintas del componente UEFI bootkit, ambas muy similares pero con ciertas diferencias. Cuando se ejecuta, el bootkit primero carga su configuración desde el archivo \EFI\Microsoft\Boot\config, y comprueba la flag de cifrado que indica el estado de cifrado actual – igual que las muestras originales de Petya/NotPetya, la flag de cifrado puede tener uno de los siguientes valores:

• 0 – listo para el cifrado,
• 1 – ya cifrado, o
• 2 – rescate pagado, disco desencriptado.

Continúa con la ejecución basándose en la flag de estado de cifrado, como se muestra en la Figura 1.

Cifrado del disco

Si el valor del indicador de cifrado es 0, el bootkit extrae la clave de cifrado Salsa20 de 32 bytes y el nonce de 8 bytes de los datos de configuración, y posteriormente reescribe el archivo de configuración, ahora con la clave de cifrado a cero y el indicador de cifrado a 1. Continúa con el cifrado del archivo \EFI\MicrosoftBoot\verify con el algoritmo de cifrado Salsa20 utilizando la clave y el nonce de la configuración. Luego, antes de proceder a su funcionalidad principal – cifrado de disco – crea el archivo \EFI\Microsoft\Boot\counter en la partición del sistema EFI; el propósito de este archivo se explica más adelante.

El proceso de cifrado del disco comienza con la identificación de todas las particiones formateadas en NTFS. Como se muestra en la Figura 2, la muestra lo hace obteniendo la lista de handles de los dispositivos de almacenamiento conectados, identificando las particiones individuales comprobando que EFI_BLOCK_IO_MEDIA->LogicalPartition es TRUE, y finalmente verificando si la partición está formateada NTFS comparando los cuatro primeros bytes de los datos presentes en el sector de la primera partición con la firma NTFS NTFS.

Una vez identificadas las particiones NTFS, el bootkit continúa con el cifrado del archivo Master File Table (MFT), el archivo de metadatos esencial que contiene información sobre otros archivos y la ubicación de sus datos en la partición con formato NTFS. Como se muestra en la Figura 3, durante el cifrado, el bootkit reescribe el contenido del archivo \EFI\Microsoft\Boot\counter con el número de clústeres de disco ya cifrados, y actualiza el falso mensaje CHKDSK que aparece en la pantalla de la víctima (mostrado en la Figura 4), con la información sobre el estado actual del cifrado (aunque, basándose en el mensaje, la víctima puede creer que se está comprobando si hay errores en el disco, no que se está cifrando).

Una vez finalizado el cifrado, el bootkit reinicia la máquina.

Cifrado de disco

Si el bootkit detecta que el disco ya está cifrado, es decir, que el valor del indicador de cifrado del archivo de configuración es 1, muestra la nota de rescate mostrada en la Figura 5 o Figura 6 (dependiendo de la versión del bootkit), y pide a la víctima que introduzca la clave de descifrado. Obsérvese que, aunque la nota de rescate de HybridPetya tiene el mismo formato que la del NotPetya original (mostrada en la Figura 7), el importe del rescate, la dirección bitcoin y la dirección de correo electrónico del operador son diferentes. Además, la versión desplegada con el bypass UEFI Secure Boot utiliza una dirección de correo electrónico de contacto diferente(wowsmith999999@proton[.]me) que la versión desplegada por los instaladores obtenidos(wowsmith1234567@proton[.]me). Cabe mencionar que la dirección bitcoin es la misma en ambas versiones.

Cuando se introduce una clave con la longitud correcta (32 caracteres) y la víctima la confirma pulsando Intro, el bootkit procede a verificar la clave. Como se muestra en la Figura 8, la validez de la clave se establece intentando descifrar el archivo \EFI\Microsoft\Boot\verify antes mencionado con la clave suministrada, y comprobando si el texto plano contiene sólo bytes con valor 0x07. Nótese que la variante del bootkit desplegada a través del bypass UEFI Secure Boot realiza el hash de la clave suministrada con un algoritmo probablemente basado en SPONGENT-256/256/16, utilizando ese valor hash como clave de descifrado, mientras que el bootkit desplegado por los instaladores obtenidos toma la entrada del usuario tal cual.

Si se introduce la clave correcta, el bootkit actualiza el archivo de configuración con el valor 2 del indicador de cifrado y también rellena la clave de descifrado. A continuación, lee el contenido del archivo \EFI\Microsoft\Boot\counter (que contiene el número de clusters de disco previamente cifrados) y procede con el descifrado del disco. Para el descifrado, el bootkit procede con un proceso muy similar al del descubrimiento de particiones NTFS y descifrado MFT (el proceso de cifrado y descifrado de Salsa20 es el mismo) como se describe en la sección de Cifrado de disco. El descifrado se detiene cuando el número de clústeres descifrados es igual al valor del archivo contador. Durante el proceso de descifrado MFT, el bootkit muestra el estado actual del proceso de descifrado, representado en la Figura 9, en la pantalla de la víctima.

A continuación, el bootkit procede a recuperar los gestores de arranque legítimos \EFI\Microsoft\Boot\bootmgfw.efi y \EFI\Boot\bootx64.efi del archivo de copia de seguridad creado previamente durante el proceso de instalación: \EFI\Microsoft\Boot\bootmgfw.efi.old.

Finalmente, una vez finalizado el proceso de descifrado y recuperados los bootloaders legítimos, el bootkit pide a la víctima que reinicie el dispositivo (Figura 10). Si todo ha ido bien, el dispositivo debería iniciar el sistema operativo con éxito tras el reinicio.

Despliegue del componente UEFI bootkit

En esta sección, nos centramos en la funcionalidad de instalación del bootkit de los instaladores de HybridPetya descubiertos. Tenga en cuenta que los instaladores que pudimos obtener no tienen en cuenta UEFI Secure Boot. Sin embargo, como se explica en la sección de explotación de CVE-2024-7344, es probable que exista una variante con dicha mejora.

Para decidir si el sistema está basado en UEFI, el instalador recupera la información del disco(IOCTL_DISK_GET_DRIVE_LAYOUT_EX), comprueba si se utiliza el esquema de particionado GPT(PARTITION_STYLE_GPT), y recorre las particiones hasta que descubre la que tiene PARTITION_INFORMATION_GPT.PartitionType establecido en PARTITION_SYSTEM_GUID, que es el identificador de la partición del sistema EFI. Después de descubrir la partición del sistema EFI, continúa:

• Eliminar el gestor de arranque UEFI de reserva, almacenado en \EFI\Boot\Bootx64 .efi.
• Soltando una configuración relacionada con el cifrado de disco junto con la flag de cifrado, al archivo \EFI\Microsoft\Boot\config en la Partición del Sistema EFI; la configuración de cifrado contiene la clave de cifrado Salsa20, un nonce de 8 bytes, y la clave de instalación personal de la víctima( datoscodificados en base58 ).
• Colocación de una matriz de verificación de cifrado de 0x200 bytes con valor 0x07 en el archivo \EFI\Microsoft\Boot\verify de la partición del sistema EFI; esta matriz es cifrada posteriormente por el componente bootkit utilizando la misma clave Salsa20 utilizada para el cifrado del disco. El propósito de este array es verificar si la víctima introdujo una clave de descifrado válida (descifrando el array con la clave introducida, y verificando que el texto plano contiene un array de bytes con valor 0x07).
• Crear una copia de seguridad de \EFI\Microsoft\Boot\bootmgfw .efi, el gestor de arranque por defecto de los sistemas basados en Windows, copiándolo en \EFI\Microsoft\Boot\bootmgfw .efi.old.

Una vez hecho esto, desencadena un bloqueo del sistema (Blue Screen Of Death, BSOD) utilizando el mismo método que Petya – invocando la API NtRaiseHardError con el parámetro ErrorStatus establecido en 0xC0000350(STATUS_HOST_DOWN) y la ResponseOption establecida en el valor 6(OptionShutdownSystem), lo que resulta en un apagado del sistema.

Los cambios mencionados aseguran que en sistemas con Windows configurado como SO principal, el binario bootkit se ejecutará una vez que el dispositivo se encienda de nuevo.

Explotación de CVE-2024-7344

En esta sección, examinamos un archivo que descubrimos en VirusTotal que contiene una variante del bootkit UEFI descrito en la sección de bootkit UEFI, pero esta vez incluido en un archivo cloak.dat especialmente formateado relacionado con CVE-2024-7344 – la vulnerabilidad de desvío de arranque seguro UEFI que nuestro equipo reveló públicamente a principios de 2025.

Una lista de los archivos presentes en el archivo junto con su contenido sugiere que esta partición del sistema EFI fue copiada de un sistema ya cifrado por esta variante imitadora de Petya/NotPetya. Nótese que no hemos obtenido el instalador responsable de desplegar esta versión con el bypass UEFI Secure Boot, pero basándonos en el contenido del archivo, que se muestra en la Figura 11, sería bastante similar al proceso descrito en la sección anterior. En concreto, el archivo contiene:

• \EFI\Microsoft\Boot\counter, un archivo que ya contiene un valor distinto de cero que representa el número de clusters de disco previamente cifrados por el bootkit,
• \EFI\Microsoft\Boot\config, un archivo con el valor dla flag de cifrado a 1, lo que significa que el disco ya debe estar cifrado y el bootkit debe proceder a mostrar la nota de rescate,
• \EFI\Microsoft\Boot\bootmgfw.efi.old, un archivo con los primeros 0x400 bytes XORed con el valor 0x07,
• \EFI\Microsoft\Boot\bootmgfw.efi, una aplicación UEFI legítima pero vulnerable (CVE-2024-7344) firmada por Microsoft (revocada en el dbx de Microsoft desde enero de 2025); en esta sección nos referiremos a este archivo con su nombre original reloader.efi, y
• \EFI\Microsoft\Boot\cloak.dat, un archivo especialmente diseñado cargable a través de reloader. efi y que contiene el binario XORed del bootkit.

Como se describe en nuestro informe de enero de 2025, el mecanismo de explotación es bastante sencillo. El archivo cloak. dat contiene datos especialmente formateados que contienen una aplicación UEFI. Cuando el binario reloader.efi (desplegado como bootmgfw.efi) se ejecuta durante el arranque, busca la presencia del archivo cloak. dat en la partición del sistema EFI, y carga la aplicación UEFI incrustada desde el archivo de una forma muy insegura, ignorando completamente cualquier comprobación de integridad, saltándose así el arranque seguro UEFI.

Tenga en cuenta que nuestro blogpost de enero de 2025 no explicaba la explotación en detalle; por lo tanto, el autor del malware probablemente reconstruyó el formato correcto del archivo cloak. dat basándose en ingeniería inversa de la aplicación vulnerable por su cuenta.

La vulnerabilidad no puede explotarse en sistemas que tengan aplicada la actualización dbx de enero de 2025 de Microsoft. Para obtener orientación sobre cómo proteger y verificar si su sistema está expuesto a esta vulnerabilidad, consulte la sección Protección y detección de nuestra entrada de blog de enero de 2025.

Conclusión

HybridPetya es ahora al menos el cuarto ejemplo conocido públicamente de un bootkit UEFI real o de prueba de concepto con funcionalidad de desvío de arranque seguro UEFI, uniéndose a BlackLotus (que explota CVE-2022-21894), BootKitty (que explota LogoFail) y el PoC Hyper-V Backdoor (que explota CVE-2020-26200). Esto demuestra que eludir Secure Boot no sólo es posible, sino que es cada vez más común y atractivo tanto para investigadores como para atacantes.

Aunque HybridPetya no se está propagando activamente, sus capacidades técnicas -especialmente el cifrado MFT, la compatibilidad con sistemas UEFI y el desvío de Secure Boot- lo hacen digno de mención para el seguimiento de futuras amenazas.

Para cualquier consulta sobre nuestras investigaciones publicadas en WeLiveSecurity, póngase en contacto con nosotros en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Puede encontrar una lista completa de indicadores de compromiso (IoCs) y muestras en nuestro repositorio GitHub.

Archivos

Técnicas ATT&CK de MITRE

Esta tabla se ha creado utilizando la versión 17 del marco MITRE ATT&CK.

¡Para todos nuestros lectores!

Aprovechen esta oportunidad de obtener un trial gratuito de 30 días para Google Workspace, la mejor solución para tu empresa. Disfruta de todas sus funcionalidades, como correo electrónico personalizado, almacenamiento en la nube y herramientas de colaboración.

Comienza tu prueba gratuita