Los atacantes de GhostAction ocultan robadores de credenciales en fuentes falsas en GitHub

El actor de amenazas detrás del ataque a la cadena de suministro de GhostAction ha cambiado sus tácticas, pasando de inyectar flujos de trabajo maliciosos en proyectos de GitHub a atacar directamente a los desarrolladores mediante phishing. En una campaña detallada por OpenSourceMalware el 19 de octubre de 2026, el grupo desplegó un robador de credenciales disfrazado de archivo de fuente en 94 repositorios comprometidos. Esta evolución permite a los atacantes cosechar datos sensibles incluso cuando GitHub bloquea sus flujos de trabajo automatizados.

Qué ocurrió

Los atacantes registraron el dominio "my-github[.]com" el 9 de octubre de 2026, apuntándolo a la dirección IP 193.32.204[.]199. Esta misma IP sirve como punto de exfiltración para los datos robados a través de GitHub Actions maliciosos. El día del registro, el grupo envió correos electrónicos de phishing que se hacían pasar por alertas de seguridad de GitHub a mantenedores de código abierto. Estos mensajes advertían sobre inicios de sesión sospechosos desde Moscú y dirigían a las víctimas a una página de inicio de sesión falsa. Esta página actuaba como un proxy inverso, capturando contraseñas y códigos de autenticación de dos factores mientras autorizaba silenciosamente una aplicación OAuth con permisos amplios para modificar flujos de trabajo y leer datos de la organización.

Una vez asegurado el acceso, los atacantes inyectaron archivos maliciosos en los repositorios. La campaña incluye un componente de segunda etapa diseñado para persistir en las máquinas de los desarrolladores. Esto implica confirmar una configuración de tareas de Visual Studio Code que se activa automáticamente al abrir una carpeta, un archivo de fuente falso que contiene una carga útil del robador y un flujo de trabajo de respaldo de GitHub Actions. El archivo de fuente, llamado "fa-solid-400.woff2", imita un activo legítimo pero en realidad cosecha claves de AWS, tokens de PyPI, tokens de npm, inicios de sesión de Git, credenciales de Kubernetes, claves SSH y credenciales de proveedores de IA como Anthropic Claude y Google Gemini.

Esta segunda etapa instala una tarea cron que ejecuta código proporcionado por el atacante cada cinco minutos si el robador inicial no logra ejecutarse. Los datos recopilados se transmiten mediante HTTP sin cifrar en el puerto 8080. OpenSourceMalware identificó 94 repositorios pertenecientes a 66 propietarios que contienen este componente de segunda etapa. Quince de estos repositorios han sido eliminados, renombrados o hechos privados desde entonces. La mayoría de los proyectos afectados parecen abandonados, ya que 65 de los 79 repositorios accesibles no muestran commits durante más de un año.

Detalles clave

• Los atacantes registraron "my-github[.]com" el 9 de octubre de 2026, utilizando la misma dirección IP que su infraestructura anterior de exfiltración.
• Los correos electrónicos de phishing se hicieron pasar por alertas de seguridad de GitHub, usando un proxy inverso para robar credenciales y autorizar aplicaciones OAuth sin el consentimiento del usuario.
• Un archivo de fuente falso llamado "fa-solid-400.woff2" contiene un robador dirigido a claves de nube, tokens y credenciales de proveedores de IA.
• El malware instala una tarea cron que se ejecuta cada cinco minutos para garantizar la persistencia y la exfiltración continua de datos.
• Se comprometieron 94 repositorios de 66 propietarios, con muchos proyectos que parecen abandonados o inactivos durante más de un año.
• GitHub comenzó a bloquear los flujos de trabajo maliciosos originales el 9 de octubre, lo que provocó el cambio hacia métodos de persistencia del lado del cliente.

Antecedentes

Los ataques a la cadena de suministro tienen como objetivo el ciclo de vida del desarrollo de software comprometiendo componentes o herramientas confiables. En este caso, los atacantes explotaron la confianza que los desarrolladores depositan en los repositorios de código abierto y entornos de desarrollo integrado como Visual Studio Code. Al disfrazar el malware como un archivo de fuente común, eludieron la inspección casual. El uso del phishing mediante el flujo de dispositivo OAuth es particularmente peligroso porque automatiza el proceso de autorización, otorgando a los atacantes tokens de API que pueden modificar la configuración del repositorio e inyectar más código malicioso.

Las tareas cron son tareas programadas que se ejecutan a intervalos fijos en sistemas tipo Unix. Aunque son esenciales para la automatización, pueden ser abusadas por los atacantes para mantener el acceso persistente a un sistema. Si se agrega un script malicioso al crontab de un usuario, puede ejecutarse repetidamente sin más interacción, asegurando que los datos robados continúen enviándose al servidor del atacante incluso si se elimina el vector de infección inicial.

Por qué importa

Para los equipos que ejecutan su propio software, este incidente destaca el riesgo de depender únicamente de los controles de seguridad a nivel de plataforma. La capacidad de GitHub para bloquear flujos de trabajo maliciosos no detuvo a los atacantes; simplemente pasaron a un método que opera en la máquina local del desarrollador. Esto significa que, incluso si su pipeline de CI/CD es seguro, las dependencias comprometidas o los repositorios clonados pueden introducir malware que roba credenciales de su entorno local. Estas credenciales a menudo incluyen acceso a la infraestructura de producción, lo que hace que la higiene local sea crítica para la seguridad general.

La orientación hacia repositorios abandonados o inactivos es una preocupación significativa para las organizaciones que bifurcan o dependen de proyectos de código abierto antiguos. Estos proyectos pueden carecer de mantenedores activos que puedan identificar y eliminar rápidamente los commits maliciosos. Si su equipo utiliza tales bibliotecas, puede introducir inadvertidamente puertas traseras sigilosas en su flujo de trabajo de desarrollo. El uso de HTTP sin cifrar para la exfiltración también sugiere que la monitorización de red podría detectar estos ataques, pero solo si el tráfico hacia IPs sospechosas se vigila de cerca.

Qué puede hacer

• Revogue todos los tokens de acceso de GitHub y cambie las contraseñas desde un dispositivo conocido limpio inmediatamente si sospecha una exposición.
• Audite sus repositorios en busca de archivos inusuales, especialmente en carpetas de activos públicos como fuentes, y verifique configuraciones inesperadas de tareas de VS Code.
• Rote todas las credenciales que puedan haberse expuesto, incluyendo claves de AWS, tokens de npm y claves SSH, especialmente aquellas almacenadas en variables de entorno.
• Monitorice sus tareas cron locales y tareas programadas en busca de entradas desconocidas que se ejecuten con frecuencia o se conecten a servidores externos.
• Alerta a cualquier usuario que haya clonado o bifurcado los repositorios afectados para asegurar que no propaguen el código malicioso.
• Implemente la monitorización de red para marcar el tráfico HTTP saliente hacia IPs o puertos desconocidos, como el puerto 8080, que fue utilizado en esta campaña.