GitHub API Abuse: How Ghost Accounts Are Mapping Organizations

Somebody might be poking around your GitHub repositories right now, and your team may have no idea. Security researchers recently found more than 50 dormant GitHub accounts, some inactive for close to 25 years, suddenly waking up to map developers, repositories, and projects inside real organizations.

Here at SWARECO, we spend our days building and scaling engineering systems for real companies, so this kind of quiet reconnaissance is exactly the sort of risk we watch for.

This piece breaks down how these campaigns actually work, the tricks attackers use to stay invisible, and the warning signs your team can watch for.

Analyzing Coordinated Threat Campaigns on GitHub

Threat actors run coordinated campaigns across GitHub by exploiting the platform's API and keeping networks of dormant "ghost" accounts on standby. These efforts map developer ecosystems, flag high-value repositories, and gather intelligence on organizations before any real attack even begins.

API Exploitation and Dormant Ghost Accounts

Coordinated campaigns lean on a clever trick: reactivating dormant accounts that sat untouched for two to five years. Old accounts look legitimate simply because they carry history, so security systems rarely flag them.

These accounts typically stay active for one to three weeks before going quiet again.

Account takeover through API abuse gives attackers a way to scrape public data, clone private repositories, and pull sensitive information out of restricted projects. Since the login looks clean and the API access is technically public, the activity blends right into normal developer workflows.

Summary Checklist for Detection and Mitigation:

• Monitor dormant account reactivation patterns.
• Review API usage and user agent baselines.
• Set up audit log streaming for real-time monitoring.
• Conduct regular threat hunts for anomalies.
• Analyze account history for unusual reactivations.

Why Detection Fails So Often

Most ghost accounts slide right into normal traffic patterns, which is why standard anomaly detection rules often miss reactivated accounts within their first 48 hours.

• Combining user agent baselining with sequence detection catches suspicious sessions within 72 hours, well before default monitoring would notice.
• Teams relying only on generic anomaly rules miss most coordinated reconnaissance activity.
• Attackers get weeks of undetected access to map developer networks and repository structures.
• Dormant accounts shield attackers from quick attribution, since the account itself looks like a real person.

Distinguishing a real developer from a compromised ghost account doing reconnaissance is one of the hardest calls a security team makes. Data scraping becomes invisible when it comes from an account that has existed quietly for years. Most vulnerability tools miss this entirely, because the account looks legitimate and the API calls seem routine.

Identifying Developers, Repositories, and Projects

Attackers use public API endpoints to build detailed maps of organizations, their developers, and their code. GitHub hosts over 420 million repositories and serves more than 150 million developers worldwide, which makes it a huge target.

Account enumeration allows bad actors to list organization members, discover repositories, and track starred projects, all via technically public endpoints. A single request from a ghost account looks harmless. It hits a public endpoint and gets a normal response.

The danger shows up when you zoom out. Each small request seems innocent on its own, but stacked together, they form a full blueprint of an organization's technical landscape.

Public API access includes endpoints for listing repositories, user lists, starred projects, and organization memberships, all reachable with basic authentication. That means an attacker can build a complete organizational map, including who works where and how teams interact, and this reconnaissance costs them almost nothing while leaving barely any trace in your logs.

Founders often overlook this exact vulnerability because the activity looks routine. Understanding how attackers map developers and repositories through the API sets up everything that follows: why detection is hard, and why defense matters so much.

Challenges in Detecting Malicious Activities

Malicious actors dress up their reconnaissance as normal developer activity, which makes them nearly invisible to standard security tools. They lean on GitHub's public API access and clean login habits to slip past the systems teams already trust.

Activities Masked as Legitimate

Threat actors have gotten good at blending in. Most of what security teams observe looks completely normal, which is exactly why it's so hard to catch.

A developer clones a repository. Another reviews code. Someone runs an API query.

These actions occur thousands of times a day across GitHub, so spotting a malicious request in that haystack feels nearly impossible. Coordinated campaigns hide easily because a single API call from an attacker looks no different from a normal developer's request.

