Agradecimientos: Un agradecimiento especial a Harlan Carvey y Lindsey O’Donnell-Welch por sus contribuciones a este blog e investigación.
Todos hablan sobre el impacto de la IA en la ciberseguridad, desde cómo afectará la gestión de vulnerabilidades hasta lo que significa para las campañas de los actores de amenazas. Durante el último año, hemos visto cómo los actores de amenazas dependen de la IA para aumentar su productividad en las campañas, en especial para redactar scripts, armar comandos y más. Al mismo tiempo, defensores como los analistas del Centro de Operaciones de Seguridad de Huntress (SOC) usan herramientas de IA en muchos puntos de sus investigaciones para conectar los puntos más rápido, mientras los analistas con experiencia revisan los resultados y se responsabilizan de cada veredicto e informe al final de la investigación.
Pero, ¿qué pasa si un usuario con Detección y respuesta para endpoints (EDR) administrada instalada intenta usar una herramienta de IA para solucionar problemas o responder a un comportamiento sospechoso? Hace poco analizamos un caso interesante donde esto ocurrió, y tuvo consecuencias inesperadas cuando nuestros analistas investigaron el endpoint.
Esta es una historia con tres líneas narrativas: el SOC de Huntress, un grupo de al menos dos actores de amenazas distintos, y un desarrollador externo que usaba el agente de codificación Codex de OpenAI para intentar frenar actividad maliciosa en su sistema Linux.
En esta primera parte de nuestra serie de blog en dos partes, explicaremos cómo el usuario final le indicó a Codex que lo ayudara a solucionar problemas y responder a un posible comportamiento malicioso en su endpoint. En la segunda parte, veremos cómo eso complicó el análisis inicial y la investigación del incidente desde la perspectiva del SOC.
Puntos clave
- Después de instalarse en medio de un incidente, Huntress investigó un endpoint perteneciente a una organización del sector tecnológico que estaba siendo atacada por múltiples actores de amenazas, quienes instalaron criptomineros, recolectaron credenciales y más.
- El usuario detrás del endpoint afectado dependía de un agente de IA (Codex) para intentar ejecutar auditorías de seguridad y solucionar problemas tras sospechar de actividad maliciosa en su sistema.
- El uso de Codex por parte del usuario añadió complicaciones imprevistas a la investigación del SOC sobre el incidente. Los intentos de usar Codex inicialmente no lograron remediar la amenaza. Los analistas del SOC que investigaban el incidente debieron luego separar los esfuerzos legítimos del usuario de las señales maliciosas.
- A medida que más usuarios dependen de la IA, incidentes como este muestran el valor de contar con expertos humanos detrás de las herramientas, con la experiencia necesaria para realizar investigaciones basadas en telemetría y distinguir entre comportamiento legítimo y malicioso.
Contexto
Entre el 20 de marzo y el 7 de abril, el SOC de Huntress respondió a varios conjuntos de alertas independientes luego de que se instalara el agente de Huntress en un endpoint Linux. La Figura 1 a continuación muestra las detecciones iniciales que se activaron. Cabe destacar que el agente se instaló en medio de un compromiso en curso, lo que significa que los actores de amenazas ya habían obtenido acceso y seguían activos en el endpoint después de la instalación. Esto suele hacer que las investigaciones sean más difíciles debido a la falta de telemetría histórica de EDR, y sin visibilidad de la actividad previa a la instalación del agente, los analistas del SOC no pueden determinar el vector de acceso inicial.
En un incidente típico, cuando se instala el agente y se activan alertas que indican algo potencialmente sospechoso, los analistas del SOC investigan en busca de pistas que ayuden a verificar si el evento es, de hecho, malicioso. Como se destaca en esta publicación del blog, estas investigaciones basadas en telemetría son hoy más importantes que nunca, porque los actores de amenazas suelen intentar esconderse a plena vista usando técnicas de vivir de la tierra, o procesos legítimos, en sus ataques. También es cada vez más común que los actores de amenazas borren los registros al finalizar un ataque, lo que hace aún más crítico contar con telemetría en vivo.
Esta necesidad crítica de distinguir el comportamiento normal de los comandos sospechosos se ilustra claramente en los comandos de la figura 1 anterior. Alerta de spoiler: algunos de los comandos eran legítimos, pero otros no.
A través del agente de Huntress, los analistas del SOC también acceden a varios tipos de datos y archivos en el endpoint como parte de su investigación del incidente, para ayudar a determinar la naturaleza y el alcance del incidente. Esto les permite vincular un incidente con diversas técnicas de atacantes, como un sitio web malicioso o un "drive-by" del navegador, un actor de amenazas que obtiene acceso a un endpoint mediante RDP para robar datos e implementar ransomware, o actividad aparentemente "maliciosa" que en realidad forma parte de la función empresarial diaria del usuario. Estos datos incluyen eventos de señal de Huntress que se activan en el momento de la instalación del agente, pero también incluyen el estudio de todo lo que ha ocurrido históricamente en el dispositivo, para ayudar a los analistas a determinar una causa raíz y pintar un panorama más preciso del incidente, lo que a su vez puede ayudar a determinar los mejores pasos de mitigación para la organización afectada.
Dado el uso de Codex observado en los comandos, como se ve en las figuras 1 y 2, en este incidente en particular, los analistas del SOC necesitaron examinar con detenimiento los artefactos de Codex, como los registros de sesión y de chat, para evaluar la legitimidad de las instrucciones específicas que se le daban a Codex. Estas pistas ayudaron al SOC a reconstruir el contexto detrás de las señales y, en última instancia, a desenredar el incidente y entender mejor lo que sucedió.
Figura 2: Una de las líneas de comando de /bin/bash que muestra el uso de Codex
Tras una inspección más detallada, los analistas del SOC descubrieron que algunos de los comandos, como los de la figura 2, en realidad son comandos legítimos de Codex realizados por el usuario en el endpoint. Según la investigación retroactiva del SOC sobre la telemetría forense, a continuación se describe un resumen de las acciones del usuario (legítimo) antes de que instalara el agente de Huntress.
Algo anda mal: ventiladores ruidosos y rendimiento lento
El 19 de marzo, el sistema del usuario se inició. Los registros de chat de Codex nos muestran que el usuario de este endpoint era, de hecho, legítimo, y parecía estar usando Codex para desarrollar activamente dos aplicaciones web en el endpoint. Podemos verlo a través del historial de chat de Codex del usuario y las marcas de tiempo a lo largo del tiempo, que muestran instrucciones para inicializar repositorios y desarrollar las aplicaciones.
Luego, la primera señal de que algo andaba mal para el usuario fue el 19 de marzo a las 15:07, cuando los registros de sesión de Codex mostraron que se quejaba de un ruido fuerte del ventilador: "Mis ventiladores están sonando muy fuerte".
Sin que lo supiera, un minero de criptomonedas se había instalado previamente en su sistema y había estado ejecutándose desde el arranque, minando Monero hacia un pool privado en 62.60.246[.]210:443. El binario del minero, /var/tmp/systemd-logind, se había compilado en agosto de 2024, lo que sugiere que era un remanente de una vulneración anterior.
Codex sugirió limitar el uso de la CPU, y el usuario luego aplicó un comando de terminal de Linux para silenciar los ventiladores. El usuario pareció quedar satisfecho con la sugerencia de Codex, diciendo: "Eso funcionó… Silencio. Perfecto. Resuelto". Luego, el usuario continuó con varias tareas de desarrollo de apps, incluyendo el uso de Codex para realizar una revisión de estado de la app.
Sin embargo, aquí es donde las cosas se complicaron: Codex solo enmascaró los síntomas del cryptominer, en lugar de diagnosticarlo realmente. El cryptominer siguió activo y en ejecución.
A las 17:30, varias horas después de su chat inicial con Codex sobre el problema, el usuario instaló el agente de Huntress en su endpoint, que rápidamente detectó la actividad en el endpoint que se muestra en la Figura 1.
Confusión de Codex
Además de que Codex no logró diagnosticar y detener eficazmente el cryptominer en el sistema, los comandos que generó fueron detectados por EDR, como este comando:
/bin/bash -c if . '/home/REDACTED/.codex/shell_snapshots/019d0c2c-e8a6-7840-8135-37ba5e11af5d.sh' >/dev/null 2>&1; then :; fi exec '/bin/bash' -c 'curl -I http://127.0.0.1:3016/[REDACTED]/index.m3u8'
Esto no fue un error.
Si bien este comando generado por IA surge de que Codex realizó la verificación condicional de la app descrita anteriormente, también podría indicar que un actor de amenazas estaba haciendo reconocimiento en el endpoint para identificar servicios locales.
El formato del comando, como la inclusión de curl y >/dev/null 2>&1, y el uso excesivo de pipes para encadenar varias operaciones en un "one-liner", se parece mucho a cómo los actores de amenazas dan formato a sus comandos, y por eso activa las detecciones de EDR creadas para encontrar comportamiento malicioso.
Todo esto para decir que la actividad legítima realizada por una IA sin una explicación clara se parece mucho a la actividad de un atacante, y revisar los comandos creados por IA para verificar si son maliciosos o legítimos según el contexto toma tiempo. La preocupación en este incidente, y en otros futuros en los que los usuarios inevitablemente usarán IA de forma similar, es el enorme volumen de ruido que generan herramientas de IA como esta, lo que podría hacer que la clasificación de endpoints sea mucho más compleja.
El final… del principio
Mientras avanzaban en la investigación, los analistas del SOC pudieron deducir el extraño giro del incidente a partir de los eventos anteriores: el usuario legítimo en el endpoint, aparentemente, estaba desarrollando dos aplicaciones web en el endpoint, usando Codex para trabajar en las apps mientras al mismo tiempo solucionaba actividad maliciosa.
Sin embargo, el incidente no termina ahí. Tras una investigación más detallada, se reveló que el endpoint estaba siendo atacado por al menos dos grupos distintos de actores de amenazas, quienes ejecutaron varios comandos que derivaron en minería de criptomonedas, robo de credenciales, exfiltración de datos y varios mecanismos de persistencia.
Mientras tanto, el usuario final siguió enviando prompts a Codex con el objetivo de realizar auditorías del sistema e intentar responder a la actividad sospechosa, lo que añadió más complicaciones a los analistas del SOC que intentaban llevar a cabo la investigación.
Si bien el uso de Codex ayudó al usuario a remediar ciertas partes del ataque, como detener una instancia del cryptominer, representó un desafío involuntario para el SOC: debido a que se le indicó que actuara como un respondedor de incidentes y remediara el sistema, sus comandos fueron marcados por las señales de Huntress, lo que hizo que la clasificación y la investigación inicial fueran más complejas. Al mismo tiempo, si bien Codex ayudó al usuario a detener procesos maliciosos, no brindó capacidades completas de respuesta a incidentes, y el actor de amenazas siguió regresando, exfiltrando credenciales, claves, tokens, metadatos de la nube y más.
…pero esa es una historia para otro blog.
Sintoniza la segunda parte de nuestra serie de blogs la próxima semana, "Codex Red: desenredando un incidente de Linux con un giro de OpenAI (Parte 2)", donde profundizaremos en el incidente después de que se instaló el agente de Huntress.
