TL;DR A staff accountant on a corporate accounts-payable team received a fully authenticated message spoofing a Xerox payment service. The body named a settlement PDF as if it were attached and offered a View Payment Receipt link. The structured record shows zero attachments and zero links. The only hyperlink in the message was a mailto address, and it pointed to a different consumer mailbox than the one in the Reply-To header. Two attacker inboxes, two characters apart. Adaptive AI scored it at 90 percent confidence on behavior alone.
Severity: High Business-Email-Compromise Payment-Fraud Brand-Impersonation Display-Name-Impersonation Reconnaissance MITRE: T1566 MITRE: T1656 MITRE: T1585.002 MITRE: T1598
A staff accountant on a corporate accounts-payable team received a message with the subject "You have a new message." The display name read Xerox ePay Systems. The body announced that an ACH payment remittance had been processed and was attached, and it named the file: P1/2 Settlement stub PAYID#[employee]-Job - Settlement/Deposit.pdf. Beneath that sat a "View Payment Receipt" call to action and a Xerox copyright line in the footer.
The structured incident record for this message lists no attachments and no links. Not a stripped attachment, not a sanitized URL. Zero of each. The named PDF exists only as a string of text inside the body, and the receipt button is not a web link at all.
The Two Reply Addresses Were Two Characters Apart
The single hyperlink in the entire message is a mailto href behind the receipt button, and it resolves to a personal consumer mailbox: pjgates@outlook[.]com. The Reply-To header on the same message names pjgates26@outlook[.]com.
Those are two different addresses. Same consumer provider, same local-part stem, separated by two digits. A recipient who clicks the button and a recipient who hits reply land in two separate attacker-controlled inboxes.
That detail is worth more than the generic observation that a corporate payment portal was using a free webmail address. It tells you the identity is manufactured rather than compromised, because nobody who legitimately operates a remittance service maintains two nearly identical personal inboxes and wires them to different parts of the same notification. It also suggests the operator is separating traffic, with one mailbox absorbing curious clicks and the other handling live conversations, or simply that the body template and the headers were assembled from different drafts of the same kit and never reconciled.
Nothing in the Message Could Be Scanned
Strip out the pretext and there is no technical object left to inspect. There is no file to detonate, no URL to resolve, no landing page to fingerprint, no QR code to decode. Attachment sandboxing has nothing to receive. URL rewriting and time-of-click protection have nothing to rewrite. Reputation scoring on the payload domain has no payload domain.
This is the structural problem with control stacks organized around objects. NIST defines phishing around the deception, not around the artifact, but most inspection technology is built to open things. When the attacker ships no object, the only remaining surfaces are the sender relationship, the header consistency, and the plausibility of the request. MITRE ATT&CK treats that as phishing all the same, with no sub-technique for attachment or link because neither is present.
The named PDF is doing deliberate work here. Asserting that a document is attached, and naming it precisely enough to sound like it came out of a real settlement system, invites the recipient to reply and ask for it. That reply is the actual objective. Pretexting of this kind is the leading social engineering pattern in the 2024 Verizon Data Breach Investigations Report, which puts the median business email compromise transaction at roughly $50,000. None of that value requires a click.
A Real Business Domain Signed the Whole Thing
The envelope sender was ryan@tiendasucre[.]com[.]mx, on a legitimate Mexican retail domain with no relationship to Xerox, to the recipient, or to payment processing of any kind. It arrived through a large cloud provider's bulk mail service, out25-29[.]sg[.]a[.]dm[.]aliyun[.]com, from 8[.]219[.]25[.]29.
Authentication was clean across the board. SPF passed. DKIM passed, with the signing domain matching the sending domain. DMARC passed under a policy of none. A one-click List-Unsubscribe header pointed at another mailbox on the same sending domain, which is the signature of a marketing or bulk sending account being used for something it was not provisioned for. Everything in that chain is accurate and everything in it is beside the point. DMARC, specified in RFC 7489, certifies that a domain authorized a message. It was authorized. The domain simply has nothing to do with the brand printed in the display name.
See Your Risk: Calculate how many threats your SEG is missing
Why Brand Impersonation Detection Stayed Quiet
The platform's automated impersonation flag did not fire on this message, and the reason is instructive rather than embarrassing. Impersonation detection generally looks for a domain that resembles the brand it is claiming, whether through a typo-squat, a homoglyph, or a suspicious new registration. There was no such domain to catch. The brand lived entirely in a display name and in footer copy, while the technical identity of the sender was a real and completely unrelated business.
That combination, a real authenticated domain paired with brand text in the human-readable layer, is a reliable blind spot for similarity scoring. MITRE tracks impersonation separately for exactly this reason, and CISA phishing guidance is explicit that authenticated mail still requires content and context review.
What did fire was behavioral. Themis, the IRONSCALES Adaptive AI analyst, scored the message at 90 percent confidence and labeled it credential theft. The sender had never corresponded with this organization before. A finance-function mailbox was receiving an unsolicited remittance notification. The reply path pointed off the sending domain to consumer webmail, and the in-body call to action pointed somewhere else again. A second accounts-payable mailbox received the same message, which is the shape of a targeted run at a payables function rather than an untargeted blast. None of those signals need a file or a URL to exist.
What To Take From This Case
Payment notifications deserve a verification path that does not run through the email itself. A settlement stub, a job number, and a processed date stamped the same day the message arrived are all free to invent and cost the attacker nothing. Business email compromise protection has to evaluate whether this sender has ever legitimately corresponded with this recipient, because that is the only question this message actually fails.
Two habits pay off immediately. First, when a body claims an attachment that is not there, treat the reply as the payload rather than treating the missing file as a delivery error. Second, read the raw headers against the body markup on any finance-themed message. This one gave itself away in the gap between a mailto target and a Reply-To value, and finding that took seconds.
Indicators of Compromise
| Type | Indicator | Context |
|---|
| Email | ryan@tiendasucre[.]com[.]mx | Envelope sender and Return-Path, carrying the display name Xerox ePay Systems |
| Domain | tiendasucre[.]com[.]mx | Legitimate Mexican retail domain used as the authenticated sending domain, unrelated to the impersonated brand |
| Email | pjgates26@outlook[.]com | Reply-To header value, an attacker-controlled consumer mailbox |
| Email | pjgates@outlook[.]com | mailto target behind the View Payment Receipt call to action, does not match the Reply-To header |
| Email | unsubscribe@tiendasucre[.]com[.]mx | One-click List-Unsubscribe mailto, consistent with an abused bulk sending account |
| IP | 8[.]219[.]25[.]29 | Sending IP address on the cloud provider's outbound mail range |
| Host | out25-29[.]sg[.]a[.]dm[.]aliyun[.]com | Bulk mail service host used for delivery |
| Filename | P1/2 Settlement stub PAYID#[employee]-Job - Settlement/Deposit.pdf | Fake remittance filename named in the body text, with the recipient username embedded, no actual attachment present |
| Subject | "You have a new message" | Generic lure subject with no brand or payment reference |
| Auth | SPF pass, DKIM pass (d=tiendasucre[.]com[.]mx, s=aliyun-ap-southeast-1), DMARC pass under policy none | Full authentication on a sending domain unrelated to the impersonated brand |
MITRE ATT&CK Mapping
| Technique | ID | Application |
|---|
| Phishing | T1566 | Payment-receipt lure delivered with no attachment and no link, so neither attachment nor link sub-technique applies |
| Impersonation | T1656 | Brand spoofed in display name and footer copy only, with no lookalike domain to detect |
| Establish Accounts: Email Accounts | T1585.002 | Two attacker-controlled consumer mailboxes stood up on the same provider for a single lure |
| Phishing for Information | T1598 | Named but absent remittance file used to solicit a reply and open a payment conversation |
See You Next Time
When there is no file and no link, the message itself is the payload. Check back tomorrow for the next teardown.
Email Attack of the Day is a daily series from
IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.
/case_study_thumb_telit.webp?width=1136&height=639&name=case_study_thumb_telit.webp)
/Leadership%20Headshots/Audian%20Paxson%20Headshot%201000x1000%20032026.webp?width=100&height=100&name=Audian%20Paxson%20Headshot%201000x1000%20032026.webp)
/Misc%20Icons/icon-red-teaming-agent-gradient-simple.svg)
/Misc%20Icons/icon-phishing-soc-agent-gradient-simple.webp?width=158&height=167&name=icon-phishing-soc-agent-gradient-simple.webp)
/Misc%20Icons/icon-phishing-simulation-agent-gradient-simple.svg)
/Misc%20Icons/icon-nav-encryption.svg)
