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

What happened

Recently, 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 just the initial compromise. It was the speed, automation, and operational discipline of what came after. The attacker went from first click to permanent account ownership in just over a minute. They used encrypted DNS to blind the firewall. They checked their own sign-in history repeatedly to see if anyone was watching. They scripted the exfiltration from a Swiss VPS. And when it was over, they sent 94 extortion emails from the victim's own account.

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 phone call: 12:24 PM

This attack did not start with a phishing email. It started with a phone call.

The attacker called a VP of Operations directly and, while speaking to him in real time, directed him to open a Google Docs link. The document either hosted or redirected to an adversary-in-the-middle proxy (likely Evilginx or EvilProxy) that relayed the Microsoft login page in real time. The VP entered his password and approved the MFA push on his real phone, just as the caller instructed.

From the VP's perspective, nothing happened. He opened a document, signed in, and went back to work. He browsed the news, checked Workday, looked at cars on Bring a Trailer. No error message. No warning. No second prompt. The entire interaction was over in 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. Seven authentication sessions fired in 23 seconds, and every one succeeded.

The blind spot: encrypted DNS

Before directing the VP to the lure document, the attacker had one more advantage. The VP's laptop was configured to use Google's encrypted DNS service (DNS-over-TLS and DNS-over-HTTPS simultaneously). This meant every domain the VP visited, including the Google Docs lure, was resolved through an encrypted channel that the corporate firewall could not inspect.

The firewall saw a TLS connection to docs.google.com. It logged the SNI hostname. But the full URL path (the document ID that would identify the specific lure page) was encrypted inside TLS. And the DNS query that resolved it never touched corporate DNS servers. The attacker's lure URL was effectively invisible to every network security tool in the environment.

During the forensic investigation, we searched every available log source: NGFW URL filtering, DNS security logs, Defender for Cloud Apps, Cortex XDR, Sentinel. The Google Docs URL was unrecoverable from network data. The only place it existed was in the browser history on the VP's laptop.

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 the AitM relay) 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 burner, while every legitimate device was an iPhone
• Push notification type 4 (Android FCM) vs type 2 (Apple APNS) on all real devices
• The MFA token was updated 8 times over 6 days, confirming the burner phone was actively receiving and approving challenges throughout the compromise

None of these indicators triggered an automated alert.

The reconnaissance: 2 hours 41 minutes of browsing

Before starting the automated exfiltration, the attacker spent nearly 3 hours manually exploring the VP's accessible applications. Within 2 minutes of initial access, they had logged into SharePoint, searched it twice, and enumerated the application catalog: OfficeHome, Office 365 Shell, My Apps, Salesforce SSO. Within 7 minutes, they were reading the VP's email. Within 15 minutes, they were in Teams. Within 2 hours, they had triggered a new device alert in Box.

They also accessed the My Signins portal and My Profile page repeatedly during the compromise. On Day 7, this escalated to a 64-event burst against the My Signins portal in 11 minutes from a single IP, likely checking what authentication methods were registered and whether the security team had flagged the account.

Meanwhile, the VP continued his normal workday. He browsed news sites, accessed Workday HR, checked Power BI dashboards, and opened Wrike project management. His session and the attacker's session ran in parallel, from different devices, different operating systems, and different cities. He had no indication his account was compromised.

The missed alert: 4 hours after compromise

At 4:38 PM, just 4 hours and 7 minutes after the initial compromise, Defender for Cloud Apps generated an incident: "Mass download involving one user." The incident contained 4 alerts spanning SharePoint, Box, and Microsoft 365, correctly categorized as "Collection." The policy that fired was "Unusual file download (by user)."

The system detected the anomaly on Day 1. It categorized it correctly. It grouped 4 related alerts into a single incident. And then the incident was classified as "Benign Positive" and resolved during standard triage.

Why? The incident was rated Low severity by Cloud Apps. In the context of a busy SOC triage queue, a Low severity download alert looks identical to routine user activity. The alert did not include the source IP's geographic context (the attacker was in Miami; the VP was in Utah). It did not surface the concurrent new MFA device registration. It did not cross-reference the anomalous device fingerprint (Windows 10 vs. the VP's known macOS environment).

If any of that context had been automatically enriched into the alert, containment could have happened on Day 1, before the bulk exfiltration. The 233,000-file Box download did not begin until the following afternoon, 22.5 hours after this alert was dismissed.

