El asalto a 1.900 cuentas de GitHub: Cómo la campaña GhostAction infectó 30.000 repositorios mediante flujos falsos

De credenciales recicladas a 30.000 repositorios comprometidos: Radiografía de la ofensiva GhostAction

Un robo de credenciales a gran escala no siempre necesita romper los muros de la plataforma que ataca. La campaña bautizada como GhostAction demostró que basta con conseguir la llave de entrada de un desarrollador para convertir las herramientas de integración continua en un extractor masivo de secretos corporativos. Sin explotar ninguna vulnerabilidad en la infraestructura central de GitHub, un grupo de atacantes tomó el control de aproximadamente 1.900 cuentas personales y corporativas. Desde ese acceso legítimo, inyectaron archivos de flujo de trabajo maliciosos en más de 30.000 repositorios de código.

El mecanismo funcionó con la discreción de un caballo de Troya corporativo. Los atacantes no intentaron alterar el código fuente de las aplicaciones de sus víctimas para insertar puertas traseras en producción. En su lugar, crearon automatizaciones con nombres engañosos como security-audit.yml o github_actions_security.yml dentro de la carpeta .github/workflows/. Como estos procesos se hacían pasar por comprobaciones rutinarias de seguridad, las canalizaciones de integración continua (CI/CD) se ejecutaban sin levantar sospechas en los equipos de desarrollo.

La ofensiva se diferenció de otros incidentes sonados de la cadena de suministro de software, como el ataque a la acción compartida tj-actions/changed-files, donde se envenenó una biblioteca comunitaria utilizada por miles de proyectos. En GhostAction, los atacantes actuaron desde dentro: utilizaron tokens de acceso personal (PAT) obtenidos con alta probabilidad en filtraciones previas en la red oscura para realizar confirmaciones de código (commits) directas con permisos de escritura.

El peligro real de este vector radica en la automatización de la recolección. Durante la oleada de mayor intensidad, registrada los días 8 y 9 de octubre, el ataque se desplegó en dos fases cronometradas: primero impactó a unas 160 cuentas que ya habían sido sondeadas en semanas anteriores; apenas 20 minutos después, desató una ráfaga masiva contra 28.000 repositorios adicionales. El objetivo prioritario no era el código fuente en sí, sino las credenciales vivas almacenadas en variables de entorno y los secretos antiguos enterrados en el árbol de cambios del repositorio.

3.174 secretos en el punto de mira: Comparativa del impacto entre oleadas de ataque

Los informes técnicos elaborados por las firmas de seguridad GitGuardian y StepSecurity revelan que GhostAction no fue una prueba de concepto aislada, sino una operación persistente con infraestructura operativa activa al menos desde septiembre de 2025. Los atacantes refinaron sus métodos de recolección entre la fase preliminar del verano y la ofensiva generalizada de otoño, aumentando drásticamente tanto el alcance como la agresividad de las búsquedas en los repositorios.

Durante los meses de agosto y septiembre, la campaña mantuvo un perfil más bajo: se detectaron flujos maliciosos en 772 repositorios públicos vinculados a 373 usuarios y organizaciones. En esa fase se contabilizaron 3.669 ejecuciones de flujos de trabajo en 605 proyectos. Sin embargo, las barreras de aprobación predeterminadas de GitHub frenaron la gran mayoría: solo 499 lograron arrancar y únicamente 336 completaron su ciclo con éxito, logrando extraer 26 secretos de 13 repositorios específicos.

La respuesta de las organizaciones afectadas fue alarmantemente lenta. Para el 5 de octubre, solo el 16% de los repositorios identificados en la primera fase (124 de 772) habían eliminado los archivos maliciosos. Esta pasividad permitió a los atacantes reciclar 92 flujos preexistentes que continuaban intactos en proyectos desatendidos.

La mutación técnica más peligrosa de la variante de octubre fue la incorporación del comando actions/checkout@v4 con el parámetro fetch-depth: 0. De forma predeterminada, los sistemas de CI/CD solo descargan la última confirmación de código para ahorrar tiempo y ancho de banda. Al forzar una profundidad cero, el flujo malicioso descargó el historial completo de cambios desde la creación del proyecto.

Con el historial completo en memoria, el script ejecutó expresiones regulares buscando patrones específicos: pares de identificador y clave secreta de Amazon Web Services (AWS), tokens de acceso personal de GitLab y GitHub, claves de proyecto de Google Cloud y Firebase, y credenciales de acceso a interfaces de programación (API) de modelos de inteligencia artificial como OpenAI, Anthropic y OpenRouter. Bastaba con que un ingeniero hubiese subido una clave por error en 2023 y la hubiese borrado minutos después en otro commit: si el secreto no había sido invalidado en la consola del proveedor, el script de GhostAction lo capturaba y lo enviaba en texto claro a la dirección IP 193.32.204.199.

