A threat actor listed 35 gigabytes of alleged Accenture source code, RSA keys, SSH keys, and Azure access tokens for sale on a cybercrime forum on July 7, 2026.
The seller, going by the handle "888," posted on PwnForums with an archive described as "just over 35gb of source codes." As proof, they shared a screenshot showing a clone of a private Azure DevOps repository named 121123_AtriasTalentAcademy, hosted under an accenture.com-associated production domain. BleepingComputer reported that the claimed archive includes source code, RSA private keys, SSH keys, Azure Personal Access Tokens, Azure Storage access keys, and configuration files. The full archive is listed for purchase.
Accenture responded on July 8. A spokesperson described the incident as "an isolated matter" that the company has "remediated its source," adding that operations and service delivery were not affected. What Accenture did not address: how access was obtained, whether the archive includes client code, whether the Azure tokens were rotated before or after the data was extracted, and whether any downstream Azure DevOps organization sharing scope with Accenture carries residual exposure. The company's statement closes the public disclosure with those four questions still open.
Those open questions carry weight. Azure Personal Access Tokens carry the same permissions as the developer account that generated them. A valid PAT can read repositories, trigger pipeline runs, push commits, and in some configurations access adjacent Azure services without any additional authentication step. If any token in the archive was still live when the data left Accenture's environment, the exposure extended to every Azure DevOps organization or project that token was scoped to reach. Two things in the reporting are worth pulling apart.
What scanners would have missed
The failure mode here is not obscure. Secrets committed to version control are a documented class of finding. Many SAST tools scan for patterns matching private keys, tokens, and connection strings. Most would have produced a result on this codebase.
The problem is what that result looks like. A SAST scanner flags a hardcoded Azure PAT with a severity score derived from pattern characteristics, not from the token's actual scope or validity. The finding says: "Hardcoded credential detected. Severity: Medium." Four things it does not say:
- Whether the token is still active.
- What Azure DevOps organization the token is scoped to.
- Whether that scope includes external client repositories.
- What an attacker could do next with a live token of that scope.
That gap between detection and exploitability is where this kind of breach lives. A triage team reviewing a medium-severity hardcoded-credential finding has no immediate reason to escalate it above the queue of CVEs from the weekly SCA scan. The finding sits. The token stays live. Someone outside the organization finds it first.
DAST does not close the gap. Dynamic scans target running applications, not version control systems. SCA tools scan for known-vulnerable packages, not cloud credentials embedded in configuration files. The tool-scope mismatch is not a failure of execution. It is structural.
What Sekura would have shown
In Sekura's pipeline, Phase 1 is white-box SAST. An agent reads source code and configuration files across the full repository surface, including files that are often excluded from production scanning: development configs, CI pipeline definitions, test harnesses, and internal tooling repos. It flags pattern matches for private keys, API tokens, and cloud credentials.
That starting point is the same as a conventional SAST scanner. The difference begins at Phase 3: dynamic probing. At that phase, Sekura's agents take the credential artifacts surfaced by Phase 1 and validate them against the live environment. For an Azure PAT, that means calling the Azure DevOps REST API with the token and returning exactly what it can do.
The resulting finding does not say "Hardcoded credential. Severity: Medium." It says: this PAT is valid, scoped to org X, has contributor-level access to three repositories, and a dry-run pipeline execution against a sandboxed endpoint confirmed write access. That is what proof-first looks like for this class of finding. A working demonstration, not a probability estimate.
The bigger pattern
Secrets in source control is not a new problem. It is a scaling problem. As organizations grow their Azure DevOps footprints, the number of repositories, service accounts, and long-lived tokens all increase faster than the processes designed to manage them.
Professional services firms carry an added surface. Their repositories often hold code written for clients, configuration shared across engagements, and tokens generated for CI pipelines that were not decommissioned after a project closed. A breach in that environment does not stay inside the firm's boundary.
I think the pattern visible in 2026 is that organizations with mature SAST programs still get breached through this class of finding because detection without validation produces a queue of work no one knows how to prioritize. The findings are there. The proof is not.
If you want to see what proof-first looks like on your own repository surface, see how Sekura compares to conventional scanners.