Atacantes usan credenciales robadas para insertar un secret stealer en GitHub Actions

Desde el martes, atacantes que disponían de credenciales robadas de 4.837 cuentas de GitHub han introducido un “secret stealer” en los flujos de integración continua (CI) de repositorios a los que esas cuentas podían escribir, según el análisis técnico publicado por la firma Aikido Security. El código malicioso fue diseñado para exfiltrar cualquier secreto o credencial en el alcance de las ejecuciones de GitHub Actions y para pivotar hacia cuentas en la nube usando tokens OIDC y otras credenciales que recuperaba del runner.

Los hechos confirmados por Aikido y otras firmas que han publicado análisis complementarios son claros en varios puntos: el atacante abrió pruebas iniciales mediante pull requests titulados “docs: dependency audit notes” desde ramas llamadas wfx-docs en al menos 61.764 repositorios públicos visibles para Aikido; en 1.806 de esos repositorios el stealer llegó a ejecutarse y presumiblemente exfiltró datos; y en total 4.837 cuentas se usaron para abrir las pruebas. SafeDep, que hizo un barrido independiente, contabilizó 8.093 repositorios que recibieron commits maliciosos en la ventana que analizaron, lo que indica que el alcance real puede ser mayor porque ambos conteos solo consideran ramas por defecto y repositorios públicos visibles para cada investigador.

Técnicamente, el ataque siguió un patrón repetible: abrir una PR desde wfx-docs para comprobar si la cuenta atacada tenía permiso de escritura; si la comprobación era positiva se añadía un paso (workflow) o un hook de postinstall en npm que ejecutaba un script cuya suma SHA-256 es 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Ese binario/script intenta recolectar claves y tokens desde múltiples fuentes locales del runner —variables y secrets de Actions, GITHUB_TOKEN, tokens en runtime, metadatos de instancias en runners self-hosted, ficheros de configuración de AWS/Azure/GCP, llaves SSH, artefactos de workflow y hasta secretos residuales en memoria de procesos— y luego exfiltra mediante HTTP POST a servidores observados (por ejemplo 194.150.166[.]244:8080, 18.143.168[.]96:8080, 153.75.82[.]159:8080) o incluso a un canal de Telegram, según SafeDep.

Una vez que el stealer obtenía credenciales OIDC o tokens válidos podía intercambiarlos por sesiones en AWS/GCP/Azure y, en el caso de AWS, crear claves de acceso de larga duración y modificar políticas de confianza (trust policy) para otorgar acceso a cuentas externas. En Azure se ha observado la creación de credenciales federadas con prefijos como wfx-ci- que permiten autenticación federada persistente desde workflows. Varias de estas operaciones están diseñadas para resistir rotaciones de claves.

Los indicadores técnicos proporcionados por Aikido —nombres de rama (wfx-docs, chore/[a-z0-9]{8}, ci-check-[0-9]{4}), título de PR concreto, mensajes de commit frecuentes (por ejemplo “ci: refresh build cache”, “chore: add ci helper”, “chore: add dependency audit workflow”) y la huella SHA-256 del payload— permiten detectar huellas de la campaña. Aikido también subraya que cualquier cuenta usada para abrir uno de estos PRs debe considerarse comprometida, aunque el stealer no llegara a ejecutarse, porque la posesión de credenciales se ha demostrado por la capacidad de crear ramas y PRs desde ellas.

Impacto práctico y alcance: además de repositorios individuales, el atacante alcanzó pipelines de publicación automatizada y paquetes. Aikido identifica una versión maliciosa en Packagist (digitalelvis/neuronai-studio v3.14.3) y dos versiones de un módulo Go que contienen el stealer en su workflow (github.com/onuragtas/docker-env v1.0.278 y v1.0.280). En algunos casos el código fuente o los binarios no fueron alterados; el riesgo vino por la presencia del payload en archivos de workflow o por hooks de npm postinstall que se habrían ejecutado en máquinas de desarrolladores. Quienes instalaron paquetes con ese postinstall o ejecutaron npm install en repositorios afectados deben asumir compromiso de la máquina y actuar en consecuencia.

