GITHUB IS THE C2 :: How Attackers Adopted Your Most Trusted Egress Destination
c2exfiltrationgithubliving-off-the-cloudsupply-chain
Block list traditional C2 infrastructure: pastebin.com, discord webhook endpoints, telegram bots, ngrok tunnels, the dynamic DNS providers attackers favor. The blocklists exist. Your egress proxy enforces them. Your SOC alerts on the rare violations.
Now read this sentence from a Wiz incident report on the Mini Shai-Hulud worm: "the stolen data is encrypted and exfiltrated to public GitHub repositories created on the victim's own account with the description 'A Mini Shai-Hulud has Appeared.'"
Over 1,100 such repositories were observed at the time of the disclosure.
That is the future of C2. It is already here.
The pattern
The classical detection model for exfiltration assumes the attacker needs to communicate with infrastructure they control. The defender enumerates that infrastructure — IP addresses, domains, ASNs — and blocks or alerts on traffic to it. This model worked when "infrastructure they control" meant rented VPS hosts and dynamic DNS records.
The model fails when the attacker chooses to communicate via infrastructure the defender cannot block.
Mini Shai-Hulud's exfiltration mechanism is elegant. The worm steals the victim's GitHub Personal Access Token from local config. It uses that token to create a public repository on the victim's own GitHub account. The stolen secrets — cloud credentials, npm tokens, SSH keys, environment variables — get encrypted and committed to that repository as a regular git push. The repository description is the campaign signature. The attacker's collection infrastructure scrapes GitHub for repositories matching that signature description.
From the network's point of view, this is indistinguishable from a developer pushing code to GitHub. Same destination — github.com. Same protocol — HTTPS with git-over-HTTP. Same authentication — the developer's own token. Same machine — the developer's own laptop or the CI runner the worm landed on.
You cannot block github.com. Every developer at your company uses it. Every CI job needs it. The platform is load-bearing infrastructure for modern software development.
Why this is structural, not tactical
You could argue this is a clever trick that will get filtered by GitHub itself. GitHub takes down the malicious repositories. The campaign signature gets blacklisted. The attackers adapt.
That is true, and also irrelevant. The attackers adapt to a different campaign signature. They use private repositories. They use Gists. They use GitHub Pages. They use the Issues API to write exfiltration data into issue comments. They use the Actions API. They use any of a hundred sub-features of a platform that intentionally provides extensive write access to authenticated users.
The same logic applies to every other platform engineers depend on. The pattern is portable.
- Slack webhooks as C2 channels. Most enterprises do not block outbound to slack.com.
- Discord webhooks as C2 channels. Some enterprises block; many do not.
- Google Drive / Dropbox / Box as exfiltration sinks. The traffic looks identical to a developer uploading a build artifact.
- Cloudflare Workers / Lambda functions hosted on infrastructure the defender's own organization uses for legitimate purposes.
- npm publishing as a covert channel — push a package version whose tarball contains exfiltrated data.
- Public S3 buckets in the same region the defender's own infrastructure lives in.
The unifying property: trusted egress destinations the defender cannot block without breaking their own engineers' workflows.
What does detection look like
If the destination is no longer the signal, the signal has to come from somewhere else. Behavioral analysis on what gets pushed, when, by which automation.
Practical instrumentation:
- Log every git push from CI runners and developer machines. Repository, branch, commit size, file types, push frequency. Establish baselines.
- Alert on new public repositories created on enterprise GitHub accounts. The Mini Shai-Hulud signature was a public repo where the victim does not normally create public repos.
- Monitor for git pushes to repositories the developer does not normally interact with. A developer who only ever pushes to internal repos suddenly pushes to a new public repo at 3am is the signal.
- Watch GitHub audit logs for token usage patterns. A token that has been doing standard CI publishes suddenly creates a new repository is the signal.
- Egress baselining at network level. Volume of outbound to github.com per host, per hour. Outliers are the signal.
None of these are single-source-of-truth indicators. All of them require effort to deploy and tuning to be useful. That is the cost of operating in a world where the attacker uses your infrastructure.
The future
This pattern is going to spread. The economics favor it. Attacker infrastructure costs money, attracts takedowns, and gets blocklisted. Defender infrastructure that the defender cannot afford to block is free, persistent, and indistinguishable from normal traffic.
The next generation of C2 will not be C2 in the classical sense. It will be application-layer abuse of platforms the defender depends on for business operations. Detection has to move up the stack to match.
If your SOC is still looking for DNS exfiltration to weird domains and TCP beacons to known-bad IPs, you are looking in the wrong place. Start logging what your CI pushes to GitHub. Today.
