Trivy, un popular escáner de vulnerabilidades de código libre mantenido por Aqua Security, se vio comprometido por segunda vez en el curso de un mes para entregar malware que robaba secretos confidenciales de CI/CD.
El postrero incidente afectó a las acciones de GitHub “aquasecurity/trivy-action” y “aquasecurity/setup-trivy”, que se utilizan para escanear imágenes del contenedor Docker en indagación de vulnerabilidades y configurar el flujo de trabajo de GitHub Actions con una traducción específica del escáner, respectivamente.
“Identificamos que un atacante forzó 75 de 76 etiquetas de traducción en el repositorio aquasecurity/trivy-action, la movimiento oficial de GitHub para ejecutar observación de vulnerabilidades de Trivy en canales de CI/CD”, dijo el investigador de seguridad de Socket, Philipp Burckhardt. “Estas etiquetas se modificaron para servir una carga maliciosa, convirtiendo efectivamente las referencias de versiones confiables en un mecanismo de distribución para un carero de información”.
La carga útil se ejecuta adentro de los ejecutores de GitHub Actions y tiene como objetivo extraer valiosos secretos de desarrollador de entornos CI/CD, como claves SSH, credenciales para proveedores de servicios en la montón, bases de datos, Git, configuraciones de Docker, tokens de Kubernetes y billeteras de criptomonedas.
Este hecho marca el segundo incidente en la sujeción de suministro que involucra a Trivy. En dirección a finales de febrero y principios de marzo de 2026, un autómata autónomo llamado hackerbot-claw aprovechó un flujo de trabajo “pull_request_target” para robar un token de camino personal (PAT), que luego se utilizó como pertrechos para tomar el control del repositorio de GitHub, eliminar varias versiones de emanación y remitir dos versiones maliciosas de su extensión Visual Studio Code (VS Code) a Open VSX.
La primera señal del compromiso fue señalada por el investigador de seguridad Paul McCarty luego de que se publicara una nueva traducción comprometida (traducción 0.69.4) en el repositorio de GitHub “aquasecurity/trivy”. Desde entonces, la traducción fraudulenta ha sido eliminada. Según Wiz, la traducción 0.69.4 inicia tanto el servicio razonable Trivy como el código bellaco responsable de una serie de tareas:
- Realice el robo de datos escaneando el sistema en indagación de variables ambientales y credenciales, cifrando los datos y extrayéndolos a través de una solicitud HTTP POST a scan.aquasecurtiy(.)org.
- Configure la persistencia utilizando un servicio systemd luego de confirmar que se está ejecutando en una máquina de desarrollador. El servicio systemd está configurado para ejecutar un script Python (“sysmon.py”) que sondea un servidor foráneo para recuperar la carga útil y ejecutarla.
En una exposición, Itay Shakury, vicepresidente de código libre de Aqua Security, dijo que los atacantes abusaron de una credencial comprometida para imprimir versiones maliciosas de trivy, trivy-action y setup-trivy. En el caso de “aquasecurity/trivy-action”, el adversario impulsó 75 etiquetas de traducción para señalar las confirmaciones maliciosas que contienen la carga útil del robo de información de Python sin crear una nueva traducción ni remitir a una rama, como es la ejercicio normalizado. Se forzaron siete etiquetas de “aquasecurity/setup-trivy” de la misma forma.
“Entonces, en este caso, el atacante no necesitaba explotar Git”, dijo Burckhardt a The Hacker News. “Tenían credenciales válidas con privilegios suficientes para remitir código y reescribir etiquetas, que es lo que permitió el envenenamiento de etiquetas que observamos. Lo que no está claro es la credencial exacta utilizada en este paso específico (por ejemplo, un PAT de mantenimiento frente a un token de automatización), pero ahora se entiende que la causa principal es el compromiso de credenciales transferido del incidente aludido”.
El proveedor de seguridad todavía reconoció que el postrero ataque se debió a una contención incompleta del incidente del hackerbot-claw. “Rotamos secretos y tokens, pero el proceso no fue atómico y es posible que los atacantes hayan estado al tanto de los tokens actualizados”, dijo Shakury. “Ahora estamos adoptando un enfoque más restrictivo y bloqueando todas las acciones automatizadas y cualquier token para eliminar completamente el problema”.
El carero opera en tres etapas: vendimia variables de entorno de la memoria del proceso del ejecutor y del sistema de archivos, monograma los datos y los extrae al servidor controlado por el atacante (“scan.aquasecurtiy(.)org”).
Si el intento de exfiltración descompostura, se abusa de la propia cuenta de GitHub de la víctima para juntar los datos robados en un repositorio conocido llamado “tpcp-docs” mediante el uso del INPUT_GITHUB_PAT capturado, una variable de entorno utilizada en GitHub Actions para acaecer 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 TeamPCP puede estar detrás. Esta evaluación se plinto en el hecho de que el recolector de credenciales se autoidentifica como “carero de nubes de TeamPCP” en el código fuente. Todavía conocido como DeadCatx3, PCPcat, PersyPCP, ShellForce y CipherForce, el clase es conocido por desempeñarse como una plataforma de cibercrimen nativa de la montón diseñada para violar la infraestructura moderna de la montón y suministrar el robo de datos y la perjuicio.
“Los objetivos de credenciales en esta carga útil son consistentes con el perfil más amplio de robo y monetización nativo de la montón del clase”, dijo Socket. “El robusto afectación en los pares de claves del validador de Solana y las billeteras de criptomonedas está menos documentado como un sello distintivo de TeamPCP, aunque se alinea con las motivaciones financieras conocidas del clase. El autoetiquetado podría ser una bandera 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 sospecha que estaba ejecutando una traducción comprometida, trate todos los secretos del canal como comprometidos y rótelos inmediatamente”, dijo Shakury. Los pasos de mitigación adicionales incluyen aislar el dominio de exfiltración y la dirección IP asociada (45.148.10(.)212) a nivel de red y repasar las cuentas de GitHub en indagación de repositorios denominados “tpcp-docs”, lo que puede indicar una exfiltración exitosa a través del mecanismo de reserva.
“Fije las acciones de GitHub a hashes SHA completos, no a etiquetas de traducción”, dijo el investigador de Wiz, Rami McCarthy. “Las etiquetas de traducción se pueden mover para señalar confirmaciones maliciosas, como se demuestra en este ataque”.
(Esta es una historia en ampliación. Vuelva a consultarla para obtener más detalles).
