Stripe Sent This Email. The Authentication Was Perfect. The Payment Button Was Not.

SPF passed. DKIM passed. DMARC passed. The email arrived from stripe[.]com, carried valid Amazon SES and Stripe cryptographic signatures, and included a legitimate X-Stripe-EID header. This was not a spoofed email pretending to be Stripe. This was Stripe's own infrastructure delivering a phishing attack.

The message was a Chinese-language failed payment notification for US$477.00, sent to a corporate recipient with no prior relationship to the sender. The subject, body, and branding were all consistent with a genuine Stripe dunning email. But the Reply-To address and the payment button both pointed somewhere Stripe has never operated: blockvision[.]org, a domain registered through GoDaddy, hosted behind Cloudflare, running Google Workspace for mail, and publishing a DMARC policy of p=none.

The attacker did not need to forge anything. Stripe's merchant-configurable fields (business name, Reply-To address, CTA destination) were sufficient to weaponize legitimate infrastructure.

Authentication Was Perfect, and That Was the Problem

The email originated from IP 54[.]240[.]76[.]202, an Amazon SES address authorized to send on behalf of stripe[.]com. The authentication results were textbook:

• SPF: Pass (Amazon SES IP authorized for stripe[.]com)
• DKIM: Pass (signatures from both stripe[.]com and amazonses[.]com verified)
• DMARC: Pass (header.from=stripe[.]com, full alignment)
• Composite authentication: Pass

These results were not falsified. They were accurate. The email genuinely originated from Stripe's sending infrastructure. Any secure email gateway that relies on authentication headers to make trust decisions would classify this message as legitimate transactional mail from a major payment platform. There is no authentication-based signal to detect because there is no authentication failure.

This is the structural problem with platform infrastructure abuse. The attacker does not compromise the platform. The attacker uses the platform as designed. The resulting emails are cryptographically indistinguishable from legitimate ones. According to the Microsoft Digital Defense Report 2024, attackers are increasingly leveraging trusted service infrastructure to bypass reputation and authentication defenses, a trend that renders domain-level trust models insufficient.

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

The Merchant Fields That Carried the Payload

Stripe payment notifications are largely templated. The layout, branding, tracking links, and footer all come from Stripe. But several fields are merchant-configurable: the business name, the Reply-To address, and the CTA button destination. Those three fields were the entire attack surface.

The business name was set to "blockvision pte ltd," which appeared in the From display name and the email body. The Reply-To was set to support@blockvision[.]org, meaning any recipient who replied to the failed payment notice would send their response directly to the attacker rather than to Stripe. The CTA button ("Update payment method" in Chinese) linked to hxxp://blockvision[.]org/?referer=failed_payment, an HTTP URL on the attacker's domain.

That HTTP protocol is a notable detail. Stripe's own links in the email used HTTPS. The tracking links routed through 58.email.stripe[.]com, all over encrypted connections. But the primary action button, the one element designed to capture the click, used plain HTTP. A platform that enforces HTTPS everywhere else would never serve its own payment update page over an unencrypted connection. This protocol mismatch is a behavioral signal that authentication cannot surface.

Blockvision[.]org: The Reply-To Destination

The attacker's domain, blockvision[.]org, was registered in June 2021 through GoDaddy, with an expiration date of June 2026. It resolved to Cloudflare IPs (104[.]26[.]4[.]104, 104[.]26[.]5[.]104, 172[.]67[.]74[.]211). Mail handling ran through Google Workspace (aspmx[.]l[.]google[.]com MX records). DNSSEC was not deployed. The domain's DMARC policy was set to p=none, meaning the owner explicitly chose not to enforce authentication failures on mail sent from this domain.

This infrastructure profile is deliberately unremarkable. Cloudflare, GoDaddy, Google Workspace, and a five-year-old domain. Nothing triggers a reputation flag. Nothing screams "attacker infrastructure." The domain age alone places it outside the fresh-registration heuristics that catch most throwaway phishing domains.

Zero Personalization in a Transactional Email

The email contained no recipient name, no invoice number, and no account reference. It simply announced that a $477.00 payment to "blockvision pte ltd" had failed and urged the recipient to update their payment method. For a genuine Stripe dunning notification, the absence of any customer-specific detail is unusual. Stripe's transactional emails typically reference the customer's name or the last four digits of the card on file.

This missing personalization is the second behavioral signal. Combined with a first-time sender relationship (this was the first time the recipient mailbox had received any email from this Stripe merchant account), the pattern resembles a spray campaign using spearphishing link delivery rather than a targeted notification about a real payment failure.

Where Behavioral Detection Found the Seam

Themis, the IRONSCALES Adaptive AI, identified this campaign through the convergence of behavioral anomalies that authentication could not surface. No single signal was conclusive. The first-time sender relationship alone is common for legitimate payment platforms. The Reply-To mismatch alone could be a misconfigured merchant account. The HTTP CTA alone could be a developer oversight.

Together, they formed a pattern: a fully authenticated email from a major payment platform, sent to a recipient with no prior relationship, carrying a Reply-To that diverted to a separate domain, with a primary CTA served over HTTP and stripped of all personalization. The business name and Reply-To domain matched each other but matched nothing in the recipient's communication history. That behavioral profile, not any failed authentication check, was the detection surface.

The masquerading technique here operates at the merchant account level rather than the email header level. The attacker did not forge the From address. The attacker configured a Stripe merchant identity that mimicked a legitimate business and let the platform's own infrastructure do the rest.

What Defenders Should Prioritize

Three patterns from this case that defenders can act on:

Evaluate Reply-To mismatches against the From domain. When the From address is stripe[.]com and the Reply-To is a separate domain, the email may be legitimate (merchants often set custom reply addresses), but the combination with other anomalies (first-time sender, no personalization) should elevate the risk score.

Flag HTTP links in emails from HTTPS-only platforms. Stripe, PayPal, and similar payment platforms serve all their pages over HTTPS. A CTA button linking to HTTP is an anomaly that automated defenses can detect without evaluating the destination domain's reputation.

Monitor for merchant account abuse across payment platforms. This attack used Stripe, but the same pattern works with any platform that allows merchants to configure sender names, reply addresses, and CTA destinations. The platform authenticates the infrastructure. It does not authenticate the merchant's intent.

---

Indicators of Compromise