How Hackers Fooled Google With a Simple Phone Call

When news broke that Google had suffered a breach in August 2025, the assumption was that it must have been some sophisticated zero-day or a supply-chain exploit. The truth was almost embarrassingly simple. Hackers from the group known as ShinyHunters, also tracked as UNC6040, managed to con a Google employee into downloading a modified version of Salesforce’s “Data Loader” tool during a voice phishing call. Once the tool was installed, it silently siphoned Google’s Salesforce CRM data, which contained business contact information for more than two billion Gmail-linked accounts (Axios, 2025).

Google confirmed that no passwords or financial information were lost. Yet for defenders and attackers alike, the breach represents something bigger. It is proof that a social engineering tactic as old as the phone call can still puncture one of the most heavily defended companies in the world (Cloud Google, 2025).

Who Are the ShinyHunters?

ShinyHunters is not a new name in cybercrime. The group has been tied to dozens of high-profile breaches since 2020, including attacks on Microsoft’s GitHub repositories, Tokopedia, and Wattpad (ReliaQuest, 2025). They gained a reputation for selling stolen data on dark web forums, often opting for quick monetization instead of stealthy persistence.

The cluster tracked as UNC6040 appears to be either a splinter or evolution of ShinyHunters. Google’s Threat Intelligence Group reported that the tactics line up with earlier ShinyHunters campaigns, but with an increased reliance on voice phishing paired with OAuth token abuse (Cloud Google, 2025). Some researchers suggest possible collaboration with Scattered Spider, another well-known social engineering crew, citing overlaps in phishing infrastructure and domain registrations (ReliaQuest, 2025).

What makes ShinyHunters effective is not their coding skill but their ability to weaponize trust. They target employees directly, convincing them that IT needs them to “install a patch” or “verify access.” Once the malicious app is approved, MFA becomes irrelevant.

Offensive Tradecraft Exposed

Investigators say the breach began with a phone call that seemed routine. An attacker posing as a Google IT technician contacted an employee and claimed there was a problem syncing Salesforce data. To “fix” the issue, the employee was directed to download what looked like an official Salesforce Data Loader tool, but in reality was a trojanized version hosted on attacker-controlled infrastructure (Cloud Google, 2025).

Once installed, the fake Data Loader prompted the user to authenticate with their Salesforce credentials, granting the malicious app OAuth token permissions identical to those of the real tool. These tokens gave the attackers programmatic access to Google’s Salesforce environment without triggering MFA prompts (Vorlon, 2025). From there, the attackers quietly ran test queries to confirm access, then escalated to bulk exports of customer contact data using Salesforce’s own APIs. Because the activity looked like a legitimate employee using a standard tool, it blended in with normal business operations until exfiltration was complete (Obsidian Security, 2025).

From an offensive perspective, this campaign is a case study in low-cost, high-impact red-teaming turned real.

Vishing as Initial Access. Attackers placed phone calls that impersonated internal Google IT staff. The human voice provided legitimacy that phishing emails often lack (The Hacker News, 2025).

Trojanized Data Loader. Instead of malware hidden in an email attachment, the attackers weaponized a legitimate Salesforce tool. Once installed, it exfiltrated CRM data using Salesforce’s own APIs. Because it was authenticated with OAuth tokens, it bypassed MFA entirely (Cloud Google, 2025).

Token Persistence. The malicious connected apps held wide-scoped OAuth tokens, which allowed the attackers to return at will without re-authenticating. This made the breach resilient to password resets unless tokens were explicitly revoked (Vorlon, 2025).

Stealth Exfiltration. In many incidents tied to this campaign, the attackers tested their access with small data pulls before moving to bulk exports. This low-and-slow tactic avoided immediate detection (Vorlon, 2025).

Cross-Platform Reach. Once footholds in Salesforce were established, attackers attempted lateral moves into linked Okta or Microsoft 365 environments, leveraging token access and overlapping accounts (Cloud Google, 2025).

Why This Matters Offensively

For red teamers and offensive security professionals, this breach reinforces a core truth: human trust is the weakest perimeter. An OAuth token gained via social engineering is often more valuable than a zero-day exploit. Trojans built on top of legitimate administrative tools are harder to detect and almost impossible to block with antivirus. The offensive lesson is not just that social engineering works, but that targeting SaaS ecosystems through connected apps can yield massive returns with minimal complexity.

Defensive Takeaways

The breach also offers valuable defensive lessons.

Audit Connected Apps. Organizations must strictly control which apps can be installed in Salesforce or any SaaS platform. Remove unused apps and carefully vet new ones (Vorlon, 2025).

Monitor Event Logs. Salesforce provides logs that can flag suspicious Bulk API calls or unusual login locations. Consistent monitoring could have caught the anomaly earlier (Vorlon, 2025).

Vishing Awareness. Employee training often focuses on email phishing, but voice phishing simulations are just as important. Staff must know how to verify internal IT requests independently.

Token Governance. Security teams need policies to revoke OAuth tokens immediately during incident response. Password resets are not enough (Obsidian Security, 2025).

Limit Admin Rights. Only a small, vetted set of users should have the ability to install or approve connected apps.

Could Your Organization Be Next?

If your company uses Salesforce or other SaaS CRMs, here are the questions worth asking right now:

Do we know exactly which connected apps have been installed in our environment?

Are we monitoring for unusual data exports or Bulk API jobs?

Have we run vishing simulations with employees who have elevated privileges?

Do we have an incident response plan that includes token revocation?

If you cannot answer yes to all of these, you might already be vulnerable.

Closing Thoughts

It is tempting to dismiss this incident as just another phishing breach, but that misses the larger picture. Google was not breached through a zero-day or a sophisticated backdoor. It was breached because someone answered the phone and trusted the wrong voice. For ShinyHunters, that was all it took to outwit one of the largest tech companies in the world.

References

Axios. (2025, August 6). Google ShinyHunters Salesforce data breach. Axios. https://www.axios.com/2025/08/06/google-shinyhunters-salesforce-data-breach

Cloud Google. (2025, June 4). Voice phishing and data extortion by UNC6040. Google Cloud Blog. https://cloud.google.com/blog/topics/threat-intelligence/voice-phishing-data-extortion

Obsidian Security. (2025, August). ShinyHunters and Scattered Spider: Salesforce attacks. Obsidian Security Blog. https://www.obsidiansecurity.com/blog/shinyhunters-and-scattered-spider-a-merger-of-chaos-in-the-2025-salesforce-attacks

ReliaQuest. (2025, August). ShinyHunters data breach and Salesforce targeting. ReliaQuest Blog. https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration

The Hacker News. (2025, June). Google exposes vishing group UNC6040. The Hacker News. https://thehackernews.com/2025/06/google-exposes-vishing-group-unc6040.html

Vorlon. (2025, August). ShinyHunters Salesforce response tips. Vorlon Blog. https://blog.vorlon.io/shinyhunters-salesforce-response-tips