UNC6040 Salesforce Breach: Vishing Attack Breakdown & Defense Guide

In mid of 2025, Google's own internal Salesforce instance was compromised by the very threat group they were tracking (UNC6040, also known as ShinyHunters) via a deceptive voice phishing (vishing) campaign and a malicious clone of Salesforce's Data Loader.

This breach, confirmed by Google's Threat Intelligence Group, isn't the only case: dozens of organizations across Europe and the Americas including Allianz Life, Adidas, Chanel, LVMH etc. have fallen victim to the same orchestrated method, resulting in widespread enterprise exposure and potential extortion threats.

Anatomy of the Attack

Step 1: Social Engineering via Vishing

UNC6040 impersonated IT support over the phone targeting English speaking branches of multinational firms. Using vishing, they persuaded employees to enact actions that unknowingly authorized a malicious connected application in Salesforce.

Step 2: Deployment of Fake Data Loader App

The attackers guided victims to Salesforce's connected app setup. There, a seemingly legitimate modified version of Data Loader, often labeled "My Ticket Portal" or "dataloader.io" was approved, granting UNC6040 persistent, privileged access, bypassing MFA.

Step 3: Data Exfiltration & Lateral Movement

Once inside, attackers exfiltrated CRM data, often focused on small to medium business contact information, business names, and notes, even if considered low-sensitivity. They then used lateral movement techniques to breach other SaaS platforms like Okta, Microsoft 365, and internal systems

Salesforce

Technical Analysis of the UNC6040 Salesforce Breach

While at first glance this attack appears to be a simple case of social engineering, the real sophistication lies in how UNC6040 exploited Salesforce's connected app ecosystem and abused OAuth 2.0 authorization flows to bypass traditional defenses.

Step 1: The OAuth 2.0 Exploit Path

Salesforce, like many SaaS platforms, supports OAuth 2.0 to let third-party applications connect securely. Normally, this prevents password sharing and enables fine-grained access.

UNC6040 abused this trust by:

1. Tricking users into navigating to "Connected Apps" settings inside Salesforce.

2. Convincing them to authorize a malicious OAuth app disguised as Salesforce Data Loader.

3. Once approved, Salesforce issued an OAuth refresh token to the attacker-controlled app.

This token acted like a "master key" giving attackers:

1. Persistent access (even after user password resets).

2. API-level privileges to export records, query data, and modify configurations.

3. MFA bypass, since Salesforce trusts OAuth apps as pre-approved.

Why this worked: Unlike login attempts, OAuth connections often don’t trigger SIEM alerts or MFA prompts, leaving a visibility blind spot

Step 2: Abusing Salesforce APIs for Data Exfiltration

The malicious app mimicked Salesforce's Data Loader functionality, a legitimate tool widely used for bulk operations. Once the OAuth token was issued, UNC6040 used Salesforce APIs to perform data extraction:

• /services/data/vXX.X/sobjects/Account/ → Extracted customer and business details

• /services/data/vXX.X/query?q=SELECT+Name,+Phone,+Email+FROM+Contact → Pulled sensitive PII

• /services/data/vXX.X/queryAll?q=SELECT+...+FROM+Case → Accessed CRM case notes, ticket histories

Logs show attackers frequently exfiltrated tens of thousands of records in one query, disguising the traffic under the guise of normal admin activity.

Step 3: Establishing Persistence

UNC6040 didn't stop at data theft. They implemented persistence in two ways:

1. Refresh Token Persistence

   • Refresh tokens allowed them to continuously re-issue access tokens.

   • Even if passwords were rotated, access persisted until the connected app was explicitly revoked.

2. Malicious App Renaming

   • Apps were registered under benign sounding names like "My Ticket Portal" or "Support Portal".

   • In several cases, these apps went unnoticed for weeks because admins assumed they were part of standard IT deployments.

Step 4: Lateral Movement Beyond Salesforce

Once embedded in Salesforce, attackers sought to pivot:

1. Harvesting credentials stored in CRM case notes.

2. Phishing customers and partners using exfiltrated contact info.

3. Leveraging Salesforce integrations with Okta, Microsoft 365, and Workday for lateral movement.

Why This Attack Was So Effective

1. Trust Misplacement → Users trusted IT-sounding vishing calls.

2. OAuth Blind Spots → Security teams often log failed logins but not OAuth app approvals.

3. Persistence Mechanism → OAuth refresh tokens bypassed credential resets.

4. MFA Ineffectiveness → Once the OAuth flow was approved, MFA was never re-prompted.

Scale & Impact

• Google's Salesforce breach occurred in June 2025. Although limited to basic business contact information, it illustrates how even nonsensitive CRM data can be weaponized.

• ~20 organizations confirmed to be impacted in an ongoing campaign spanning Europe and Americas. Some cases led to extortion attempts months after initial compromise

• Notable victims include:

  • Allianz Life - Over 2.8M customer records exposed

  • Major luxury and consumer brands like Adidas, Chanel, LVMH, and airlines (e.g., Qantas, Air France)

Detection & Defense Strategies

1. Connected App Monitoring

   1. Audit and allowlist only trusted connected apps. Salesforce's API Access Control is a powerful safeguard rejecting unauthorized or unknown OAuth clients.

2. Behavioral & OAuth Monitoring

   1. Track atypical OAuth app installations, especially those with names like "My Ticket Portal". Time or location based anomalies in OAuth activity may indicate malicious behavior.

3. User Awareness & Incident Prep

4. Least Privilege Enforcement

The UNC6040 Salesforce breach isn't about exploiting code, it's about hijacking trust. That voice on the phone, the familiar looking Data Loader tool, both were weaponized to breach leading enterprises.

Key Takeaways:

• Use defensive tools like API Access Control

• Audit connected apps regularly

• Train users on vishing and social engineering

• Enforce least privilege policies across users and SaaS tools

“In modern cloud ecosystems, attackers don’t break the software, they subvert the trust.”

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don’t forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let’s keep the conversation going and make cybersecurity a community effort!

-AJ