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.
Insurance / cloud CRM · July 2025
A legitimate, properly authenticated user is talked into authorizing a Connected App controlled by the attacker. From then on, the API calls look like those of an approved application.
SaaS / outsourced support · September 2025
A support access used by an external provider was enough to reach Discord's customer support environment. Less a “Zendesk flaw” than a problem of governing third-party identities, their capabilities and their behaviour after authentication.
Automotive / manufacturing · August – October 2025
From 31 August 2025, a cyberattack led Jaguar Land Rover to shut down part of its IT estate. The immediate consequence: production and retail operations came to a halt. The initial access vector has not been publicly confirmed.
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 preventionSector : Insurance / cloud CRM · Period : July 2025
In July 2025, Allianz Life suffered a large data breach from its cloud CRM following a social engineering operation. The case belongs to a campaign in which attackers convinced victims to authorize a malicious Salesforce Connected App impersonating Data Loader. Once that trust was granted, the API calls could look like those of an authorized application.
16 July 2025 — a threat actor gained access to the third-party cloud CRM used by Allianz Life through social engineering. Allianz Life detected the incident on 17 July, states it acted to contain the access and notified the FBI.
Scope: Allianz explicitly stated it had no evidence that the Allianz Life network or its other internal systems, notably the policy administration system, had been compromised. What was compromised is the cloud CRM used by Allianz Life, not the whole information system.
The initial public statement referred to a third-party CRM without naming it. Investigations and specialised sources later connected Allianz Life to the Salesforce data theft campaign documented by Google.
The mechanics of that campaign, tracked by Google Threat Intelligence under the UNC6040 cluster, are documented: a phone call, an attacker impersonating IT support, a request to open the Salesforce page used to connect an application, the user entering a code provided by the attacker, and the authorization of a Connected App controlled by the attacker — frequently a modified, unauthorized version of Salesforce Data Loader, or an app with misleading branding. The application then obtains OAuth capabilities to access, search and extract data through the API.
A note on method: we connect the Allianz incident to that campaign because several specialised sources did, but Allianz did not itself publish the Data Loader/OAuth technical sequence. Google also states that these attacks relied on manipulating users, not on exploiting an inherent Salesforce vulnerability.
How a human identity creates a hostile non-human identity
The chain crosses two IAM perimeters usually handled separately: users on one side, applications on the other.
The IAM problem: the user was legitimate, the application they authorized was not. We tend to ask a single question at authentication: “is this really that user?”. Here, that is not enough.
The user can be correctly authenticated, protected by MFA, genuinely sitting in front of their screen — and still make a dangerous security decision. The attacker is not so much impersonating the user as getting them to delegate their capabilities to an application.
A legitimate human. A legitimate action. A malicious application. And yet a trust relationship that is perfectly valid from the protocol's point of view.
The Ariovis conviction
OAuth consent is an authorization decision. An organisation must therefore govern not only users and their rights, but also their ability to create new trust relationships with applications.
What this technique does not mean
Two formulations to avoid, because the sources do not support them:
The UNC6040 campaign had several variants, including phishing of credentials and MFA codes. What makes the Connected App scenario attractive to the attacker is that it moves the attack outside the classic interactive authentication journey: once the app is authorized, what must be controlled is the rights granted to that application identity and its behaviour. The sources do not establish the type or lifetime of the token used at Allianz, so we speak of an OAuth grant and of API access granted to the application. Scopes such as refresh_token or offline_access are particularly sensitive permissions to monitor in this kind of campaign, not a demonstrated fact in this specific case.
The regulatory filing with the Maine Attorney General reports 1,497,036 people affected in total, a breach date of 16 July 2025 and discovery on 17 July 2025. Have I Been Pwned separately ingested 1.1 million unique email addresses from the Allianz Life data: the two numbers do not contradict each other, HIBP counting unique email addresses present in its corpus while the regulatory figure is the total number of affected people declared by Allianz.
Publicly documented data categories include names, addresses, dates of birth, contact details and, for some people, Social Security Numbers.
Attribution: several sources connected the incident to the Salesforce campaign associated with UNC6040 and to the extortion operations using the ShinyHunters brand, which Google tracks under a separate cluster (UNC6240). Allianz Life has not itself publicly attributed the incident to a specific group.
The authentication controls did exactly what was asked of them: verify the user was who they claimed to be. The attacker did not challenge that answer, they used it.
What was missing sits after authentication: the ability to decide who in the organisation may authorize a new application over sensitive data, with which scopes, and the ability to notice that an unknown application has just been approved and is now walking through the CRM.
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 failures attributed to Allianz: the sources do not allow that. They are the controls this modus operandi makes necessary.
Prevent — govern who may authorize an application
An organisation should not automatically let any user connect any application to sensitive data. Depending on the platform: restrict the creation and authorization of Connected Apps, limit which users may approve certain applications, put in place an allowlist or an equivalent trust mechanism, require administrative validation for high-risk applications, and maintain a catalogue of officially authorized integrations.
The question is no longer only “what rights does Alice hold?” but “what rights can Alice delegate to a piece of software?”.
Limit — do not hand over all the user's rights
Apply least privilege to OAuth scopes, API permissions, objects, operations and reachable data. A productivity application does not necessarily need access that allows extracting an entire CRM.
The blast radius of an OAuth consent depends directly on the permissions the application can obtain.
Detect — is the behaviour still coherent?
Once the application is authorized, its usage can technically look valid. Monitor: new Connected App, unusual application name or identifier, sensitive scopes, Connected App policy changes, first use of an unknown application, unusual IP or ASN, usage from VPN or Tor.
Then, on the data side: sudden bursts of API requests, Query, QueryMore and QueryAll calls, Bulk API, large exports, high numbers of records read, mass download of files or attachments, and significant deviation from the user's or the application's normal usage. Google explicitly recommends correlating OAuth events with data extraction events, and describes API bursts and large data volumes as useful signals.
A valid token proves a trust relationship exists. It does not prove the current use of that relationship is legitimate.
Respond — a revocation procedure that already exists
Be able to quickly identify the Connected App, revoke its grant, revoke the associated sessions and tokens, find the other users who authorized the same application, identify the objects accessed, measure the exported volume and check for pivots into other SaaS.
The revocation procedure should not be invented on the day of the incident.
After authentication, identity security continues
Authentication is a moment in time. After it, you still need to know which new permissions are created, which applications are authorized, which actions are executed, which data is read, at what volume and from what context.
The SentinelOne Annual Threat Report 2026 describes the same shift: look at post-authentication behaviour and review the permissions of service accounts, automations and other non-human principals; it also frames OAuth exfiltration as a context problem, requiring correlation of identity, application, destination and volume.
Salesloft / Drift
Allianz Life
Legitimate integration
Malicious application
Already approved
Approved under manipulation
Vendor compromised
User manipulated
OAuth credential stolen
OAuth relationship granted
Legitimate NHI hijacked
Hostile NHI introduced
Key control: govern credentials and usage
Key control: govern consent and applications
In one case, the attacker steals the trust. In the other, they convince the organisation to grant it.
The IAM question is no longer only “who can access Salesforce?” but “who can authorize software to act inside Salesforce, with which rights, and how do we know that software still behaves normally?”.
See how Ariovis approaches data breach preventionSector : SaaS / outsourced support · Period : September 2025
September 2025 — a support access used by an external provider allowed an attacker to reach Discord's customer support environment. The case illustrates less a “Zendesk flaw” than a problem of governing third-party identities, their capabilities and their behaviour after authentication. Attribution is not publicly established: the name Scattered Lapsus$ Hunters circulated after the incident, but the group later denied being behind the Zendesk support compromise.
In October 2025, Discord announced that an unauthorised actor had compromised the access of a third-party provider used for its customer support, and later identified that provider as 5CA.
The exact mechanism of the initial access is not fully established publicly. 5CA states that its own systems were not compromised and says its preliminary investigation points to human error involving a single employee working as a support agent on the client's behalf.
According to the attackers interviewed by BleepingComputer, they used the account of an agent employed through a BPO provider to access the support instance used by Discord, and claim to have retained that access for about 58 hours starting 20 September 2025 — a duration claimed by the attackers, not confirmed by Discord.
An abuse of legitimate access
The precise mechanism of the initial identity compromise is not publicly established: neither phishing, nor session theft, nor any specific technical compromise is confirmed.
This is not just a SaaS leak. It is an identity incident: an attacker does not necessarily need to break an application when they can borrow the path of an already-authorised identity.
An external support agent may legitimately have access to sensitive data. The problem then becomes more subtle: who is this person, why do they still hold this access, which data can they reach, what actions can they perform, in what volume, from which context — and does their behaviour remain consistent with that of a normal support agent?
Authentication is therefore only the beginning of control.
Authentication is only the beginning of control
A perfectly authenticated identity can perform a perfectly illegitimate action.
The visible SaaS… and the hidden tools behind it
According to the attackers, the support access also allowed them to use “Zenbar”, an internal tool integrated into Discord's support operations. BleepingComputer reports that this environment enabled various support actions, and that certain integrations with internal systems allegedly allowed a large number of API requests. The important point is not only Zendesk: a SaaS application can become the entry point to a whole set of —
That trust chain is what must be governed. Zenbar and the millions of API requests come from the attackers' account as reported by BleepingComputer; they are not presented as confirmed, and neither is the exfiltration of 1.6 TB.
That is precisely one of the particularities of this incident. Discord identified 5CA as the third-party provider involved. 5CA, for its part, states that its own systems were not compromised and says its preliminary investigation points to human error involving a single employee, which enabled access to the client's third-party support system. Zendesk also stated that the incident did not result from a vulnerability or a compromise of its platform.
We do not attempt to artificially arbitrate between these accounts. For the CISO, the debate over the exact boundary of the compromised system does not change the problem: a trust chain linking the customer, the provider, a human identity, a SaaS and integrated applications made it possible to reach sensitive data.
The classic controls governed the sign-in, not the usage. Once the support identity was authenticated, nothing appears to have bounded the number of tickets browsed, the volume of attachments downloaded or the number of requests made through the associated tools and integrations.
A general-purpose support tool turned into a permanent warehouse of highly sensitive data — including photos of government IDs — mechanically increased the value of the loot reachable by a single compromised identity.
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
No single control would necessarily have prevented the incident. The point is to reduce the attacker's room for manoeuvre at each stage.
Third-party identity governance
Identities of providers, BPOs, partners and subcontractors must have a sponsor, a validity period, an explicit scope, regular reviews and automatic deprovisioning when the engagement ends. This is identity governance (IGA) applied to third parties.
Phishing-resistant MFA… but not only
Support accounts with access to sensitive data need strong, ideally phishing-resistant authentication. But since the exact initial mechanism of this incident is not confirmed, one cannot claim MFA would necessarily have prevented it: control must continue after authentication.
Control capabilities, not just the login
An agent handling a handful of tickets should not be able, without additional control, to browse thousands of cases, download attachments in bulk, run abnormal volumes of searches, reach data unrelated to the tickets they handle, or trigger sensitive operations without justification.
This is the logic of least privilege and, where relevant, fine-grained contextual authorization: ABAC / PBAC, Policy Decision Point, Policy Enforcement Point, step-up authentication or additional approval for the most sensitive operations.
Detect abnormal use of a legitimate identity
Behaviour must be observed after authentication: volume of tickets browsed, number of attachments downloaded, search frequency, API calls, working hours, device context, data destination, and deviation from the role's usual behaviour.
An authorised identity becomes dangerous when its behaviour no longer matches what it was authorised for.
Reduce the value of the loot
IAM security does not replace data minimisation. For highly sensitive documents such as ID cards: limit retention, set a TTL where the process allows it, separate read rights, log access, restrict downloads and prevent a general-purpose support tool from becoming a permanent warehouse of sensitive data. This is impact reduction, not a measure that would have prevented the initial access.
What Discord confirms
What the attackers claim
An incident involving a third-party customer support provider.
About 1.6 TB of data, including around 1.5 TB of attachments and over 100 GB of ticket transcripts.
Around 70,000 users worldwide who may have had a photo of a government-issued ID exposed.
Around 8.4 million tickets and 5.5 million unique users affected.
Data potentially concerned: name, Discord username, email address and contact details shared with support, IP address, exchanges with Customer Support / Trust & Safety teams, limited billing information (payment method, last four card digits), and some internal company data.
Access retained for about 58 hours from 20 September 2025, using Zendesk, Zenbar and integrations enabling a large number of API requests.
Passwords, authentication data, full payment card numbers and Discord messages outside support conversations were not affected.
—
The volumes in the right-hand column have not been confirmed by Discord; BleepingComputer notes it could not independently verify the attackers' claims.
Mapping third-party identities, bounding their capabilities and monitoring their real behaviour: that is exactly the core of our data breach prevention approach.
See how Ariovis approaches data breach preventionSector : Automotive / manufacturing · Period : August – October 2025
From 31 August 2025, a cyberattack against Jaguar Land Rover severely disrupted the carmaker's IT systems. JLR chose to shut down a significant part of its information system to contain the incident, with an immediate consequence: vehicle production and several commercial operations were paralysed.
The incident matters for IAM not because its entry point has been demonstrated, but because it shows how far the compromise of a trusted digital environment can go. When the systems that drive users, operations, logistics and production become unavailable — or can no longer be considered trustworthy — cyber risk becomes industrial risk.
On 2 September 2025, Jaguar Land Rover confirmed it had suffered a cyber incident and had proactively shut down its systems to limit the impact. Production and retail activities were severely disrupted.
On 10 September, JLR stated that some data had also been affected and that the relevant authorities had been notified.
Recovery then proceeded gradually. On 25 September, parts of the information system were brought back online: invoice processing capability, spare-parts logistics and the financial system required for vehicle sales. Production itself restarted in a controlled way over the following weeks.
An entity using the name “Scattered Lapsus$ Hunters” claimed responsibility and published screenshots presented as coming from JLR internal systems. That claim is not a confirmed attribution: a month after the events, the initial modus operandi and the attribution remained publicly unconfirmed.
Impact chain
We describe an impact chain rather than an attack chain: the exact initial access vector has not been publicly established.
Because the initial access has not been publicly documented, it would be wrong to turn the JLR incident into definitive proof of an IAM weakness.
The case does, however, illustrate a fundamental question: after authentication, are we still able to determine whether an identity, a session or an action remains legitimate?
Groups associated with the Scattered Spider / ShinyHunters ecosystem are known for social engineering and identity impersonation. That scenario is therefore credible as a risk to address, but it must not be presented as the demonstrated cause of the JLR incident.
For Ariovis, the real lesson is broader: an industrial organisation cannot protect its critical processes by controlling the login alone. It must also control privileges, account recovery procedures, MFA factor changes, sessions and the behaviours that follow authentication.
Authentication is only the beginning of control
MFA can prevent the direct theft of a password. On its own, it does not answer every situation in which a legitimate identity is hijacked. Security must therefore continue after the login: privilege changes, account recovery, enrolment of a new authenticator, access to a critical resource, unusual volumes or actions inconsistent with the expected role should all be able to become risk signals. That continuity between identity, privilege and real usage is what reduces the blast radius when an account is eventually compromised anyway.
The help desk is an administration interface
A support team able to reset a password, change an MFA factor or restore access to an account is indirectly performing a privileged function. A weak account recovery procedure can therefore neutralise the protections put in place at authentication time. For sensitive accounts, an organisation should typically provide for:
These are recommendations derived from the risk, not a diagnosis of JLR's information system: nothing publicly indicates that these controls were missing.
Production: several weeks of major disruption and the shutdown of production sites.
Supply chain: more than 5,000 UK organisations estimated to be affected by the Cyber Monitoring Centre.
Economic impact: an estimated £1.9bn impact on the UK economy, per the Cyber Monitoring Centre. This is an estimate for the UK economy, not a loss figure published by JLR.
Data: JLR confirmed that some data was affected, without publishing at this stage an exhaustive scope that would allow anyone to claim a complete exfiltration of its internal data.
When IT becomes a physical dependency of production.
The JLR case shows that, in a heavily digitised industry, you do not need to compromise an industrial controller directly in order to stop a factory.
If logistics, financial flows, supply, sales systems or the applications required for manufacturing become unavailable or untrustworthy, the organisation may be forced to physically halt production.
The blast radius of an IT compromise can therefore become industrial. This reading assumes no identified failure at JLR: it describes a structural dependency shared by most manufacturers.
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
Go further
These measures are presented as risk reducers applicable to any industrial organisation. They do not imply that they were missing at JLR.
Phishing-resistant MFA
FIDO2 / WebAuthn for sensitive user populations and administrators, rather than factors that can be intercepted or relayed.
Hardened account recovery
A separate process for privileged accounts, with additional verification and possibly third-party approval.
Protecting MFA enrolment
Treat adding or replacing an authenticator as a sensitive operation, logged and notified.
PAM and just-in-time privileges
Reduce standing administrative rights and limit a compromised account's ability to move through the estate.
Post-authentication detection
Do not treat a session as legitimate simply because the user passed authentication.
Segmenting critical systems
Limit the ability of a compromise in the office or administration estate to reach the processes required for production.
Controlling privileges, account recovery procedures and the behaviours that follow authentication: that is the core of our data breach prevention approach.
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.
