Ghost accounts explotan la API de GitHub para mapear repositorios y equipos internos

Introducción

Las cuentas fantasma no son solo un problema de limpieza de Active Directory: ahora operan como nodos de inteligencia en campañas de reconocimiento masivo. Desde octubre de 2025, actores maliciosos usan cuentas de GitHub registradas entre 2020 y 2023 —pero nunca utilizadas— para consultar datos públicos a través de la API sin autenticación. El objetivo no es acceder directamente a los repositorios (muchos son private), sino trazar el grafo completo de organizaciones, miembros, gists, repositorios estrella y relaciones entre usuarios. El dato clave: el 92 % de las solicitudes exitosas devuelven HTTP 200 sin fallos de autenticación, lo que permite a los atacantes mezclarse con tráfico legítimo de herramientas de CI/CD o bots de documentación.

El riesgo no está en el acceso inicial, sino en la escalada. Aunque Datadog reporta que solo el 3 % de los casos observados logró exfiltrar datos desde repositorios privados, la metodología combina tres vectores:

1. Enumeración masiva de endpoints públicos de GitHub (REST y GraphQL).
2. Abuso de credenciales filtradas para consultar rutas de commits privados en ventanas de minutos.
3. Clonación selectiva de repositorios descubiertos para análisis posterior offline.

Qué ocurrió

El patrón comenzó a ser monitoreado por Datadog a principios de 2025, pero la actividad escaló en octubre cuando se detectaron 50+ cuentas fantasma enviando tráfico coordinado a endpoints como:

• GET /orgs/{org}/repos
• POST /graphql con consultas anidadas para obtener miembros y repositorios privados a los que el usuario tiene acceso.
• GET /users/{user}/repos con parámetros de ordenamiento inusuales (?sort=created&direction=asc).

Lo distintivo es el user agent: herramientas como «ExfiltrationAnalytics/1.2.3» o «DashboardExporter/v4.1.0» que imitan tráfico legítimo de integraciones de analytics o logging. En un caso documentado, un atacante logró clonar 4 repositorios privados durante 8 minutos antes de que el sistema detectara actividad anómala en los logs de auditoría de GitHub.

El vector de credenciales filtradas apareció en otra campaña: los atacantes probaron tokens personales de desarrolladores legítimos (obtenidos de leaks en foros o brechas menores) contra rutas como GET /repos/{owner}/{repo}/commits con ventanas de 2 a 5 minutos. Aunque GitHub revoca tokens al detectar actividad sospechosa, el tiempo de ventana fue suficiente para mapear rutas de commits en 37 repositorios privados antes de que los propietarios recibieran alertas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e infraestructura

• Sobrecarga silenciosa en la API de GitHub: las cuentas fantasma generan tráfico en ráfagas de 1 a 3 semanas, con picos de 1.200 solicitudes/hora por cuenta. En organizaciones con repositorios públicos masivos (ej.: 5.000+ repositorios en una org), esto puede saturar cuotas gratuitas de la API (10.000 solicitudes/hora en el plan Free) y generar costos inesperados en planes Pro o Enterprise.
• Falsos positivos en herramientas de monitoreo: el 78 % de los user agents maliciosos coinciden con patrones de herramientas legítimas (Sentry, Datadog, GitHub Actions). Sin baselining previo, los equipos pueden ignorar alertas reales.
• Exposición de datos sensibles en metadatos: aunque los repositorios sean públicos, los nombres de ramas (feature/x-<uuid>), gists privados compartidos o forks internos revelan información sobre la estructura de equipos o proyectos en curso.

Para equipos de seguridad

• Reconocimiento previo a exfiltración: el 14 % de las campañas observadas avanzó de la enumeración a la clonación de repositorios. Aunque no se lograra acceso a contenido sensible, los atacantes pudieron:

– Extraer metadatos de commits para inferir calendarios de despliegue o responsables técnicos.

• Infección cruzada con malware: en un caso aislado, un repositorio clonado contenía un payload oculto en un workflow de GitHub Actions que intentaba descargar un binario malicioso desde un bucket de S3 público.

Métricas clave (según Datadog)

Componentes afectados

• GitHub API: versiones REST v3 y GraphQL v4 (todos los planes, incluyendo Free).
• Tokens personales: cualquier token con alcance repo o read:org emitido antes de 2024 y no revocado.
• User agents maliciosos: herramientas como «ExfiltrationAnalytics/1.2.3», «DashboardExporter/v4.1.0», «CI-Scanner/v2» o «LogShipper/0.9.8».

Vectores de ataque

1. Enumeración vía GraphQL:

   query {
     organization(login: "nombre-org") {
       membersWithRole(first: 100) {
         nodes { login }
       }
       repositories(first: 100, privacy: PRIVATE) {
         nodes { name }
       }
     }
   }
   

– Respuesta exitosa: HTTP 200 con datos de miembros y repositorios privados (si el token tiene permisos).

