Salesforce Is the New Identity Goldmine — and Auth Apps Aren't the Answer
A repeatable, industrialized attack pattern is compromising Salesforce environments across regulated industries. The vulnerability is not in Salesforce. It is in the authentication model that controls access to it.
The Attack Pattern
Attackers are not exploiting Salesforce through zero-day vulnerabilities. They are exploiting the human workflow that grants access to it. The method is consistent: voice phishing, IT impersonation, and social engineering lead employees to authorize malicious connected apps or disclose credentials. Once authorization is granted, Salesforce issues OAuth tokens to attacker-controlled tools. From that point forward, the attacker operates as an approved application — querying customer records, support cases, contact tables, and opportunity data at scale.
The FBI has documented this pattern in its advisory on UNC6040 and UNC6395. UNC6040 has conducted voice phishing campaigns since at least October 2024, with attackers posing as IT support and directing customer service employees to actions that grant Salesforce access or disclose credentials — including MFA codes used to add Salesforce Data Loader. The FBI specifically noted that malicious connected app authorization can bypass traditional defenses such as MFA, password resets, and login monitoring, because the resulting OAuth tokens are issued by Salesforce and appear as trusted integration activity.
Google Threat Intelligence Group and Mandiant have described a related vector: UNC6395 targeted Salesforce customer instances through compromised OAuth tokens tied to the Salesloft Drift third-party application. GTIG assessed that authentication tokens stored in or connected to Drift should be treated as potentially compromised across all integrations, not only the Salesforce connection.
Two attack lanes have emerged. In the first, the attacker socially engineers the user into approving access — the voice phishing and malicious connected app pattern. In the second, the attacker acquires already-issued OAuth tokens from a compromised third-party integration. Both are identity failures. Both reflect the same structural problem: the enterprise SaaS access fabric has become a surface where a single approved identity, application, or token can serve as a master key.
Named Organizations Affected
The scope of confirmed and claimed breaches is significant. Malwarebytes reported that Google, Adidas, Louis Vuitton, Chanel, Allianz Life, Qantas, and Pandora were among organizations targeted through Salesforce social engineering — specifically, attackers posing as IT support directed employees to connect to a fraudulent version of Salesforce Data Loader, using an eight-digit code flow to link the victim's Salesforce environment to an attacker-controlled exfiltration tool.
CyberSignal reported that ShinyHunters claimed 9.4 million Amtrak records through a Salesforce breach, with 2.1 million unique accounts confirmed on Have I Been Pwned. The same social engineering playbook has been attributed to incidents involving ADT, Udemy, Medtronic, Vimeo, and Cisco. Medtronic appears in multiple reports as a confirmed ShinyHunters breach involving approximately nine million claimed records using the same Salesforce access chain.
CrowdStrike has separately documented Cordial Spider and Snarky Spider as financially motivated actors conducting high-speed SaaS data theft and extortion. These groups use voice phishing to route users to adversary-in-the-middle login pages, capture authentication data and active session tokens in real time, and pivot into identity provider-integrated SaaS applications. CrowdStrike assessed that these actors have operated since at least October 2025 across academic, aviation, retail, hospitality, automotive, financial services, legal, and technology sectors.
This is not an isolated incident pattern. It is a repeatable attack methodology with a growing list of confirmed victims — organizations with mature security programs, dedicated security teams, and existing MFA deployments.
Where Authentication Apps Fall Short
Authenticator apps were designed to answer a specific question: does the person logging in currently possess a second factor? That is a meaningful control in credential-stuffing scenarios. It is not sufficient against social engineering.
The authenticator app has no awareness of context. It does not know whether the user is being coached through a process by someone claiming to be IT support. It does not know whether the connected app being approved is legitimate or attacker-controlled. It does not know whether the OAuth consent flow will grant Salesforce API access to an external tool. It does not know whether the session will be converted into persistent SaaS access the moment approval is granted.
In social engineering attacks, the attacker manufactures the context the user perceives. They instruct the user on what to expect, what to enter, what to approve, and why the process appears legitimate. The authenticator app confirms that the user complied with those instructions. That is not a security verification. It is a confirmation that the human was present for the event the attacker designed.
The connected app attack vector compounds this failure. Once a user authorizes a malicious connected app, Salesforce issues OAuth tokens to that application. From that moment forward, the attacker may interact with Salesforce APIs as an approved integration. Password resets may not invalidate the token. Traditional login monitoring may see trusted application traffic rather than a hostile interactive session. The FBI's advisory is direct on this point: this technique can bypass MFA, password resets, and login monitoring because the activity is indistinguishable from legitimate integration behavior.
The authenticator app performed exactly as designed and still did not protect the data. It confirmed the wrong event. It verified user participation in an authorization flow the attacker controlled.
Why Salesforce Is a High-Value Target
Salesforce concentrates exactly the data that makes extortion viable: customer relationships, deal history, support records, contact details, case notes, partner information, and operational context. It is also deeply integrated with the rest of the business — connected to marketing tools, support platforms, analytics systems, data loaders, workflow engines, and third-party applications. That connectivity is the point of the platform. It is also what makes every integration a trust relationship.
An attacker who compromises a single approved identity, application, or token does not need malware on an endpoint. No exploit kit is required. No ransomware binary is necessary at the point of entry. The attacker operates inside the identity and SaaS control plane, using approved protocols, approved APIs, and approved sessions.
CrowdStrike assessed this directly: these attacks bypass traditional endpoint visibility because adversaries operate inside trusted SaaS environments and move quickly from access to impact. Endpoint detection does not see what it was not designed to see.
How Token Addresses This Class of Attack
Token shifts the authentication control point from user judgment to hardware-enforced cryptographic proof.
Token products use FIDO2 hardware-bound authentication. During enrollment, the Token device generates a unique public-private key pair for the specific service domain. The private key is created inside secure hardware and never leaves the device. The public key is registered with the service. At authentication, the legitimate service issues a cryptographic challenge. The Token device will only sign that challenge when three conditions are simultaneously satisfied: the origin matches the registered domain, the enrolled user provides a live biometric match, and the device is physically present at the authentication endpoint.
This architecture directly addresses the attack patterns documented by the FBI, GTIG, and CrowdStrike. A fraudulent Salesforce login page cannot obtain a valid Token signature — the origin does not match the registered domain. An adversary-in-the-middle proxy cannot relay a reusable code, because no code exists. Push fatigue attacks have no mechanism to exploit, because no push approval is presented. A caller coaching an employee through a fake support process cannot instruct them to read back a one-time code, because one-time codes are not part of the authentication event. A stolen password is insufficient to authenticate, because credential possession alone does not satisfy the hardware and biometric requirements. A stolen Token device is inoperable without the enrolled fingerprint. A remote attacker cannot authenticate on behalf of a user, because the device proximity requirement cannot be satisfied remotely.
Applied to the connected app problem specifically: if Salesforce administrative access, connected app authorization, Data Loader approval, and high-risk OAuth consent flows require Token biometric FIDO2 authentication, a social engineering caller cannot guide an employee through a phishable approval. The attacker needs the live fingerprint of the enrolled user, the physical Token device, cryptographic domain binding, and endpoint proximity — simultaneously. That requirement is categorically different from asking a user to enter a code.
Token does not make Salesforce immune to every misconfiguration or overprivileged integration. No identity product eliminates risk created by unlimited OAuth permissions or absent least-privilege controls. Enterprises deploying Token still require strict connected app policies, admin approval workflows, token revocation processes, application allow lists, and SaaS posture management. Token eliminates the most consistently exploited element of this attack chain: the ability to socially engineer a human into completing a phishable authentication event.
What Enterprises Should Do Now
Every enterprise operating Salesforce should immediately conduct a review of connected apps, OAuth grants, Data Loader configurations, API permissions, inactive users, privileged roles, and third-party integrations. Unnecessary tokens should be revoked. Connected app approval should be restricted to named administrators. New integration requests should require explicit admin review. Bulk export behavior should be monitored, and anomalous API activity should generate alerts. These are the baseline controls the current threat environment requires.
The structural change is to replace authenticator apps as the primary control for Salesforce, SSO, and privileged SaaS access. Authenticator apps are phishable. They can be coached. They can be relayed. They can be used — exactly as designed — to authorize attacker-controlled access.
Token moves authentication out of the realm of user judgment and into hardware-enforced proof: biometric match, cryptographic origin binding, hardware-resident private keys, device proximity enforcement. No shared secrets. No codes. No push prompts. No cloud-synced credentials.
The Fundamental Question
Salesforce has become a high-priority target because it holds the customer data that makes extortion viable, and because it is architecturally connected to the rest of the enterprise. Attackers understand this. The campaigns documented by the FBI, GTIG, CrowdStrike, and independent researchers are not opportunistic. They are deliberate, repeatable, and scaling.
The question organizations face is direct: if Salesforce access can be approved by a user receiving a phone call, the data inside it can be exfiltrated through the same call.
Authentication apps do not resolve that exposure. Token's hardware-bound, biometrically-enforced FIDO2 architecture does.
