SURIQ
Reconnaissance rarely trips an alarm, and that is the whole problem with the GitHub campaign Datadog Security Research disclosed this week. The traffic looks ordinary: years-old accounts, public endpoints, clean HTTP 200 responses, not a single failed login. There is nothing to patch, and for most of the activity, nothing you can reliably detect. Reading this as "block the scanning" burns the short window you have before the mapping turns into access. The moment worth your attention is not the enumeration. It is the point where a stolen token clones a private repository.
What Datadog actually found
Since October 2025, Datadog's researchers have tracked more than 50 dormant accounts taking part in coordinated GitHub API enumeration. The accounts were created years earlier, sat idle to avoid looking new, then woke up for short bursts of one to three weeks and moved across many companies at once. They follow recognizable naming patterns, including an amazon-data-* prefix, an -orb family such as kuku-orb and zouzou-orb, and throwaway handles like BirdWithDreams and user432023.
The queries hit GitHub's public API, especially the GraphQL endpoint, to pull organizations, repositories, members, follower graphs, gists, and starred projects in bulk. That surface needs no authentication and returns success codes, so the requests blend into normal developer and tooling traffic. Senior security engineer Julie Agnes Sparks said the operators run automated scrapers carrying either bespoke or innocuous-looking client identifiers, driving them through the ghost accounts or through OAuth grants and personal access tokens taken from real users. In a set of cases the activity went past public data: a client calling itself repo-dumper successfully cloned a private repository, with the audit log capturing the theft as a mix of git clone and API calls to private paths.
Why the recon half is a detection trap
The enumeration is engineered to be indistinguishable from legitimate use, and that defeats the obvious defensive instinct. Aged accounts sail past any "new account" heuristic. Public data means there is no failed-auth event to key on. If you write a detection for "someone is enumerating our org through the API," it will fire on every developer, every continuous integration job, and every dependency scanner that reads your public repositories. Datadog's own framing is that each request is unremarkable on its own, and the signal only appears in the aggregate: a cluster of accounts moving in sync across many companies.
That aggregate is real, but here is the part the coverage glosses over: seeing it requires a vantage point across many organizations at once. GitHub can correlate that from the platform side. A single customer looking at its own logs almost never can, because from inside one org the campaign is just a handful of ordinary-looking reads. So account age is the wrong trust signal to build on, and cross-org correlation is not a detection most defenders can run. Chasing the recon is effort spent on the one stage of this attack you are structurally least equipped to catch.
The signal that actually matters
Sort the activity by what your own audit log can prove, and the picture inverts. The mapping is noise you cannot separate from real traffic. The escalation is a high-confidence event, because cloning a private repository is not something a public, unauthenticated scanner can do. It needs a credential, and that credential leaves a specific fingerprint.
| GitHub activity | Audit-log fingerprint | Detection value |
|---|---|---|
| Public org, member, and repo enumeration via GraphQL | HTTP 200, no auth failure, public paths | Low: indistinguishable from normal developer and tooling reads |
| Bursts from aged "ghost" accounts | Legitimate account, years old, active 1 to 3 weeks | Low alone: defeats new-account rules, needs cross-org context you rarely have |
| Private repo clone or archive download via stolen token | git clone or zip download to a private path, programmatic OAuth or PAT, odd user agent | High: this is where you build the alert |
The alert to write keys on the escalation row: a clone or archive download against a private repository, where the access type is a personal access token or OAuth grant, and the user agent is one you have never baselined or the actor and source IP are new for that identity. Datadog points defenders at exactly this, streaming the audit log and building detections around anomalous user agents on private-repository access rather than the enumeration itself. The token-theft wave that fed these clones landed across the turn of the year, late December 2025 into the first days of January 2026, so the leaked credentials predate the enumeration bursts you would see now.
This is the reconnaissance stage of a kill chain you have seen before
Read on its own, org mapping sounds like harmless open-source intelligence. Placed in sequence, it is stage one. Map the organization to find the repositories and the people worth targeting, harvest or reuse a leaked token, then act inside the org as a trusted identity. We have already documented what stage two looks like. In Cordyceps, a free account pushed code as a trusted maintainer through a GitHub Actions flaw. In GitLost, a crafted public issue tricked an AI agent into leaking a private repository. This campaign is the quiet survey that makes those later moves precise.
The common thread across all three is that GitHub itself is rarely the thing that breaks. The pivot is an identity: a leaked token, a free account granted too much trust, an agent acting on attacker input. Which means the control that pays off is not a GitHub patch. It is treating every personal access token and OAuth grant as a live credential that will eventually leak, and shrinking what a leaked one can reach.
What to do this week
Four moves, in order of return. First, turn on audit log streaming if it is off, and baseline the user agents that legitimately touch your private repositories, so an unknown one stands out. Second, write the detection on the escalation, not the enumeration: private-repo clone or archive download by a token whose user agent, actor, or source IP is new. Third, work the token surface, because the whole escalation depends on a stolen credential: expire and tightly scope personal access tokens, prefer fine-grained tokens over classic ones, rotate OAuth grants, and hunt for tokens committed into code. Fourth, shrink the recon yield as attack-surface reduction: set organization member visibility to private, prune stale public repositories and forks, and check which internal-looking repos are public by accident.
None of this stops a stranger from reading what you have chosen to make public, and it is not meant to. The recon is going to happen and you will not see most of it. The goal is to make the enumeration return less, and to make sure the one action that actually costs you, a stolen token reaching into a private repository, is the loudest event in your log rather than the quietest.