Campaña GhostAction compromete cuentas de mantenedores e inserta workflows para exfiltrar secretos

Investigadores de seguridad han vuelto a detectar una campaña masiva de robo de credenciales que explota cuentas de mantenedores de proyectos open source para insertar flujos de trabajo maliciosos en repositorios de GitHub. Según varios informes técnicos —entre ellos los de StepSecurity, Socket y GitGuardian—, atacantes vinculados a la campaña conocida como GhostAction comprometieron cuentas de mantenedores reputados y empujaron un archivo de workflow que extrae secretos a un servidor controlado por el operador. Los hechos confirmados incluyen compromisos documentados en múltiples ventanas temporales (por ejemplo, 27 repositorios a las 13:20 UTC por la cuenta de Takashi Kitao y 318 repositorios en 16 minutos por la cuenta de Henry Wu) y la detección de cientos de cuentas y miles de secretos exfiltrados en el periodo reportado.

La técnica no es una vulnerabilidad en GitHub en sí misma, sino un abuso de las credenciales de mantenedor (probablemente tokens de acceso personal, PAT) para modificar la rama por defecto de proyectos y añadir un workflow que se ejecuta con los permisos del repositorio. El archivo malicioso se presenta con nombres legítimos como "security-audit.yml" o "github_actions_security.yml" y realiza cuatro tareas claves durante su paso "Audit": agrega los secretos nombrados del repositorio, busca en el árbol de trabajo patrones de credenciales (13 patrones asociados a AWS, proveedores de IA, registries y servicios en la nube), escanea todo el historial git para credenciales previamente comprometidas y empareja IDs de acceso de AWS con sus secret access keys. Los datos recolectados se envían por HTTP a una IP dura (193.32.204[.]199), lo que confirma exfiltración de secretos sin cifrado.

Qué está comprobado: múltiples firmas de seguridad han observado el mismo flujo de ataque; los workflows maliciosos activan workflow_dispatch y se ejecutan tras pushes sin filtros, usan fetch-depth: 0 para acceder al historial, y exfiltran tokens y claves de servicios como PyPI, npm, DockerHub, AWS, OpenAI, Anthropic, OpenRouter y tokens de GitHub/GitLab. Informes públicos señalan cifras concretas: Socket detectó más de 500 cuentas que han hecho commits del workflow desde el 7 de octubre de 2026 y, en un barrido previo, GitGuardian informó de 772 repositorios públicos afectados entre el 31 de agosto y el 30 de septiembre de 2026; otro recuento cita 817 repositorios comprometidos y 3.325 secretos exfiltrados.

Qué se infiere pero no está totalmente comprobado: la fuente exacta de las credenciales usadas para tomar las cuentas —el análisis apunta a tokens filtrados en logs de info-stealers o dump de credenciales—; aunque esta hipótesis encaja con patrones anteriores de GhostAction, no hay un rastreo público que demuestre la cadena completa desde el robo inicial del PAT hasta el commit malicioso en cada cuenta afectada. Tampoco hay evidencia pública, por ahora, de paquetes maliciosos publicados en registries con credenciales robadas —aunque sí se ha documentado la modificación de una imagen Docker para incluir un miner en al menos un caso.

El impacto práctico para proyectos y organizaciones es directo: cualquier secreto presente en el repositorio (ya sea en variables de Actions, en ficheros del árbol de trabajo o en commits antiguos) puede ser leído y exfiltrado, y con ello se abren vectores para comprometer infraestructuras de CI/CD, registries, servicios cloud y cuentas de desarrolladores. Además, el uso de la propia identidad del mantenedor para insertar la carga hace más difícil distinguir la actividad maliciosa de cambios legítimos en revisiones superficiales, y la presencia del workflow en forks y espejos (incluyendo forks privados) amplifica la superficie de exposición. Socket alertó que muchos forks en el namespace de una de las cuentas afectadas seguían portando la definición maliciosa, lo que permite ejecución adicional si Actions está habilitado.

Para desarrolladores y administradores de repositorios la respuesta debe ser inmediata y práctica. Primero, comprobar si existe en cualquier rama (incluida la por defecto) un archivo llamado "security-audit.yml" o "github_actions_security.yml" o cualquier workflow sospechoso añadido desde el 31 de agosto de 2026; si aparece, asumir compromiso. Eliminar el archivo malicioso de todas las ramas no es suficiente por sí solo: es necesario revocar la credencial comprometida (PAT), rotar cualquier clave o token que pudiera haber estado en el repositorio (PyPI, npm, DockerHub, AWS, servicios de IA, GitHub/GitLab, y otros listados en los informes) y regenerar accesos. También conviene inspeccionar forks y mirrors —los forks públicos y privados pueden heredar el workflow y ejecutar envíos posteriores— y deshabilitar GitHub Actions en repositorios que no lo requieran.

En términos operativos, revisar el historial de Actions runs para identificar ejecuciones inusuales (workflow_dispatch invocados externamente, ejecuciones provocadas por pushes de cuentas comprometidas), y auditar los registros de red y de CI para detectar conexiones salientes hacia direcciones sospechosas (por ejemplo, la IP observada 193.32.204[.]199) ayudará a acotar alcance. Ejecutar búsquedas de patrones de credenciales en el árbol y en el historial git es crítico: dado que el workflow hace fetch-depth: 0, el adversario tuvo acceso al historial completo. Para buscar secretos involuntarios se pueden usar herramientas de escaneo como las que ofrece GitHub (secret scanning) y productos de terceros especializados en detección de secretos en repositorios; GitHub documenta sus capacidades de secret scanning en su sitio oficial.

Medidas concretas recomendadas: 1) Revocar y rotar inmediatamente PATs, claves de servicios y tokens listados; 2) eliminar el workflow malicioso en todas las ramas y forks, y deshabilitar Actions hasta confirmar limpieza; 3) activar o revisar políticas de aprobación para workflows externos y bloquear ejecución automática de workflows no verificados; 4) habilitar secret scanning y alerts de seguridad en la organización; 5) revisar y auditar logs de CI/CD y tráfico saliente hacia IPs/hosts no reconocidos; 6) forzar 2FA y revisar sesiones y aplicaciones autorizadas en las cuentas de mantenedores; 7) tratar como comprometidos los repositorios privados que puedan contener credenciales y rotar claves asociadas.

Para orientar incidentes y mitigaciones, documentación oficial sobre Actions y secret scanning puede consultarse en los recursos de GitHub (https://docs.github.com/en/actions y https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning). También es útil seguir análisis de terceros como los de GitGuardian, que centralizan indicadores y detecciones públicas (https://www.gitguardian.com/). Tener estos procedimientos estandarizados en runbooks de respuesta a incidentes reduce el tiempo de exposición y facilita la revocación ordenada de credenciales.

Lo cierto es que este episodio subraya un principio recurrente en seguridad de la cadena de suministro: las cuentas humanas con permisos amplios son vectores de alto impacto. Mientras se investiga la escala total y la procedencia de los tokens usados, los mantenedores de proyectos deben asumir que la mera presencia de un workflow sospechoso implica exfiltración posible y actuar con rotación de credenciales y revocación de accesos. Las defensas eficaces combinan prevención (limitación de permisos, políticas de revisión de workflows), detección (secret scanning, monitorización de Actions) y respuesta rápida (rotación y limpieza), y en este caso concreto son las únicas medidas que cortan el acceso del atacante a los secretos ya replicados.