Cuando el ransomware atacaba antes de arrancar Windows: explorando OpenPetya y la lógica detrás de un bootkit moderno
OpenPetya es un proyecto que ha nacido como un ejercicio práctico para responder una pregunta que muchas veces queda a medias cuando se estudia malware histórico: ¿qué ocurre realmente por debajo del sistema operativo cuando un bootkit toma control del proceso de arranque?
Cuando se habla de Petya o NotPetya, la mayoría de explicaciones se detienen en la superficie: ransomware que cifra datos, interrumpe sistemas y deja una pantalla exigiendo una clave. Pero el comportamiento interno es mucho más interesante. Petya no se limitaba a ejecutarse dentro de Windows; alteraba el propio proceso de inicio del sistema. El ataque comenzaba antes de que el usuario llegara al escritorio, antes incluso de que gran parte del sistema operativo estuviera disponible.
OpenPetya intenta reconstruir esa lógica desde una perspectiva educativa.
No pretende ser una réplica exacta de Petya ni de NotPetya. En lugar de perseguir una simulación perfecta, adopta una aproximación más enfocada en aprendizaje y análisis: implementar desde cero los mecanismos fundamentales que hacen funcionar un bootkit y entender cómo interactúan entre sí.
El proyecto está desarrollado utilizando Assembly, C y C++, una combinación especialmente adecuada para trabajar en niveles muy cercanos al hardware. Cada lenguaje cumple un papel distinto: Assembly permite controlar directamente las fases tempranas del arranque y las instrucciones de bajo nivel del procesador, mientras que C y C++ aportan estructura para la lógica más compleja.
La arquitectura gira alrededor de varios elementos principales.
El primer componente es un Master Boot Record personalizado o MBR. El MBR es una pequeña región ubicada al inicio del disco que tradicionalmente contiene información necesaria para iniciar el sistema operativo. Normalmente su función es relativamente simple: localizar el siguiente componente de arranque y transferirle el control.
OpenPetya reemplaza este comportamiento por uno propio. En lugar de continuar con la secuencia estándar de arranque de Windows, el MBR modificado carga un payload adicional: un bootloader de segunda etapa o Stage-2. Aquí es donde ocurre la mayor parte de la lógica del proyecto.
El Stage-2 actúa como núcleo funcional y contiene mecanismos responsables de:
- transición del procesador a Protected Mode
- operaciones criptográficas basadas en Salsa20
- cifrado y descifrado de estructuras NTFS
- validación de contraseñas
- restauración del sistema
- interfaz visual durante el arranque
Uno de los aspectos más interesantes es la transición entre Real Mode y Protected Mode.
Al iniciarse una arquitectura x86 tradicional, el procesador comienza ejecutándose en modo Real de 16 bits, un entorno extremadamente limitado heredado de diseños antiguos. En este modo existen restricciones importantes:
- espacio de memoria reducido
- direccionamiento limitado
- ausencia de capacidades avanzadas
- pocas facilidades para programas complejos
Por esta razón OpenPetya cambia el procesador a Protected Mode de 32 bits antes de ejecutar lógica de mayor nivel.
Este cambio permite acceder a:
- modelos de memoria más amplios
- mejores mecanismos de segmentación
- instrucciones más avanzadas
- estructuras necesarias para operaciones complejas
Una vez realizado el cambio de modo, comienza el proceso relacionado con almacenamiento y cifrado.
En lugar de cifrar archivos individuales, OpenPetya adopta una estrategia inspirada en Petya y actúa directamente sobre una estructura crítica del sistema de archivos NTFS: la Master File Table o MFT.
La MFT puede entenderse como una especie de índice central que describe prácticamente todos los archivos y directorios presentes en un volumen NTFS. Aunque el contenido físico de los archivos permanezca en disco, corromper o cifrar partes críticas de esta estructura hace extremadamente difícil acceder a ellos.
El proyecto implementa un mecanismo basado en Salsa20 para realizar estas operaciones. Salsa20 es un algoritmo criptográfico de flujo diseñado por Daniel J. Bernstein que destaca por su velocidad y simplicidad relativa. En OpenPetya se utiliza para demostrar cómo un bootkit podría aplicar procesos criptográficos dentro de un entorno extremadamente limitado, donde todavía no existen librerías de alto nivel disponibles. Sin embargo, el proyecto introduce algunas simplificaciones deliberadas.
A diferencia de variantes reales de ransomware, OpenPetya no incorpora infraestructura Command and Control (C2). Tampoco busca dificultar el análisis mediante técnicas avanzadas de evasión.
Además, después del cifrado almacena copias de seguridad de la información MFT en sectores ocultos del disco en formato sin cifrar.
Esta decisión puede parecer extraña desde una perspectiva ofensiva, pero tiene sentido en un entorno educativo: el objetivo no es destruir información ni crear una amenaza real, sino permitir que el investigador pueda observar el comportamiento interno y comprender cómo funciona la recuperación.
El proceso completo puede resumirse de la siguiente forma:
1. Inicialmente el usuario ejecuta OpenPetya.exe y selecciona una contraseña. El instalador permite elegir unidades y preparar los componentes necesarios.
2. Posteriormente el sistema se reinicia manualmente o mediante un mecanismo basado en NtRaiseHardError, una API interna de Windows utilizada para generar una interrupción crítica.
3. Durante el siguiente arranque el MBR personalizado toma el control y carga el Stage-2.
4. Una vez cargado:
- el procesador cambia a Protected Mode
- se ejecuta la lógica criptográfica
- se seleccionan estructuras críticas del MFT
- se realiza el proceso de cifrado
5. El sistema vuelve a reiniciarse. En el siguiente arranque aparece una interfaz previa al sistema operativo solicitando una contraseña. Si la contraseña introducida coincide:
- la información cifrada es restaurada
- la cadena original de arranque vuelve a su estado previo
- el bootkit elimina sus propios componentes
- Windows continúa iniciando normalmente
Otro detalle interesante es lo que OpenPetya decide no implementar. El proyecto evita comportamientos clásicos utilizados por Petya para manipular psicológicamente al usuario, como pantallas falsas de CHKDSK o mecanismos de ingeniería social.
La intención es mantener el foco sobre la parte realmente interesante: la mecánica interna del boot process. Más que una demostración de ransomware, OpenPetya funciona como un laboratorio de investigación sobre:
- bootkits
- arquitectura de bootloaders
- internals de Windows
- programación Assembly
- estructuras NTFS
- criptografía aplicada
- malware de bajo nivel
Proyecto: https://github.com/iss4cf0ng/OpenPetya
Fuentes: [Learning] OpenPetya: A Proof-of-Concept of Petya Ransomware
Refs.
Comentarios
Publicar un comentario