La campaña Gheist usa tokens robados de GitHub para extraer secretos de repositorios masivamente

La empresa de seguridad en la nube Wiz ha estado rastreando una campaña de ataque automatizada, a la que llamó Gheist, que usa tokens de acceso robados de GitHub para extraer sistemáticamente secretos de repositorios privados y entornos empresariales de GitHub. Wiz ha recuperado más de 13,500 ramas maliciosas plantadas en más de 850 cuentas comprometidas desde que comenzó a rastrear la campaña el 15 de septiembre de 2026, y al 24 de octubre la operación seguía activa y evolucionando.

El nombre proviene de la cadena de user agent «gheist» que la herramienta automatizada de los atacantes envía con cada solicitud a la API de GitHub, según el informe publicado el 26 de octubre por The Hacker News.

Cómo extrae secretos el ataque sin un servidor de comando

El mecanismo de Gheist está construido para no dejar nada que los atacantes puedan bloquear. Usando un token robado, la herramienta enumera cada repositorio al que ese token puede acceder. Para cada uno, crea una rama con un nombre como ci-sync- seguido de seis caracteres aleatorios, luego confirma un único archivo — .github/workflows/sync-check.yml — con el mensaje de commit inocuo «ci: sync config». El commit se deja sin firmar.

Empujar esa rama activa automáticamente el flujo de trabajo, que simplemente imprime cada variable de entorno y secreto que el job tiene permiso de leer. Para evitar el enmascaramiento automático de registros de GitHub para patrones de secretos conocidos, la herramienta codifica la salida en base32 antes de imprimirla. El atacante luego descarga el registro resultante a través de la propia API de GitHub — lo que significa que los datos robados nunca tienen que salir por un servidor externo que un defensor pueda detectar o bloquear — y borra la ejecución del flujo de trabajo segundos después de recuperarlo.

Escala y consecuencias reales

Wiz no ha revelado cuántas organizaciones tuvieron secretos realmente expuestos, pero confirma que la campaña ha tenido éxito tanto contra repositorios privados como contra implementaciones completas de GitHub Enterprise Server, no solo proyectos personales públicos.

La protección existente de GitHub solo cubre la mitad del problema

Desde el 28 de julio, GitHub requiere que un colaborador con acceso de escritura apruebe manualmente las ejecuciones de flujo de trabajo marcadas como sospechosas — un cambio que Wiz confirmó que detuvo todos los intentos de Gheist que probó contra repositorios públicos. Sin embargo, ese requisito de aprobación no se extiende a repositorios privados ni a GitHub Enterprise Server, que es exactamente donde Gheist ha tenido sus éxitos documentados.

Respuesta recomendada

Wiz recomienda que las organizaciones busquen en sus registros de auditoría ramas que coincidan con el patrón de nombres ci-sync- y revisen cualquier asunción de rol OIDC vinculada a esas ramas. Cualquier secreto accesible desde un repositorio afectado debe tratarse como comprometido y rotarse de inmediato.