Parasitizing trusted infrastructure means an attacker stops building their own delivery channel and borrows yours instead. The malicious content travels through services your business already permits, like file-sharing platforms, collaboration tools, survey and payment services, and the transactional email pipelines of major retailers. The sending system is genuine. The content it was instructed to carry is not. Details in this article come from analysis published by Cisco Talos.
Cisco Talos has tracked a marked acceleration in this behavior over the past year, building on its earlier research into platform-as-a-proxy (PaaP) abuse of software-as-a-service notification pipelines.
Talos observed abuse across more than 25 distinct legitimate platforms in the past year, spanning collaboration, productivity, file-sharing, survey, payment and AI-related services.
What is notable here is where the malicious element sits. In the order notification campaigns Talos analyzed, which together accounted for roughly 1,400 messages, there was no forged sender and no lookalike domain. The attacker fed content into fields the retailer's own system later rendered into a confirmation email, so the finished message arrived with the brand's real template, real footer and real sending infrastructure behind it.
That is why the controls most organizations rely on at the perimeter do not catch it. SPF, DKIM and DMARC confirmed alignment for the retailer domains in both campaigns. Domain allowlists and sender reputation scoring reach the same verdict, because the domain genuinely is who it claims to be and the platform genuinely does have a clean sending history. Your gateway answers the question it was designed to answer, which is where the message came from, and that answer is correct.
The unanswered question is what the trusted system was told to carry. Any user-supplied value that a platform echoes into an automated email, including names, company fields, order notes and support instructions, becomes a path for attacker-influenced content that inherits the platform's reputation on the way out.
This is a defense-architecture problem. There is no single vulnerability to patch, because the mechanism being abused is an ordinary business process working exactly as designed.
How the Delivery Chain Works: Hosting, Redirection and Execution
The chain starts with a form field, not an exploit. The attacker finds an input that a legitimate system will later render into an outbound email, places their content in it, and lets the platform do the sending. In the two order notification campaigns Talos analyzed, that produced roughly 1,400 messages carried by Staples and Dell transactional pipelines.
The Staples sample arrived from
The Dell variant followed the same construction. It came from "Dell | Order Received <
There is no attachment, no link and no binary in either message. The payload is a phone number, which maps to MITRE ATT&CK T1566.004, phishing via voice. The intended execution step happens off your network entirely, when an employee dials the helpline to cancel a purchase they never made and the operator walks them through social engineering, payment manipulation, credential theft, or remote assistance fraud that hands over a live session on a corporate endpoint.
Authentication worked exactly as designed and still passed the content through. The Staples message showed DKIM alignment for orders.staples.com with DMARC passing for the visible domain. The Dell message showed DKIM passing for Dell-related infrastructure and DMARC passing for order.dell.com. Both then traveled through forwarding and re-encapsulation paths, including Proton Mail, Microsoft 365 and downstream enterprise mail infrastructure, with SRS-style return paths appearing in the headers. Those hops make provenance analysis harder while leaving the underlying issue untouched, because a valid signature describes the sending system and says nothing about the transaction it describes.
The registration variant of this chain uses the same reflection mechanic against public-facing signup, profile and project-naming forms that do not validate input. The attacker submits a hostile string, such as a cryptocurrency-themed lure, into a name, company or title field. The platform stores it as user data and echoes it into automated welcome, verification and notification templates, which then reach the target inbox carrying the sending platform's reputation and authentication results.
The third path moves into the mail system. Delivery status notifications and non-delivery reports routinely return original headers, body fragments, URLs, attachments or a full encapsulated copy of the failed message. Talos observed a delivery system notification carrying a WeTransfer-themed file-sharing lure nested inside the administrative wrapper.
Key Insight: Attackers reach that state through opportunistic backscatter, forging the victim's address as the SMTP envelope sender so the eventual DSN returns to them, or through intentional bounce abuse using an authenticated or compromised sending context to trigger a failure that returns attacker-influenced content.
The blind spot is structural. Inspection that stops at the outer sender, the template identity and the domain reputation never reaches the rendered personalization fields or the nested MIME object inside a bounce container. A message can be fully legitimate at the transport layer and still deliver a credential harvesting page or a callback number to the user reading it.
What Allowlisted Delivery Means for Detection and Incident Scope
Allowlists are the first control to fail here. If your secure email gateway, web proxy, or mail flow rules carry exceptions for major retailers, file-sharing services, or SaaS notification senders, the message arrives with a clean verdict because every signal the control was built to check comes back correct. Sender reputation is good, DKIM aligns, DMARC passes. Nothing in that evaluation examines what the trusted system was told to render.
The second problem is that this attack class often leaves no technical artifact to investigate. When the requested action is a phone call to a helpline printed in a transaction field, there is no URL click, no attachment detonation, and no proxy log entry. Your incident timeline starts at the point the user reports something, which may be days after the call happened and after the attacker has already worked through payment manipulation, credential theft, or remote assistance fraud over voice.
That gap matters when you try to establish scope. If an employee granted a caller remote assistance, the session originates from an endpoint you own, using credentials that belong to the person who authorized it. Your SIEM sees a legitimate remote access tool, a legitimate login, and outbound connections to services your staff use every day. Answering the questions a regulator or a cyber insurer will ask becomes an exercise in reconstructing intent from normal-looking activity:
- When did unauthorized access actually begin, as opposed to when it was noticed
- Which accounts, mailboxes, or payment records were touched during the session
- Whether any data left the environment through a sanctioned file-sharing platform
- Whether the same lure reached other employees who have not reported it
Dating initial access is the part that drives cost. Breach notification obligations and most contractual incident clauses run from the moment you become aware, and both require you to describe what was affected. If your investigators cannot fix a start date, counsel will generally advise notifying on the widest defensible scope, which means more notified individuals, more client disclosures, and a longer forensic engagement than the actual intrusion warranted.
There is a dependency problem layered on top. The abused platform is frequently a service your business genuinely relies on, so the usual containment instinct of blocking the sender domain or the service outright takes out a working business function at the same time. You end up negotiating between detection coverage and the ability of your finance, legal, or project teams to do their jobs.
If your own organization operates public-facing registration, sign-up, or project-naming forms, the exposure runs in the other direction. Talos notes that when a provider's infrastructure broadcasts attacker-supplied content, the resulting complaints and bounce-backs degrade that provider's sender reputation and can lead to blocklisting that affects its legitimate business mail. For a firm that sends invoices, client notifications, or portal alerts by email, a reputation hit means your routine communications stop arriving, and you learn about it from customers rather than from a security alert.
Bounce abuse adds a quieter version of the same exposure. A delivery status notification that encapsulates the original message can carry a phishing link or a malicious attachment inside nested MIME content, and many gateways treat the administrative wrapper as the thing to score. The malicious element sits one layer below where the inspection stopped.
Detection Approaches That Do Not Rely on Domain Reputation
The highest-value change you can make is to inspect the fully rendered message instead of stopping at the sender verdict. That means your gateway parses the HTML and text body, the URLs and redirects, the attachments, the personalization fields, and any nested MIME content, then scores what it finds on its own merits.
Immediate hunts. Start with your message trace and gateway logs, since the artifacts here live in content rather than infrastructure:
- Query inbound transactional mail for phone numbers, URLs, or support instructions appearing in fields that normally hold shipping or billing values. A "Ship To" block containing a helpline string is the signature of this attack class.
- Extract and detonate the nested
message/rfc822parts inside delivery status notifications. Talos observed a mail delivery failure wrapper carrying a WeTransfer-themed file-sharing lure, where the administrative outer message looked like routine mail-system noise and the returned content held the actual phishing prompt. - Look for backscatter: DSNs arriving for messages your users never sent. That pattern indicates someone is forging your addresses as the SMTP envelope sender, and the bounce returning to your staff may carry the attacker's original body.
- Flag any mailbox receiving a sudden burst of welcome, verification, or account-notification mail from unrelated services. In list bombing used as a delivery vehicle, the lure sits in the reflected name, company, or project-title field of those automated templates.
Short-term controls. Turn recursive MIME inspection on at the gateway so DSN containers are unpacked and the returned fragments receive the same phishing, malware, and URL analysis as any ordinary inbound message. Then add content rules that treat transactional email against the workflow that produced it, so a receipt containing unexpected support numbers, cancellation instructions, or high-urgency language is handled differently from a routine order confirmation.
If you run customer-facing registration, profile, or order forms, validate user-controlled values before storage and again before rendering. Reject phone numbers, URLs, markup, and line breaks in fields intended for a name, company, title, or order note. Also review how much of the original message your MTA returns inside a bounce, because every header, URL, and body fragment you echo back is content an attacker can pre-load.
Brief your service desk on the callback path specifically. Users should verify any unexpected purchase through the retailer's published support number or account portal, never the number printed in the message, and report the mail rather than resolving it by phone.
Longer term. Because the recipient action is a voice call, your detection often has to pick the attack up after the conversation starts. Watch for what follows: a new MFA device registered on an account, an unfamiliar remote assistance tool launching, or a sign-in from a location that does not match the user's pattern. In environments Capstone manages, Adlumin flags those authentication anomalies, which matters when the attacker's goal on the call is credential theft or remote assistance fraud rather than a payment.
Finally, monitor your own outbound reputation. If your platform renders untrusted input into automated mail, the resulting complaints and bounce-backs can degrade your sender reputation and lead to blocklisting that affects legitimate business communication. Treat sender trust and content trust as two separate signals, and build detection that answers the second one.
Priorities for Defenders
Reputation-based filtering answers one question: did this message come from infrastructure that behaves well over time. That question still has value, and it no longer carries the weight your mail security program has historically placed on it. When the sending system is genuine and the content inside it was supplied by someone else, a clean reputation verdict describes the carrier and says nothing about the cargo.
The practical consequence for your environment is that trust scoring has to move down a layer. A sender score, a domain age check, or a known-good platform classification tells you about provenance. The decision you actually need is about behavior: what the message asks the recipient to do, what the attachment or link does once it lands, and what the endpoint does after a user acts on it.
The single most important shift is to base detection logic on post-arrival behavior instead of origin. That means process-lineage telemetry on the endpoint, so you can see the parent-child chain when a document spawns a script or a browser launches an unexpected binary, and enforced egress visibility, so outbound connections are inspected and logged whether the destination is a known-bad host or a reputable cloud service.
Pair that with the recognition that some of these campaigns end in a voice call and never touch your endpoints at all, which puts part of the control burden on user reporting rather than telemetry. Treat sender trust and content trust as two separate inputs, and build your logic around the one your current stack is weakest at measuring.
