Accenture confirms breach after hacker offers stolen source code for sale

A hacker going by "888" put roughly 35GB of alleged Accenture data up for sale on 6 July, including source code, RSA keys, SSH keys, and Azure Personal Access Tokens. Accenture has confirmed it identified the source of the intrusion and remediated it.

The company's public statement says the incident had "no impact on its financial position or operations." That's the sort of line companies reach for after almost every breach, and it may well be true for Accenture's own bottom line. It says nothing about the clients whose access keys and code might now be circulating.

We covered the seller's original post separately in a seller claims to have 35GB of Accenture data. This is the follow-up: the company has now acknowledged an intrusion, and the question has moved from "is it real?" to "what exactly walked out?"

What is confirmed and what is only claimed

The split matters here, so it is worth being strict about it.

Accenture has not published a full technical breakdown of what was accessed versus what was merely claimed. Until it does, treat the hacker's claims as plausible but unverified in scope, while treating the confirmed intrusion itself as real.

Why access keys matter more than the headline number

A source code leak sounds bad but is often manageable. Code gets patched and rotated. Access tokens and SSH keys are a different problem: if any of those were live at the time of theft and haven't been revoked, they're a working set of house keys for whatever systems they unlock.

That is the whole difference between an embarrassing leak and an operational one. Source code tells an attacker how something works. A live key lets them walk in.

Each item on the alleged list carries a different risk:

• SSH keys give remote shell access to servers if the matching public key is still trusted. An unprotected private key needs no password at all.
• RSA keys can be used to sign or decrypt, depending on what they were issued for. A stolen signing key lets an attacker impersonate a trusted service.
• Azure Personal Access Tokens act as a stand-in for a password in Azure DevOps. They are often scoped broadly and left running for months because nobody wants to break a build pipeline.
• Source code can expose hard-coded secrets, internal URLs and design flaws, which is why it is rarely just "code".

None of this means any of those credentials worked at the time, or still do. That is exactly what Accenture's clients should be finding out.

Why consultancies are such attractive targets

Consulting and outsourcing firms hold two things attackers want. The first is client data: architecture diagrams, credentials, project documents and sometimes production copies of databases. The second is access. Staff at a firm like Accenture log in to many client environments, often through VPNs, shared accounts and delegated cloud permissions.

Scale makes this worse. Accenture's annual revenue is generally put at somewhere around $65 billion, which implies work inside a very large number of companies. Breaking into one well-connected supplier can be cheaper than breaking into dozens of hardened customers.

Money explains the rest. IBM's yearly cost-of-a-breach research has put the global average at roughly $4.88 million per incident in recent editions, and a firm holding other people's secrets can be pressured to pay or to keep quiet. Treat any single average loosely, as costs swing hugely by sector and country.

How a supplier breach spreads

Supply-chain incidents rarely stay with the first victim. The pattern is usually the same:

1. Attackers take credentials, tokens or code from a supplier.
2. They test those credentials against client systems, often quietly and slowly.
3. They move from a low-profile client to one with more valuable data.
4. The damage surfaces weeks or months later, often reported by someone else.

Well-known cases show how far this goes. The 2013 Target breach is widely reported to have started with credentials stolen from a heating and cooling contractor, and ended with around 40 million payment cards exposed. The 2020 SolarWinds compromise reached an estimated 18 thousand organisations through one tainted software update.

Industry breach reports keep pointing the same way. Verizon's recent data breach investigations report put third-party involvement at roughly 30% of breaches, up sharply on the year before, though methodology differs between studies.

Recent incidents on this site show the same shape. Security firms got breached through a vendor they all trusted in the Klue and Salesforce case. EY's breach exposed tax data, a reminder that professional services firms hold exactly the records attackers want. And Abbott is fighting off two hacking gangs at once, which shows how much phone-based social engineering is now part of the mix.

What Accenture's clients should do now

If your organisation uses Accenture for IT consulting, cloud migration, or managed services, ask your security team whether any shared credentials, API keys, or access tokens tied to the Accenture relationship have been rotated since 6 July. Don't wait for Accenture to tell you, ask.

A sensible order of work looks like this:

First 24 hours

• List every credential, key and token that Accenture staff or tooling could have touched. Include service accounts and pipeline secrets, not just named users.
• Rotate the high-risk ones first: SSH keys, Azure Personal Access Tokens, cloud API keys and anything with admin rights.
• Revoke old tokens rather than simply issuing new ones. A replaced token that still works is not a rotation.

First fortnight

• Review sign-in and audit logs for activity from unusual locations, new IP ranges or odd hours, going back well before 6 July. Intruders often sit inside a supplier for some time before they sell anything.
• Check repositories for hard-coded secrets and rotate any found.
• Ask Accenture in writing what client-related material, if any, was in the affected systems, and when you can expect an answer.
• Tighten contract language so that suppliers notify you within a defined window, not whenever they feel ready.

Longer term

• Give suppliers narrowly scoped, short-lived access instead of standing credentials.
• Require hardware-backed or passphrase-protected SSH keys.
• Put third-party accounts behind multi-factor authentication and conditional access policies.

What staff and individuals should do

Not every reader works in security, but most can help. Staff who worked with Accenture on a project should check whether they ever pasted a key or token into a ticket, wiki page or chat. If they did, say so. It is far better to rotate something unnecessarily than to find out later it was live.

Watch for follow-up phishing. After a breach, attackers often impersonate the affected company or a client's IT desk, and a convincing email that quotes real project names deserves extra suspicion. If a message asks you to approve a sign-in you did not start, refuse it and report it.

Finally, remember that "no impact on operations" and "no impact on you" are different claims. Accenture's statement covers the first. Only your own review can answer the second.

Key takeaways

• A hacker called "888" claims to have taken roughly 35GB of Accenture data on 6 July, including source code and access keys. That is a claim, and its scope is unverified.
• Accenture has confirmed the intrusion and says it identified and remediated the source. It says there was no impact on its financial position or operations.
• Live SSH keys and Azure Personal Access Tokens matter more than the code itself, because they can open real systems.
• Consultancies are valuable targets because they hold client data and have access into many companies at once.
• Clients should rotate and revoke shared credentials tied to Accenture now, then review logs from before 6 July.
• Ask Accenture for a written account of what was accessed, rather than relying on the public statement.