寄生信任：合法基础设施如何沦为攻击者的投递管道（Cisco Talos）

来源机构：Cisco Talos　|　原文：Parasitizing trust: How legitimate infrastructure becomes a delivery pipeline for attackers　|　原文发布：2026-10-21　|　页面性质：中文翻译与摘录（非原创综述）

概述：被寄生的信任

合法基础设施已成为攻击者强大的投递机制，承载着它们原本需要自行建立的信任。正如 Cisco Talos 在先前关于“武器化 SaaS 通知管道”的研究中所探讨的，这些平台正越来越多地被重新用作恶意意图的代理。Talos 此后追踪到这一趋势显著加速：过去一年内在超过 25 个不同的合法平台上观察到滥用，涉及的被滥用基础设施涵盖协作、生产力、文件共享、调查、支付和 AI 相关平台。这说明攻击者不再局限于传统钓鱼基础设施或仿冒域名，而是在系统性地颠覆企业所信任的工具本身。

订单通知滥用：Staples 活动

Talos 近期分析了两起滥用 Staples 与 Dell 交易邮件管道的订单通知活动，两起活动合计被 Talos 观察到约 1,400 封邮件。恶意要素并不在外层发件人身份（如简单的伪造发件人或仿冒域名），而是出现在合法订单通知工作流所渲染的内容之中，即本应填写物流信息的字段。攻击者的目标是借助可信的零售管道，围绕一笔高价值采购制造紧迫感，并把收件人推向攻击者控制的电话号码。

在第一起活动中，邮件以 “support@orders.staples.com” 发出的 Staples 订单确认形式出现，主题为“Here’s your Staples order #9939818875. Thanks for shopping with us.”。正文中展示了一笔看似合理的 Apple iPad 采购，包含订单号、配送时间、价格、账单信息与标准 Staples 页脚。可疑内容被嵌入订单详情：“Helpline 806 283 7712”、“Order Confirmed”以及 Staples 公司地址，出现在通常属于物流或账单信息的字段中。

邮件结构的要点在于：攻击者并非试图说服用户点击粗糙的钓鱼链接，而是制造“一笔昂贵订单已经产生、最快的解决方式是拨打内嵌‘客服热线’”的印象。期望的用户动作是一次电话呼叫。一旦受害者从邮件转到语音通话，攻击者便可继续通过社会工程、支付操纵、凭据窃取或远程协助欺诈推进骗局。

订单通知滥用：Dell 活动与认证结果

第二起活动使用相同的模式，出现在 Dell 的订单收讫通知中。邮件发自 “Dell | Order Received”，主题为“We have your order | Dell Purchase ID: 2009829958247.”。正文展示了一笔 Microsoft Project Standard 2024 的采购，金额 736.09 美元。与 Staples 示例相同，可疑内容出现在交易字段中，“Ship To”与“Bill To”部分包含“Confirmed Order”、“Helpline 808 232 6397”与“Call Our Sales Team”。

头部信息强化了信任问题：Staples 邮件显示 orders.staples.com 的 DKIM 对齐，可见 Staples 域名的 DMARC 通过；该邮件还经过 Proton Mail、Microsoft 365 及下游企业邮件基础设施的转发与重新封装路径。这些跳转使溯源更复杂，但并未改变核心问题——认证帮助确认外层邮件可信，却无法保证其中的电话号码或交易上下文合法。Dell 邮件同样显示 Dell 相关基础设施的 DKIM 通过、order.dell.com 的 DMARC 通过。

信任边界为何失效

这些活动体现出与 Talos 先前“平台即代理（PaaP）滥用”研究相同的信任边界失效。在那些案例中，攻击者把恶意内容放入 SaaS 字段，由可信平台随后渲染进通知；此处同样的概念出现在商业基础设施——零售商的订单管道中。攻击者提供意图，而可信系统负责投递。

