Gheist: vaciaron los secretos de 850 cuentas de GitHub con sus propios workflows

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Un token robado, un commit y tus secretos en un log ajeno

Wiz Research la sigue desde el 15 de septiembre y la bautizó Gheist, por el user agent de sus herramientas. La idea es de esa clase de simple que indigna: nadie explota un bug del software. Los atacantes entran con tokens de GitHub robados — de infostealers y de compromisos anteriores de supply chain — y comitean un workflow nuevo en cada repositorio al que el token alcanza. La rama se llama ci-sync- más seis caracteres al azar, el commit dice «ci: sync config» y solo agrega un archivo en .github/workflows. A toda vista.

El workflow imprime los secretos del repositorio en el log de GitHub Actions, y ahí viene el detalle fino: GitHub enmascara en los logs los valores que aparecen tal cual, pero si el secreto llega codificado en base32 el enmascarado no lo reconoce y el valor sale completo. Después la herramienta baja el log vía API de GitHub y borra el run segundos más tarde. Los secretos escapan por la propia infraestructura de GitHub, así que no hay dominio ni conexión saliente que bloquear.

Con ese mecanismo plantaron más de 13.500 ramas en más de 850 cuentas comprometidas, desde proyectos personales hasta repositorios privados de organizaciones. Mi lectura es la de siempre en seguridad: no hace falta ingeniería del infierno cuando los tokens viven su vida completa en las máquinas de todos.

Dónde se frenó y dónde no

La parte buena: GitHub puso el 28 de julio un freno que retiene en revisión los workflows potencialmente maliciosos en repositorios públicos. Todos los runs de Gheist en públicos que revisó Wiz quedaron congelados en «requiere aprobación» y nunca ejecutaron. El control funcionó.

La parte mala: ese hold no cubre repositorios privados ni GitHub Enterprise Server. Ahí los logs muestran runs de ramas ci-sync completando y borrados casi de inmediato, y CloudTrail registra workflows asumiendo roles de AWS desde ramas del atacante — mirar el log de la nube encuentra la campaña incluso sin logs de GitHub.

Lo que buscan en tu servidor

El 19 de octubre la herramienta se pondría más agreste. Contra repos con runners self-hosted mandó un segundo job que barre la máquina: 31 formatos de token — incluidas llaves de proveedores de IA como Anthropic, Hugging Face, Groq o NVIDIA —, archivos .env, estado de Terraform, historial de shell, el ambiente de cada proceso vía /proc, y hasta monta el filesystem raíz del host desde un contenedor pasando por el Docker socket para repetir el barrido completo. Remata con credenciales de instance roles de AWS y el token de service account de Kubernetes. Lo curioso: la herramienta está llena de bugs — busca la llave equivocada del runner, su regex de credenciales está rota — y aun así le alcanza.

Esa lista de lo que busca es, casi palabra por palabra, el inventario de secretos de cualquier servidor autogestionado: .env, tokens de agentes, credenciales de cron. Yo mismo corro agentes con llaves en .env, así que la lección no la tomo como anécdota ajena: un token de larga vida en una máquina es una bomba de tiempo, y cada agente nuevo que instala alguien la agranda. La campaña ni siquiera necesitaba ser perfecta — al 24 de octubre sigue activa, con cerca de dos tercios de las cuentas involucradas ya desaparecidas de GitHub tras el aviso de Wiz, y en paralelo las mismas cuentas reutilizadas para repartir malware, minar en GitHub Actions y envenenar archivos de build.

Qué hacer si te salpicó

Si aparecen ramas ci-sync- en tus repos, la prioridad es rotar cada secreto, de repositorio, organización y environment, al que el repo pudo llegar: borrar el run o la rama no deshace la exposición. Revoca los tokens que comitearon y revisa los equipos de sus dueños por infostealers. Si un run cayó en un runner self-hosted, trata el host como comprometido. Y el hardening de siempre que casi nadie aplica: revisores obligatorios en environments con secretos de producción, tokens de vida corta con permisos mínimos en vez de personal access tokens eternos, y runners efímeros sin Docker socket ni acceso abierto al metadata.

Fuente: Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles, de Wiz Research.

Fuente de inspiración: Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles