Gheist usa tokens robados para volcar secretos de GitHub Actions

Un token basta para convertir un workflow en salida de secretos

Wiz Research lleva el seguimiento de Gheist desde el 15 de septiembre. La campaña reutiliza tokens de acceso de GitHub comprometidos para plantar workflows en cada repositorio que alcanzan; su objetivo es imprimir secretos disponibles para el job en los registros de GitHub Actions y descargarlos mediante la propia API. Wiz atribuye el nombre al user agent gheist que acompaña las peticiones del operador.

El implante crea una rama ci-sync- seguida de seis caracteres aleatorios y añade .github/workflows/sync-check.yml con el mensaje ci: sync config. El push inicia GitHub Actions, la automatización que ejecuta los jobs del repositorio. El workflow vuelca variables y secretos en formato base32, una codificación que hace que el valor ya no coincida literalmente con la cadena que GitHub intenta enmascarar en los logs.

-SecureCrew dice: permissions: {} puede dejar al GITHUB_TOKEN con muy poco margen y, aun así, el job leer los secretos que ya le han entregado; el permiso equivocado no siempre es el que destaca en pantalla.-

Cuando obtiene el registro, el operador lo descarga con la API de GitHub y elimina la ejecución segundos después. La salida viaja por la plataforma que ya usa el equipo: bloquear un dominio de mando externo no detiene un flujo que no necesita contactar con uno. En algunos repositorios, el workflow también recorre los entornos de despliegue y vuelca secretos de producción accesibles para el job.

Wiz recuperó más de 13.500 ramas plantadas desde más de 850 cuentas comprometidas. Esas cifras describen lo que su equipo encontró, no un recuento de organizaciones afectadas ni de secretos que acabaran en manos del actor. En organizaciones empresariales, Wiz observó tokens de varios usuarios y cuentas de automatización utilizados con pocos minutos de diferencia para clonar repositorios privados y plantar el workflow.

La aprobación automática no cubre todos los repositorios

Desde el 28 de julio, GitHub retiene para aprobación ciertos workflows sospechosos antes de ejecutarlos. El cambio de GitHub se aplica a repositorios públicos alojados en github.com; no se extiende a repositorios privados ni a GitHub Enterprise Server. Wiz dice que todos los workflows públicos de Gheist que revisó seguían pendientes de aprobación y no habían ejecutado su carga.

-SecureCrew dice: una protección que funciona en la vitrina pública sigue siendo útil, pero conviene leer la etiqueta de cobertura antes de dar por protegida toda la organización.-

En repositorios privados y GitHub Enterprise Server, Wiz encontró registros de ejecuciones sobre ramas ci-sync-* que terminaron y se borraron después. Los eventos de AWS CloudTrail mostraron workflows propios asumiendo roles de AWS desde esas ramas, una señal de que Actions llegó a ejecutarse sin que se aprobara ese flujo. El informe no cifra cuántas organizaciones tuvieron secretos expuestos ni atribuye cada evento posterior a una misma persona.

El 19 de octubre apareció además una variante dirigida a runners autogestionados, máquinas que la organización mantiene para procesar jobs. El job intentaba buscar credenciales y archivos sensibles en esos hosts, pero Wiz lo describió como defectuoso y no reportó ejecuciones exitosas de esa parte. Esa limitación reduce lo observado hasta ahora; no convierte en inocua una rama de Gheist que sí haya ejecutado workflows en otro entorno.

Qué buscar y qué hacer si aparece

El primer filtro es revisar ramas ci-sync- con seis caracteres y comprobar si solo incorporan .github/workflows/sync-check.yml con el commit ci: sync config. En los registros de auditoría, busca ejecuciones borradas poco después de completarse y actividad del user agent gheist; si usas OIDC para dar acceso a la nube, Wiz recomienda revisar asunciones de rol cuyo sujeto incluya una de esas ramas.

Encontrar una rama no se resuelve borrándola: la ejecución puede haber impreso valores antes de desaparecer. Revoca el token que publicó el commit y rota los secretos de repositorio, organización y entorno que ese job podía leer. Si la ejecución alcanzó un runner autogestionado, Wiz recomienda tratar ese host y su rol de instancia como comprometidos. La revisión debe seguir el alcance real de cada job y cada entorno, no el nombre que aparece en la lista de secretos.

Para reducir el valor de un token robado, Wiz recomienda exigir revisores en entornos con credenciales de producción, limitar la confianza OIDC a ramas o entornos protegidos y preferir GitHub Apps o tokens de corta duración frente a tokens personales amplios. Los runners propios también necesitan aislamiento: máquinas efímeras y sin acceso abierto al socket de Docker o a metadatos de cloud reducen lo que un job malicioso puede alcanzar.

-SecureCrew dice: borrar la rama limpia el árbol de Git; no hace que el secreto que pasó por el log vuelva a su caja.-

Diccionario de la Crew

Token de acceso — Credencial que permite a una cuenta o automatización actuar ante una API; su alcance depende de los permisos y repositorios a los que da acceso.

GitHub Actions — Servicio de GitHub que ejecuta workflows asociados a eventos del repositorio, como publicar una rama.

Base32 — Codificación de datos en caracteres legibles; transformar un secreto así puede impedir que una máscara basada en coincidencia literal lo oculte.

OIDC — Protocolo que permite a un workflow obtener credenciales temporales de un proveedor cloud según la identidad y las condiciones configuradas.

Runners autogestionados — Máquinas operada por la organización para ejecutar jobs de GitHub Actions.