En ocasiones, un archivo de malware continúa la infección en un equipo y se detiene tras unas pocas comprobaciones cuando se ejecuta en un laboratorio. Si reconoce indicios de que está siendo analizado, puede cambiar su comportamiento antes de mostrar la actividad que se intenta observar.
Esto ocurre porque algunas familias examinan el entorno antes de continuar. Buscan nombres de dispositivos virtuales, determinadas características del hardware o herramientas asociadas al análisis. Estas técnicas de antianálisis pueden impedir que un sistema de análisis automático llegue a observar las siguientes etapas de la infección. MITRE ATT&CK: evasión de entornos de análisis.
RenEngine incorpora comprobaciones de este tipo. En esta primera entrega de Reversing y antianálisis, seguimos sus llamadas y los valores que devuelven para entender cómo se calcula el resultado de la evaluación del entorno.
Introducción y alcance
RenEngine es una familia de malware de tipo loader. En una cadena de infección, un loader se encarga de preparar y ejecutar otro componente de malware. Ese componente puede, por ejemplo, robar información o dar acceso remoto al equipo. El análisis del loader permite estudiar cómo se llega a esa etapa y qué condiciones se comprueban antes de ejecutarla.
Otras familias que cumplen esta función son GuLoader, utilizado para descargar y cargar otros componentes de malware, y Bumblebee, empleado en campañas de intrusión para introducir cargas posteriores.
RenEngine utiliza un lanzador de videojuegos basado en Ren’Py para ejecutar sus scripts Python. El paquete combina componentes legítimos de ese entorno con el código del malware. Howler Cell, el equipo de investigación de Cyderes, documentó su distribución en instaladores de juegos modificados y una cadena en la que RenEngine precede a HijackLoader. Análisis de la campaña.
- 01Paquete descargadoDistribución como instalador
- 02Lanzador Ren’PyEjecución de los scripts
- 03 / ESTA ENTREGARenEngine LoaderComprobaciones del entorno
- 04Etapas posterioresHijackLoader en la cadena descrita
Cadena descrita por Howler Cell. Alcance de esta entrega: comprobaciones del entorno de RenEngine.
Para observar una muestra, un analista puede ejecutarla en una sandbox: un entorno con recursos y permisos controlados que permite registrar su actividad. Una máquina virtual puede formar parte de ese laboratorio. A su vez, el malware puede consultar los atributos del equipo y encontrar nombres como VirtualBox, que revelan virtualización. Una máquina virtual también puede alojar aplicaciones de producción, por lo que ese indicio puede aparecer en ambos entornos.
En RenEngine, varias funciones consultan esos atributos y les asignan puntuaciones. El motor de decisión reúne los resultados y calcula un valor de retorno. Para reconstruirlo hay que seguir cada llamada hasta el cálculo final. Como veremos, esta muestra realiza consultas cuyas puntuaciones acaba descartando.
La reconstrucción combina la lectura del código Python con los resultados de su ejecución en Windows. Al final se incluyen reglas de hunting y un laboratorio descargable para explorar las evidencias y reproducir los cálculos con un agente de IA.
NOTA DE LECTURAAnálisis estático y análisis dinámico
El análisis estático examina archivos, instrucciones y datos sin ejecutar el programa estudiado. Permite seguir llamadas y comprobar cómo se utilizan las variables.
El análisis dinámico observa una ejecución: llamadas, archivos, conexiones o valores de retorno. Sus resultados corresponden al entorno y a las condiciones de esa ejecución.
Esta entrega combina ambos métodos: sigue las llamadas del código Python y relaciona sus valores con las puntuaciones y el retorno registrados en el laboratorio.
01. Identificación de la muestra
El paquete de partida es un ZIP que contiene un instalador. Dos paquetes pueden compartir ese instalador y ejecutar scripts distintos, así que el nombre del archivo o el de la familia de malware resultan insuficientes para comparar investigaciones.
Para fijar qué archivos se analizan se utilizan hashes: resúmenes calculados a partir de su contenido. El informe de Triage 251222-yz7h3sslhz identifica el ZIP y su ejecutable con estos valores SHA-256:
| Artefacto del informe | SHA-256 |
|---|---|
(3) Free Download Files.zip |
436096ead19b13d54198f81f09bee47c48b63048ac83f0c4c6fb96ae01e1bf8c |
lnstaIer.exe |
7123e1514b939b165985560057fe3c761440a9fff9783a3b84e861fd2888d4ab |
Estos hashes sitúan el análisis en un paquete concreto. A continuación revisamos su estructura y los módulos que realizan las comprobaciones del entorno.
La primera captura permite situar el código que nos interesa. Se distinguen el runtime de Ren’Py —los componentes necesarios para ejecutar sus scripts—, un archivo archive.rpa y el directorio data/python-packages/planner/. En este último aparecen sandbox.py, specs.py, file_system.py, internet_access.py y __init__.py.
data/ y los módulos de planner/.Ampliar captura ↗El análisis se centra en sandbox.py, que organiza las comprobaciones, y en specs.py, que consulta los atributos del equipo. La presencia de file_system.py plantea otra comprobación: seguir las llamadas para saber si sus funciones llegan a ejecutarse. Lo revisaremos en la sección 03.
02. Configuración
El loader necesita localizar el recurso que contiene la siguiente etapa. En este paquete, el archivo data/.key guarda su nombre, el del ejecutable y una clave. La información está representada en Base64, una codificación que permite expresar datos como texto y recuperar después su contenido original.
Al decodificar el archivo en CyberChef aparece un objeto JSON. Sus campos relacionan cada nombre con un valor:
{
"filename": "0TKsgVisyu.txt",
"password": "aOlokna",
"exec_file": "vRzlJgcP.exe",
"sandbox": false,
"pub": "a16p2_1"
}
.key.Ampliar captura ↗Tres campos permiten seguir el recurso hasta la etapa posterior:
filenameseñala el recurso codificado:0TKsgVisyu.txt.passwordcontiene la clave que se utiliza en la operación XOR de la sección 06.exec_filedeclara el ejecutable de la siguiente etapa:vRzlJgcP.exe.
La configuración fija sandbox en false. En la variante documentada por Cyderes, ese valor activa las comprobaciones; true las omite. La sección siguiente sigue la evaluación del entorno dentro de is_sandboxed().
El campo pub, con el valor a16p2_1, se incluye en una petición de telemetría. Este uso fue verificado por el autor durante el análisis.
03. Flujo de llamadas y normalización
La función is_sandboxed() devuelve la evaluación del entorno. Para entender qué calcula, seguimos sus llamadas hasta la instrucción return.
En el código analizado, la puntuación procede de _check_specs(). La llamada a _check_file_system() está comentada: el intérprete la ignora durante la ejecución. También está comentada la línea que combinaría los resultados de ambas fuentes.
NOTA DE LECTURALectura de los fragmentos Python
def is_sandboxed(self):define un método.selfpermite acceder al objeto al que pertenece. La sangría delimita el bloque de instrucciones.#inicia un comentario. Las llamadas precedidas por ese carácter quedan fuera de la ejecución.s1, d1, e1 = ...asigna los tres valores devueltos a tres variables. En estos fragmentos se sigue la puntuación almacenada ens1.return self._normalize([s5, s6])pasa una lista con dos puntuaciones al normalizador y devuelve su resultado.
# Fragmento abreviado del código visible en la figura 3.
def is_sandboxed(self):
s1 = self._check_specs()
# s2 = self._check_file_system()
# final_score = self._normalize([s1, s2])
final_score = s1
percentage = int(100 - ((final_score / 5) * 100))
# Se omite aquí el bloque de logging.
return percentage / 100
Dentro de _check_specs() se ve el detalle de las consultas: disco, RAM, procesadores lógicos, modelo y fabricante. Cada llamada devuelve tres valores. Aquí seguimos el primero, la puntuación que se guarda en una variable s*.
# Fragmento abreviado del código visible en la figura 3.
s1, d1, e1 = Specs.check_hard_drive()
s2, d2, e2 = Specs.check_ram_space()
s3, d3, e3 = Specs.check_cpu_cores()
# s4, d4, e4 = Specs.check_serial_number()
s5, d5, e5 = Specs.check_model()
s6, d6, e6 = Specs.check_manufacturer()
# return self._normalize([s1, s2, s3, s4, s5, s6])
return self._normalize([s5, s6])
is_sandboxed(); a la derecha, _check_specs(). El retorno utiliza s5 y s6.Ampliar captura ↗La última línea fija las entradas del normalizador: _normalize([s5, s6]). La lista contiene las puntuaciones de modelo y fabricante. Las de disco, RAM y CPU se han calculado, pero quedan fuera de ese retorno.
Esta diferencia importa tanto para interpretar el resultado como para plantear detecciones. Las consultas de disco, RAM y CPU se ejecutan y pueden dejar actividad observable aunque sus puntuaciones no intervengan en el cálculo final.
Las llamadas a número de serie y a las comprobaciones de filesystem aparecen comentadas. En esos fragmentos quedan fuera de la ejecución.
is_sandboxed()_check_specs()s1 = 4Se ejecuta · valor descartados2 = 3Se ejecuta · valor descartados3 = 0Se ejecuta · valor descartados5 = 0Entrada al normalizadors6 = 5Entrada al normalizador_normalize([s5, s6])Transformación y retorno de is_sandboxed()Valores de la ejecución mostrada en la figura 4. Las llamadas a número de serie y filesystem aparecen comentadas.
04. Resultados del laboratorio
En el laboratorio, la llamada a is_sandboxed() devuelve 1.0. Para reconstruir ese número, partimos de las cinco puntuaciones que muestra la figura 4. El equipo devuelve VirtualBox como modelo e innotek GmbH como fabricante:
| Comprobación | Valor mostrado | Puntuación | Llega a _normalize() |
|---|---|---|---|
| Disco | 100 GiB totales | 4 | No |
| RAM | 2 GiB | 3 | No |
| CPU | 1 procesador lógico | 0 | No |
| Modelo | VirtualBox |
0 | Sí |
| Fabricante | innotek GmbH |
5 | Sí |
Según el flujo de llamadas anterior, de esta tabla solo llegan al normalizador los valores de modelo y fabricante: [0, 5]. La figura 5 recoge la invocación que produce el retorno de 1.0.
Sandbox.is_sandboxed() con logging. La salida mostrada es 1.0.Ampliar captura ↗La relación entre ambos resultados está en la salida anticipada de _normalize(): cuenta cuántos ceros hay en la lista y devuelve cero en cuanto encuentra alguno.
# Rama de salida anticipada de _normalize().
vm_indicators = values.count(0)
if vm_indicators > 0:
return 0
En [0, 5] hay un cero, por lo que esta rama devuelve 0. Ese valor pasa a ser final_score en is_sandboxed(). Al sustituirlo en la fórmula, se obtiene int(100 - ((0 / 5) * 100)) / 100 = 1.0, el mismo resultado que aparece en la consola.
En esta ejecución, el cero de la comprobación de modelo determina el resultado de la normalización, aunque fabricante aporte un 5.
Comparación del fabricante
La función check_manufacturer() evalúa manufacturer.lower() in Specs._MANUFACTURER. Primero convierte el nombre del fabricante a minúsculas y después comprueba si ese texto coincide con alguna entrada de la lista.
En el laboratorio, innotek GmbH pasa a ser innotek gmbh. La lista contiene innotek, pero carece de una entrada innotek gmbh. La comprobación de pertenencia devuelve falso y la función asigna una puntuación de 5. El operador in, aplicado a esta lista, exige la coincidencia con un elemento completo.
_MODELS y _MANUFACTURER en specs.py.Ampliar captura ↗05. Interpretación del valor de retorno
El retorno de 1.0 es el dato que recibe el código que ha llamado a is_sandboxed(). Resume el resultado de las comprobaciones que intervienen en el cálculo y permite utilizarlo como condición dentro del flujo de ejecución.
El mensaje de la función presenta el resultado como una probabilidad de virtualización. Su valor procede de una puntuación heurística y de la transformación aritmética que acabamos de seguir: final_score = 0 produce el retorno 1.0.
En la variante documentada por Cyderes, el loader compara el resultado con un umbral del 50 % para decidir si continúa. Esa condición conecta las comprobaciones de antianálisis con el acceso a las siguientes etapas de la infección.
06. Decodificación del recurso
La configuración también permite localizar el recurso de la siguiente etapa: 0TKsgVisyu.txt. Para identificar su contenido hay que deshacer la transformación aplicada a sus datos.
La captura de CyberChef muestra un fichero de 13.272.740 bytes y una operación XOR con la clave textual de .key. XOR combina los datos con una secuencia de clave; aplicar de nuevo esa misma secuencia recupera los valores iniciales. En la captura, la salida empieza por PK y contiene nombres de archivos.
El prefijo PK y los nombres de archivos de la salida son característicos de un contenedor ZIP. Una cabecera aporta información sobre el formato de los datos; en este caso, la operación XOR permite reconocer el formato del recurso que el loader mantiene codificado.
Triage clasifica el paquete como HijackLoader. Cyderes documenta también la relación entre ambas familias: RenEngine prepara una etapa posterior que continúa la cadena de infección. El motor de decisión estudiado en esta entrega forma parte de las comprobaciones previas a esa ejecución.
07. Detección y threat hunting
Las comprobaciones estudiadas permiten localizar el patrón del módulo en el código y buscar su actividad en los registros del sistema. Las reglas YARA y Sigma que acompañan al artículo describen estas dos búsquedas.
Buscar el patrón en código con YARA. En los scripts interesa la combinación de is_sandboxed, _check_specs y el retorno hacia _normalize([s5, s6]). YARA permite expresar patrones de texto o bytes y las condiciones que deben cumplir. La regla adjunta exige que estos tres aparezcan en un mismo fichero Python previamente extraído. Cada coincidencia debe revisarse junto con los demás archivos del paquete.
Buscar actividad en registros con Sigma. En los eventos de creación de procesos puede investigarse si un mismo proceso lanza varias consultas de inventario. Sigma permite describir esa selección para adaptarla después a una plataforma de análisis de registros. La propuesta busca consultas de PowerShell iniciadas desde Python o desde un lanzador con el nombre del informe.
La correlación agrupa al menos tres eventos en 30 segundos por equipo y proceso padre. Así se evita reunir consultas de máquinas o padres distintos. Cuenta eventos, incluidas repeticiones del mismo comando, y admite distintos órdenes de ejecución.
Estas consultas de inventario también son habituales en tareas de administración. Para valorar una coincidencia hay que revisar la procedencia y la ruta del proceso padre, los archivos asociados y la actividad posterior.
NOTA DE LECTURAInterpretación de una coincidencia
Una coincidencia indica que los datos cumplen las condiciones de una regla. Para atribuirla a malware se revisan los archivos implicados, la procedencia de los procesos y la actividad asociada.
Un falso positivo ocurre cuando la regla señala actividad legítima como sospechosa. Las consultas de inventario de este artículo también pueden proceder de tareas de administración.
El laboratorio permite comparar coincidencias y casos de control con datos de ejercicio. En un SOC, esa revisión incorpora el contexto del activo, las herramientas de administración autorizadas y la actividad relacionada.
El laboratorio incluye pruebas reproducibles de compilación YARA, sintaxis Sigma y correlación con datos de ejercicio. Para utilizar las consultas en un SOC, adapta los campos al origen de eventos y la correlación al motor de la plataforma. Especificación de correlación de Sigma.
YARA / SIGMAUso de las reglas
El laboratorio incluye reglas de hunting y ejercicios para estudiar su funcionamiento. Las pruebas reproducen la compilación de YARA, el análisis sintáctico de Sigma y la correlación de eventos con casos de coincidencia y de control.
renengine_source_pattern.yar busca tres patrones dentro de un único fichero de texto Python. Se aplica a los scripts extraídos del paquete. Al revisar una coincidencia, comprueba el código circundante, la procedencia del archivo y su relación con el resto de componentes.
renengine_inventory_hunt.yml contiene una selección de eventos de creación de PowerShell y una correlación event_count. Agrupa por Computer y ParentProcessGuid y cuenta al menos tres eventos en 30 segundos. Cuenta también las repeticiones de un mismo comando.
Para utilizar Sigma en tu plataforma, mapea los campos de la fuente de eventos y configura la correlación en el motor de destino. Los datos de equipo, proceso padre y línea de comandos permiten agrupar la actividad y estudiar su contexto. Contrasta las coincidencias con las tareas de administración autorizadas en ese entorno.
El ZIP contiene los ejemplos y un verificador local. validation/toolchain.json recoge las versiones y los resultados de las herramientas. Los eventos sintéticos permiten estudiar cómo influyen la ventana temporal, las repeticiones y la agrupación por proceso padre.
08. Conclusiones
Al seguir las llamadas se observa que esta variante consulta cinco atributos del hardware y utiliza dos puntuaciones para calcular el resultado: modelo y fabricante. En el laboratorio valen 0 y 5, respectivamente. La rama abreviada del normalizador devuelve cero para esa entrada y la conversión posterior produce 1.0, en concordancia con la consola.
Este recorrido permite relacionar el código, la salida del laboratorio y las detecciones propuestas. Las consultas de inventario generan actividad útil para hunting incluso cuando sus puntuaciones se descartan. Seguir el flujo de datos permite identificar qué comprobaciones intervienen en el resultado y cuáles aportan señales para investigar la muestra.
La siguiente entrega prevista tratará environmental keying, el uso de información del entorno en el descifrado de una etapa.
REVERSING / LABORATORIO 01Analiza el caso
con tu agente de IA
Descarga las evidencias y las instrucciones del laboratorio. Tu agente puede ayudarte a seguir las llamadas, reproducir el cálculo de la puntuación y probar las hipótesis de detección con los datos de ejercicio.
- EvidenciasCapturas, fragmentos y observaciones con su procedencia.
- Guía para agentesInstrucciones Markdown, tareas y formatos de resultados.
- EjerciciosReglas YARA/Sigma, datos sintéticos y verificador local.
ZIP · 2,0 MB
Contraseña infected
SHA-256
645b862e155293d31eeac16a5eb7b2fe7266c86be3df0d0dbd15c9c728aa0fa1Incluye material documental y ejercicios con datos sintéticos. No contiene malware ejecutable ni registros originales.
GUÍA DE USOEmpezar con tu agente
Extrae el ZIP con la contraseña infected, abre la carpeta en tu herramienta de IA y utiliza esta instrucción:
Lee AGENTS.md y sigue WORKFLOW.md. Ayúdame a reconstruir las llamadas de RenEngine, reproducir los cálculos y probar las reglas de hunting con los datos del paquete. Explica los conceptos que necesite y cita la evidencia de cada conclusión. Guarda los resultados en out/.
El verificador utiliza Python 3.9 o posterior. La prueba con el motor YARA requiere tenerlo instalado. El laboratorio también se puede recorrer manualmente.
Conceptos de
reversing
Terminología utilizada en el artículo.
Reversing
Análisis de un programa para reconstruir su estructura y funcionamiento a partir de sus archivos, instrucciones y datos. Puede combinar la inspección del código con la observación de su ejecución.
Esta entrega sigue las llamadas y los valores de los scripts Python documentados.
Antianálisis
Técnicas con las que un programa dificulta su inspección o cambia su comportamiento al detectar condiciones asociadas al análisis, como herramientas de depuración o indicios de virtualización.
RenEngine consulta características del equipo. Para determinar cómo afectan a la ejecución hay que seguir el código que utiliza el resultado.
Loader
Componente que prepara y carga otro componente de software. En una cadena de infección puede recuperar, decodificar y ejecutar una etapa posterior del malware.
RenEngine interviene antes de las etapas posteriores descritas en el informe de la campaña.
Sandbox
Entorno de ejecución con recursos y permisos restringidos. En el análisis de malware se utiliza para observar actividad bajo condiciones controladas.
Las comprobaciones de esta muestra buscan indicios de virtualización; esos indicios también pueden aparecer en equipos de producción.
Máquina virtual
Sistema que ejecuta un sistema operativo sobre recursos de hardware virtualizados. Un mismo equipo físico puede alojar varias máquinas virtuales.
El laboratorio muestra VirtualBox como modelo del sistema. La virtualización también se utiliza habitualmente para alojar servidores y aplicaciones.
Motor de decisión y normalización
En este artículo, el motor de decisión es el conjunto de funciones que consulta atributos del equipo, les asigna puntuaciones y calcula un resultado. La función de normalización procesa las puntuaciones que recibe.
El normalizador recibe las puntuaciones de modelo y fabricante: [0, 5]. La presencia de un cero activa la salida anticipada y determina el resultado de esta ejecución.
Valor de retorno
Dato que una función entrega al código que la ha llamado. En Python, la instrucción return termina esa llamada y devuelve el valor de la expresión que la acompaña.
La captura muestra un retorno de 1.0 para is_sandboxed(). Su efecto sobre la ejecución depende de cómo lo utilice el código que llama a la función.
Hash / SHA-256
Un hash es un resumen calculado a partir de unos datos. SHA-256 produce 256 bits, habitualmente representados por 64 caracteres hexadecimales. Se utiliza para identificar archivos y comprobar su integridad.
Los valores de la tabla permiten localizar los archivos concretos del informe. La clasificación de un archivo como malware requiere información adicional.
Runtime
Componentes necesarios para ejecutar un programa: pueden incluir un intérprete, bibliotecas y servicios de ejecución.
El paquete contiene componentes de Ren’Py que permiten ejecutar sus scripts Python.
Base64
Codificación que representa datos mediante un alfabeto de 64 caracteres. La decodificación recupera los datos originales siguiendo un procedimiento público, sin necesidad de una clave secreta.
Al decodificar data/.key, la captura de CyberChef muestra la configuración en formato JSON.
JSON
Formato de texto para representar datos estructurados. Un objeto JSON contiene pares de nombre y valor; los valores pueden ser textos, números, booleanos, listas u otros objetos, entre otros tipos.
En la configuración, filename es el nombre de un campo y 0TKsgVisyu.txt es su valor. false es un valor booleano.
Telemetría
Datos que un sistema registra o transmite sobre su estado y actividad. Pueden incluir eventos de procesos, conexiones, errores y métricas.
El autor verificó que pub se incluye en una petición de telemetría. Los eventos de procesos utilizados en detección son otra forma de telemetría: datos recogidos para investigar actividad.
Filesystem
Sistema de archivos: estructuras y mecanismos que organizan archivos, directorios y sus metadatos en un medio de almacenamiento.
La llamada a _check_file_system() aparece comentada en el fragmento de is_sandboxed().
Logging
Registro de mensajes y eventos durante la ejecución de un programa. Los registros pueden incluir valores internos, errores y marcas de tiempo.
Las capturas muestran mensajes con las puntuaciones de las comprobaciones y el resultado devuelto.
XOR
Operación lógica entre bits: devuelve 1 cuando son distintos y 0 cuando son iguales. Aplicar XOR dos veces con la misma secuencia de clave recupera los datos iniciales.
La captura aplica XOR al recurso indicado en la configuración. El resultado empieza por los caracteres PK.
Cabecera de archivo
Estructura de datos que aporta información sobre el formato o el contenido de un archivo. Puede incluir una secuencia de bytes utilizada para reconocer el tipo de datos.
La salida de XOR muestra el prefijo PK y nombres de archivos, característicos del formato ZIP.
DLL
Biblioteca de enlace dinámico de Windows. Contiene código y datos que otros módulos pueden utilizar, por ejemplo mediante llamadas a las funciones que exporta.
Las cadenas de infección de Windows pueden combinar ejecutables y DLL. Identificar qué proceso carga cada biblioteca ayuda a reconstruir su ejecución.
Hunting
Búsqueda de actividad sospechosa a partir de una hipótesis. Se consultan datos disponibles y se revisan los resultados para comprobar si encajan con el comportamiento investigado.
La hipótesis de esta entrega busca consultas de inventario asociadas a determinados procesos y propone revisar su contexto.
YARA
Herramienta y lenguaje de reglas para buscar patrones textuales o binarios y combinarlos mediante condiciones lógicas.
La regla propuesta busca una combinación concreta de funciones y código en un archivo Python previamente extraído.
Sigma
Formato para describir reglas de detección sobre registros de eventos. Permite convertir esas reglas a consultas para distintas plataformas, con la adaptación de campos y fuentes que corresponda.
La propuesta utiliza eventos de creación de procesos y una correlación temporal. Su funcionamiento depende de los datos recogidos y del sistema de destino.
Proceso padre
Proceso registrado como origen de la creación de otro proceso. Esta relación permite reconstruir parte de la actividad de ejecución de un sistema.
La correlación agrupa eventos por equipo y proceso padre. Su ruta, identificador y línea de comandos ayudan a interpretar las coincidencias.
No hay conceptos que coincidan con la búsqueda.