Attackers lean into this cover by using accounts with a proven track record. The deception goes even deeper. Some tools are built to mimic known, trusted user agents, layering fake authenticity atop an already convincing disguise.

As highlighted in Verizon's 2025 Data Breach Investigations Report, stolen credentials serve as the initial access point in 88% of basic web application attacks. That single number explains why "clean" logins are so hard to catch. The requests use real accounts, familiar tools, and normal working hours, so nothing about them screams intruder.

Yet underneath that calm surface, coordinated teams are mapping organizations, identifying developers, and pulling sensitive data. Catching this kind of activity means looking past surface-level authentication and studying patterns, anomalies, and behavior baselines that reveal what's really happening.

Public API Access and Clean Authentication Tactics

The very openness that makes GitHub valuable is what makes it easy to abuse. Many API endpoints sit completely unguarded, no authentication needed at all.

Attackers use this to gather intelligence on developers, repositories, and projects without leaving obvious traces. Clean logins, or none at all, let their reconnaissance blend right into normal API traffic.

The most dangerous attacks are the ones that look completely normal to everyone watching.

Organizations struggle to distinguish between a developer querying public data and an attacker mapping their entire infrastructure. No passwords get stolen. No firewalls get breached. No alarms trigger.

Attackers use public repositories and organization memberships to build detailed maps of target companies, scraping information about team structures, dependencies, and technology stacks. Authorization gaps make this worse, since many endpoints expose information that probably should stay private, and none of it requires special access or elevated privileges.

Startups face a particular kind of risk here. Repositories often hold sensitive details about business strategy, customer lists, and technical roadmaps that competitors or bad actors actively hunt for.

Methods of GitHub API Abuse

Attackers exploit GitHub's API in a handful of consistent ways: scraping public data, cloning repositories, stealing tokens, and pulling information straight from private projects.

Scrape Public Data

Automated scanning tools collect information from public endpoints without ever tripping an alarm or needing account access. Campaigns gather intelligence about organizations, their members, and their project structures simply by mining public records at scale.

This data collection happens in plain sight, using API calls that look no different from normal developer activity. With over 420 million repositories on the platform, each one carrying publicly accessible details, automated tools have plenty to harvest.

Founders face real exposure here, since scraping public data requires no account compromise and no stolen tokens at all. An attacker just points automated tools at GitHub's public API and lets the mapping begin, learning which developers work together, what technologies your company uses, and how your teams interact.

This kind of reconnaissance almost always comes before something more serious. Watching for it is one of the earliest warning signs that someone is studying your company. Defense means proactive threat hunts, custom detection rules, and keeping an eye on unusual API access patterns before things escalate.

Clone Private Repositories

Attackers have successfully cloned private repositories by stealing credentials and authentication tokens outright. One documented campaign used a user agent named "repo-dumper" to systematically pull data out of private repositories through Git cloning and API requests.

Threat actors target organization repositories by listing them, fetching commits, and probing private repo paths to find valuable code and intellectual property. The trick works because legitimate developers use these exact same endpoints every day, so malicious activity blends right into normal traffic.

Founders face real exposure here. Attackers can grab proprietary algorithms and business logic without leaving obvious fingerprints behind.

Compromised tokens hand attackers the same access as a legitimate developer, letting them pull entire codebases and harvest sensitive configuration files. That risk grows when team members share tokens across projects or skip regular rotation.

Treat token management like your front door keys. Lose one, and someone walks right in. Defense means watching for suspicious user agents, setting baselines for normal API behavior, and streaming audit logs to catch unauthorized access before it spreads.

Compromise User Tokens

Once attackers get into private repositories, they shift focus to stealing the real keys to the kingdom: personal access tokens, or PATs. These tokens work like digital passwords, granting entry to sensitive data and code.

People expose PATs by accident all the time, leaving them in code, config files, or shared documents. Compromised systems leak tokens too, straight into the hands of people who know exactly what to do with them.

