A long-running reconnaissance campaign is showing how attackers can quietly abuse legitimate GitHub features to map organisations, identify developers and study software projects without immediately triggering obvious security alarms.
The activity involves networks of older, largely inactive GitHub accounts that suddenly begin making large numbers of API requests. These accounts are not necessarily breaking into GitHub itself. Instead, they are using publicly accessible endpoints to collect information at scale and, in some cases, moving on to private repositories when exposed credentials become available.
The campaign is a reminder that attackers do not always begin with malware or a direct intrusion attempt. Sometimes, the first stage is simply learning everything they can about a target.
What Are "Ghost Accounts"?
The accounts involved in the campaign were reportedly created between two and five years ago, but remained largely dormant for long periods.
Because these profiles are not newly created, they may appear more legitimate than disposable accounts registered immediately before an attack. Their age can help them blend into normal platform activity, especially when they are used gradually rather than all at once.
Once activated, the accounts begin sending automated GitHub API requests in short bursts, often lasting between one and three weeks.
More than 50 such accounts have reportedly been connected to overlapping activity targeting multiple organisations.
How Attackers Are Using the GitHub API
GitHub provides both REST and GraphQL APIs that allow developers, applications and automation tools to interact with repositories and account data.
A large portion of public GitHub information can be accessed without authentication. This includes information such as:
Because these requests retrieve publicly available information, they usually return normal HTTP 200 success responses. There may be no failed login attempt, authentication error or obvious security alert.
This makes the activity difficult to distinguish from legitimate development tools, dashboards, research projects or analytics services.
Why Public Information Still Matters to Attackers
Public repository information may not provide immediate access to an organisation, but it can reveal a detailed picture of how that organisation works.
By combining public API data, an attacker may be able to identify:
This information can later support phishing attacks, credential theft, social engineering or targeted attempts to compromise developer accounts.
For example, an attacker who knows which engineer maintains a critical project can create a more convincing fake security alert or repository invitation.
The reconnaissance may therefore appear harmless in isolation, but it can form the foundation of a much more targeted attack.
Activity Designed to Blend Into Normal Traffic
The attackers reportedly used user-agent names that sounded like legitimate analytics, data export or dashboard tools.
User agents identify the application or tool making a request. By choosing names that resemble ordinary development utilities, attackers may reduce the likelihood that the traffic will immediately appear suspicious.
Most of the observed requests were directed at GitHub's GraphQL interface, while others targeted REST API routes.
GraphQL is particularly useful for reconnaissance because it allows an operator to request multiple related pieces of information in a structured query. This can make large-scale mapping faster and more efficient.
The Campaign Sometimes Went Beyond Reconnaissance
Most of the observed activity appears to have focused on collecting publicly accessible information.
However, some incidents reportedly escalated beyond simple enumeration.
In one campaign, attackers used GitHub access tokens that had been unintentionally exposed by legitimate users. These credentials were then used to request commit-related information from private repositories through dozens of genuine accounts over a short period.
This is a much more serious development.
Once an attacker obtains a valid token, their activity may appear to come from a legitimate developer or service account. Depending on the token's permissions, they may be able to view private code, access commit history, download repository contents or interact with other GitHub resources.
In a small number of cases, attackers reportedly succeeded in extracting data from targeted organisations.
Why Leaked Tokens Are So Dangerous
GitHub tokens are commonly used by developers, scripts, CI/CD pipelines and third-party integrations.
They can become exposed through:
A token does not always provide full account access, but even limited permissions may expose sensitive source code or repository metadata.
The risk becomes greater when tokens are long-lived, have broad permissions or are connected to accounts with access to multiple repositories.
Organisations should therefore treat leaked tokens with the same urgency as exposed passwords.
Why Traditional Security Alerts May Miss This Activity
This campaign highlights a visibility problem.
Public API requests may look normal. Authenticated requests using a valid stolen token may also avoid typical login alerts because the credentials themselves are technically accepted.
As a result, defenders may not see obvious indicators such as:
The warning signs may instead appear in API behaviour, audit logs and user-agent patterns.
This means GitHub security monitoring needs to focus not only on whether a request succeeded, but also on whether the activity makes sense for the account, tool and organisation involved.
Watch for Unusual User-Agent Behaviour
User agents can provide valuable clues when investigating suspicious GitHub activity.
Security teams should look for:
A user agent alone is not proof of malicious activity. Many legitimate tools use custom names, and some applications change versions frequently.
The more useful approach is to compare the user agent with the account's normal behaviour, source location, repository access and timing.
GitHub Audit Logs Should Be Treated as a Core Security Source
Organisations using GitHub Enterprise should consider enabling audit log streaming so activity can be sent continuously to a security monitoring platform.
This allows security teams to retain more detailed records, correlate GitHub activity with other systems and create alerts for unusual behaviour.
Useful events to monitor include:
Without centralised logging, suspicious activity may only be discovered after code or data has already been taken.
Build a Baseline of Normal GitHub Activity
Every organisation uses GitHub differently.
A software company may generate thousands of automated API requests every hour, while a smaller business may use only a handful of repositories. Generic security rules may therefore generate too many false alarms or miss behaviour that is unusual for a specific environment.
Security teams should build a baseline covering:
Once this baseline exists, it becomes easier to identify behaviour that does not fit the organisation's normal pattern.
Reduce the Risk From Exposed Credentials
GitHub reconnaissance becomes much more dangerous when attackers obtain valid tokens.
Organisations should regularly scan repositories for exposed secrets and rotate any credential that may have been disclosed.
Other useful controls include:
Developers should also avoid placing secrets directly inside source code or configuration files committed to repositories.
Dormant Accounts Deserve Additional Attention
The use of older inactive accounts is one of the more notable aspects of this campaign.
Organisations should review whether dormant internal accounts, former contractors or inactive service users still retain access to private repositories.
An account that has not been used for months should not suddenly begin making large numbers of API requests without explanation.
Where possible, organisations should automatically remove or suspend access for inactive users and require a formal approval process before it is restored.
This reduces the number of forgotten accounts that attackers might exploit.
Public Repositories Still Need Security Review
A repository being public does not mean everything inside it is safe to expose.
Public projects should be reviewed for sensitive information such as:
Even when no secret is directly exposed, small pieces of information can be combined to create a detailed organisational map.
This is why public repository governance should include both code review and information exposure review.
Final Thoughts
The abuse of GitHub's API shows how ordinary platform features can become powerful reconnaissance tools when used at scale.
Most of the requests in this campaign targeted public information and did not exploit a vulnerability. That makes the activity harder to block because the attackers are often using GitHub exactly as it was designed—just for a malicious purpose.
The greater danger appears when reconnaissance is combined with leaked credentials. Once attackers obtain a valid token, they may be able to move from mapping an organisation to accessing private repositories and extracting sensitive data.
Defenders should therefore pay close attention to user-agent behaviour, dormant accounts, API activity, private repository access and unusual cloning patterns.
The most effective protection will not come from a single security rule. It requires strong audit logging, credential hygiene, behavioural baselines and regular threat hunting.
Public information may seem harmless when viewed one item at a time. In the hands of a determined attacker, however, it can become a detailed blueprint for the next stage of an intrusion.
Comments