Three Leaks Opened: 2.8B ZenBusiness Records, CI Secrets Under S&P Global's Name and Disney HR Tables

Covers three leaks indexed by HaveIBeenRansom between 2026-08-15 and 2026-08-27 and analysed on 2026-09-01. Each case shows when it was listed and when its data became searchable. How we pick cases, read records and score attribution: methodology.

Why these three

A leak has a name, and the name sets an expectation. "Disney internal Slack" sounds like chat logs. "S&P Global" sounds like one company's files. "ZenBusiness" sounds like a customer list. We hold the indexed content of all three, so we opened them and read the records in context, one by one: three leaks, opened and read. In every case the label and the content only partly match, and the gap is the story: HR and access-control tables under a Slack title, other organisations' CI/CD secrets under S&P Global's name, and 2.8B ZenBusiness records, leaked by ShinyHunters, that include AI interaction logs.

Everything below separates what the publishers and groups claim from what the indexed data contains. A listing is not a confirmed intrusion, and a domain in a leak does not show how anyone got in.

Key findings

The records without an email are not empty: they hold names, identifiers, internal fields and secrets. Email is just the easiest thing to count, so "% with email" understates what each leak holds. We have not quantified the non-email types.

How to read the percentages. Personal means an address on a fixed list of free-webmail providers; Corporate is everything else, so it does not mean "belongs to the victim" (relays, service accounts and third parties land there too). Shares in the top-5 tables are within their class. "Records read" means the records returned for the named domain, up to 1,000, read in context; they describe those records and are never extrapolated to the whole leak.

1 · Disney internal Slack (posted by DDoSecrets)

HIBR entry: Disney internal Slack on HaveIBeenRansom

What happened. The dataset is titled "Disney internal Slack" and described as Disney and Hulu internal communications. It was published by DDoSecrets, generally known as a collective that republishes leaked data rather than an extortion crew; HIBR indexes it under the key ddosecret. The metadata carries no extortion fields, so we treat it as a publication. The 2024 Disney Slack incident is confirmed by a US Department of Justice filing; this dataset is only a partial match for it. Listed 2026-05-02, indexed 2026-08-22.

Scale. 87,690,612 records (87.7M) and 9,442,051 email addresses. By file type: 71.4% CSV, 19.8% JSON, 5.0% XLS, 2.4% XLSX, 1.1% PDF, the rest marginal. Mail archives are under 0.01% and there are no .mbox files. This is a tabular dump far more than a chat export. 2,196 records are identity documents; 87.93% of those have no country (WW) and 7.83% are US.

What the data contains. Reading 1,000 records per domain:

• disney.com: 76.3% carry employee-record fields: employee ID, hire date, seniority, work-state descriptions, start and stop times. That looks like workforce-scheduling data. Another 10.3% carry IT access or configuration fields.
• hulu.com: 96.5% are access-permission rows: user ID, application ID, enterprise account ID, permission level.
• gmail.com: 65.8% are HR-style person profiles (nationality, position, assignment dates) and 33.7% are the same permission rows.
• The word "Slack" appears in 1.8% of disney.com records, 1.9% of hulu.com records and none of the gmail ones.

This does not prove there is no Slack content: our reading is driven by email domains, and the JSON share could hold exports we did not reach. What the records we read show is HR, access-control and risk-register data, not conversations.

Corporate vs Personal. 32.21% Corporate, 67.79% Personal (of 9,442,051 addresses).

Against all addresses, Disney-family domains are at least 23.4% (a floor, since only the top corporate domains are published) and gmail.com alone is 40.5%. The corporate class also holds a mail-delivery relay (SparkPost), which shows how loose the label is.

Attribution confidence: 72/100 (estimate, method v2.0). Disney domains are 22.5% of distinct corporate addresses (a lower bound) and the most frequent corporate domain, and 14.5% of records come from source files whose path contains the organisation name. The largest third party is a mail relay (20.6% of distinct corporate addresses), which counts for nothing against Disney. The Disney domains were inferred from the post title, not declared.

Why it stands out. Staff identifiers, hire dates and permission levels are the raw material of insider-risk, social-engineering and identity-fraud attacks. The "Slack" label hides that.

2 · S&P Global / LiteLLM-Trivy campaign (listed by Vect)

HIBR entry: S&P Global / LiteLLM-Trivy campaign on HaveIBeenRansom

What happened. Vect listed S&P Global on 2026-04-15 with the tag "LiteLLM/Trivy campaign (TeamPCP)". The group claims "internal projects, secrets, api keys", 250 GB and a negotiation deadline. S&P Global has not confirmed an incident that we know of. The data was indexed on 2026-08-15. The title already hints at something wider than one victim.

Scale. 204,612 records: 64.5% database-type and 35.5% text. 57.9% of records have an email (155,672 addresses), some more than one.

What the data contains. Every one of the 2,255 records we read carries a path starting with suppluchain/. The content is automated reports, one per CI/CD runner, each listing the runner's host, user, environment and the secrets found.

In the records we read, every one of the 606 secrets of the SSH-key, GitHub-token and AWS-key-ID types is shown truncated, not in full. GPG material appears in only 2.3–2.8% of records, by keyword, so we cannot confirm private keys. We did not check all records.

