A PayPal Invoice for Apple, Paid to a Third Brand

One mailbox at a municipal government building-services department received an invoice for $1,040.02. The subject line read "Invoice from Transaction Receipt." The body carried a PayPal logo, PayPal's real corporate street address in San Jose, and the printed claim that the transaction had been processed by PayPal, Inc. The transaction summary directly beneath it named Apple Inc. as the merchant. The "Pay Now" button pointed at neither company. And the one party whose identity actually passed authentication appeared nowhere in the story a reader would assemble from the layout.

Nothing in this message was spoofed. No lookalike domain, no forged header, no broken signature. That is exactly why it is worth a teardown.

Three Brand Claims and a Fourth Sender

The visible design work leaned on brands a recipient would recognize instantly. The header logo and the processor line said PayPal. The address block matched PayPal's genuine headquarters. The itemized section was titled as a transaction summary with Apple Inc., positioning a consumer technology purchase as the thing being billed. A footer logo then introduced a third brand, a merchant payment portal, and the payment call to action linked to that portal's customer payment page.

The actual sender was a fourth name: hello@payanywhere[.]com, a real payment-processing brand and a corporate sibling of the portal in the footer. Sender and payment destination are therefore consistent with each other. It is the two brands doing all the visual persuasion, the ones a busy accounts-payable reader actually registers, that have no relationship to either.

That is the whole trick, and it is cheaper than any kit. The attacker did not build a phishing page. They filled in the fields of a real invoicing product.

The Platform Signed It Because the Platform Sent It

Authentication was not merely passing, it was immaculate. SPF passed from an Amazon Simple Email Service sender in the platform's own outbound range, 54[.]240[.]126[.]216, resolving to a126-216[.]smtp-out[.]amazonses[.]com. DKIM passed twice, once with a signing domain matching the sending brand and once with the mail service's own domain. DMARC passed under a published policy of reject, with subdomain reject and full enforcement. Composite authentication scored at the maximum, and the ARC chain validated across every hop into Microsoft's protection frontends.

Every one of those results is correct. The platform really did send this message, under its own domain, from its own infrastructure, signed with its own keys. Alignment policy defined in RFC 7489 answers a narrow question about whether a domain authorized a message, and here the answer is an honest yes. What it does not answer is whether the merchant account that generated the invoice belongs to a real merchant. Domain reputation was borrowed rather than stolen.

Two Attachments, One Uploaded Logo

The message arrived with an invoice PDF just under 58 KB and a separate merchant logo image of roughly 109 KB. Both scanned clean, because both genuinely were clean: no macro, no embedded object, no script behavior to detect.

The logo file is the interesting artifact. Merchant logo upload is a standard feature of invoicing platforms, intended so a contractor can put its own mark on a bill. Used adversarially, it is how a well-known payment brand's mark ends up rendered inside mail that a different company authenticated. The attacker's whole technical investment was an account signup and an image upload, and none of it is blockable without blocking a legitimate processor that thousands of small businesses depend on.

The Arithmetic Does Not Close

Fabricated financial documents tend to fail on internal consistency, and this one failed twice.

The itemized section listed a single express item at $1,005.37, then stated a subtotal of $1,024.65 directly beneath it, roughly nineteen dollars higher than the only line item said to compose it. Tax of $15.37 brought that to the $1,040.02 total, so the total reconciles with the subtotal while the subtotal reconciles with nothing. A real invoicing engine does not produce that gap. A human editing template fields does.

The second tell sat in the contact details: two support phone numbers in the same document, written in two different formats, one parenthesized with a country code and one a bare ten-digit string. The payment deadline was set to the day of delivery, leaving no interval to check anything. Same-day urgency on a mid-four-figure amount is deliberate calibration. The 2024 Verizon Data Breach Investigations Report puts the median business email compromise transaction near $50,000, against roughly $2.9 billion in reported losses in the 2023 FBI IC3 Internet Crime Report. A charge of $1,040.02 is sized to fall below the threshold where a second signature is required.

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

A Clean Link to a Real Payment Page

The payment button resolved to a customer payment endpoint on the portal brand from the footer, carrying a long signed token encoding merchant, account, user, and customer identifiers. Automated link scanning returned a verdict of clean.

That verdict is accurate too. This is not credential harvesting and there is no fake login page. It is a functioning portal owned by a licensed processor, and money entered into it would move successfully. It would simply move to the wrong merchant. URL reputation, sandboxing, and link rewriting have nothing to fire on, because no stage of the chain is technically malicious. The malice lives in the mismatch between who the document says is billing and who the payment rail says gets paid, the layer MITRE ATT&CK tracks separately as impersonation and that CISA phishing guidance insists still requires content review on authenticated mail.

Content Scoring Beat Header Validation

Microsoft's own antispam engine was not persuaded by the flawless headers. Despite the full authentication pass it scored the message as spam-confidence bulk content rather than trusted mail, an internal disagreement between the identity layer and the content layer of a single mail platform.

Detection on our side came from behavior rather than reputation. Themis, the IRONSCALES Adaptive AI analyst, evaluates whether a first-time payment-request sender fits the recipient's correspondence history and whether the brands asserted in a message agree with the destination of its links. Automated detection quarantined the message roughly seven seconds after delivery and the incident closed automatically as phishing, one mailbox affected. The recipient, whose job is issuing building permits rather than adjudicating invoice authenticity, was never asked to make the call.

What To Take From This Case

Verify merchants, not messages. A payment platform can authenticate perfectly for a customer it has never met, so the useful control is a rule that any first-time payment instruction gets confirmed against a known vendor contact through a channel the email did not supply. Then add a brand-consistency check to invoice review: if the logo names one company, the merchant line names another, and the payment domain names a third, that disagreement is the finding, and no amount of header cleanliness overrides it. Business email compromise protection has to weigh relationship history and document coherence, because here there was no bad domain to block, no bad file to quarantine, and no bad link to rewrite.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

When a document names three brands and the money goes to a fourth, believe the payment link. Check back tomorrow for the next teardown.