The exfiltration: 300,000+ files in under 5 hours

Within 2 hours and 41 minutes of initial access, the attacker pivoted the stolen session token to a Private Layer VPS in Switzerland. The user agent changed from Chrome to python-requests/2.28.1. The automation had begun.

Two Python scripts ran in parallel from the Swiss 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. 233,000+ unique files. Approximately 1.15 TB. The script ran for 4.5 hours, refreshing its authentication token as needed.

Script 2 (SharePoint): Used the search API to enumerate every site collection, then systematically downloaded files. 69,000+ files. 6,547 download actions in a single 25-minute burst, peaking at 10,850 files 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). This time, they went loud.

At 10:54 AM, 24 minutes before the identity provider finally generated an actionable alert, the attacker sent 94 extortion emails from the VP's own account. The subject line: a data breach notification demanding contact within 72 hours. The emails went to 93 unique employees, including senior leadership.

Of the 94 emails, 85 were delivered directly to recipients' inboxes. 7 were blocked by Exchange transport rules. 2 were junked. The emails were sent as intra-org mail from a trusted internal address, which is why the vast majority bypassed spam filters entirely.

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 to real colleagues.

The response: 64 seconds to containment

The SOC responded within 3 minutes of the Entra ID Protection alert and locked the account within 64 seconds of the first remediation action. Four rounds of token revocations. The rogue Samsung device removed. All MFA methods wiped. FIDO2 key deleted. Account disabled via AD Connect.

But the attacker had maintained access for 6 days, 22 hours, and 50 minutes before anyone noticed. The Day 1 alert was there. It was correct. It was dismissed.

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.

The investigation: what logs did not capture

During the forensic investigation, we discovered that the VP's laptop had no endpoint detection agent. No Microsoft Defender for Endpoint. No Cortex XDR endpoint agent. The only visibility into the device was through the Palo Alto firewall's network logs, which could see connection destinations but not browser activity, process execution, or file system events.

Combined with the attacker's use of encrypted DNS (bypassing corporate DNS inspection) and TLS encryption (hiding URL paths from the firewall), this created a complete blind spot. The initial access URL, the Google Docs lure that started everything, was unrecoverable from any network or cloud log source. It could only be recovered from the browser history on the physical device.

We also identified three indicators of compromise in the initial report that turned out to be false positives after deeper analysis: an internal IP flagged as lateral movement was actually the VPN portal (1,096 devices connect to it daily), and two connections flagged as geo-anomalous (one routed to Hong Kong, one to Germany) were normal Chrome and Microsoft telemetry endpoints that hundreds of fleet devices connected to simultaneously. Thorough validation of IOCs matters as much as finding them.

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 phone call, a Google Docs 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 a caller was walking him through it.
• Email security never saw the lure. The attack started with a phone call. There was no phishing email to scan, no URL to detonate, no attachment to sandbox.
• Conditional accessdid not flag the sign-in. The risk was rated "none" despite the sign-in coming from a different device (Windows vs. macOS), different city (Miami vs. Utah), and different ISP (T-Mobile cellular vs. corporate).
• The Day 1 Cloud Apps alert correctly identified the anomaly but was classified as Benign Positive because it lacked geographic, device, and MFA context enrichment. The bulk exfiltration happened the next day.
• Network inspection was blinded by encrypted DNS and TLS. The firewall saw docs.google.com but could not see the document path. The initial access URL was forensically unrecoverable from network logs.
• 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. The device had a zeroed Device ID, a mismatched OS, and a mismatched push notification type. All of these are detectable at registration time.
• Alert enrichment with geographic and device context. The Day 1 Cloud Apps alert was correct but lacked the context to distinguish it from routine activity. Automated enrichment (source IP geolocation vs. user baseline, recent MFA device changes, device fingerprint comparison) would have escalated it immediately.
• Endpoint agent coverage.The VP's laptop had no endpoint detection agent. If it had, browser activity, process execution, and the Google Docs URL would have been logged. The investigation would not have hit a dead end at the TLS boundary.
• 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 Utah on macOS. Minutes later, a sign-in appeared from Miami 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 receives a phone call" and "attacker has permanent access" is now measured in seconds, not hours. MFA alone is not enough. Email scanning alone is not enough. Network inspection alone is not enough. Even a correctly firing alert is not enough if it lacks the context to be actioned.

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.