Hackers Are Using Real Dell and Staples Emails to Make Their Scams Look Legitimate

Hackers are abusing genuine Dell and Staples order emails to make fake purchase alerts look credible. Instead of sending a forged message, they place scam instructions inside order details that trusted retail systems deliver, pushing recipients toward phone numbers controlled by the attackers.

The emails describe expensive purchases that recipients may not recognize. Their aim is to make someone call a supposed support line to cancel the order.

The sender and email design can look genuine because the message travels through the retailer’s notification system, even though parts of its content serve the scam.

Cisco Talos researchers identified two campaigns involving roughly 1,400 messages, according to an October 21 report by Diana Brown.

The findings describe phishing and phone-based fraud, not a confirmed malware infection. Talos also observed abuse of more than 25 legitimate platforms during the past year across several service categories.

Hackers Are Using Real Dell and Staples Emails

The Staples sample presented an Apple iPad purchase with an order number, delivery details, pricing, billing information, and the retailer’s standard footer.

The suspicious instructions appeared inside fields normally used for shipping or billing data. Similar Microsoft Teams notification scams have used trusted messages to direct recipients toward fraudulent support calls, showing how familiar branding can hide dangerous instructions.

The Dell example followed the same pattern. It described a Microsoft Project Standard 2024 purchase costing $736.09.

Its shipping and billing sections contained order confirmation wording and a supposed helpline, making the phone number appear connected to an established sales process rather than an outside scammer.

Neither example depended on persuading the recipient to open an obvious phishing link. The intended next step was a phone call.

Once contact moved away from email, attackers could attempt payment fraud, password theft, or remote assistance scams. Talos did not establish which follow-on actions occurred in these two campaigns.

The Staples message showed aligned DKIM authentication and passed DMARC checks. Dell-related infrastructure also passed DKIM, while its order domain passed DMARC.

These results supported the messages’ apparent origin, but they did not prove that the purchase details or embedded support instructions were genuine.

This reflects the same weakness seen in GitHub and Jira notifications, where attackers place harmful content inside fields that legitimate services later include in automated emails.

Why Email Authentication Did Not Prove Safety

Talos calls this platform-as-a-proxy abuse: the attacker supplies the misleading content while a trusted service handles delivery. The distinction matters for email security. SPF, DKIM, and DMARC help establish whether sending infrastructure is expected.

They do not decide whether a shipping field should contain cancellation instructions, whether a purchase makes sense, or whether a listed phone number belongs to the retailer.

Talos also described registration abuse, where attackers enter scam text into name, company, or project fields. Automated welcome messages then repeat that text to recipients.

In some cases, list bombing becomes more than inbox disruption: legitimate registration emails themselves become carriers for attacker-controlled messages.

Related email bombing support scams show how inbox confusion can support social engineering, although that separate activity should not be treated as evidence of the same operators.

Talos additionally found a WeTransfer-themed lure inside a delivery failure notification, extending the problem to returned email content.

Talos recommends checking user-controlled fields before storing them and again before generating emails. Unexpected phone numbers, links, urgent language, and support instructions should trigger review when they appear in address or name fields.

Security gateways should inspect complete messages, including content nested inside delivery reports, rather than trusting the outer sender alone.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) 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 TI Feeds with data from 16K SOCs.