The Salesforce Breach Pattern Big Tech Can’t Blame on Passwords

The sharpest technology accountability story today is not a single hacked database. It is a year-long pattern showing how attackers can walk through trusted software integrations, harvest customer data, and leave conventional login defenses looking almost ornamental.

New research from Microsoft, reported Tuesday by The Hacker News, maps a chain of Salesforce-related intrusions tied to ShinyHunters-branded activity from mid-2025 into mid-2026. The common thread is brutally simple: the attackers often did not need to break Salesforce itself. They abused the permission structure around Salesforce — OAuth approvals, third-party integrations, stale credentials, and misconfigured public-facing guest access — to reach corporate customer data through channels companies had already blessed.

That makes the story bigger than Salesforce, Microsoft, or any one vendor caught in the blast radius. It is a live test of how modern enterprise software is governed after years of piling apps, AI assistants, sales tools, chat widgets, market-intelligence products, and support platforms on top of the same customer records. The security model still talks like it is guarding doors. The attack surface now looks more like a backstage pass system where old badges, vendor keys, and overbroad app permissions can be as dangerous as a stolen password.

Microsoft’s research groups the activity into three paths: voice-phishing that tricks employees into approving malicious connected apps; stolen OAuth tokens from trusted software vendors; and Salesforce Experience Cloud guest-access misconfigurations that expose data without a normal login. The company said it saw activity across tenants in sectors including retail, education, and manufacturing, according to The Hacker News. It also worked with Salesforce on additional detection and governance features meant to surface activity that ordinary sign-in monitoring may miss.

The accountability question is now unavoidable: if the most sensitive customer systems in an organization depend on integrations that can quietly keep broad privileges for months, who is responsible for proving that those privileges are still needed?

The attack hiding in the consent screen

The first path is the cleanest illustration of the problem. In the campaign Microsoft described, attackers used voice-phishing calls that posed as IT support and guided employees through Salesforce’s OAuth consent process. The malicious app reportedly presented itself as Salesforce’s Data Loader, a legitimate tool used to import and export Salesforce data. Once a user approved the app, the attacker could make API calls as that user.

No malware had to run on the victim’s laptop. No password had to be replayed against a login page. The user had been persuaded to grant an application permission, and that grant became the doorway.

Google’s Threat Intelligence Group and Mandiant documented related 2025 activity under the tracking labels UNC6040 for initial access and UNC6240 for follow-on extortion. Google said last year that one of its own corporate Salesforce instances was affected in June 2025, with the attackers accessing largely public business contact information before the activity was cut off. The same broader wave was publicly connected to incidents involving brands including Chanel and Pandora, while additional companies were named in reporting and victim claims.

This is where the usual corporate “user training” answer starts to look thin. Yes, employees need to be trained not to approve unknown apps during a phone call. But the larger system also has to answer why a consent click can create durable access to high-value records, why a lookalike connected app can pass as normal long enough to matter, and why security teams often learn about dangerous app behavior after the data has already moved.

The human is the front door in this version of the attack, but the building was designed with too many side rooms already unlocked.

The vendor compromise problem

The second path is more troubling because it does not depend on tricking one employee inside the target company. Instead, the attacker compromises a vendor whose product already has OAuth access into many customers’ Salesforce environments. Steal the tokens or integration secrets there, and one breach can become a downstream data-extraction campaign across multiple companies.

That is the supply-chain version of a CRM breach. The victim company may have multifactor authentication, conditional access policies, and alerting on employee logins. None of that necessarily catches an approved integration behaving badly if the logs are not attributing activity to the specific connected app and its granted scopes.

The Salesloft Drift incident is the clearest example in the public record. In 2025, attackers stole OAuth and refresh tokens connected to Drift, the sales and chat integration, and used them against Salesforce customer environments. Google estimated the token theft potentially exposed more than 700 organizations. Companies including Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, PagerDuty, and Tanium were among those publicly identified in connection with the incident. Cloudflare’s Cloudforce One tracked the cluster as GRUB1, while Google used UNC6395.

