mythsthe appsSalesforce vishing campaign (UNC6040)6040saas / cross-sector

everyone assumed:

we have MFA on salesforce, so nobody gets in without us noticing

what was actually true:

In the Salesforce vishing campaign an employee approved the attackers' app during a phone call, and the FBI assesses that approval bypasses MFA, password resets and login monitoring.

how it happened

  1. whoa caller posing as IT supportUNC6040, per the FBI and Google
  2. the gapa connected app approvedby an employee, during the call
  3. thenbulk exportthrough API queries
  4. the resultextortionShinyHunters-branded, per the FBI and Google
the gap that let it happen the result

what everyone assumed

Multi-factor authentication is a reasonable answer to the question of how a CRM is protected: it guards the login, and a login is how most people picture an intruder arriving.

No victim in the sources said this out loud, so the belief on this page is an editorial inference, labelled as such: that MFA on Salesforce means nobody gets in without the company noticing. The inference rests on what the sources say about the route. The FBI states that authorizing a malicious connected app “bypasses many traditional defenses”, and lists MFA, password resets and login monitoring among them. Google’s threat intelligence group (GTIG) describes the same gap: MFA alone does not stop a user who approves the app themselves.

what happened

The mechanism is documented by three primary sources that agree with each other: Salesforce’s blog of 12 March 2025, GTIG’s report of 4 June 2025 and the FBI’s FLASH of 12 September 2025.

The caller. Per the FBI, UNC6040 actors phone staff, often call-centre or support staff, posing as IT support who are “addressing enterprise-wide connectivity issues”, under the guise of closing an auto-generated ticket. The FBI dates this activity to October 2024.

The approval. The employee is guided to the connected-app setup page and approves a modified version of Salesforce’s Data Loader. Salesforce, GTIG and the FBI describe this step the same way. In one case GTIG documents, the app was named “My Ticket Portal”, a name chosen to fit the ticket story. Salesforce’s blog of 12 March 2025, updated on 14 March 2025, warned customers about vishing, a modified Data Loader running under another name, and that setup page.

The apps. The FBI says the attackers registered the malicious apps from Salesforce trial accounts. Once approved, the app exports data in bulk through API queries.

The panels. Alongside the app, the FBI and GTIG describe phishing panels shown to victims that ask directly for credentials and MFA codes. GTIG reports movement from there to Okta and Microsoft 365 using phished credentials.

The extortion. The FBI describes extortion by a ShinyHunters-branded actor (UNC6240) arriving after a delay of days to months. GTIG describes demands in bitcoin with a 72-hour deadline. GTIG also suspects UNC6040 worked with a second actor who monetised the data. That is a hypothesis in GTIG’s wording, not an established fact.

Salesforce’s position, as SalesforceBen quotes a statement of 7 August 2025, is that the activity was not due to “any known vulnerability in our technology”. Mandiant’s January 2026 report makes the same point about the compromises it tracks. That is accurate, and it shows why a platform fix alone would not have prevented the approvals.

step by step

  1. a company connects apps to SalesforceAn employee approves a connected app on the Salesforce setup page, and the login itself sits behind MFA.
  2. since October 2024a caller asks for one approvalThe FBI says UNC6040 has gained initial access since October 2024 through voice phishing, with the caller guiding the employee to the connected-app setup page.the assumption breaks here
  3. the app exports the dataThe FBI describes bulk export through API queries, followed by extortion.
  4. 12 September 2025the FBI publishes a FLASHIt follows Salesforce's blog of 12 March 2025 and Google's report of 4 June 2025.

how it surfaced

Salesforce published its warning on 12 March 2025. GTIG named UNC6040 on 4 June 2025, and the FBI followed with its FLASH on 12 September 2025, which separates UNC6040 (vishing) from UNC6395 (the stolen tokens in the Salesloft Drift incident).

Google also reported its own case. The GTIG post says Google’s corporate Salesforce instance was hit by similar activity in June 2025, and an update dated 5 August describes the data involved as contact data for small and medium businesses, basic and largely public. This is the only instance in the sources where a company says “Salesforce” about itself in connection with this campaign.

