- Cisco Talos analysed two campaigns that put attacker phone numbers inside genuine Staples and Dell order emails, about 1,400 messages in total. The messages passed sender checks.
- Sender checks show where a message came from, not whether its contents are legitimate. Talos says defenders should treat sender trust and content trust as separate signals.
- Companies that send order email should validate every field they print. Security teams should inspect the fully rendered message, including content nested inside bounce notices.
The sender was real. The message was not.
Staff are often taught one test for odd email: check who sent it. A new Cisco Talos report shows the limit of that test. Talos found fraudulent messages that went out through the real order systems of Staples and Dell. The sender was genuine. Key lines inside the message came from an attacker.
This shows a simple point. A trusted envelope is not a trusted letter. Talos makes the same case: sender authentication is necessary, but it is not sufficient.
What Talos found
Talos analysed two order-notification campaigns. Together they covered roughly 1,400 messages that Talos observed.
The first looked like a Staples order confirmation for an Apple iPad. It had an order number, delivery timing, pricing and the usual Staples footer. But the order details held "Helpline" followed by a phone number, plus the words "Order Confirmed".
The second was a Dell "order received" email for Microsoft Project Standard 2024, totalling $736.09. Its "Ship To" and "Bill To" sections held "Confirmed Order", a helpline number and "Call Our Sales Team".
How the trick works
Retailers build order emails from templates. A template prints values from fields such as shipping name, billing name or order note. Talos says any such field can carry an attacker's words if it is not checked before the email is built.
Talos links this to its earlier research on platform-as-a-proxy abuse. In that work, attackers placed content into fields on software platforms. The platforms later printed it into their own notifications. Talos sums it up this way: "The attacker supplies the intent, while the trusted system performs the delivery."
The messages passed sender checks. In the Staples email, DKIM, a digital signature on the message, matched the orders.staples.com domain. DMARC, the policy check built on that signature, passed for the Staples domain readers could see. The Dell email passed DKIM, and it passed DMARC for order.dell.com.
These checks help show that mail came from expected systems. They do not show that an order was real. They also say nothing about whether a phone number in a billing field belongs there.
The aim was a phone call, not a click. The emails implied that an expensive order was already placed. The quickest way to fix it, they suggested, was to ring the "helpline".
After that, the fraud can take several forms. Talos names social engineering, payment manipulation, credential theft and remote assistance fraud.
Two more routes to the same trust
Talos describes the same pattern in list bombing. Here, attackers sign a victim's address up to many services to flood the inbox. Talos has seen a subset of cases where those emails carry a lure. The attacker types text, such as a cryptocurrency-themed lure, into a name or company field. The service then repeats it in a welcome or verification email.
Talos is clear on scale. It describes the list-bombing pattern as not yet widespread across the industry.
The third route uses bounce messages. These are the automated notices sent when mail cannot be delivered. They can include parts of the original message. Talos saw one such notice carrying a WeTransfer-themed file-sharing lure. Its administrative look made it resemble routine mail-system traffic.
Who carries the cost
The recipient is the first to bear it. The sending company is second. Talos says user complaints and bounce-backs from misused notifications can lower a platform's sender reputation. That could lead to blocklisting, which would affect the company's legitimate business email.
Security teams lose a shortcut too. Talos notes that a message from a trusted platform may be judged as routine notification traffic. A check meant to help can become the reason a message gets through.
Questions to put to your teams
If you send customer email, ask how each printed field is checked. Talos advises validating values when they are stored and again before they are rendered. A phone number, web address, line break or urgent support wording in a name or address field should raise a flag.
If you run email security, ask what your gateway actually examines. Talos wants the finished email read in full, including HTML, links, attachments and nested parts, rather than a verdict based on who sent it or which template was used. For bounce notices, it advises opening the nested content and applying normal phishing, malware and URL analysis.
Ask also what staff should do with an unexpected order. A sound rule is to ignore the number in the email and find a support channel independently. Talos adds that retailers should compare order content with account history, payment state and known support channels.
Authentication tells you who sent the message. It does not tell you whether the sender was made to carry someone else's words.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cisco Talos.
