Reconnaissance is the first phase of any targeted attack. When infrastructure teams think about adversarial mapping, the focus often lands on network scanning and port enumeration. But a less obvious attack surface exists in plain sight: the GitHub API. Recent analysis from Datadog Security Labs documents coordinated campaigns systematically enumerating corporate GitHub organisations, repositories, and developer accounts through automated tooling that deliberately avoids triggering rate limits or detection.
How Ghost Accounts Enable Quiet Reconnaissance
The mechanics of these campaigns reveal a subtle but deliberate operational approach. Attackers do not use freshly created GitHub accounts—those would lack history and reputation. Instead, they acquire or reactivate dormant accounts, sometimes years old, which carry legitimate-looking activity graphs and commit histories. These ghost accounts blend seamlessly into GitHub's ecosystem. When paired with custom or legitimate-appearing user agents, API requests originating from such accounts do not immediately register as suspicious.
The alternative vector involves compromised OAuth tokens, either harvested through previous breaches, phishing campaigns, or social engineering. A token tied to a real developer account carries implicit trust and can bypass many detection heuristics that organisations apply to their API usage patterns.
Once equipped with these cover identities, attackers run automated scraping tools that query the GitHub API for organisation structure, team membership, repository names, commit histories, and visibility settings. The goal is not immediate exploitation but rather detailed mapping of a target's software development posture—identifying which repositories are public, which are private, what development practices are visible, and which accounts have elevated privileges.
Why Organisations Miss These Signals
The reconnaissance phase can persist for weeks without triggering conventional alerts. GitHub organisations often permit relatively high API call volumes, particularly for organisations with many developers. A dormant account making methodical queries across public metadata may not breach rate limits. Additionally, organisations frequently lack centralised visibility into who is querying their API and from where, especially if they have not configured audit logging at the organisation level.
The reconnaissance itself is non-destructive—no code is modified, no access is gained, no outbound exfiltration occurs. Standard SIEM tools tuned for breach indicators will not flag systematic API enumeration as anomalous, particularly if the requests come from established GitHub accounts with prior history.
Hardening GitHub as Critical Infrastructure
For infrastructure and security teams, GitHub access should be treated as a sensitive control point, not a public service. Several practical measures reduce the reconnaissance surface:
- Audit log retention and review: Enable GitHub organisation-level audit logging and ingest logs into a SIEM. Look for unusual API patterns—rapid enumeration of repositories, systematic querying of team membership, or requests from unexpected geographic origins.
- Personal access token rotation: Enforce regular rotation of personal access tokens and OAuth applications. Compromised tokens with age are more likely to be dormant in attacker hands.
- API rate limit monitoring: Configure custom alerts if API usage from any account or application approaches your organisation's rate limits, even if limits are not breached.
- Repository visibility controls: Reduce the metadata surface exposed to anonymous or low-privilege API callers. Consider restricting public repository listings if your threat model justifies it.
- Branch protection and code review policies: Even successful repository access is less valuable if code changes require review and approval. This is not reconnaissance defence but post-breach resilience.
The Larger Picture: Reconnaissance as a Persistent Threat
Reconnaissance campaigns like those documented by Datadog are often run months before any exploitation attempt. They represent a low-risk way for adversaries to identify high-value targets and understand their development workflows. For organisations hosting sensitive code—whether in private cloud environments, managed repositories, or offshore infrastructure—treating GitHub as a potential observation point is essential.
The use of ghost accounts and compromised tokens is not unique to GitHub. The same pattern appears in reconnaissance against cloud platforms, DNS services, and other APIs that organisations expose. The lesson is that any API you expose for legitimate developer use also exposes information to patient attackers. The defence is not to block access entirely but to instrument visibility, establish baselines for normal behaviour, and respond when those baselines shift.
Datadog's analysis serves as a reminder that infrastructure security extends beyond firewalls and network segmentation into the tools and workflows that developers depend on daily. Securing the supply chain means securing the infrastructure on which code is built, reviewed, and released.
