Scammers Are Hiding Callback Fraud Inside Real Dell and Staples Order Emails

The most convincing phishing email is the one that isn't fake at all. Attackers are now planting fraud instructions inside genuine order notifications sent by Dell's and Staples' own systems, so the message arrives from the real retailer, passes email authentication, and still steers the reader toward a scammer's phone line.

What happened

Researchers tracked two campaigns totalling roughly 1,400 messages. The technique is simple: instead of forging a retailer's email, the attacker places an order (or starts one) and types scam text into fields the customer controls, such as the shipping name, address lines or billing details. The retailer's notification system then dutifully copies that text into an otherwise legitimate confirmation email.

• Staples sample: an Apple iPad order of about $455, with the "shipping" and "billing" blocks reading Order Confirmed and a "helpline" number, plus a note that orders can be cancelled within 30 minutes.
• Dell sample: a Microsoft Project Standard 2024 licence at $736.09, with Confirmed Order, Helpline… Call Our Sales Team written into the Ship To and Bill To fields.

The goal is not a click. It's a phone call. A recipient who sees an expensive purchase they never made is nudged to ring the "support" number and cancel it.

The same research describes this as platform-as-a-proxy abuse: the attacker writes the content, a trusted service delivers it. Similar abuse has been seen across more than 25 legitimate platforms over the past year, including registration and welcome emails that echo whatever a user typed into a name or company field, and a lure tucked inside a delivery-failure (bounce) notification.

Why it matters

Both messages showed passing DKIM and DMARC results, because they really did come from Dell- and Staples-operated infrastructure. That is exactly the point: SPF, DKIM and DMARC prove who sent a message, not whether what it says is true. They can't tell you that a shipping field shouldn't contain a phone number.

What happens after the call wasn't established for these two campaigns. Callback scams of this type typically lead to payment fraud, credential theft or a "remote support" session, but the observed activity here is phishing and phone-based fraud, not a confirmed malware infection.

What to do

For everyone receiving these emails

• Treat any unexpected purchase confirmation as suspicious, even if the sender is genuine.
• Never call a number printed inside an order email. Look up the retailer's support contact on its official website or in your account.
• Read the address and name fields. "Helpline", "Call our team" or a phone number where your street should be is a red flag.

For security and IT teams

• Don't let a DMARC pass act as an allow-list. Have gateways inspect the full body, including content nested in bounce and delivery reports.
• Add detections for phone numbers, urgent cancellation language and support instructions appearing in name/address blocks of transactional mail.
• Brief staff on callback (TOAD) phishing: the danger is the call, not the link.

For anyone running a platform that sends automated email

• Validate and constrain user-controlled fields when they're stored and again when they're rendered into an outbound template: length limits, character sets, and flags for phone numbers or URLs in fields that shouldn't hold them.
• Rate-limit and review sign-ups and orders that never complete but still trigger notifications.

This is ultimately a data-flow problem in the sender's application: untrusted input travelling, unchecked, into a trusted message. It's the kind of issue our AI-assisted code review is built to surface, tracing user-supplied fields through to the templates that send them so they can be validated before your brand delivers someone else's scam.

Indicators

The sender addresses are legitimate retailer infrastructure. Don't block them; flag the injected content.

Research: Cisco Talos. Originally reported by Cyber Security News.