La campaña Gheist roba secretos de repositorios privados de GitHub a través de los registros de Actions

Una nueva campaña de ataque automatizado denominada Gheist está explotando tokens robados de GitHub para extraer datos sensibles de repositorios privados. Desde mediados de septiembre, investigadores de seguridad de Wiz han observado a los atacantes implantando flujos de trabajo maliciosos que imprimen los secretos del repositorio directamente en los registros de GitHub Actions. Estos ataques apuntan específicamente a repositorios privados e instancias de GitHub Enterprise Server, donde las salvaguardas automatizadas existentes son menos efectivas.

Qué ocurrió

La campaña Gheist opera utilizando credenciales comprometidas para crear nuevas ramas en los repositorios objetivo. Cada rama sigue un patrón de nomenclatura específico, comenzando con ci-sync- seguido de seis caracteres aleatorios. Los atacantes confirman un único archivo de flujo de trabajo en estas ramas, diseñado para ejecutarse inmediatamente tras el push. Este flujo de trabajo accede a las variables de entorno y secretos del repositorio, codificándolos en formato base32 antes de imprimirlos en la salida estándar. Dado que los datos están codificados, se eluden las funciones automáticas de enmascaramiento de secretos de GitHub, permitiendo que los valores completos aparezcan en los registros de compilación.

Una vez finalizado el flujo de trabajo, la herramienta del atacante descarga el archivo de registro mediante la API de GitHub y luego elimina la ejecución del flujo de trabajo y la propia rama. Esta rápida limpieza dificulta la detección, ya que las pruebas desaparecen rápidamente. Wiz informa que, aunque GitHub ha implementado una salvaguarda que pausa las ejecuciones sospechosas de flujos de trabajo en repositorios públicos, esta protección no se extiende actualmente a los repositorios privados ni a las instalaciones autoalojadas de GitHub Enterprise Server. En consecuencia, todos los intentos en repositorios públicos analizados por Wiz fueron bloqueados, pero los entornos privados y empresariales permanecieron vulnerables a la exfiltración exitosa.

La escala de la campaña es significativa. Wiz ha identificado más de 13.500 ramas implantadas en más de 850 cuentas comprometidas. Estas cuentas van desde desarrolladores individuales hasta grandes organizaciones empresariales. En algunos casos empresariales, los atacantes rotaron múltiples tokens de usuario y de automatización en cuestión de minutos, clonando código privado e implantando flujos de trabajo en varios repositorios. Los tokens robados solían originarse en malware infostealer o compromisos previos de la cadena de suministro, como el incidente de marzo que involucró al escáner de vulnerabilidades Trivy.

Detalles clave

• La campaña utiliza la cadena de agente de usuario gheist para todas las solicitudes a la API.
• Las ramas maliciosas se nombran ci-sync- seguidas de seis caracteres alfanuméricos en minúsculas.
• El archivo de flujo de trabajo confirmado siempre es .github/workflows/sync-check.yml con el mensaje ci: sync config.
• Los secretos se exfiltran codificándolos en base32 para eludir el enmascaramiento de registros de GitHub.
• La retención automática de GitHub para ejecuciones sospechosas se aplica actualmente solo a repositorios públicos en github.com.
• Wiz ha recuperado más de 13.500 ramas implantadas de más de 850 cuentas comprometidas desde el 15 de septiembre.

Antecedentes

GitHub Actions permite a los desarrolladores automatizar flujos de trabajo de software, como la compilación y prueba de código. Estos flujos de trabajo a menudo requieren acceso a información sensible como claves de API, contraseñas de bases de datos y credenciales de nube, que se almacenan como secretos del repositorio. De forma predeterminada, cualquier usuario con permisos de escritura en un repositorio puede leer estos secretos. Cuando se ejecuta un flujo de trabajo, GitHub intenta enmascarar los valores de secretos conocidos en los registros para evitar exposiciones accidentales. Sin embargo, este enmascaramiento depende de la coincidencia exacta de cadenas. Si un secreto se modifica, por ejemplo, codificándolo en base32 o dividiéndolo en partes, es posible que GitHub no lo reconozca ni lo enmascare, dejando el valor sin procesar visible en los registros.

La distinción entre las protecciones de repositorios públicos y privados es crítica aquí. GitHub introdujo recientemente una función que retiene las ejecuciones de flujos de trabajo de fuentes no verificadas para aprobación manual en repositorios públicos. Esto actúa como una barrera sólida contra el abuso automatizado en proyectos de código abierto. No obstante, esta función aún no está disponible para repositorios privados ni para GitHub Enterprise Server, que muchas empresas utilizan para software propietario interno. Esta brecha deja a los entornos autoalojados y privados dependientes de otras medidas de seguridad, como una gestión estricta de tokens y el registro de auditoría, que pueden ser más difíciles de monitorear en tiempo real.

Por qué importa

Para los equipos que ejecutan su propio software o gestionan bases de código privadas, este incidente destaca un eslabón frágil en la cadena de seguridad de CI/CD. La suposición de que los registros son seguros porque los secretos están enmascarados ya no es válida. Los atacantes están utilizando activamente técnicas de codificación para eludir estas protecciones. Si su organización utiliza GitHub Actions para el despliegue, especialmente con runners autoalojados o repositorios privados, sus secretos corren peligro si un token se ve comprometido. El hecho de que los atacantes eliminen las ejecuciones inmediatamente significa que la monitorización tradicional podría pasar por alto el evento por completo a menos que tenga habilitados registros de auditoría detallados y los revise activamente.

Además, la campaña demuestra el efecto cascada del robo de tokens. Un único token de acceso personal robado o una credencial de automatización puede llevar al compromiso de toda la infraestructura en la nube de una organización. En los casos analizados por Wiz, los atacantes utilizaron el acceso inicial para asumir roles de AWS mediante OIDC, obteniendo potencialmente un control más amplio sobre los recursos en la nube. Para los líderes de TI e ingenieros de DevOps, esto significa que asegurar el pipeline de CI/CD no se trata solo de la calidad del código, sino de proteger las llaves de su entorno de producción. La falta de bloqueo automático en repositorios privados recae completamente sobre el equipo de seguridad interno para la detección.

Qué puede hacer

• Busque en sus repositorios ramas que coincidan con el patrón ci-sync- seguido de seis caracteres y elimínelas si las encuentra.
• Rotee inmediatamente todos los secretos de repositorio, organización y entorno si sospecha de algún compromiso de token.
• Revise los registros de auditoría de GitHub para buscar ejecuciones de flujos de trabajo en ramas ci-sync-* que fueron eliminadas dentro de un minuto tras su finalización.
• Verifique los registros del proveedor de nube, como AWS CloudTrail, en busca de asunciones de roles vinculadas a sujetos de ramas ci-sync-.
• Revoque cualquier token asociado con cuentas comprometidas y escanee los dispositivos de los propietarios en busca de malware infostealer.
• Exija la aprobación manual del revisor para los despliegues en entornos que contengan secretos de producción.