Preámbulo
El lunes pasado por la noche estaba trabajando hasta tarde y llegó una alerta de Slack de una herramienta de monitorización que montó tres días antes. Axios llegó a un compromiso; Uno de los paquetes NPM más populares del mundo.
Mi corazón empezó a latir con fuerza, sabía que cada segundo contaba para responder y limitar el daño. Pero sinceramente fue tan loco que pensé que debía ser un falso positivo. Revisé y volví a revisar todo varias veces aunque parecía claramente malicioso.
No fue un falso positivo. Fue uno de los mayores compromisos en la cadena de suministro jamás registrados en el NPM, con presunta atribución a actores estatales de la RPDC. Lo pillamos con una prueba de concepto que improvisé un viernes por la tarde, funcionando en mi portátil, impulsado por diferenciales de lectura por IA.
Quiero compartir toda la historia. Cómo llegamos hasta aquí, qué construí y por qué creo que compartirlo abiertamente hace que todos estén un poco más seguros.
Llevo un tiempo preocupado por la cadena de suministro
Algunos incidentes recientes en la cadena de suministro realmente me dejaron despierto por las noches. El compromiso de la cadena de suministro es un problema difícil. En Elastic tenemos muchísimos desarrolladores, y nuestros clientes de seguridad confían en nosotros para protegerlos. Quedó claro que el statu quo está roto y necesitamos alguna nueva tecnología o procedimientos que ayuden. Tenía algunas ideas sobre un ecosistema más fiable y verificado por IA, basar en principios de control de aplicaciones y limitando costos y fricciones.
Pero el compromiso Trivy fue realmente donde me fijé. El 19 de marzo, un grupo llamado TeamPCP comprometió la acción GitHub Action de aquasecurity/trivy-action (la que es para el popular escáner de seguridad Trivy, sí, una herramienta de seguridad). Inyectaron a un ladrón de credenciales que extraía secretos de las tuberías CI/CD. Se robaron una enorme cantidad de credenciales.
Eso se desbordó rápido. El 24 de marzo, LiteLLM fue atacado. TeamPCP robó las credenciales de publicación PyPI de LiteLLM a través de la canalización envenenada de Trivy y las empleó para difundir versiones maliciosas que eran agresivos ladrones de credenciales. Claves SSH, credenciales en la nube, claves API, datos de cartera, todo.
LiteLLM es un paquete que yo mismo usé. Así que se podría decir que en ese momento estaba completamente "despierto por la noche".
Sabía que con todas las credenciales filtradas por la brecha de Trivy, definitivamente habría más. Necesitábamos hacer algo para mantenernos por delante. Tanto para nuestros clientes como para proteger a Elastic.
Viernes, luego del vuelo nocturno
Acababa de volar de regreso desde el RSAC 2026 en Santo Francisco. Vuelo nocturno el jueves por la noche. Si hiciste un vuelo nocturno luego de cuatro días de conferencia, sabes en qué estado estaba. Sin embargo, estaba tan emocionado como siempre por un nuevo proyecto, así que me senté y desarrollé la v0.0.1.
La idea: monitorizar los cambios a medida que se envían a los repositorios de paquetes. Haz un diferencial para ver qué cambió. Usa IA/LLM para determinar si los cambios son maliciosos. Básicamente eso es todo.
El oleoducto se ve así:
- Consulta la API de registro de cambios de PyPI y el feed de
_changesde CouchDB de npm para nuevas versiones - Filtra según una lista de seguimiento de los 15.000 paquetes principales por número de descargas
- Descarga las versiones antigua y nueva directamente desde el registro (sin instalación de pip, sin instalación de npm, sin ejecución de código)
- Diferencialos en un reporte de descuento
- Envía el diferencial a un LLM: "¿esto es malicioso?"
- Si es así, alerta a Slack
Quería centrarme principalmente en paquetes top ya que probablemente ahí irían los atacantes de todos modos, y sería mucho menos costoso en términos de tokens y cálculo. Era completamente manejable de ejecutar en mi portátil.
Por qué Cursor
Hay muchos arneses para agentes por ahí. Escribí los míos propios para proyectos como ingeniería inversa de malware por IA. Pero iba muy justo de tiempo, así que decidí aprovechar Cursor porque es una de mis principales herramientas de desarrollo. La Agent CLI te permite invocarla programáticamente: pasar un espacio de trabajo, una instrucción y un modelo. Lo uso en modo ask (solo lectura) para que solo pueda leer el diferencial, nunca modifica nada. Todo el paso de análisis es una llamada a un solo subproceso.
El prompt es sencillo. Le digo qué debe buscar (código ofuscado, base64, evalación/ejecutiva, llamadas de red inesperadas, esteganografía, mecanismos de persistencia, abuso de scripts del ciclo de vida) y le pido que responda con Verdict: malicious o Verdict: benign. Analiza el veredicto, actúa en consecuencia.
Sobre la selección de modelos
Normalmente uso Opus 4.6 o GPT 5.4 para la mayoría de las cosas. Opus especialmente para tareas centradas en ciberseguridad. Pero quería mantener bajos los costos para algo que necesita analizar decenas de lanzamientos por hora.
Últimamente hubo muy buenas entradas en el blog del equipo de Cursor, una sobre la búsqueda rápida de agentes regulares para herramientas y otra sobre su enfoque de RL en tiempo real, donde usan tokens reales de inferencia de producción como señales de entrenamiento y despliegan puntos de control mejorados aproximadamente cada cinco horas. Ingeniería realmente impresionante.
Así que quería darle una oportunidad a Composer 2 . Usé el modo rápido, que es realmente rápido. Perfecto para un caso de uso en tiempo real. Bajo costo, rápido y efectivo (según mis pruebas).
Pruebas en Telnyx
Tienes que probar estas cosas para saber si realmente funcionan. Normalmente eso significa ajustar muchos prompts.
Tuve suerte (o mala suerte) con el timing. El mismo viernes que estaba construyendo esto, el paquete PyPI de Telnyx fue comprometido por TeamPCP. Inyectaban 74 líneas de código malicioso en _client.py: cargas útiles ocultas dentro de archivos de audio WAV (esteganografía), ofuscación base64, un implante de persistencia de Windows disfrazado de msbuild.exey exfiltración a un C2 codificado en fija.
Empleé la diferencia entre el paquete legítimo y el malicioso telnyx para desarrollar el prompt inicial. El modelo era muy bueno identificando cambios maliciosos como este. También quería saber inmediatamente cuando se detectara un compromiso, así que agregué alertas de Slack.
Lunes por la noche
La dejé funcionar durante el fin de semana. Se agitaba entre liberaciones, todo volvía benigno.
Nunca di ni un solo falso positivo, lo cual es sinceramente extraño si alguna vez hiciste trabajo de detección en ciberseguridad. Normalmente estamos ahogados en FPs. Intencionadamente instruí al LLM para que solo avisara sobre compromisos en la cadena de suministro de "alta confianza", ya que generalmente son muy rápidos desde el principio. Sigo detectando el caso de prueba de Telnyx, sin FPs. Podría estar sobreajustando con un tamaño de muestra tan bajo, pero no hay tiempo para construir algo más robusto.
Luego, el lunes por la noche, trabajando hasta tarde, llegó la alerta de Slack.
🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4¿De verdad acaba de encontrar uno de los mayores compromisos en la cadena de suministro de los últimos tiempos?
Revisé el análisis. Lo volvió a comprobar. Lo volví a comprobar. Los atacantes comprometieron la cuenta npm de un mantenedor, cambiaron el correo a una cuenta de ProtonMail que controlaban y publicaron dos versiones maliciosas (1.14.1 y 0.30.4). No inyectaban código directamente en Axios. En su lugar, agregaron una dependencia fantasma llamada plain-crypto-js que ejecutaba un gancho postinstalación para desplegar malware multiplataforma. Obviamente fue malicioso.
La respuesta
Contacté inmediatamente con nuestro equipo de seguridad de la información y el equipo de investigación de Elastic para que los pusiera en marcha. Sabía que cada segundo importaba. Resulta que cuando contacté con ellos, ya recibieron alertas de Elastic Defend en un host que instaló el paquete malicioso y estaba respondiendo activamente. Pero en ese momento nadie se dio cuenta de la magnitud del problema ni tenía una causa raíz que entendía cómo se infectaba la máquina. La herramienta de monitorización proporcionó ese contexto que faltaba.
Intenté enviarle un correo a security@npmjs y me dieron un rebote. Intenté enviarlo a su portal de seguridad y me salió un error. Tuiteé desesperada por contactar con un humano. También abrí rápidamente un problema de seguridad en el propio repositorio Axios.
Más tarde, vi un tuit de otro investigador que observó el compromiso, y me di cuenta de que lo estaba gestionando más como una vulnerabilidad que como un incidente en la cadena de suministro. Con una vulnerabilidad, coordinas en silencio. Con un compromiso activo que es instalar malware en las computadoras de las personas ahora mismo, ir a la gran distancia es la decisión correcta. Así que inmediatamente compartí todos los detalles que recopiló en X.
Incluso empezamos a recibir alertas de nuestra telemetría mostrando organizaciones afectadas en la naturaleza. La cosa estaba funcionando activamente.
Por suerte, el equipo de Axios se lanzó y retiró los paquetes bastante rápido. Además, el servidor C2 del atacante recibía tantas peticiones que se estaba cayendo. Podría ser mucho peor.
Nuestro equipo en Elastic Security Labs publicó reportes técnicos completos sobre el compromiso. El primero cubre la cadena de ataque de extremo a extremo, el malware multiplataforma y el protocolo C2: Dentro de la cadena de suministro de Axios, compromiso - un RAT para gobernarlos todos. El segundo cubre las reglas de caza y detección en Linux, Windows y macOS: Elastic libera las detecciones para el compromiso de la cadena de suministro de Axios.
¿A dónde vamos a partir de aquí?
La situación actual no es buena y necesitamos mejorar como ecosistema de software en general, y mucho menos en la industria de la seguridad.
En dos semanas de marzo:
- Trivy (un escáner de seguridad) fue comprometido para robar secretos de CI/CD
- LiteLLM fue comprometido usando esos secretos robados
- Telnyx fue comprometida en la misma campaña
- Axios, uno de los paquetes más confiables en npm, fue comprometido por un actor sospechoso de la RPDC
- Y más
Los registros de paquetes son infraestructuras críticas. Los equipos que gestionan PyPI y npm están haciendo un gran trabajo, pero la amenaza superó lo que los modelos actuales de confianza pueden manejar. Necesitamos una mejor monitorización automatizada de los cambios de paquetes. No solo escanear firmas, sino entender realmente qué hace el código. Los LLMs son realmente buenos en esto, como demuestra este proyecto. Y necesitamos que la rotación de credenciales luego de las brechas ocurra más rápido. La cascada de Trivy a Litellm a Telnyx ocurrió porque los créditos robados no se rotaban lo suficientemente rápido.
Una cosa práctica que puedes hacer ahora mismo: no recibas actualizaciones de paquetes inmediatamente. Agrega un tiempo de remojo. Deja reposar las nuevas versiones un tiempo antes de que tus builds las adopten. Hacemos esto con nuestros sistemas CI/CD en Elastic en respuesta a shai-hulud. No lo detendrá todo, pero da tiempo a la comunidad para detectar compromisos antes de que lleguen a tus pipelines de CI/CD y a los equipos de desarrolladores. La buena noticia es que muchos gestores de paquetes agregaron soporte nativo para esto. Por ejemplo, para hacer cumplir un retraso de 7 días:
npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"Estamos abriendo el código
Estamos lanzando la herramienta: monitorización de la cadena de suministro
Quiero ser sincero. Es una prueba de concepto. La construí en una tarde sin dormir. No espero que nadie lo ejecute a nivel de producción. Requiere una subscripción a Cursor para el análisis del LLM, procesa las versiones secuencialmente y las listas de seguimiento son estáticas.
Pero el enfoque funciona. Diferenciar los lanzamientos de paquetes en tiempo real y usar IA para clasificar los cambios provocó un ataque en la cadena de suministro a uno de los paquetes más populares en npm.
Comparto esto porque es mejor para la comunidad aprender de nuestras experiencias. Si alguien toma esta idea y construye algo mejor, genial. Si un equipo de registro de paquetes lo integra en su pipeline, mejor aún. Si eso significa que alguien más tiene una gran partida la próxima vez, esto mereció la pena.
Cómo funciona (para los curiosos)
Monitorización: Dos hilos sondean PyPI (vía changelog_since_serial() XML-RPC) y npm (mediante CouchDB _changes feed). Los nuevos lanzamientos que coinciden con la lista de seguimiento de la primera N se ponen en cola. El estado insiste en last_serial.yaml para que continúe donde lo dejó.
Diferencia: Versiones antiguas y nuevas descargadas directamente desde las APIs del registro. No hay instalación de pip/npm, ni ejecución de código. Archivos extraídos, archivos hasheados, reportes diferenciales unificados generados en markdown.
Análisis: El reporte de diferencias va a la CLI del Cursor Agent en modo solo lectura. El prompt le pide que busque indicadores de la cadena de suministro. Resultados analizados para el veredicto.
Alerta: Un veredicto malicioso envía un mensaje de Slack con el nombre del paquete, rango, enlace del registro y resumen de análisis.
IA en seguridad, más allá de este proyecto
La seguridad en la cadena de suministro es un gran problema, pero no estamos impotentes. La IA nos proporciona nuevas herramientas para defendernos a gran escala y a velocidad de máquina. Este proyecto es un ejemplo de cómo se emplea IA para ayudar con un problema de seguridad, pero estuvimos haciendo mucho trabajo interesante con IA en Elastic Security en general. Una cosa que destacaría: nuestro equipo publicó recientemente una publicación sobre el uso de Detección de Ataques, Flujos de Trabajo y Constructor de Agentes para detectar y confirmar automáticamente ataques a nivel APT. Esto demuestra el poder de la Plataforma Elástica, que ofrece seguridad agente para mejorar de manera significativa la eficiencia y eficacia de tu SOC en un momento en que colectivamente estamos ahogados en ataques.
El proyecto de monitorización de la cadena de suministro está disponible en github.com/elastic/supply-chain-monitor.
Gracias al equipo de Elastic Infosec por la rápida respuesta a incidentes, a los mantenedores de axios por la rápida eliminación y a la comunidad de seguridad por el esfuerzo colectivo que limitó el radio de la explosión.