El impacto operativo en las empresas: Costes de remediación, paradas técnicas y exposición en la nube

Cuando un atacante extrae credenciales de infraestructura a través de una canalización de código, el problema trasciende el departamento de desarrollo de software y golpea de forma directa la continuidad del negocio y el balance operativo.

Costes directos de rotación masiva y horas de ingeniería (OPEX)

La invalidación de un secreto filtrado no consiste únicamente en pulsar un botón. Cuando se ven expuestas claves de acceso a nubes como AWS o tokens de plataformas de modelos lingüísticos, el equipo de ingeniería debe generar una nueva credencial, desplegarla en todos los servicios dependientes, actualizar los entornos de prueba y producción, y verificar que ninguna integración crítica quede interrumpida.

En un escenario corporativo mediano con 15 repositorios comprometidos y una media de 8 secretos por proyecto (incluyendo bases de datos, pasarelas de pago y proveedores de nube), el proceso de rotación manual exige entre 60 y 90 horas de trabajo cualificado de ingeniería de operaciones. Tomando como referencia un coste interno de 75 dólares por hora de especialista DevOps, la respuesta básica de contención puede superar los 6.500 dólares en tiempo improductivo, sin contar el coste de herramientas forenses especializadas. A ello se suma el peligro del uso no autorizado: las claves robadas de OpenAI o Anthropic suelen revenderse o utilizarse de inmediato para minería de consultas o entrenamiento no autorizado, generando facturas imprevistas que pueden alcanzar miles de dólares en cuestión de horas.

Dilación de entregas y bloqueo de canalizaciones (Lead Time)

Mientras un repositorio está bajo sospecha, las buenas prácticas de seguridad exigen congelar los despliegues automatizados a producción. La presencia de flujos espía obliga a auditar el historial de ejecuciones de GitHub Actions para comprobar qué secretos estaban asignados al contexto del trabajo malicioso y si la clave llegó a ser transmitida.

Este análisis forense congela el ciclo de entrega continua (lead time) de nuevas funciones para los clientes. En empresas de software que despliegan cambios varias veces al día, una auditoría completa de 48 a 72 horas para revisar los archivos .github/workflows/ y contrastar los registros de auditoría de tokens de acceso representa un retraso directo en los compromisos comerciales con clientes y socios.

Pérdida de soberanía en la nube y cadenas de confianza rotas

El daño más profundo radica en la persistencia del acceso no autorizado. Si un atacante extrae una clave de AWS con permisos de administrador o de creación de funciones sin servidor (serverless), puede crear usuarios secundarios, abrir pasarelas de red o modificar políticas de almacenamiento mucho después de que el archivo .github/workflows/security-audit.yml haya sido borrado del repositorio. Creer que el incidente se soluciona únicamente eliminando el archivo YAML del repositorio es el error que explica por qué el 84% de las empresas vulneradas en la primera fase continuaban expuestas semanas después del aviso inicial.

Escudos de arquitectura: Cómo proteger la integración continua frente al secuestro de cuentas

La lección fundamental de la crisis de GhostAction es que la seguridad del código ya no puede depender exclusivamente de nombres de usuario y contraseñas, ni siquiera cuando se cuenta con autenticación de dos factores básica en la interfaz web, si los tokens de acceso personal carecen de restricciones estrictas. Las organizaciones con arquitecturas más maduras lograron neutralizar el impacto del ataque aplicando tres barreras de contención estructurales.

Eliminación de claves fijas mediante OpenID Connect (OIDC)

La defensa más eficaz contra la exfiltración de credenciales de nube (como AWS, Azure o Google Cloud) es prescindir por completo de claves estáticas. Mediante la integración de OpenID Connect (OIDC) entre GitHub Actions y el proveedor de infraestructura, la canalización solicita un token criptográfico temporal que caduca automáticamente en un plazo de 15 a 60 minutos.

Si un flujo malicioso inyectado intenta leer variables de entorno en un repositorio configurado con OIDC, no encontrará ninguna clave de AWS para robar. Incluso si el atacante lograra interceptar un token efímero durante los segundos de ejecución, ese token solo tiene permisos para realizar la tarea específica ligada a esa rama protegida, impidiendo que el servidor externo 193.32.204.199 pueda reutilizarlo desde otra dirección IP.

