Trivy, un popular escáner de vulnerabilidades de código abierto mantenido por Aqua Security, se vio comprometido por segunda vez en el lapso de un mes para entregar malware que robaba secretos confidenciales de CI/CD.

El último incidente afectó a GitHub Actions» seguridad acuática/acción trivial «y» aquasecurity/setup-trivy », que se utilizan para escanear imágenes de contenedores de Docker en busca de vulnerabilidades y configurar el flujo de trabajo de GitHub Actions con una versión específica del escáner, respectivamente.

«Identificamos que un atacante empujó por la fuerza 75 de las 76 etiquetas de versión del repositorio aquasecurity/trivy-action, la GitHub Action oficial para ejecutar escaneos de vulnerabilidades de Trivy en canalizaciones de CI/CD», dijo Philipp Burckhardt, investigador de seguridad de Socket dijo . «Estas etiquetas se modificaron para que sirvieran como carga maliciosa, lo que convirtió de manera efectiva las referencias a versiones confiables en un mecanismo de distribución para un ladrón de información».

La carga útil se ejecuta en los ejecutores de GitHub Actions y tiene como objetivo extraer valiosos secretos de los desarrolladores de los entornos de CI/CD, como las claves SSH, las credenciales para los proveedores de servicios en la nube, las bases de datos, las configuraciones de Git y Docker, los tokens de Kubernetes y las carteras de criptomonedas.

adsense

El desarrollo marca el segundo incidente en la cadena de suministro que involucra a Trivy. Hacia finales de febrero y principios de marzo de 2026, apareció un bot autónomo llamado hackerbot-claw explotado un flujo de trabajo «pull_request_target» para robar un token de acceso personal (PAT), que luego se convirtió en un arma para hacerse con el control del repositorio de GitHub, eliminar varias versiones de lanzamiento e insertar dos versiones maliciosas de su extensión Visual Studio Code (VS Code) en Open VSX.

La primera señal del compromiso fue marcado del investigador de seguridad Paul McCarty tras la publicación de una nueva versión comprometida (versión 0.69.4) en el repositorio GitHub «aquasecurity/trivy». La versión falsa ha sido eliminada desde entonces. Según Mago , la versión 0.69.4 inicia tanto el servicio legítimo de Trivy como el código malicioso responsable de una serie de tareas -

  • Realice el robo de datos escaneando el sistema en busca de variables ambientales y credenciales, cifrando los datos y filtrándolos mediante una solicitud HTTP POST a scan.aquasecurtiy [.] org.
  • Configure la persistencia mediante un servicio systemd después de confirmar que se está ejecutando en una máquina de desarrollador. El servicio systemd está configurado para ejecutar un script de Python (» sysmon.py «) que sondea un servidor externo para recuperar la carga útil y ejecutarla.

En un comunicado, Itay Shakury, vicepresidente de código abierto de Aqua Security, dijo los atacantes abusaron de una credencial comprometida para publicar versiones maliciosas de trivy, trivy-action y setup-trivy. En el caso de «aquasecurity/trivy-action», el adversario empujó 75 etiquetas de versión por la fuerza para señalar las confirmaciones maliciosas que contenían la carga útil del ladrón de información de Python sin crear una nueva versión ni enviarla a una sucursal, como es práctica habitual. De la misma manera, se presionaron a la fuerza siete etiquetas «aquasecurity/setup-trivy».

«Así que en este caso, el atacante no necesitó explotar el propio Git», dijo Burckhardt a The Hacker News. «Tenían credenciales válidas con privilegios suficientes para insertar código y reescribir etiquetas, lo que provocó el envenenamiento por etiquetas que observamos. Lo que aún no está claro es la credencial exacta que se usó en este paso específico (por ejemplo, una PAT para el mantenedor o un token de automatización), pero ahora se entiende que la causa principal es que el problema de las credenciales está en peligro debido al incidente anterior».

El proveedor de seguridad también reconoció que el último ataque se debió a la contención incompleta del incidente de hackerbot-claw. «Intercambiábamos los secretos y los tokens, pero el proceso no era atómico, y es posible que los atacantes hayan tenido acceso a los tokens actualizados», explica Shakury. «Ahora estamos adoptando un enfoque más restrictivo y bloqueando todas las acciones automatizadas y cualquier token para eliminar por completo el problema».

El ladrón opera en tres etapas: recopila variables de entorno de la memoria de procesos del ejecutor y del sistema de archivos, cifra los datos y los exfiltra al servidor controlado por el atacante («scan.aquasecurtiy [.] org»).

Si el intento de exfiltración fracasa, se abusa de la propia cuenta de GitHub de la víctima para almacenar los datos robados en un repositorio público llamado «tpcp-docs» mediante el uso de la INPUT_GITHUB_PAT capturada, una variable de entorno que se usa en GitHub Actions para pasar una PAT de GitHub para la autenticación con la API de GitHub.

Actualmente no se sabe quién está detrás del ataque, aunque hay indicios de que el actor de amenazas conocido como Equipo PCP puede estar detrás de esto. Esta evaluación se basa en el hecho de que el recolector de credenciales se identifica a sí mismo como «ladrón de nubes de TeamPCP» en el código fuente. También conocido como DeadCatx3, PCPCat, PersyPCP, ShellForce y CipherForce, el grupo es conocida por actuar como una plataforma de ciberdelincuencia nativa de la nube diseñada para violar la infraestructura de nube moderna y facilitar el robo de datos y la extorsión.

enlaces

«Los objetivos de credenciales de esta carga útil son coherentes con el perfil más amplio de robo y monetización nativo de la nube del grupo», afirma Socket. «El gran énfasis que se le da a los pares de claves validadores de Solana y a los monederos de criptomonedas no está tan documentado como sello distintivo de TeamPCP, aunque coincide con las conocidas motivaciones financieras del grupo. El autoetiquetado podría ser una señal falsa, pero la superposición técnica con las herramientas anteriores de TeamPCP hace que la atribución genuina sea plausible».

Se recomienda a los usuarios que se aseguren de utilizar las últimas versiones seguras -

«Si sospechas que estás utilizando una versión comprometida, considera que todos los secretos de la canalización están comprometidos y rota de inmediato», afirma Shakury. Otras medidas de mitigación incluyen bloquear el dominio de exfiltración y la dirección IP asociada (45.148.10 [.] 212) a nivel de red, y comprobar si hay repositorios denominados «tpcp-docs» en las cuentas de GitHub, lo que puede indicar que la exfiltración se ha realizado correctamente mediante el mecanismo alternativo.

«Fija las GitHub Actions a hashes completos de SHA, no a etiquetas de versión», dijo el investigador de Wiz, Rami McCarthy. «Las etiquetas de versión se pueden mover para que apunten a confirmaciones malintencionadas, como se demostró en este ataque».

(Esta es una historia en desarrollo. Vuelva a consultar para obtener más información.)

¿Te ha parecido interesante este artículo? Síguenos en Noticias de Google , Twitter y LinkedIn para leer más contenido exclusivo que publicamos.