Cuentas de GitHub secuestradas: wfx-loot roba secretos

¿Qué es la campaña wfx-loot de GitHub?

wfx-loot es una campaña en la que un atacante usa credenciales de GitHub robadas para introducir un workflow malicioso en los repositorios en los que esas cuentas pueden escribir, y así robar secretos de GitHub Actions y credenciales de la nube ^[1]. Aikido Security, que fue la primera en informar de ella, la bautizó con el nombre que el propio atacante da al malware («wfx») y la palabra que usa para los secretos robados («loot») ^[1]. SafeDep también atribuye a Aikido el primer informe ^[5].

StepSecurity llama «wfx» al mismo ladrón y subraya un punto clave: el atacante no explota un error de GitHub Actions ^[2]. En cambio, usa tokens válidos de cuentas reales de desarrolladores y de bots, y abre pull requests y sube commits como lo haría un desarrollador ^[2][4].

Aikido cree que el objetivo principal son los secretos de CI y no propagarse a través de paquetes de software, aunque la carga llegó al menos a un paquete de Packagist y a uno de Go mediante activadores de publicación automatizada ^[1]. BleepingComputer, basándose en el análisis de Aikido, informa de que algunas de las cuentas comprometidas pertenecían a grandes organizaciones ^[3].

¿Qué magnitud tiene el ataque wfx-loot?

Aikido cuenta 4.837 cuentas comprometidas que abrieron pull requests de sondeo en 61.764 repositorios, con el ladrón ejecutándose en al menos 1.806 repositorios ^[1]. Las cifras difieren ligeramente entre investigadores porque cada uno buscó en GitHub en un momento distinto mientras la campaña seguía activa.

• Aikido: 4.837 cuentas, 61.764 repositorios; 10.431 pull requests fueron a repositorios que la cuenta no posee; el 92% sigue abierto; al menos 50 usuarios comprometidos publican paquetes en npm, Go, Packagist, PyPI o crates ^[1].
• Aikido (cifra resumen): al menos 1.835 repositorios ejecutaron la carga y sufrieron el robo de credenciales; BleepingComputer usa esta cifra ^[1][3].
• StepSecurity: más de 63.000 pull requests de sondeo a las 07:40 UTC del 12 de noviembre, de las cuales cerca del 90% seguían abiertas ^[2].
• SafeDep: 8.093 repositorios recibieron commits maliciosos entre el 10 y el 12 de noviembre, una cifra que, como señala SecurityWeek, no significa necesariamente que el ladrón se ejecutara ^[5][4].

Aikido advierte de que su recuento de ejecuciones puede subestimar el impacto, porque los registros de ejecución se eliminaron en los repositorios afectados ^[1].

¿Cómo funciona el ladrón wfx-loot?

Por cada repositorio en el que un token robado puede escribir, el atacante sondea, sube la carga y luego borra sus huellas en cerca de un minuto ^[1].

1. Sondeo: una pull request titulada «docs: dependency audit notes» desde una rama llamada wfx-docs añade un diminuto archivo de notas. «La pull request no hace nada por sí sola», dice StepSecurity; solo demuestra que el token tiene acceso de escritura ^[2][4].
2. Carga: un script de shell de unas 1.500 líneas llega de una de tres maneras: inyectado en un workflow existente («ci: refresh build cache»), como un script más un hook postinstall de npm («chore: add ci helper») o como un nuevo workflow en una rama chore/ desechable («chore: add dependency audit workflow») ^[1].
3. Limpieza: el atacante revierte el cambio y elimina la ejecución del workflow y sus registros ^[1]. Un número de ejecución que falta es a menudo el único rastro ^[1].

El script recopila secretos y tokens de GitHub Actions, el entorno completo del runner, archivos de credenciales de AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH y más, historiales de shell, y claves de proveedores de IA y herramientas de desarrollo ^[1][3]. Incluso lee la memoria de los procesos en ejecución del runner ^[1][4]. Aikido descubrió que las copias que analizó enviaban los datos robados únicamente mediante HTTP POST a servidores controlados por el atacante ^[1]. StepSecurity vio después un cambio: desde cerca de las 05:30 UTC del 12 de noviembre, las nuevas copias enviaban los datos solo a través de Telegram, de modo que bloquear únicamente las direcciones de servidor publicadas ya no las detiene ^[2].

¿Por qué no basta con rotar los secretos?

Porque el ladrón intenta plantar puertas traseras que sobreviven a la rotación de credenciales ^[1][2]. Aikido describe tres trucos de persistencia ^[1]:

• Comprobaciones de estado falsificadas: Aikido dice que publica comprobaciones falsas de «éxito» con los nombres de las comprobaciones obligatorias de un repositorio, lo que puede superar las barreras de fusión de la protección de ramas ^[1]. StepSecurity halló esta función desactivada en las 101 muestras que examinó ^[2].
• Reescritura de la política de confianza de AWS: puede configurar la política de confianza de un rol para que permita cualquier cuenta de AWS ^[1].
• Inyección de identidad federada de Azure: puede añadir credenciales federadas con el nombre wfx-ci-… a aplicaciones de Azure AD, lo que permite a los workflows del repositorio comprometido autenticarse sin un secreto almacenado ^[1].

También puede generar tokens OIDC de GitHub e intercambiarlos por sesiones de AWS, Google Cloud y Azure, encadenarse con otros roles IAM y crear claves de acceso de AWS de larga duración ^[1][3]. Por eso StepSecurity dice que hay que «eliminar la persistencia, porque la rotación por sí sola no lo hace» ^[2].

¿Cómo compruebo si mis repositorios de GitHub fueron atacados?

