# Ghost Accounts Abuse GitHub API in Sophisticated Reconnaissance Campaign


Threat actors are leveraging abandoned GitHub accounts to conduct large-scale reconnaissance operations against organizations and their development infrastructure, according to research from Datadog. The campaign represents a novel approach to information gathering that exploits GitHub's permissive API design while evading traditional security detection mechanisms.


## The Threat


Multiple coordinated campaigns have been systematically abusing the GitHub API to enumerate organizations, map their repositories, identify team members, and in rare cases, exfiltrate proprietary code and sensitive project data. Rather than using newly created accounts that might trigger immediate suspicion, attackers are weaponizing "ghost accounts"—legitimate GitHub profiles that were registered two to five years ago but left dormant, allowing them to blend seamlessly with normal platform traffic.


The scope is substantial. Datadog researchers identified over 50 ghost accounts participating in the reconnaissance effort since at least October 2025, conducting API requests in coordinated bursts typically lasting one to three weeks. While the primary objective appears to be intelligence gathering, several incidents escalated beyond reconnaissance to successful data theft, signaling this is more than passive information collection.


## Background and Context


The campaign highlights a persistent gap in API security that often goes overlooked: publicly accessible data can be systematically harvested at scale without triggering authentication failures or obvious red flags. GitHub's architecture is designed to be open and collaborative, with large portions of the API surface intentionally available to unauthenticated users—a design choice that facilitates legitimate use cases like building GitHub integrations, conducting research, and discovering open-source projects.


