Análisis Forense de Memoria y Reconstrucción de una Infección mediante ChromeSetup.exe, Volatility 3 y Threat Intelligence
Introducción
En numerosas investigaciones forenses, el punto de entrada no suele ser una sofisticada vulnerabilidad de día cero ni una compleja cadena de explotación. En muchas ocasiones, el compromiso comienza con algo aparentemente inocente: una descarga realizada por un usuario convencido de estar instalando una aplicación legítima.
Durante el análisis de una captura de memoria RAM obtenida de un sistema Windows comprometido, se detectó actividad asociada a un proceso que simulaba ser el instalador oficial de Google Chrome. Lo que inicialmente parecía una instalación rutinaria terminó revelando la presencia de una muestra perteneciente a la familia Ramnit, una amenaza activa desde hace años y especializada en el robo de información, descarga de componentes adicionales y comunicación con infraestructura controlada por atacantes.
A través del análisis de memoria mediante Volatility 3, la recuperación de artefactos residentes en RAM y la correlación con fuentes de inteligencia de amenazas, fue posible reconstruir la cadena de ejecución del malware e identificar los indicadores de compromiso asociados a la intrusión.
Primeras señales del compromiso
Toda investigación forense comienza respondiendo a una pregunta sencilla:
¿Qué estaba ejecutándose en el sistema en el momento de la adquisición de memoria?
Para ello se utilizó el plugin windows.pslist de Volatility 3, permitiendo enumerar los procesos activos presentes en la imagen analizada.
vol3 -f memory.dmp windows.pslist
Tras revisar los procesos del sistema, uno de ellos destacó inmediatamente por su naturaleza poco habitual.
Se trataba de un ejecutable denominado:
ChromeSetup.exe
PID: 4628
A diferencia de los procesos legítimos observados en la captura, este ejecutable no formaba parte de la línea base habitual del sistema operativo ni se encontraba asociado a software instalado previamente.
Su nomenclatura resultaba especialmente interesante: un supuesto instalador de Google Chrome ejecutándose en memoria en el mismo instante en que se generaba una alerta de seguridad.
Evidencia 1 – Identificación del proceso sospechoso
Localizando el origen del ejecutable
Identificar un proceso sospechoso es únicamente el comienzo. El siguiente paso consiste en determinar desde dónde fue ejecutado.
Mediante el plugin windows.cmdline se recuperó la línea de comandos asociada al proceso.
vol3 -f memory.dmp windows.cmdline | grep 4628
El resultado permitió identificar la ruta completa del binario:
C:\Users\alex\Downloads\ChromeSetup.exe
Este hallazgo resulta especialmente relevante desde una perspectiva de respuesta ante incidentes.
La ubicación del archivo sugiere que la ejecución fue iniciada directamente por el usuario desde la carpeta de descargas, un patrón extremadamente común en campañas de malware que utilizan instaladores falsos, actualizaciones fraudulentas o software troyanizado como mecanismo de distribución.
Evidencia 2 – Ruta de ejecución del malware
Reconstruyendo las comunicaciones de red
Una vez identificado el ejecutable, el siguiente objetivo fue determinar si había establecido comunicaciones externas.
El análisis de conexiones de red se realizó mediante el plugin windows.netscan.
vol3 -f memory.dmp windows.netscan
Filtrando por el PID del proceso investigado se observó actividad de red asociada directamente a ChromeSetup.exe.
vol3 -f memory.dmp windows.netscan | grep 4628
Entre los resultados apareció una dirección IP externa que destacaba por estar vinculada al proceso analizado:
58.64.204.181
La presencia de conexiones activas desde un supuesto instalador de navegador hacia una infraestructura remota constituye un fuerte indicador de comportamiento malicioso.
Evidencia 3 – Conexiones de red detectadas
Pivotando hacia la infraestructura atacante
La dirección IP identificada fue sometida a un proceso de enriquecimiento utilizando diversas fuentes OSINT y plataformas de Threat Intelligence.
La información obtenida reveló que la infraestructura estaba alojada en Hong Kong.
| Campo | Valor |
|---|---|
| Dirección IP | 58.64.204.181 |
| ASN | AS17444 |
| ISP | NWT iDC Data Service |
| Ubicación | Hong Kong |
Aunque la IP no acumulaba reportes directos de abuso en determinadas plataformas, la correlación posterior con la muestra analizada permitió confirmar su relación con actividad maliciosa.
Este tipo de escenarios son habituales en campañas de malware que emplean infraestructura efímera o recientemente desplegada para dificultar su detección.
Evidencia 4 – Geolocalización de la infraestructura
Recuperando el malware desde la memoria RAM
Uno de los mayores beneficios del análisis forense de memoria es la posibilidad de recuperar artefactos que pueden haber sido eliminados posteriormente del sistema de archivos.
Utilizando el plugin windows.dumpfiles, se procedió a extraer los objetos asociados al proceso investigado.
vol3 -f memory.dmp -o ./output windows.dumpfiles --pid 4628
Entre los elementos recuperados apareció el ejecutable completo cargado en memoria.
Evidencia 5 – Recuperación del ejecutable
Una vez recuperado el fichero, se calculó su huella criptográfica SHA-256.
1ac890f5fa78c857de42a112983357b0892537b73223d7ec1e1f43f8fc6b7496
Evidencia 6 – Hash SHA-256 de la muestra
Identificación de la familia malware
La consulta del hash en VirusTotal reveló un consenso prácticamente unánime entre motores antivirus.
La muestra fue identificada como maliciosa por:
65 de 70 motores
Las detecciones coincidían principalmente con las familias:
- Ramnit
- Nimnul
- Wapomi
- VJadtre
La convergencia de firmas permitió atribuir la muestra con alta confianza a la familia Ramnit, una amenaza históricamente vinculada al robo de credenciales, fraude financiero y distribución de malware secundario.
Evidencia 7 – Clasificación de la muestra
Infraestructura asociada a la campaña
El análisis de relaciones proporcionado por VirusTotal permitió identificar dominios e indicadores adicionales relacionados con la muestra.
Entre ellos destacaban:
ddos.dnsnb8.net
dnsnb8.net
Asimismo, se observaron referencias a múltiples archivos comprimidos alojados en la infraestructura remota:
http://ddos.dnsnb8.net:799/cj/k1.rar
http://ddos.dnsnb8.net:799/cj/k2.rar
http://ddos.dnsnb8.net:799/cj/k3.rar
http://ddos.dnsnb8.net:799/cj/k4.rar
http://ddos.dnsnb8.net:799/cj/k5.rar
La utilización de recursos comprimidos es una técnica frecuente en campañas Ramnit para la distribución de módulos adicionales o actualizaciones del malware.
Evidencia 8 – Dominios y recursos asociados
Conclusiones
Este caso demuestra nuevamente el valor del análisis forense de memoria como fuente primaria de evidencia durante investigaciones DFIR.
A partir de una única captura RAM fue posible identificar el proceso responsable, recuperar el ejecutable original, reconstruir sus comunicaciones de red y relacionarlo con una familia de malware ampliamente documentada.
La investigación permitió atribuir la actividad observada a una variante de Ramnit distribuida bajo la apariencia de un instalador legítimo de Google Chrome, confirmando una vez más que los mecanismos de ingeniería social continúan siendo uno de los vectores de compromiso más efectivos para los atacantes.
Más allá de la detección inicial, la memoria RAM conservó evidencias críticas que permitieron reconstruir la cadena completa de infección y generar indicadores de compromiso accionables para tareas de contención, detección y threat hunting. Esto ya tiene el nivel y la narrativa de un artículo profesional de DFIR similar al de StrelaStealer.
