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

Legitimate infrastructure has become a powerful delivery mechanism for attackers, carrying the inherent trust they once had to build. As Cisco Talos explored in our previous research on weaponizing software-as-a-service (SaaS) notification pipelines , these platforms are increasingly repurposed as proxies for malicious intent. Talos has since tracked a significant acceleration in this trend, observing abuse across more than 25 distinct legitimate platforms in the past year. The abused infrastructure included collaboration, productivity, file-sharing, survey, payment, and AI-related platforms. This demonstrates that attackers are not limiting themselves to traditional phishing infrastructure or lookalike domains. Instead, they are systematically subverting the very tools businesses trust. Order notification abuse Talos recently analyzed two order notification campaigns abusing Staples and Dell transactional email pipelines. Together, these campaigns accounted for roughly 1,400 messages observed by Talos. The malicious element was not the outer sender identity, like a simple forged sender or lookalike domain. It was the content of the legitimate order notification workflow rendered. The suspicious content appeared inside the notification itself, in fields that would normally contain shipping information. The attacker’s objective was to use a trusted retail pipeline to create urgency around a high-value purchase and push the recipient toward an attacker-controlled phone number. In the first campaign, the message appeared as a Staples order confirmation from "support@orders.staples.com” with the subject line, “Here’s your Staples order #9939818875. Thanks for shopping with us.” The body displayed a plausible purchase for an Apple iPad, including order number, delivery timing, pricing, billing information and standard Staples footer content. The suspicious element was embedded in the order details: “Helpline 806 283 7712,” “Order Confirmed,” and the Staples corporate address appeared in fields normally associated with shipping or billing information. The structure of the message matters. The attacker was not trying to persuade the user to click a crude phishing link. Instead, the message created the impression that an expensive order had already been placed and that the fastest way to resolve it was to call the embedded “helpline.” The desired user action was a phone call. Once the victim moved from email to voice, the attacker could continue the scam through social engineering, payment manipulation, credential theft, or remote assistance fraud. The headers reinforced the trust problem. The Staples message showed DKIM alignment for “orders.staples.com” and DMARC passed for the visible Staples domain. The message also passed through forwarding and re-encapsulation paths, including Proton Mail, Microsoft 365, and downstream enterprise mail infrastructure. These hops complicate provenance analysis, but they do not change the core issue: Authentication helped establish that the outer message was credible, while offering no assurance that the phone number or transaction context was legitimate. The second campaign used the same pattern in a Dell order received notification. The message was sent from “Dell | Order Received ” with the subject line, “We have your order | Dell Purchase ID: 2009829958247.” The body presented a purchase for Microsoft Project Standard 2024, totaling $736.09. As with the Staples example, the suspicious content appeared in transaction fields. The “Ship To” and “Bill To” sections included “Confirmed Order,” “Helpline 808 232 6397,” and “Call Our Sales Team”. The Dell message used the same psychological lever: an unexpected high-value purchase, a legitimate-looking order template, and a phone number positioned as the path to resolution. The attacker did not need the recipient to trust a new domain or unfamiliar brand. The message borrowed credibility from Dell’s order pipeline and redirected the recipient toward attacker-controlled contact information. Authentication results showed DKIM passing for Dell-related infrastructure and DMARC passing for “order.dell.com”. As with the Staples sample, forwarding artifacts and SRS-style return paths appeared as the message moved through Microsoft and enterprise mail infrastructure. But the malicious intent did not live in an obviously forged sender. It lived inside the rendered order content. These campaigns illustrate the same trust-boundary failure described in our earlier research on platform-as-a-proxy (PaaP) abuse. In those cases, attackers placed malicious content into SaaS fields that trusted platforms later rendered into notifications. Here, the same concept appears in commerce infrastructure, in the retailer’s order pipeline. The attacker supplies the intent, while the trusted system performs the delivery. From a defensive perspective, sender authentication is necessary, but it is not sufficient. SPF, DKIM, and DMARC help answer whether a message came from expected infrastructure. However, they do not answer whether the transaction was legitimate, whether the rendered fields make business sense, or whether the user is being pushed toward an attacker-controlled action. Order notifications should be treated as sensitive content. Any field reflected into a transactional message — shipping name, billing name, address line, company name, order note, support field, or fulfillment instruction — can become a delivery vehicle if it is not validated before rendering. Retailers and security teams should correlate order notification content with account history, payment state, shipping context, and known support channels. Transactional templates should reject or flag unexpected phone numbers, URLs, urgency language, and support instructions when they appear in fields where they do not belong. In both campaigns, the wrapper was legitimate enough to inherit trust. The payload was attacker-influenced. That distinction is the center of this attack class. The abuse of commerce pipelines is merely one manifestation of a broader, systemic vulnerability. Whether the attacker initiates a fake purchase or a fraudulent account sign-up, the root cause remains the same: Platforms are implicitly trusting data that enters their systems from untrusted sources, only to render that data into high-reputation, automated notifications. This same mechanism of reflection — where input is echoed back into an email to a third party — is the engine behind an evolution in list bombing, moving the attack from simple denial-of-service to a sophisticated vehicle for content delivery. List bombing: From inbox disruption to content delivery List bombing is an abuse technique in which attackers submit a victim’s email address to numerous legitimate registration, subscription or notification workflows, flooding the inbox with automated messages. While this vector is traditionally viewed as a denial-of-service or distraction tactic designed to bury critical alerts in a flood of junk, Talos has observed a subset of cases where this behavior is being repurposed as a delivery vehicle for malicious content. This abuse occurs when an attacker identifies public-facing registration, profile, or project-naming forms that lack sufficient input validation. By inputting a "hostile string" — such as a cryptocurrency-themed lure — into fields intended for a name, company, or title, the attacker forces the platform to treat this data as legitimate user information. When the service reflexively incorporates this input into its automated welcome, verification, or notification templates, the system acts as an unintended carrier, delivering the attacker’s content inside a high-reputation, system-generated email that can pass standard authentication checks. The attacker’s objective in these cases is to bypass the security perimeter by laundering their malicious content through the brand reputation of a trusted service provider. While this is not yet a