怎样系统排查邮箱里被植入的隐蔽转发规则与访问后门？

取得邮箱访问权之后，攻击者面临的第一个问题是「如何在口令被改掉之后还能继续拿到邮件」。邮箱规则给出了一个近乎完美的答案：它是邮箱系统的正常功能，运行在服务端，不依赖任何持续的连接或凭据，而且执行时不产生用户可见的痕迹。

更麻烦的是它的隐蔽性来源于产品设计本身：

• 规则通常在多个界面分散管理，某一个界面看不到全部规则。
• 规则名可以为空或使用不可见字符，在列表中难以察觉。
• 规则可以只对特定关键词生效，日常使用中完全不触发，只在涉及敏感话题时才动作。
• 规则可以把处理过的邮件移出收件箱并标记为已读，使受害者从未察觉。

RFC 5228 定义的 Sieve 语言直观地展示了这类能力的边界：redirect 动作把报文重新投递到另一个地址；discard 动作静默丢弃报文而不产生任何通知；fileinto 把报文归入指定邮箱；隐式保留（implicit keep）机制则决定在没有显式动作时报文是否仍进入默认邮箱。这些都是过滤语言的正常语义，问题不在语言，而在于「谁写下了这条规则」。

因此排查的目标不是「找出恶意语法」，而是「确认每一条规则都是用户本人有意创建的」。

这是最容易漏查的一组区别。服务器侧规则在邮件到达时由服务端执行，客户端不开机也生效；客户端侧规则存储在客户端配置中，只在该客户端运行时生效。二者的存储位置、管理界面、审计记录都不同。

1. 用管理员权限枚举服务器侧规则，而不是让用户自己在客户端里看。用户界面可能隐藏某些规则，管理侧枚举才能拿到完整列表。
2. 逐条核对每条规则的条件与动作。重点关注：动作中包含向外部地址转发或重定向的；动作中包含删除、永久删除、标记已读的；条件中包含财务、付款、发票、账号、密码、验证码等关键词的；条件中包含特定往来对象地址的。
3. 核对规则的创建与修改时间。与时间线中的「首次异常认证成功」比对。创建时间落在暴露窗口内的规则，无论看起来多正常，都要向用户逐条确认。
4. 检查客户端侧规则。如果攻击者曾在某台终端上配置过客户端，规则可能只存在于该终端。这一层的排查需要终端侧配合。
5. 注意规则的执行顺序与终止行为。RFC 5228 §3.2 定义了 stop 控制结构，它使脚本立即结束。一条排在前面并提前终止的规则，可以让后面所有的告警类规则都不执行——检查规则时必须看顺序，不能只看单条内容。

规则之外还有几条独立的通道，它们不在规则列表里，需要单独检查。

• 账户级自动转发。许多平台在规则之外还提供账户属性层面的转发设置，界面位置与规则完全分离。只查规则不查这一项，是最典型的漏查。同时确认转发是否保留副本——不保留副本的转发会让邮件直接消失。
• 邮箱委托与共享权限。攻击者可以把某个受控账号添加为代理人或授予完全访问权限。这条通道完全不依赖被害账号的口令，改密码对它无效。需要枚举邮箱的全部权限授予关系，包括「代表发送」与「作为其发送」这类容易被忽略的权限。
• 应用专用凭据与旧式认证凭据。为不支持现代认证的客户端签发的凭据独立于主口令。逐一列出并作废。
• 已授权的第三方应用。OAuth 授权是另一条独立通道，需要单独排查。
• 组织级邮件流规则与连接器。如果攻击者取得了管理员权限，可能在组织层面而非邮箱层面配置转发。这一层影响面最大，一旦忽略，个人邮箱清理得再干净也没有用。NSA 与 CISA 的多份公开公告都强调过对认证机制与租户级配置滥用的检测，这类租户级配置正是重点对象。

如果攻击者在你之前就把规则删了，或者规则在某次处置中被误删而未留记录，直接枚举是查不到的。这时要靠审计记录。

1. 检索规则相关的审计事件。主流平台的审计日志会记录邮箱规则的创建、修改与删除操作，包含操作时间、操作主体与来源地址。Microsoft Purview 的审计解决方案文档说明了可审计的活动类别与检索方式；Google Workspace 的管理审计与调查功能提供类似能力。先确认自己的租户是否已启用相应级别的审计——很多环境是在事件发生后才发现审计根本没开。
2. 比对配置快照。如果有定期导出的配置基线，直接做差异比对，效率远高于逐条人工核对。
3. 反向验证：看邮件去了哪里。如果规则记录缺失，可以从邮件流跟踪反推——某段时间内是否存在向某个外部地址的持续投递。这一路径能发现「规则已删但曾经生效」的情况，是配置侧证据缺失时的重要补充。
4. 检查 IMAP 侧的标志变化。RFC 9051 定义了 \Seen 等系统标志。大量邮件在用户未操作的时间段内被批量置为已读，是自动化处理留下的痕迹。

• 先导出，再删除。每一条被清理的规则都要先完整留档，包括条件、动作、创建时间与创建者。删掉之后再想复原它的内容，通常是做不到的。
• 对规则新增与转发变更设置告警。特别是「新增指向外部域的转发」这一类，应当做到近实时告警。这是投入产出比最高的一条检测规则。
• 按组织策略限制外部自动转发。多数平台支持在租户级别限制或阻断自动外发转发。若业务确有需要，采用白名单方式逐个批准，而不是全局放开。
• 把规则纳入定期审阅。参照 NIST SP 800-53 Rev. 5 中关于配置管理与账户管理的控制思路，把邮箱规则与委托权限当作配置项管理，定期复核并留下审阅记录。
• 清理后保持观察期。NIST SP 800-61 Rev. 3 的响应框架中，根除与恢复之后仍需持续监测。规则在清理后短期内重新出现，几乎可以确定攻击者仍有访问权，此时应当立即回到遏制阶段，而不是继续清理。
• 把排查项写成清单并固化。五个层面逐项打勾，避免依赖处置人员的记忆。漏查一层，整次处置的价值就大打折扣。