Los investigadores de seguridad han descubierto campañas coordinadas que utilizaron más de 50 cuentas inactivas de GitHub para mapear organizaciones corporativas, repositorios, usuarios y actividad de desarrolladores a través de la API de GitHub.
La actividad fue documentada porLaboratorios de seguridad de Datadog, que dijo que las campañas han sido monitoreadas desde octubre de 2025. Los operadores utilizaron herramientas de scraping automatizadas, cuentas de GitHub inactivas durante mucho tiempo y, en algunos casos, tokens de OAuth o tokens de acceso personal comprometidos.
La mayor parte de la actividad se centró en datos públicos y parecía tráfico API normal. Sin embargo, Datadog dijo que algunas campañas exploraron rutas de repositorios privados, y un caso mostró un acceso exitoso al repositorio privado a través de solicitudes de API y clonación de git.
Qué hicieron las campañas de reconocimiento de GitHub
Las campañas utilizaron las API públicas y autenticadas de GitHub para recopilar información sobre organizaciones, repositorios, desarrolladores, seguidores, esencias, repositorios destacados y patrones de actividad.
Esa información puede ayudar a los atacantes a construir un mapa de la huella de ingeniería de una empresa. Incluso sin un código fuente privado, los metadatos públicos pueden revelar identidades de desarrolladores, nombres de proyectos, opciones de idioma, dependencias de código abierto, herramientas de seguridad y probablemente pilas de tecnología interna.
El riesgo aumenta cuando el reconocimiento público se combina con tokens robados. Un token con acceso a repositorios privados puede hacer que un atacante pase del mapeo al acceso al código fuente.
| Elemento de campaña | Comportamiento observado | Por qué es importante |
|---|---|---|
| Cuentas fantasma | Las cuentas inactivas de GitHub creadas entre dos y cinco años antes se activaron para solicitudes de API | Las cuentas más antiguas pueden parecer menos sospechosas que las cuentas scraper nuevas |
| Consultas GraphQL | Uso intensivo del punto final /graphql de GitHub | Permite consultas masivas entre organizaciones, usuarios y repositorios. |
| Rutas DESCANSO | Solicitudes de repositorios, seguidores, esencias, membresías en organizaciones y proyectos destacados | Admite el mapeo de organizaciones y desarrolladores |
| Fichas comprometidas | Se abusó de los tokens de OAuth y de los tokens de acceso personal de usuarios legítimos. | Puede exponer rutas privadas si el token tiene suficiente acceso |
| volcador de repositorios | Un caso observado accedió con éxito a un repositorio privado | Muestra que la actividad puede ir más allá del reconocimiento público. |
Las cuentas fantasma de GitHub ayudaron a los atacantes a integrarse
Datadog dijo que la actividad más amplia provino de redes de cuentas "fantasmas". Estos perfiles se crearon entre dos y cinco años antes, permanecieron inactivos y, de repente, comenzaron a enviar tráfico API a través de múltiples organizaciones de GitHub.
Los nombres de las cuentas seguían patrones reconocibles. Los ejemplos incluyeron cuentas de amazon-data-*, cuentas de kobalt*, BirdWithDreams, BirdWithPlan, user432023, user412023 y varias cuentas de la familia *-orb, como kuku-orb, lolo-orb, lulu-orb, ruru-orb, zouzou-orb y meme-orb.
Las cuentas a menudo permanecían activas durante breves períodos de una a tres semanas antes de cerrarse. Ese patrón puede ayudar a los atacantes a reducir la posibilidad de que una cuenta acumule demasiado historial sospechoso en una sola organización.
Por qué la API de GitHub hizo que la actividad fuera difícil de detectar
GitHub expone grandes cantidades de repositorios públicos y metadatos de usuario por diseño. Eso hace que la plataforma sea útil para desarrolladores, investigadores e integraciones, pero también brinda a los atacantes una ruta de reconocimiento aparentemente legítima.
ElDocumentación de la API de GitHub GraphQLdice GraphQL brinda a las integraciones una forma más precisa y flexible de recuperar datos de GitHub que las solicitudes REST tradicionales. Esa flexibilidad también lo hace atractivo para la organización masiva y la enumeración de repositorios.
Datadog descubrió que el mayor volumen de solicitudes estaba dirigido a /graphql, mientras que las rutas API REST se usaban para enumerar los repositorios de la organización, los seguidores de los usuarios, las cuentas seguidas, las esencias, las membresías de las organizaciones, los repositorios de los usuarios y los repositorios destacados.
- /graphql para consultas masivas de organizaciones, usuarios y repositorios
- /organizations/:organization_id para obtener detalles de la organización
- /organizations/:organization_id/repos para repositorios de organizaciones
- /user/:user_id/followers para mapeo de seguidores
- /user/:user_id/following para cuentas que sigue un desarrollador
- /usuario/:user_id/gists para esencias
- /user/:user_id/orgs para membresías de organizaciones
- /user/:user_id/repos para repositorios de usuarios
- /user/:user_id/starred para repositorios destacados
Varias herramientas utilizaban cadenas de agente de usuario que parecían utilidades de raspado o exfiltración. Estos incluyeron GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0 y GitHubAnalytics/1.5.
Otros nombres se parecían más a herramientas de análisis, paneles de control, supervisión o inspección de repositorios. Datadog también notó una campaña que utilizó la solicitud simple de agente de usuario, que se destacó porque las otras campañas generalmente usaban nombres versionados.
Los patrones de agente de usuario son importantes porque muchas solicitudes arrojaron respuestas HTTP exitosas. Sin observar los agentes de usuario, los actores, los tipos de tokens y el acceso a recursos privados, los defensores pueden confundir la enumeración coordinada con el uso normal de API.
| Tipo de indicador | Ejemplos | Uso del defensor |
|---|---|---|
| Agentes de usuario | GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, GitHubAnalytics/1.5 | Búsqueda de herramientas raspadoras personalizadas |
| Agentes de búsqueda de compromisos | GitHub-Commit-Fetcher/1.3, GitHub-Commit-Fetcher/1.4, GitHub-Event-Fetcher/2.2 | Investigar el acceso a las rutas de confirmación del repositorio privado |
| Herramienta de acceso privado | volcador de repositorios | Priorice cualquier evento de repositorio privado git.clone o api.request |
| Proveedores de alojamiento | 3xktech[.]nube, cherryservers[.]com | Revisar la infraestructura de origen y los patrones ASN |
Los tokens robados convirtieron el reconocimiento en una investigación de repositorios privados
Datadog también observó campañas que utilizaban tokens de usuarios legítimos de GitHub. Es posible que los tokens se hayan filtrado, expuesto accidentalmente, robados de puntos finales comprometidos u obtenidos a través de otra ruta.
Entre finales de diciembre de 2025 y principios de enero de 2026, una campaña utilizó tokens de OAuth y tokens de acceso personal comprometidos con una progresión de agentes de usuario: GitHub-Commit-Fetcher/1.3, GitHub-Commit-Fetcher/1.4 y GitHub-Event-Fetcher/2.2.
Las solicitudes tenían como objetivo rutas de confirmación de repositorios privados para una sola organización en un período breve. En esa campaña específica, Datadog dijo que los intentos fracasaron, pero el patrón mostró una clara intención de ir más allá de la enumeración pública.
Una campaña accedió a un repositorio privado
El hallazgo más grave involucró una herramienta identificada como repo-dumper. Datadog dijo que la herramienta realizó acciones con éxito dentro de un repositorio privado que pertenece a una organización.
El registro de auditoría capturó la actividad a través de eventos git.clone y api.request en rutas de repositorio privadas. Ambas cuentas de GitHub vinculadas a ese acceso ya habían aparecido en una actividad fallida anterior.
Este detalle cambia la gravedad de la investigación. Las campañas no solo recopilaban metadatos públicos. Al menos uno pasó al acceso confirmado al repositorio privado.
Por qué debería importarle a los equipos de código fuente corporativo
Los metadatos públicos de GitHub pueden soportar ataques posteriores incluso cuando no exponen código privado directamente. Los atacantes pueden identificar desarrolladores activos, inferir estructuras de equipo, encontrar proyectos de alto valor y apuntar a cuentas que parecen vinculadas a repositorios confidenciales.
ElAPI GraphQLTambién permite que las integraciones legítimas consulten relaciones complejas de manera eficiente. Los defensores deben esperar que los atacantes utilicen la misma eficiencia en el reconocimiento.
Los equipos de código fuente deben tratar la actividad de la API de GitHub como parte de su superficie de ataque. Las señales más importantes no son sólo los inicios de sesión fallidos. Las solicitudes de API exitosas a recursos privados, los tipos de tokens inusuales, los agentes de usuario extraños y el comportamiento de clonación anormal merecen una revisión detallada.
Cómo detectar esta actividad en los registros de GitHub
Los administradores de organizaciones de GitHub pueden usar registros de auditoría para revisar la actividad de los usuarios y las aplicaciones. ElDocumentación del registro de auditoría de GitHubdice que el registro de auditoría muestra quién realizó una acción, qué acción ocurrió y cuándo sucedió.
Datadog recomienda centrarse en actividades exitosas contra recursos privados. Los eventos útiles incluyen api.request, git.clone y repo.download_zip cuando el repositorio es privado y el acceso proviene de tokens OAuth o tokens de acceso personal.
Los equipos de seguridad deben realizar una referencia a los agentes de usuario normales en su organización de GitHub. Los agentes de usuario personalizados pueden ser legítimos para herramientas internas, pero el uso repentino de nombres de estilo scraping o herramientas con versiones desconocidas debería desencadenar una revisión.
- Habilite la recopilación de registros de auditoría de GitHub para organizaciones y empresas.
- Base de referencia para agentes de usuario normales, actores, tipos de tokens y ASN de origen.
- Investigue eventos exitosos de api.request en repositorios privados.
- Investigue eventos de git.clone para repositorios privados cuando el acceso utilice OAuth o tokens de acceso personal.
- Revise los eventos repo.download_zip para repositorios privados.
- Busque agentes de usuario vinculados a repo-dumper, GitHub-Company-Scraper y GitHub-Commit-Fetcher.
- Compruebe si la actividad inusual proviene de cuentas antiguas recientemente activas o de cuentas legítimas comprometidas.
La transmisión de auditoría puede ayudar a detectar patrones más rápidamente
Las organizaciones con una gran presencia de GitHub necesitan más que comprobaciones de registros manuales ocasionales. La transmisión de eventos de auditoría y Git a un SIEM o plataforma de datos de seguridad facilita la detección de comportamientos coordinados entre usuarios, tokens y repositorios.
de GitHubguía de transmisión de registros de auditoríaexplica cómo los propietarios de empresas pueden transmitir datos de auditoría y eventos de Git a sistemas externos para su monitoreo y análisis.
Ese tipo de transmisión ayuda a identificar breves ráfagas de actividad, como docenas de cuentas legítimas que utilizan tokens comprometidos contra una organización en cuestión de minutos.
Los controles de tokens deben reforzarse
Los tokens comprometidos son el camino principal desde una enumeración pública aparentemente inofensiva hasta el sondeo de repositorios privados. Las organizaciones deben revisar el uso de tokens de acceso personal y limitar qué tokens pueden acceder a los recursos de la organización.
ElPolítica de token de acceso personal de GitHubpermite a las organizaciones restringir, permitir o exigir aprobación para el acceso simbólico a los recursos propiedad de la organización.
Los equipos también deberían alejarse de los tokens amplios de larga duración siempre que sea posible. Los tokens detallados, el acceso basado en aplicaciones, los flujos de trabajo de aprobación y las revisiones periódicas de los tokens pueden reducir el radio de explosión si una estación de trabajo de un desarrollador o un almacén secreto se ven comprometidos.
- Requerir aprobación para tokens de acceso personal detallados que acceden a los recursos de la organización.
- Restrinja los tokens de acceso personal clásicos siempre que sea posible.
- Revisar aplicaciones OAuth con acceso a repositorios de la organización.
- Rotar tokens vinculados a eventos de auditoría sospechosos.
- Utilice la aplicación de inicio de sesión único y una autenticación multifactor sólida.
- Elimine usuarios obsoletos, aplicaciones obsoletas y tokens inactivos.
Respuesta recomendada para los equipos de seguridad.
Los equipos de seguridad primero deben determinar si su organización de GitHub ha visto los agentes de usuario enumerados, nombres de cuentas fantasma, proveedores de alojamiento sospechosos o acceso inusual a repositorios privados.
ElDatadog reportproporciona un útil conjunto inicial de agentes de usuario y rutas comunes. Los equipos deben adaptar esos indicadores a su propio entorno en lugar de depender únicamente de coincidencias exactas de cadenas.
Las acciones recomendadas incluyen:
- Busque en los registros de auditoría de GitHub agentes de usuario sospechosos conocidos.
- Revise la actividad de descarga de archivos ZIP, API y clones de repositorios privados.
- Identifique solicitudes realizadas con tokens de OAuth, tokens de acceso personal clásicos y tokens de acceso personal detallados.
- Investigue estallidos de actividad de muchas cuentas contra una organización.
- Revise los nombres de los actores que coincidan con los patrones de nombres de cuentas fantasma.
- Compruebe si la actividad provino de proveedores de hosting vinculados a abusos conocidos.
- Revocar y rotar cualquier token vinculado a un acceso sospechoso.
- Notifique a los propietarios de los repositorios afectados si se accedió a rutas privadas.
Las empresas suelen centrar la seguridad de GitHub en repositorios privados, secretos y protección de sucursales. Esos controles siguen siendo importantes, pero esta campaña muestra que los metadatos públicos también tienen valor de inteligencia.
Los atacantes pueden utilizar repositorios públicos para identificar sistemas de compilación, herramientas de seguridad, administradores de paquetes, proveedores de nube, hábitos de los desarrolladores y mantenedores. Luego pueden utilizar tokens comprometidos o ingeniería social dirigida para buscar datos privados.
Elregistro de auditoría de la organizaciónyTransmisión de registros de auditoría de GitHubdebería ocupar un lugar central en esa estrategia de seguimiento. de GitHubguía de política de tokensLuego, puede ayudar a reducir la posibilidad de que las credenciales robadas conviertan el reconocimiento en un acceso privado al código fuente.
Preguntas frecuentes
¿Qué encontró Datadog en las campañas de reconocimiento de GitHub?
Datadog encontró varias campañas superpuestas que utilizaban más de 50 cuentas inactivas de GitHub, herramientas automatizadas de extracción de API y tokens de acceso personal o OAuth comprometidos para enumerar organizaciones, repositorios y usuarios corporativos de GitHub.
¿Qué son las cuentas fantasma de GitHub?
Las cuentas fantasma de GitHub son cuentas que se crearon años antes, se dejaron inactivas y luego se activaron para una actividad API coordinada. En esta campaña, muchos tenían entre dos y cinco años antes de comenzar a realizar solicitudes entre organizaciones.
¿Las campañas accedieron a repositorios privados de GitHub?
La mayor parte de la actividad se centró en el reconocimiento de datos públicos, pero Datadog documentó un caso en el que una herramienta llamada repo-dumper realizó con éxito acciones git.clone y api.request contra rutas de repositorios privados.
¿A qué agentes de usuario de GitHub deberían estar atentos los defensores?
Los defensores deben estar atentos a agentes de usuario como GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, GitHubAnalytics/1.5, GitHub-Commit-Fetcher/1.3, GitHub-Commit-Fetcher/1.4, GitHub-Event-Fetcher/2.2 y repo-dumper.
¿Cómo pueden las organizaciones proteger los repositorios de GitHub de esta actividad?
Las organizaciones deben permitir la recopilación o transmisión de registros de auditoría, establecer una base de referencia de la actividad normal de la API, revisar los clones de repositorios privados y los eventos de API, restringir los tokens de acceso personal, aplicar MFA y SSO, y rotar los tokens vinculados a actividades sospechosas.