Trivy bajo ataque la cadena de suministro expone credenciales en pipelines

Hace apenas unos días la comunidad de desarrolladores y equipos de seguridad recibió una noticia inquietante: el popular escáner de seguridad Trivy fue utilizado como vector en un ataque de la cadena de suministro. Investigadores y la propia proyecto confirmaron que una versión oficial del software y varias acciones de GitHub relacionadas fueron troceadas para incluir un malware diseñado para robar credenciales y persistir en sistemas comprometidos.

El descubrimiento inicial llegó de la mano del investigador Paul McCarty, que alertó sobre una versión backdoor de Trivy (v0.69.4). Análisis técnicos posteriores de grupos especializados, entre ellos Socket y Wiz, detallaron cómo los atacantes no solo publicaron un binario troceado en la release, sino que también comprometieron el proceso de build en GitHub Actions y alteraron las etiquetas del repositorio aquasecurity/trivy-action, redirigiendo casi todas las etiquetas de versión a commits maliciosos.

Según los investigadores, el actor responsable (vinculado a un grupo conocido como TeamPCP, también rastreado como DeadCatx3 o PCPcat) explotó credenciales que habían sido exfiltradas en un incidente anterior en marzo. Con acceso de escritura al repositorio, los atacantes forzaron actualizaciones de tags: en concreto, se reportó que se reescribieron 75 de 76 etiquetas del repositorio trivy-action, de modo que flujos externos que referenciaban esas etiquetas ejecutaron código malicioso antes de correr los análisis legítimos de Trivy.

La muestra desplegada actuaba como un infostealer centrado en localizar secretos. En entornos de CI/CD el script malicioso rastreaba información de reconocimiento del runner y escaneaba regiones de memoria del proceso GitHub Actions Runner.Worker buscando cadenas JSON que definieran secretos (patrones del tipo que contienen "isSecret":true). En máquinas de desarrollador, el binario troceado recopilaba variables de entorno, examinaba ficheros locales en busca de credenciales y enumeraba interfaces de red. Los análisis muestran que el malware buscaba claves SSH, archivos de configuración de Git, tokens de servicios cloud (AWS, GCP, Azure), ficheros .env, credenciales de bases de datos, configuraciones de CI/CD como Jenkins o Terraform, llaves TLS, historiales de shell y hasta carteras de criptomonedas.

Los datos recopilados eran empaquetados y cifrados en un archivo llamado tpcp.tar.gz para luego intentar su exfiltración a un servidor de mando y control con un dominio intencionalmente tipeado (typosquat) scan.aquasecurtiy[.]org. Si la exfiltración directa fallaba, el malware usaba una ruta de escape ingeniosa: creaba un repositorio público en la cuenta de GitHub de la víctima llamado tpcp-docs y subía allí los datos robados. Para lograr persistencia local también dejaba un payload en ~/.config/systemd/user/sysmon.py y lo registraba como servicio de systemd que consultaba remotos para descargar cargas adicionales.

Una pista directa en el propio código permitió a los equipos de análisis ligar la campaña a TeamPCP: uno de los payloads Python contenía un comentario final que se auto-identificaba como “TeamPCP Cloud stealer”, y las tácticas que aprovechan infraestructuras mal configuradas o tokens robados encajan con actividades ya documentadas para ese actor, según los investigadores de Socket. Los equipos de Aqua Security corroboraron públicamente que la intrusión fue posible debido a que la contención del incidente anterior fue incompleta y que, aunque se rotaron secretos, el proceso no garantizó que los tokens renovados no hubieran sido interceptados. Puede consultarse la declaración de la organización en su hilo de discusión oficial en GitHub: Aqua Security - discusión.

En cuanto a ventanas temporales, la release maliciosa de Trivy (v0.69.4) estuvo disponible públicamente durante aproximadamente tres horas, mientras que las etiquetas comprometidas de GitHub Actions permanecieron activas hasta doce horas en algunos casos, tiempo suficiente para que numerosos pipelines ejecutaran el código troceado inadvertidamente. Ante esto, las recomendaciones de los equipos forenses fueron contundentes: las organizaciones que utilizaron las versiones afectadas durante el periodo del incidente deberían considerarse totalmente comprometidas, rotar de inmediato todas las claves, tokens y contraseñas, y realizar análisis exhaustivos de los sistemas para detectar movimientos laterales o presencia persistente.

El alcance del problema no se limitó a Trivy. Investigadores de Aikido vincularon al mismo actor con una campaña secundaria basada en un gusano autorreplicante llamado CanisterWorm que ataca el ecosistema npm. Ese malware roba tokens de npm y automatiza la publicación de actualizaciones maliciosas en paquetes de usuarios comprometidos, propagándose con extrema rapidez: en pruebas se observó cómo retomaba proyectos y publicaba cargas en docenas de paquetes en menos de un minuto. Para la distribución de cargas adicionales utiliza un mecanismo de dead-drop basado en canisters de la red Internet Computer (ICP), lo que hace la infraestructura de mando y control más resistente a las interrupciones, ya que esos canisters solo pueden ser eliminados por su controlador mediante un proceso de gobernanza de la propia red. Más detalles técnicos sobre este vector están disponibles en el análisis de Aikido y en el panel de canisters de ICP: Internet Computer – canisters.

La campaña combina dos tendencias peligrosas que venimos observando en los últimos años: la víctima preferida son herramientas que se ejecutan con frecuencia en pipelines y entornos de desarrollo —es decir, puntos con acceso a secretos sensibles— y el uso de infraestructuras descentralizadas o poco convencionales para ocultar y robustecer la operativa del atacante. El resultado es un ataque que puede permanecer invisible durante la fase de ejecución (porque el binario troceado se ejecuta como parte del workflow legítimo) y que puede escalar rápidamente a otros repositorios o paquetes una vez que consigue tokens válidos.

Si gestionas pipelines, repositorios o entornos cloud, conviene tomar varias acciones con carácter inmediato. Revisa si tu organización ejecutó Trivy v0.69.4 o referencias a etiquetas comprometidas del repositorio trivy-action durante las ventanas indicadas. Revoca y vuelve a emitir credenciales y tokens, no solo en los servicios cloud sino también en gestores de paquetes y en cuentas de GitHub. Audita los runners y las máquinas de desarrollo en busca de persistencia (por ejemplo ~/.config/systemd/user/sysmon.py u otros servicios desconocidos), busca repositorios públicos llamados similitudes a tpcp-docs en cuentas propias o de colaboradores, y analiza logs para identificar exfiltraciones o accesos inusuales. Para orientarse en la mitigación y obtener información técnica adicional pueden consultarse los informes de los análisis: el reporte de Socket, el blog de Wiz y la discusión de Aqua Security.

Este incidente vuelve a subrayar que las herramientas de seguridad también son objetivos valiosos para los atacantes: su presencia en pipelines y su capacidad para acceder a artefactos o secretos las convierten en vectores privilegiados si son comprometidas. Mantener procesos atómicos y verificables para rotación de claves, aplicar firma de artefactos y reproducibilidad en builds, aislar runners y minimizar el uso de credenciales de amplio alcance en pipelines son medidas que reducen el riesgo, pero no eliminan la necesidad de respuesta rápida y la suposición prudente de compromiso cuando ocurren brechas de este tipo.

Para quien quiera profundizar en los análisis originales, aquí están las fuentes técnicas citadas en este reportaje: el aviso inicial de Paul McCarty en LinkedIn (enlace), el análisis de Socket (enlace), el reporte de Wiz (enlace), la discusión oficial de Aqua Security en GitHub (enlace) y el análisis sobre CanisterWorm de Aikido (enlace).