Hackers Are Embedding Scam Instructions Inside Real Dell and Staples Order Emails

Researchers have discovered attackers abusing legitimate order notification systems at major retailers to make fraudulent purchase alerts appear authentic. Instead of forging entire emails, the attackers insert scam instructions into order fields that the retailers’ systems then deliver, steering recipients toward phone numbers controlled by the fraudsters.

The messages describe expensive purchases the recipient may not recognize and encourage a call to an alleged support line to cancel the order. Because the notifications are sent through the retailer’s infrastructure, the sender address, layout, and authentication can look genuine even though parts of the message contain malicious instructions.

Cisco Talos researchers identified two such campaigns involving roughly 1,400 messages, according to an October 21 report by Diana Brown. Talos characterized the incidents as phishing and phone-based fraud rather than confirmed malware infections, and noted that over the past year attackers abused more than 25 legitimate platforms across several service categories.

Examples: Staples and Dell Notifications

In the Staples sample, the email presented an Apple iPad purchase with an order number, delivery and billing details, pricing, and the retailer’s usual footer. The suspicious instructions were placed inside fields normally used for shipping or billing information.

Similar scams have used trusted notifications—Microsoft Teams alerts, for example—to display fraudulent support numbers, demonstrating how familiar branding and system-generated emails can conceal dangerous instructions.

The Dell example used the same approach: it showed a Microsoft Project Standard 2024 purchase totaling $736.09, with shipping and billing sections containing order confirmation language and a purported helpline number. Placing the phone number inside transaction fields made it appear to be part of the retailer’s sales process rather than an external scam.

Neither sample relied on a clear phishing link; the goal was to provoke a phone call. Once contact left email, attackers could attempt payment fraud, credential theft, or remote-assistance scams. Talos did not confirm which specific follow-on actions occurred in these two campaigns.

Technical checks showed that the Staples message had aligned DKIM and passed DMARC, and the Dell-related infrastructure also passed DKIM while its order domain passed DMARC. Those results supported the apparent origin of the messages but did not prove that the purchase details or embedded support instructions were legitimate.

This technique mirrors previous abuses of notification services such as GitHub and Jira, where attackers inject harmful content into fields that legitimate services include in automated emails.

Why Email Authentication Didn’t Guarantee Safety

Talos describes this as platform-as-a-proxy abuse: attackers supply misleading content while a trusted service handles delivery. Standard email authentication mechanisms—SPF, DKIM, and DMARC—help determine whether the sending infrastructure is expected, but they cannot validate whether a shipping field should contain cancellation instructions, whether a listed purchase is plausible, or whether a phone number actually belongs to the retailer.

Talos also documented registration abuse, where attackers enter scam text into name, company, or project fields so that automated welcome or confirmation messages repeat attacker-controlled content to recipients. In some cases, list-bombing and registration abuse turn legitimate registration emails into carriers for malicious messages.

Talos found other variants as well, including a WeTransfer-themed lure embedded in a delivery failure notification, showing the problem can extend to returned or bounced-email content.

The researchers recommend validating user-controlled fields both before storing them and again before generating outgoing emails. Unexpected phone numbers, links, urgent language, or support instructions appearing in name or address fields should trigger manual review. Security gateways should inspect entire messages—including content nested inside delivery reports—rather than relying solely on the outer sender identity.

Indicators of Compromise (IoCs)

Note: IP addresses and domains are sometimes intentionally defanged (for example, with “[.]”) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat-intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate threat intelligence feeds with data from thousands of SOCs.