Cisco Talos: ~1,400 callback phishing emails sent through legitimate Dell and Staples order notifications, passing DKIM and DMARC
Matéria consolidada. Reúne 2 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que a fonte trouxe em 29/10/2026 00:01; os links antigos trazem para cá.
Fontes: gbhackers.com ×2 ↗
Cisco Talos observed roughly 1,400 messages in two callback phishing campaigns that abuse the legitimate order-notification systems of Staples and Dell (gbhackers.com). Attackers insert fraudulent helpline numbers and support instructions into fields that the retailer platforms reflect into authenticated transactional emails. The messages therefore pass DKIM and DMARC without spoofed senders or malicious links. The lures push recipients alarmed by an unexpected purchase to phone an attacker-controlled number instead of visiting a phishing site. Talos has seen similar abuse across more than 25 legitimate platforms over the past year, including collaboration, productivity, payments, file sharing, survey and AI services (gbhackers.com, 28 Oct 2026). The supplied findings do not establish which follow-on actions occurred, such as payment manipulation, credential theft or remote-assistance fraud.
Detalhes técnicos
- Injection method: the attacker enters a hostile string into fields meant for a name, company, title, or Ship To / Bill To. The platform treats it as legitimate user data and renders it in the order confirmation, so the email inherits the provider's reputation (gbhackers.com).
- Staples lure: an order confirmation for order #9939818875 describing an Apple iPad purchase. Shipping and billing fields contained "Helpline 806 283 7712" and "Order Confirmed". DKIM was aligned for orders.staples.com and DMARC passed. Forwarding through Microsoft 365 and Proton Mail complicated provenance analysis (gbhackers.com).
- Dell lure: referenced Purchase ID 2009829958247 and a Microsoft Project Standard 2024 purchase totaling $736.09. Ship To / Bill To fields contained "Helpline 808 232 6397", "Confirmed Order" and "Call Our Sales Team". DKIM and DMARC passed for order.dell.com (gbhackers.com).
- Authentication limits: the results validate the delivery context, not the legitimacy of the purchase or the embedded phone numbers (gbhackers.com).
- Platform-as-a-proxy lineage: the technique extends earlier Talos research on SaaS notification pipelines, which covered scam content in GitHub commit messages and Jira project or invitation fields. In the GitHub activity, invoice-themed lures were 1.20% of observed notification traffic over five days, peaking at about 2.89% of the daily sample on February 17, 2026. Those figures do not apply to the Staples and Dell campaigns (gbhackers.com).
- Other vectors: registration workflows that reflect attacker-supplied names in automated welcome emails (including list-bombing for targeted delivery). Delivery status notifications can also carry lures in returned message bodies or nested MIME content. One observed example was a WeTransfer-themed lure (gbhackers.com).
Remediação
- Retailers should validate user-controlled fields before storage and rendering. They should flag unexpected phone numbers, URLs or urgent support instructions, and correlate notifications with account history, payment status, shipping context and authorized support channels.
- Security gateways should inspect rendered HTML, plain text, attachments, redirects and nested MIME objects, including returned delivery reports, rather than relying on sender reputation or authentication alone.
- Recipients should verify unexpected purchases through independently accessed retailer accounts or established support channels, never through numbers in the suspicious email.
Linha do tempo
-
Cisco Talos finds ~1,400 scam emails sent through legitimate Staples and Dell order notification systems
ler a análise desta fonte ocultar
Cisco Talos identified roughly 1,400 scam emails delivered through legitimate Staples and Dell order notification systems. Attackers inserted fraudulent support instructions into authenticated transactional messages. Talos has seen similar abuse across more than 25 legitimate platforms over the past year, including collaboration, productivity, payments, file sharing, survey and AI services. The lures push recipients to call an attacker-controlled phone number about an unexpected purchase rather than visit a phishing site. The supplied findings do not establish which follow-on outcomes (payment manipulation, credential theft, remote assistance fraud) occurred.
Technical Details
- Attacker-controlled input is placed in fields that the platform reflects into order confirmations, such as name, company, title, and Ship To / Bill To. The messages therefore inherit the provider's reputation.
- The Staples samples were order confirmations (e.g., an Apple iPad purchase) with "Helpline 806 283 7712" and "Order Confirmed" in shipping/billing fields.
- The Dell sample was an order for Microsoft Project Standard 2024 totaling $736.09, with "Confirmed Order", "Helpline 808 232 6397" and "Call Our Sales Team" in the Ship To / Bill To sections.
- Samples passed DKIM and DMARC, including alignment tied to orders.staples.com and order.dell.com. Authentication validated delivery, not the legitimacy of the embedded phone numbers or transaction claims. Forwarding through extra mail infrastructure complicated provenance.
- This extends the platform-as-a-proxy model from earlier Talos research on SaaS notification pipelines, which covered lures in GitHub commit messages and Jira project or invitation fields. In the GitHub activity, invoice-themed lures were 1.20% of observed notification traffic over five days, peaking at about 2.89% of the daily sample on February 17, 2026. These figures do not apply to the Staples and Dell campaigns.
- Other vectors: hostile strings in registration fields reproduced by automated welcome emails (including list-bombing cases), and delivery status notifications whose returned bodies or nested MIME objects carry phishing content. Talos saw a WeTransfer-themed lure carried this way.
Remediation
- Defenders should inspect rendered transactional content alongside sender identity.
- Retailers should validate reflected fields, flag misplaced phone numbers and support instructions, and correlate notifications with account history, payment status, shipping context and authorized support channels.
- Email gateways should recursively inspect returned messages and nested MIME content instead of exempting delivery reports.
- Recipients should verify unexpected purchase claims through independently accessed retailer accounts or established support channels, never through phone numbers in suspicious transaction fields.
-
Scammers abuse legitimate Dell and Staples order emails to deliver callback phishing lures that pass DKIM and DMARC
ler a análise desta fonte ocultar
Cisco Talos observed roughly 1,400 messages across two callback phishing campaigns that abuse legitimate Dell and Staples order notification pipelines. The attackers inject fraudulent helpline numbers into fields the retailer platforms render in authenticated transactional emails, so the messages pass authentication without spoofed senders or malicious links. The goal is to push recipients alarmed by an unexpected purchase to phone the scammers, where payment fraud, credential theft or remote-assistance scams could follow. Talos has tracked similar abuse of more than 25 legitimate platforms over the past year. The supplied findings do not establish which follow-on actions occurred.
Technical Details
- The Staples lure appeared as an order confirmation for order #9939818875, describing an Apple iPad purchase. Shipping and billing fields contained "Helpline 806 283 7712" and "Order Confirmed". DKIM was aligned for orders.staples.com and DMARC passed.
- The Dell lure referenced Purchase ID 2009829958247 and a Microsoft Project Standard 2024 purchase totaling $736.09. "Ship To" and "Bill To" fields contained "Helpline 808 232 6397", "Confirmed Order" and "Call Our Sales Team". DKIM passed and DMARC passed for order.dell.com.
- The attacker enters a "hostile string" into fields meant for a name, company or title, and the platform treats it as legitimate user data. Authentication results validate the delivery context, not the purchase or the embedded phone numbers.
- Forwarding through Microsoft 365 and Proton Mail in the Staples example complicated provenance analysis.
- The mechanism mirrors earlier Talos "platform-as-a-proxy" research: scam content in GitHub commit messages and Jira project or invitation fields, registration workflows that reflect attacker-supplied names, and list-bombing used for targeted content delivery.
- Delivery status notifications can also carry lures in returned message bodies or nested MIME content. One observed example had a WeTransfer-themed lure.
Remediation
- Retailers should validate user-controlled fields before storage and rendering, and flag unexpected phone numbers, URLs or urgent support instructions.
- Check order notifications against payment status, account history, shipping context and approved support channels.
- Security gateways should inspect rendered HTML, plain text, attachments, redirects and nested MIME objects rather than relying on sender reputation or authentication alone.
- Recipients should verify unexpected purchases through independently accessed retailer accounts or established support channels, never through numbers in the suspicious email.