OAuth token theft is the breach that leaves no failed logins behind. Between June 8 and June 18, 2026, an attacker tracked as UNC6395 used stolen tokens issued to the Salesloft Drift chat integration to read Salesforce data from more than 700 organizations. No password was guessed. No multifactor prompt was bypassed. No flaw in Salesforce was exploited. The attacker simply held a credential that each of those 700 customers had granted to a third party, often years earlier, and the platform did what it was designed to do. We have run connected-app reviews for clients every week since, and almost nobody can name every application holding a live token against their own systems.
The Five Things to Settle About Your Connected Apps
Before the next vendor compromise, settle these five questions about the integrations already installed against your business systems.
- A granted token is a standing credential. It keeps working until somebody revokes it, and nobody revokes what nobody has listed.
- The vendor was breached, not you. Your controls were never tested, because every request the attacker made was properly authorized.
- Scope granted at install is scope granted forever. An integration approved for one purpose usually holds read access to everything in the object it touches.
- Your worst data may be in free text. The attacker went after support case bodies, where staff paste keys and passwords to reproduce a problem.
- Revocation is fast and nobody practices it. Salesloft and Salesforce revoked all Drift tokens within a day. Most businesses could not do the same for their own integrations.
Our note on managing third party cyber security risks sets the wider frame before the mechanics below.
Why OAuth Token Theft Defeats Controls That Work Perfectly
OAuth token theft succeeds against a well defended tenant because the stolen credential carries a permission the owner granted deliberately, so every control that checks whether access is authorized returns yes. When a business installs a connected application, it completes a consent screen that issues that application a token. From then on the application authenticates as itself rather than as a person. There is no password to rotate, no multifactor prompt to satisfy, and in most platforms no expiry unless one was configured. The trust sits between two companies rather than between a user and a system, which is why our guidance on managing third party vendor access treats integrations as a separate class of account rather than as software.
Your Logs Recorded It as Normal Traffic
Every export the attacker performed appeared in the audit log as legitimate API activity by an approved integration, which is why detection came from the vendor rather than from any of the 700 customers. The signal that existed was volumetric. A chat integration that normally reads a handful of records began exporting case text in bulk, and the shape of that traffic was visibly wrong to anyone watching for it. Almost nobody was. The reasonable objection is that alerting on integration volume produces noise, because a legitimate data sync or a reporting job looks much the same and a small team will mute the alert within a fortnight. That is a real risk. Our position is narrower than blanket alerting: baseline the two or three integrations that can read your most sensitive object, alert only on those, and accept that the rest are monitored by your vendor rather than by you.
The Counterargument for Integrations Deserves a Hearing
Connected applications earn their place, and a security posture that treats every integration as a liability will be overruled by the business within a quarter. The Drift integration existed because it did something useful, and the firms that installed it were not careless. A business that refuses integrations pays in manual work, duplicated data entry, and staff building their own unapproved workarounds, which is a worse outcome than a reviewed integration. The honest framing is not whether to connect applications but whether anyone owns the list. We have watched clients cut their connected-app count by more than half in one afternoon without a single complaint, purely because the removed entries belonged to pilots and departed vendors nobody had thought about since.
What an OAuth Token Theft Audit Actually Covers
An OAuth token theft audit answers three questions: which applications hold a live token, what each one can read, and who inside the business owns the relationship. Most platforms expose the first two in a connected applications or third party access view, and the third is the one that has no screen. Work through it by system rather than by vendor, because the same vendor often holds tokens in several places. Our write up on securing third party vendor access covers the control side, and for regulated environments the third party risk work in healthcare networks shows how the same review lands where patient data is in scope.
Read the Scope, Not the Vendor Name
The scope a token carries matters more than the reputation of the company holding it, because a breach at a careful vendor still exposes whatever you granted. A chat tool with read access to all case records is a data export risk whether the vendor is a startup or a public company, and the Drift incident made that concrete. Read each grant and ask whether the application needs every object it was given. Where the platform supports a narrower permission set or a restricted profile for integration users, use it. The argument against is practical: narrowing scope breaks integrations in ways that surface days later, and the vendor documentation often asks for broad permissions because it is simpler to support. That is true and it is still worth doing on the two or three integrations touching your most sensitive data, rather than across all forty.
Set Expiry on Tokens and Rehearse Revocation
Token lifetimes and a tested revocation path convert a breach from an open window into a bounded incident, which is exactly the difference the vendor response demonstrated in June. Salesloft detected the activity on June 19 and had every Drift token revoked by June 20. Ask yourself how long the same action would take in your business and who would perform it at 9pm. Write it down as a short runbook: where the connected applications list lives for each platform, who holds the administrative role, and what breaks when a given integration is cut. Then test it on something harmless. The counterpoint is that revoking a production integration during business hours causes an outage, and staff will resist rehearsing something that costs them a morning. We schedule it against a low-value integration for exactly that reason. The point is proving the path exists, not proving you can survive losing your CRM sync.
The Secondary Breach Nobody Budgets For
The most damaging material taken in June was not customer data at all, it was the plaintext credentials staff had pasted into support cases while troubleshooting. Cloud access keys, database tokens, virtual private network credentials, and passwords sat in ticket bodies because that is where an engineer pastes a configuration to get help. The attacker harvested those and used them to reach systems far outside the original CRM. This is why the incident kept producing follow-on compromises for weeks after the tokens were revoked, and it is the part most incident plans leave out. The same dynamic runs through vendor access risk in manufacturing plants, where a support ticket often carries device credentials as a matter of routine.
Treat Your Ticket System as a Credential Store
Any system where staff paste configuration to get help is holding secrets, so it deserves the controls you would put on a password vault rather than the ones you put on a mailbox. Scan historic tickets for credential patterns. Put a short note in the support template telling people to redact, which works better than training because it arrives at the moment of the decision. Rotate anything you find rather than deleting the ticket and assuming the exposure ended there. The fair objection is that redaction slows support and engineers will paste anyway under pressure, which we have seen plenty of times. That is why the scan matters more than the policy. Assume the paste happens, and build the detection that catches it afterwards rather than relying on discipline at the keyboard.
Assume the Blast Radius Is Wider Than the Platform
A credential taken from one system is used against a different one, so the response to a vendor breach has to cover systems the vendor never touched. Firms that scoped their June response to Salesforce alone were still finding exposed cloud keys in August. Build the list the other way around: start from what a support ticket in that system might plausibly contain, then rotate across every platform on that list. There is a reasonable pushback here about proportionality, since rotating credentials estate-wide after every vendor advisory is not sustainable for a small team. We agree. The trigger is not every advisory, it is specifically an incident where free-text content was exported, because that is the case where the loss is not bounded by the schema. For a comparable pattern on the personal side, our note on protecting against identity theft covers how one stolen detail becomes several.
Give Every Integration a Named Human Owner
An integration without a named owner inside your business is the one that survives every review, because nobody in the room feels able to say it can go. This is the failure we see more than any technical gap. The list gets pulled, four entries are obviously fine, three are obviously dead, and the remaining dozen sit in a category of nobody is quite sure, which resolves by default into keeping them. Put a name against each one. Not a department, a person, because a department never answers. Record what the integration does in one sentence written by that owner rather than copied from the vendor site, and record the date the grant was last confirmed. When the next advisory lands naming a vendor, you have somebody to call rather than a meeting to schedule.
The objection worth taking seriously is that this creates paperwork that decays within six months, and plenty of asset inventories have died exactly that way. Our answer is to tie the confirmation to something that already happens on a cycle rather than inventing a new one. Most businesses review vendor spend annually, and an integration that nobody is paying for is itself a finding. Attach the access confirmation to that review and it inherits a cadence somebody already owns. For businesses that administer data on behalf of others, our work with third party administrators shows how much heavier this obligation gets when the records belong to somebody else, since the question stops being what you are comfortable with and becomes what you can evidence to a client.
Frequently Asked Questions
Were we affected if we never installed Drift?
Not by this campaign. The relevant question is which other integrations hold live tokens against your systems, because the mechanism works identically for any of them. Pull your connected applications list rather than checking for one vendor name.
Does multifactor authentication stop OAuth token theft?
No. The stolen token authenticates the application rather than a person, so no multifactor prompt is involved. Token scope, expiry, and revocation are the controls that apply here.
How do we find out what a connected app can actually read?
Each platform exposes the granted scopes in its connected applications or third party access settings. Read the scope list rather than the vendor’s description of the product, since the two often differ substantially.
Should we remove integrations we are unsure about?
Remove the ones nobody owns. In most reviews we run, a large share of connected applications belong to finished pilots or departed vendors, and removing those is low risk and immediate.
What do we do first after a vendor announces a token breach?
Revoke the tokens, then search the exported data type for credentials. If free text such as support cases or chat logs was taken, treat every credential that may have appeared in it as exposed and rotate it.
Who You Are Taking This Advice From
Mindcore runs third party access reviews for businesses whose core systems are all delivered as software by somebody else, which is now most of the mid market. We pull connected application lists, read granted scopes against what the integration actually needs, and build the revocation runbook that turns a vendor breach into a contained afternoon, and the guidance above comes from reviews we have run since June rather than from reading the advisories. Matt Rosenthal, who leads Mindcore, keeps the firm focused on controls a business can operate with the staff it already has, which for vendor risk means a maintained list and a rehearsed revocation rather than another monitoring platform. You own the relationships. Our job is to make sure somebody owns the list.
Your Next Move on Connected App Risk
Open the connected applications view in your main business platform and count the entries. That number is usually the first surprise, and the second is how many of them nobody can explain. Remove what belongs to finished pilots and departed vendors, which is safe and quick. For what remains, read the granted scope on the two or three integrations that can reach your most sensitive records, and narrow them where the platform allows. Write the revocation runbook while you are already in the screens, because that is the only time anyone will. Then test it once against something you can afford to break. June proved that the vendor’s response time is not the variable that decides your outcome, since Salesloft moved in a day and 700 businesses still spent months on cleanup. What decided the outcome was whether the customer knew what had been connected and what it could read. If you want a second pair of eyes on your integration inventory and the scopes behind it, book a free strategy call and we will go through the list with you.
