No, the TransUnion Breach Was Not the Salesloft Drift Breach. They Are Eleven Days and Two Campaigns Apart.

People keep asking us a specific question. We can see it in the search terms that land on this site: was the TransUnion breach related to Salesloft Drift? Is the TransUnion security breach related to the Drift incident? Those queries arrive here because we wrote four pieces on the Drift compromise and one on the twelve security vendors who ended up in its victim list.

We never answered the TransUnion question, so here is the answer.

No. And the reason is a date, not an opinion.

The eleven days

TransUnion's incident occurred on July 28, 2025. They discovered it two days later, on July 30. The notification went out by US Mail on August 26, covering 4,461,511 people — names, dates of birth, and unredacted Social Security numbers, taken from a third-party application used for US consumer support operations. TransUnion was clear that the core credit database and credit reports were not involved, and equally clear in declining to name the third-party application.

UNC6395 abused the stolen Salesloft Drift OAuth tokens against Salesforce customer instances between August 8 and at least August 18, 2025. Salesloft and Salesforce revoked every Drift token on August 20 and pulled the app from AppExchange the same day. More than 700 organisations were hit.

TransUnion's breach happened eleven days before the Drift exfiltration window opened, and TransUnion had already discovered and begun responding to it nine days before the first Drift token was used in anger.

You cannot be robbed in August by a key that was used against you in July. The dates alone close this.

So why does everybody think they are the same thing?

Because of when the letters arrived, and because both stories carry the same brand name.

TransUnion's notification letters went out August 26. The Drift story broke publicly on August 20 and Google's threat intelligence group published its fuller account on August 26 — the same day. So millions of consumers opened an envelope saying "a third-party application was compromised" during the exact week that every security outlet was explaining how a third-party Salesforce application had been compromised. The two stories arrived in the same news cycle, and the reader was given no reason to separate them.

TransUnion's silence on which application it was did the rest. When a company says "a third party" and declines to say which, the audience fills in the third party currently in the headlines.

And both incidents get attributed, in the loose press usage, to ShinyHunters — which by now means so many different sets of people that it functions as a genre rather than a group. We wrote about that problem this week: attribution by claim is broken, and the ShinyHunters name has become a brand that multiple unrelated crews wear. Two attacks sharing that label tells you approximately nothing about whether they share an operator.

Two campaigns, not one, and the difference matters

The Salesforce data-theft wave of 2025 was two distinct campaigns that Google's threat intelligence group explicitly separated. Conflating them is not a trivia error; it changes what you should do about it.

UNC6040 is the vishing campaign. Active since late 2024, surfaced publicly in June 2025. The operators phone your employees, pose as internal IT support, and talk them into authorising a malicious connected app — frequently dressed up as Salesforce Data Loader. The failure is a human one, the entry point is your own staff, and the malicious app is authorised through your front door by a person who thought they were helping.

UNC6395 is the supply-chain campaign. The operators compromised Salesloft's GitHub between March and June 2025, extracted the OAuth tokens for the Drift and Drift Email integrations, and then used those tokens directly against every Salesforce tenant that had installed Drift. No employee was tricked. No app was authorised in August. The authorisation had been granted, legitimately, months or years earlier by whoever installed the chatbot, and the attacker simply inherited it.

The FBI issued a joint advisory in September 2025 covering both, which is a reasonable indication that the distinction was not obvious to defenders at the time either.

TransUnion's timeline sits inside UNC6040's window and outside UNC6395's. We are not going to tell you TransUnion was definitively UNC6040 — TransUnion never named the application and never confirmed a campaign, and we are not in the business of asserting things the victim declined to say. What we will tell you flatly is what it was not, because that part is arithmetic.

Why the distinction changes your homework

If you believed TransUnion was a Drift victim, the lesson you took away was "audit your installed OAuth integrations." That is good advice and you should do it.

But it is the wrong defence for the campaign TransUnion's dates actually fit. Against UNC6040, an OAuth inventory does not help you, because the malicious app was not on your inventory yesterday — it gets added tomorrow, by an employee, in real time, during a phone call. The defences that work there are different ones: restrict who in your organisation can authorise a connected app at all, alert on new connected-app authorisations as a security event rather than an IT event, and train your help desk on the specific scenario of an inbound caller claiming to be internal IT and walking them through an approval screen.

Against UNC6395, the OAuth inventory is exactly right, and so is the harder question underneath it — for every integration you have installed, what happens to you when that vendor's source control is compromised? The Drift tokens were not stolen from Salesforce and they were not stolen from the 700 victims. They were stolen from a GitHub repository belonging to a company most of those victims had never thought about as part of their attack surface.

One campaign is a people problem. The other is a vendor problem. Telling a defender they were hit by the wrong one sends them to fix the wrong thing.

The honest position

We did not investigate the TransUnion breach and we hold no indicators from it. We have no private information about which application was involved and neither does anyone else writing about it, because TransUnion did not say.

What we did was read the public record carefully and put two timelines next to each other, which is the whole trick and takes about ten minutes. Everything above is from TransUnion's own disclosure and notification dates, Mandiant and Google's published windows for UNC6395, Google's public separation of the two campaigns, and the FBI's September 2025 advisory. Credit for the Drift research that established the August 8–18 window belongs to Mandiant, Google Threat Intelligence, and Arctic Wolf, who published on it early and clearly.

We wrote this because thousands of people are typing the question into search engines and arriving at posts of ours that answer a different one. That is a bad outcome for them, and it was cheap to fix.

Confidence capped at 95%. Dates are from primary disclosures and vendor research as cited. The claim that TransUnion was not part of the Drift campaign is grounded in the non-overlapping timelines and is as strong as those published dates. The claim about which campaign it was is deliberately not made — TransUnion never said, and neither will we.

---

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register