已经按伪造的邮件指令把款打出去了，最初几个小时应该做什么？

绝大多数安全事件的正确顺序是「先取证、再处置」。商务邮件诈骗（BEC）是少数例外之一，因为它存在一个由金融系统清算流程决定的硬时间窗：资金一旦完成后续转移，追回难度会急剧上升。

所以处置结构应当是两条线并行，而不是串行：

• 资金线（最高优先级）：联系付款银行请求止付或撤回、向执法机构报案、联系收款行。
• 技术线（同时进行）：判定攻击形态、保全证据、检查是否存在持续性访问。

这两条线必须由不同的人同时推进。常见的失败是安全团队先花时间把技术细节查清楚再报给财务，等财务联系银行时窗口已经过去了。技术上的完整结论对追回资金没有帮助，速度才有。

预案里应当预先写好：谁有权在无需层层审批的情况下直接联系银行。这是前面「预授权」原则最典型的应用场景。

1. 立即联系付款银行。说明这是一笔基于伪造指令的付款，请求止付、撤回或冻结。要走银行的紧急处置渠道而不是普通客服排队——这个渠道应当事前从客户经理处取得并记录在预案中。
2. 向执法机关报案。国内按属地要求向公安机关报案；涉及跨境资金时，FBI IC3 互联网犯罪投诉中心 提供了面向公众的举报入口，其运作机制包括与金融机构协作开展资金拦截协助。报案要与联系银行同时进行，不要先后。
3. 准备好银行与执法机关需要的材料。付款凭证、收款方信息、触发付款的原始邮件、以及事件发生的时间序列。这些材料应当由技术线同步准备，让资金线的人不必等待。
4. 核查是否还有在途或已排期的付款。这一条极其重要且经常被漏：攻击者通常不会只发一次指令。要立即冻结与该对话相关的全部待付事项，并复核近期已变更收款信息的所有供应商。
5. 联系收款方与真实的对方公司。用邮件之外的、事先已知的联系方式——不要用邮件里给出的任何号码或地址。对方公司很可能也已被入侵，或者对此事完全不知情。

这个判断决定了后续处置的走向，且必须尽快做出。两种形态的处置完全不同：

纯外部仿冒——攻击者从外部构造邮件，没有进入任何内部系统。指纹包括：

• 发件域是相似域（视觉上接近的注册域）而非本域或对方真实域；
• 或者显示名与真实姓名一致但实际地址是免费邮箱；
• 认证结果显示未通过对齐（参见 RFC 7489 与本站关于 DMARC 分诊的说明）；
• 邮件不在原有对话线程中，或者线程是被伪造重建的。

账号接管——本方或对方的真实邮箱已被控制。指纹包括：

• 邮件从真实域发出、DKIM 签名有效且对齐（RFC 6376）；
• 邮件确实出现在真实的历史对话线程中，引用内容准确；
• 存在异常登录记录、异常应用授权；
• 存在可疑的邮箱规则——这是最强的单一指纹。

邮箱规则必须优先检查，因为它是攻击者维持隐蔽的核心手段：把特定关键词（如汇款、发票、账号）的邮件自动移入不常看的文件夹或直接删除，使真实的对话方无法察觉。检查范围要覆盖本方所有相关人员的邮箱，而不只是直接经手人。同时要检查转发规则、委托权限与已授权的应用。

如果判定为账号接管，则进入账号接管处置流程：吊销全部会话与令牌、清理规则、重置凭据。注意仅重置密码不足以驱逐攻击者——已签发的令牌与已建立的长连接可能独立于口令继续有效。

虽然资金线优先，但证据保全不能因此被跳过——它只是不应该阻塞资金线。按 RFC 3227 的易失性顺序，优先固化那些会被处置动作覆盖的东西：

1. 邮箱规则的当前状态。这是最易失的：一旦重置账号或用户自行清理，规则就没了。先截取或导出完整规则列表，再删除规则。
2. 登录与授权审计记录。时间、源地址、客户端类型、认证方式。注意这类记录通常有自己的留存期，且可能比邮件日志短。
3. 触发付款的原始邮件及其完整信头。符合 RFC 5322 的原始形态，包含 Received 链与 Authentication-Results（RFC 7601）。不要用转发的方式取样本。
4. 整条对话线程。BEC 往往经过多轮铺垫，单看最后一封无法还原手法，也无法判断攻击者从何时开始在场。
5. 相关人员的发件箱与已删除项。用于判断是否有以本方名义发出的其他指令。

每一份证据都要记录提取时间、提取人与摘要值。银行与执法机关后续可能需要这些材料，格式的完整性直接影响它们的可用性。

BEC 事件的通报有其特殊性，因为它同时涉及资金损失、可能的账号失陷、以及外部合作方。建议的顺序与范围：

• 内部：财务负责人、法务、管理层。管理层要在第一时间知情，因为后续可能涉及对外披露、保险索赔与法律行动的决策。
• 对方公司：如果判定对方账号可能已被接管，必须通过带外渠道告知对方安全负责人。不要只通知业务对接人——如果对接人的邮箱就是被接管的那个，通知等于送信给攻击者。
• 其他潜在受影响方：如果攻击者已在本方邮箱中潜伏，那么本方与其他合作伙伴的往来同样可能被用于下一次诈骗。应当主动提醒近期有资金往来的对象核验最近的账号变更请求。
• 员工范围内的通告：侧重于「如果你近期收到过要求变更收款账号的邮件，无论是否已处理，请上报」。措辞要明确不追究已经上当者的责任，否则拿不到最关键的信息。

英国 NCSC《Phishing attacks: defending your organisation》指南集 在组织防护建议中反复强调建立无责上报文化的重要性，这一点在 BEC 场景下尤为关键，因为经手人往往因为自责或畏惧而延迟上报——而延迟直接等于资金追回概率的下降。

BEC 之所以难防，是因为它攻击的是流程而不是系统。技术手段能减少伪造的可行性，但真正的兜底在流程侧：

1. 付款前的带外核验，且核验方式必须是事前约定的。核心原则是：绝不使用来自本封邮件的任何联系方式进行核验。要用通讯录里既有的、事前确认过的号码。这一条看起来简单，但它是所有控制中收益最高的一条。
2. 收款账号变更走独立流程。变更供应商银行账号应当是一个有独立审批、双人复核、且需要带外确认的流程，而不是一封邮件通知就能完成的操作。攻击者的整个剧本都建立在这个流程薄弱的假设上。
3. 大额付款的双人授权。并且两人要能独立看到原始指令，而不是一人转述。
4. 把「紧急 + 保密 + 变更账号」识别为固定的风险组合。这三个要素同时出现时，无论邮件看起来多真实，都必须触发核验流程。把它训练成条件反射，比训练用户识别钓鱼特征更有效，因为前者不依赖用户的技术判断力。
5. 收紧本域 DMARC 策略（RFC 7489），并建立相似域监测。前者压缩精确冒用的空间，后者应对相似域注册。但要清醒地认识到：这两项都无法防御「真实账号被接管后发出的真实邮件」，而那正是最难识别的一类。
6. 把本次事件的时间线写成培训材料。真实发生在本组织的案例，其说服力远高于任何通用教材。