La trampa de la fuente falsa en GitHub: Cómo GhostAction secuestró 94 repositorios mediante sesiones OAuth
Análisis técnico del ataque a la cadena de suministro que convirtió repositorios abandonados y proyectos activos en ladrones de credenciales para desarrolladores.
Fecha de publicación: 2026.10.20
El asalto a la cadena de suministro que saltó de la nube al editor de código
La seguridad del desarrollo de software acaba de toparse con una táctica de evasión tan sencilla como peligrosa. La campaña bautizada como GhostAction ha dado un giro operativo drástico. Tras ser bloqueada por los filtros automáticos de GitHub en la nube, la ofensiva modificó su vector de ataque para infiltrarse directamente en los ordenadores de los programadores mediante archivos camuflados como fuentes tipográficas.
Hasta hace pocas semanas, el método de GhostAction consistía en secuestrar cuentas de desarrolladores de código abierto e insertar flujos de trabajo maliciosos dentro del directorio .github/workflows/. Cuando los servidores de integración continua de GitHub ejecutaban esos flujos, el script extraía los secretos del proyecto y los enviaba al servidor del atacante. Sin embargo, el 9 de octubre de 2026, la plataforma implementó contramedidas que neutralizaron la ejecución de estos flujos no autorizados.
Lejos de abandonar la operación, los atacantes respondieron en menos de una semana trasladando la carga de ataque a un terreno donde GitHub no tiene visibilidad directa: el entorno de desarrollo local (IDE) del programador. La investigación publicada por la firma OpenSourceMalware documenta cómo la campaña comenzó a distribuir un archivo malicioso disfrazado de fuente tipográfica. Al clonar o abrir el repositorio comprometido en editores como Visual Studio Code, el sistema ejecuta de fondo una tarea que instala un recolector de credenciales y programa una tarea en segundo plano cada cinco minutos.
Del secuestro de flujos en la nube a la infección del entorno local
Phishing con proxy inverso
Envío de alertas falsas de inicio de sesión desde Moscú para capturar contraseñas y códigos 2FA.
Autorización OAuth encubierta
Inyección automática de permisos de lectura y escritura sobre repositorios y organizaciones.
Bloqueo de GitHub en la nube
Los filtros de la plataforma impiden la ejecución de workflows maliciosos en GitHub Actions.
Salto al editor local (Fase 2)
Inyección de archivos que activan tareas automáticas y cron jobs locales camuflados como fuentes tipográficas.
Para lograr el acceso inicial, los atacantes desplegaron una campaña de ingeniería social dirigida contra mantenedores de paquetes. Registraron el dominio my-github.com y lo asociaron a la dirección IP 193.32.204.199. Desde la cuenta de correo noreply@my-github.com, enviaron mensajes advirtiendo sobre un supuesto acceso no autorizado a la cuenta de GitHub desde Moscú, Rusia.
Al pulsar el enlace para proteger su cuenta, la víctima era dirigida a un portal intermedio que actuaba como proxy inverso. Esta página clonada no solo robaba la contraseña y el código de doble factor en tiempo real, sino que también ejecutaba un script en JavaScript. Dicho script interactuaba de forma transparente con el flujo de autorización de dispositivos de GitHub (OAuth device flow), concediendo a una aplicación externa permisos con los alcances repo, workflow y read:org. De este modo, el atacante obtenía una clave de API legítima y reutilizable para alterar repositorios y consultar información corporativa sin levantar sospechas.
Cifras de la brecha: 94 repositorios vulnerados y 66 cuentas comprometidas
El análisis de la infraestructura expuesta revela que el atacante combinó técnicas de automatización masiva con descuidos operativos notables. OpenSourceMalware confirmó un total de 94 repositorios comprometidos que pertenecían a 66 propietarios diferentes.
Uno de los aspectos más reveladores del ataque es el estado de abandono en el que se encontraban la mayoría de los proyectos afectados. De los repositorios accesibles, 65 llevaban más de doce meses sin recibir una sola confirmación de cambios (commit), y uno de ellos permanecía inactivo desde hacía más de nueve años. Esta característica facilitó que el código malicioso permaneciera inadvertido durante días, ya que no había equipos activos revisando las ramas principales ni los cambios en las carpetas de configuración.
A continuación se detallan las diferencias operativas y técnicas entre la primera versión del ataque y la variante mejorada que saltó al entorno local:
| Parámetro técnico | Fase 1: Extracción en CI/CD | Fase 2: Infección en IDE local |
|---|---|---|
| Punto de ejecución | Servidores de GitHub Actions | Estación de trabajo local del desarrollador |
| Mecanismo de activación | Evento de integración continua (push/pull_request) | Apertura del proyecto en editores con tareas automáticas |
| Camuflaje del código | Archivo YAML en .github/workflows/ | Archivo ejecutable encubierto como fuente tipográfica |
| Persistencia | Dependiente de ejecuciones periódicas en la nube | Tarea programada (cron job) cada 5 minutos |
| Canal de exfiltración | Conexión TCP por el puerto 8443 | Petición HTTP simple por el puerto 8080 |
| Dependencia de la plataforma | Bloqueable mediante directivas centrales de GitHub | Fuera del alcance del control perimetral de la nube |
A pesar de la sofisticación del mecanismo de autorización OAuth mediante proxy inverso, los investigadores de seguridad señalaron que el operador de la campaña cometió errores de principiante. La misma dirección IP se utilizó tanto para alojar el phishing como para escanear internet y recibir los datos robados. Asimismo, el script de búsqueda de claves en variables de entorno omitía formatos habituales de claves de API y el rastreo de carpetas personales solía cancelarse por tiempo límite antes de enviar resultados. Aun así, la capacidad de ejecutar código en las máquinas locales de los desarrolladores convierte a esta campaña en una amenaza corporativa de primer orden.
Impacto operativo en las organizaciones: costes, retrasos y riesgo en la cadena
La transición de un ataque en la nube hacia el equipo personal o corporativo del empleado altera por completo el modelo de riesgo de los equipos de tecnología. Cuando un flujo de CI/CD malicioso se ejecuta en la nube, el radio de impacto suele limitarse a los secretos expuestos en ese repositorio particular. Cuando el ataque se instala en el equipo local, la superficie de exposición abarca toda la red corporativa.
1. Costes de respuesta a incidentes y auditoría forense
La presencia de una tarea programada local obliga a tratar el incidente como una intrusión de red completa y no como un simple problema de configuración de Git. Si un desarrollador descargó uno de estos 94 repositorios infectados, su equipo debe ser puesto en cuarentena de inmediato.
En términos económicos prácticos, una auditoría forense interna sobre una estación de trabajo comprometida exige entre 16 y 40 horas de trabajo especializado por máquina. Los analistas deben reconstruir el historial de comandos, analizar las conexiones salientes hacia la dirección 193.32.204.199 y revisar si las claves privadas SSH o las credenciales de AWS almacenadas en el directorio ~/.aws/ fueron extraídas. Si la organización utiliza soluciones de supervisión centralizada como Datadog, el equipo de seguridad puede rastrear anomalías en los registros de red y aislar los puntos finales antes de que el daño se extienda al resto del equipo.
Tiempo medio de respuesta según el vector de infección
Diferencia de horas requeridas para aislar y limpiar el incidente
2. Parálisis en los tiempos de entrega y bloqueo de dependencias
El segundo efecto tangible es la fricción en el ritmo de desarrollo. Cuando se descubre que un repositorio dependiente ha sido vulnerado, los equipos deben congelar los despliegues de producción para auditar las dependencias indirectas.
La necesidad de revocar tokens OAuth otorgados con alcances repo y workflow implica desvincular integraciones legítimas. Durante el proceso de revocación masiva, las tuberías de despliegue continuo se detienen hasta que se generan y configuran nuevos pares de claves. Para un departamento de ingeniería con 50 desarrolladores, este proceso suele provocar entre dos y tres días hábiles de productividad reducida, retrasando entregas comerciales y obligando a los líderes técnicos a destinar tiempo a labores de saneamiento manual.
3. Exposición de datos corporativos mediante permisos organizacionales
El aspecto más crítico de la variante observada en octubre es el uso del alcance read:org. Cuando la víctima aprueba el flujo OAuth sin saberlo a través de la página falsa, el atacante no solo puede modificar el código de los repositorios a los que el usuario tiene acceso directo; también adquiere visibilidad sobre la estructura interna de la organización.
Este permiso permite al adversario listar los miembros de la empresa, identificar quiénes administran los proyectos más confidenciales y trazar un mapa de relaciones internas. Con esta información, los actores maliciosos pueden diseñar campañas de suplantación mucho más precisas contra ejecutivos o ingenieros principales, ampliando el radio de alcance desde un proyecto de código abierto abandonado hasta la infraestructura de producción de una corporación entera.
Barreras técnicas y contramedidas para aislar el entorno de trabajo
La respuesta de GitHub, que desactivó la ejecución automática de los flujos maliciosos el 9 de octubre, demostró que las plataformas de alojamiento pueden aplicar filtros perimetrales con rapidez. Sin embargo, el surgimiento inmediato de la Fase 2 evidenció que la defensa en el servidor es insuficiente si los editores locales ejecutan instrucciones sin supervisión.
Para neutralizar este tipo de ataques, las empresas deben aplicar defensas en dos frentes simultáneos: restringir la confianza ciega en las herramientas de escritorio y limitar los permisos de las identidades de integración.
Supervisión perimetral en la nube vs. Control en el entorno local
Por qué los filtros de GitHub no protegen el ordenador del programador
Protección en GitHub (Nube)
Insuficiente- • Bloquea workflows abusivos en sus ejecutores
- • Revoca dominios de phishing conocidos
- • No puede ver los archivos clonados en tu disco local
- • No detecta tareas automáticas en editores de código
Defensa en el puesto local (Endpoint)
Indispensable- • Modo Workspace Trust activo en el editor
- • Bloqueo de peticiones salientes a puertos no estándar
- • Restricción de creación de cron jobs no firmados
- • Autenticación OAuth restringida por administradores
Un elemento indispensable consiste en activar de forma obligatoria el modo de espacio de trabajo seguro (Workspace Trust) en Visual Studio Code y herramientas afines. Cuando esta función está activada, el editor deshabilita la ejecución automática de tareas (tasks.json) y extensiones en cualquier carpeta descargada de internet hasta que el usuario confirme explícitamente que confía en los autores del código. De haberse aplicado esta política de forma estricta, el archivo malicioso disfrazado de fuente tipográfica jamás habría activado el recolector de datos ni configurado el cron job local.
Asimismo, las organizaciones deben bloquear a nivel de red las conexiones directas hacia direcciones IP individuales en puertos como el 8080 o el 8443 cuando se originan desde terminales de desarrollo, exigiendo que todo el tráfico de dependencias pase por servidores proxy corporativos con registro de actividad.
Protocolo de contención y saneamiento en tres líneas defensivas
Frente a campañas que combinan phishing de proxy inverso, abuso de tokens OAuth y malware local, las organizaciones no pueden limitarse a cambiar una contraseña. Es imperativo ejecutar un plan de contención estructurado que corte el acceso activo, limpie las máquinas locales y blinde los procesos de desarrollo hacia el futuro.
Secuencia obligatoria de saneamiento ante sospecha de compromiso
Pasos cronológicos para eliminar la persistencia de GhostAction
1. Desconexión y revocación
Revocar todas las aplicaciones OAuth y claves personales desde un dispositivo no infectado.
2. Limpieza de terminales locales
Revisar tareas de cron, procesos activos en puerto 8080 y carpetas de configuración del IDE.
3. Rotación de secretos y bloqueo
Sustituir variables de entorno de nube y activar Workspace Trust corporativo.
Primera línea de defensa: revocación inmediata de accesos y tokens OAuth
Cualquier intervención debe comenzar desde un dispositivo completamente limpio, nunca desde el equipo sospechoso de haber clonado los proyectos vulnerados:
- Auditoría de autorizaciones OAuth: Acceda al panel de seguridad de la cuenta de GitHub y examine la lista de aplicaciones de terceros con acceso a sus proyectos. Cualquier aplicación desconocida o agregada recientemente sin justificación documentada debe ser eliminada de inmediato. Preste especial atención a aquellas que posean permisos de administración de flujos de trabajo (
workflow) o visibilidad sobre la organización (read:org). - Invalidación de sesiones activas: Cierre todas las sesiones web activas y desautorice los dispositivos registrados mediante el flujo de códigos.
- Actualización de credenciales maestras: Cambie la contraseña principal y reconfigure la aplicación de autenticación de doble factor, asegurándose de generar nuevas claves de recuperación.
Segunda línea de defensa: auditoría de repositorios huérfanos y configuración de IDEs
El hecho de que 65 de los repositorios afectados llevaran más de un año sin mantenimiento demuestra que el código abandonado es el vector favorito para alojar infraestructura maliciosa:
- Búsqueda y eliminación de persistencia local: En cada ordenador donde se sospeche que se clonó uno de los repositorios afectados, revise el archivo de tareas programadas ejecutando
crontab -len la terminal. Identifique y elimine cualquier entrada que invoque comandos de red cada cinco minutos o que apunte a puertos como el 8080. - Inspección de procesos en ejecución: Compruebe si existen conexiones activas hacia la IP
193.32.204.199o hacia el dominiomy-github.commediante herramientas de inspección de red del sistema operativo. - Configuración obligatoria de espacios de trabajo seguros: Configure las políticas corporativas del editor de código para impedir la ejecución de tareas de fondo en repositorios no validados previamente por el equipo de seguridad.
Tercera línea de defensa: rotación de secretos y aislamiento de entornos CI/CD
Una vez neutralizados los accesos externos y desinfectados los equipos de trabajo, el equipo de ingeniería debe garantizar que ninguna clave filtrada siga operativa:
- Sustitución de claves de servicios externos: Asuma que cualquier clave de API, certificado de firma o credencial de acceso a la nube presente en las variables de entorno locales o en los secretos de los repositorios afectados ha quedado comprometida. Emita nuevas claves y destruya las anteriores en las consolas de sus proveedores de infraestructura.
- Restricción de permisos en GitHub Actions: Establezca permisos de solo lectura (
contents: read) por defecto en todos los repositorios corporativos. Ningún flujo de trabajo automático debe contar con autorización para modificar archivos del proyecto o solicitar nuevos permisos a menos que esté expresamente firmado por un administrador. - Política de saneamiento de dependencias inactivas: Implemente una regla estricta para auditar periódicamente los repositorios archivados o inactivos de la organización, revocando los permisos de escritura de cuentas que ya no forman parte de la plantilla laboral.