Each token unlocked access to data that should have stayed locked down. Threat actors then use those stolen tokens to move around GitHub freely, pulling data from private repositories without raising a single red flag, since the login itself looks completely clean.

Startups face particular exposure here, since smaller teams often reuse tokens across multiple projects or skip regular rotation. Based on IBM's latest Cost of a Data Breach report, breaches that start with compromised credentials cost U.S. organizations an average of $4.67 million and take a staggering 292 days to identify and contain. One leaked token can expose your entire engineering operation, your roadmap, and your competitive edge, and it can sit there undetected for the better part of a year.

Extract Data from Private Repositories

Compromised tokens open doors that attackers exploit with precision. Once they get valid credentials, they move fast to pull data out of private repositories, combining Git cloning with API requests to grab restricted content straight from protected storage.

It feels simple to them. It's devastating for founders and their teams.

A startup's private repository holds the crown jewels, and attackers know it. They use API calls that look completely normal, blending into everyday traffic and making detection genuinely hard.

Security gaps in token management create the opening, but repository theft happens through steady, patient extraction. Exposed or compromised tokens make unauthorized pulls disturbingly efficient, and attackers rarely need fancy tools. They just use the credentials they already have.

A founder's worst nightmare is discovering that a competitor or outside actor has copied months of development work. Credential leakage from a single developer's machine can compromise an entire codebase, and attackers often download repositories piece by piece specifically to avoid triggering alarms.

Attribution and Characteristics of Threat Campaigns

Threat actors deploy automated tools alongside networks of ghost accounts to run these campaigns, which makes attribution hard but not impossible. Here's how organizations start tracking these fingerprints.

Use of Automated Tools and Networks of Ghost Accounts

Malicious actors combine custom scanning tools with networks of dormant ghost accounts, some inactive for multiple years, and then reactivate them for specific operations.

Multiple overlapping campaigns run across many GitHub organizations at once, which suggests no single group controls all of it. Some focus purely on extracting data from private repositories. Others concentrate on mapping organizational networks.

With over 420 million repositories and a global developer base exceeding 150 million users, the attack surface here is enormous. Founders protecting their intellectual property need to understand how attackers combine automated systems with account manipulation, and reviewing your own audit logs to establish a baseline is the right place to start.

Scale creates opportunity for attackers. They blend their reconnaissance into legitimate traffic and build networks of ghost accounts that harvest data methodically, mapping repositories and locating private projects with real intellectual property inside.

Public API access means no special permissions are needed. Attackers authenticate cleanly, scrape freely, and disappear before detection systems even activate. The challenge grows because founders often prioritize shipping features over security monitoring, even though the infrastructure built today becomes tomorrow's target.

Developer Security Checklist:

• Monitor public API activity for unusual data scraping patterns.
• Strengthen token management practices.
• Regularly update and review access controls.
• Conduct frequent vulnerability assessments.

Geolocation Data Absence and Attribution Difficulties

Attackers hide their tracks by masking geolocation data, which makes it nearly impossible to pin down who's really running these ghost account networks. Here's how your team can fight back anyway.

Log Analysis for Requesting Actors and Token Usage

GitHub logs capture data founders can't afford to ignore: which actor made each request, and what type of token they used. That information becomes the foundation for spotting suspicious activity across an organization's repositories.

Since GitHub doesn't provide geolocation data for events tied to external resources, log analysis is really the only reliable path to detecting threats. Requesting actors and token usage patterns reveal when something's off.

A developer in New York shouldn't suddenly pull data from a private repository at 3 a.m. using a token that belongs to someone in California.

Log data exposes exactly this kind of inconsistency, giving security teams a chance to catch trouble before it spreads. Organizations that build custom detection around token usage gain a real edge in attribution, since logs show precisely which tokens accessed what resources and when.

Startups can set baselines for normal user agent behavior, then flag anything that deviates. This works because malicious actors often leave traces in the very events they generate, using automated tools that produce unusual request patterns no real developer would create. Streaming and hunting through audit logs proactively protects your systems from campaigns built to map your organization and extract sensitive data.

