One Token, 88 Repos: Reading the Accenture PwnForums Listing

Author: Crimson7 Threat Intelligence Date: July 9, 2026 Version: 1.0 Classification: TLP Threat Type: Credential Leak / Data Broker Listing Severity: High (active, developing)

---

TL;DR: A threat actor named "888" is selling roughly 35GB of alleged Accenture data on PwnForums: source code, RSA/SSH keys, Azure Personal Access Tokens (PATs), and Azure Storage keys, pulled (they claim) from an Azure DevOps organization called LISTeamRepos. Accenture has confirmed "an isolated matter" without confirming scope, contents, or cause. We created an account on the forum, read the listing directly, and cross-referenced it against a six-million-line directory manifest the actor posted as proof. The access method is confirmed, a valid Personal Access Token used exactly as intended. How that token leaked in the first place is not.

---

One of the things we keep running into in this line of work is the gap between what a forum listing claims and what you can actually stand behind once you have read it yourself. Press coverage of this incident converged fast on the headline numbers, 35GB, source code, keys, tokens, and then mostly stopped there, because nobody outside the forum had read past the opening post. That gap is where this post lives.

A disclaimer before we go further, because it matters for how you should read everything below: this is passive observation, start to finish. We made an account on PwnForums to read the listing directly. We did not purchase, download, negotiate, or interact with any attacker-controlled infrastructure beyond viewing a public forum post. Nothing here came from exploiting anything.

What the Press Already Had

In practice, most of the coverage converged on the same three facts: a threat actor named "888," a ~35GB claim, and a proof screenshot showing an Azure DevOps repository clone. What it did not have was much beyond that. No outlet independently verified the data's authenticity, and none identified how "888" got in. One outlet (MarketScale) floated a theory involving automated credential-stuffing against an "isolated" internet-facing node, but no primary source corroborates it, so we are setting that one aside rather than building on it.

Accenture's own statement to press did not move things much further: "We are aware of this isolated matter, and we have remediated its source. There is no impact to Accenture operations and service delivery." That is a company confirming an incident occurred while declining to confirm almost anything about it: not the volume, not the contents, not how it happened.

Checking the Usual Channels

Before reading the thread itself, we ran the incident against our standard dark-web and paste-site monitoring: Telegram watchlist search, onion-crawl keyword hits, paste-site pattern matching. All three came back empty. That tells us the listing has not propagated past its original posting and the initial news cycle yet. It is worth another pass in a few days. Broker-listed breaches typically get mirrored once buyers start reselling or forum members start discussing.

We also checked infostealer-exposure data for accenture.com, and this is where we want to be careful not to overclaim. Accenture's ADFS and Office 365 federation login pages, the pages an employee actually authenticates against, show up repeatedly in infostealer logs, with the primary ADFS endpoint alone appearing over 14,000 times. That is cumulative data, not scoped to this specific incident, and it does not prove anything about how "888" got their access. What it does establish is that a plausible path, infected endpoint, harvested session or credential, pivot into a federated cloud identity, is technically live at Accenture rather than purely hypothetical. We flag it as context, not evidence.

Reading the Listing

The thread itself is titled, plainly, "Accenture Data Breach," posted by 888 on Monday, July 6, 2026 at 09:57 PM. The opening line does not waste time: "Hello PwnForums Community, Today I am selling the Accenture Data Breach, thanks for reading and enjoy!" This is followed by an Accenture-branded graphic and the same summary that had already made it into press coverage: 35GB of source code, RSA keys, SSH keys, Azure PATs, Azure Storage access keys, and configuration files, credited to "@888."

That much matched what we already knew. Two things in the thread did not.

The Proof-of-Access Text

The first was the proof-of-access text itself, command output the seller posted to demonstrate they were not bluffing:

curl -u :[REDACTED] "https://LISTeamRepos@dev.azure.com/LISTeamRepos/121123_AtriasTalentAcademy/_apis/git/repositories?api-version=7.1"
{"value":[{"id":"6f97dad5-474b-4afb-ba51-1179b4bb168c","name":"121123_AtriasTalentAcademy", ...
"project":{"id":"2d8fa395-f0a0-400e-ae05-a942675817fe","name":"121123_AtriasTalentAcademy",
"description":"This repository is for Atrias Talent Academy and its production URL is
https://[REDACTED].[REDACTED].accenture.com/AtriasTalentAcademy/", ... "revision":1505, "visibility":"private"} ...
git clone https://LISTeamRepos@dev.azure.com/LISTeamRepos/121123_AtriasTalentAcademy/_git/121123_AtriasTalentAcademy

That curl -u :<PAT> construction is a specific, recognizable pattern: Azure DevOps REST API authentication via HTTP Basic Auth, empty username, Personal Access Token in the password field. It is not fuzzer output and it is not an exploit chain. It is what a working credential looks like in a terminal. Whatever else is uncertain about this incident, the access method is not: this was a valid PAT, used exactly as Microsoft's own documentation says a PAT should be used, against an organization called LISTeamRepos. As far as we can tell, that org name had not surfaced in any public reporting before now.

Worth sitting with for a second: the repository shown as proof is a modest 61.8MB. Against a 35GB claim, that is roughly 0.2% of the total. Either the PAT in question has read access across a lot more of LISTeamRepos than one training-portal repo, or the 35GB includes things well beyond bare git history.

The Manifest

That is where the second artifact answered the question. The seller also posted a directory-tree manifest, 251MQ.txt, a Windows tree-style listing, 6,173,917 lines, CRLF line endings, covering the full contents of what they claim to have. We want to be precise about what this is: filename and path metadata only. No file bodies, no credential or key values appear in the manifest itself. Everything below is what a directory structure tells you, not the contents of the files inside it, and we are holding that line firmly through the rest of this section.

The 88 root-level project folders, in full:

ABCtalent_Staging                  ABCuniversitystaging_node          Agile_staging@2
Agile_Staging_Node@2                AO_Staging_Node@2                  ASPIRA-FY24
ATCGN                                ATCGN_Staging                      AtriasAcademy
CommsBuilder_Prod                    communityoflearning@2              communityoflearning_Node
CyberImmerseElite_Node               DBAccess                           DevAgent
DevAgent_Node                        DevOps_Staging                     DevOps_Staging_Node
DLF_NODE                             DLF_Staging                        Dlf_Staging_Node
EITAcademy                           eitacademy_staging                 EIT_Oracle_Calendar
EIT_Portal_NODE                      EIT_Salesforce_Calendar            FordTalentAcademy_prod
Ignite@2                             Ignite_Node                        INDstaging_Node@2
IRC_prod                             L-TT                               leadershipprpgram_staging_node@2
LKMIND_Staging                       LKM_Portal_React                   LOA_Agent_node_prod
LOA_Agent_Prod                       LTTMicrosite                       LTTMicrosite_staging
LTT_Microsite_node                   LXTracker@2                        lxtracker_staging_Node
MSE_Node                             oracle-calendar_Staging            PM_Node
PM_staging_Node                      prject_tracker@2                   ProjectManagement_Staging
project_tracker_Node                 propel_academy_prod                QA_NODE
QIP                                  Sage_Node                          salesforce-calendar_Staging
SAPAscend                            sapascend_node                     SAPAscend_Staging@2
Sapcalendar_NODE                     SapFlipbook                        Sapflipbook_staging
SAPHEC                               Securitylearnings                  Securityportal_Staging@2
ShellUniversity                      SI_Node                            Si_Staging_Node@2
SRE                                  SRE_nodes                          SRE_staging
SRE_Staging_Node@2                   SSL-Mapping                        SSLRenewal2
SSL_CSR_Generation                   SystemIntegration_Staging          Talk_Native_react
techcore_staging                     Techcore_Staging_Node              Techexpressway
Techexpressway_NODE                  Techexpressway_Staging             techexpressway_staging_Node
TT-ServiceDesk_Staging               TTAutomation                       TTServiceDesk_Node
TT_NODE                              TT_Staging                         TT_Staging_Node@2
VodafoneAcademy-Node

Each of these 88 folders carries build/, node_modules/, and uploads/ subdirectories. That is not what a git clone produces. That is what you get from copying deployed application directories wholesale, dependency trees, build artifacts, and uploaded files included. It is also a plausible explanation for how one 62MB source repo becomes a 35GB claim once you are grabbing everything sitting next to it on disk.

The 88 names sort into some recognizable clusters, and they matter because they push this well past "a training portal got popped":

• Client-branded academies, suggesting third-party/customer blast radius, not just Accenture-internal: FordTalentAcademy_prod, ShellUniversity, VodafoneAcademy-Node.
• PKI/certificate tooling: SSL-Mapping, SSLRenewal2, SSL_CSR_Generation, more on this below.
• SAP-adjacent: SAPAscend, sapascend_node, SAPAscend_Staging@2, SAPHEC, Sapcalendar_NODE, SapFlipbook, Sapflipbook_staging.
• Oracle/Salesforce calendar integrations: EIT_Oracle_Calendar, EIT_Salesforce_Calendar, oracle-calendar_Staging, salesforce-calendar_Staging.
• AtriasAcademy, same project family as the 121123_AtriasTalentAcademy repo named in the proof screenshot, though the manifest does not contain an exact string match for 121123 or AtriasTalentAcademy (the substring 121123 appears once, inside an unrelated hash string). Same-family, not confirmed identical, repo/path.
• Largest subtrees by line count: SAPAscend/SAPAscend_Staging@2 (~160.7K lines each), FordTalentAcademy_prod (~154K), DevOps_Staging (~150.6K), CommsBuilder_Prod (~142K), LTTMicrosite/LTTMicrosite_staging (~138.5K), AtriasAcademy (~138.3K), L-TT (~138K), SRE/SRE_staging (~136.7K), Talk_Native_react (~136.4K), LKM_Portal_React (~134.9K), QIP (~134.6K), ATCGN_Staging (~133.4K).

Those are not training-content repos in every case. Several are integration tooling for enterprise systems, which is a different, generally more sensitive, category of exposure than "here is our onboarding curriculum."

What Did Not Pan Out

Skimming a six-million-line manifest for anything meaningful means running keyword sweeps first, and most of what those sweeps turn up is noise. We want to publish this table specifically so nobody downstream mistakes a raw hit count for a real finding:

2,677 hits for the string "password" sounds alarming until you actually open the paths. It is not 2,677 exposed passwords. It is a lesson in reading past the grep output.

What Did

Two folders sat outside node_modules and referenced real Accenture infrastructure, and unlike everything in the table above, these held up:

+---SSLRenewal2
|   |   cert.zip
|   |   cert.zip.base64
|   |
|   \---extracted
|       \---atci_lkmlearningconquerors_accenture_com_1526538498
|               atci_lkmlearningconquerors_accenture_com.crt
|               DigiCertCA.crt
|               INSTALL_INSTRUCTIONS.en.txt / .es.txt / .fr.txt / .it.txt
|               TrustedRoot.crt
|
+---SSL_CSR_Generation
|       atci.lkm.staging.accenture.com.csr
|       csr_script.sh
|       output.log

This reveals two real internal subdomains, atci.lkmlearningconquerors.accenture.com and atci.lkm.staging.accenture.com, new attack-surface data points alongside the ADFS/O365 federation hosts already noted above. The cert.zip/cert.zip.base64 pair and a DigiCert-issued cert chain (DigiCertCA.crt, TrustedRoot.crt) point to a working certificate-renewal automation pipeline. No private key (.key) file appears in this project, and CSR and cert files alone do not expose the private key, but csr_script.sh and output.log (contents unknown to us) are exactly the kind of artifact that could reveal how and where the corresponding private key gets generated or stored, if anyone with lawful access to the archive ever reads them. This is the single most concrete piece of new technical exposure the manifest surfaces. Everything else either corroborates the actor's broader claims or rules out noise.

The Rest of It

The manifest also shows 154 non-vendored .env-family files scattered across most of the 88 projects, filenames only, contents unknown, but consistent with the seller's "configuration files" claim:

On the lower-sensitivity end: .xlsx (many), .csv (32), .docx (60), .pdf (83), sampled paths are overwhelmingly training-program operational data: session calendars, a "Lateral Training Calendar," Oracle/Salesforce calendar exports, skill-level rosters (Azure Competent.xlsx, React Expert.xlsx, and similar), and sample/dummy templates (Dummy_1.xlsx, adminFileDummy.xlsx). Two names stand out as worth a closer look if archive access is ever lawfully obtained: UserRoles.xlsx and UserRoleFile.xlsx, potential access/permission data, though we cannot confirm which project they belong to from the filename alone.

The file-extension breakdown confirms what the folder structure already implied:

.js 2,786,373 · .ts 1,092,630 · .json 651,395 · .map 215,417 · .md 139,513 · .mjs 47,499 · .flow 39,796 · .png 35,096 · .cjs 29,343 · .mts 22,174 · .cts 20,654 · .svg 18,774 · .yml 12,266 · .css 6,192 · .po 5,986 · .eslintrc 5,840 · .txt 4,254 · .html 3,616 · .scss 3,511 · .tsx 3,209 · .jsx 2,864

Millions of .js/.ts/.map files means this manifest is dominated by installed node_modules dependency trees, not hand-authored project code. The signal that matters is entirely in the non-vendored files itemized above.

Where this leaves the external picture: a forum listing by "888" on PwnForums, offering access tied to an Azure DevOps organization named LISTeamRepos, demonstrated through a valid PAT and an 88-project directory manifest spanning training platforms, SAP/Oracle/Salesforce integration tooling, and PKI automation, with at least two real internal Accenture hostnames confirmed via leaked certificate-automation artifacts, and zero corroborating chatter yet on Telegram, paste sites, or the onion-crawl index we monitor.

The Attack, As Far As We Can Tell

Here is our honest read of what happened, with the inferred parts clearly marked as inferred.

Somewhere before July 2026, a Personal Access Token for the LISTeamRepos Azure DevOps organization ended up in the hands of someone willing to sell it, either "888" directly, or an initial-access broker "888" bought from. We do not know which, and we do not know how the token was obtained. What we can say is that the mechanism is consistent with what a lot of cloud breaches look like in 2026: not a novel exploit against Azure DevOps, but a valid credential doing exactly what it was scoped to do, in the wrong hands. The infostealer-exposure check earlier in this post shows Accenture's federated login surfaces are actively targeted by stealer malware, a plausible route for a PAT to leak, whether directly (stored in a config file on an infected developer machine) or indirectly (a stolen session used to mint or view a new token). That is a plausible path, not a confirmation, and we do not want to blur that line.

Once inside, the actor did not stop at one repository. The PAT's access apparently spanned the organization broadly enough to pull deployed application directories, not just source, but node_modules, build output, and uploads, across at least 88 separate projects. That is consistent with either a broadly-scoped PAT or a compromised identity with organization-level read permissions, rather than a narrowly-provisioned service credential. Among what came out: a working certificate-renewal pipeline referencing real internal hostnames, and something like 150+ environment-configuration files whose contents remain unknown to us but which the actor claims include Azure Storage keys.

What happens next is the open question, and it is Accenture's to answer, not ours: whether any of the PATs, SSH keys, or storage keys named in the listing are still live, and whether "isolated matter, remediated" means the specific token was revoked or the underlying access path was actually closed.

Who Is Behind "888"

Confidence: moderate on the identity of the seller, low on anything about how the intrusion happened.

"888" is not a mystery handle. Their PwnForums profile backs that up in plain numbers: joined August 2023, "Kingpin" rank, 2,646 posts across 213 threads, and a reputation score of 4,469, on top of an active red "Moderator" badge. That is not a burner account trying to bluff its way to credibility with a single flashy post. It is a long-tenured, high-reputation figure in this specific corner of the ecosystem, previously a moderator on the ".as" forum before it folded, part of the same wave of forum operators who resurfaced after BreachForums' disruption.

Their track record includes claimed breaches at Microsoft, BMW Hong Kong, Shopify, Shell, Decathlon, Credit Suisse, Heineken, and UNICEF, and, notably, this is not even their first run at Accenture. In June 2024 they claimed a 32,826-record employee data leak that Accenture disputed, saying the real exposed data amounted to three names and email addresses.

That history cuts two ways. It confirms "888" is a real, active player with a genuine sales channel, this is not a first-timer bluffing for reputation. It also means "888" has a documented pattern of overstating scope, which is exactly why we are not taking the 35GB figure or full contents claim at face value without independent verification, even with the manifest evidence in hand.

What we cannot say anything about is who is actually behind the handle. No malware family, no C2 infrastructure, and no tracked TTPs are associated with "888" in any threat-intelligence platform we checked. This is a broker persona, not a technical intrusion crew with a fingerprint. That is consistent with the access method observed here: buying or otherwise acquiring a working credential does not require the kind of tooling that leaves the forensic trail an intrusion group's malware would.

Timeline

Where This Fits

Nothing about the technique here is new. Stolen or leaked Personal Access Tokens turning into full-repository (or full-organization) compromise is one of the most consistent stories in cloud-native development shops, and Azure DevOps, GitHub, and GitLab all share the same underlying exposure: a PAT is a bearer credential, often long-lived, often broader in scope than the task it was issued for, and routinely the first thing an infostealer or a careless .env commit hands to an attacker.

What makes this one worth a longer look is the follow-on math. A single leaked token did not just expose one project. If the manifest evidence holds up, it exposed 88 of them, spanning internal tooling, PKI automation, and what look like client-branded platforms built for at least three other named companies. That is the actual lesson here, more than anything specific to Accenture: the blast radius of a single over-scoped DevOps credential is an organizational question, not a per-repository one. If your PATs can read everything your team can read, one leaked token is equivalent to compromising your whole DevOps org, because, functionally, it is.

TTP Mapping

Mapped only to what we have direct evidence for. No speculative techniques added.

We are deliberately not mapping Persistence, Defense Evasion, Lateral Movement, or Exfiltration techniques. There is no evidence describing how the data left Accenture's environment or whether the actor did anything beyond read/clone operations, and padding this table would overstate what we actually know.

The Caveats

A few things we want to be explicit about, because it is easy for hedges buried mid-paragraph to get lost:

• Authenticity is unverified. Security Affairs states no independent confirmation the leaked data is genuine exists beyond the actor's own screenshot. Everything in this post treats the manifest and proof text as what the actor chose to show, not as ground truth about the full 35GB.
• "888" has a documented history of overstating scope. The June 2024 Accenture claim (32,826 records, later disputed down to three) is the clearest example, and it should weigh on how much confidence you put in the current 35GB figure.
• The infostealer-exposure data is context, not causation. It is cumulative and undated. It tells you a plausible path exists; it does not tell you this is the path that was used.
• The manifest is metadata, not the leak. We did not retrieve, download, or view any file contents, only the filenames and paths the actor chose to publish as proof. Several categories in the tables above (.conf, .config, .sql, .npmrc) are flagged as worth checking, not confirmed as sensitive, because we genuinely do not know what is inside them.
• The access method is confirmed; the root cause is not. We want to repeat this one because it is the single most important distinction in the whole post. A valid PAT was used. How it became available to "888" remains open.

What We Would Watch For Next

This is an active, developing situation, and we will be watching a few things over the coming days: whether the listing propagates to the paste/Telegram/onion channels we monitor (broker-listed breaches usually do, within a week or two), whether Accenture issues any further disclosure beyond "isolated matter, remediated," and whether "888" posts anything further in the thread that narrows down the access story.

If we had to compress the whole post into two sentences, it is this: the interesting part of this incident was never really the 35GB number. It is that a single credential, scoped too broadly, turned "one training-portal repo" into eighty-eight projects spanning PKI automation, SAP integrations, and at least three other companies' branded platforms, and that gap between what one leaked token was supposed to reach and what it actually could reach is where the real risk in this story lives.

IOC / Identifier Summary

Deliberately excluded from this table: Accenture's ADFS/O365 federation hostnames (acnsts.accenture.com, federation-sts.accenture.com, and related) that turned up in the infostealer-exposure check. Those are Accenture's own legitimate login endpoints, not attacker infrastructure, and the exposure data behind them is cumulative and undated. It is not confirmed to be connected to this incident in any way. They are discussed above as circumstantial context for one possible access theory, not listed here as indicators, because an IOC table implies a confirmed link this evidence does not support.

---

This post reflects an active, developing situation as of July 9, 2026. Accenture has not confirmed the scope, contents, or root cause of this incident publicly. All claims attributed to the threat actor are unverified beyond the analyst-reviewed proof artifacts described above. We will update if Accenture issues further disclosure or if the listing propagates to channels we monitor.