从防御视角看，发件人认证（SPF、DKIM、DMARC）是必要的，但远远不够。它们能回答“邮件是否来自预期的基础设施”，却无法回答交易是否真实、渲染出的字段在业务上是否合理，或者用户是否正被推向攻击者控制的行为。订单通知应被视为敏感内容：任何被反射进交易邮件的字段——收件人姓名、账单姓名、地址行、公司名、订单备注、支持字段或履约指令——若在渲染前未经验证，都可能成为投递载体。零售商与安全团队应将订单通知内容与账户历史、支付状态、物流上下文和已知支持渠道相关联；当意料之外的电话号码、URL、紧迫性话术或支持指令出现在不该出现的字段时，事务模板应拒绝或标记它们。

内容信任缺口：防御要务

在这些向量中，防御失败是一致的：可信基础设施正被当作“可信内容”的捷径。发件人认证仍然不可或缺，但它无法回答一个日益重要的问题——那个可信系统被指示携带的究竟是什么。

防御需要在投递链的多个环节做“内容感知”的校验。平台方应将任何被渲染进邮件模板的用户可控值视为不可信数据；用于姓名、地址、公司名、项目标题、订单备注或支持指令的字段，应在存储前与渲染前都做校验；当电话号码、URL、标记、换行或紧迫的支持话术出现在不该出现的字段时，应被拒绝或标记。安全网关应检查“完全渲染后的邮件”，而非仅检查发件人或模板，包括 HTML、文本、URL、重定向、附件、个性化字段与嵌套 MIME 内容；对交易邮件，还应评估其内容是否与产生它的工作流相符。

对投递状态通知（DSN），递归 MIME 检查尤为重要：网关应解析 DSN 容器，提取被退回的消息或消息片段，并对嵌套内容应用常规的钓鱼、恶意软件与 URL 分析。更广义的教训是：攻击者不仅在利用基础设施中的技术漏洞，也在利用业务流程中内建的假设。当合法系统把攻击者影响的数据渲染进可信通知，结果可能在通过认证检查的同时仍然投递恶意意图。防御方应将“发件人信任”与“内容信任”视为分离但互补的信号——外层包装能解释邮件从何处来，却无法证明负载安全。

常见问题（答案均取自上述人类原文章节）

攻击者是如何借合法订单通知邮件行骗的？

攻击者在 Staples、Dell 等零售商的合法订单确认/收讫邮件的物流或账单字段中植入攻击者控制的“客服热线”电话。邮件本身通过 DKIM 对齐、DMARC 校验，外观可信，但字段中的电话是攻击者诱导受害者打电话、进入后续诈骗（支付操纵、凭据窃取、远程协助欺诈）的入口。Talos 在两个活动中共观察到约 1,400 封此类邮件。

为什么这些钓鱼邮件能通过 DKIM/DMARC 认证？

因为恶意内容并非伪造发件人身份，而是被注入到合法订单工作流渲染出的邮件正文中，出现在本应填写收货/账单信息的字段。发件基础设施确实是 Staples/Dell 的，因此 DKIM 对齐、DMARC 通过。认证只证明“邮件来自预期的基础设施”，并不证明“交易真实”或“电话/交易上下文合法”。

此类攻击的根本原因是什么？

平台隐性信任了来自不可信来源、进入其系统的数据，并将这些数据回显到高信誉的自动化通知邮件中。订单通知、注册流程、投递报告等任意被反射进邮件模板的用户可控字段（姓名、地址、公司名、订单备注、支持字段等），若渲染前未做校验，都可能成为投递载体。

邮件安全网关应如何防御此类内容信任缺口？

安全网关应检查“完全渲染后的邮件”而不仅仅是发件人或模板，包括 HTML、文本、URL、重定向、附件、个性化字段与嵌套 MIME 内容；对交易邮件应评估其内容是否与产生它的工作流相符。对投递状态通知（DSN）应做递归 MIME 检查，解析被退回的消息或片段并对其中的嵌套内容应用常规钓鱼/恶意软件/URL 分析。