Accenture Breach: Hacker Sells 35GB of Source Code

A cybercrime forum listing that surfaced on July 7, 2026 claims to hold 35GB of Accenture's internal engineering data, including source code, cryptographic keys, and cloud access tokens. The seller, a threat actor tracked as 888, backed the claim with a screenshot of a live git clone pulling from an Azure DevOps repository hosted under an accenture.com domain. Accenture confirmed to BleepingComputer that a breach occurred, but the consulting giant has not said how the attacker got in, and it has not confirmed whether any client data was touched.

For a firm that sells cybersecurity services to some of the largest banks and governments on earth, a leak of its own source code and cloud credentials is an awkward headline. It also raises a narrower question for any organization plugged into an Azure DevOps pipeline: if one leaked token can expose 35GB of proprietary code, what does your own token sprawl look like right now?

Key Takeaways

• Threat actor 888 began selling 35GB of claimed Accenture data on a cybercrime forum on July 7, 2026, priced as a one time sale payable only in Monero.
• The stolen data allegedly includes source code, RSA keys, SSH keys, Azure Personal Access Tokens, Azure Storage access keys, and internal configuration files.
• Screenshot evidence showed the actor cloning an Azure DevOps repository named "121123_AtriasTalentAcademy" under an accenture.com hostname.
• Accenture confirmed the breach to BleepingComputer but said "there is no impact to Accenture operations and service delivery," without disclosing the access method.
• This is 888's second attempt to sell Accenture data since 2024, and Accenture's third major extortion incident since the 2021 LockBit ransomware attack.

What Did the Hacker Steal?

The actor claims to have taken source code, RSA keys, SSH keys, Azure Personal Access Tokens, Azure Storage access keys, and configuration files, packaged into a 35GB archive. According to BleepingComputer's reporting, the forum listing framed the sale as a one time offer, accepted only in Monero, the privacy focused cryptocurrency that cybercrime marketplaces favor precisely because it resists transaction tracing. As proof, 888 posted a screenshot showing a curl request against a dev.azure.com endpoint followed by a git clone command targeting a repository named "121123_AtriasTalentAcademy," with the terminal output showing thousands of objects streaming in at high speed. BleepingComputer said it could not independently verify the full scope of what the actor actually holds, and Accenture has not confirmed the specific file counts or repository names involved.

How Did Accenture Respond?

Accenture acknowledged the incident but kept its statement to BleepingComputer narrow. The company said it is "aware of this isolated matter" and has "remediated its source," adding that "there is no impact to Accenture operations and service delivery." That answers almost nothing a security team would want to know: it does not say whether the attacker used a phished credential, an exposed token, or a vulnerable endpoint, and it does not say whether client environments or personal data appeared in the stolen archive. Accenture is a $65 billion consulting firm with access to systems across finance, government, and healthcare clients, so the gap between "isolated matter" and "no operational impact" carries real weight.

Why Are Leaked Azure Tokens and SSH Keys So Dangerous?

Leaked Azure Personal Access Tokens are dangerous because they often carry the same permissions as the developer who created them, letting an attacker read repositories, trigger pipelines, or push malicious commits without touching a password. Microsoft's own documentation recommends short expiration windows precisely because a PAT that never expires becomes a permanent skeleton key once it leaks. Azure Storage access keys extend that risk to entire data containers, RSA and SSH keys can unlock servers the moment they are copied off a compromised machine, and configuration files often reveal connection strings and hostnames that map a target's infrastructure for follow up attacks. A token dump like this one is less a single leak than a set of keys to several doors, some of which may lead into client networks that never agreed to the exposure.

Is This Different From Accenture's Last Two Breaches?

This is the third time in five years that Accenture has landed in a ransom or extortion story, and the pattern is escalating rather than repeating. In August 2021, the LockBit ransomware gang claimed to have stolen six terabytes of data and demanded a $50 million ransom, an incident Accenture said it fully recovered from using backups. In June 2024, 888 itself tried to sell a database Accenture said contained only three genuine employee records padded out to look like a breach of 32,826 people. This claim is different because the material, source code and live cloud credentials, is a more direct operational risk than a ransomware lockup or a stale HR spreadsheet. If the tokens in the archive are still valid, the exposure did not close when Accenture issued its statement, and any company sharing an Azure DevOps organization or code dependency with Accenture inherits part of that risk without appearing in a single headline.

What Should Enterprises and Developers Do Right Now?

Security teams do not need to wait for Accenture to disclose more before acting on their own exposure. A few concrete steps matter more than watching the forum listing for updates:

• Rotate every Azure Personal Access Token and Storage access key tied to shared repositories, third party contractors, or any vendor relationship that touches Accenture built code.
• Audit SSH and RSA key usage across build servers and CI pipelines, replacing long lived keys with short lived certificates where the tooling supports it.
• Set expiration policies on all PATs by default, following the scoped, time limited model Microsoft recommends, instead of issuing tokens that never expire.
• Scan source repositories for hardcoded secrets before they ship, the same failure mode that malware such as the Djinn Stealer, built specifically to harvest cloud and AI credentials, is designed to exploit.
• Watch for anomalous git clone volume or unusual data egress from DevOps organizations, which is exactly the telltale signature 888 published as proof in this case.

The underlying lesson extends past Accenture. Nissan's employee data was exposed through a separate zero day Oracle exploit earlier this month, and LastPass confirmed customer data stolen through a compromised vendor just weeks before that. Each incident traces back to a single credential or dependency that sat outside the victim's direct control, which is precisely the blind spot that token sprawl and long lived cloud credentials create at scale.

Accenture's statement may prove accurate, and the damage may end up smaller than 35GB of headlines suggests. But the company controlling the narrative is the same one now attached to three separate extortion claims since 2021. Until Accenture publishes a fuller account of what 888 actually took, the safest assumption for any organization with an Azure DevOps footprint is that the keys in this dump are real until proven revoked.

Sources: BleepingComputer, BleepingComputer (2021 LockBit breach), and Microsoft Azure DevOps documentation.