Dormant GitHub Accounts Hijacked for Corporate Source Code Reconnaissance

Key Takeaways

• Multiple coordinated campaigns are exploiting GitHub’s API for corporate reconnaissance.
• These operations utilize networks of dormant “ghost” accounts and compromised credentials to map organizations, repositories, and developers.
• While primarily focused on public data, some attackers have successfully accessed private source code repositories.
• The campaigns have been active since at least October, employing automated tools and evolving tactics.
• Organizations should monitor GitHub audit logs for unusual API activity, user agents, and token usage, particularly concerning private repositories.

Recent investigations have uncovered a series of sophisticated, coordinated campaigns leveraging dormant GitHub accounts to conduct extensive reconnaissance on corporate entities. These operations aim to map organizational structures, identify key repositories, and profile developers, primarily by exploiting GitHub’s public API.

Although the primary objective appears to be data collection from publicly available information, researchers have noted instances where threat actors attempted, and in rare cases succeeded, in gaining access to private source code repositories.

These campaigns have been active since at least October, exhibiting characteristics that suggest multiple overlapping operations rather than a single threat actor. Researchers observed the use of automated tools, compromised access tokens, and an intricate network of “ghost” accounts that had remained inactive for extended periods.

Many of these accounts were established between two and five years ago, lying dormant until they abruptly initiated a flurry of API requests targeting various GitHub organizations. This strategy of utilizing aged, inactive accounts likely serves to enhance the attackers’ perceived legitimacy, making their activities less suspicious than those originating from newly created accounts used for aggressive data scraping.

GitHub Accounts Hijacked for Corporate Reconnaissance

The accounts involved in these reconnaissance efforts often exhibited discernible naming patterns. Examples include prefixes such as “amazon-data-*” and the “*-orb” family, along with repetitive usernames like “BirdWithDreams,” “BirdWithPlan,” “user432023,” and “user412023.”

Datadog confirmed the participation of numerous such accounts in reconnaissance activities. These accounts typically operated for a brief period, often one to three weeks, before ceasing activity.

Attackers predominantly queried GitHub’s /graphql endpoint, which facilitates bulk requests for information pertaining to organizations, users, and repositories. They also utilized REST API routes to enumerate public repositories, organization memberships, followers, gists, starred projects, and user activity.

Given that much of this information is public, these requests frequently returned successful HTTP responses, often appearing as legitimate usage of the GitHub API. This collected data allows attackers to construct a comprehensive profile of a company’s developers, active projects, technology stack, exposure to open-source vulnerabilities, and potential targets for future compromise attempts.

Several campaigns employed suspicious user-agent strings, including “GitHub-Company-Scraper,” “GitHub-Scraper-Tool/1.0,” and “GitHubAnalytics/1.5.” Other tools attempted to mimic legitimate applications by incorporating names associated with analytics, dashboards, monitoring, or repository analysis.

One notable campaign used the simplistic user agent “request,” which stood out from the more common versioned tool names. Datadog also identified activities involving the compromise and abuse of OAuth tokens and personal access tokens.

Between late December and early January, credentials belonging to dozens of legitimate GitHub users were compromised. These stolen credentials were then used within minutes to access a single organization. Operators cycled through user agents such as “GitHub-Commit-Fetcher/1.3,” “GitHub-Commit-Fetcher/1.4,” and “GitHub-Event-Fetcher/2.2.” These requests aimed to list repositories, retrieve commit data, and access private repository paths.

While many attempts to access private repositories failed, Datadog documented one confirmed incident where a tool identified as “repo-dumper” successfully executed git clone and API actions against a private repository.

These campaigns underscore the critical role that publicly available GitHub metadata plays in supporting corporate reconnaissance, often preceding more direct attacks involving credential abuse or the theft of source code.

What You Should Do

• Enable GitHub Audit Log Streaming: Configure and actively stream GitHub audit logs to your security information and event management (SIEM) system.
• Establish API Activity Baselines: Develop a baseline of normal GitHub API activity within your organization to quickly identify anomalies.
• Investigate Suspicious Activity: Promptly investigate any successful API requests, Git clone operations, or ZIP downloads involving private repositories, especially if they originate from OAuth tokens or personal access tokens.
• Monitor User Agents: Look for unusual user agents, unexpected account activity, suspicious token types, and abnormal request volumes.
• Scrutinize Source Infrastructure: Pay close attention to requests originating from known hosting providers like 3xktech[.]cloud and cherryservers[.]com, which have been linked to malicious activity.
• Review and Rotate Tokens: Regularly review and rotate personal access tokens and OAuth tokens, ensuring they adhere to the principle of least privilege.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.