La campaña GhostAction secuestra cuentas de GitHub para robar secretos de CI/CD e IA

Una ciberoperación coordinada conocida como GhostAction comprometió aproximadamente 1.900 cuentas de GitHub en octubre de 2026. Los atacantes utilizaron estos puntos de acceso para inyectar flujos de trabajo maliciosos de GitHub Actions en más de 30.000 repositorios, con el fin de exfiltrar credenciales sensibles, incluidas claves de acceso a la nube y tokens de API de proveedores de IA.

Qué ocurrió

El ataque se intensificó los días 8 y 9 de octubre de 2026, cuando los actores de amenazas dirigieron sus esfuerzos contra repositorios pertenecientes a unos 3.000 usuarios y organizaciones. Durante este periodo pico, los flujos de trabajo maliciosos intentaron extraer 3.174 secretos distintos. GitGuardian, que rastreó la campaña, señaló que los atacantes desplegaron la carga útil en varias fases. Un primer impulso afectó a unas 160 cuentas previamente victimizadas, seguido veinte minutos después por un despliegue mucho mayor que impactó a 28.000 nuevos repositorios.

A diferencia de ataques anteriores a la cadena de suministro que explotaban vulnerabilidades en acciones compartidas, como la comprometedora de tj-actions/changed-files, GhostAction dependía de credenciales de desarrolladores robadas. El análisis de StepSecurity del 9 de octubre sugiere que los atacantes probablemente utilizaron tokens de acceso personal obtenidos de volcados de credenciales, aunque la fuente inicial de estas credenciales sigue sin confirmarse. Con acceso válido de escritura, los atacantes modificaron directamente los flujos de trabajo de los repositorios, evitando la necesidad de cualquier vulnerabilidad en la propia plataforma de GitHub Actions.

Los archivos maliciosos fueron disfrazados con nombres inocuos como security-audit.yml o github_actions_security.yml. Estos trabajos falsos hacían referencia a secretos ya utilizados por procesos de compilación legítimos, lo que les permitía ejecutarse sin levantar sospechas inmediatas mientras recolectaban credenciales en segundo plano. Los controles de aprobación de GitHub bloquearon muchos de estos flujos de trabajo, pero los atacantes se adaptaron reciclando 92 flujos de trabajo antiguos de ataques previos, algunos de los cuales habían estado activos desde septiembre de 2025.

Cómo funciona

El mecanismo central del ataque consistía en inyectar archivos de flujo de trabajo YAML que ejecutaban acciones estándar de checkout con una obtención agresiva del historial. Específicamente, los flujos de trabajo utilizaban actions/checkout@v4 con el parámetro fetch-depth: 0. Esta configuración instruye al runner para que descargue todo el historial de Git en lugar de solo el último commit. Al acceder al historial completo, los scripts maliciosos podían escanear no solo el árbol de trabajo actual, sino también commits pasados en busca de secretos codificados.

Los escáneres buscaban una amplia gama de credenciales, incluyendo claves de AWS, tokens de acceso personal de GitHub y GitLab, claves de Google y Firebase, y tokens de API de proveedores de IA como Anthropic, OpenAI y OpenRouter. Las iteraciones posteriores del malware mejoraron su lógica de extracción capturando líneas de código circundantes, lo que les permitía emparejar los ID de clave de AWS con sus correspondientes claves secretas de acceso, incluso si estaban separadas en la estructura del archivo.

Una vez recolectadas, las credenciales se enviaban mediante HTTP a un servidor controlado por el atacante en la dirección IP 193.32.204.199. Este método permitía a los atacantes recuperar claves que habían sido eliminadas de la base de código actual meses o años atrás, pero que seguían siendo accesibles en el historial de Git. El proceso de exfiltración era silencioso, aprovechando el entorno de ejecución legítimo de GitHub Actions para mezclarse con el tráfico normal de CI/CD.

Detalles clave

• Aproximadamente 1.900 cuentas de GitHub fueron comprometidas para facilitar el ataque.
• Se inyectaron flujos de trabajo maliciosos en más de 30.000 repositorios pertenecientes a 3.000 usuarios y organizaciones.
• Los atacantes apuntaron a 3.174 secretos, incluyendo claves de la nube y tokens de API de proveedores de IA.
• Los flujos de trabajo usaron fetch-depth: 0 para escanear todo el historial de Git en busca de credenciales previamente eliminadas.
• Los datos exfiltrados se enviaron vía HTTP a la dirección IP 193.32.204.199.
• Solo el 16% de los repositorios afectados en fases anteriores había sido limpiado para el 5 de octubre.

Por qué importa

Este incidente destaca un punto ciego crítico en la seguridad del desarrollo moderno: la persistencia de secretos en el historial de Git. Muchos equipos asumen que eliminar una clave codificada de la rama actual elimina el riesgo. Sin embargo, dado que Git es inmutable por diseño, esos secretos permanecen en el historial a menos que se purguen explícitamente. La campaña GhostAction demuestra que los atacantes están explotando activamente esta brecha, utilizando herramientas estándar de CI/CD para desenterrar credenciales antiguas que los desarrolladores pueden haber olvidado.

Para los líderes de ingeniería y los equipos de DevOps, la dependencia de los controles de aprobación nativos de GitHub es insuficiente. Aunque GitHub bloqueó muchas ejecuciones maliciosas, la capacidad de los atacantes para reciclar flujos de trabajo antiguos y usar credenciales válidas significó que aún se produjo cierta exfiltración. El hecho de que solo el 16% de los repositorios previamente afectados hubiera sido limpiado meses después de la detección inicial sugiere un retraso significativo en los esfuerzos de respuesta a incidentes y remediación en todo el ecosistema.

Además, el objetivo de las claves de proveedores de IA señala un cambio en las prioridades de los atacantes. A medida que las empresas integran más servicios de IA en sus productos, los tokens de API para proveedores como OpenAI y Anthropic se han convertido en objetivos de alto valor. Comprometer estas claves puede conducir no solo a pérdidas financieras por uso no autorizado, sino también a posibles filtraciones de datos si las claves otorgan acceso a modelos propietarios o a datos de clientes procesados por estos servicios.

Qué puedes hacer

• Audita los registros de auditoría de GitHub y la actividad de los tokens de acceso personal para identificar cualquier cuenta que haya modificado .github/workflows/ recientemente.
• Revisa los historiales de ejecución de GitHub Actions para detectar trabajos que se ejecutaron inesperadamente o accedieron a secretos que no necesitaban.
• Revoca inmediatamente las credenciales de cualquier cuenta comprometida, incluso si el flujo de trabajo malicioso ya ha sido eliminado.
• Rota todas las claves de la nube, credenciales de despliegue, tokens de registro y claves de API de proveedores de IA que puedan haber quedado expuestas.
• Escanea todo tu historial de Git en busca de secretos codificados, no solo el HEAD actual, utilizando herramientas diseñadas para la inspección profunda del historial.
• Implementa requisitos estrictos de aprobación para cambios en los flujos de trabajo y limita el alcance de los tokens de acceso personal utilizados en CI/CD.