The Accenture claim: when the loot is 35 GB of source code — and the keys inside it

On July 8, 2026, a threat actor going by "888" posted on a cybercrime forum claiming to have taken roughly 35 GB from Accenture. The claimed haul is the interesting part: not customer databases, but source code, RSA keys, SSH keys, Azure personal access tokens, Azure Storage access keys, and configuration files, with a screenshot of a private Azure DevOps repository offered as proof. Accenture's response acknowledged an "isolated matter" whose source has been "remediated," without confirming that data was exfiltrated.

Fairness first: attacker claims are marketing, and until someone independently validates that archive, the numbers deserve skepticism. But the shape of the claim is worth studying regardless of how this particular story resolves, because it describes the most common failure mode in modern engineering organizations: repositories quietly become key rings.

A code leak is a credential leak

Ask what each claimed artifact type actually unlocks and the incident stops looking like intellectual-property theft and starts looking like an access package:

SSH keys — direct authentication to servers, jump hosts, and Git remotes. A passphrase-less key in a repo is a door that opens for whoever holds the file.
Azure personal access tokens — scoped like the developer who minted them: repos, pipelines, artifact feeds. PATs are long-lived by default and rarely inventoried.
Storage access keys — full read/write on storage accounts, independent of any user identity, invisible to conditional-access rules.
Configuration files — connection strings, service passwords, webhook URLs, internal hostnames: a map of the estate plus some of the keys to it.

That's why "source code stolen" is the wrong headline for incidents like this. Code can be rewritten; the credentials embedded in and around it keep working until someone finds and revokes every copy. The half-life of a leaked repository is measured in the lifetime of the longest-lived secret inside it.

Why this keeps happening to sophisticated companies

Nobody decides to store keys in Git. It accumulates: a config committed "just for the demo," a deploy key pasted into a README, a token in a CI variable that gets echoed into a build log, a .env that slipped past the .gitignore. Each one is small; a decade of them across thousands of repositories is 35 GB with keys in it. Accenture — a company that sells security consulting — has now had several public incidents since 2017. If it can happen there, the honest conclusion is that it happens everywhere, and the differentiator is how fast you can find and kill exposed credentials, not whether they exist.

The playbook if this were your repo

Treat a repository exposure as a credential incident from minute one:

Assume everything in the repo is burned. Rotate first, and investigate afterwards. Waiting to "confirm exfiltration" before rotating is how a leak becomes a takeover.
Inventory before you need it. Run secret scanners (gitleaks, trufflehog, GitHub secret scanning) across the full history, not just HEAD — deleting a key from the latest commit doesn't remove it from git log.
Shorten lifetimes structurally. Replace long-lived PATs and static storage keys with short-lived, identity-bound credentials (OIDC federation for CI, managed identities, SAS tokens with expiry). A key that expires in an hour is a much smaller story than one minted in 2023.
Fix the rotation channel too. The moment you rotate, the new secret has to reach a teammate or a deployment — and the reflex is to paste it into chat or email, recreating the original problem in a new location. Rotated credentials should travel through a channel that expires, can only be read once, and leaves an audit trail.
Watch for reuse. Exposed keys get tried. Alert on authentication from new networks with old credentials, and on PAT/API usage patterns that don't match the owning team.

The quiet takeaway

Whether "888" has 35 GB or 35 MB, the claim worked as an advertisement because everyone who read it recognized their own repositories in it. The fix isn't a heroic cleanup sprint once a headline lands — it's making long-lived, copyable secrets structurally rare: short lifetimes by default, scanning in CI, and sharing channels that self-destruct instead of becoming archives. Secrets should be boring, brief, and single-use. The ones that make headlines are always the ones that were allowed to live forever.