What should defenders understand about stolen integration tokens?
An approved integration can become an access path when its credential is stolen. Map each credential to its resource and owner, investigate actual use, verify revocation effects, and handle separate secrets found in exposed data.
Your team approved an integration months ago. It had a business owner, a legitimate purpose, and permission to retrieve records. Then a supplier reports that credentials associated with the integration were stolen.
The first response question is no longer whether an employee should have approved the app. It is which access that existing approval still enables, what the stolen credential could reach, and what evidence shows was actually read.
An integration token is a credential used by software to access another service. In an OAuth integration, an access token represents authorization to reach protected resources. A refresh token, when issued, serves a different purpose: obtaining access tokens from the authorization server. Keep those roles separate when planning containment. RFC 6749, sections 1.4–1.5
The 2025 Salesloft Drift incident shows why a supplier notice needs to be traced to individual integrations, credentials, and customer records.
The incident starts with an existing integration
In August 2025, Google Threat Intelligence Group and Mandiant described UNC6395 using compromised OAuth tokens associated with Salesloft Drift to access Salesforce customer data. Their August 28 update expanded the scope beyond Salesforce and advised treating authentication tokens stored in or connected to Drift as potentially compromised. The update also described access to a small number of specifically integrated Google Workspace accounts, not arbitrary accounts across those organizations.
The report distinguished the integration compromise from a vulnerability in the core Salesforce platform. It also described searches of stolen data for credentials that could enable further access. GTIG and Mandiant: Drift integration incident, including August 28 update
Later vendor reporting matters. Salesloft’s trust center describes an investigation in which the actor reached Drift’s AWS environment and obtained integration tokens. Its final investigation summary states that investigation and remediation concluded on September 30, 2025, with no ongoing Drift compromise identified at that time. Those are historical findings; they do not establish the present state of any particular customer’s credentials or tenant. Salesloft: investigation updates and summary
A legitimate connection can become the access path without a new employee approval at the moment of abuse. The response must address the existing credential and its authority.
Who approved the integration, held its credential, and used it?
Our UNC6040 app-authorization article covers a different starting point: an attacker persuades someone to authorize an application. Consent phishing asks how that permission was obtained. This article starts with an approved connection whose credential is later compromised.
A response meeting should distinguish:
- Approval: who authorized the integration, for which business purpose, and with which permissions?
- Custody: where was its usable credential held, and which provider or customer systems could access it?
- Use: which resource accepted a request using the integration’s authority, and what did that operation return?
An approval record answers the first question. A supplier incident notice may speak to the second. Resource-side evidence is needed for the third. One record rarely answers all three.
That distinction also changes the exercise design. Testing whether an employee rejects a suspicious consent prompt does not test whether an already approved integration’s credential is contained after a supplier incident. Both questions can matter; they need different starting conditions and different success criteria.
Map each credential to the service it can access
A useful map needs named objects, not just company logos. Start with the integration instance, the credential reference, the tenant or account, the permitted resource, and the operational owner. Keep raw credentials out of the diagram.
Map the credential, then the evidence
- Approved integration
A named instance and business owner hold a credential for another service.
If the credential is stolen
- Credential exposure
Usable authority may leave the intended integration boundary.
Request, if usable
- Resource operation
Was the credential accepted? Was data returned? Check operation results and resource records.
If another secret is present in exposed data
- Separate secret
Assign its own owner and response. Downstream use remains a new question.
Each edge needs its own evidence. No social-engineering origin is assumed.
A customer may have more than one instance of the same integration. One might read test data and another might run a production synchronization. Label each instance separately. A product name alone does not tell the responder which tenant, identity, or permission set belongs to the incident.
If the data the integration could read contained a secret, add that connection to the map too. That creates a further investigation question. For example, a support case might contain a credential for another service. Revoking the integration’s token would not, by itself, establish that the separate credential has been invalidated.
Label what you know about that secret. “Secret found in potentially exposed records” and “secret used against another service” are different findings. The first can justify precautionary rotation under the response plan; the second requires evidence from the downstream service or another reliable source.
Find the person who can revoke each credential
The business owner may be able to pause a synchronization job without having permission to revoke its credential. The SaaS administrator may control that integration but not a separate service whose secret appears in exposed records. Assigning everything to “the app owner” leaves those responsibilities unresolved.
Identify who can approve interruption, who can revoke access, and who owns any downstream credential. Keep credential references in the restricted incident system. A shared coordination record should identify the work without becoming another repository of secrets.
Decide what can stop now
Have the business owner establish what pausing the integration would interrupt. The response lead can then authorize containment while the platform administrator preserves available evidence and follows the supported revocation procedure. Before issuing a replacement into the same storage location, establish what changed in the supplier’s storage and access conditions.
Use the provider’s current instructions and your approved response process. The historical GTIG advisory recommended reviewing connected integrations, rotating or revoking associated credentials, and investigating exposed secrets. GTIG: recommendations
Name the person who can authorize restoration as well as interruption. “Waiting for the vendor” is too broad to manage; confirmation that a replacement credential store is ready identifies a specific dependency.
Revocation, rotation, and disconnecting are different actions
A revocation invalidates a credential or grant through the relevant authorization system. Rotation replaces credential material. Disconnecting a product’s integration may include some of these actions, but its exact effect must be checked in that product’s documentation and configuration.
OAuth’s revocation specification allows invalidation of a token and, where applicable, related tokens or the underlying grant. It also acknowledges propagation delay and implementation differences. An HTTP success response from a revocation endpoint is not proof that a particular token previously existed: the specification also returns success for an invalid token. RFC 7009, sections 2.1–2.2 and 3
Record the administrative change, the provider’s stated effect, and the validation evidence separately. A recorded disconnect action does not establish its effect until the other two are understood.
Do not assume a user password reset closes every integration path. Instead, enumerate the actual access token, refresh capability, grant, and any separate secret involved. Ask the responsible platform owner which operation affects each one. Our identity containment review uses the same principle across sessions, methods, devices, and grants.
Establish what happened before deciding who did it
A resource query under an integration identity establishes an operation, not who controlled the credential. Compare the job schedule, expected client behavior, network context, and supplier findings. An unusual time or address can justify investigation without identifying the operator.
A matching export record can support a more specific conclusion about the data returned. Without it, retain the narrower conclusion that a query occurred and identify what its result leaves unresolved.
Finding a separate credential in exposed records opens another response task. It does not establish that the credential was used. Its owner must assess validity, revoke or rotate as appropriate, and inspect the downstream service. That branch requires its own closure evidence.
Record what your investigation could and could not see
Write down the beginning and end of the evidence window, which sources were available, and what each source records. If retention starts after the suspected exposure, say so. If the provider can supply additional records, record the request and its owner rather than silently treating the gap as a clean result.
Build the query around the integration instance and resource identity where available. Then examine the operations and results. A recognizable application name is not enough to separate legitimate synchronization from unauthorized use, and an unfamiliar address alone does not establish data theft.
Document exclusions. Perhaps only one tenant retained useful resource records, or one API surface was outside the collected telemetry. Readers should be able to distinguish “reviewed with no suspicious result found” from “not observable in the available records.” Those statements lead to different follow-up decisions.
Keep the supplier’s scope statement alongside, rather than inside, the customer conclusion. A supplier may confirm credential exposure without knowing exactly which customer records were accessed. Conversely, a customer may find an export before the supplier has resolved the full intrusion path.
Validate containment without spreading the secret
Plan validation with the platform owner. Prefer the provider’s supported evidence and an explicitly authorized, isolated test arrangement. Do not paste incident credentials into a shared script, chat, or worksheet to see what happens. Do not improvise replay of revoked credentials; the OAuth revocation specification instructs clients not to use a token after a successful revocation response.
In an exercise, a disposable integration can demonstrate the expected before-and-after behavior using harmless data and approved platform procedures. For a live incident, administrative records, provider confirmation, and subsequent resource monitoring may be the available evidence. State which kind was obtained.
If no direct behavioral retest was performed, say so. The closure note should distinguish an administrative action and provider confirmation from an observed resource response. The incident lead should also verify that separate credentials found in exposed data have their own owners and response records.
Check permissions and credential storage before reconnecting
Restoration should answer a fresh set of questions. Does the integration still need its original permissions? Is the intended owner still responsible? Where will replacement credentials live? What evidence will show ordinary use after the connection returns?
Review whether the platform can narrow the restored integration to the data needed for its purpose. Where it cannot limit individual fields, the owner must decide whether the available scope is acceptable. Record the replacement credential separately and compare the first synchronization with the intended data set.
The business owner also decides how to handle missed work. Restarting a job may create a backlog or duplicate work, depending on the application’s behavior. Ask the owner to define the acceptable recovery result before pressing resume. Record both the security checks and the business owner’s acceptance before closing the recovery work.
Retain the original permissions and evidence references for the incident record. Otherwise, a narrowed replacement configuration can accidentally be presented as the configuration that existed during exposure.
Keep ownership current before the next notice
An integration inventory is useful during an incident only if it identifies both the access and the person who can revoke it. Keep that ownership current, including separate services whose credentials might be stored in the integration’s data. A supplier’s remediation notice cannot close those customer-specific questions.
