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.
Luxury / Retail · Initial access claimed in April 2025 · incident identified by Kering in June 2025 · made public in September 2025
A social engineering campaign in which a legitimate application authorization can become an exfiltration channel.
Financial services / Fintech · June – August 2025 · incident detected on 1 September 2025
Prosper established that an unauthorised third party had accessed its systems and obtained information through queries on databases containing customer and applicant data. The initial vector is not public, so the IAM value of the case begins after access: with the privileges capable of reaching the data directly and the signals that should accompany high-volume use.
Microsoft Entra ID · IAM / Identity security / Cloud · September 2025
A vulnerability combining Microsoft Actor Tokens with insufficient validation in the legacy Azure AD Graph API allowed cross-tenant impersonation up to Global Administrator privileges. The case shows why securing only the login and MFA is no longer enough.
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.
IAM can no longer govern humans only. A SaaS application can hold very powerful rights, act without interactive authentication and keep a trust relationship for months. Like any sensitive identity, it must therefore have an owner, a purpose, minimal rights, a lifecycle and observable behaviour. The goal is not to guarantee that no credential will ever be compromised, but that a compromised credential does not automatically become a master key to the organisation's data.
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.
A non-human identity can be compromised. It can also be created by the attacker with the unwitting help of a perfectly legitimate user. Governing NHIs therefore means controlling their whole lifecycle: who can create or authorize them, why they exist, which rights they obtain, how long they stay authorized and what they actually do with those rights. MFA remains essential. But after authentication a second problem begins: the authorization and the real use of the trust that was granted.
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.
“Identity is the new perimeter” does not only mean protecting a login: it means knowing what an identity — internal, provider or machine — is allowed to do once connected, then detecting when it steps outside that frame. In the Discord case, the question is not only “how do we prevent the theft of a support account?”, but also “why can a compromised support identity browse or extract so much data before its behaviour becomes obviously abnormal?”. That second question is what connects identity governance, fine-grained authorization and behavioural detection.
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.
An attacker does not need to break your MFA if they can hijack the process that resets it. Identity security therefore does not stop at the login: the continuity between identity, privilege and real usage determines what a compromise can reach — and, in manufacturing, how far the blast radius of an IT incident can travel into the physical world.
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 preventionSector : Luxury / Retail · Period : Initial access claimed in April 2025 · incident identified by Kering in June 2025 · made public in September 2025
A social engineering campaign in which a legitimate application authorization can become an exfiltration channel. The organisation concerned is Kering, with the houses reported including Gucci, Balenciaga and Alexander McQueen.
In June 2025, Kering identified that an unauthorised third party had gained temporary access to its systems and accessed customer data belonging to some of its houses. The incident was made public in September. The reported data includes names, email addresses, phone numbers, postal addresses and the total amount spent by some customers. Kering stated that no financial data such as a payment card number or bank account number had been compromised. The April 2025 initial access is a claim made by the attackers to the press, not a timeline published by Kering.
The incident was connected to the broad 2025 campaign against Salesforce environments. In that campaign, tracked by Google Threat Intelligence as UNC6040, the attackers called employees while impersonating IT support. Their goal was not necessarily to steal a password immediately: they sought in particular to convince the victim to authorize a Connected App controlled by the attacker, sometimes presented as a variant of Salesforce Data Loader.
That authorization then creates OAuth access the application can use to query Salesforce and extract data through the APIs. The traffic can therefore originate from a technically authorized mechanism. The security problem no longer sits only at the moment the user authenticates, but in the rights delegated to an application and in how they are used after that authorization.
Kering has not, however, published the technical detail that would allow anyone to state that this precise chain was used in its environment. It must therefore be presented as the campaign mechanics the incident was publicly associated with, not as an official reconstruction of the Kering intrusion. Attribution to UNC6040, and to the associated extortion operations using the ShinyHunters brand, is reported by threat analyses and specialised press: Google Threat Intelligence tracks the Salesforce intrusions under UNC6040 and the extortion phases under UNC6240, without these designations covering a single formally established entity together with ShinyHunters or Scattered Spider.
From the phone call to CRM extraction
Technical chain documented for the UNC6040 campaign the incident was associated with; Kering has not publicly confirmed every step of that sequence.
Reducing this case to “a stolen password” would miss the point. What matters is that a perfectly legitimate human identity can be manipulated into granting rights to an application. OAuth is not an authentication mechanism here but an authorization delegation mechanism: an application receives the right to access resources on behalf of a user or within an authorized context.
A Connected App, a service principal, an OAuth token or a SaaS integration must therefore be treated as governance objects in their own right: who owns them, who may authorize them, which scopes they are granted, which data they may read, from which environments they are normally used, how long their tokens stay valid, how they are revoked and what counts as normal activity for them.
This modus operandi also moves the trust model towards the support function. IT support is now part of the identity trust model: an attacker does not need to compromise support if they can convince the user that they are support. UNC6040 campaigns exploited exactly that trust, impersonating IT technicians or agents when contacting users.
The Ariovis conviction
Identity no longer stops at the user who signs in. As soon as a human can delegate rights to an application, that application also enters the trust perimeter. Governing modern identity means controlling the user, the delegation they grant and the behaviour of the resulting application identity.
What makes this case singular: the spend data
What makes this breach particularly sensitive is the presence of the total amount spent by some customers. An apparently commercial CRM field becomes a segmentation criterion for an attacker: it can help identify the most interesting customers for later phishing, impersonation or targeted extortion campaigns. That risk is a possible consequence of the exposed data, not a secondary fraud whose occurrence is established.
The attackers claimed to hold data associated with around 7.4 million unique email addresses. That figure has not been confirmed by Kering and must therefore not be presented as the official number of victims.
The reported information includes personal contact details and data about the spending of some customers. Kering stated that no payment card number, bank account number or official identity document had been compromised.
This incident shows an important shift in identity risk. A user can be correctly authenticated and still trigger a dangerous chain by granting rights to an application. Once the OAuth authorization is obtained, the activity can look like that of a legitimate SaaS integration.
Defence must therefore go beyond controlling the login. Connected applications, tokens and non-human identities must be governed, then monitored for what they do after authorization. The right question is no longer only “who signed in?” but also “which application received which rights, from whom, and what is it doing with them now?”
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
No single measure is enough here: a FIDO2 key and phishing-resistant authentication reduce the risk of credential theft, but they do not necessarily stop a user who willingly authorizes a malicious application. Defence in depth is what narrows the attacker's room for manoeuvre.
Govern Connected Apps and delegation rights
Strict, deny-by-default governance of Connected Apps requires explicit approval of authorized applications and an up-to-date catalogue. It goes with limiting the “API Enabled” right and the rights that allow managing or authorizing connected applications, so that the ability to create a new trust relationship is not handed to every user.
Apply least privilege to scopes and technical identities
Least privilege must apply to OAuth scopes, technical accounts, integrations and non-human identities. An application does not need a perimeter that lets it query and export an entire CRM to deliver its expected service, and that perimeter is what determines how much data is actually reachable if it is abused.
Secure requests attributed to IT support
A robust verification process must govern any request from a supposed IT support function asking for an action that affects a user's identity, authentication factors or authorizations. This is complemented by phishing-resistant authentication and stronger control over administrative accounts and sensitive operations.
Detect after authorization, revoke fast
Behavioural detection focuses on what follows the authorization: a new Connected App appearing, access from unusual infrastructure, a sharp rise in API requests, mass exports or access to data volumes inconsistent with normal behaviour. It only has operational value if the organisation can quickly revoke the OAuth tokens and sessions tied to a compromised application.
Governing connected applications means governing identities: their owner, their authorization, their scopes, their lifetime and their observed behaviour after consent.
A CRM's commercial data is sometimes worth as much as a credential: preventing its exposure relies on the same identity, entitlement and monitoring controls.
See how Ariovis approaches data breach preventionSector : Financial services / Fintech · Period : June – August 2025 · incident detected on 1 September 2025
The 2025 Prosper Marketplace data breach documents neither the initial vector nor the identity used. It does, however, provide a useful basis for examining what an identity or technical principal can actually do once database access has been obtained.
Between June and August 2025, according to Prosper's later official notice, an unauthorised third party obtained personal data through queries on company databases containing customer and applicant information.
On 1 September 2025, Prosper detected unauthorised activity, activated its incident response process, engaged cybersecurity specialists and notified the authorities. The incident became public on 17 September through a filing with the SEC.
Prosper states that it found no evidence of unauthorised access to customer accounts or funds and that customer-facing operations were not interrupted.
The analysis of the affected data was completed on 26 November 2025, before individual notifications were sent in December.
A note on method: public disclosures do not describe how the third party obtained initial access, or which identity or technical principal was used. It would therefore be incorrect to turn this incident into a phishing, credential-stuffing, administrator-account compromise or DBA scenario without a source. The documents refer to database queries without establishing that they were necessarily SQL queries.
An attack chain limited to what we know
The chain deliberately begins with the first established fact. No compromised administrator account or initial-access mechanism is added by assumption.
The IAM problem is what an identity can do once access has been obtained. We do not know which identity or principal enabled the initial access. What the incident does show is that, once present in the environment, the third party had a path for directly querying databases containing particularly sensitive information.
The IAM angle is therefore not to claim that PAM would have ‘prevented Prosper’. It is to ask the questions every organisation should be able to answer: which human or technical identities can query these databases, with what scope, for how long, from which contexts, and with what real extraction capacity?
Authentication and authorization answer different questions. A technically accepted identity should not automatically be able to exercise every theoretical privilege without limits on scope, duration or context, or without monitoring how that privilege is used.
The Ariovis conviction
‘Identity is the new perimeter’ does not mean protecting the login alone. It also means controlling what a privileged identity can actually do once connected: which data it can reach, which operations it can perform, for how long and at what scale. Encryption, segmentation and perimeter controls remain necessary, but they are not sufficient on their own when authorised access already reaches the data. Controlling privilege and its use then becomes an additional layer of defence.
Exposed data
Prosper's notice lists the following categories, depending on the individual concerned:
Not every category necessarily applies to each person notified.
Prosper officially confirmed the exposure of personal and financial data. Its December notice lists official identifiers, bank details, tax information, payment data and credit-application information among the affected categories.
Have I Been Pwned separately records 17.6 million unique email addresses in the dataset associated with Prosper. Its entry also documents names, addresses, dates of birth, employment data, income levels, credit status, IP addresses and browser User-Agents. That figure is the number of unique addresses in HIBP's dataset; it is not an official victim count confirmed by Prosper.
The two sources therefore do not necessarily measure exactly the same thing: Prosper's notice qualifies the affected people and data categories, while HIBP counts the unique email addresses in the dataset it received.
These controls are not presented as safeguards that were absent at Prosper. They are lessons this modus operandi offers any organisation that exposes sensitive data to privileged identities.
The useful question is not to infer a missing control from information that is not public, but to verify whether data access can be scoped, observed and revoked before its use creates a disproportionate blast radius.
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
The Prosper case moves the question from ‘how did the attacker get in?’ to ‘what could they do once inside?’.
Reduce permanent power
When access to critical data relies on a very broad, standing privilege, the compromise of a single identity potentially able to exercise it can create a considerable blast radius. The priority is to reduce continuously available power and make it temporary where realistic.
Monitor use, not only the secret
A modern PAM strategy does not only protect administrative passwords. It makes sensitive operations traceable and helps detect when technically legitimate access is no longer used in a way that is consistent with its purpose.
Identity protection does not stop at login: it must scope, trace and monitor what a privilege can actually do to the data.
Preventing a data breach requires knowing which identities can reach the data, but also how much they can actually extract.
See how Ariovis approaches data breach preventionSector : Microsoft Entra ID · IAM / Identity security / Cloud · Period : September 2025
Microsoft Entra ID — CVE-2025-55241. A technical case on the chain of trust between services, Azure AD Graph and Microsoft Graph, and what it teaches about governing privileged identities.
In September 2025, the publication of CVE-2025-55241 revealed a particularly instructive vulnerability for IAM and cloud security teams. Discovered by researcher Dirk-jan Mollema, it combined an internal delegation mechanism called the Actor Token with a validation error in the legacy Azure AD Graph API, reachable via graph.windows.net. This combination theoretically made it possible to impersonate an identity belonging to another Microsoft Entra ID tenant, up to an account holding the Global Administrator role.
The vulnerability was reported to Microsoft on 14 July 2025. Microsoft rolled out a global fix on 17 July. CVE-2025-55241 was then published on 4 September, before Dirk-jan Mollema publicly detailed his research on 17 September.
The case matters because it relies neither on stealing an administrator's password, nor on MFA phishing, nor on a specific misconfiguration of the victim tenant. The flaw lay in the chain of trust itself: a legitimate service-to-service mechanism could be presented to a legacy component that did not properly check the tenant of origin.
The chain of trust involved
An explanatory view of the chain of trust, not an exploitation procedure.
Actor Tokens designed for service-to-service communication. Actor Tokens are tokens used by certain Microsoft services to communicate with each other and act on behalf of a user. Dirk-jan Mollema came across them while studying mechanisms related to Exchange and service-to-service communication. They allowed a service holding an Actor Token to build an impersonation token representing the user on whose behalf it had to act.
Broken cross-tenant validation in Azure AD Graph. The critical problem then lay in Azure AD Graph. During the research, the API accepted a token whose tenant of origin did not match the tenant being queried. Once a valid user identifier had been obtained in the target tenant, the researcher demonstrated in his test environments that it was possible to impersonate that user, identify a Global Administrator and then act with their rights.
The potential scope covered Entra ID tenants in the public cloud. This result does not extend to national cloud environments, which the researcher had not tested.
Why MFA and Conditional Access were not enough
It would be wrong to present this vulnerability as ‘breaking MFA’: in this scenario, MFA was simply not on the decision path. Actor Tokens were used for service-to-service communication and were not subject to Conditional Access policies the way an interactive user sign-in would have been. This incident therefore shows that an IAM strategy can no longer protect interactive authentication alone: it must also control sessions, applications, non-human identities, delegations and privileged actions.
Azure AD Graph made it possible to query users, groups, roles, applications, Service Principals, some tenant settings and Conditional Access policies. By impersonating a Global Administrator, an attacker could also have modified these objects, created new identities, added privileges or prepared access to other resources associated with the tenant.
The defensive difficulty came in particular from the visibility available. Issuing and using Actor Tokens did not produce the usual traces of a user sign-in, and read operations performed through Azure AD Graph had less telemetry than Microsoft Graph.
Write operations, on the other hand, could produce audit events. They were, however, likely to appear as having been performed by the impersonated Global Administrator and by a Microsoft service. The defensive question therefore becomes more complex than ‘do we have a log?’: it becomes ‘does this action attributed to a legitimate identity really correspond to a legitimate use of that identity?’.
1. Actually move off Azure AD Graph
Microsoft fixed CVE-2025-55241 on the service side, so migrating to Microsoft Graph is not the fix for this CVE. Azure AD Graph is, however, a legacy technology being retired, and an organisation that still has applications or Service Principals using graph.windows.net needs to identify them and prepare their migration to Microsoft Graph.
Modernisation must examine the whole chain rather than simply replacing a URL: authentication libraries, permissions, Service Principals, application dependencies, telemetry and operations.
2. Reduce standing privileges
Microsoft Entra Privileged Identity Management makes a user eligible for a privileged role and activates that role only when the task requires it, with additional mechanisms such as a limited duration, a justification, stronger authentication or an approval.
PIM would not have removed CVE-2025-55241. It does, however, reduce the amount of privilege permanently available and improves the governance of administrative identities, in line with a principle we apply elsewhere: reduce privilege at the source before stacking up additional technical mechanisms.
3. Monitor how identities are used after authentication
An external SIEM cannot invent telemetry that the source platform does not generate. Centralising events does, however, become particularly important as soon as an identity changes roles, adds credentials, modifies applications, changes policies or performs unusual administrative operations.
The goal is therefore not only to monitor sign-ins. Identity events, privilege changes, operations performed by Service Principals and post-authentication behaviour must be correlated to identify a technically valid identity whose use has become inconsistent.
Our IAM reading. CVE-2025-55241 is a reminder that an IAM set-up cannot be judged solely on the strength of its sign-in screen. An organisation can have MFA, Conditional Access and demanding authentication policies and still be exposed when a legacy API, a delegation relationship or a service identity offers another path.
Identity governance must cover the whole chain of trust: users, administrators, applications, Service Principals, tokens, delegations, APIs and the privileges actually exercised. The right question is therefore no longer only ‘who has just authenticated?’, but also ‘on whose behalf is this action being performed, why does this identity hold this privilege, and is this action consistent with what we expect from it?’.
Does your Entra ID security go beyond MFA?
A robust identity architecture must also control privileges, applications, Service Principals, delegations and administration paths. We can audit what exists, identify areas of excessive trust and build a security roadmap suited to your information system.
Assess our IAM architectureAriovis helps you map human and non-human identities, their rights, how they are really used, and the controls that reduce the risk of exfiltration.
