A phishing message does not need a fake sender or a lookalike domain any more. It can arrive inside a genuine order confirmation from a retailer you actually buy from, carrying the retailer's own signature.
What happened
Cisco Talos analysed two campaigns that abused the transactional email systems of Staples and Dell, together about 1,400 messages. Attackers typed their own text into fields the retailers later render into order confirmations, such as shipping and billing lines. The finished email showed a plausible purchase, the real branding and the real footer, but the shipping block read "Helpline 806 283 7712" on the Staples sample and "Helpline 808 232 6397" on the Dell sample.
Both messages passed authentication: DKIM aligned and DMARC passed for the genuine sending domains. There was no attachment, no link and no binary. The payload was a phone number, meant to move the victim from email to a voice call where the operator can push payment changes, credential theft or remote support software.
Talos says it has now seen this pattern, which it calls platform-as-a-proxy, across more than 25 legitimate platforms in the past year, covering collaboration, productivity, file-sharing, survey, payment and AI services. Two related variants put the lure in sign-up fields so the platform's own welcome email delivers it, or inside a bounce message containing a file-sharing lure.
Who is affected
- Any organisation whose staff receive order, invoice, shipping or subscription notifications from real vendors
- Microsoft 365 and Google Workspace tenants that rely on SPF, DKIM and DMARC as the main phishing control
- Help desks that handle "cancel this order" calls without a verification step
- Companies that forward mail through several systems, which hides the original path further
What to do now
Assume authentication is not content inspection, and give staff a rule for numbers inside unexpected order emails.
- Tell users never to call a number printed in an order confirmation for a purchase they did not make. Look the number up on the retailer's own site instead.
- Ask your email gateway vendor whether it inspects the fully rendered message and personalisation fields, not only the envelope sender and domain reputation.
- Hunt mail logs for transactional senders whose bodies contain support numbers outside your known allowlist, and for the numbers above if you want a quick test.
- Add callback scams to help desk scripts: verify the caller against the account, never against the details in the email.
What this means for South African businesses
Most South African SMEs have spent the last few years getting SPF, DKIM and DMARC right, and this campaign is the clearest example yet that those records only answer whether a domain sent the mail. Our judgment is that a mid-sized local company is more exposed through its help desk than through its mail filter, because a staff member with a real-looking receipt and a deadline will phone the number and a busy support agent will believe them. The controls that matter here are procedural and cost nothing: verify by callback to a known number, and treat urgency inside a genuine notification as the warning sign it is.
Source: Cisco Talos, Parasitizing trust.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.