65 Seconds: How Cordial Spider Turns One Click Into Total Account Takeover

What happened

Last week, I helped respond to an active compromise at a large U.S. enterprise. The attacker was Cordial Spider, a threat group known for adversary-in-the-middle (AitM) phishing, fast MFA bypass, and automated data exfiltration at scale.

What made this incident remarkable was not the initial compromise (a phishing link, like thousands of others). It was the speed, automation, and persistence of what came after. The attacker went from first click to owning the account permanently in just over a minute. Everything that followed was methodical, scripted, and designed to survive incident response.

I am sharing this (with all identifying details removed) because the attack pattern is replicable, the tools are widely available, and the defenses most organizations rely on did not stop it. If you manage email accounts for a business, this is the playbook being used against you right now.

The phishing click: 12:31 PM

A VP of Operations received a phishing email and clicked the link. The link went to an adversary-in-the-middle proxy (likely Evilginx or EvilProxy) that relayed the login page in real time. The VP entered their password, approved the MFA push on their real phone, and went back to work.

From the VP's perspective, nothing happened. They logged in. The page looked normal. There was no error message, no warning, no second prompt. The entire interaction took about 15 seconds.

From the attacker's perspective, they now had a fully authenticated session with a valid MFA claim. The identity provider rated the risk as "none." Zero conditional access policies triggered.

65 seconds: the rogue MFA device

This is the part that changes everything.

Exactly 65 seconds after the initial sign-in, the attacker registered a new phone as a Microsoft Authenticator device on the VP's account. The enrollment took 18 seconds from start to finish. A pre-staged Android phone, Authenticator app already installed, QR code scanned the instant the session was live.

Why does this matter? Because a stolen session cookie expires. A registered MFA device does not. The attacker now had permanent, independent authentication capability: the VP's password (captured during phishing) plus their own MFA device. Session revocation, cookie clearing, even forcing a password reset would not lock them out as long as that device remained registered.

The indicators that this device was purpose-built were clear in hindsight:

• Device ID was all zeros (not enrolled in the organization's device management)
• Android Authenticator on a Samsung, while every legitimate device was an iPhone
• Push notification type 4 (Android FCM) vs type 2 (Apple APNS) on all real devices
• The device was never used for anything except this account

None of these indicators triggered an automated alert.

The reconnaissance: 3 hours of browsing

Before starting the automated exfiltration, the attacker spent 3 hours manually exploring the VP's accessible applications from their laptop browser. They opened SharePoint, Box, Outlook, Teams, Salesforce, and the organization's internal portal. They browsed the full application catalog. They checked dashboards, contacts, work orders, and reports.

They also checked their own sign-in history 11 times in the first hour. Counter-surveillance. They were watching to see if the security team was watching them.

One detail stood out: the attacker visited the "Change Password" page in Salesforce but left after 10 seconds without submitting the form. They had a stolen session cookie, not the actual password. Salesforce requires the current password to change it. This was the one wall they hit.

The exfiltration: 300,000+ files in 28 hours

At 7:08 PM, the automated scripts began. Two Python scripts ran in parallel from a Swiss bulletproof VPS:

Script 1 (cloud storage):Enumerated every shared folder accessible to the VP's account, recursively walked the entire folder tree, and downloaded every file. 232,000+ unique files. Approximately 1.15 TB. The script ran for 28 hours straight, refreshing its authentication token every 60 minutes.

Script 2 (SharePoint): Used the search API to enumerate every site collection, then systematically downloaded files from 394 sites. 69,000+ files. Average speed: 6,600 files per hour, peaking at 10,850 per hour. The gap between file accesses averaged 0.54 seconds.

Combined: approximately 301,000 unique files totaling an estimated 1.2 to 1.3 TB.

The file names included wire transfer instructions, bank reconciliation documents, escrow procedures, payroll records, tax documents, contracts, legal filings, firewall configurations, and password guides.

The extortion: day 7

After 6 days of silence, the attacker returned. They authenticated again using the stolen password and their rogue MFA device (proving session revocation alone was insufficient). Then they did something brazen: they sent 3 extortion emails to executives from the VP's own email account.

The subject line demanded contact within 72 hours. The emails were sent from a trusted internal address to a list of senior leaders. Most were delivered successfully. One was caught by the spam filter.

This is double extortion: steal the data first, then use the victim's own infrastructure to deliver the threat. The emails had maximum credibility because they came from a real VP's real account.

The response: 64 seconds to containment

The SOC locked the account within 64 seconds of the first remediation action. Refresh tokens revoked. The rogue Samsung device removed. All MFA methods wiped. The account flagged as compromised in identity protection.

But the attacker had maintained access for 6 days, 22 hours, and 50 minutes before anyone noticed.

And containment was not complete. The identity provider revocation only prevents new sign-ins via SSO. It does not reach into downstream SaaS applications to kill existing sessions. The attacker's Salesforce session survived for 3 more hours after containment. During that time, they installed the Salesforce mobile app, registered a push notification device, and downloaded 7 more files.

This is a critical gap in incident response that most organizations do not account for: SAML and OIDC federated sessions are independent of the identity provider. Revoking tokens at the IdP does not invalidate sessions in downstream apps. Each app must be revoked individually.

What this means for your organization

Cordial Spider did not use a zero-day exploit. They did not deploy malware. They did not need to bypass a firewall or exploit a vulnerability. They used a phishing link, a pre-staged Android phone, and a Python script.

The defenses that failed:

• MFA did not prevent the compromise. The AitM proxy relayed the real MFA push in real time. The user approved it because it looked legitimate.
• Conditional accessdid not flag the sign-in. The risk was rated "none" despite the sign-in coming from a different device, different OS, and different IP than the user's normal pattern.
• Session limits slowed the attacker but did not stop them. When the 4-hour session expired, they re-authenticated using their rogue MFA device.
• Token revocation did not reach federated SaaS apps. Salesforce and Box sessions survived independently.

The defenses that would have helped:

• MFA device enrollment alerts. If adding a new Authenticator device triggered an immediate notification to the user and IT, the rogue Samsung would have been caught in seconds instead of days.
• Continuous email configuration monitoring. The attacker accessed Outlook and could have set up forwarding rules or delegates for long-term persistence. Detecting these configuration changes in real time prevents the silent surveillance phase.
• Impossible travel detection. The VP was logged in from their home IP on MacOS. Three minutes later, a sign-in appeared from a different IP on Windows. That should trigger an immediate alert.
• Federated session revocation playbooks. When an account is compromised, every downstream SaaS app with an active session must be revoked individually, not just the identity provider.

The takeaway

The gap between "user clicks phishing link" and "attacker has permanent access" is now measured in seconds, not hours. MFA alone is not enough. Session revocation alone is not enough. Traditional email security tools that only scan content are looking in the wrong place.

The attacks that cause the most damage are the ones that live in your account settings: forwarding rules, delegates, OAuth apps, registered devices. They are invisible to spam filters and antivirus. They survive password resets. And they give attackers a persistent, silent window into everything you send and receive.

That is exactly what InboxWatch checks for.