/
← Voltar ao feed
medium retail consumers

Scammers abuse legitimate Dell and Staples order emails to deliver callback phishing lures that pass DKIM and DMARC

1 fonte(s) · 1 atualização(ões) · publicado 22/10/2026 09:10 · coletado há 3 horas

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.

Detalhes técnicos

  • 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.

Remediação

  • 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.

Linha do tempo

  1. gbhackers.com ↗ · pub. 22/10/2026 09:10 · coletado 22/10 11:00 primeiro registro

    Scammers abuse legitimate Dell and Staples order emails to deliver callback phishing lures that pass DKIM and DMARC

    ler a análise desta fonte

    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.