Identity Is Under Attack. The Architecture Must Change.
CrowdStrike is now tracking two financially motivated threat groups—Cordial Spider and Snarky Spider—that are systematically targeting identity platforms and SaaS environments across aviation, retail, financial services, healthcare, legal, and technology sectors. Their methods: voice phishing, social engineering, and spoofed SSO pages. Their objective: valid access, obtained without defeating a single firewall.
These are not isolated incidents. They represent a repeatable, scalable playbook that succeeds because most enterprise authentication still depends on a single, exploitable variable: human judgment under pressure.
The Playbook Is Precise. The Defense Cannot Be Approximate.
The attack sequence is well-established. Attackers identify targets through LinkedIn, breached data repositories, and email pattern analysis. They initiate contact—by phone, text, or email—posing as IT support, security operations, or HR. They manufacture urgency: a locked account, an expiring SSO session, a device that requires revalidation. Then they direct the employee to a spoofed login page, visually indistinguishable from the organization’s real identity provider.
Once credentials are entered, the attacker relays the authentication in real time to the legitimate service. The session is captured. MFA devices are re-enrolled under attacker control. Inbox rules suppress security alerts. Within minutes, the attacker moves laterally through email, SharePoint, Salesforce, HR systems, customer portals, and financial records. Data is extracted. Extortion follows.
The identity provider is no longer just an access control. It has become the enterprise’s primary attack surface.
Authentication That Requires Human Judgment Is Not Security.
These attacks succeed for a structurally simple reason: most authentication systems ask users to make decisions that attackers have engineered them to get wrong. Did the employee notice the URL discrepancy? Did the help desk agent detect the social engineering? Did the user recognize the push notification as illegitimate?
Security awareness training is necessary but insufficient. Research indicates that a meaningful percentage of employees will fall for well-constructed phishing or vishing attempts regardless of training quality. Attackers do not require high failure rates. They require one. One credential. One approved prompt. One successful help desk reset.
Legacy MFA compounds the problem. SMS codes are intercepted or relayed. Authenticator app codes are captured in real time through adversary-in-the-middle proxies. Push approvals are bypassed through fatigue attacks. Help desks are manipulated into re-enrolling attacker-controlled devices. Session tokens are stolen and reused. Each of these vectors succeeds because legacy MFA still asks a human to validate what should be verified cryptographically.
The question is not whether an organization has MFA. The question is whether that MFA can be phished, relayed, socially engineered, or reset. If the answer is yes, MFA is now part of the attack surface, not a defense against it.
Cryptographic Identity Cannot Be Socially Engineered.
Token’s Biometric Assured Identity eliminates the attack surface these groups depend on—not by training users to make better decisions, but by removing human decision-making from the authentication path entirely.
Token uses FIDO2 authentication with hardware-bound cryptographic credentials, biometric verification, and domain-level origin binding. During enrollment, the Token device generates a unique public-private key pair scoped to the legitimate service. The private key never leaves the secure element. At login, the relying party issues a cryptographic challenge. Token will complete the authentication only if three conditions are simultaneously satisfied: the requesting origin matches the registered domain exactly, the user provides a live, on-device biometric match, and the hardware is physically present at the authentication endpoint.
This architecture removes each element of the Scattered Spider-style playbook:
-
A spoofed SSO page cannot obtain a valid Token signature—the domain binding fails at the cryptographic layer, before any credential is exchanged.
-
A real-time relay attack cannot convert a phished session into a valid authentication—origin binding is enforced by the hardware, not the user.
-
A stolen password provides no authentication path—there is no password-based factor to exploit.
-
A stolen device cannot authenticate—the authorized biometric is required and verified on-chip.
-
Push fatigue attacks are not possible—there is no push prompt in the authentication flow.
-
Help desk manipulation cannot enroll an attacker-controlled device—biometric binding prevents unauthorized re-enrollment.
The user can receive the vishing call. They can follow the link. They can arrive at the spoofed portal. The attack still fails—because the authentication event is cryptographically bound to the correct person, the correct device, the correct domain, and physical presence. None of those conditions can be fabricated remotely.
Detection Is Necessary. Prevention Is the Requirement.
Visibility into anomalous authentication events, suspicious MFA re-enrollment, impossible travel, and SaaS exfiltration remains essential. Detection capability matters. But when attackers move from initial contact to active data theft in under an hour, post-compromise detection is structurally insufficient as the primary control.
The best outcome is an attack that cannot initiate—because the credential is hardware-bound, the domain binding is cryptographically enforced, and there is no human decision point for social engineering to exploit.
Cordial Spider and Snarky Spider have validated what Scattered Spider established: this playbook works, scales, and is economically viable at volume. Others will replicate it. The identity attack surface will continue to expand as long as authentication depends on factors that can be phished, relayed, or reset.
Attackers are not breaking in. They are logging in—using credentials that human-dependent authentication cannot protect.
Token removes the conditions that make that possible. Phishing-resistant, hardware-bound, biometrically verified authentication does not ask users to make the right call under pressure. It makes the wrong call technically impossible.