A Refund Notice From the Wrong Industry

The display name promised a payment notification from a farm and ranch equipment brand. The envelope address behind it belonged to a hotel business. The only button in the message went to neither of them.

That three-way contradiction was the whole case. Nothing failed an authentication check and nothing was spoofed. The email reached mailboxes at an agricultural and ranch-equipment manufacturer wearing that manufacturer's own brand in the sender line, and every cryptographic control for validating a sender said the mail was exactly what it claimed to be.

A Subject Line Built From Payment Vocabulary

The subject read like a string assembled by a script rather than written by a person. Stripped of identifying fragments, it ran roughly: -Returned Funds Processing: Ppayment for [equipment brand] In Line. [EFT Batch No. (token) Under Review], plus a random suffix and a date fragment truncated here.

Two things stand out. The first is the typo. "Ppayment," with a doubled leading letter, is the artifact of a template copied, hand-edited, and never proofread, and no real accounts-payable platform generated this notice. The second is the vocabulary. Returned funds, EFT batch, under review. That is the register of a genuine electronic funds transfer notification, and it does something a fake invoice demand does not: it promises the recipient money rather than asking for it. A refund pretext lowers scrutiny because the reader believes they are the beneficiary.

The display name completed the illusion by pairing the recipient's own company with a plausible system label, an ePayment notifier. In a mail client that shows the friendly name and hides the address, this reads as the manufacturer's own payment system writing to its own staff.

The Address Behind the Name Was in the Wrong Business Entirely

The address behind that display name was a generic information mailbox on a hospitality-sector domain, whose apex domain was registered in 2016 to a Sri Lanka-based IT reseller and has nothing to do with farm equipment, ranch gates, or electronic funds transfers in North America.

This is where the case stops being routine impersonation. The message passed the Sender Policy Framework and carried a valid DomainKeys Identified Mail signature for that hospitality domain, delivered through a transactional email service the domain legitimately uses. The signature verified and the sending IP was authorized, which rules out spoofing outright: forging this domain would have broken both checks.

What remains is that the mail was genuinely sent by something the domain authorizes. The conservative reading is a hijacked or abused legitimate domain rather than attacker-registered infrastructure: a taken-over mailbox, a stolen outbound API credential, or a mail platform tenant someone else is now driving all produce identical header evidence. That likely puts account takeover on a third party upstream of this message, where no amount of authentication hardening at the receiving end would have changed the verdict.

Domain-based Message Authentication, Reporting and Conformance resolved to a best-guess pass with no action to take, meaning the domain publishes no policy of its own and the receiving side inferred alignment from the passing checks described in RFC 7489. The ARC chain validated too. Four green lights, all correct, all describing a message no human at either company authorized.

The Only Link Pointed at a Content Delivery Network

The message carried one actionable call to action, a View Document button. It resolved to an AWS CloudFront subdomain: a long, random-looking label under the provider's own hostname.

Compare that against the two organizations the email invoked. It did not point at the hospitality domain that sent the mail, nor at any domain belonging to the impersonated equipment brand. It pointed at a third party's shared infrastructure, a mismatch no legitimate transactional email produces. Real payment notices link back to the system that issued them.

Automated URL analysis returned a mixed, partial verdict on that destination and captured no screenshot, so what waited at the far end was never established. Stated plainly rather than embellished: the provable finding is the infrastructure mismatch, and it is sufficient. A content delivery network hands an attacker a hostname with valid transport security, no registration history to age, and a reputation inherited from every legitimate service on the same platform. Scoring that leans on domain age has nothing to grade.

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

Borrowed Template, Borrowed Trust

One more artifact gives away the method. Tracking assets from a legitimate customer-success platform appeared alongside the malicious button, on a domain with no business being in a funds-transfer notification.

That is the residue of a cloned template: someone kept a real transactional email's markup, layout, and tracking pixels and swapped the destination of its primary call to action. Cheaper than building one, and it inherits the polish of whatever was copied. It also leaves fingerprints, because those leftover assets imply a vendor relationship that exists for neither party named in the header.

What Actually Caught It

No single control was going to produce this verdict. Authentication passed on every axis, the sending domain was eight years old with a real business behind it, the landing host belonged to a major cloud provider, and the scanner verdict on the destination was partial rather than definitive.

The evidence was entirely relational, which is the ground Themis, the Adaptive AI analyst on the IRONSCALES platform, works on. A display name naming the recipient's own company. An envelope address in an unrelated industry on the other side of the world. A single call to action pointing at neither. Tracking assets from a vendor with no role in the transaction. A refund pretext with a doubled letter in the subject. Individually each is a shrug. Together they describe one thing.

The incident resolved automatically as phishing on content and link analysis, with no manual analyst step. That is the practical shape of payment-diversion attempts against a manufacturer: the technical controls confirm the mail is authentic, and the relationships confirm it is not.

Mapping to MITRE ATT&CK

Delivery is T1566.002 Phishing: Spearphishing Link, with a single View Document CTA as the entire payload surface. Sending genuinely authenticated mail from an unrelated legitimate domain maps to T1586.002 Compromise Accounts: Email Accounts. Standing the landing page up on a content delivery network is T1583.006 Acquire Infrastructure: Web Services, and wearing the target's own brand in the display name is T1656 Impersonation.

Indicators of Compromise

The Takeaway

Authentication is a statement about custody, not intent. The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and the human element in 68 percent, names pretexting the leading social-engineering type, and puts the median business email compromise transaction near 50,000 dollars. The 2023 FBI IC3 Internet Crime Report accounts for roughly 2.9 billion dollars in reported losses from that category, and the IBM Cost of a Data Breach Report 2024 puts the global average breach cost at 4.88 million dollars. None of those shrink because SPF passed.

Three practices close most of this gap. Compare the display name against the envelope domain and treat an industry mismatch as disqualifying on its own. Resolve every call to action before a user can click it, and flag any link whose host matches neither the sender nor the brand in the message. And verify refund notices inside the accounting system that owns the payment, following CISA phishing guidance and the baseline NIST maintains for phishing.

See You Next Time

Four passing authentication checks proved the mail was really sent. They never claimed it was really theirs.