The twist: S&P Global is a small slice. Only 544 of 204,612 records (0.27%) match spglobal.com, and all of them trace back to a single address, a GitHub Actions pipeline labelled with an S&P "innersource" organisation. The GitHub-matched records span 78 distinct company labels and the GitLab-matched ones 21. It reads as a harvest across many organisations' pipelines, consistent with the "campaign" wording, with S&P Global as one of them.

Corporate vs Personal. 97.02% Corporate, 2.98% Personal (of 155,672 addresses).

Hypothesis, not fact: judging by the commit-author and actor fields in the records read, these addresses are the Git identities of developers who triggered the pipelines, not mailbox contents. No country data exists for this leak.

Attribution confidence: 39/100 for S&P Global alone; 83/100 for the TeamPCP/LiteLLM campaign as a whole (estimate, method v2.0). Distinct spglobal.com addresses are 0.04% of distinct corporate addresses, and no source-file path contains the organisation's name. That describes the content, not S&P Global's security: the data do not look like S&P Global's own, which fits a multi-organisation campaign. It does not say S&P Global was unaffected.

Why it stands out. The exposure is a rotation problem for every organisation named in the runner reports, not one company's leak. A single "victim" label would leave dozens of other companies' defenders looking in the wrong place.

3 · ZenBusiness (listed by ShinyHunters)

HIBR entry: ZenBusiness on HaveIBeenRansom

What happened. ShinyHunters listed ZenBusiness, Inc., the US business-formation service, on 2026-03-26. The group claims "several terabytes" from Snowflake, Mixpanel and Salesforce, with a final-warning deadline. ZenBusiness has not confirmed an incident that we know of. The data was indexed on 2026-08-27.

Scale. 2,819,708,288 records, the largest of the three: 99.15% CSV and 0.85% legacy DOC. 16.1% of records have an email (454,364,504 addresses).

What the data contains. Reading 1,000 records per domain:

• zenbusiness.com: 100% carry Fivetran sync columns, so these are warehouse tables replicated by Fivetran. 77.0% are CRM-style email-to-record link tables, 12.1% are LLM interaction logs (prompt ID, model name, token counts, latency, response) and 6.6% are issue-tracker rows.
• gmail.com: 99.8% carry Fivetran columns. 50.0% are product access-audit events (event type, actor type, operation, business-entity ID) and 33.9% are contact-status rows (hard-bounce, unsubscribed and marked-as-spam flags, country, browser language).
• Phone and CRM traces: "phone" appears in 10.9% of the gmail records and "Salesforce" in 30.7%.

The pattern fits the group's own list of sources: warehouse exports, not mailboxes. It also exposes something the headline does not: LLM interaction logs in the same dump.

Corporate vs Personal. 24.28% Corporate, 75.72% Personal (of 454,364,504 addresses).

Against all addresses, zenbusiness.com is 9.6% and gmail.com alone is 58.6%. Two of the five corporate domains are US state business registries and one is a registered-agent company. Hypothesis, not fact: a business-formation service naturally exchanges email with Secretary of State offices and registered agents. The domains show who the data talks about, not how anyone got in.

Attribution confidence: 61/100 (estimate, method v2.0). ZenBusiness addresses are 7.0% of distinct corporate addresses. The largest third party is a transactional mail relay (Mandrill, 78.1% of third-party addresses), which method v2.0 no longer counts against the victim. A customer-data leak is mostly customers, so staff-domain evidence stays weak even if the victim is right. Read the score as a partial match, not a confirmation.

Why it stands out. Scale plus contact data plus AI logs: customers' emails, phone traces and what they typed into AI tools may sit in the same tables, which is the ingredient list for convincing phishing.

What they have in common

• None is what its label suggests. HR and access-control data under a "Slack" title; credentials harvested from many organisations' build pipelines under one company's name; a data warehouse that includes AI logs.
• The label comes from the headline, the content from whatever system was reached. Hypothesis, not fact: titles reflect the victim list, the attacker's note or the publisher's framing. Reading the records is the only way to see the difference.
• None shows how anyone got in. A domain, a pipeline label or a table name is not an entry point.

What defenders can do

• If your organisation appears in the S&P Global / LiteLLM-Trivy reports, rotate CI/CD secrets first: SSH deploy keys, GitLab CI job tokens, GitHub tokens and AWS keys used by runners. Then check whether your runners execute as root (93.7% of the GitLab reports we read do) and review pipelines that use LiteLLM or Trivy, the two tools named in the listing.
• Disney and its suppliers: treat it as an identity and insider-risk exposure, not a chat leak. Employee IDs, hire dates and permission levels enable convincing pretexting against HR and help desks; review whether the access-permission rows (user, application, permission level) still map to live accounts, especially those tied to hulu.com.
• ZenBusiness customers and partners: expect tailored phishing. Business owners, registered agents and state registry contacts appear in the data; warn customers about messages quoting their company filings, and audit what reaches LLM logs in your own warehouse syncs.
• For any leak, read the records before you scope the response. Search your domains in HIBR and size the exposure by data type, not by email count.

Is your company — or one of your suppliers — in one of these leaks? Search HaveIBeenRansom for free · Monitor your domains with HIBR for business

DarkEye Threat Research · Data: HaveIBeenRansom · Indexing methodology peer-reviewed in MDPI Electronics · Attribution confidence is a heuristic estimate (method v2.0), not a formal attribution.

Related: Ransomware Weekly · Breaches Weekly