Una campaña con 4 837 cuentas secuestradas ha utilizado repositorios de GitHub para introducir malware y extraer credenciales de empresas, servicios en la nube y herramientas de inteligencia artificial. Los investigadores advierten de que borrar el código malicioso no garantiza que el ataque haya terminado.
La amenaza puede seguir activa incluso después de que desaparezcan las pruebas visibles. Un grupo de atacantes ha aprovechado cuentas legítimas de GitHub para introducir código malicioso en miles de repositorios y acceder a información que puede abrir las puertas de infraestructuras empresariales completas.
La campaña, detectada a partir del 10 de noviembre de 2026, ha utilizado credenciales robadas de 4 837 cuentas de GitHub para probar el acceso a 61 764 repositorios. Según Aikido Security, el programa diseñado para sustraer secretos llegó a ejecutarse en al menos 1 806 repositorios. Por separado, investigadores de SafeDep contabilizaron 8 093 repositorios públicos que recibieron confirmaciones maliciosas durante el periodo analizado. Son mediciones diferentes y no deben confundirse: recibir un cambio malicioso no significa necesariamente que el código llegara a ejecutarse.
El objetivo no era simplemente modificar proyectos de programación. El malware buscaba extraer tokens, contraseñas, claves de acceso a servicios en la nube, credenciales de inteligencia artificial y secretos utilizados por los sistemas automatizados de desarrollo.
La investigación revela, además, una técnica especialmente preocupante: los atacantes revertían los cambios y eliminaban los registros de ejecución para dificultar su detección. En algunos casos, el repositorio podía parecer limpio mientras las credenciales ya estaban en manos de terceros.
4 837 cuentas de GitHub utilizadas para atacar más de 61 000 repositorios
La investigación de Aikido Security describe una operación basada en el secuestro de cuentas legítimas. En lugar de entrar directamente en cada repositorio mediante una vulnerabilidad, los atacantes utilizaron credenciales robadas para actuar como usuarios autorizados.
El primer movimiento consistía en abrir una solicitud de cambios, conocida como pull request, con el título «docs: dependency audit notes» y desde una rama denominada wfx-docs.
La finalidad era comprobar si la cuenta comprometida tenía permisos de escritura en el repositorio. Si la operación funcionaba, el atacante podía intentar introducir modificaciones en los archivos utilizados por los procesos automatizados de desarrollo.
La campaña probó esta técnica en 61 764 repositorios. No todos terminaron infectados: en muchos casos no se publicó posteriormente ningún código malicioso o las condiciones de configuración y permisos impidieron que se ejecutara.
Aikido identificó 4 837 cuentas comprometidas utilizadas para estas pruebas. La empresa advierte de que las cuentas empleadas para abrir las solicitudes de prueba deben considerarse comprometidas, incluso cuando el programa malicioso no llegó a ejecutarse.
El alcance también superó los repositorios propiedad directa de los usuarios afectados. 10 431 solicitudes de prueba se enviaron mediante permisos de colaborador o de organización, y el 92 % seguía abierto cuando se realizó la comprobación citada en la investigación.
Esto significa que una cuenta secuestrada podía convertirse en una amenaza para proyectos de terceros que confiaban en ella.
Cómo funciona el malware que roba secretos de GitHub Actions
La campaña aprovecha una característica habitual del desarrollo moderno: los sistemas de integración y entrega continuas, conocidos como CI/CD.
Estas herramientas automatizan tareas como comprobar el código, ejecutar pruebas, construir aplicaciones y publicar versiones de software. Para hacerlo, necesitan acceder a credenciales y servicios externos.
En GitHub, uno de los mecanismos más utilizados para estas tareas es GitHub Actions. Sus flujos de trabajo pueden disponer de permisos y secretos que permiten comunicarse con plataformas de alojamiento, servicios de nube y registros de paquetes.
El problema aparece cuando un atacante consigue modificar esos flujos de trabajo. Si el código malicioso se ejecuta con los permisos del proceso automatizado, puede acceder a información que normalmente no está disponible para un usuario externo.
Según Aikido y SafeDep, la campaña utilizó distintas formas de introducir el programa:
- Modificar un flujo de trabajo existente: se añadían aproximadamente 1 500 líneas de código a un archivo de automatización.
- Incorporar un gancho
postinstallde npm: se añadía un script que podía ejecutarse al instalar dependencias con npm. - Crear un nuevo flujo de trabajo: se introducían archivos maliciosos en ramas temporales del repositorio.
La segunda modalidad resulta especialmente delicada. El código no solo podía ejecutarse en la infraestructura automatizada, sino también en el ordenador de un desarrollador que instalase el paquete o las dependencias afectadas.
La campaña demuestra cómo una cuenta aparentemente legítima puede servir para introducir código que se ejecuta con los privilegios de otros sistemas.
Qué información buscaban los atacantes
El programa malicioso estaba diseñado para recopilar credenciales de diferentes fuentes disponibles en el entorno de ejecución.
Entre los datos que podía buscar figuraban:
- Secretos de GitHub Actions: claves y variables configuradas para automatizar tareas.
- Tokens de acceso: incluido el
GITHUB_TOKENutilizado por los flujos de trabajo. - Credenciales de servicios en la nube: información de AWS, Microsoft Azure y Google Cloud Platform.
- Claves de herramientas de inteligencia artificial: credenciales de proveedores de IA disponibles en el entorno.
- Credenciales de desarrolladores: archivos de configuración de SSH, npm, PyPI, Kubernetes y otras herramientas.
- Información del repositorio: código fuente, los últimos 100 commits y artefactos recientes de los procesos automatizados.
El robo de credenciales de inteligencia artificial merece especial atención. Muchas empresas utilizan claves API para conectar sus aplicaciones con modelos y plataformas externas. Si esas claves terminan en manos de un atacante, pueden utilizarse para acceder a servicios, consumir recursos o intentar alcanzar otros sistemas vinculados.
En los ejecutores autohospedados, es decir, máquinas propias utilizadas para ejecutar GitHub Actions, el programa también podía buscar credenciales disponibles en los metadatos de la infraestructura, información de contenedores Docker y unidades de systemd.
El objetivo era mucho más amplio que obtener una contraseña: se trataba de recopilar las llaves digitales que permiten operar sobre sistemas empresariales.
El borrado de registros dificulta descubrir qué repositorios han sido comprometidos
Uno de los elementos más inquietantes de la campaña es la rapidez con la que desaparecían las modificaciones.
Después de introducir el código malicioso, el atacante solía revertir el cambio en cuestión de minutos. Además, cuando el programa llegaba a ejecutarse, sus registros de actividad se eliminaban habitualmente junto con la propia ejecución.
Esto complica enormemente las investigaciones posteriores. Un administrador puede revisar el repositorio y no encontrar el archivo que provocó el robo, aunque las credenciales ya hayan sido extraídas.
Los investigadores de Aikido señalan que la ausencia de un número de ejecución en la secuencia de GitHub Actions puede ser una de las pistas más fiables para detectar que el atacante llegó a ejecutar el programa.
La ausencia de archivos sospechosos, cachés o registros visibles no demuestra que el repositorio esté limpio.
Qué cifras se conocen del ataque
Los datos publicados por las dos empresas de seguridad describen diferentes fases de la operación:
| Indicador | Cifra o resultado |
|---|---|
| Cuentas de GitHub utilizadas | 4 837 |
| Repositorios sondeados por Aikido | 61 764 |
| Repositorios donde Aikido detectó ejecución del ladrón | Al menos 1 806 |
| Repositorios con confirmaciones maliciosas según SafeDep | 8 093 |
| Solicitudes de prueba mediante permisos de organización o colaboración | 10 431 |
| De esas solicitudes que seguían abiertas en la comprobación | 92 % |
SafeDep aclara que su recuento de 8 093 repositorios corresponde a proyectos que recibieron confirmaciones maliciosas en el periodo observado. Su análisis se centró en las ramas predeterminadas de repositorios públicos que podía consultar, por lo que no representa necesariamente la dimensión total de la campaña.
La diferencia entre las cifras no implica que una de las investigaciones sea incorrecta: miden acontecimientos distintos y utilizan criterios de observación diferentes.
El malware también puede abrir puertas traseras en AWS y Azure
El robo inicial de credenciales puede ser solo el primer paso.
Los investigadores describen funciones diseñadas para utilizar los tokens obtenidos y acceder a recursos más profundos de las cuentas en la nube.
En AWS, el programa podía intercambiar tokens OIDC de GitHub por sesiones de acceso y, en determinadas condiciones, crear claves de acceso de larga duración para usuarios de IAM.
También podía modificar políticas de confianza de roles para permitir accesos desde cuentas de AWS que no deberían tener autorización.
En Microsoft Azure, los investigadores identificaron mecanismos para añadir credenciales de identidad federada con el prefijo wfx-ci- a aplicaciones. Esto permitiría que determinados flujos de trabajo siguieran autenticándose sin depender de una clave secreta convencional.
La consecuencia es especialmente grave: cambiar las contraseñas o revocar los tokens originales puede no ser suficiente si el atacante ha conseguido modificar los mecanismos de confianza de la infraestructura.
Por eso, la respuesta debe incluir una auditoría de los permisos, las aplicaciones federadas y las políticas de acceso, además de la rotación de secretos.
Señales para detectar si un repositorio ha sido atacado
Aikido y SafeDep han publicado indicadores que los administradores pueden utilizar para revisar sus proyectos.
Entre las señales más relevantes figuran:
- Rama denominada
wfx-docs. - Ramas temporales con nombres como
chore/seguidos de ocho caracteres alfanuméricos. - Ramas con el patrón
ci-check-y cuatro cifras. - Solicitudes de cambios tituladas
docs: dependency audit notes. - Confirmaciones con mensajes como
ci: refresh build cache. - Archivos con nombres similares a
.ci-xxxxxx.sh. - Flujos de trabajo con nombres como
.github/workflows/build-audit-xxxxxx.yml. - Mensajes de confirmación como
chore: add ci helper,ci: restoreoci: cleanup.
También se ha identificado el siguiente hash SHA-256 asociado al script de robo:
89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf
Los investigadores observaron comunicaciones hacia direcciones externas, entre ellas:
194.150.166[.]244:8080/exfil18.143.168[.]96:8080/exfil153.75.82[.]159:8080
SafeDep también encontró que el malware podía enviar información a través de Telegram. En una muestra de 200 confirmaciones maliciosas analizadas, aproximadamente una quinta parte utilizó exclusivamente ese canal.
Estos indicadores son útiles para una primera revisión, pero no constituyen una garantía de seguridad. Un repositorio puede haber sufrido una ejecución maliciosa aunque no conserve los artefactos habituales.
Qué deben hacer las empresas y desarrolladores afectados
Los investigadores recomiendan actuar con rapidez y no limitarse a eliminar los archivos sospechosos.
La prioridad es impedir que las credenciales robadas sigan siendo válidas y comprobar que el atacante no haya creado mecanismos de acceso persistentes.
Las medidas recomendadas incluyen:
- Revocar los tokens comprometidos: revisar los tokens personales, permisos de aplicaciones OAuth, claves SSH y sesiones de las cuentas implicadas.
- Activar la autenticación de dos factores: reforzar el acceso a las cuentas de GitHub y a los servicios asociados.
- Rotar todos los secretos: cambiar las claves y variables a las que podía acceder el repositorio afectado.
- Auditar los permisos de GitHub Actions: comprobar qué permisos tienen los flujos de trabajo y limitar el acceso a los recursos imprescindibles.
- Revisar las cuentas de nube: buscar claves de acceso nuevas, cambios en políticas de confianza y sesiones sospechosas.
- Inspeccionar las credenciales federadas: comprobar que no existan identidades
wfx-ci-*que no hayan sido creadas por los administradores. - Revisar las máquinas de desarrollo: cualquier equipo que haya ejecutado
npm installen una confirmación afectada debe tratarse como potencialmente comprometido.
En AWS, los investigadores recomiendan revisar especialmente las llamadas AssumeRoleWithWebIdentity, CreateAccessKey y UpdateAssumeRolePolicy en CloudTrail, así como las sesiones con nombres asociados a wfx-.
En Google Cloud Platform, conviene investigar llamadas GenerateAccessToken y SignJwt procedentes de grupos de identidades de carga de trabajo de GitHub. También deben revisarse los accesos JWT a servicios como Vault.
La limpieza debe realizarse desde un entorno de confianza y acompañarse de una revisión de los registros disponibles. Revocar credenciales sin investigar las posibles puertas traseras puede dejar abierta una vía de acceso alternativa.
Packagist, Go y WebdriverIO: el ataque alcanza el ecosistema de paquetes
La operación no se quedó en los repositorios utilizados para desarrollar software. Los investigadores también encontraron actividad relacionada con paquetes y módulos distribuidos a través de diferentes plataformas.
Uno de los casos más relevantes afecta al paquete de Packagist digitalelvis/neuronai-studio, cuya versión 3.14.3 fue identificada como maliciosa.
SafeDep advirtió de que instalar esa versión y ejecutar determinadas acciones dentro de su directorio podía activar el código malicioso. La recomendación de los investigadores es bloquear la versión 3.14.3 y utilizar la 3.14.2 o una anterior, tras comprobar su integridad.
También se encontraron modificaciones en módulos de Go:
github.com/onuragtas/docker-env, versionesv1.0.278yv1.0.280.github.com/vkuznet/gocurl, en la pseudoversiónv0.0.0-20261111095532-8d5aad0cb0da.
En el primer caso, los investigadores precisaron que el código Go y los binarios de lanzamiento no habían cambiado: el contenido malicioso estaba en un flujo de trabajo de GitHub Actions. Aun así, recomendaron retirar las versiones afectadas.
En el segundo, el flujo de trabajo malicioso no llegó a ejecutarse según el análisis citado, pero se aconsejó bloquear la pseudoversión.
La investigación también identificó el acceso a 28 repositorios de WebdriverIO mediante confirmaciones realizadas con la cuenta de bot wdio-bot. No se detectaron versiones de paquetes afectadas, aunque el token del bot debe considerarse comprometido.
Al menos 50 usuarios afectados publicaban paquetes en plataformas como npm, Go, Packagist, PyPI o crates. Esto aumenta el riesgo de que las consecuencias de la campaña se extiendan más allá de los repositorios inicialmente atacados.
La relación con GhostAction: cuentas ya comprometidas vuelven a ser utilizadas
La investigación ha encontrado coincidencias entre las cuentas utilizadas en noviembre y las afectadas por la campaña GhostAction de octubre.
Según Aikido, las cuentas comprometidas durante aquella oleada tenían aproximadamente 1 000 veces más probabilidades de volver a ser utilizadas en esta nueva operación que otras cuentas activas.
En más de 100 repositorios, el nuevo programa se incorporó a archivos de flujos de trabajo que ya habían sido modificados durante la campaña de octubre. En esos casos, se mantuvo el paso anterior encargado de enviar información al exterior.
La coincidencia es relevante porque apunta a un problema que va más allá de un ataque aislado: las credenciales robadas pueden seguir circulando y ser reutilizadas por distintos grupos durante semanas o meses.
Sin embargo, Aikido ha evitado atribuir la operación de noviembre al mismo responsable de GhostAction. La empresa señala que las herramientas, la infraestructura y los métodos observados son diferentes, y recuerda que las credenciales robadas pueden terminar en manos de múltiples atacantes.
La conexión entre ambas campañas no demuestra que exista un único grupo detrás de las dos operaciones.
La cadena de suministro del software, un objetivo cada vez más atractivo
El caso vuelve a poner de manifiesto la vulnerabilidad de la cadena de suministro del software. Los proyectos actuales dependen de repositorios, paquetes de terceros, servicios de nube y sistemas automatizados que necesitan permisos para funcionar.
Cuando un atacante consigue secuestrar una cuenta con capacidad de escritura, puede aprovechar la confianza depositada en ese usuario para introducir código en procesos que se ejecutan automáticamente.
La amenaza no se limita a los desarrolladores. Una empresa puede terminar exponiendo credenciales de producción, claves de servicios de inteligencia artificial o accesos a plataformas de nube sin que sus sistemas principales hayan sido atacados directamente.
La lección es clara: la seguridad de un repositorio no depende únicamente de que su código sea legítimo, sino también de quién puede modificarlo, qué permisos tiene y qué secretos quedan al alcance de sus procesos automatizados.
Las empresas que utilizan GitHub Actions deberían revisar sus permisos, limitar los secretos disponibles para cada flujo de trabajo y mantener una vigilancia continua sobre las credenciales. En esta campaña, confiar en que el atacante ha borrado sus huellas puede ser precisamente el error que permita que siga dentro.
Chollones
Chollones
Chollones