Hackers Turn 50+ Dormant GitHub Accounts Into Corporate Source Code Recon Network

Security researchers have uncovered coordinated campaigns that used more than 50 dormant GitHub accounts to map corporate organizations, repositories, users, and developer activity through GitHub’s API.

The activity was documented by Datadog Security Labs, which said the campaigns have been monitored since October 2025. The operators used automated scraping tools, long-inactive GitHub accounts, and in some cases compromised OAuth tokens or personal access tokens.

Most of the activity focused on public data and looked like ordinary API traffic. However, Datadog said some campaigns probed private repository paths, and one case showed successful private repository access through git clone and API requests.

What the GitHub reconnaissance campaigns did

The campaigns used GitHub’s public and authenticated APIs to collect information about organizations, repositories, developers, followers, gists, starred repositories, and activity patterns.

That information can help attackers build a map of a company’s engineering footprint. Even without private source code, public metadata can reveal developer identities, project names, language choices, open-source dependencies, security tools, and likely internal technology stacks.

The risk grows when public reconnaissance gets combined with stolen tokens. A token with access to private repositories can move an attacker from mapping to source code access.

Campaign element	Observed behavior	Why it matters
Ghost accounts	Dormant GitHub accounts created two to five years earlier were activated for API requests	Older accounts may look less suspicious than brand-new scraper accounts
GraphQL queries	Heavy use of GitHub’s /graphql endpoint	Allows bulk queries across organizations, users, and repositories
REST routes	Requests for repositories, followers, gists, org memberships, and starred projects	Supports organization and developer mapping
Compromised tokens	OAuth tokens and personal access tokens from legitimate users were abused	Can expose private paths if the token has sufficient access
repo-dumper	One observed case successfully accessed a private repository	Shows the activity can move beyond public reconnaissance

Ghost GitHub accounts helped attackers blend in

Datadog said the broadest activity came from networks of “ghost” accounts. These profiles were created two to five years earlier, remained inactive, and then suddenly began sending API traffic across multiple GitHub organizations.

The account names followed recognizable patterns. Examples included amazon-data-* accounts, kobalt* accounts, BirdWithDreams, BirdWithPlan, user432023, user412023, and several accounts in the *-orb family such as kuku-orb, lolo-orb, lulu-orb, ruru-orb, zouzou-orb, and meme-orb.

The accounts often stayed active for short bursts of one to three weeks before going quiet. That pattern can help attackers reduce the chance that one account accumulates too much suspicious history in a single organization.

Why GitHub’s API made the activity hard to spot

GitHub exposes large amounts of public repository and user metadata by design. That makes the platform useful for developers, researchers, and integrations, but it also gives attackers a legitimate-looking route for reconnaissance.

The GitHub GraphQL API documentation says GraphQL gives integrations a more precise and flexible way to retrieve GitHub data than traditional REST requests. That flexibility also makes it attractive for bulk organization and repository enumeration.

Datadog found that the heaviest request volume targeted /graphql, while REST API routes were used to list organization repositories, user followers, followed accounts, gists, organization memberships, user repositories, and starred repositories.

• /graphql for bulk organization, user, and repository queries
• /organizations/:organization_id for organization details
• /organizations/:organization_id/repos for organization repositories
• /user/:user_id/followers for follower mapping
• /user/:user_id/following for accounts a developer follows
• /user/:user_id/gists for gists
• /user/:user_id/orgs for organization memberships
• /user/:user_id/repos for user repositories
• /user/:user_id/starred for starred repositories

Suspicious user agents exposed the tooling

Several tools used user-agent strings that sounded like scraping or exfiltration utilities. These included GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, and GitHubAnalytics/1.5.

Other names looked more like analytics, dashboards, monitoring, or repository-inspection tools. Datadog also noted one campaign that used the simple user agent request, which stood out because the other campaigns usually used versioned names.

The user-agent patterns matter because many requests returned successful HTTP responses. Without looking at user agents, actors, token types, and private-resource access, defenders may mistake coordinated enumeration for normal API usage.

Indicator type	Examples	Defender use
User agents	GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, GitHubAnalytics/1.5	Hunt for custom scraper tooling
Commit-fetching agents	GitHub-Commit-Fetcher/1.3, GitHub-Commit-Fetcher/1.4, GitHub-Event-Fetcher/2.2	Investigate access to private repository commit paths
Private access tool	repo-dumper	Prioritize any private repo git.clone or api.request events
Hosting providers	3xktech[.]cloud, cherryservers[.]com	Review source infrastructure and ASN patterns

Stolen tokens turned recon into private-repo probing

Datadog also observed campaigns using tokens from legitimate GitHub users. The tokens may have been leaked, exposed accidentally, stolen from compromised endpoints, or obtained through another route.

Between late December 2025 and early January 2026, one campaign used compromised OAuth tokens and personal access tokens with a progression of user agents: GitHub-Commit-Fetcher/1.3, GitHub-Commit-Fetcher/1.4, and GitHub-Event-Fetcher/2.2.