– Sin autenticación: los endpoints públicos como GET /orgs/{org} devuelven datos sin requerir credenciales.

1. Abuso de tokens filtrados:

     curl -H "Authorization: token ghp_<token-filtrado>" \
          https://api.github.com/repos/empresa/repo-privado/commits
     

– GitHub no bloquea solicitudes con tokens expirados o revocados de inmediato; el token sigue válido hasta que el usuario lo revoca manualmente.

1. Clonación de repositorios:

   git clone --depth 1 https://github.com/empresa/repo-privado.git
   

– Si el repositorio es privado, el clon solo funciona con credenciales válidas o tokens con alcance repo.

Detección y respuesta

• Logs de auditoría de GitHub: activar streaming a SIEM (ej.: Splunk, ELK) para correlacionar:

– Solicitudes a rutas privadas (/repos/{owner}/{repo}/commits) fuera de horarios laborales.

• Baselining de user agents: generar reglas basadas en patrones de herramientas legítimas. Ejemplo en Splunk:

  index=github sourcetype=github:api
  | stats count by user_agent, action, repo
  | where user_agent NOT IN ("GitHub-Hookshot/*", "Sentry/*", "Datadog/*")
  

• Alertas en tiempo real: configurar umbrales para solicitudes por minuto por IP/origen. Ejemplo en Datadog:

  - type: "threshold alert"
    query: "sum:github.api.requests{*} by {ip, user_agent}.rollup(sum, 60) > 100"
    message: "Posible enumeración masiva desde IP {{ip}} con user agent {{user_agent}}"
  

Qué deberían hacer los administradores y equipos técnicos

1. Auditar y revocar tokens expuestos

• Pasos concretos:

  # Listar tokens personales activos (requiere admin)
  gh api /user/codespaces/secrets | jq '.secrets[] | select(.expires_at < (now + 30d))'

  # Revocar tokens filtrados (ejemplo con GitHub CLI)
  gh auth list | grep "ghp_<token>" | awk '{print $1}' | xargs -I {} gh auth logout {}
  

• Herramientas: usar GitHub Token Scanning para detectar tokens en repositorios públicos antes de que sean usados por atacantes.

2. Configurar logs y alertas en GitHub

• Activar streaming de logs:

  # En .github/settings.yml (para orgs)
  features:
    audit_log: true
    stream_audit_log_to_external: true
  

• Reglas de alerta en SIEM:

|——-|———–|——–|

| User agent no reconocido + solicitud a ruta privada | Alta | Bloquear IP y notificar SOC |

| Clonación de repositorio privado fuera de horarios | Media | Revisar contenido del clone |

| 100+ solicitudes/minuto a /repos/ | Crítica | Activar rate limiting* en API |

3. Implementar rate limiting y WAF

• En GitHub Enterprise:

  # Configuración en GitHub Enterprise Cloud
  rate_limits:
    api:
      requests_per_hour: 5000  # Aumentar si es necesario
    graphql:
      depth_limit: 10
  

• En Cloudflare (si usan Cloudflare como proxy):

  # Reglas de WAF para bloquear user agents maliciosos
  [firewall_rules]
  expression = "(http.user_agent contains 'ExfiltrationAnalytics')"
  action = "block"
  

4. Educar a los equipos

• Talleres prácticos: mostrar cómo detectar cuentas fantasma con comandos como:

  # Buscar usuarios inactivos con más de 2 años de antigüedad
  gh api /orgs/{org}/members | jq '.[] | select(.updated_at < (now - 730d))'
  

• Guía de respuesta rápida: incluir pasos para aislar repositorios comprometidos y revocar accesos.

5. Monitorear repositorios clonados

• Herramientas: usar GitHub Advanced Security para escanear clones locales en busca de código malicioso.
• Automatización: ejecutar scripts como:

  # Escanear repositorios clonados en busca de *workflows* sospechosos
  find ./repos-clonados -name "*.yml" -exec grep -l "curl.*wget" {} \;
  

Conclusión

El abuso de cuentas fantasma en GitHub no es un problema de autenticación, sino de ingeniería social aplicada a la API. Los atacantes explotan la confianza en endpoints públicos y la falta de baselining en user agents para mapear infraestructura sin dejar huellas evidentes. La solución no es bloquear la API —es entender qué es «normal» en el tráfico de tu organización.

Los equipos deben priorizar:

1. Revocación inmediata de tokens expuestos (especialmente en repositorios públicos).
2. Baselining de user agents y correlación con logs de auditoría.
3. Automatización de alertas para detectar ráfagas de actividad anómala.

La ventana de detección efectiva es de 2 a 8 minutos desde el primer token probado. Pasado ese tiempo, los atacantes ya tienen datos suficientes para pivotar a otros vectores. La clave está en convertir los logs de GitHub en un sistema de detección temprana, no en un repositorio de incidentes pasados.