Busque la pull request de sondeo y los mensajes de commit del atacante desde el 10 de noviembre y, después, busque huecos en los números de ejecución de los workflows ^[2][1].

1. Busque en las pull requests «docs: dependency audit notes» y en las ramas llamadas wfx-docs o chore/ seguidas de ocho caracteres ^[1][2].
2. Busque en los commits desde el 10 de noviembre «ci: refresh build cache», «ci: restore», «ci: cleanup», «chore: add ci helper» y «chore: add dependency audit workflow» ^[2].
3. Para cada coincidencia, abra la pestaña Actions y busque un número de ejecución que falte justo después del commit; StepSecurity lo califica como la señal más fiable de que el ladrón se ejecutó ^[2].
4. Anote qué cuenta subió los commits: los tokens de esa cuenta están robados ^[2]. Si existe una pull request de sondeo, la cuenta está comprometida aunque no se ejecutara ninguna carga ^[1].

No se fíe de la ausencia de artefactos. Aikido dice que la ausencia de artefactos wfx-loot, de entradas de caché wfx- o de resúmenes de pasos especiales no significa que no se robaran datos, porque esos canales estaban desactivados en esta campaña ^[1]. Aikido también sugiere que la carga puede desplegarse tanto en repositorios privados como en públicos ^[1].

¿Qué debo hacer si el ladrón se ejecutó?

Dé por comprometidos todos los secretos y roles de la nube disponibles para el workflow afectado, rótelos y, después, busque persistencia ^[1][2].

• Rote: todos los secretos de repositorio, de entorno y de organización a los que el trabajo podía acceder, no solo los que nombra el workflow; los tokens de publicación de npm, PyPI y otros; y las claves de la nube almacenadas como secretos ^[2].
• Revise los paquetes: busque versiones de paquetes publicadas después del commit malicioso ^[2].
• AWS: busque políticas de confianza que permitan a cualquier entidad de AWS, claves de acceso IAM creadas desde el 10 de noviembre y sesiones de CloudTrail que empiecen por wfx- ^[2].
• Azure: elimine las credenciales de identidad federada llamadas wfx-ci-* en los registros de aplicaciones ^[2].
• Google Cloud, Vault, Kubernetes: revise la generación de tokens y los inicios de sesión realizados con tokens de inicio de sesión de GitHub Actions ^[2].
• GitHub: elimine las ramas sobrantes, cierre las pull requests de sondeo, compruebe que no se fusionó nada con una comprobación falsificada y revoque los tokens, las concesiones de OAuth y las claves SSH de la cuenta ^[2].
• Tokens, según la documentación de GitHub: revise sus tokens de acceso personal en Settings, Developer settings y elimine los que no reconozca o no necesite; GitHub recomienda tokens de granularidad fina, solo los permisos mínimos necesarios y una fecha de caducidad, porque un token clásico puede acceder a todos los repositorios a los que usted puede acceder ^[6].

El hook de npm también se ejecuta en las máquinas de los desarrolladores: quien ejecutó npm install durante la breve ventana ejecutó el ladrón en local y también debe rotar sus propias credenciales ^[2]. SecurityWeek resume el consejo de varias empresas de seguridad: revocar los tokens comprometidos, rotar los secretos expuestos y comprobar si hay cambios no autorizados en la nube ^[4]. En el caso de las cuentas de bots, StepSecurity sugiere además revisar si realmente necesitan permiso para saltarse la protección de ramas ^[2]. Una protección sólida del inicio de sesión dificulta las campañas con cuentas robadas; consulte Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

¿Qué paquetes se vieron afectados?

Aikido enumera un paquete de Packagist y un módulo de Go que recogieron la carga mediante publicación automatizada ^[1].

• Packagist: digitalelvis/neuronai-studio versión 3.14.3; Aikido dice que hay que tratar como comprometida cualquier máquina que lo instalara o abriera ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 y v1.0.280; la carga solo está en un archivo de workflow de GitHub Actions, el código fuente y los binarios de Go no han cambiado y las compilaciones de Go nunca ejecutan archivos de workflow, pero Aikido recomienda igualmente retirar estas versiones ^[1].

Los recuentos difieren: SafeDep dice que tres paquetes de Packagist y del proxy de módulos de Go incluyen la carga, y SecurityWeek menciona versiones de dos módulos de Go ^[5][4]. SafeDep añade que la carga no se ejecutó para los consumidores habituales que instalan estos paquetes con composer require o go get ^[5]. Compruebe la lista actual de cada investigador antes de fiarse de una sola.

¿Quién está detrás de wfx-loot y cómo consiguió los tokens?

Ninguno de los informes citados aquí identifica al atacante, y StepSecurity dice que no ha establecido cómo se obtuvieron los tokens ^[2][4].

StepSecurity halló 173 pull requests de sondeo, de 19 cuentas, hechas con tokens emitidos a la aplicación de GitHub de Fly.io; dijo que no pudo determinar cómo se obtuvieron y que no tenía pruebas de que se hubiera vulnerado la infraestructura de Fly.io ^[2][4].

Aikido encontró coincidencias con cuentas afectadas por la oleada GhostAction de octubre y vio wfx-loot inyectado en archivos de workflow de GhostAction en más de 100 repositorios, pero consideró que se trata de dos campañas distintas, probablemente dirigidas por actores diferentes, ya que las credenciales robadas suelen acabar en manos de varios grupos ^[1]. También observó comentarios en indonesio en algunas versiones más recientes del malware ^[1]. Guardar los tokens con cuidado es importante en este caso; Password Managers Explained: How They Work and Whether They Are Safe explica lo básico.