Una nueva ola de la campaña de cadena de suministro GhostAction ha comprometido 772 repositorios públicos de GitHub. El ataque utilizó archivos de flujo de trabajo de GitHub Actions falsos para robar credenciales de entornos CI/CD. Entre el 31 de agosto y el 30 de septiembre de 2026, la actividad afectó a 373 usuarios y organizaciones, comprometiendo 2.577 secretos, incluyendo claves de nube, credenciales SSH y accesos a registros de contenedores.

Una nueva ola de la campaña de cadena de suministro GhostAction ha comprometido 772 repositorios públicos de GitHub, utilizando archivos de flujo de trabajo (workflow) falsos de GitHub Actions para robar credenciales de entornos CI/CD.

La actividad se llevó a cabo desde el 31 de agosto hasta el 30 de septiembre de 2026, y tuvo como objetivo 2,577 secretos de 373 usuarios y organizaciones de GitHub, incluyendo claves de nube, credenciales SSH, inicios de sesión de registros de contenedores, contraseñas de bases de datos y tokens de GitHub.

La investigación de GitGuardian muestra que la campaña utiliza el acceso robado a cuentas de GitHub para añadir flujos de trabajo maliciosos bajo la propia identidad de la víctima.

Los archivos maliciosos parecen actualizaciones de automatización normales, lo que hace que sea fácil pasarlos por alto durante una revisión rápida de código. En la mayoría de los casos, el actor añadió un flujo de trabajo llamado github_actions_security.yml con el mensaje de commit Add Github Actions Security workflow.

El flujo de trabajo espera a que se realice un "push" normal al repositorio, lee los secretos seleccionados de GitHub Actions y los envía a una infraestructura controlada por el atacante a través de una solicitud POST de curl.

Esta técnica se asemeja a actividades anteriores de robo de credenciales mediante actualizaciones falsas de CI, donde se utilizaban cambios en los flujos de trabajo con apariencia rutinaria para acceder a tokens y credenciales de nube.

Los analistas de GitGuardian identificaron la actividad más reciente de GhostAction después de que investigadores de Cynative detectaran independientemente commits sospechosos y contactaran a la empresa.

GitGuardian reveló primero GhostAction en septiembre de 2025, cuando la campaña comprometió 817 repositorios públicos y recolectó al menos 3,325 secretos.

Los hallazgos más recientes muestran que no fue un evento efímero: flujos de trabajo maliciosos de olas anteriores permanecieron en algunos repositorios y fueron actualizados posteriormente con nuevos puntos finales (endpoints) de robo de datos.

La campaña de cadena de suministro GhostAction utiliza GitHub Actions maliciosos

GhostAction no recolecta simplemente cada variable disponible para un ejecutor de flujo de trabajo. En su lugar, el flujo de trabajo parece inspeccionar el flujo de trabajo existente del repositorio y el historial de configuración en busca de referencias a secretos formateadas como ${{ secrets.NAME }}.

Luego inserta esos nombres exactos de secretos en el flujo de trabajo añadido. Esto hace que el archivo malicioso sea más preciso y le permite recolectar credenciales que probablemente sean útiles para el despliegue, la publicación, la gestión de la nube o el acceso al código fuente.

El payload más reciente envía datos a través de HTTP simple a 193.32.204.199, reemplazando la infraestructura anterior de GhostAction. Una variante más pequeña vista en siete repositorios utilizaba security-check.yml, mostraba el nombre de flujo de trabajo “Security Check” y usaba el mensaje de commit Add security check workflow.

Esa variante enviaba datos a un punto final de API que contenía un identificador de inyección único, lo que sugiere que el operador podría estar rastreando las credenciales robadas por repositorio o instancia de flujo de trabajo.

El uso de persistencia de flujos de trabajo ocultos también es consistente con el ataque de cadena de suministro npm Shai-Hulud, que inyectaba archivos de GitHub Actions para continuar recolectando secretos después de un compromiso inicial.

GitGuardian registró tres ráfagas principales en la nueva ola: 143 repositorios el 31 de agosto; aproximadamente 400 repositorios entre el 2 y el 5 de septiembre, incluyendo 294 solo el 5 de septiembre; y 103 repositorios el 15 de septiembre. De las 3,669 ejecuciones de flujo de trabajo revisadas en 605 repositorios, GitHub retuvo la mayoría para su aprobación.

Aun así, 499 se ejecutaron en 32 repositorios y 336 ejecuciones se completaron con éxito, permitiendo el robo de 26 secretos de 13 repositorios. Los valores más frecuentemente atacados fueron claves privadas SSH y credenciales de servidores de despliegue, sumando 446 referencias a secretos.