Salesloft later said the root cause involved attacker access to its GitHub account months earlier, which was then used to reach Drift’s cloud environment and harvest tokens. The attackers were not just grabbing contact lists. Reporting and vendor writeups described searches through support cases and other Salesforce objects for cloud keys, Snowflake tokens, passwords, and other secrets that could open additional systems. In other words, CRM data became a map to the rest of the company.

That should scare boards more than a simple breach count. Salesforce is not just a rolodex with a better interface. In many companies it holds customer negotiations, support tickets, pricing, contracts, internal notes, partner records, and sometimes secrets that should never have been pasted into a ticket or sales note in the first place. When a vendor integration can query that system at scale, it is not a narrow app-risk problem. It is enterprise data-governance debt.

The same vendor-token pattern appeared again in the Gainsight incident reported in late 2025. Salesforce pulled Gainsight-published apps after unusual API activity was detected, and Google linked the campaign to ShinyHunters-affiliated activity affecting more than 200 Salesforce instances, according to The Hacker News. ShinyHunters-linked actors claimed the Salesloft and Gainsight waves together reached close to 1,000 organizations, a number that has not been independently confirmed.

The unconfirmed number matters less than the architecture. A single vendor permission can scale a breach faster than a phishing campaign ever could.

Klue showed how old credentials become live blast radius

The most recent case in this pattern is Klue, the competitive-intelligence platform that disclosed in June that an attacker had accessed part of its integration infrastructure. Klue said the attacker used a compromised legacy credential associated with an integration service, obtained OAuth tokens connecting Klue to third-party platforms including Salesforce, and then accessed data in a number of connected customer environments.

Klue said it revoked affected credentials and tokens, removed unauthorized code, disabled potentially impacted integrations, launched an investigation, notified law enforcement, and engaged CrowdStrike. It also said it found no evidence that customer content stored within the Klue platform itself was affected.

Huntress, one of the affected customers, published its own account. It said copied data from its Salesforce account included business contacts, price quotes, and other sales-related data and messaging. Huntress said it found no indication of impact to its products or infrastructure, and that no threat data, passwords, payment-card information, or engineering data relating to the Huntress agent or telemetry was affected.

That narrower scope is important. Not every Salesforce-related breach means core product systems were compromised. But it also shows why these incidents can be minimized too quickly. Business contacts, pricing quotes, sales communications, and customer relationship notes are sensitive. In the wrong hands, they can support extortion, competitive intelligence, social engineering, vendor impersonation, and follow-on attacks against customers.

CybersecurityNews reported that at least nine organizations publicly disclosed impact from the Klue incident, including HackerOne, Huntress, Jamf, LastPass, Malwarebytes, Mimecast, Recorded Future, Rubrik, and WatchGuard. BleepingComputer reported that LastPass disabled employee access to Klue, rotated exposed API and OAuth tokens, and notified law enforcement.

The Klue case is the one every company should put on a slide for its own audit committee, because the reported entry point was not a glamorous zero-day. It was a legacy credential tied to an integration service. That is the kind of leftover operational artifact companies accumulate by the thousand: test integrations, pilot tools, temporary vendor connections, apps from departed teams, and service accounts that nobody wants to touch because nobody is fully sure what they still do.

Attackers love uncertainty. It gives stale access a long shelf life.

Guest access is the quiet third lane

The third path Microsoft described is different: misconfigured guest access in Salesforce Experience Cloud sites. Experience Cloud lets companies build portals and public-facing digital experiences connected to Salesforce data. Guest users are supposed to have limited permissions. But if those permissions are too broad, an unauthenticated visitor can reach more than intended.

Microsoft reportedly saw suspicious guest-user activity against Salesforce Aura endpoints, including calls to GraphQL Aura controller functionality. By using cursor-based pagination, attackers could pull records beyond the standard 2,000-record query limit where guest permissions were improperly configured. The related detection pointed to tooling known as AuraInspector used to probe those endpoints.

Again, the pattern is not “Salesforce had a simple bug and everyone else was helpless.” The pattern is that enterprise platforms are powerful enough to expose data in ways customers and vendors do not always understand, while the logs and permissions needed to police that exposure lag behind the business appetite to connect everything.

