La campaña GhostAction apunta a los secretos de CI/CD en GitHub mediante cuentas comprometidas

Una nueva oleada del ataque a la cadena de suministro GhostAction comprometió aproximadamente 1.900 cuentas de usuario de GitHub entre el 8 y el 9 de octubre de 2026. Los investigadores de seguridad de GitGuardian observaron que los actores de amenazas apuntaban a más de 30.000 repositorios pertenecientes a 3.000 usuarios y organizaciones con el fin de extraer credenciales sensibles de entornos de integración continua.

Qué ocurrió

La campaña, identificada por primera vez en septiembre de 2025, se basa en que los atacantes obtengan permisos de escritura en repositorios legítimos de desarrolladores. Logran esto utilizando Personal Access Tokens (PATs) robados o credenciales cosechadas de registros de malware infostealer. Una vez dentro, los atacantes inyectan archivos de flujo de trabajo maliciosos de GitHub Actions en los repositorios objetivo. Estos archivos suelen disfrazarse con nombres engañosos como "security-audit.yml" o "github_actions_security.yml" para evitar sospechas inmediatas durante revisiones casuales de código.

El objetivo principal es el robo a gran escala de secretos almacenados en pipelines de CI/CD. Esto incluye credenciales de proveedores de nube, tokens de registro de paquetes para servicios como npm, PyPI y DockerHub, y claves API de proveedores de inteligencia artificial. El reciente pico de actividad representa una escalada significativa, con los atacantes intentando extraer 3.174 secretos de repositorios públicos. Gaetan Ferry y Guillaume Valadon de GitGuardian señalaron que la compromisión de 1.900 cuentas fue la causa directa de este intento generalizado.

Esta nueva fase de GhostAction parece más experimental y manual que las iteraciones anteriores. La carga útil ha evolucionado a través de múltiples versiones desde el 31 de agosto de 2026. La primera versión introdujo una función para escanear el historial de git en busca de secretos, utilizando expresiones regulares para identificar IDs de clave AWS, tokens de GitHub y GitLab, y otras claves API de la nube. Variantes posteriores mejoraron esta capacidad al capturar el contexto alrededor de los IDs de clave AWS para emparejarlos con sus correspondientes claves de acceso secretas, aumentando la probabilidad de que los datos robados fueran utilizables.

Detalles clave

• Escala del impacto: El pico del 8-9 de octubre apuntó a más de 30.000 repositorios pertenecientes a 3.000 usuarios y organizaciones.
• Compromiso de cuentas: Aproximadamente 1.900 cuentas de GitHub fueron comprometidas usando PATs robados o credenciales de registros de infostealers.
• Secretos objetivo: Los atacantes intentaron extraer 3.174 secretos, incluyendo credenciales de nube, tokens de paquetes y claves API de IA.
• Evolución de la carga útil: El flujo de trabajo malicioso evolucionó para incluir el escaneo del historial de git, con versiones posteriores capturando contexto alrededor de las claves AWS para facilitar el robo completo de credenciales.
• Método de despliegue: Los flujos de trabajo maliciosos se subieron bajo nombres engañosos como "security-audit.yml" para mezclarse con tareas de mantenimiento legítimas.
• Tiempo de mitigación: GitHub comenzó a impedir la ejecución del flujo de trabajo malicioso el 9 de octubre, deteniendo olas posteriores el 10 y 12 de octubre que buscaban extraer nuevos secretos.

Contexto

GitHub Actions es una plataforma de automatización popular que permite a los desarrolladores definir flujos de trabajo para compilar, probar y desplegar código directamente dentro de sus repositorios. Estos flujos de trabajo a menudo requieren acceso a información sensible, como contraseñas de bases de datos o claves de servicios en la nube, que se almacenan como "secretos" en la configuración del repositorio. Aunque es conveniente, esta centralización convierte a los pipelines de CI/CD en objetivos de alto valor para los atacantes. Si un atacante puede modificar la definición del flujo de trabajo, puede ejecutar scripts que exfiltran estos secretos hacia servidores externos.

Los ataques a la cadena de suministro como GhostAction explotan la confianza inherente a los ecosistemas de desarrollo de software. Al comprometer una sola cuenta de desarrollador, los atacantes pueden propagar código malicioso a todos los proyectos que esa persona mantiene. Esto es particularmente peligroso porque el código malicioso proviene de una fuente confiable, lo que dificulta su detección por parte de herramientas de seguridad automatizadas o revisores de pares. El uso de malware infostealer para cosechar credenciales iniciales destaca la importancia de la seguridad de endpoints junto con las protecciones específicas de la plataforma.

Por qué importa

Para los equipos que gestionan su propia infraestructura de software, este incidente subraya la fragilidad de la gestión de credenciales en los pipelines de CI/CD. Muchas organizaciones dependen de secretos de larga duración que rara vez se rotan. El hecho de que un subconjunto de víctimas en esta nueva ola hubiera sido comprometido en ataques anteriores sugiere que los atacantes apuestan a que los secretos no rotados sigan siendo válidos. Si su equipo no rota regularmente las claves API y los tokens, una sola brecha puede tener consecuencias duraderas, permitiendo a los atacantes mantener el acceso incluso después de parcheada la vulnerabilidad inicial.

Además, la evolución de la carga útil de GhostAction demuestra que los atacantes se adaptan activamente a las medidas defensivas. La adición del escaneo del historial de git significa que simplemente eliminar un secreto del código base actual es insuficiente si existe en el historial de commits. Los equipos deben asumir que cualquier secreto jamás commiteado a un repositorio está potencialmente expuesto. Esto requiere un cambio de estrategia de la limpieza reactiva a la gestión proactiva de secretos, incluyendo el uso de tokens de corta duración y controles de acceso rigurosos para las modificaciones del repositorio.

Qué puede hacer

• Rotee todos los secretos de CI/CD inmediatamente: Asuma que cualquier secreto almacenado en un repositorio de GitHub puede haber estado expuesto si su cuenta formaba parte de la base de usuarios afectada o si utiliza patrones similares.
• Habilite reglas de protección de ramas: Exija revisiones de pull request y verificaciones de estado antes de fusionar cambios en las ramas principales para prevenir modificaciones no autorizadas de flujos de trabajo.
• Audite el historial de git en busca de secretos: Utilice herramientas para escanear todo su historial de commits en busca de credenciales filtradas, no solo el HEAD actual de la rama.
• Implemente acceso de mínimo privilegio: Restrinja quién puede subir archivos de flujo de trabajo y gestionar secretos en sus repositorios, reduciendo el radio de explosión de una cuenta comprometida.
• Utilice credenciales de corta duración: Donde sea posible, reemplace las claves API de larga duración con tokens temporales que caduquen automáticamente, limitando la ventana de oportunidad para los atacantes.
• Monitoree actividad inusual de flujos de trabajo: Configure alertas para cambios en los archivos de flujo de trabajo, especialmente aquellos con nombres que se asemejen a auditorías de seguridad o tareas de mantenimiento.