Inicio › Ciberseguridad

Ciberseguridad

4.837 cuentas de GitHub secuestradas siembran un ladrón de secretos en miles de repositorios: la campaña «wfx» sigue activa

Entra con un pull request de aspecto rutinario, roba todo lo que el CI puede tocar —nube e IA incluidas—, deja acceso persistente en AWS y Azure y se borra solo en un minuto. Y esta madrugada seguía abriendo sondas.

Redacción AlexTechNews12 de noviembre de 20263 min de lectura💬 Comentar
Interfaz de GitHub con el Octocat y una alerta roja de «CI workflow (malicious)» sobre un archivo de workflow, con accesos a credenciales de la nube y secretos de GitHub
Un workflow de CI marcado como malicioso dentro de GitHub, el vector de entrada de la campaña «wfx». Imagen: The Hacker News.

La mayor campaña de robo de credenciales contra GitHub de la temporada no entró por una vulnerabilidad: entró con las llaves de sus propios usuarios. Aikido Security ha publicado este jueves el análisis de la campaña «wfx»: desde el 10 de noviembre, un atacante con credenciales robadas de 4.837 cuentas abrió pull requests de sondeo en 61.764 repositorios y ejecutó un ladrón de secretos en al menos 1.806, de los que, según la empresa, ya exfiltró las credenciales al alcance de sus flujos de CI.

El sondeo es un pull request de aspecto aburrido, «docs: dependency audit notes», abierto desde una rama llamada wfx-docs para comprobar si la cuenta robada puede escribir en el repositorio. GitHub devuelve 61.839 pull requests así entre el 10 de noviembre a las 12:45 UTC y el 11 a las 15:00 UTC; 10.431 llegaron a repositorios ajenos por acceso de colaborador u organización y el 92 % seguían abiertos al revisarlos Aikido. Si uno apareció en un repositorio en el que puedes escribir, esa cuenta está comprometida aunque el ladrón nunca corriera, advierte la empresa.

Donde corre, el payload —un script de unas 1.500 líneas que se firma «wfx»— entra inyectado en un workflow existente («ci: refresh build cache»), como gancho postinstall de npm o como workflow nuevo. Recoge secretos de GitHub Actions, el GITHUB_TOKEN, tokens OIDC, credenciales de AWS, Azure, GCP, npm, PyPI y SSH, claves de IA y secretos en la memoria del runner. Después escala: intercambia tokens OIDC por sesiones en las tres nubes, crea claves duraderas en AWS y deja persistencia que sobrevive a la rotación —abrir un rol de AWS a cualquier cuenta o añadir credenciales federadas «wfx-ci-» en Azure—. Al terminar revierte el cambio en un minuto y suele borrar la ejecución: a menudo la única pista es un número de ejecución que falta.

La campaña también alcanzó paquetes por publicación automática: la versión 3.14.3 de digitalelvis/neuronai-studio en Packagist lleva el ladrón —Aikido pide dar por comprometida cualquier máquina que la haya instalado o abierto— y dos versiones del módulo de Go github.com/onuragtas/docker-env lo llevan solo en su workflow. SafeDep, que la rastreó por su cuenta, contó 8.093 repositorios con commits maliciosos hasta hoy a las 04:36 UTC y avisó de que seguía activa.

Y sigue activa: The Hacker News comprobó que esta misma madrugada, entre las 05:04 y las 05:38 UTC de hoy, se abrieron más sondas desde ramas wfx-docs, ya fuera de la ventana de Aikido. Las cuentas se solapan con la oleada GhostAction de octubre, aunque Aikido no atribuye noviembre al mismo actor. La recomendación es directa: donde el payload corrió, todo secreto y rol de nube al alcance debe darse por comprometido y revisarse en busca de las puertas traseras, porque rotar contraseñas, solo, no cierra esta puerta.

Comentarios

Sé el primero en comentar.

Los comentarios aparecen tras una breve revisión. Sin cuentas y sin rastreadores.

Sigue leyendo