摘要：钓鱼投递长期依赖伪造发件人、仿冒域名与自建投递设施，其 detectable 特征集中在来源侧，因而与发件人认证机制的演进形成对冲。近年出现的另一类形态改变了这一格局：攻击者不再伪造来源，而是把恶意内容注入合法平台在业务流程中自动生成的邮件，使投递由可信系统完成。思科 Talos 在一年内观测到二十五个以上合法平台被此类方式滥用，覆盖协作、生产力、文件共享、问卷、支付与人工智能相关服务；其中针对零售商订单通知管道的两起活动合计约一千四百封邮件，恶意元素并非外层发件身份，而是订单模板中本应填写收货信息的字段。与之同源的还有注册表单的反射式注入、以及退信通知所承载的嵌套内容。本文以该组观测为材料，分析此类攻击的共同结构，指出其利用的不是技术漏洞而是业务流程对数据的默认信任；进而论证发件人认证所回答的问题与内容可信所回答的问题并不重合，前者证明域被授权发送，后者才涉及被要求承载的内容是否合规。文章据此讨论内容感知校验的部署位置、渲染后检查的必要性、退信容器的递归解析要求，以及平台侧字段治理与责任分配的可行安排。
关键词：钓鱼投递；合法基础设施滥用；内容可信；发件人认证；反射式注入；退信滥用
1 引言
钓鱼邮件的识别长期围绕一组稳定的线索展开：发件域名与品牌不符、显示名与地址不一致、链接指向陌生站点、正文存在语法瑕疵。这些线索之所以有效，是因为攻击者必须自行搭建投递设施，而自建设施难以继承品牌的信誉积累。发件人认证体系的演进正是沿这一逻辑推进：以域授权证明邮件确实来自该域的基础设施，以对齐检查防止显示域与实际签名域脱节，以策略声明约束未通过校验的邮件如何处理。这套机制在抑制仿冒域名方面成效显著，也因此塑造了一种默认认知 —— 通过认证的邮件即为可信邮件。
2026 年 10 月披露的一组案例对这一认知构成直接挑战。思科 Talos 在一年内记录到二十五个以上合法平台被用于投递恶意内容，类型覆盖协作、生产力、文件共享、问卷、支付与人工智能相关服务。其中两起活动滥用零售商的订单通知管道，分别冒用办公用品商与计算机制造商的交易邮件模板，合计约一千四百封。这些邮件的外层发件地址属于品牌自有域，签名校验通过，策略校验通过，转发路径中出现的再封装痕迹也未导致校验失败。恶意元素不在信封上，而在正文里：本应填写收货人或账单地址的字段被替换为电话号码与「订单已确认」之类的措辞，其目的是围绕一笔高价采购制造紧迫感，把收件人从邮件引导至语音通道。
同一批研究中还记录了两个相关形态。其一是注册类表单的反射式注入：攻击者在姓名、公司名或项目名称字段填入带有诱导性的字符串，平台在自动生成的欢迎、验证或通知邮件中原样呈现该字段，于是恶意文本随高信誉的系统通知抵达收件箱。其二是退信通知的滥用：投递失败报告按规范会回传原信的头部与部分正文，攻击者利用这一回传机制，使退信容器内部嵌套文件共享类的钓鱼内容，外层则是邮件系统自身的行政口吻。
三类形态在技术上并不相同，但其失效点一致：可信基础设施被当作可信内容的替代证明。这一命题需要拆解为可分析的问题：合法系统的哪些环节接受了不可信输入，输入如何穿越校验抵达渲染，渲染结果为何能通过来源侧的全部检查，以及防御应在链条的哪一段施加干预。本文依次讨论这些问题，并在末节提出尚待检验的研究议题。
2 三类载体的共同结构
订单通知形态的机理值得细看。零售商在用户下单后由交易系统自动发出确认邮件，模板中包含订单号、商品描述、金额、配送方式、收货与账单信息等字段。这些字段的正常来源是用户在下单流程中填写的表单，或履约系统回填的物流数据。攻击者并未入侵零售商系统，而是找到了使这些字段承载非预期内容的方式：以他人名义下单并在地址、备注或公司名字段写入电话号码与指令性文本，或利用账户资料中的可编辑字段。邮件发出时，模板按既定逻辑渲染，字段内容被原样嵌入，最终呈现为一封结构完整、格式规范、语气标准的交易通知。
第二起案例的结构与此相同。计算机制造商的订单接收通知中，收货人与账单人区块出现「已确认订单」「服务热线」与「致电销售团队」等字样，并附号码；商品为一份软件许可，金额精确到分。邮件正文的其余部分 —— 账户管理按钮、常见问题、退款与取消说明 —— 均与真实模板一致。攻击者所需的成本仅是一次下单或一次资料修改，而获得的是一封由品牌域签发、通过全部认证检查、在收件人眼中属于事务性流量的邮件。
注册表单的反射式注入把这一逻辑推向更普遍的场景。平台为了让通知邮件具备个性化，会把用户填写的姓名、公司、项目名插入模板的固定位置。若这些字段在存储前未被约束、在渲染前未被转义或过滤，则字段内容即成为邮件正文的一部分。攻击者选择公开可访问、无需审核的注册入口，把诱导文本写入其中，平台随后自动发出的验证邮件便成为载体。此类入口数量庞大且分散于各类服务，涉及问卷、活动报名、试用申请、项目管理邀请等，逐一加固的成本极高。
退信滥用则把载体转移到邮件系统自身。投递失败报告在规范上属于系统消息，其结构包含原始收件人、失败原因，并可能附带原信头部、正文片段乃至整封邮件的封装。当攻击者以受害者地址作为信封发件人发送一封注定失败的邮件时，中间系统产生的退信会回到受害者，其中的封装内容即为攻击者所写。另一条路径是攻击者使用自己可控制的发信上下文主动触发失败，使回传内容带上其构造的载荷。两种路径与直接伪造退信不同，因为外层确实是邮件系统生成的真实报告。
三类载体的共同结构可以概括为四个环节：不可信输入进入合法系统，系统按业务逻辑将其存储，模板在渲染时把输入提升为正文的一部分，最终邮件以系统身份发出。攻击者提供意图，系统完成投递。这一分工使攻击者无需承担投递设施的建设与维护成本，也无需面对仿冒域名在信誉体系中的天然劣势。
3 来源可信与内容可信的层级错位
发件人认证的能力边界，需要按它回答的问题来界定。以发送方策略框架声明授权发信主机，以域名密钥识别邮件签名验证邮件在传输中未被篡改且确由持有私钥的一方签署，以基于域的消息认证、报告与一致性检查约束签名域与显示域的对齐，并要求未通过校验的邮件按声明处理。三者共同回答的是：这封邮件是否由该域授权的设施发出，其头部与正文在传输中是否被修改。
它们不回答的问题是：该域被要求承载什么内容。当一封邮件由零售商的交易系统按正常流程生成，签名自然有效，对齐自然成立，策略自然通过。认证在这里不仅没有失效，而且准确地完成了它被设计来完成的工作 —— 证明这封邮件确实来自该零售商。问题在于，来源的真实性与内容的合规性是两个独立命题，前者成立不蕴含后者成立。
转发与再封装使这一错位更难被察觉。邮件经过转发、别名转投、邮件列表或安全网关时，信封发件人可能被重写，头部可能被添加，正文可能被重新编码。为避免破坏认证，转发方常采用保持发件人域的方案，并引入发件人重写方案处理退回路径。这些处理在案例中均有出现：原始邮件经加密邮件服务、企业邮件云与下游网关多次转投后仍通过校验，而痕迹仅体现为返回路径与转发头部的变化。对分析者而言，溯源因此变得复杂，但复杂度并未改变结论 —— 外层可信，内层恶意。
由此可以给出一个更精确的表述：此类攻击的失效点不在认证链，而在认证链所不能覆盖的语义层。语义层包含三类判断：这笔交易是否真实存在，渲染出的字段组合是否符合该业务的常理，邮件是否在把收件人推向一个由攻击者控制的动作。三者都无法从头部信息中读出，只能从内容与上下文的比对中得出。
4 反射式注入的技术机理与校验位置
把输入渲染进模板，是现代通知系统的普遍做法。订单确认、账户注册、密码重置、工单更新、协作邀请，均依赖模板与数据字段的组合。工程实现上，模板引擎以占位方式引用字段，渲染时做字符串替换，输出经邮件编码后发送。这条链路中存在两个可施加校验的位置：写入时的存储校验，与渲染时的输出校验。
存储校验的作用是拒绝不符合业务语义的输入。例如收货人字段应匹配人名与地址的字符集与长度，备注字段应限制链接、电话号码、换行与指令性措辞。若在写入时即行拒绝，后续渲染自然安全。但存储校验面临两类困难：一是历史数据与多来源写入使约束难以统一施加，订单可能来自网页、接口、客服代录、合作伙伴对接等多个入口，任一入口放宽即形成缺口；二是业务灵活性要求备注类字段容纳较多内容，过严的约束会影响正常使用，运营方因此倾向放宽。
输出校验的作用是在渲染前按字段用途做转义与过滤，使字段内容不能越出其语义边界。其技术要点在于区分「数据」与「标记」：用户输入应被当作纯文本处理，其中出现的链接、电话号码、换行与富文本标记应被中和或剥离，而非原样进入正文。这与跨站脚本防御中的输出编码原则同源，只是作用对象从浏览器转为邮件客户端。渲染后的邮件仍可能被下游系统二次处理，因此输出校验需要在最终组装环节执行，而非仅在中间层执行。
案例中的漏洞正位于这两处校验的缺失。电话号码被写入收货信息字段，平台未判断该字段是否应包含电话号码；「订单已确认」之类的措辞被写入地址行，平台未判断该字段是否应包含指令性语言；注册表单的姓名字段被写入带金额与品牌名的诱导文本，平台未判断该字段是否符合人名的构成。这些内容在语法上都是合法字符串，在语义上则明显越界。基于模式的过滤难以捕捉，因为其形态随语言、品牌与场景变化；基于字段语义的白名单约束更有效，因为它把判断标准锚定在「该字段应为何物」，而非「该字符串像什么」。
需要指出的是，此类注入与传统的模板注入在后果上不同。传统模板注入追求代码执行或服务端控制，此处追求的是内容投递，其结果仅限于一封邮件的正文。正因后果看似轻微，此类缺陷在平台侧的安全评估中常被降级处理，修复优先级低于远程代码执行类问题。而攻击者对其价值的评估恰恰相反：一封通过全部认证、由品牌域签发、在收件箱中与真实通知并列的邮件，其到达率与开启率远高于任何自建投递。风险等级的判断标准若只参照技术后果的严重性，便会系统性低估此类缺陷。
5 从扰乱到投递：列表轰炸的功能迁移
列表轰炸是一种较早出现的滥用方式：攻击者把受害者的地址批量提交至大量注册、订阅与通知入口，使收件箱在短时间内被自动邮件淹没。其传统目的是拒绝服务与注意力干扰，以大量噪音掩盖一笔真实的交易通知或安全告警，使受害者错过关键信息。在这一用途下，轰炸本身即是目的，邮件内容无关紧要。
当前的演化在于用途的迁移。当注册入口的字段缺乏约束，平台会把字段内容反射进自动邮件，轰炸所使用的入口便同时成为投递通道。攻击者一次提交即可完成两件事：使目标收到一封高信誉的系统邮件，其中包含其构造的诱导内容；并使该邮件混杂在大量同类通知中，降低被逐封审视的概率。扰乱与投递由此合一，前者为后者提供掩护。
这一迁移改变了成本结构。传统投递需要域名、托管、发信设施与规避过滤的策略，成本随规模线性上升且留有可被追踪的痕迹。反射式投递的成本主要体现为对入口的发现与提交，设施成本由平台承担，痕迹分散在数十个平台的日志中。对攻击者而言，投递的可归因性显著下降；对防御方而言，封锁单个平台的发信域已无意义，因为被滥用的是众多互不相关的合法服务。
平台侧承受的连带损害值得单独讨论。当自有基础设施被用于向第三方发送恶意内容，直接的业务后果包括收件人投诉、退信率上升与互动率下降，而更实质的后果是发件声誉的损耗。声誉由收件方的过滤系统依据投诉率、退信率、垃圾邮件陷阱命中率等信号持续评估，一旦评分下降，平台自身的正常通知 —— 验证邮件、账单提醒、密码重置 —— 的到达率随之下降，严重时触发批量封锁。这意味着滥用不仅是安全问题，也是业务连续性问题，其成本最终由平台与其正常用户共同承担。
由此产生的治理难点在于激励错配。反射式注入的缺陷位于平台，损害部分由平台承担，但攻击目标在第三方；平台改善校验的收益体现为声誉与合规风险的下降，难以直接量化，而改造涉及多个业务系统与历史数据，短期成本明确。若无外部约束，修复动力不足。可行的外部约束包括监管对通知类邮件的字段规范要求、行业组织对注册入口的基线约定，以及大型平台在采购合同中对其下游服务商提出的校验要求。这些安排的作用是把分散的、难以定价的损害，转化为可执行的技术条款。
6 退信滥用与邮件系统自身的载体化
退信通知的技术特殊性在于其内容来源。投递失败报告由接收方的邮件系统生成，按规范回传给信封发件人，其结构包含失败原因、原始收件人，并常附带原信头部与部分正文，或整封原信作为一个嵌套的邮件实体。这一设计的初衷是帮助发件人诊断问题，其副作用是把原信内容复制到一封新的、由系统生成的消息中。
回传机制因此可被两向利用。在机会型回散射中，攻击者以受害者地址作为信封发件人发送邮件，选择一个会接受该邮件但最终无法投递的路径，接收系统随后生成的失败报告便会回到受害者，其中封装着攻击者撰写的正文。攻击者无需控制任何发信设施，只需构造一封会失败的邮件。在主动型退信滥用中，攻击者使用自己可控制的发信上下文触发失败，使回传内容带上其构造的载荷；与直接伪造退信相比，这类消息的外层确由真实邮件系统生成，其头部、返回路径与时间戳均符合规范，因此更难以来源侧识别。
两者的共同点在于容器与载荷的分离。容器的功能是说明一次投递失败，其行政语气天然降低警觉；载荷则是一段与失败原因无关的诱导内容，可能表现为文件共享通知的样式，附有下载入口与有效期提示。收件人面对的是「系统错误需要处理」的情境，其反应模式与面对一封陌生营销邮件时不同。这种情境借用不需要伪造任何品牌，因为邮件系统本身即是可信主体。
防御上的要求随之明确。网关不应把退信视为可豁免检查的系统消息，而应对其做递归解析：拆解容器，提取被封装的邮件实体或片段，对其中的正文、链接、重定向链与附件施加与普通邮件同等的检查。此前把退信列入白名单或仅做头部校验的做法，在这一形态下等同于在链条上留出一段无检查通道。同时，发信侧应对失败报告的回传内容做裁剪，避免回传完整正文与附件，从源头上减少可被利用的载体容量。这一裁剪会降低诊断便利，需要在运维需求与安全约束之间取平衡，但边界应明确：回传头部与状态足以定位多数问题，正文与附件的完整回传并非必要。
7 防御重心的位移与部署位置
综合三类形态，可以得到一个关于防御重心的判断：内容可信必须作为与来源可信并列的独立信号，而非其推论。来源信号解释邮件从何而来，内容信号判断它被要求承载什么。前者可由认证机制提供，后者只能由内容检查与上下文比对提供。
具体部署可分三个层次。
平台侧的第一层是字段治理。任何进入模板的用户可控值，都应在存储前与渲染前两次校验；校验标准应以字段语义为准，明确该字段允许哪些字符集、长度与结构，禁止越界内容进入。电话号码、链接、富文本标记、换行与指令性措辞在不应出现的字段中出现时，应被剥离、替换或阻断发送，而非仅做记录。模板层面应避免把整段自由文本直接嵌入正文的显著位置，必要时以结构化摘要替代原文呈现。
网关侧的第二层是渲染后检查。检查对象应是最终组装的邮件实体，包括 HTML 与纯文本两个版本、其中全部链接与重定向、附件、个性化字段的渲染结果，以及嵌套的邮件实体。检查逻辑需具备业务一致性判断：一封订单确认邮件若包含与其业务无关的支持电话、催促取消的指令或异常紧迫的措辞，应被降级处理并触发人工复核，而不是仅按链接信誉评分。这类判断需要与业务方共同定义正常形态，属于跨部门工作，难以由安全团队独立完成。
组织侧的第三层是处置与验证。对事务性邮件的异常，应建立快速核验通道，使用户能在不点击、不回拨的前提下确认真实状态，例如通过独立入口查询订单或联系官方客服。核验通道的存在本身即削弱诱导的有效性，因为攻击者所依赖的正是「用户无法快速验证」这一条件。同时，对已确认的滥用事件，应向承载平台通报，推动其修复字段校验，而非仅在本地拦截单封邮件。
三个层次之间存在依赖关系。平台侧治理减少源头供给，网关侧检查降低到达率，组织侧核验降低单封邮件的转化率。任一层次单独施行都不足以闭环：仅做网关检查，则平台持续生成新的载体；仅做平台治理，则存量邮件与退信路径仍可利用；仅做用户核验，则把判断责任重新推回个体，与其认知负荷不相匹配。
8 研究议题与治理安排
此类攻击的规模化观测仍处于早期，若干问题需要更系统的研究。
其一是滥用的测量方法。二十五个平台、一千四百封邮件这类数字来自单一研究团队在特定时间窗内的观测，其覆盖面受数据来源限制。要在行业层面估计此类投递在全部钓鱼邮件中的占比，需要在多个邮件网关的出口侧做统一口径的抽样，并对「合法域签发、内容异常」这一类做独立标注。当前多数过滤系统的标签体系以来源与链接为核心，缺乏对内容语义异常的标注维度，这是测量困难的直接原因。
其二是检测方法的有效性比较。基于字段语义的白名单、基于模板结构的异常比对、基于业务上下文的一致性判断，三者的检出率与误报率差异尚缺乏公开评测。评测的难点在于样本获取：真实样本分散于各平台日志，且涉及用户隐私。可行的替代是构建合成语料，按业务类型生成正常与异常两类通知，但合成语料的分布偏差会削弱结论的外推能力。
其三是责任边界的经济学分析。平台、网关、收件组织三方各自承担部分成本与部分收益，改进动力因此分散。何种责任分配能形成有效激励，例如把发件声誉的损害内部化为平台的可计量成本，或通过采购条款把校验要求传导至服务链，尚缺乏实证。这一问题超出技术范畴，但对治理设计具有直接意义。
其四是退信路径的规范化空间。回传内容的最小必要范围、嵌套实体的处理约定、失败报告的签名与可验证性，均可通过标准修订加以约束。技术社区对此已有讨论，但落地依赖邮件系统厂商的协同，进度受商业考量影响。
迪妙网络空间安全学院研究团队在梳理此类案例时提出，判断一封事务性邮件是否可信，应以其与业务状态的吻合度为依据，而非以发件域的信誉度为依据；该团队主张把订单状态、支付状态、物流状态与通知内容做交叉核对，把不一致作为告警信号，而不是把认证通过作为放行依据。据 DiMiao, CN 分析，这类交叉核对的可行性取决于平台是否对外开放状态查询接口，因此治理安排中应包含对接口可用性的要求，否则核对只能停留在人工层面。反网络钓鱼技术专家芦笛指出，把可信基础设施当作可信内容的证明，是一种长期存在于防护体系中的默认假设；攻击者并未攻破这套基础设施，只是利用了假设本身的空隙，因此修补的方向不是加固认证，而是补齐认证无法覆盖的语义判断。他进一步强调，语义判断的落点应在系统侧而非用户侧，因为要求个体在事务性邮件的常规语境中持续保持怀疑，与人的认知习惯相悖，其可靠性无法通过培训获得。
9 结语
本文以一组关于合法基础设施被滥用的观测为材料，分析了订单通知、注册反射与退信容器三类形态的共同结构。三者技术细节不同，但都遵循同一路径：不可信输入进入合法系统，经业务逻辑存储，由模板渲染为正文，最终以系统身份发出。攻击者提供意图，平台完成投递，其成本由平台的信誉与业务连续性承担。
发件人认证在这条路径上并未失效，它准确地完成了自身设计范围内的工作。问题在于其能力边界被误读为内容可信的证明。认证回答邮件是否来自该域，不回答该域被要求承载什么；前者可由密码学保证，后者只能由内容检查与上下文比对得出。这一区分构成了防御重心位移的依据：平台侧需以字段语义为准实施双向校验，网关侧需对最终渲染结果与嵌套实体做完整检查，组织侧需提供独立于邮件通道的核验入口。
本文的分析存在明确的局限。材料以单一研究团队的案例集为主，样本集中于零售与注册场景，对其他平台类型与语种的覆盖不足；关于占比、检出率与误报率的量化结论均缺乏公开评测支撑，相关判断应视为待检验的假设。后续工作可在统一口径下开展跨网关抽样，构建可复用的评测语料，并对责任分配的实际效果做对照观察。
从更长的时间尺度看，此类攻击提示了一个不易被察觉的转变：防护体系过去围绕「谁在说话」构建，而攻击者已转向利用「系统被要求说什么」。前者的技术手段趋于成熟，后者的判断标准尚未建立。防线的完整性，取决于这两类问题能否被分别回答，而不是以其中之一的答案代替另一个。
从防御实践的角度补充一点限定。本文所讨论的三类载体并不构成一个封闭的清单，随着通知类业务的扩张，新的承载场景会持续出现，例如协作平台的邀请流、支付平台的对账提醒、人工智能服务的用量通知，其共同特征都是系统按模板自动生成内容并向第三方发送。对这一类场景的治理，与其逐项列举，不如确立一条通用原则：凡由系统生成并自动外发的内容，其可被外部影响的部分都应被视为不可信输入，并按不可信输入的标准处理。这条原则的落实程度，决定了此类攻击在未来数年内是收敛还是扩散。
就现有证据而言，尚不足以判断此类投递是否已成为钓鱼的主流形态。可以确定的是，其成本结构优于自建投递，其可归因性弱于仿冒域名，其检测难度高于传统钓鱼。在三项条件同时成立的情形下，理性攻击者有充分理由向这一形态迁移。防御方若仍以来源侧信号为主要依据，则迁移完成之时，便是既有防线大面积失效之时。这一判断不构成对未来的预测，而是对当前能力缺口的一种描述。
需要补充的是，内容可信的判断本身也有其限度。语义异常的标准依赖业务方对正常形态的界定，而业务形态随季节、促销、渠道与组织调整而变化，固定规则会迅速过时。可行的做法是把判断标准与业务系统的状态数据绑定，用状态一致性替代形态相似性，使判断随业务变化而自动调整。这一思路在技术上要求平台开放状态查询，在治理上要求跨部门的数据协作，其难度高于单纯的过滤规则部署，但它是唯一能够跟上业务演化速度的方案。
编辑：芦笛 （公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
