El actor de la amenaza responsable de la campaña de cadena de suministro GhostAction ha ampliado sus tácticas más allá de la inyección de flujos de trabajo maliciosos de GitHub Actions en proyectos comprometidos. Ahora también suplanta a desarrolladores de código abierto mediante phishing y distribuye un malware stealer camuflado dentro de un archivo de fuente falso. Según la plataforma de inteligencia de amenazas OpenSourceMalware, esta evolución indica que los atacantes están ajustando activamente sus métodos tras las medidas adoptadas por GitHub para impedir la ejecución de los flujos de trabajo maliciosos.
Infraestructura y phishing
La plataforma de inteligencia de amenazas señala que el atacante registró el dominio "my-github[.]com" y lo apuntó a "193.32.204[.]199", la misma dirección IP usada como punto de exfiltración de los datos recogidos por el flujo de trabajo malicioso. El dominio se registró el 9 de octubre de 2026, 17 días después del registro de "my-gitlab[.]com". No está claro si este último dominio, también temático de alojamiento de código, pertenece al mismo actor.
Sigue el mismo patrón de nombres my-<code-host>.com, lo que lo convierte en un pivote útil, pero la infraestructura actual no lo conecta directamente con GhostAction. Usan registradores, registros de titular, pares de servidores de nombres de Cloudflare, direcciones IP, ASN y diseños DNS distintos, y no se ha recuperado ningún certificado ni artefacto de cuenta compartido.
Ese mismo día, el dominio "my-github[.]com" se utilizó en un correo de phishing que suplantaba una alerta de seguridad de GitHub dirigida a un mantenedor de código abierto. El mensaje, enviado desde "noreply@my-github[.]com", advertía de un nuevo inicio de sesión en su cuenta de GitHub desde Moscú (Rusia) e instaba a hacer clic en un enlace para asegurar la cuenta. Según OpenSourceMalware, la página engañosa actuaba como proxy inverso, capturaba la contraseña y el código de doble factor (2FA) de la víctima e inyectaba JavaScript que autorizaba una aplicación OAuth con permisos para modificar sus flujos de trabajo y facilitar un ataque al estilo GhostAction.
La página de inicio de sesión falsa también incluye JavaScript para autorizar de forma silenciosa un flujo de dispositivo OAuth de GitHub con los ámbitos repo, workflow y read:org, lo que le concede amplios permisos para leer y escribir repositorios, modificar archivos de flujo de trabajo de Actions y obtener visibilidad sobre la pertenencia a organizaciones y datos organizativos relacionados. El objetivo es el mismo que en el phishing por código de dispositivo: obtener un token de acceso de GitHub y exfiltrarlo a "my-github[.]com" por TCP/8443.
El script recibe un código de dispositivo y un código de usuario, carga /login/device, extrae los formularios de GitHub del HTML devuelto y los envía automáticamente. Inserta el código de usuario, localiza un formulario de autorización, añade authorize=1 y publica la aprobación a través de la sesión proxy autenticada de la víctima.
La víctima no necesita escribir el código de dispositivo ni aprobar conscientemente la aplicación OAuth. Este kit va más allá al automatizar los pasos de código de usuario y autorización a través de la sesión de proxy inverso.
Al robar un token OAuth con alcance de repositorio, el atacante obtiene una credencial de API reutilizable. Además, los permisos concedidos mediante esta autorización OAuth encubierta coinciden con la capacidad de GhostAction de enumerar repositorios e inyectar archivos de flujo de trabajo maliciosos en ".github/workflows/".
El actor ahora puede combinar automatización a escala de repositorio con ingeniería social individual contra personas cuyas cuentas dan acceso a proyectos, organizaciones, registros y usuarios posteriores.
Componente de segunda etapa persistente
La campaña también incorpora un componente de segunda etapa que persiste en las máquinas de los desarrolladores incluso después de eliminar el flujo de trabajo malicioso. El enfoque toma ideas prestadas de las tácticas de Corea del Norte y confirma tres archivos distintos:
- Un archivo tasks.json de Microsoft Visual Studio Code (VS Code) con el disparador "runOn: folderOpen", que hace que se ejecute automáticamente al abrir la carpeta en la aplicación.
- Un archivo "public/fonts/fa-solid-400.woff2" que contiene una carga útil de stealer diseñada para recoger claves de AWS, tokens de PyPI, tokens de npm, credenciales de acceso a Git, credenciales de clústeres de Kubernetes, claves privadas SSH y credenciales de proveedores de IA como Anthropic Claude y Google Gemini. El nombre del archivo de fuente coincide con el usado en la campaña PolinRider de Corea del Norte de enero de 2026.
- Un segundo flujo de trabajo de GitHub Actions que se activa si el infostealer nunca llega a ejecutarse.
Esto provoca que VS Code ejecute automáticamente el stealer de credenciales, que además de recopilar datos instala una tarea cron que ejecuta código suministrado por el atacante cada cinco minutos. Los datos recogidos se envían al mismo servidor por HTTP sin cifrar en el puerto 8080. Se han identificado un total de 94 repositorios comprometidos con el componente de segunda etapa.
El segundo flujo de trabajo de CI es idéntico al original malicioso, pero incorpora formatos de credenciales adicionales que buscar y un mecanismo de reserva que sube los hallazgos a un gist secreto de GitHub si falla la petición POST. Este segundo flujo de trabajo utiliza los siguientes nombres:
- lint.yml
- ci-check.yml
- build-check.yml
- repo-health.yml
- audit.yml
- code-review.yml
- test-suite.yml
- cache-cleanup.yml
OpenSourceMalware indica que los 94 repositorios pertenecen a 66 propietarios, de los cuales 15 han sido eliminados, renombrados o convertidos en privados desde entonces. Entre los repositorios aún accesibles, la mayoría parecen estar en gran medida abandonados: uno de ellos lleva más de nueve años sin modificaciones y 65 de los 79 no han recibido ninguna confirmación en más de un año.
La etapa 1 necesita que GitHub ejecute el flujo de trabajo. El 9 de octubre, GitHub comenzó a impedir la ejecución del flujo de trabajo malicioso, y las oleadas del 10 y el 12 de octubre no extrajeron secretos. La etapa 2 añade un lanzador que no necesita ningún runner, y llegó seis días después del bloqueo. No podemos afirmar que el bloqueo la causara. Sí podemos afirmar que el operador se trasladó a un lugar al que no llegan los controles de GitHub.
Recomendaciones y valoración
Para mitigar la amenaza, los desarrolladores deben revocar los accesos y tokens de GitHub desde un dispositivo limpio, cambiar sus contraseñas, auditar sus repositorios, rotar todas las credenciales a las que puedan acceder los flujos de trabajo y avisar a los usuarios que hayan clonado los repositorios.
No sabemos quién es el operador, pero su trabajo sugiere una experiencia limitada. El filtro de variables de entorno del stealer pasa por alto la mayoría de las claves de API, su búsqueda en el directorio personal puede agotar el tiempo de espera y descartar sus propios resultados, y una sola IP gestiona la exfiltración, el phishing y el escaneo ruidoso de internet. Ese último error es la razón por la que buscar la IP todavía revela infecciones.
Deja una respuesta