Scammers are abusing legitimate Dell and Staples order notifications to deliver callback phishing lures, embedding fraudulent helpline numbers inside transactional emails that pass authentication checks.
Cisco Talos observed roughly 1,400 messages across two campaigns, highlighting how trusted retail infrastructure can carry attacker-controlled instructions without relying on spoofed senders or malicious links.
The activity extends a broader pattern: Talos tracked abuse involving more than 25 legitimate platforms over the past year, spanning collaboration, productivity, file sharing, surveys, payments, and AI services.
The Staples campaign used an order confirmation appearing from [email protected], with a subject referencing order #9939818875.
Its professionally formatted body described an Apple iPad purchase, complete with pricing, delivery information, billing details, and standard corporate branding.
However, fields normally reserved for shipping or billing information contained “Helpline 806 283 7712” and “Order Confirmed.”
These inserted instructions encouraged recipients alarmed by an unexpected purchase to telephone the attacker rather than investigate through official channels.
The Dell campaign followed the same model. An order notification referenced Dell Purchase ID 2009829958247 and a Microsoft Project Standard 2024 purchase totaling $736.09.
Its “Ship To” and “Bill To” sections included “Helpline 808 232 6397,” “Confirmed Order,” and “Call Our Sales Team.”
Both campaigns sought to move recipients from email to voice conversations, where scammers could potentially pursue payment fraud, credential theft, or remote-assistance scams.
Cisco Talos Researchers said that, on weaponizing software-as-a-service (SaaS) notification pipelines, these platforms are increasingly repurposed as proxies for malicious intent.
The supplied findings do not establish which follow-on actions occurred.
Dell and Staples Emails Exploited
The Staples sample showed aligned DKIM authentication for orders.staples.com and a passing DMARC result. Dell-related infrastructure also passed DKIM, while DMARC passed for order.dell.com.
By inputting a “hostile string” such as a cryptocurrency-themed lure into fields intended for a name, company, or title, the attacker forces the platform to treat this data as legitimate user information.
These results authenticated the delivery context, not the legitimacy of the purchase or embedded telephone numbers.
Forwarding through services including Microsoft 365 and Proton Mail in the Staples example complicated provenance analysis without changing that distinction.
The mechanism mirrors Talos’ earlier research into platform-as-a-proxy abuse, where attackers inserted scam content into GitHub commit messages and Jira project or invitation fields.
Trusted services subsequently incorporated that input into authenticated notifications, lending their reputation to malicious instructions.
Talos also described registration workflows that reflect attacker-supplied names, company details, or project titles into automated emails.
In selected list-bombing cases, this transforms inbox flooding into targeted content delivery rather than merely disruption.
Delivery status notifications offer another carrier. Returned message bodies or nested MIME content can preserve phishing lures inside otherwise legitimate delivery-failure reports.
One observed example contained a WeTransfer-themed lure, although different delivery mechanisms can produce similar-looking messages.
Retailers should validate user-controlled fields before storage and rendering, flagging unexpected telephone numbers, URLs, or urgent support instructions where those values do not belong.
Order notifications should also be checked against payment status, account history, shipping context, and approved support channels.
Security gateways need to inspect rendered HTML, plain text, attachments, redirects, and nested MIME objects rather than relying solely on sender reputation or authentication.
Business-context checks can expose cancellation instructions embedded in address fields.
This separates infrastructure authentication from transaction validation, two controls that address fundamentally different risks.
Recipients should verify unexpected purchases through independently accessed retailer accounts or established support channels, never through telephone numbers supplied in suspicious notifications.
The central failure is misplaced trust: legitimate infrastructure can deliver hostile content even when the email’s outer identity is authentic.
Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.
