AI 让伪造变得廉价后，付款与账号变更该怎么核验？

所有有效核验都只做一件事——让确认信息经过一条攻击者无法控制的通道。判断一个核验动作是否有效，只需问：这条通道的联系方式从哪里来？

• 有效：来自内部主数据（人力系统、供应商主档、内部通讯录）中早于本次事件就已存在的联系方式。
• 无效：来自本封邮件的签名、来电显示、聊天工具中对方发来的号码、本次沟通中新提供的任何联系方式。

「早于本次事件已存在」是判定的核心。把这句话写进制度，比列举十条识别技巧更管用。

供应商收款账号变更是商务邮件欺诈最主要的落点。CISA Phishing Guidance: Stopping the Attack Cycle at Phase One 在防护建议中也强调需要以流程性控制配合技术控制。可执行的流程：

1. 只接受受控渠道提交：变更申请必须通过既定表单或供应商门户提交，不接受邮件正文或邮件附件作为唯一依据。
2. 带外电话核验：拨打主档中原有号码，与已登记的对接人确认；不接受对方回拨，不接受新号码。
3. 双人复核：发起人与核验人不得为同一人，核验记录（时间、拨打号码、接听人、确认内容）入档。
4. 冷静期与首笔限额：变更生效后设置观察期，首笔付款设置金额上限并单独复核。
5. 反向通知：通过主档中的原联系方式通知对方「你方账号已变更」。若变更系伪造，这一步会让真实供应商立刻发现——这是成本最低、效果最好的一步，却最常被省略。

熔断条件的价值在于不依赖当事人的判断力。满足任一条件即暂停并转入强化核验：

• 收款账号为首次出现，或与主档不一致。
• 收款方名称与合同主体不一致（含「代收」「关联公司」等说法）。
• 要求缩短付款时限，或强调错过的严重后果。
• 要求保密、要求不走常规审批、要求不要联系其他同事。
• 发件域与既往通信域存在细微差异，或 RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 校验未通过 / 未对齐。
• Reply-To 与 From 不同域。
• 请求在非工作时间、长假前后或对接人休假期间提出。

关键设计：熔断不设职级豁免。「这是老板要求的」不能作为跳过条件——正是这一豁免使攻击成立。

多数组织有流程，但攻击依然成功，原因几乎总是同一个：基层员工在面对高管加急要求时不敢坚持流程。这是组织问题，不是技术问题。

可操作的组织措施：

• 管理层公开背书：明确宣布「任何人要求跳过核验，都应当被拒绝，且拒绝者不承担责任」，并留下书面记录。
• 把核验设为系统强制项：审批系统中缺少核验记录则无法提交，让流程不依赖个人勇气。
• 提供标准话术：让员工有现成的、不冒犯的表达方式，例如「按公司规定我需要用主档号码回拨确认，大约两分钟」。有了话术，执行阻力显著下降。
• 把成功阻断的案例公开表扬，建立正向激励。

相当一部分账号变更欺诈并非外部伪造，而是供应商或本方邮箱已被控制，攻击者在真实邮件线程中接续。这种情况下发件域完全正常、历史通信完整，内容判据全部失效。

唯一有效的应对是在身份层：按 NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management 对认证强度的要求部署抗钓鱼的多因素认证，并对邮箱的自动转发规则变更、异常地理位置登录、异常客户端接入设置告警。邮箱规则被悄悄加上外发转发，是账号失陷最典型的痕迹。

1. 账号变更是否只能通过受控渠道提交。
2. 带外核验是否强制使用主档中既有联系方式，并有记录留档。
3. 是否执行反向通知。
4. 熔断条件是否写入制度且无职级豁免。
5. 审批系统是否把核验记录设为强制字段。
6. 邮箱转发规则变更是否有告警。
7. 是否做过含「高管施压」要素的桌面演练。