The requests targeted private repository commit paths for a single organization within a short window. In that specific campaign, Datadog said the attempts failed, but the pattern showed clear intent to move beyond public enumeration.

One campaign accessed a private repository

The most serious finding involved a tool identified as repo-dumper. Datadog said the tool successfully took actions inside a private repository belonging to one organization.

The audit log captured the activity through git.clone and api.request events against private repository paths. Both GitHub accounts tied to that access had already appeared in earlier failed activity.

This detail changes the severity of the research. The campaigns were not only gathering public metadata. At least one moved into confirmed private repository access.

Why corporate source code teams should care

Public GitHub metadata can support later attacks even when it does not expose private code directly. Attackers can identify active developers, infer team structures, find high-value projects, and target accounts that appear tied to sensitive repositories.

The GraphQL API also lets legitimate integrations query complex relationships efficiently. Defenders should expect attackers to use the same efficiency for reconnaissance.

Source code teams should treat GitHub API activity as part of their attack surface. The most important signals are not only failed logins. Successful API requests to private resources, unusual token types, strange user agents, and abnormal cloning behavior deserve close review.

How to detect this activity in GitHub logs

GitHub organization administrators can use audit logs to review user and application activity. The GitHub audit log documentation says the audit log shows who performed an action, what action occurred, and when it happened.

Datadog recommends focusing on successful activity against private resources. Useful events include api.request, git.clone, and repo.download_zip when the repository is private and the access comes from OAuth tokens or personal access tokens.

Security teams should baseline normal user agents in their GitHub organization. Custom user agents may be legitimate for internal tooling, but sudden use of scraping-style names or unknown versioned tools should trigger review.

1. Enable GitHub audit log collection for organizations and enterprises.
2. Baseline normal user agents, actors, token types, and source ASNs.
3. Investigate successful api.request events against private repositories.
4. Investigate git.clone events for private repositories when access uses OAuth or personal access tokens.
5. Review repo.download_zip events for private repositories.
6. Search for user agents tied to repo-dumper, GitHub-Company-Scraper, and GitHub-Commit-Fetcher.
7. Check whether unusual activity comes from newly active old accounts or compromised legitimate accounts.

Audit streaming can help catch patterns faster

Organizations with large GitHub footprints need more than occasional manual log checks. Streaming audit and Git events into a SIEM or security data platform makes it easier to detect coordinated behavior across users, tokens, and repositories.

GitHub’s audit log streaming guidance explains how enterprise owners can stream audit and Git events data to external systems for monitoring and analysis.

That kind of streaming helps identify short bursts of activity, such as dozens of legitimate accounts using compromised tokens against one organization within minutes.

Token controls should be tightened

Compromised tokens are the main path from harmless-looking public enumeration to private repository probing. Organizations should review personal access token usage and limit which tokens can access organization resources.

The GitHub personal access token policy lets organizations restrict, allow, or require approval for token access to organization-owned resources.

Teams should also move away from long-lived broad tokens where possible. Fine-grained tokens, app-based access, approval workflows, and regular token reviews can reduce the blast radius if a developer workstation or secret store gets compromised.

• Require approval for fine-grained personal access tokens that access organization resources.
• Restrict classic personal access tokens where possible.
• Review OAuth applications with access to organization repositories.
• Rotate tokens tied to suspicious audit events.
• Use single sign-on enforcement and strong multi-factor authentication.
• Remove stale users, stale apps, and inactive tokens.

Recommended response for security teams

Security teams should first determine whether their GitHub organization has seen the listed user agents, ghost account names, suspicious hosting providers, or unusual private repository access.

The Datadog report provides a useful starting set of user agents and common routes. Teams should adapt those indicators to their own environment rather than relying only on exact string matches.

Recommended actions include:

1. Search GitHub audit logs for known suspicious user agents.
2. Review private repository clone, API, and ZIP download activity.
3. Identify requests made with OAuth tokens, classic personal access tokens, and fine-grained personal access tokens.
4. Investigate bursts of activity from many accounts against one organization.
5. Review actor names that match ghost-account naming patterns.
6. Check whether activity came from hosting providers linked to known abuse.
7. Revoke and rotate any token tied to suspicious access.
8. Notify affected repository owners if private paths were accessed.

Public metadata needs threat modeling

Companies often focus GitHub security on private repositories, secrets, and branch protection. Those controls remain important, but this campaign shows that public metadata also has intelligence value.

Attackers can use public repositories to identify build systems, security tools, package managers, cloud providers, developer habits, and maintainers. They can then use compromised tokens or targeted social engineering to pursue private data.

The organization audit log and GitHub audit log streaming should sit at the center of that monitoring strategy. GitHub’s token policy guidance can then help reduce the chance that stolen credentials turn reconnaissance into private source code access.

FAQ