GhostAction amplía el ataque: phishing para robar credenciales y persistencia en VS Code

Un grupo detrás de la campaña GhostAction —ya conocido por infiltrar flujos de trabajo de GitHub Actions en proyectos de código abierto— ha ampliado su arsenal: además de implantar workflows maliciosos en repositorios comprometidos, ahora envía correos de suplantación para capturar credenciales y entrega un cargador de información disfrazado como una fuente (.woff2) que actúa como un infostealer con persistencia en equipos de desarrolladores. Esta evolución, reportada por OpenSourceMalware y reproducida por medios de seguridad, muestra una transición desde la explotación pura de la ejecución automática en CI hacia una combinación de ingeniería social, abuso de OAuth y persistencia en el entorno de desarrollo.

Hechos confirmados: investigadores de OpenSourceMalware identificaron un dominio registrado como my-github[.]com que apunta a la IP 193.32.204[.]199 —la misma IP usada por la campaña para exfiltrar datos— y observaron que el dominio se utilizó en un correo phishing que imitaba un aviso de seguridad de GitHub para capturar contraseñas y códigos 2FA. La página fraudulenta actuó como un proxy inverso: robó credenciales y ejecutó JavaScript que autorizó automáticamente una aplicación OAuth y completó el flujo de dispositivo de GitHub para obtener un token con permisos de repo, workflow y read:org. Ese token permite modificar archivos bajo .github/workflows/ y volver a inyectar workflows maliciosos. Además, se detectó una segunda etapa en 94 repositorios: inclusión de un .vscode/tasks.json con trigger runOn: folderOpen, un archivo de fuente public/fonts/fa-solid-400.woff2 que contiene el payload para robar credenciales (AWS, PyPI, npm, Kubernetes, SSH, tokens de proveedores de IA) y un workflow de respaldo que, si la primera vía no ejecuta el ladrón, lanza la extracción e instala un cron que ejecuta código atacante cada cinco minutos; la exfiltración ocurre hacia la misma infraestructura por HTTP/8080.

Cómo funciona técnicamente la cadena de ataque: la secuencia combinada reportada puede resumirse así. Primero, el actor compromete repositorios y añade un workflow malicioso que, si se ejecuta en GitHub Actions, recoge secretos accesibles (tokens de GitHub, credenciales en el repo) y los envía a un servidor controlado. Para sortear bloqueos en la ejecución de workflows, el atacante usa phishing dirigido: un dominio similar a GitHub se registra y se emplea para enviar un falso aviso de inicio de sesión. La página proxy roba credenciales y, mediante scripts, automatiza el flujo de dispositivo de GitHub para obtener un token reuseable sin interacción consciente del usuario. Con ese token el actor puede escribir nuevos workflows o ficheros en repositorios. Si el control de ejecución de Actions queda limitado por GitHub, el adversario añade componentes que se ejecutan localmente en la máquina del desarrollador (VS Code tasks y archivos binarios disfrazados de fuentes) para persistir y robar secretos locales, instalando además un cron para mantener acceso periódico.

Quiénes quedan afectados y por qué es relevante: el blanco principal son mantenedores de proyectos de código abierto y desarrolladores con acceso a repositorios vulnerables o abandonados. OpenSourceMalware contabilizó 94 repositorios afectados pertenecientes a 66 propietarios; muchos repositorios estaban inactivos (la mayoría sin commits en más de un año). La combinación de repositorios poco vigilados y permisos excesivos en tokens de GitHub facilita la expansión lateral: con un token de repositorio el atacante puede afectar integraciones, paquetes y usuarios downstream que confían en esos repositorios.

Las consecuencias prácticas incluyen pérdida de tokens reutilizables que permiten modificar código y flujos de CI, exposición de credenciales de la nube y registros de proveedores (AWS, npm, PyPI), robo de claves SSH y secretos de APIs de IA —todos datos que permiten desde el abuso de infraestructura a la distribución de malware a través de artefactos legítimos—. Además, la persistencia local mediante un archivo que se activa al abrir el proyecto en VS Code eleva el riesgo: desarrollar con un repositorio comprometido puede convertir la estación de trabajo en una puerta trasera.

Confirmado vs. incierto: es un hecho verificado, según los informes, que el dominio my-github[.]com fue usado para phishing y que la IP mencionada sirvió como punto de exfiltración. También está confirmado el diseño técnico de la automatización del flujo de dispositivo para conseguir tokens. No está claro —según los propios investigadores— si otros dominios con nombres similares (por ejemplo my-gitlab[.]com) pertenecen al mismo operador: registros, registradores y artefactos CRYPTO/DNS no muestran una conexión directa. La atribución del actor permanece sin confirmar y la motivación exacta (financiera, espionaje, pruebas de concepto) no ha sido establecida públicamente.

Interpretación y contexto: la táctica revela dos tendencias conocidas pero combinadas de forma más agresiva: a) abuso del mecanismo OAuth/device flow para conseguir credenciales persistentes sin intervención explícita del usuario, y b) uso de vectores de persistencia en herramientas de desarrollo (VS Code) que no siempre son auditadas por controles de CI. La respuesta de GitHub —bloquear la ejecución del workflow malicioso— redujo la eficacia de la primera etapa, pero el actor respondió en cuestión de días con un diseño que evita la dependencia del runner. Esto ilustra la dinámica ofensiva-defensiva en la que los atacantes adaptan su infraestructura tras cada medida de mitigación.

Medidas concretas que deben tomar desarrolladores y administradores hoy mismo: revocar todos los tokens y autorizaciones de GitHub desde un dispositivo limpio y rotar todas las credenciales que pudieran haber estado accesibles a los workflows (claves de nube, tokens de paquetes, credenciales de registries). Revisar y retirar aplicaciones OAuth desconocidas en la página de settings > authorized OAuth apps y en la gestión de tokens de la organización. Auditar repositorios por archivos sospechosos (.github/workflows con nombres de CI comunes, .vscode/tasks.json, fuentes inusuales en public/fonts) y por cualquier cron o tarea programada en estaciones de trabajo de desarrolladores. Buscar conexiones salientes a 193.32.204[.]199 y domains my-github[.]com y bloquearlas a nivel de red. Habilitar políticas que limiten los permisos de workflows a lo estrictamente necesario y exigir revisiones manuales para cambios en .github/workflows; usar herramientas de protección como GitHub Actions security hardening y Require approval for third-party access en organizaciones. Para credenciales de alto valor (cloud, proveedores de IA) considerar la rotación inmediata y el uso de credenciales de corta duración y servicios de gestión de secretos. Finalmente, para elevar la protección contra phishing de OAuth, promover mecanismos de autenticación resistentes a phishing (llaves de seguridad FIDO) y educación específica sobre la ingeniería social que usa páginas proxied y flujos automáticos.

Para más información técnica sobre cómo funciona el flujo de dispositivo y medidas preventivas en Actions, consulte la documentación oficial de GitHub sobre el Device Flow y las recomendaciones de endurecimiento de Actions: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow y https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions. También puede seguir investigaciones y muestras en el repositorio de análisis de OpenSourceMalware: https://opensourcemalware.org/.

En resumen: la operación GhostAction ha demostrado capacidad para adaptarse rápidamente y mezclar técnicas de supply‑chain, phishing de OAuth y persistencia local. Los desarrolladores de código abierto y organizaciones mantenedoras deben asumir que cualquier repositorio con historial de commits inactivos o sin auditoría reciente podría ser un vector y actuar con prioridad en la revocación, rotación y endurecimiento de permisos.