Las credenciales robadas de 4.837 cuentas de GitHub permitieron a un atacante desplegar malware dirigido a los secretos de los repositorios y al acceso a la nube, según indicó Aikido Security en sus hallazgos informados por The Hacker News, el 12 de noviembre. La campaña comenzó el martes 10 de noviembre, y el malware se ejecutó en al menos 1.806 repositorios, donde Aikido cree que probablemente se robaron credenciales.
Los propietarios de repositorios, los administradores de organizaciones y los desarrolladores que instalaron código afectado se enfrentan a exposiciones distintas. Aikido considera comprometida cualquier cuenta utilizada para abrir los pull requests de prueba del atacante, haya o no ejecutado malware después. Cuando hubo ejecución, todos los secretos y roles de nube accesibles para los flujos de trabajo automatizados deben tratarse como comprometidos.
Las pruebas de escritura alcanzaron 61.764 repositorios
El atacante comprobó los permisos de repositorio de cada cuenta enviando un pull request (una propuesta de cambio de código) con el título docs: dependency audit notes desde una rama wfx-docs. Aikido registró estas pruebas en 61.764 repositorios. Los permisos de colaborador u organización correspondían a 10.431 pull requests de prueba, lo que extendió la campaña más allá de los repositorios propiedad de las cuentas robadas; el 92 % de esas solicitudes seguía abierto en el momento de la comprobación.
La mayoría de los repositorios probados no recibieron después ningún payload, o tenían ajustes o permisos de cuenta que impidieron la ejecución. La visibilidad de Aikido se limitaba a los repositorios públicos, aunque la configuración de repositorios privados en el malware sugería que también podría estar operando en privado.
SafeDep, empresa de seguridad de la cadena de suministro de software, identificó por separado commits maliciosos en 8.093 repositorios entre las 12:46 UTC del 10 de noviembre y las 04:36 UTC del 12 de noviembre. Esta cifra mide la entrega, no la ejecución. Su búsqueda examinó solo las ramas predeterminadas de los repositorios públicos, lo que llevó a los investigadores a estimar que el total era mayor.
Los flujos de trabajo de integración continua (CI) existentes, es decir, trabajos automatizados que compilan y verifican código, recibieron el payload en 7.309 repositorios. Otros 771 lo recibieron mediante un hook postinstall de npm, un script que se activa con npm install y que también puede ejecutarse en el ordenador de un desarrollador.
La actividad continuó más allá de la búsqueda de Aikido, que terminó el miércoles. The Hacker News comprobó tres pull requests adicionales abiertos entre las 05:04 y las 05:38 UTC del 12 de noviembre: todos usaban el mismo título y una rama wfx-docs, aunque no estaba claro si después se entregó malware.
Lo que el malware puede robar y conservar
Aikido describió un stealer diseñado para buscar credenciales en el runner, la máquina que ejecuta un flujo de trabajo. Entre sus objetivos figuran los secretos y variables de GitHub Actions, GITHUB_TOKEN, los tokens de tiempo de ejecución de Actions, las claves de servicios de IA y los secretos almacenados en la memoria de procesos. También lee archivos de credenciales de AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH y otras herramientas.
La recolección abarca el contenido de los repositorios, los últimos 100 commits y los artefactos recientes de los flujos de trabajo, es decir, las salidas de trabajo guardadas. En los runners autoalojados, el malware apunta además a las credenciales de nube expuestas a través de los metadatos de instancia, el estado de los contenedores Docker y las unidades systemd, que definen los servicios del sistema.
SafeDep identificó dos vías para enviar el material robado: solicitudes HTTP POST a servidores del atacante y mensajes a un chat de Telegram. Alrededor de una quinta parte de los 200 commits de payload analizados dependía exclusivamente de Telegram.
El acceso a la nube puede mantenerse incluso después de reemplazar los secretos originales. El malware puede intercambiar tokens de GitHub OpenID Connect (OIDC), afirmaciones de identidad que los flujos de trabajo usan para solicitar acceso a la nube, por sesiones en AWS, GCP y Azure. Sus capacidades en AWS incluyen crear claves de acceso de larga duración para usuarios de Identity and Access Management y modificar la política de confianza de un rol para admitir cualquier cuenta de AWS.
En las aplicaciones de Azure AD, puede crear credenciales de identidad federada que comiencen por wfx-ci-. Estas establecen una relación de inicio de sesión de confianza que permite a los flujos de trabajo del repositorio comprometido autenticarse sin un secreto almacenado, incluso después de rotar los tokens.
Aikido también encontró una relación con la campaña GhostAction de octubre, que usó cuentas de GitHub robadas para introducir flujos de trabajo que roban secretos. Las cuentas afectadas entonces tenían unas 1.000 veces más probabilidades que otras cuentas activas de aparecer en la actividad de noviembre. En más de 100 repositorios, el último payload entró en los archivos de flujo de trabajo de octubre sin eliminar su paso de robo de datos existente. Aikido se abstuvo de atribuir el hecho al mismo actor porque la infraestructura, las herramientas y los métodos eran distintos, y las credenciales robadas pueden circular entre varios atacantes.
La exposición de los paquetes depende del uso del código
Los disparadores de publicación automatizada llevaron el malware al menos a un paquete de Packagist y a un módulo de Go. Al menos 50 usuarios comprometidos parecen publicar a través de npm, Go, Packagist, PyPI o crates, aunque Aikido consideró que obtener los secretos de CI era el objetivo aparente del atacante.
La versión maliciosa de Packagist es digitalelvis/neuronai-studio versión 3.14.3. En su listado figuraba como fecha de publicación el 11 de noviembre; a primeras horas del 12 de noviembre seguía disponible bajo un aviso de que sus versiones habían sido marcadas como malware. Aikido recomienda tratar como comprometidos los ordenadores que la instalaron o abrieron. La ejecución depende del comando: un composer install normal no lanza el stealer, mientras que npm install dentro del directorio vendor del paquete sí lo hace. Los usuarios deben bloquear v3.14.3 y fijar v3.14.2 o una versión anterior.
En github.com/onuragtas/docker-env, las versiones v1.0.278 y v1.0.280 contienen el payload únicamente en un flujo de trabajo de GitHub Actions. Ni el código Go ni los binarios de publicación cambiaron, y las compilaciones de Go no ejecutan archivos de flujo de trabajo, así que es posible que los usuarios del módulo hayan quedado al margen de la exposición. No obstante, Aikido recomienda eliminar ambas versiones.
Los investigadores también identificaron un flujo de trabajo malicioso en la pseudoversión v0.0.0-20261111095532-8d5aad0cb0da de github.com/vkuznet/gocurl. Ese flujo de trabajo nunca se ha ejecutado; los usuarios deben bloquear la pseudoversión.
Los commits atribuidos a wdio-bot introdujeron el stealer en 28 repositorios de WebdriverIO. Las versiones publicadas de los paquetes no se vieron afectadas, pero el token del bot debe considerarse robado.
Localizar los cambios y, después, revocar el acceso
Los propietarios de repositorios deben revisar la actividad desde el 10 de noviembre en todos aquellos en los que puedan escribir. Por lo general, el atacante deshacía los cambios maliciosos en cuestión de minutos y borraba los registros de ejecución; normalmente también eliminaba la ejecución del flujo de trabajo. Por tanto, que el archivo actual esté limpio no permite descartar que las credenciales se hayan expuesto.
Buscar ramas llamadas wfx-docs, ramas de vida corta que coincidan con chore/[a-z0-9]{8} y ramas que coincidan con ci-check-[0-9]{4}. Junto con el título del pull request docs: dependency audit notes, estos mensajes de commit identifican cambios relevantes:
ci: refresh build cache: unas 1.500 líneas insertadas en un flujo de trabajo existente.chore: add ci helper: un script.ci-xxxxxx.shemparejado con un hook postinstall enpackage.json, que se activa con cualquiernpm install.chore: add dependency audit workflow: un nuevo archivo.github/workflows/build-audit-xxxxxx.ymlen una ramachore/.chore: initial commit: un commit previo a la adición de un archivo de flujo de trabajo en un repositorio vacío.ci: restoreyci: cleanup.
La huella SHA-256 del script del stealer es 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Los indicadores de red son 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil y 153.75.82[.]159:8080.
La ausencia de artefactos wfx-loot, entradas de caché wfx- o resúmenes de paso WFX-BEGIN no descarta el robo. Los investigadores describieron un salto en la numeración de las ejecuciones del commit del atacante como una pista de ejecución más fiable.
Los administradores de nube también deben comprobar los mecanismos de persistencia que identificaron los investigadores:
- Entra ID: credenciales federadas desconocidas llamadas
wfx-ci-*. - AWS CloudTrail: sesiones
AssumeRoleWithWebIdentityoAssumeRolellamadaswfx-*, seguidas deCreateAccessKeyoUpdateAssumeRolePolicy. - GCP: llamadas
GenerateAccessTokenySignJwtoriginadas en el pool de identidades de carga de trabajo de GitHub, que proporciona identidades de flujo de trabajo para el acceso a la nube. - Vault: inicios de sesión con JSON Web Token (JWT) que usan el emisor OIDC de GitHub.
SafeDep recomienda a los propietarios de repositorios afectados revocar los tokens, las autorizaciones de aplicaciones OAuth, las claves SSH y las sesiones del autor del commit, activar la autenticación de dos factores y rotar todos los secretos y variables que el repositorio pueda leer. Los desarrolladores que ejecutaron npm install sobre un commit afectado deben considerar comprometido su ordenador y rotar sus claves.