In 2026 Mandiant (30 January 2026) and Okta (22 January 2026) described a different technique with the same human step. Per Mandiant, the caller says the company is updating its MFA settings, the victim is sent to a lookalike SSO site, and the attacker registers their own MFA device before reaching Salesforce, SharePoint, DocuSign and Google Workspace. Okta describes phishing kits built for live calls that follow the caller’s script and defeat push with number matching. Mandiant tracks the intrusion clusters (UNC6661 and UNC6671) separately from the extortion cluster (UNC6240) and says separate individuals may be involved. The Retool incident shows the same phone-call pattern against a second factor, and the Tycoon2FA page covers kits that relay codes.

what the record does not settle

  • The victim count. The GTIG post as read gives no total, and attacker claims on leak sites are far larger and unverified.
  • Who was hit by which route. Several companies described incidents on an unnamed third-party platform without naming Salesforce, and press lists often merge this campaign with the stolen-token waves, which the FBI keeps apart. The Gainsight page covers another token route. This page names no victim beyond Google, because no other company in the sources says it was hit by this route.
  • Who is behind the 2026 wave. The attribution to ShinyHunters is partly confirmed at best.

An approved connected app skips the checks built around logging in.

The useful question is who in your company is allowed to make that approval. The guide to Salesforce connected apps covers the list you already have, and the guide to profile creep covers who holds the permissions. The Marks & Spencer and MGM Resorts pages share the phone-call pretext.

picture it at a company like yours

The company here is made up. The other two paths are not: they happened, and each links to the story.

your company
a normal dayYour support team lives in the CRM, and a call from someone claiming to be IT is an ordinary part of the day.
the gap nobody seesNobody has written down who may approve a new app, so whoever is on the phone can.a second factor that can be relayed
  1. in this story
    the day it mattersThe caller says a ticket needs closing and talks a support agent through one approval screen.
    what it costs youYour customer records leave through an app your own people approved, and you hear about it in an extortion message.
  2. or it goes like this
    howA fake login page passes the password and code to the real site as they are typed.
    what leavesinternal documents, code and dashboardswho ends up with itthe attacker behind the page
    it happenedReddit, 2023
  3. or it goes like this
    howLogin prompts keep coming until a tired employee taps approve.
    what leavesadmin tools and company chatwho ends up with itan attacker who bought a contractor's password
    it happenedUber, 2022

sources

  1. Salesforce blog: Protect against social engineering (12 March 2025, updated 14 March 2025)
  2. Google Threat Intelligence Group: The Cost of a Call: From Voice Phishing to Data Extortion (4 June 2025, with updates)
  3. FBI (IC3) FLASH: Cyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Instances (12 September 2025)
  4. Mandiant / Google Threat Intelligence: Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft (30 January 2026)
  5. Okta Threat Intelligence: Phishing kits adapt to the script of callers (22 January 2026)
  6. SalesforceBen: Salesforce data theft roundup (secondary source for the 7 August 2025 Salesforce statement)

← all myths

your turn

what you can do about it

  1. this week

    List who in Salesforce may approve a connected app, and cut that list to named admins.

    In Salesforce Setup, list every user who holds "Manage Connected Apps", "Customize Application" or "Modify All Data", and remove those permissions from anyone who is not a named administrator. GTIG recommends limiting the first two to trusted admins. Then add one rule to the staff guide: nobody approves an app or enters a connection code because of a phone call, and anyone who gets such a call hangs up and rings IT on the number on the intranet.

  2. go deeper

  3. if you're not sure where to start

    Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.

    open the checklist →

the letter · every two weeks

one access gap in your inbox, with the fix.

Every issue takes one way access creeps in, shows a real incident where it went wrong, and ends with one thing to check that week. Written for the people who run the tools, without a security team behind them.

  • 1one mechanism, explained plainly
  • 2one real incident, taken apart
  • 3one step you can take on Monday

get the next issue

One email every two weeks. Your address stays here and is never passed to vendors. One click to unsubscribe. Privacy.