IAM case files
A compromised OAuth token, a hijacked service account, an entitlement that was far too broad, a standing privilege, abnormal behaviour that no one noticed… The mechanisms change, but identity sits at the centre of the attack chain. Ariovis analyses documented incidents here to identify the IAM controls that could have prevented them or reduced their impact.
Understand our approach to preventing data breachesA classic cyber analysis looks first at the entry vector: the vulnerability exploited, the phishing message, the exposed service. That matters, but it does not explain why an incident turned into a data breach of that scale. We add the identity and entitlement questions that come right after the intrusion.
Each case has its own anchor so it can be quoted or shared directly.
SaaS / supply chain · March – August 2025
More than 700 organisations affected by stolen OAuth tokens tied to Drift integrations. A trusted application, a valid credential, and human authentication is no longer the relevant barrier.
Sector : SaaS / supply chain · Period : March – August 2025
More than 700 organisations were affected by a supply-chain attack exploiting stolen OAuth tokens tied to Drift integrations. The incident illustrates a still-common IAM blind spot: applications also have an identity, rights and a lifecycle that must be governed.
March to June 2025 — according to the Mandiant investigation published by Salesloft, the threat actor accessed Salesloft's GitHub account, downloaded the content of several repositories, added a guest user and set up workflows. Reconnaissance activity was then observed in the Salesloft and Drift environments.
The investigation then established access to Drift's AWS environment, from which the attacker obtained OAuth tokens associated with customers' technology integrations.
8 to 18 August 2025 — those OAuth credentials were used to reach customer environments through the Drift integrations and exfiltrate data. Salesloft documents this window; FINRA also recommends hunting for abnormal access over that period.
A note on method: some early publications mentioned tokens obtained during earlier phishing or social engineering campaigns. We rely here on the later, more precise timeline established by the investigation, and we do not present both hypotheses as simultaneously proven.
An attack on the trust relationship
No step in this chain requires a human user to log in again.
The IAM problem: the identity accessing the data was not human. When a person signs in, you can ask for a password, an additional factor, adaptive authentication, a compliant device, a coherent context.
An OAuth integration works differently. Once the trust relationship is established and a credential issued, the application calls the APIs within the permissions it was granted. The attacker therefore did not need to repeat a human user's journey: FINRA notes that the stolen tokens made it possible to impersonate the trusted Drift application and bypass the traditional MFA journey.
The token is that application identity's credential, not its identity. That distinction moves the subject: from human authentication towards governing the application identity, its credentials, its permissions and its behaviour.
MFA did not fail
It was protecting a different step of the chain. Once a valid OAuth credential is compromised, the problem moves from human authentication to governing the application identity, its credentials, its permissions and its behaviour.
A SaaS integration is an identity
A non-human identity can be an application, a SaaS integration, a service account, a workload, a bot or an AI agent. It also has:
The fact that no human logs in does not remove the subject from the IAM perimeter: that is precisely what makes it a non-human identity governance topic. A useful nuance: “non-human identity” does not necessarily mean an OAuth client_credentials flow.
FINRA reports that the campaign affected more than 700 organisations, and that the attackers reached Salesforce, Google Workspace and, in some cases, Slack environments. Exposed data could include contacts, accounts, opportunities and cases, but also API keys, cloud credentials, passwords and tokens present in the content.
Cloudflare, which published its response, explains that its Salesforce environment contained support ticket information that could embed tokens or passwords. The company identified 104 Cloudflare API tokens in the affected data and rotated them all, without identifying suspicious activity associated with those tokens.
This is where blast radius becomes concrete: stolen data can become the credential for the next attack. A compromised integration opens the CRM, the CRM contains a token, that token potentially opens a third system. The reach then extends well beyond the SaaS initially concerned.
User-oriented controls — password, MFA, adaptive authentication — were guarding a step the attacker did not need to cross: they held a credential already granted to a trusted application.
From that point on, only controls covering the application identity could still act: the scope of the permissions granted, the credential's lifetime, the ability to revoke it, and monitoring of the integration's actual usage.
No single control would necessarily have prevented the incident. The point is to reduce the attacker's room for manoeuvre at each stage.
Prevent
Limit
Detect
Respond
These are not “five mistakes made”: the sources do not allow us to state that these controls were missing. They are the IAM lessons we draw from the case.
1 — Govern the integration as an identity
A sensitive integration must have a business owner, a technical owner, a purpose, a vendor, a list of reachable resources, documented permissions, a revocation procedure, a review frequency and an end-of-life event.
This is exactly the lifecycle applied to humans: onboard, modify, review, offboard.
A non-human identity without an owner should be treated as an anomaly.
2 — Apply least privilege to the application
The question is not only “does this application have access to the CRM?” but “to do exactly what, on which data and with what depth?”.
In practice: OAuth scopes, permission sets, reachable objects, allowed operations, separation of use cases, rights that are genuinely needed. FINRA explicitly recommends least privilege for third-party applications.
A compromise cannot always be prevented. Its reach, however, can be designed in advance.
3 — Govern credentials over time
An application's credential also has a lifecycle: issuance, storage, rotation where relevant, expiry where supported, revocation, an emergency rotation procedure, and removal when the integration is no longer used.
We do not set an arbitrary duration: the right policy depends on the protocol and the platform.
4 — Look at what the identity actually does
A valid credential does not mean its usage is normal. Compare the theoretical right with observed usage: number of API calls, frequency, data volume, bulk exports, objects read, time windows, IP addresses, User-Agent, abrupt behavioural change. FINRA specifically recommends hunting for unusual exports and abnormal access patterns.
A CRM integration that usually syncs a few hundred objects is no longer within its normal behaviour when it suddenly walks through massive volumes of data. Even if its token is perfectly valid.
This is where identity, authorization, behaviour and volume meet.
5 — Do not treat the initial authorization as eternal
On an API or an application the organisation controls, the decision can go beyond “valid token = access granted”: the enforcement point requests a decision, the policy engine evaluates identity, resource, action, context and risk, then allows or denies.
An integration may be allowed to read data without being allowed to read that category of data, at that volume, from that context, at that moment, or after a risk signal. We do not claim a policy engine would have protected this specific architecture: it is an additional capability on the resources the organisation controls, not a universal remediation for third-party SaaS.
A compromised identity should not be able to freely extract every piece of data it theoretically has access to.
See how Ariovis approaches data breach preventionAriovis helps you map human and non-human identities, their rights, how they are really used, and the controls that reduce the risk of exfiltration.