Las credenciales de Azure fueron objetivo 218 veces, mientras que las de Docker Hub y GitHub Container Registry aparecieron 142 veces.

Los flujos de trabajo también buscaron contraseñas de bases de datos, claves de acceso de AWS, credenciales FTP, credenciales de Google Cloud y Firebase, tokens de GitHub y tokens de API para servicios como Cloudflare, npm, PyPI, Slack, Telegram, Discord y plataformas de IA.

Esto refleja el riesgo creciente descrito en el abuso de herramientas de desarrollo confiables, donde los sistemas de los desarrolladores y los pipelines de construcción se utilizan como ruta para acceder a la nube y al código fuente.

La campaña GhostAction nunca se detuvo por completo

La señal más fuerte de persistencia de la campaña es que, en 92 casos, el actor no creó un flujo de trabajo nuevo. En su lugar, actualizó un archivo ya comprometido utilizando el mensaje de commit Update Github Actions Security workflow.

Estos archivos habían sobrevivido a periodos anteriores de la campaña y fueron modificados para usar el nuevo servidor de recolección. Los investigadores vincularon el mismo patrón de flujo de trabajo a puntos finales más antiguos, incluyendo bold-dhawan.45-139-104-115.plesk.page, carte-avantage.com, 170.39.218.2 y dominios de Interactsh *.oast.fun.

Solo 124 de los 772 repositorios afectados, o el 16%, habían sido limpiados efectivamente en el historial de commits públicos al 5 de octubre. Esta cifra es importante porque un flujo de trabajo malicioso puede ejecutarse nuevamente cada vez que un desarrollador realice un commit legítimo.

Por lo tanto, debes tratar la eliminación del flujo de trabajo como solo una parte de la respuesta. Debes identificar cómo el atacante obtuvo acceso de escritura al repositorio, revocar la credencial de GitHub afectada, revisar las ejecuciones de los flujos de trabajo y los registros de auditoría, y rotar cada secreto que haya estado disponible para el ejecutor.

GitHub aconseja a los equipos limitar cada flujo de trabajo y el GITHUB_TOKEN a los permisos mínimos requeridos, auditar el código fuente del flujo de trabajo y las acciones de terceros, y anclar las acciones a un SHA de commit completo, lo que proporciona una referencia inmutable.

Las organizaciones también deben usar controles de aprobación de entorno para secretos de despliegue sensibles y revisar minuciosamente los archivos recién añadidos o modificados en .github/workflows/. La guía de uso seguro de GitHub señala que un secreto expuesto debe ser rotado, incluso si fue enmascarado en los registros.

GitGuardian también encontró un criptominero en el repositorio kuafuai/DevOpsGPT, que posteriormente fue afectado por GhostAction. Sin embargo, los investigadores no atribuyeron ambos eventos al mismo operador.

El minero utilizaba un correo electrónico de autor falsificado, un payload personalizado, un binario de XMRig disfrazado de /usr/local/bin/pyworker y un estilo operativo diferente, mientras que GhostAction dependía de una inyección automatizada y amplia de flujos de trabajo a través de la API de GitHub.

El solapamiento sigue resaltando un problema clave: las credenciales robadas de GitHub pueden ser reutilizadas por varios grupos de amenazas no relacionados. Una cuenta de mantenedor comprometida puede usarse para recolectar secretos de CI/CD, inyectar código malicioso, publicar paquetes alterados o ejecutar cargas de trabajo de criptominería.

Como ha mostrado la reciente actividad de amenazas a la cadena de suministro de software, una sola identidad de desarrollador puede convertirse en una vía de acceso a sistemas de construcción, cuentas de nube, registros de paquetes y entornos de clientes finales.

Para quienes defienden sus sistemas, la lección central es el control de la identidad. No solo debes eliminar los archivos de flujo de trabajo sospechosos y rotar las claves de la nube; debes revocar los tokens de acceso personal de GitHub expuestos, imponer una autenticación multifactor resistente al phishing, requerir la revisión de los cambios en los flujos de trabajo, aplicar permisos de privilegio mínimo y monitorear el tráfico de red saliente de los ejecutores de CI.

En los incidentes de GhostAction, dejar activa la credencial original robada de GitHub podría permitir que el mismo operador —u otro actor que posea esa credencial— regrese.

Fuentes:
https://cybersecuritynews.com/ghostaction-supply-chain-campaign/