GitHub continues to be a scintillating target for attackers because it sits in the middle of the software supply chain and gives threat actors three things they crave: source code, secrets, and automated pipelines to run amok in.
Datadog Security Research has been tracking what it calls a “sustained pattern” of GitHub API abuse over the past several months that seeks to map organizations and their members. While individually these requests are “unremarkable,” they become dangerous when they move across environments for weeks at a time, and, worse, progress to full-out cloning. The biggest challenge is that they blend into normal API usage patterns.
GitHub has been a goldmine for criminals looking to breach organizations because many development lifecycles are insecure, said David Shipley of Beauceron Security. Typically, threat actors are after API keys and cloud secrets.
“Now with everyone being pushed to do more, faster, with AI agents coding, the treasure trove of secrets is likely even bigger,” he said. “In short, to steal a line from a previous gold rush of the analog era, ‘there’s gold in them thar hills.'”
Scott Miserendino, CTO at security and compliance company DataBee, agreed. “Github is the most popular source code repository for both open-source and enterprise projects,” he said. “Its sheer volume of projects, along with being home to some of the most popular and widely used software, make it a target.”
He noted that intellectual property theft such as the unauthorized cloning of private repositories can be used to gain use of proprietary software or find vulnerabilities that can be exploited.
A second popular attack involves searching for repositories containing default credentials to popular software. Using them, attackers may develop and test assaults on accounts that are present in production environments or come installed by default on certain appliances.
And, Datadog senior security engineer Julie Agnes Sparks wrote in a blog post, “the activity is not a single actor. Rather, it’s a blend of custom automated scanner tools, opportunistic abuse of leaked credentials, and coordinated networks of burner (ghost) accounts.”
A simple but effective way to map GitHub users
Sparks explained that a “large share” of GitHub’s API surface can be reached without authentication; it is public by design. Requests against APIs typically produce standard HTTP 200 responses.
This means a threat actor can build detailed maps of organizations, their public repositories, their members, who they follow, their starred repos, and projects they interact with. This traffic blends into normal API usage and thus does not seem suspicious, she said.
Furthermore, GitHub only collects geolocation data when a user interacts with private repositories, recording who they are and what access token they used, not when they interact with external resources. This limits geolocation and VPN/proxy-based attribution.
Typically, threat actors have performed automated scraping with custom or legitimate-sounding user agents, taking advantage of GitHub “ghost” accounts, profiles created anywhere from two to five years ago and left dormant.
This is an attractive method because, Sparks noted, “an account with a multi-year history reads as more legitimate than one registered the same week it starts scraping.”
Typically, these accounts are used for a “burst” of just one to three weeks across many enterprises at once, then usage stops. The researchers identified more than 50 ghost accounts across multiple user agents, clustered into families with names like user432023, user412023, or kobalt*.
Some campaigns did use the legitimate accounts of GitHub users who had inadvertently posted their OAuth tokens or personal access tokens (PATs), or have had their endpoints compromised or exposed in other ways.
Attackers use a mix of data exfiltration agents with names like GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0., and GitHubAnalytics/1.5,designed to blend into normal data analysis traffic. The bulk of requests target the open source query language /graphql, which is “well suited” for bulk queries across enterprises, users, and repositories, Sparks noted. Normal REST endpoints are used for org-mapping.
The focus of the campaigns was “narrow and consistent,” and the concern “lies in the aggregate,” Sparks said. In isolation, requests target public repositories without authentication and return successful responses. This rarely produces “meaningful access” into an enterprise’s repositories.
But a group of accounts moving in sync across shared GitHub accounts with versioned, custom tooling over a period of weeks represents more troubling and systematic behavior. She cited one event in which dozens of distinct, legitimate, but compromised GitHub user accounts made API requests to a single organization within a window of only a few minutes, although in that case the attack failed, because they targeted private repository commit paths.
How enterprises can protect their GitHub environments
Sparks pointed out that these behaviors can be hunted for and detected “if you are watching the right fields,” such as those identifying the user agent, token type, autonomous system number (ASN), or attempted action.
“User agents, event activity, and actor names are vital clues to unauthorized activity in your environment,” Sparks emphasized. She suggested reviewing unusual user agent behavior across GitHub audit logs, particularly for those that extend to private repositories where the platform also captures the IP address, actor name, and programmatic access type.
Enterprises should also enable GitHub audit log streaming, baseline user agents, and perform proactive threat hunting. Most importantly, she said, they should develop detections unique to their GitHub organization, noting, “It’s important to know what normal looks like in your environment.”
Simply put, added Miserendino, enterprises should be following security best practices, including enabling multi-factor authentication (MFA) on all accounts, performing periodic user access reviews, removing any unused or unneeded accounts, and scanning repositories for credentials stored in plaintext rather than in a secret store.
This article originally appeared on InfoWorld.