The One PayPal Link That Dropped to Plain HTTP

A PayPal invoice landed in the inboxes of a Fortune 500 automotive manufacturer, and by every technical measure it was the real thing. The payment links pointed at genuine paypal.com invoice infrastructure. SPF passed. DKIM passed, aligned to the sending domain. DMARC passed. Even the ARC chain, the seal that vouches for a message as it hops through forwarders, validated cleanly across several Google and Microsoft relay points. A gateway inspecting the envelope, the signatures, and the destination of every link would have found nothing to hold, because there was nothing forged to find. The fraud lived in the shape of the message, not its credentials.

A real invoice, weaponized as the payload

Most invoice fraud fakes something. It spoofs a domain, attaches a booby-trapped PDF, or hides wire instructions in the body. This one faked nothing. The lure was an authentic PayPal invoice, and the payment mechanism was PayPal itself. Repeated through the message were a dozen View and Pay Invoice buttons, each resolving to a legitimate paypal.com invoice URL. There was no attacker-registered domain to blocklist, no malicious attachment to detonate, and no credential-harvesting page pretending to be a login screen.

That is what makes genuine-infrastructure abuse so hard to stop. When the payment conduit is the real brand's own platform, every reputation and link-scanning check that a filter leans on comes back green. The attacker is not impersonating PayPal from the outside. They are using PayPal's own invoicing to issue a real, payable demand, and betting that a busy accounts-payable inbox will treat a familiar, authenticated request as routine. That is exactly the assumption disciplined business email compromise protection is built to break, by treating every unsolicited payment demand as unverified until confirmed off-channel.

The forwarding headers told on the sender

The first structural crack was in the routing. The Return-Path showed SRS rewriting through a Microsoft-hosted tenant, and a Resent-From header pointed at a separate third-party forwarding domain. The Sender Rewriting Scheme is legitimate. It exists so that when a message is forwarded, the rewritten return path still passes SPF at the next hop. But it also lets a forwarded message carry clean authentication into places the original sender never intended.

Here that machinery was doing something no real invoice does. The same invoice had been fanned out through those mangled forwarding headers to a broad, unrelated group of recipients spread across several different companies at once. A genuine one-to-one invoice goes to the party that owes the money. This one was sprayed at a grab-bag of businesses that had no commercial relationship with each other, with several unrelated organizations copied on the same thread. Whether the sending domain, a real and established small business, was compromised outright or caught in an abused auto-forwarding chain, the distribution pattern was the fingerprint. No legitimate billing workflow addresses five unconnected companies with one invoice.

One link that dropped its guard

The second, more damning anomaly was buried among the payment buttons. Of the roughly dozen View and Pay Invoice links in the message, all but one used HTTPS, the encrypted protocol that PayPal serves everything over. Exactly one, styled identically to the rest, quietly dropped to plaintext HTTP.

That single downgrade is not something the real service produces. PayPal does not serve one payment button over unencrypted HTTP while serving the eleven around it over HTTPS. A protocol downgrade on a lone link, hidden in a sea of clean and identical-looking siblings, is a deliberate seam. It is the kind of detail engineered to be visually invisible, since the button text and styling match perfectly, and to survive inspection that only scrutinizes encrypted traffic or only checks the destination domain rather than the scheme in front of it. The link was the whole point of the message, and it was the one place the attacker had to touch, so it was the one place the seam showed.

Why authentication had nothing to say

It is worth being precise about why none of the usual defenses fired. SPF, DKIM, DMARC, and ARC answer a narrow question: did this message come from where it claims to, and was it altered in transit? The honest answer was yes and no. Those checks say nothing about whether the request inside is legitimate or whether one invoice belongs in five unrelated inboxes.

Link reputation was equally quiet. Every URL pointed at paypal.com, one of the most trusted domains on the internet, so there was no known-bad host to match and no lookalike to catch. A legacy secure email gateway, which resolves trust to a stack of pass or fail verdicts on sender and destination, clears a message like this without hesitation. For a sense of how wide that blind spot runs against genuine-infrastructure abuse, our email security gap calculator is a useful gut check.

How the pattern surfaced

The case did not surface on any single indicator, because there was no single bad indicator to surface on. It surfaced on the relationships between the signals. The platform's Adaptive AI modeled the message the way a suspicious human would, asking questions a pass or fail filter never asks. Why is one invoice being fanned out through mangled forwarding headers to five companies that have nothing to do with one another? Why does one of a dozen identical-purpose payment links use plaintext HTTP when the service it points at serves everything over HTTPS? Why does the sender relationship look like a broadcast when the content claims to be a specific bill?

Individually, each observation is defensible. Forwarding happens. Links vary. Stacked together on a fully authenticated PayPal invoice, they form a shape no legitimate billing message makes. That pattern-level read is what flagged and pulled the message across all five affected mailboxes before anyone in finance clicked the odd button. The 2024 Verizon Data Breach Investigations Report names pretexting, the category that covers business email compromise, as the top social-engineering type of the year, puts the median BEC transaction at roughly fifty thousand dollars, and finds the human element present in sixty-eight percent of breaches. Attacks that weaponize a trusted brand's own infrastructure are cheap to send and profitable to land, which is why the defense has to move past the credentials and read the whole story.

Indicators of Compromise

MITRE ATT&CK Mapping

For a broader baseline on interrupting an attack before the click, CISA's phishing guidance on stopping the attack cycle is a solid reference, and the 2024 Verizon Data Breach Investigations Report documents how often the way in is a person, not a broken protocol.

See You Next Friday

Clean authentication is a starting point, never a verdict. When a real PayPal invoice arrives with every signature aligned, every link pointing at the genuine brand, and a spotless ARC chain, the credentials have told you the truth about the wrong thing. The story is in the structure: one bill sprayed at five strangers, and one payment button that quietly dropped its encryption while a dozen others kept it. Read the whole message, verify every payment demand through a channel outside email, and remember that the seam an attacker cannot avoid touching is often the only place they slip.