Threat actors have learned to weaponize this openness. By operating through ghost accounts that appear legitimate on the surface, they can:


  • Enumerate all public repositories within target organizations
  • Map organizational structure and team membership
  • Identify developers and their project involvement
  • Discover potentially sensitive naming patterns or internal project structures
  • Locate exposed credentials or misconfigurations mentioned in repositories
  • Graph relationships between developers, organizations, and projects

  • The timing of this campaign suggests a deliberate reconnaissance infrastructure being built over months. The use of dormant accounts is a sophisticated tradecraft decision—old accounts with minimal activity history are far less likely to trigger automated abuse detection systems than freshly created profiles.


    ## Technical Details


    How the Reconnaissance Works


    GitHub's API design allows significant data enumeration without authentication. Key vulnerable endpoints include:


    | API Function | Data Exposed | Authentication Required |

    |---|---|---|

    | List organization repositories | All public repos, metadata | No |

    | Get organization members | Public team membership | No |

    | Enumerate user followers/following | Social graph | No |

    | GraphQL queries on public objects | Complex data relationships | No |

    | List gists and starred repositories | Historical activity, interests | No |


    Each request to these endpoints returns an HTTP 200 status code, generating no authentication failure signals that might alert defenders. This is by design—GitHub intentionally provides this data to facilitate legitimate discovery—but it creates an attractive intelligence-gathering surface for attackers.


    The Attack Pattern


    The observed campaigns employ a multi-layered approach:


    1. Account Preparation: Registering or acquiring legitimate GitHub accounts years in advance, allowing them to age naturally and build credibility.


    2. Reconnaissance Infrastructure: Deploying automated scanners that systematically iterate through API endpoints, targeting specific organizations or broader GitHub discovery.


    3. Credential Abuse: In some instances, leveraging leaked GitHub tokens from legitimate users to access private repository data without raising immediate suspicion about account behavior.


    4. Spoofed User Agents: Disguising scanners with user agent strings designed to mimic legitimate tools—dashboards, analytics platforms, data exfiltration services—making requests appear routine.


    5. Coordinated Bursts: Spacing requests in burst patterns rather than continuous activity, potentially to avoid rate limiting thresholds or statistical anomalies.


    Escalation to Data Theft


    While reconnaissance is the primary activity, Datadog documented rare but concerning instances where attackers progressed beyond passive mapping. Successful data exfiltration from private repositories was observed, suggesting that reconnaissance serves as a targeting phase for subsequent exploitation. This pattern aligns with standard attack workflows: gather intelligence, identify high-value targets, then execute deeper compromise.


    ## Implications for Organizations


    Exposure Beyond Visibility


    The campaign reveals a blind spot many development teams face: they often assume their GitHub organizations are secure because access controls are in place. What they miss is that reconnaissance happens entirely in the open, using legitimate API paths that appear indistinguishable from normal traffic. A developer running tools to analyze their own codebase and an attacker enumerating the same organization generate identical API traffic patterns.


    Supply Chain Risk


    Organizations should recognize that detailed GitHub reconnaissance maps not just their code but their technical strategy. Attackers can identify which frameworks your developers use, which libraries you depend on, which internal tools you've built, and how your teams are structured. This intelligence informs subsequent attacks—whether through dependency confusion, targeting vulnerable libraries your team actively uses, or social engineering specific developers known to work on critical projects.


    False Sense of Security


    Many organizations assume their private repositories are protected because they're not publicly listed. However, if an organization's membership or repository structure is enumerated, attackers gain context for targeted attacks that assume successful compromise of a legitimate developer account or exposure of deploy credentials.


    ## Recommendations


    Detection and Monitoring


    Organizations should implement the following detective controls:


  • Baseline normal behavior: Understand what typical GitHub API traffic looks like from your legitimate tools, CI/CD pipelines, and integrations. Significant deviations warrant investigation.
  • Anomalous user agent monitoring: Track requests using user agents that don't match your known tools or services. Requesters claiming to be "DataDashboard v2.1" or "AnalyticsBot" that you don't operate are red flags.
  • GraphQL query patterns: GraphQL requests are heavily featured in this campaign. Monitor for complex queries systematically iterating through organization data rather than fetching specific resources.
  • Audit log streaming: Enable GitHub's audit log streaming to your SIEM or log aggregation platform, enabling historical analysis and correlation.
  • Private repository access anomalies: Flag any requests to private repository paths from unexpected users or during unusual times.

  • Defensive Actions


  • Rotate exposed credentials: If you've ever committed a GitHub token to a repository (even briefly before deletion), assume it's been discovered. Rotate it immediately.
  • Review collaborator access: Audit who has been added to your organization recently, and verify all active tokens.
  • Implement IP allowlisting: For CI/CD systems and automated tools, restrict GitHub API access to known IP ranges.
  • Use fine-grained tokens: Deploy GitHub's newer fine-grained personal access tokens with minimal scopes rather than classic tokens with broad permissions.

  • ## HackWire Analysis


    This campaign represents a troubling evolution in reconnaissance tradecraft: the realization that defenders have become adept at detecting malicious infrastructure, so attackers are increasingly exploiting legitimate platforms and aged accounts to blend in. The ghost account strategy is particularly cunning because it inverts traditional abuse detection logic—old accounts with light activity histories appear *safer* than new ones, yet they're being weaponized precisely because of that camouflage.


    What makes this story urgent now is the pattern recognition. We're seeing similar tactics across multiple platforms: dormant social media accounts used for disinformation, aged email accounts for phishing, and now GitHub accounts for reconnaissance. It suggests a maturing ecosystem where attackers trade or bulk-purchase aged accounts specifically to defeat behavioral analysis systems.


    The broader risk many organizations are missing: GitHub reconnaissance isn't just about stealing code. It's about building a detailed map of your technical footprint—which developers matter, which projects are critical, which dependencies you rely on, which internal tools exist. This map then informs downstream attacks. A developer gets phished. A dependency gets poisoned. A deploy credential gets exposed. Each attack is more precise because it started with this reconnaissance phase.


    For defenders, the uncomfortable reality is that much of the reconnaissance traffic is indistinguishable from legitimate use. You can't block it at the API level without breaking real workflows. The only defense is baselining what normal looks like in *your* environment, then hunting relentlessly for the anomalies that fall outside that baseline. That requires treating GitHub audit logs with the same rigor you'd apply to network logs—not as an optional nice-to-have, but as core infrastructure telemetry.


    HackWire Editorial


    ## Related Coverage


  • Read more in our [Malware & Threats](https://www.hackwire.news/category/malware) coverage
  • Cross-reference with [Supply Chain Security](https://www.hackwire.news/category/supply-chain) and [Developer Security](https://www.hackwire.news/category/dev-security)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)