Trivy, un popular escáner de vulnerabilidades de código abierto administrado por Aqua Security, se ha visto comprometido por segunda vez en menos de un mes para distribuir malware que roba secretos confidenciales de CI/CD.
El último incidente afectó a las acciones de GitHub ‘aquasecurity/trivy-action’ y ‘aquasecurity/setup-trivy’. Estos se utilizan para escanear imágenes del contenedor Docker en busca de vulnerabilidades y configurar flujos de trabajo de GitHub Actions con versiones específicas del escáner, respectivamente.
«Observamos que el atacante impulsó 75 de las 76 etiquetas de versión en el repositorio aquasecurity/trivy-action, que es la acción oficial de GitHub para ejecutar análisis de vulnerabilidades de Trivy en canales de CI/CD», dijo el investigador de seguridad de socket Philipp Burckhardt. «Estas etiquetas se han modificado para entregar cargas maliciosas, convirtiendo efectivamente las referencias de versiones confiables en un mecanismo de distribución para los ladrones de información».
La carga útil se ejecuta dentro del ejecutor de GitHub Actions y está destinada a extraer valiosos secretos de desarrollador del entorno CI/CD, como claves SSH, credenciales de proveedores de servicios en la nube, bases de datos, Git, configuraciones de Docker, tokens de Kubernetes y billeteras de criptomonedas.
Este es el segundo incidente en la cadena de suministro que involucra a Tribee. A finales de febrero y principios de marzo de 2026, un robot autónomo llamado hackerbot-claw aprovechó el flujo de trabajo «pull_request_target» para robar tokens de acceso personal (PAT), que fueron utilizados como arma para tomar el control de los repositorios de GitHub, eliminar varias versiones de lanzamiento e insertar dos versiones maliciosas de extensiones de Visual Studio Code (VS Code) en Open VSX.
El primer indicio de una infracción fue informado por el investigador de seguridad Paul McCarty después de que se publicara una nueva versión comprometida (versión 0.69.4) en el repositorio de GitHub «aquasecurity/trivy». Desde entonces, la versión no autorizada ha sido eliminada. Según Wiz, la versión 0.69.4 inicia tanto el servicio legítimo Trivy como el código malicioso que realiza una serie de tareas.
Realiza el robo de datos escaneando sistemas para obtener variables de entorno y credenciales, cifrando datos y extrayendo datos a través de solicitudes HTTP POST a scan.aquasecurtiy(.)org. Después de asegurarse de que se esté ejecutando en la máquina del desarrollador, configure la persistencia utilizando el servicio systemd. El servicio systemd está configurado para ejecutar un script Python (‘sysmon.py’) que sondea un servidor externo para recuperar la carga útil y ejecutarla.
Itay Shakury, vicepresidente de código abierto de Aqua Security, dijo en un comunicado que los atacantes explotaron las credenciales filtradas para publicar versiones maliciosas de Tribby, Tribby Action y Setup Tribby. En el caso de «aquasecurity/trivy-action», el atacante impulsó una etiqueta de versión 75 que apuntaba a una confirmación maliciosa que contenía una carga útil de robo de información de Python, sin crear una nueva versión ni enviar a una rama, como es la práctica estándar. Se forzaron siete etiquetas de «aquasecurity/setup-trivy» de la misma manera.
«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 enviar el código y reescribir las etiquetas, que es lo que permitió el envenenamiento de etiquetas que observamos. Lo que se desconoce son las credenciales exactas utilizadas en este paso en particular (por ejemplo, PAT de mantenimiento y tokens de automatización), pero actualmente se entiende que la causa principal son las credenciales comprometidas transferidas de un incidente anterior».
El proveedor de seguridad también reconoció que el último ataque se debió a una contención incompleta del incidente de la garra del hackerbot. «Rotamos los secretos y los tokens, pero el proceso no fue atómico, por lo que el atacante podría haber obtenido tokens actualizados», dijo Shakri. «Ahora estamos adoptando un enfoque más restrictivo, bloqueando todas las acciones automatizadas y todos los tokens para eliminar por completo el problema».
El ladrón opera en tres etapas: recopila variables de entorno de la memoria del proceso ejecutor y del sistema de archivos, cifra los datos y los filtra a un servidor controlado por el atacante (‘scan.aquasecurtiy(.)org’).
Si el intento de exfiltración falla, se explota la propia cuenta de GitHub de la víctima y los datos robados se almacenan en un repositorio público llamado ‘tpcp-docs’ utilizando el INPUT_GITHUB_PAT capturado. INPUT_GITHUB_PAT es una variable de entorno utilizada por GitHub Actions para pasar GitHub PAT para la autenticación con la API de GitHub.
Actualmente no está claro quién está detrás del ataque, pero hay indicios de que un actor de amenazas conocido como TeamPCP podría estar detrás. Esta evaluación se basa en el hecho de que el recolector de credenciales se autoidentifica en su código fuente como un «ladrón de nubes de TeamPCP». El grupo, también conocido como DeadCatx3, PCPcat, PersyPCP, ShellForce y CipherForce, es conocido por operar como una plataforma de cibercrimen nativa de la nube diseñada para infiltrarse en la infraestructura moderna de la nube para facilitar el robo de datos y la extorsión.
«La orientación de credenciales en esta carga útil es consistente con el perfil más amplio de monetización y robo nativo de la nube del grupo», dijo Socket. «El enfoque en los pares de claves del validador de Solana y las billeteras de criptomonedas es una característica menos documentada de TeamPCP, pero es consistente con los motivos financieros conocidos del grupo. Si bien el autoetiquetado puede ser una bandera falsa, 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 la última versión segura.
«Si sospecha que está ejecutando una versión comprometida, trate todos los secretos del canal como comprometidos y rótelos inmediatamente», dijo Shakri. Los pasos de mitigación adicionales incluyen bloquear el dominio filtrado y la dirección IP asociada (45.148.10(.)212) a nivel de red y verificar la cuenta de GitHub en busca de un repositorio llamado ‘tpcp-docs’ que pueda indicar una exfiltración exitosa a través de un mecanismo alternativo.
El investigador de Wiz, Rami McCarthy, dice: «Fije las acciones de GitHub a hashes SHA completos en lugar de etiquetas de versión». «Como se demostró en este ataque, las etiquetas de versión se pueden mover para señalar confirmaciones maliciosas».
(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).
Source link
