Cuando las etiquetas se vuelven peligrosas: el segundo ataque a Trivy expone credenciales y secretos de CI/CD

La cadena de suministro del software volvió a demostrar su fragilidad cuando Trivy, el popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, sufrió un segundo compromiso en pocas semanas que permitió la distribución de código malicioso diseñado para robar secretos de entornos CI/CD. El incidente afectó tanto al repositorio aquasecurity/trivy-action, usado para ejecutar Trivy dentro de GitHub Actions, como a aquasecurity/setup-trivy, que facilita configurar una versión concreta del escáner en flujos de trabajo.

Según la investigación pública, el atacante logró reescribir la mayoría de las etiquetas de versión en el repositorio de la acción oficial y apuntarlas a commits maliciosos que incluían un ladrón de credenciales escrito en Python. Al modificar las tags, los atacantes convirtieron referencias de versión supuestamente confiables en un vector de distribución del malware, lo que permitió la ejecución del payload dentro de los runners de GitHub Actions y la extracción de información sensible presente en esos entornos.

El software malicioso fue diseñado para buscar y recopilar una amplia gama de secretos: variables de entorno, claves SSH, credenciales de proveedores de nube, credenciales de bases de datos, configuraciones de Docker, tokens de Kubernetes e incluso pares de claves y monederos de criptomonedas asociados con validadores de Solana. Tras recolectar esa información, el código la cifraba y trataba de enviarla a un servidor controlado por el atacante; como mecanismo de contingencia, si la exfiltración directa fallaba, el malware intentaba publicar los datos en un repositorio público bajo la cuenta de GitHub de la víctima utilizando un token robado.

Este episodio es la continuación de un incidente previo que involucró a un bot autónomo apodado hackerbot-claw, que explotó la acción pull_request_target para obtener un token de acceso personal (PAT) y luego lo utilizó para publicar versiones maliciosas y modificar la infraestructura del proyecto. La propia Aqua Security ha reconocido que, aunque se rotaron secretos y tokens tras aquella intrusión inicial, la contención no fue completa y algunos credenciales comprometidos pudieron seguir activos durante la nueva manipulación. Puede leerse más sobre la cronología y la respuesta de la compañía en la discusión oficial en GitHub: comunicado de Aqua.

Varias firmas de seguridad han analizado el código malicioso. Los informes técnicos señalan que el ladrón opera en etapas claras: primero recoge datos sensibles tanto de la memoria del proceso del runner como del sistema de archivos; a continuación cifra el material robado; y finalmente intenta transmitirlo a un dominio controlado por el atacante (identificado en los reportes como scan.aquasecurtiy[.]org) o, si eso no funciona, usa el token capturado para subir la información a un repositorio público llamado "tpcp-docs". Informes adicionales y descripciones técnicas están disponibles en blogs de investigación como los de Socket, Wiz y Step Security.

En cuanto a atribución, hay indicios que apuntan a un actor conocido en el ecosistema como TeamPCP (también identificado por varios alias). Parte del código se autodenomina "TeamPCP Cloud stealer" y elementos técnicos coinciden con herramientas previas atribuidas al grupo, aunque los investigadores señalan que esa autoadscripción podría ser un señuelo. Para un contexto más amplio sobre esta amenaza y sus tácticas en entornos cloud, Elastic Security Labs publicó material de referencia que ayuda a comprender el modus operandi de actores como TeamPCP: análisis técnico de Elastic.

Las implicaciones para proyectos y equipos que dependen de GitHub Actions son claras: las referencias a versiones o etiquetas pueden dejar de ser seguras si un actor con credenciales válidas reescribe tags o publica releases maliciosos. Por ello, expertos recomiendan evitar anclar acciones a etiquetas de versión móviles y, en su lugar, usar el SHA completo del commit para garantizar que la acción ejecutada sea exactamente la esperada. Esta recomendación técnica fue destacada por investigadores de Wiz como una defensa práctica contra el tipo de envenenamiento de tags observado.

Si administras pipelines que usarían Trivy o sus acciones asociadas, la respuesta inmediata debe ser preventiva y contundente. Aqua Security y las firmas que investigaron el incidente han sugerido comprobar que se esté usando una versión segura del software (por ejemplo, Trivy 0.69.3, trivy-action 0.35.0 y setup-trivy 0.2.6 según los comunicados), tratar cualquier secreto que pudiera haber sido accesible como comprometido y proceder a rotarlo de manera prioritaria. Además, bloquear a nivel de red el dominio de exfiltración y la dirección IP asociada (se ha mencionado 45.148.10[.]212 en los análisis) puede ayudar a mitigar intentos de transmisión de datos mientras se investiga.

Más allá de las acciones reactivas, hay lecciones organizativas importantes: los procesos de rotación de credenciales deben ser atómicos y verificables, los permisos concedidos a tokens y automatizaciones han de ser mínimos por diseño, y las revisiones de seguridad de flujos de trabajo deben incluir controles para detectar cambios inesperados en etiquetas o releases. Para comprender mejor la persistencia que el malware intentaba instalar en sistemas Linux mediante systemd, la discusión sobre este mecanismo en Red Canary aporta contexto útil sobre cómo los atacantes tratan de mantener acceso en equipos afectados: explicación sobre persistencia con systemd.

Finalmente, este caso subraya que la seguridad del software no termina al publicar código: las infraestructuras de entrega continua y las cuentas con privilegios son blanco crítico. La combinación de revisiones técnicas, prácticas de gestión de secretos, y una configuración de CI consciente de la seguridad es imprescindible para reducir el riesgo de que una dependencia legítima se convierta en una puerta trasera hacia tus secretos. Mantente atento a las actualizaciones de los mantenedores y de los laboratorios de seguridad que investigan el incidente y actúa con prudencia si tu organización pudo haber usado versiones afectadas.

Fuentes y lecturas recomendadas: el análisis de Socket sobre la nueva oleada de compromisos (Socket), el informe técnico de Wiz con detalles del malware (Wiz), el seguimiento de Step Security sobre la versión maliciosa (Step Security) y la discusión abierta de Aqua en GitHub (Aqua Security).