The PayPal Email That Wanted a Phone Call, Not a Click

The email subject read: "Creation of your PayPal Manager user account."

For a senior HR professional at a professional services firm, that subject line lands in a specific way. No one in HR authorized a new PayPal Manager account. Something is off. So they open it.

The body looks roughly like a PayPal system notice. There is a vendor section, a password block, some account details. And then, at the bottom, a single action item: call 805-259-2049 to sort it out.

No reset link. No "verify your account" button. Just a phone number.

That is the whole attack.

The Infrastructure That Lent It Credibility

Before the email reached anyone's inbox, it traveled a path that looked legitimate at every checkpoint a gateway would inspect.

The message originated from mx5.slc.paypal.com (173.0.84.230), a real PayPal mail server. Mimecast received it, verified that PayPal's DKIM signature was valid, that SPF passed for the sending IP, and that DMARC showed pass under PayPal's reject policy. Mimecast did what it was designed to do: it rewrapped the links inside URL-protection redirectors at url[.]us[.]m[.]mimecastprotect[.]com and marked them clean. It then relayed the message toward Microsoft 365.

At the final Microsoft 365 inbound hop, the authentication picture changed. SPF showed softfail because the Mimecast relay IP (170.10.128.131) was not listed as a permitted sender in PayPal's SPF record. DKIM signature verification failed at this hop. DMARC failed under a reject policy. The compauth result was none, reason 451.

The email still reached the inbox. The gateway's SCL score was 1, well below any quarantine threshold, because the link scan had already returned clean verdicts on the Mimecast-protected URLs. At the link level, there was nothing malicious to find. The Mimecast wrapper pointed back to manager.paypal.com, a real PayPal host, and the scanner treated that as exculpatory.

See Your Risk: Calculate how many threats your SEG is missing

The Verizon DBIR 2026 puts phishing at 16% of initial access vectors across all breaches, with callback and telephone-oriented delivery accounting for roughly 5% of the gateway-categorized mix. That share has climbed steadily as defenders have improved link-scanning fidelity. When link scanning gets better, attackers remove the link.

Behind the Curtain

The email copy itself is the tell that no relay reputation check would catch.

The body contains concatenated strings that appear to be template rendering gone wrong: "An administrator Your order details ready Call 8052592049 created an user account." The phrase "created an user account" appears twice, verbatim. There is a nonsensical vendor/password block that does not correspond to any real PayPal account-management workflow. The attacker contact email embedded in the header chain, m1n8ybm@haibabon[.]com, has no relationship to PayPal's domain.

What the email does not contain: a credential-harvesting page link, a malicious attachment, a QR code, or any redirect chain to a fraud site. Every visible URL points to legitimate PayPal infrastructure. The attack surface is a phone number. That is intentional.

TOAD attacks, documented under MITRE ATT&CK T1566.002 for phishing link delivery and T1598 for phishing for information, sidestep every artifact-based detection control. There is no payload to sandbox, no URL to score, no attachment to detonate. The weapon is a human voice. Once the victim calls, a social engineering operator handles the rest: walk them through "verifying" their account, capture credentials, possibly authorize a fraudulent payment or account transfer. The FBI IC3 2024 report documents billions in losses annually from phone-enabled fraud chains that begin with exactly this kind of email lure.

The Microsoft Digital Defense Report 2024 identifies social engineering at scale as a persistent challenge precisely because the technical signals are intentionally absent. When the gateway sees clean links and a known sender domain, it has nothing left to block.

When Mimecast's Clean Verdict Was Not Enough

The detection did not come from link reputation. It came from reading the email.

Themis, the AI virtual SOC analyst built into the IRONSCALES platform, flagged the message on content and behavioral signals: language patterns inconsistent with genuine PayPal transactional email, the absence of any account-management action other than a phone call, and community correlation matching a known TOAD campaign signature. The confidence score reached 88%, with a credential theft label. The incident was automatically resolved as phishing and the message quarantined before any callback occurred.

The MITRE ATT&CK T1656 impersonation technique is the frame here. The attacker did not need to compromise PayPal. They needed a message that looked close enough to PayPal to motivate a phone call. The real PayPal infrastructure lent surface credibility. The garbled copy and the callback-only CTA told the story to any system trained to read it.

Security awareness training closes the human side of this gap. Employees who know that legitimate financial institutions never ask you to call a number from an email, never present a password block in a notification, and never use "created an user account" in automated copy are harder targets. But training alone does not scale to every variant. The phone number changes. The ESP shifts. The wrapper rotates.

The CISA guidance on recognizing and reporting phishing and the NIST definition of phishing both emphasize that reporting speed matters, that the email that looks wrong should go to the security team immediately, not into a mental folder labeled "probably fine."

What This Attack Teaches

TOAD attacks exploit the verification gap between what a gateway can scan and what a human caller will believe. The Mimecast URL wrapper in this case was not a failure of Mimecast's design. It was the attacker correctly predicting that clean link verdicts would reduce scrutiny on everything else. The broken authentication at the final hop (SPF softfail, DKIM fail, DMARC fail under reject) should have been a hard stop. Instead, a strong link-scan result outweighed it.

Three things are worth acting on: First, configure vishing-aware detection rules that treat "call this number" as a primary body-level risk signal, not a benign element. Second, ensure DMARC failures under reject policy generate alerts even when link scans return clean verdicts. Third, understand that the Verizon DBIR 2026 notes 62% of breaches involve the human element, and callback phishing is specifically engineered to make a human the final, exploitable hop.

The IBM Cost of a Data Breach 2024 report puts the average breach cost at $4.88 million. A phone call that should not have been made is often how the math starts. Stop the call before it happens.