Attribution and Monitoring Checklist:

• Analyze logs for unusual token usage.
• Compare access times with expected geographic data.
• Validate user agent consistency.
• Establish behavior baselines for routine activities.

Strategies for Monitoring and Defense

Your organization needs practical defenses against GitHub API abuse. Teams that act now catch malicious actors before they finish mapping your developers and repositories.

Implement GitHub Audit Log Streaming

Audit log streaming is the foundation for real-time monitoring of suspicious activity across an organization's repositories. Founders should enable this feature to get detailed activity records showing exactly who accessed what and when.

Startup engineering leads can deploy a lightweight version of this quickly:

• Enable organization audit streaming and route events to a simple SIEM or log aggregator.
• Create three correlation rules targeting odd token usage, mass repository enumeration, and unfamiliar user agent patterns.
• Run a two-week pilot to surface a manageable set of investigation-worthy alerts.
• Watch specifically for mass enumeration patterns and suspicious token usage that default monitoring would miss.

Establish User Agent Baselines

Audit logs show what happened. User agent baselines show who's doing it.

Organizations need to track the tools and software developers typically use to access APIs. This baseline profiling reveals what normal operations actually look like, so when attackers use mimicked or legitimate-sounding tools, the baseline catches the imposter.

Founders should document what their teams actually use: browsers, SDKs, mobile apps, and internal tools. This documentation becomes the measuring stick for spotting anomalies later.

A developer using a Python script suddenly appears as a Windows automation tool? That's worth investigating.

Threat detection improves dramatically once these baselines exist early. Monitoring user agents catches activity that audit logs alone might miss, and organizations that skip this step leave themselves open to attackers who know exactly how to blend in. Startups especially benefit from setting baselines now, before infrastructure grows too complex to track easily. The effort takes days, not months.

Conduct Proactive Threat Hunts and Develop Custom Detection Techniques

1. Launch threat hunts focused on anomaly detection within GitHub audit logs, looking for patterns that deviate from established baselines.
2. Develop custom detection methods based on your own operational patterns, since attackers adapt faster than generic rules can catch them.
3. Monitor actor names and event activity for signs of ghost accounts doing reconnaissance, as Datadog researchers noted an uptick in tools mimicking known user agents.
4. Build incident response procedures that trigger when behavioral analysis flags suspicious token usage or API calls from unfamiliar regions or unusual times.
5. Run vulnerability assessments on how private repositories get accessed, checking whether clone operations correlate with suspicious authentication patterns.
6. Focus monitoring on three fields: user agents, event activity, and actor names, since attackers often leave traces here despite clean logins.

Mitigation Strategies for Startups with Limited Security Resources

Startups can protect their development practices by:

• Enabling audit log monitoring using simple log aggregators.
• Setting user agent baselines and reviewing alerts consistently.
• Implementing regular vulnerability assessments.
• Conducting focused threat hunts for abnormal API activity.
• Training team members to spot unusual patterns in API usage.

Conclusion

GitHub API abuse through ghost accounts is a serious threat that founders and startups can't afford to ignore.

Malicious actors reactivate accounts dormant for up to 25 years, then use them to map developers, repositories, and projects across organizations.

These campaigns scrape public data, clone private repositories, compromise tokens, and pull sensitive information out quietly, all while looking legitimate to anyone doing a quick check.

At SWARECO, we've seen firsthand that these defenses take relatively little effort to set up, yet deliver serious protection against coordinated campaigns like these. Startups that start monitoring their GitHub environments today put themselves ahead of the 95 percent of cyber campaigns aimed squarely at this platform.

Disclosure: This content is for informational purposes only and does not constitute professional cybersecurity advice. The data referenced includes reports by Datadog Security Research, Verizon's 2025 Data Breach Investigations Report, IBM's Cost of a Data Breach report, and Cofense Intelligence.