Tag: Threat Spotlight

• 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 <received@order.dellcom>” 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 broad industry shift, it represents a calculated abuse of a platform’s trust boundary. By embedding their lure in an automated notification, the adversary ensures that the message arrives with the appearance of administrative legitimacy, significantly increasing the likelihood that the recipient will trust the content. The goal is to reach the target’s inbox with enough platform authority that the message may be evaluated as routine notification traffic rather than attacker-controlled content. 

Beyond the risk to the individual recipient, this vector creates a significant brand liability. When a service provider’s infrastructure is used to broadcast fraudulent content, the resulting user complaints and bounce-backs can degrade the platform’s own sender reputation, potentially triggering blocklisting that impacts their legitimate business communications. 

Bounce abuse: When delivery reports carry the lure 

The final vector moves the abuse pattern into the mail system itself. Instead of relying on a retailer, SaaS platform, or registration workflow to generate the message, the attacker attempts to make a delivery status workflow carry attacker-controlled content. 

Bounces, formally known as delivery status notifications (DSNs) or non-delivery reports (NDRs), are generated when a message cannot be delivered. Under normal conditions, a mail system sends the delivery report back to the original SMTP envelope sender. Depending on the implementation, that report may include the original headers, portions of the message body, URLs, attachments, or an encapsulated copy of the failed message. That returned content creates the abuse opportunity.  

In one example Talos observed, a mail delivery system notification carried a WeTransfer-themed file-sharing lure. The administrative wrapper made the message look like routine mail-system noise, while the nested content asked the recipient to engage with what appeared to be a file transfer workflow. The attacker’s goal was to make the phishing lure feel less like an unsolicited external message and more like part of a technical delivery failure that required review. Users are conditioned to view system errors as benign and are far more likely to engage with an “administrative” fix than a suspicious, standalone phishing email.  

There are several ways this kind of message can reach a victim. In opportunistic backscatter, an attacker sends mail using the victim’s address as the forged envelope sender. If an intermediate system accepts the message and later fails to deliver it, the resulting DSN may be sent back to the forged sender. If the DSN includes enough of the original message, the bounce itself can carry the lure. 

 A second possibility is intentional bounce abuse, where the attacker uses an authenticated, compromised, or otherwise controllable sending context to trigger a delivery failure that returns attacker-influenced content. This differs from an outright forged NDR, where the attacker simply fabricates the bounce message and sends it directly. From the recipient’s mailbox, however, these cases can look similar: A delivery-failure wrapper contains content the attacker wants the user to trust. 

This distinction matters for defenders. A DSN’s administrative appearance does not validate the content inside it. The outer message may be a legitimate delivery report, while the returned or encapsulated content may still contain a phishing link, credential harvesting page, malicious attachment, or social engineering prompt. 

The content-trust gap: A defensive imperative 

Across these vectors, the defensive failure is consistent: Trusted infrastructure is being treated as a shortcut for trusted content. 

Sender authentication remains essential. SPF, DKIM, DMARC, reputation, and infrastructure analysis help determine whether a message came from an expected source. But these controls do not answer a separate and increasingly important question: What was that trusted system instructed to carry? 

Order notifications, registration workflows and delivery reports all create opportunities for attacker-influenced content to appear inside messages that users and security tools are conditioned to trust. In the Staples and Dell campaigns, the suspicious content was a phone number placed into transactional fields. In list bombing and registration abuse, the lure can appear inside reflected account or profile data. In bounce abuse, the malicious content may sit inside returned message data or a nested MIME object. 

Defending against this requires content-aware validation at multiple points in the delivery chain. Platform owners should treat any user-controlled value rendered into an email template as untrusted data. Fields used for names, addresses, company names, project titles, order notes or support instructions should be validated before storage and again before rendering. Phone numbers, URLs, markup, line breaks, and urgent support language should be rejected or flagged when they appear in fields where they do not belong.  

Security gateways should inspect the fully rendered message, not only the sender or template. That includes HTML, text, URLs, redirects, attachments, personalization fields, and nested MIME content. For transactional email, defenders should also evaluate whether the message content aligns with the workflow that produced it. An order notification containing unexpected support numbers, cancellation instructions, or high-urgency language should be treated differently from a routine receipt. 

For delivery reports, recursive MIME inspection is especially important. Gateways should parse DSN containers, extract returned messages or message fragments, and apply normal phishing, malware, and URL analysis to the nested content. A bounce should explain a delivery failure, not provide a blind path for untrusted payloads. 

The broader lesson is that attackers are no longer only exploiting technical vulnerabilities in infrastructure. They are exploiting the assumptions built into business processes. When legitimate systems render attacker-influenced data into trusted notifications, the result can pass authentication checks and still deliver malicious intent.  

Defenders should therefore treat sender trust and content trust as separate but complementary signals. The wrapper can explain where a message came from. It cannot prove that the payload is safe. 

Acknowledgments 

Special thanks to Eric Peterson, Dev Shah, and Adam Katz for their professional guidance and input during the development of this research. 

Source: Cisco Talos Intelligence · 2026-10-21