Una campaña automatizada llamada Gheist usa tokens de GitHub robados para plantar workflows que imprimen los secretos de repositorios, también privados y de GitHub Enterprise, en los logs de Actions. Si tu equipo usa GitHub con CI/CD, busca hoy ramas ci-sync- en los audit logs y, si aparecen, rota todos los secretos.
Lo esencial
- Wiz ha recuperado más de 13.500 ramas plantadas desde más de 850 cuentas comprometidas, desde proyectos personales hasta repositorios privados de empresas (The Hacker News).
- Cada ataque crea una rama
ci-sync-seguida de seis caracteres aleatorios y sube un único archivo,.github/workflows/sync-check.yml, con el commit «ci: sync config». - Desde el 28 de julio GitHub retiene las ejecuciones potencialmente maliciosas hasta que alguien con permiso de escritura las aprueba, pero solo en repositorios públicos de github.com.
- Wiz sigue la campaña desde el 15 de septiembre, a 24 de octubre seguía activa y cambiando, y estima que ha afectado a «una docena de empresas» (Dark Reading).
¿Cómo roba los secretos?
El atacante no necesita romper nada. Usa un token de GitHub robado, crea la rama y sube el workflow. Ese workflow imprime el entorno del job y todos los secretos que puede leer, codificados en base32. GitHub enmascara los secretos en los logs, pero no lo garantiza cuando el valor está codificado, así que el texto sale completo. Después el atacante descarga los logs y borra la ejecución.
Como los secretos salen por la propia GitHub, no hay servidor del atacante ni conexión saliente que bloquear. Tu firewall no ve nada raro.
¿De dónde salen los tokens? Wiz rastreó algunos hasta logs de infostealers y hasta tokens expuestos en ataques anteriores a la cadena de suministro, según The Hacker News.
¿Me afecta si mis repositorios son privados?
Sí, y más que si fueran públicos. La retención de GitHub frenó todas las ejecuciones en repositorios públicos que Wiz comprobó, pero no cubre los privados ni GitHub Enterprise Server. Los ataques han funcionado en repositorios privados y en entornos GitHub Enterprise.
En organizaciones empresariales, la herramienta rotó tokens de varios usuarios y cuentas de automatización en pocos minutos y clonó repositorios privados antes de plantar el workflow. Horas después, credenciales de nube de la misma organización se usaron para enumerar AWS Secrets Manager. El robo no se queda en GitHub.
Hacia el 19 de octubre apareció una versión que lanza un segundo job contra los self-hosted runners. Wiz lo describe como defectuoso y no informa de ninguna ejecución con éxito.
Qué hacer hoy
- Pide a quien administre GitHub que busque en los audit logs ejecuciones en ramas
ci-sync-*borradas en menos de un minuto tras terminar, y actividad del user agent «gheist». - Si tus workflows usan OIDC con tu proveedor de nube, revisa sus logs en busca de asunciones de rol cuyo subject incluya una rama
ci-sync-. - Si encuentras rastro, rota todos los secretos de repositorio, organización y entorno que ese repositorio pudiera usar: claves de AWS u otra nube, tokens de despliegue, contraseñas de base de datos. Borrar la rama o la ejecución no deshace la exposición.
- Revoca los tokens que hicieron los commits y revisa los portátiles de sus dueños por si tienen un infostealer.
- Deja constancia escrita de la revisión, encuentres algo o no.
Qué significa para una pyme
El punto débil aquí no es GitHub: son los tokens personales de larga duración. Un token antiguo con permiso de escritura basta para leer todos los secretos del repositorio. En una startup, esos secretos suelen ser las claves de producción en la nube.
Nuestra postura: trátalo como un problema de gestión de credenciales, no de un proveedor concreto. A medio plazo, sustituye los tokens personales por GitHub Apps o tokens de corta duración, exige revisores en los entornos de producción, limita OIDC a ramas o entornos protegidos y usa self-hosted runners efímeros. Ninguna de estas medidas es exótica ni cara.
No olvides el RGPD. Si un secreto robado da acceso a datos personales en producción, puede convertirse en una brecha notificable. Por eso conviene documentar la revisión. Si quieres una segunda mirada sobre tu cadena de CI/CD, puedes apoyarte en nuestro servicio de ciberseguridad.
Una salvedad: los datos vienen de medios especializados que citan el informe de Wiz. No hemos accedido al informe original ni a un aviso de GitHub.
Preguntas frecuentes
¿Basta con borrar la rama ci-sync?
No. Los secretos ya han salido por los logs. Hay que rotarlos todos y revocar los tokens implicados.
¿Mi firewall lo detecta?
No por la salida de datos: los secretos salen por la propia GitHub, sin conexión a un servidor del atacante. La detección pasa por los audit logs.
¿Estoy protegido si uso GitHub Enterprise Server?
No. La retención de ejecuciones que GitHub aplica desde el 28 de julio solo cubre repositorios públicos de github.com.
