Cryptojacking en un servidor CentOS 7: análisis forense de una infección por minero de criptomonedas

Introducción

Todo empezó con algo bastante clásico: un servidor en producción con CPU al mango.
El consumo no bajaba, se mantenía alto, y eso en un sitio web… es raro. Muy raro.

Así que nos metimos a ver qué estaba pasando.
No era tráfico legítimo, no era un pico de carga… era otra cosa.
Y lo que encontramos fue un caso textbook de cryptojacking: alguien había tomado control del sistema y lo estaba usando para minar criptomonedas.

¿Qué encontramos?

El atacante aprovechó una vulnerabilidad conocida: CVE-2020-7961, una falla de deserialización insegura en Liferay que permite ejecución remota de código a través del endpoint:

/api/jsonws/expandocolumn/update-column

Con eso, logró:

• Descargar y ejecutar scripts maliciosos (mon.sh, run.sh)

• Instalar un minero de criptomonedas basado en XMRig (versión 6.15.2)

• Dejar binarios ofuscados en el sistema, como:

  • /opt/liferay/g → binario ELF estático, ofuscado (posible downloader o minero)

  • /root/L → archivo que contiene el resultado de una redirección a

  • https://www.thc.org/ssh-it/bs

• Ese último (bs) no es cualquier cosa: es un gusano SSH diseñado para moverse lateralmente buscando claves privadas o contraseñas en historiales, e intentar propagarse por la red.

Evidencia clave

Durante el análisis forense identificamos una cadena de actividades maliciosas típicas de campañas de cryptojacking automatizadas. Todo comenzó con la descarga de scripts desde servidores externos, como mon.sh y run.sh, alojados en IPs efímeras (151.106.34.115, 189.203.240.235). Estos scripts se ejecutaron de forma automática tras explotar la vulnerabilidad en Liferay.

Una vez dentro del sistema, el atacante desplegó un minero de criptomonedas basado en XMRig (v6.15.2), detectado activo en /home/usuario/xmrig6152. Pero no se quedó ahí: también dejó binarios ofuscados para asegurar persistencia y evadir detección.

El más llamativo es el archivo /opt/liferay/g: un binario ELF 64-bit, estático y ofuscado, cuyo comportamiento sugiere que actúa como downloader o minero secundario. Además, encontramos el archivo /root/L, que contiene el registro de una redirección HTTP hacia https://www.thc.org/ssh-it/bs —un conocido gusano SSH diseñado para propagarse lateralmente mediante credenciales débiles o claves expuestas.

Lo más preocupante: el atacante usó técnicas avanzadas de evasión. Por ejemplo, aplicó atributos inmutables (chattr +i) a algunos archivos para impedir su eliminación accidental, y configuró tareas programadas vía cron para reiniciar el minero si era detenido.

También notamos que cambiaba frecuentemente las IPs y servidores de descarga, lo que indica una infraestructura dinámica pensada para evitar bloqueos y prolongar la vida útil de la infección.

Afortunadamente, pese a estas tácticas, no hallamos indicios de que lograra moverse a otros servidores de la red interna

¿Hubo movimiento lateral?

Armamos un script de auditoría específica, luego lo estaré subiendo al repositorio para compartir, lo que hace es:

1. Identifica el sistema operativo

2. Busca logs de autenticación /var/log/secure, journalctl

3. Escanea por la IP sospechosa 10.100.10.122

4. Revisa historial de comandos de root

5. Analiza accesos SSH exitosos y fallidos

6. Audita registros de /var/log/audit

Resultado

No encontramos evidencia de movimiento lateral dentro de los activos analizados. El ataque parece haberse limitado a este servidor.

Medidas implementadas

Dado que no era viable actualizar la plataforma por tratarse de un sistema legacy que debía continuar en producción, se optó por un enfoque orientado a mitigar el riesgo en lugar de eliminarlo completamente.

La estrategia adoptada fue rediseñar el entorno para reducir la superficie de ataque y aislar la aplicación vulnerable.

Cambios en la infraestructura

• Migración a un host con Debian hardenizado

• Uso de contenedores con Podman

• Creación de una imagen con CentOS 7 para mantener compatibilidad con Liferay

• Aislamiento del servicio dentro del contenedor

Este enfoque permitió encapsular la aplicación en un entorno controlado, limitando el impacto ante un posible compromiso.

Medidas adicionales firewall

• Restricción de acceso al sitio por país

• Reducción de superficie de ataque

• Mayor control del entorno

El objetivo no era hacer el sistema perfecto, sino hacerlo mucho más difícil de comprometer.

Conclusión

Fueron la consecuencia de un sistema expuesto, atacado por herramientas automatizadas que explotan vulnerabilidades conocidas.

La solución no fue solo técnica, sino estratégica: pasar de reaccionar a incidentes → a diseñar un entorno más seguro.

Porque en seguridad, muchas veces, no gana el sistema más fuerte…

sino el que está mejor preparado.

Si querés compartir tu experiencia, escribime a: valerkasystem@protonmail.com

- Valerka
Montevideo, Uruguay