The PayPal Phish With No Link and No Brand Name

The subject line read "Invoice update transaction reference." It names no brand at all. The body underneath it was a PayPal billing notice, except that the word PayPal never appeared in it. Not once, and not in any form a filter could read.

Every instance of the brand was typed in leetspeak. The masthead and sign-off rendered it as P@YP@L, at-signs standing in for both A characters. Elsewhere it appeared as P@Y_P@L and P@_yP@l, an underscore wedged into the middle, and in one place as P@YP@I, with a capital I doing the work of the L. A keyword rule hunting for "paypal" in any casing has nothing to grab, because the string is not in the message.

There was also nothing to click. Every clickable URL in the delivered mail belonged to the inline mail-security gateway in front of the recipient's mailbox. The only action on offer was a phone number, set at roughly double the surrounding text size, beneath the instruction "Kindly c0ntact us at." The recipient, an accountant in the finance function at a residential remodeling contractor, was told to call it to stop a $299.99 charge.

The Brand Never Appears in Readable Characters

The substitution is not confined to the brand name. It runs through the whole message: gr@teful, patr0nage, Inv0ice, unauth0rized @ccess, re_fund, S@les Tax, and a fake support desk billed as Cust0mer Servics. The seams show in the writing too, with a toll-free label truncated to t0ll-fre and an instruction to "cal us" spelled with one L.

The typographic detail is the part worth studying. In the body prose, each substituted glyph is set a few pixels smaller than the letters around it: in gr@teful the letters sit at 19 pixels and the at-sign at 14, and in patr0nage the letters sit at 19 and the zero at 15. An at-sign is taller and heavier than the a it replaces, and a zero wider than an o, so shrinking each pulls it optically back toward the letter it stands in for. The word reads normally to anyone skimming a billing notice, while a parser reads the literal characters it was given. That is the point of obfuscating content rather than hiding it.

That holds in the prose and only there. In the branded masthead the sizing is erratic, with one at-sign set larger than the letter beside it, so this brand impersonation was assembled by hand, not by a rule.

No URL in the Message Belonged to the Attacker

This is the structural fact the case turns on. Not low-reputation links, and not a lookalike domain. There were no attacker links. All five extracted URLs were the receiving gateway's own reporting controls, and the only other clickable element was a mailto pointing back at the sending address inside the gateway's warning banner. The one-pixel white-on-white preview text at the top of the HTML and the lone attachment, an inlined banner graphic, are the gateway's too.

Strip that out and the attacker's contribution is text plus ten digits. That makes it a callback attack, tracked by MITRE as spearphishing voice and known to defenders as vishing. The fraud happens live on the line, where an operator handles objections and walks the caller toward remote access, a card capture framed as cancelling the charge, or a refund flow run inside the victim's own banking session. The 2024 Verizon Data Breach Investigations Report puts a human element in 68 percent of breaches. A payload-free message reduces the attack surface to that element and nothing else.

Fanned Out Through Twenty Generated Consumer Groups

The recipient was not in the To header. Twenty addresses were, all at a consumer Microsoft Outlook groups domain, each a generated first name plus surname plus digits inside Microsoft's consumer template tenant. They read as attacker-created accounts rather than real subscribers, and they exist to fan the message out. Group expansion then did the delivery work, rewriting the envelope sender on the way, so at the final hop SPF passed cleanly against the consumer groups domain while the From header still read a regional government education authority's Workspace domain. DMARC came back as a best-guess pass, which is what a receiver does when the sending domain publishes no DMARC record to evaluate against. That sending account is a bystander, so its address and apex domain stay out of this post.

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

The Signature Broke After the Defender Touched It

DKIM passed at the gateway. One hop later, at the receiving provider, the same signature with the same selector and hash value came back neutral, body hash did not verify. Nothing between those two hops was an attacker.

The gateway stamped a header recording that it had sanitized the HTML, then injected its caution banner and the inlined graphic, which changed the bytes the signature covered. The ARC chain preserved the earlier valid pass, so the receiver could still see the signature had been good beforehand. Read without that context, a late body-hash failure looks like tampering and aims the investigation at the wrong party.

Both Filters Graded It Spam and Sent It to Junk

The provider set its spam flag while leaving its phishing flag at zero. The inline gateway scored the message a 4 on its phishing-confidence scale and a 5 and a 6 on its two spam scales, captioned its banner "Spam Content," and sent the mail to junk without quarantining it. Junked, not held, so it stayed reachable.

Both undershoots are explainable rather than negligent, which is the uncomfortable part. With no attacker URL to reputation-score and no brand string to match, the signals that normally carry a phishing verdict were absent by construction.

No human reported it. The case reached the SOC through automated detection and resolved as phishing. Themis, the IRONSCALES Adaptive AI analyst, returned 90 confidence and labelled it a vishing attack, weighing content wording and structure, community reputation on comparable incidents, and a high-risk first-time sender writing under a personal alias unrelated to its own opaque mailbox address. Roughly three hours later a second copy reached the same mailbox under a reworded subject, "Invoice update invoice information." One mailbox, two attempts, no mitigation recorded against either.

What Has to Change in the Control Stack

Three moves come out of this case. First, stop treating brand-keyword matching as brand-impersonation detection. Normalize the text before comparing it, folding at-signs to a, zeros to o and capital I to l, then compare fuzzily, and treat per-character font-size variance inside one word as a signal rather than formatting noise. Second, score identity and behavior when there is no payload, because a first-time sender, a mismatched alias, an unauthorized charge and one oversized phone number are all evaluable with nothing to scan. That is the argument for augmenting the gateway you already run rather than accepting its spam-versus-phishing call as final. Third, read a late body-hash failure against your own rewriting infrastructure before calling it tampering.

Then give people one rule, consistent with CISA phishing guidance and the behavior NIST describes for this class of attack: never dial a number inside an unsolicited charge notice. A callback lure only pays if somebody picks up.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

The two controls this message was built to defeat, link analysis and brand-keyword matching, both worked as designed and both returned nothing, because there was nothing of that shape to find. Everything that mattered was in the words and the pixel sizes. Check back tomorrow.