Gobernanza de tokens de acceso personal de grano fino

El vector de entrada de GhostAction fueron cuentas comprometidas con permisos amplios de escritura mediante tokens clásicos (repo scope). GitHub introdujo los tokens de acceso personal de grano fino (Fine-Grained PATs), que permiten a los administradores limitar el acceso de una clave a repositorios específicos y otorgar únicamente permisos de lectura de código o gestión de incidencias, bloqueando la capacidad de modificar flujos de trabajo (workflows: write).

Además, para supervisar el comportamiento de las canalizaciones en tiempo real e identificar accesos anómalos o consumos imprevistos de recursos de cálculo, las organizaciones conectan sus entornos a plataformas integradas como Datadog, lo que permite alertar en segundos si una tarea desconocida de GitHub Actions intenta comunicarse con rangos de direcciones IP no clasificadas.

Inmutabilidad del historial y detección de secretos en el pipeline

Evitar que las claves borradas sigan viviendo en el historial requiere aplicar herramientas de protección activa antes de que el código llegue al servidor central:

• Escaneo previo a la confirmación (Pre-commit hooks): Bloquea cualquier intento de subir archivos que contengan estructuras de claves conocidas (como prefijos AKIA en AWS o cadenas sk- en proveedores de IA).
• Protección de ramas principales (Branch protection rules): Obliga a que cualquier modificación dentro del directorio .github/ requiera la aprobación obligatoria de dos ingenieros sénior mediante solicitud de extracción (Pull Request), impidiendo confirmaciones directas incluso a quienes poseen permisos de escritura.
• Saneamiento forense con herramientas de reescritura: Cuando una clave se filtra en un commit, no basta con borrarla en el siguiente; es imperativo reescribir el árbol mediante herramientas especializadas o purgar los registros de la base de datos de Git para que un clonado profundo (fetch-depth: 0) no recupere texto plano antiguo.

Protocolo de contención: Tres líneas operativas para aislar y limpiar canalizaciones expuestas

Ante una campaña masiva como GhostAction, las organizaciones deben estructurar su respuesta en fases secuenciales para evitar que la persistencia silenciosa de los atacantes anule el trabajo de los equipos técnicos.

1ª Línea de defensa: Auditoría inmediata de cuentas, PATs y registros de GitHub

La primera medida no es borrar el archivo sospechoso, sino cerrar la vía por la que entró. Si el atacante aún dispone de un token válido, volverá a inyectar el script minutos después del borrado:

• Revisión del registro de auditoría corporativo: Comprobar en la consola de administración de la organización los eventos workflows.create y workflows.update para detectar cuentas que hayan subido cambios a .github/workflows/ durante las fechas de la campaña.
• Revocación universal de tokens personales clásicos: Anular de inmediato todos los tokens de acceso personal de ámbito amplio creados antes del incidente para cualquier colaborador con permisos de escritura en repositorios públicos o privados.
• Revisión del historial de ejecuciones (Action Run History): Comprobar qué trabajos ejecutaron flujos con nombres como security-audit.yml, audit.yml o github_actions_security.yml, anotando los identificadores de trabajo para comprobar la lista de secretos inyectados en la memoria de la máquina virtual durante la ejecución.

2ª Línea de defensa: Rotación obligatoria de secretos vivos y saneamiento del historial Git

Asumir que un secreto no ha sido robado porque la ejecución falló o fue cancelada a medias es una negligencia grave. Todo secreto que haya estado registrado en un repositorio donde se detectó el flujo malicioso debe ser catalogado como comprometido:

• Rotación inmediata en el proveedor de origen: Acceder a las consolas de AWS, Google Cloud, OpenAI, Anthropic y proveedores de pasarelas para revocar de raíz las claves de acceso y emitir identificadores nuevos. No basta con cambiar el valor en la pantalla de variables de GitHub; la clave original debe quedar inutilizada en el proveedor de la nube.
• Auditoría de actividad post-filtración en la nube: Inspeccionar los registros de CloudTrail en AWS o los registros de acceso de la API de OpenAI desde el 1 de agosto hasta la fecha actual, filtrando llamadas procedentes de la dirección IP 193.32.204.199 o de nodos VPN y servidores proxy residenciales no habituales.
• Saneamiento del historial de Git: Si en algún momento del pasado se subieron claves reales al código, ejecutar un proceso de purga del historial completo del repositorio o considerar la migración del código limpio a un repositorio nuevo, evitando que herramientas automatizadas de escaneo histórico puedan rescatar credenciales que los desarrolladores creían eliminadas.