Gheist: tokens de GitHub robados y secretos filtrados vía Actions

📌 Novedades posteriores: Gusano testmetest: payloads de 13 MB en 42 repositorios GitHub (26 de octubre de 2026)

Una campaña llamada Gheist usa tokens de acceso de GitHub robados para que los repositorios de las víctimas ejecuten un workflow de GitHub Actions que imprime los secretos en los logs, desde donde el atacante los descarga. La descripción técnica procede del análisis de Wiz Research, recogido por Help Net Security; también han informado The Hacker News, Dark Reading, que habla de un ataque a la cadena de suministro todavía en curso contra miles de repositorios de desarrolladores, e Infosecurity Magazine, que confirma la magnitud: más de 13.500 ramas y repositorios atacados.

Qué ha pasado

Según Wiz, los investigadores han recuperado más de 13.500 ramas creadas por el atacante en repositorios de más de 850 cuentas de GitHub comprometidas. El nombre de la campaña viene del user agent que la herramienta envía en sus peticiones a la API de GitHub. Wiz no indica cómo se robaron los tokens.

El punto crítico son los repositorios privados. Desde el 28 de julio, GitHub retiene en los repositorios públicos las ejecuciones de workflows potencialmente maliciosas hasta que un colaborador las aprueba, y allí el ataque queda bloqueado. Ese control no se aplica a los repositorios privados ni a GitHub Enterprise Server: según Wiz, los registros de auditoría de GitHub muestran ejecuciones en las ramas del atacante que se completan y luego son borradas por el user agent de Gheist. Entre los secretos expuestos están los de los environments, que a menudo son credenciales de producción.

Cómo funciona el ataque

La cadena descrita por Wiz es corta y se queda por completo dentro de GitHub:

1. la herramienta toma un token robado y enumera todos los repositorios a los que ese token tiene acceso;
2. en cada uno crea una rama llamada ci-sync- seguida de seis caracteres aleatorios y añade un pequeño workflow llamado sync-check;
3. el push de la rama inicia el workflow automáticamente; el workflow tiene una única tarea: escribir los secretos del repositorio en el log de la ejecución;
4. para eludir el enmascaramiento de secretos de GitHub, que solo reconoce un secreto si aparece tal como se guardó, cada valor se codifica en base32 y termina completo en el log;
5. la herramienta descarga el log mediante la API de GitHub y borra la ejecución pocos segundos después.

No hay un servidor del atacante: los secretos salen a través de la API de GitHub, así que no existe un dominio externo ni una conexión que bloquear. Borrar la ejecución y la rama, sin embargo, no anula la exposición.

Wiz ha observado dos variantes de la herramienta. Desde el 19 de octubre, una de ellas añade un segundo job dirigido a los runners self-hosted: busca tokens y claves en la máquina y usa Docker para llegar a los archivos del host.

En las organizaciones enterprise, la herramienta pasó en pocos minutos por los tokens de varios usuarios y cuentas de automatización, y clonó los repositorios privados antes de insertar el workflow. Horas después, credenciales cloud de la misma organización se usaron para enumerar AWS Secrets Manager; Wiz no dice cómo se obtuvieron. En los registros de CloudTrail de las víctimas aparecen los workflows de las propias organizaciones ejecutándose en ramas ci-sync- mientras asumían roles de AWS: la prueba de que Actions se ejecutó sin ninguna aprobación.

Las mismas cuentas las usan también otros grupos: el 6 de octubre, 391 cuentas renombraron unos 1.461 repositorios como señuelos de software crackeado (166 de esas cuentas nunca aparecen en la actividad de Gheist), y el 18 de octubre 25 cuentas de Gheist crearon cada una un repositorio «Windows RDP Runner» en nueve minutos.

En nuestra lectura, las técnicas MITRE ATT&CK pertinentes son T1078 (Valid Accounts), T1213.003 (Code Repositories), T1027 (Obfuscated Files or Information) por la codificación en base32, T1567 (Exfiltration Over Web Service), T1070 (Indicator Removal) por el borrado de las ejecuciones y T1555.006 (Cloud Secrets Management Stores) por la enumeración de AWS Secrets Manager.

Impacto para las empresas europeas e italianas

Muchas empresas europeas tienen su código y sus pipelines de publicación en GitHub, a menudo en repositorios privados con secretos de environment que dan acceso a la nube, a registros de contenedores y a bases de datos de producción. Basta un solo token de un desarrollador o de una cuenta de automatización para exponer los secretos de todos los repositorios a los que llega. Para las entidades sujetas a NIS2, la seguridad del desarrollo y de la cadena de suministro es una de las medidas exigidas: el uso de credenciales de producción exfiltradas debe valorarse también como posible incidente notificable.

Qué hacer ahora

1. Busca rastros en los registros de auditoría de GitHub: el user agent de Gheist, la creación de ramas ci-sync-*, workflows sync-check y ejecuciones borradas justo después de terminar.
2. Revisa los registros de la nube: si tus workflows se autentican con OIDC, busca asunciones de rol cuyo subject contenga una rama ci-sync-. Según Wiz, es la prueba de que Actions se ejecutó en una rama del atacante, aunque no recojas los registros de GitHub.
3. Rota todos los secretos disponibles para un repositorio afectado: de repositorio, de organización y de environment. Revoca los tokens que hicieron los push, como recomienda Wiz.
4. Revisa los runners self-hosted: arranques de contenedores con acceso al sistema de archivos del host y credenciales presentes en la máquina desde el 19 de octubre.
5. Reduce la superficie de ataque (recomendaciones nuestras): limita las políticas de confianza OIDC a ramas o environments concretos, protege los environments con reglas sobre las ramas de publicación y revisores obligatorios, usa tokens con permisos mínimos y caducidad corta, y valora reglas que impidan modificar los archivos de los workflows a quien no deba hacerlo.

Cómo ayuda ARXDOME

El agente de ARX Sentry recoge logs, eventos e inventario de procesos de servidores Linux, Windows y macOS, incluidos los que se usan como runners self-hosted: ayuda a detectar arranques inusuales de contenedores y procesos en la máquina. Con ARX Trace, nuestros analistas pueden lanzar recopilaciones y búsquedas en varias máquinas para comprobar qué se ha tocado, y ARX Shield permite aislar de la red un runner sospechoso mientras se rotan los secretos.

Última actualización: 27 de octubre de 2026