Lo que se conoce con incertidumbre: los análisis no han identificado de forma pública cómo se obtuvieron inicialmente las credenciales de las 4.837 cuentas; tampoco hay una atribución concluyente del actor. Aikido señala una superposición con cuentas afectadas en la oleada conocida como GhostAction en octubre, pero no atribuye automáticamente ambos eventos al mismo operador porque las infraestructuras y métodos muestran diferencias y porque credenciales robadas pueden repartirse entre varios atacantes.

Consecuencias reales que los responsables deben asumir incluyen pérdida de secretos y posible escalada a entornos de nube enteros (creación de claves, modificación de políticas, incorporación de federación). En repositorios donde el stealer se ejecutó, se debe considerar comprometido todo lo que el workflow pudiera leer, incluyendo secrets de Actions, variables, tokens OIDC, y roles/credenciales en AWS/Azure/GCP.

Medidas concretas y priorización: primero, trate cualquier cuenta que abrió una prueba como comprometida. Revoque inmediatamente tokens de acceso personal, OAuth grants, llaves SSH y sesiones. Active la autenticación de dos factores (2FA) en cuentas con permisos de escritura. En repositorios afectados, rote y reemplace todas las secrets y variables que el workflow pudiera leer y considere regenerar cualquier clave de API accesible desde el runner.

Para buscar puertas traseras en la nube revise los siguientes eventos y objetos (formas de detección sugeridas): en Azure AD, busque credenciales federadas con prefijo wfx-ci-*; en AWS CloudTrail busque llamadas AssumeRoleWithWebIdentity o sesiones cuyo nombre contenga wfx-* seguidas de CreateAccessKey o UpdateAssumeRolePolicy; en GCP rastree GenerateAccessToken y SignJwt desde su pool de identidad de workloads. También inspeccione los logs de Vault para JWT logins originados del emisor OIDC de GitHub. Estas búsquedas coinciden con las señales que Aikido y SafeDep han destacado.

Si su repositorio recibió el commit malicioso pero el workflow no llegó a ejecutarse, igual revoque las credenciales del autor y rote secretos: Aikido aclara que la mera capacidad de empujar commits confirma control de la cuenta. Si ejecutó un npm install en una copia que contenía el hook malicioso, trate la máquina como comprometida: haga un reinstalado desde cero, revoque credenciales almacenadas localmente y rote claves API y tokens usados desde ese entorno.

Para reducir superficie en el futuro, aplique las prácticas de endurecimiento para GitHub Actions: conceda el menor privilegio posible a tokens, limite los permisos de GITHUB_TOKEN y habilite la autenticación OIDC con auditoría; use runners self-hosted con aislamiento y sin metadatos accesibles si no son necesarios; y configure reglas para bloquear commits o PRs que provengan de ramas o mensajes sospechosos. GitHub mantiene documentación sobre hardening y OIDC que puede servir de guía práctica: GitHub — Security hardening with OpenID Connect y GitHub — Security hardening for GitHub Actions.

Además, audite las actividades de STS y OIDC en proveedores de nube; por ejemplo, la API de AWS para AssumeRoleWithWebIdentity y su uso están documentados aquí: AWS STS — AssumeRoleWithWebIdentity. Estas búsquedas ayudan a detectar intentos de intercambio de tokens y creación de claves que el stealer aprovecha.

Resumen: la campaña ha mostrado un patrón automatizado y eficaz: uso de credenciales robadas para insertar un stealer en workflows y hooks que exfiltran secretos y escalan a entornos cloud. Si su organización usa GitHub Actions, cualquier repositorio en el que una cuenta haya abierto la PR de prueba debe considerarse en riesgo hasta que se haya realizado la revocación de credenciales, la rotación de secrets y la auditoría de roles en nube y runners. La falta de una atribución clara y la posibilidad de que el actor persista mediante federación implican que la respuesta debe ser amplia y rápida.