This is why “shared responsibility” can become a fog machine. Salesforce can say customers must configure guest access correctly. Customers can say vendors and platforms should make risky defaults harder. Vendors can say they are following the scopes customers approve. Meanwhile, attackers are reading the gaps as a product manual.

What Microsoft and Salesforce are trying to fix

Microsoft’s response is aimed at the telemetry gap. According to The Hacker News, Microsoft worked with Salesforce to improve Defender for Cloud Apps’ Salesforce connector, including support for Salesforce Shield Event Monitoring and Real-Time Event Monitoring. The goal is to show which connected app made a call, what OAuth scopes it holds, and whether its behavior fits the tenant’s normal pattern.

Microsoft also added governance features for connected OAuth apps, including a way to surface highly privileged apps, identify unused apps that have been inactive for 90 days or more while retaining permissions, and assign a 0-to-100 risk score that teams can use for alerts and policy decisions.

Those are useful controls. They also amount to an admission about where the old model failed. A lot of companies built security programs around the person logging in: MFA, device posture, location, session rules, and conditional access. But modern enterprise work increasingly happens through non-human access: app-to-app connections, API tokens, service accounts, sales and support integrations, AI workflow tools, and vendor automations.

If the security team cannot easily answer “which app touched this data, why did it have that permission, when was the permission last reviewed, and what would break if we revoked it,” then the company does not really control its CRM. It rents control from the hope that every integration is behaving.

The practical fixes are not mysterious. Inventory connected apps. Remove unused integrations. Scope every remaining app to least privilege. Monitor API behavior by app identity, not only by user identity. Turn on Salesforce event logging where available. Lock down Experience Cloud guest permissions. Revoke and rotate tokens quickly when a vendor incident appears. Ban secrets from CRM notes and support cases. Require vendors to disclose how they store, rotate, and monitor OAuth tokens before they get production access.

The harder fix is cultural. Sales, marketing, support, and customer-success teams adopt tools because they help revenue teams move fast. Security often gets asked to bless them after the integration is already working and politically hard to unwind. That is how “temporary” permissions become permanent infrastructure.

The story is bigger than CRM

This is a technology investigations story because the public record now shows a repeatable accountability failure across the enterprise software stack. The risk did not come from one dramatic exploit. It came from a permissions economy that made trust portable, persistent, and hard to inspect.

That economy is expanding. AI agents, sales copilots, customer-support bots, data enrichment tools, and workflow automations all want access to the same high-value records. They will ask for OAuth scopes. They will create service accounts. They will move data across platforms. Some will be built by large vendors with mature security teams. Others will be fast-growing startups trying to win enterprise logos before their governance catches up.

The ShinyHunters-linked Salesforce campaign is a warning about what happens when that connective tissue becomes the attack surface. Big Tech and its enterprise customers have spent years selling integration as efficiency. Today’s evidence says integration also needs to be treated as custody.

For readers, the takeaway is plain: when a company says “no passwords were stolen,” that may be true and still not reassuring. The more important question is whether an approved app, a forgotten credential, or a public guest role could reach the same data without ever tripping the alarms built for a human login.

That is where the next breach may already be sitting: not outside the wall, but inside a permission nobody has reviewed since the pilot ended.

Sources

• Microsoft Security Blog, “Defending SaaS-based applications against ShinyHunters OAuth abuse,” July 13, 2026.
• The Hacker News, “Microsoft Maps Three Salesforce Attack Paths Tied to a Year of ShinyHunters Activity,” July 14, 2026.
• Google Threat Intelligence Group and Mandiant reporting on UNC6040, UNC6240, and related Salesforce social-engineering activity.
• Klue, “An Update on the Recent Klue Security Incident,” June 2026.
• Huntress, “Klue Breach Investigation,” June 2026.
• CybersecurityNews, reporting on the Klue breach and affected cybersecurity firms, June 2026.
• BleepingComputer, reporting on the Klue OAuth breach and downstream victim disclosures, June 2026.

---

Shadowfetch is a technology publication. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.