Phishing

A Dell order confirmation for $736.09 of Microsoft Project Standard 2024 that nobody ordered, with "Helpline" and a phone number printed in the Ship To box. Cisco Talos published that example on October 21 as part of research into attackers abusing more than 25 legitimate platforms, and counted about 1,400 messages across two campaigns that used Dell and Staples order emails this way. The email is real. Dell's systems wrote it, signed it and sent it. The attacker only chose what went into the address fields.

Messages like these pass SPF, DKIM and DMARC, the three checks that tell a mail system whether a message really came from the domain it claims. The lure needs no malicious link or attachment, only a number to call. If your staff receive order, invoice or booking notices from large vendors, and your mail filter trusts authenticated mail from them, this reaches inboxes. The fix is a set of content rules, a hunting query and a script for whoever answers the phone.

How it works

Transactional email is built from templates. A shop, a booking site or a payment service fills in fields the customer typed (name, address, company, listing title) and sends the result from its own mail servers, signed with its own DKIM key. DMARC checks only that the domain in the visible From line lines up with a domain that passed SPF or DKIM, so whatever text the platform renders into its template inherits the platform's reputation.

The attacker fills the free-text fields with the lure. In the Dell case Talos documented, the Ship To and Bill To blocks read "Confirmed Order", "Helpline" with a number, and "Call Our Sales Team". In the Staples case, an iPad order from orders.staples.com carried the same kind of "Helpline" line, next to the Staples corporate address. The point is a costly purchase the reader did not make and a number that promises to undo it.

Next, the order goes to a mailbox the attacker controls, which relays it on. In a September 18 write-up, IRONSCALES traced one genuine Dell acknowledgement that went to a mailbox on an attacker-owned Microsoft 365 tenant and was relayed through two further tenants to two unrelated organisations, about two minutes apart. Relaying rewrote only the SMTP envelope, the routing addresses the servers use, so the signed headers and body were untouched. Both recipients' systems recorded SPF pass, DKIM pass on Dell's domain and DMARC pass under Dell's reject policy.

The tell was in the signature itself. The To header was one of the signed headers, and it named the attacker's first mailbox, not the person who received the email. Only the envelope named the real recipient. DMARC never compares those two, so the mismatch passed every check while proving the message had never been addressed to the person reading it.

What attackers are doing

The same pattern shows up elsewhere:

• Airbnb. Ocean Security reported on June 1 that attackers created free Airbnb host accounts and typed a fake "payment successful" notice with a callback number into the listing name. Airbnb's notification rendered it into a genuine email, DKIM-signed for email.airbnb.com and passing DMARC against a reject policy. Each target had its own listing, its own iCloud address and its own GMX account: an iCloud mail rule forwarded the notification to GMX, which sent it on unchanged. There was no link and no attachment.
• PayPal. IRONSCALES described a cancellation notice for a $50 invoice, sent through PayPal's real invoicing system and signed for paypal.com, which passed SPF, DKIM and DMARC. The lure here was the Reply-To address, which pointed to an outside merchant domain, so any reply went to the attacker.
• Amazon branding via SendGrid. A fake Amazon order for an iPhone 17 at $975.00 told the reader to call "immediately to block this transaction". SPF and DKIM passed for sendgrid.net, but DMARC failed because the visible From was a Gmail address. Microsoft sent it to Junk rather than blocking it.
• Bounces and list bombing. Talos also saw lures typed into the name or company fields of sign-up forms, which the platform's welcome email then delivered, and delivery-failure notices carrying a WeTransfer-themed lure.

The goal of a callback lure is a phone conversation. IRONSCALES describes the usual follow-up as a fake cancellation that asks for card details, or a "refund" that needs remote access software installed. None of the reports say how many people called, and IRONSCALES notes it could not confirm who answers the Dell number.

What to do

Add a content rule for transactional senders. Authentication cannot catch this, so match the content. In Exchange Online, a mail flow rule can combine the sender domain with a body pattern and flag the message instead of blocking it, because real order emails also carry support numbers:

New-TransportRule -Name "Callback check: order and booking mail" `
  -SenderDomainIs order.dell.com,orders.staples.com,paypal.com,airbnb.com `
  -SubjectOrBodyMatchesPatterns 'helpline','call our sales team','call immediately','call to cancel' `
  -PrependSubject "[Unverified order: do not call] " `
  -SetHeaderName "X-Callback-Review" -SetHeaderValue "1"

SenderDomainIs also matches subdomains. Add the vendors your company actually buys from. For the first week, leave out -PrependSubject and keep only the header, then filter EmailEvents on the ExchangeTransportRule column to see how much legitimate mail the rule touches. Add the callback numbers published in the Talos and IRONSCALES write-ups as extra patterns.

Hunt for the recipient mismatch. With Defender for Office 365, the EmailEvents table holds both the To header and RecipientEmailAddress. A query like this finds vendor mail delivered to someone it was never addressed to:

EmailEvents
| where Timestamp > ago(30d) and EmailDirection == "Inbound"
| where SenderFromDomain matches regex @"(^|\.)(dell|staples|airbnb|paypal)\.com

      
    
quot;
| where isempty(DistributionList)
| where indexof(tolower(To), tolower(RecipientEmailAddress)) == -1
| project Timestamp, RecipientEmailAddress, To, SenderFromAddress,
    SenderMailFromDomain, Subject, AuthenticationDetails, UrlCount,
    AttachmentCount, IsFirstContact

Bcc and some list mail also produce a mismatch, so review the results rather than alert on all of them. A hit with UrlCount of zero, IsFirstContact of 1 and a sender your company has no account with is worth a closer look.

Read the headers when someone reports one. Check Authentication-Results for dkim=pass header.d= and dmarc=pass, then compare the To header with the mailbox it landed in. Look at the Received chain for hops through unrelated onmicrosoft.com tenants, GMX servers, or an X-Apple-Action: FORWARD header. Check that Reply-To matches the vendor.

Give the help desk a script. When someone calls about an order they did not place: do not call the number in the email; find out whether the company has an account with that vendor; check the order through the vendor's website or the procurement system; and if they already called, ask whether they gave card details or installed anything. Remote access software installed during a call means isolating the device and resetting the user's passwords.

Brief finance and IT staff. These are the people who receive order and invoice notices and who might call to stop a charge. Tell them that a passed authentication check only proves which company's servers sent the email. Whether the order exists is a question for the vendor's own website or the purchasing system, and the only number to call is the one listed there.

Report the abuse to the vendor. Each of these platforms has a phishing reporting route on its help or security pages; send the full original message as an attachment so the signed headers survive. Report it to Microsoft from the Submissions page in the Defender portal as well.

The wider lesson

Many organisations allow-list big SaaS senders because their mail authenticates cleanly. Talos's recommendation is to judge whether the content fits the process that produced it: a support number in a Ship To field, or an urgent cancellation in a listing name, does not. Talos also asks platforms to reject phone numbers, URLs and urgent support language in name and address fields. Until they do, the check belongs in your own mail rules.

Our security operations team runs this kind of hunting and tunes mail flow rules for it, and our safeguarding and hardening work reviews which senders your filters trust and why. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Cisco Talos, Help Net Security, IRONSCALES on the Dell relay, Ocean Security on Airbnb, Expert Insights on Airbnb, IRONSCALES on PayPal invoices, IRONSCALES on the Amazon lure, Microsoft: mail flow rule conditions, Microsoft: EmailEvents table.