Farmers Insurance insures homes, cars, lives and small businesses for millions of customers. In August 2025, it began notifying 1,111,386 of them that their personal data had been stolen. Farmers' own systems were not breached. A third-party vendor told Farmers on May 30, 2025 that an unauthorized party had gotten into a database holding Farmers customer information the day before.
Reporting tied the Farmers Insurance data breach to a campaign that stole data from dozens of Salesforce customers in 2025. The attackers did not exploit Salesforce. They phoned employees and talked them into connecting a malicious app.
This teardown walks the timeline, the chain from phone call to bulk export and how to test your own SaaS estate for the same path.
What CodeAnt AI solves here: CodeAnt AI tests the connections between your identity provider, SaaS platforms and the data behind them, including OAuth-connected apps. It proves whether one compromised session or app grant reaches customer records, with a working proof of exploit for each high or critical finding.
What Happened in the Farmers Insurance Data Breach
The dates below come from Farmers' own notice and reporting by Security Boulevard, CX Today and CPO Magazine.
Date | What happened |
|---|---|
March 2025 | Salesforce warns customers about vishing calls and malicious modified versions of its Data Loader app. |
May 29, 2025 | An unauthorized party accesses a third-party vendor's database containing Farmers customer data. |
May 30, 2025 | The vendor detects the activity, blocks the actor and notifies Farmers. |
June 4, 2025 | Google Threat Intelligence Group publishes its analysis of the UNC6040 vishing campaign against Salesforce customers. |
August 22, 2025 | Farmers begins notifying affected customers and reports 1,111,386 people to regulators. |
Close to three months passed between detection and customer notification. That gap drew criticism once the breach became public.
What Data Was Exposed
Farmers said the stolen records included the following fields.
Identity data: Names, addresses and dates of birth.
ID numbers: Driver's license numbers and the last four digits of Social Security numbers.
For an auto and home insurer, driver's license numbers are core underwriting data. They are also exactly what identity thieves use to pass verification checks elsewhere.
The Attack Chain, Technically
Farmers has not named the vendor. BleepingComputer reported that the data was stolen in the Salesforce campaign, and the chain below follows the method Google documented for it.
Stage 1. A vishing call posing as IT support
The attackers call employees while impersonating internal IT support, often about a supposed connectivity or ticket issue. Google's analysis says they targeted English-speaking employees of large companies. No email is involved. Mail filters and link scanners never get a chance to see anything.
Stage 2. A malicious connected app approved by the victim
During the call, the attacker walks the employee to Salesforce's connected app setup page and has them enter a connection code. Google's report says the app being approved was usually a modified version of Salesforce's Data Loader with different branding. That one approval hands the attacker an OAuth grant to query and export data from the org. Salesforce said the campaign exploited no vulnerability in its platform, and every step used a legitimate feature.
Stage 3. Bulk export through the API
Data Loader exists to move large volumes of records in and out of Salesforce. In attacker hands, it pulls entire tables. Google observed the group testing with small queries first, then ramping up to full table exports. In one case, detection cut them off after about 10 percent of the data, which is the best outcome this chain allows.
Stage 4. Persistence that survives a password reset
An OAuth grant is a standing credential. Resetting the employee's password does not revoke an app the employee already authorized. Incident response that stops at "reset the password" leaves the attacker's pipe open. Revoking the connected app has to be its own explicit step.
Stage 5. Extortion weeks or months later
Extortion demands in this campaign often came well after the theft, from actors using the ShinyHunters name. The group behind the Farmers theft claimed that ShinyHunters and Scattered Spider are the same. Farmers' vendor did one thing right. Its monitoring caught the activity quickly and blocked the actor, according to Farmers' notice.
Why the Salesforce Campaign Hit So Many Companies
Farmers was one of many. The same method reached Google, Workday, Allianz Life and a long list of other Salesforce customers across 2025. The campaign worked because a CRM concentrates customer data in one place and offers powerful, legitimate export tools. A single approved app turns both into an exfiltration channel.
Security control | Did it stop this chain? | Why |
|---|---|---|
Email security | No | The attack arrived by phone |
MFA on user login | Often no | The employee approved the app from an authenticated session |
Password reset after detection | No | The OAuth grant keeps working |
Connected app allowlisting | Yes | Unapproved apps cannot be authorized |
Bulk export monitoring | Partly | It can cut off exfiltration mid-stream |
For insurers, this is a vendor-risk problem as much as an internal one. The data sat in a vendor's system, and Farmers' customers paid the price.
What a Real Test Against This Chain Looks Like
The phone call is a social engineering test. The rest of the chain is technical and testable.
Chain link | What the test checks | Evidence it produces |
|---|---|---|
Connected app policy | Whether any user can authorize a new OAuth app without admin approval | Proof of whether the setup page accepts unapproved apps |
Existing grants | Every connected app with API or bulk access to customer data | A live inventory of standing OAuth credentials |
Export scope | What a standard user's session can pull through the API | Records and objects reachable in bulk |
Revocation | Whether incident response actually kills app tokens | Proof that access ends when it should |
Vendor data paths | Which vendors hold your customer data in SaaS platforms they control | A map of third-party exposure |
The McKesson breach teardown walks the same vishing, SSO and OAuth chain in more technical detail. Our API penetration testing guide covers how scope and authorization testing applies to SaaS APIs.
Lessons for Auto, Home and P&C Insurers
The Farmers Insurance data breach carries lessons for any carrier that shares customer data with vendors running SaaS platforms.
Lock down connected apps: Require admin approval for every new OAuth app in Salesforce and every other SaaS platform holding customer data.
Inventory existing grants: Review which apps already hold API access, and remove anything unused or unrecognized.
Treat app revocation as an IR step: A compromised-account playbook must revoke OAuth tokens as well as reset passwords.
Alert on bulk exports: Large API exports by a new app or a user who never exports should trigger review.
Push the same controls to vendors: Ask vendors holding your data how they restrict connected apps and monitor exports, then verify.
Know your regulatory clock: Insurers answer to the GLBA Safeguards Rule, NYDFS Part 500 and state data security laws, all of which reach third-party service providers.
Our guide to how insurance companies get breached through portals, APIs and vendors covers why the vendor path has become the dominant way into insurers.
How CodeAnt Would Have Caught This
The breach happened in a vendor's environment, and Farmers has not named the vendor. So we can't claim CodeAnt would have prevented it. What CodeAnt tests is the exact seam this campaign used, between an authenticated identity and the data a SaaS platform will export.
Gray box testing from a compromised session: Agents authenticate as a standard user and chain what that session can reach, including API scopes and bulk export paths.
API-scoped testing for connected apps: OAuth scopes and app grants are tested directly, so a standing credential with bulk access gets found before an attacker uses it.
Proof instead of a severity label: A broad app scope gets tested for whether it actually reaches customer records, and the finding ships with a working proof of exploit.
Continuous coverage: A newly authorized app or widened scope gets tested when it changes, instead of waiting for next year's engagement.
The walkthrough of how AI penetration testing traces a data leak shows a full chain end to end.
The Fix
The Farmers Insurance data breach needed one phone call, one approved app and one export tool that worked exactly as designed. The weak point was the permission to connect, and it sat in a vendor's system. Lock down who can authorize apps, inventory the grants you already have and test what they can export.
Run a free black box scan on one URL to see your exposed surface, then book a walkthrough to see SaaS and API chains tested through to a proven data leak. For the compliance side, start with our guide to penetration testing for insurance companies.
