Parasitizing trust: How legitimate infrastructure becomes a delivery pipeline for attackers

What it is

Cisco Talos describes attacker-influenced content riding inside genuine, authenticated system email. It names three vectors: order-notification abuse (Staples and Dell, about 1,400 messages), list bombing used for content delivery, and bounce (DSN) messages that carry a lure. In each case the outer message is real, and the attacker controls only a field or a nested payload. Talos says the central point is this split between a wrapper that inherits trust and a payload the attacker influences.

How it works

Order notifications. The attacker puts text into fields the retailer reflects into its transactional template, and the retailer's system sends the email. Both campaigns pushed the victim toward a phone call, not a link.

• Staples: sender support@orders.staples.com, an iPad order, and "Helpline 806 283 7712" and "Order Confirmed" in fields normally holding shipping or billing details.
• Dell: sender received@order.dell.com, a Microsoft Project Standard 2024 order totalling $736.09, and "Helpline 808 232 6397" and "Call Our Sales Team" in the "Ship To" and "Bill To" sections.
• Headers showed DKIM alignment and DMARC pass for the retailer domains. Messages also passed through Proton Mail, Microsoft 365 and enterprise mail, which added forwarding and SRS-style return-path artifacts.

List bombing. Attackers find public registration, profile or project-name forms with weak input validation. They enter a hostile string, such as a cryptocurrency-themed lure, in a name, company or title field. The service echoes it into a welcome or verification email that can pass authentication. Talos says this is not yet a broad industry shift.

Bounce abuse. A DSN or NDR can include the original headers, body portions, URLs, attachments or an encapsulated copy of the failed message. Talos saw a mail-delivery notification carrying a WeTransfer-themed lure. It describes two routes: backscatter to a forged envelope sender, and deliberate triggering from an authenticated or compromised sending context. A fabricated NDR looks similar in the mailbox.

flowchart LR
    A[Attacker input] --> B{Platform validates field?}
    B -- no --> C[Trusted template renders it]
    C --> D[Passes DKIM/DMARC]
    D --> E{Gateway inspects rendered content?}
    E -- no --> F[Victim sees lure]
    B -- yes --> G[Rejected or flagged]
    E -- yes --> G

What to do

For platform owners:

• Treat every user-controlled value rendered into an email template as untrusted.
• Validate fields such as names, addresses, company names, project titles, order notes and support instructions before storage and again before rendering.
• Reject or flag phone numbers, URLs, markup, line breaks and urgent support language in fields where they do not belong.
• Correlate order notification content with account history, payment state, shipping context and known support channels.

For mail security teams:

• Inspect the fully rendered message: HTML, text, URLs, redirects, attachments, personalization fields and nested MIME.
• Check whether transactional content fits the workflow that produced it. Unexpected support numbers, cancellation instructions or urgency language in a receipt should be treated differently from a routine one.
• Parse DSN containers recursively, extract the returned message or fragments, and run normal phishing, malware and URL analysis on them.

Caveats

• SPF, DKIM and DMARC pass in the Staples and Dell samples, so authentication results cannot be used to clear this kind of mail.
• Talos gives no detection queries, indicators beyond the two phone numbers, or prevalence figures for list bombing and bounce abuse. The bounce section rests on one observed WeTransfer example.
• The page does not say how the attackers got their text into the Staples and Dell fields, so the exact injection point is unconfirmed.
• Forwarding hops complicate provenance analysis.