用Claude识别商务邮件钓鱼攻击

简而言之： Claude可以像一名受过训练的分析师那样读一封可疑邮件——验证结果、发件人历史、文字本身，以及链接真正指向哪里——并在几秒内给出带推理过程的结构化判定。最合适的落点是一个"可疑邮件上报"邮箱，专门分诊员工标记出来的邮件。它是邮件安全网关的补充，绝不是替代品：没有沙箱、没有隔离区、也没有投递后的撤回能力。

大多数中小企业对付钓鱼邮件其实只有一道防线：Microsoft 365或Google Workspace默认过滤掉的那些，加上恰好在读这封信的人的判断力。这套组合对付批量垃圾邮件和已知恶意域名是有效的。但对真正会造成损失的那类邮件，它就明显吃力了——一封简短、合理、不带任何附件或恶意链接的邮件，来自收件人认识的人，要求做一件听起来很像周二日常的事。本文讲的是一件用Claude API花一个下午就能搭出来、而且确实有用的窄事情，以及它做不到的那一大堆事情。

到底什么能绕过标准垃圾邮件过滤

商业邮件欺诈（BEC）根本没有可检测的东西。 没有附件、没有恶意链接、没有畸形报文头——只有一段文字。"你在座位上吗？截止时间之前需要你处理一笔供应商付款。"一个为查找恶意软件而调优的过滤器什么也查不到，因为那里除了意图之外什么都没有。

显示名伪造能通过身份验证。 SPF、DKIM和DMARC验证的是发件域名，不是邮件客户端里显示的那个人名。攻击者用一个自己合法拥有的域名发信，三项校验全部通过，照样可以把贵司财务总监的全名放进发件人栏。而在手机上，域名往往根本不显示。

被入侵的合法账户能通过全部检查。 当真实供应商的邮箱被接管，邮件就是从真实域名发出的，通过验证，而且常常出现在一条真实的既有会话里。基于信誉的过滤在结构上对此是盲的——因为那份信誉是真的。

仿冒域名是现注册、只用一次的。 一个48小时前注册的域名还没有坏名声，因为它压根还没有任何名声。等它进了黑名单，这一波攻击早就结束了。

会话劫持借用的是你自己的上下文。 攻击者把真实对话复制过来后在其中回复，引用着真实的早前消息。所有本来会让收件人放心的东西——主题行、下面的历史记录、熟悉的名字——都是攻击本身提供的。

这五种情况的共同点是：信号是上下文层面的，而不是技术层面的。语言模型并不是一个更好的垃圾邮件过滤器，但它确实擅长这五种情况所需要的那种判断。

AI钓鱼检查实际是怎么运作的

该喂给模型什么——报文头、发件人历史、正文和链接落点

判定的质量，完全取决于你在调用API之前组装了什么证据，而这些证据里有很大一部分应该用确定性代码采集，而不是交给模型去评判。自己解析Authentication-Results报文头，把SPF、DKIM、DMARC的结果作为客观事实传进去。提取真正的From域名，用代码把它与你的通讯录和历史往来做比对——"这个显示名匹配一位内部高管，但这个域名从来没给我们发过信"，这条事实比任何篇幅的文风分析都值钱。

把每个链接都解析开。取href而不是锚文本，在不执行任何内容的前提下跟随跳转，把最终落点连同可注册域名、以及（如果你有查询能力的话）它的注册年龄一起传进去。把纯文本正文、主题、收件人的岗位角色，以及这封信是否回复了一条邮箱里真实存在的会话，都给模型。然后要求结构化输出——一份JSON判定，包含风险等级、发现的具体指标、明确检查过但不存在的指标，以及一段非技术同事能读懂的解释。要明确指示它：无法确定的一律标为未知，不要猜；一个自信的错误判定比一处诚实的空缺糟糕得多。

两种搭法：上报邮箱分诊机器人 vs 串行网关

这件事有两种形态，而其中只有一种适合自己动手做。串行版本坐在邮件流里，投递前检查所有邮件，并执行拦截或隔离。自己搭这个，意味着你要为全公司的邮件投递负责——每一次超时、限流、模型故障和误报，都会变成丢失或延误的业务邮件，而你还得再搭出缓冲队列、故障转移，以及凌晨两点放行隔离邮件的办法。那是一个产品，不是一个脚本，而且成熟的产品早就有了。

分诊版本坐在邮件流旁边。员工转发或上报一封可疑邮件，机器人分析后给出答复。什么都不拦截，什么都不延误，最糟的失败模式无非是回复慢了点。而且它针对的恰恰是那些已经绕过了其他一切防线的邮件，残余风险正好就在那儿。从这里开始，而且除非有特定理由，就留在这里。

一套可落地的做法：可疑邮件上报邮箱分诊流程

给员工一个明确动作。 一个共享邮箱，比如phishing@yourcompany.com，如果用得上再加上Outlook或Gmail自带的上报按钮，以及一条指令：觉得不对劲就上报，你会收到答复。上报必须比自己拿主意更省事。

要拿到原件，而不是转发件。 普通转发会毁掉你需要的报文头。让员工以附件形式上报，或者使用平台自带的上报机制，或者通过Microsoft Graph、Gmail API按消息ID把邮件拉取出来，保证原始源码完整。

先做富化，再去提问。 把确定性检查跑一遍——验证结果、对照历史发件记录做首次联系判断、链接解析、域名年龄、显示名是否与通讯录条目撞名——然后交给Claude一份结构化的证据包，而不是一大坨文本。

几分钟内用大白话回复上报人。 "这极可能是一次付款改道诈骗。显示名与贵司财务总监一致，但域名yourc0mpany-finance.com是9天前注册的，此前从未与我们联系过。请勿回复。IT已收到通知。"正是这样的回复，会让员工愿意上报下一封。

按严重程度分流，高风险端必须留人。 低风险判定可以带着解释自行闭环。任何评为高风险的，都应当直接呼叫IT，而模型在那里的职责是分诊和取证，不是拍板。

全量留痕，每周复盘。 把证据包、判定结果，以及事后证实的真相都存下来。每周花二十分钟复核分歧，对提示词的改进速度会超过任何前期设计，而且它能给你一个真实的误报率和漏报率，而不是一种感觉。

把已确认的攻击回灌进你的控制措施。 一个确认的恶意域名应当进入租户级封禁名单；如果还有其他人被作为目标，就该触发一次跨邮箱搜索。分析的价值取决于你拿它做了什么。

AI辅助分诊 vs 托管邮件安全网关

识别BEC与社会工程文本 — AI分诊在这里确实强，而这也正是网关历史上最薄弱的缺口。现代网关已经加入了自己的AI冒充检测，所以这是一项正在收窄的优势，而不是永久优势。
投递前拦截 — 只有网关做得到。分诊机器人是在邮件已经躺进收件箱之后才作答的，这意味着风险窗口等于员工决定上报所花的时间。
附件与恶意链接 — 网关完胜。在沙箱里引爆一个文件、把URL重写成点击时再校验一次，这些是工程能力，不是推理能力。模型读一个文件名，学不到这个文件会做什么。
投递后清除 — 只有网关或邮件平台能伸进每一个邮箱，把一封事后被判定为恶意的邮件抽走。你用API搭出来的东西做不到这件事。
向非技术用户解释判定 — AI分诊明显胜出。网关产出的是隔离通知；模型产出的是收件人真能看懂的一段话，这对员工安全意识的价值超过大多数培训模块。
成本与投入 — 分诊机器人是几天的集成工作，每次分析花几分钱。托管网关是一笔持续订阅和一段供应商关系。两者定价方式不同，是因为它们根本不是同一种控制措施。
失效时会发生什么 — 分诊机器人坏了，只是沉默且恼人。自建的串行过滤器坏了，全公司邮件停摆。这种不对称，正是选择分诊形态的全部理由。

为什么它是补充而不是替代

没有沙箱。 模型无法在隔离环境里打开附件、看它究竟做了什么。如果答案需要引爆才能得到，那这个答案就拿不到。

没有撤回能力。 当一封邮件在投递一小时后被确认为恶意，把它从四十个邮箱里删掉是平台的功能。你的机器人可以建议这么做，但执行不了。

没有队列。 你的集成挂掉时，既没有任何保护，也没有任何缓冲。网关生来就是要能扣住邮件的；脚本不是。

模型自己也会被社会工程。 藏在邮件正文里的提示词注入——写给分析系统而不是写给人看的指令——是针对这套设计的真实且显而易见的攻击。把邮件内容当作不可信输入，与你的指令明确隔离开，绝不让模型输出自行触发动作，并且要假定迟早有人会来试。

一个自信的漏报比没有工具更糟。 如果员工学会了"机器人说没问题"，他们就会停止仔细阅读。要让不确定性在回复里可见，绝不能让低风险判定读起来像一张免责保证书。

把这件事做对：邮件数据治理、API密钥，以及何时该让IT介入

被上报的邮件是企业里最敏感的数据之一。一封钓鱼上报常常连带着一张真实发票、一份真实合同或一段真实对话，把它转给第三方API是一个带有合同与合规分量的处理决策——取决于你的人员和数据所在地，可能落在香港《个人资料（私隐）条例》、新加坡PDPA或中国《个人信息保护法》之下。有意识地决定哪些内容会离开租户、是否使用零留存的API条款，并且在客户的安全问卷问到之前，就先把答案写下来。

把凭据权限收窄。邮箱集成需要的是对一个共享邮箱的读取权限，而不是全组织范围的邮件读取权限；而Microsoft Graph里的应用程序权限默认就是宽的——请用应用访问策略把它限定到那一个邮箱。把Anthropic API密钥放进密钥管理系统而不是自动化流程的配置文件里，按计划轮换，并对费用异常告警：一张意料之外的账单，往往是某个环节在死循环或被滥用的第一个可见信号。

这正是托管伙伴体现价值的地方。Brocent的托管邮件安全服务覆盖这套流程旁边的网关层——AI辅助的冒充与BEC检测、附件沙箱，以及任何自研脚本都做不到的投递后处置。我们的AI+支持服务负责搭建和调优分诊集成本身，托管IT支持则在上线后接管凭据、监控与事件响应。如果你的短板在员工行为而不是工具，我们那篇讲亚洲钓鱼演练项目的指南覆盖的是同一个问题的培训那一侧。Brocent自2007年在北京创立以来一直在亚洲提供托管IT与安全服务，总部位于新加坡，并自2016年起设有香港办公室。

常见问题

AI能替代我们的邮件安全网关吗？

不能，而且值得把原因说直白。网关在投递前拦截、在沙箱里引爆附件、重写URL使其在点击时再次校验，并且能在事后把一封邮件从所有邮箱中移除。基于API的分析器一样都做不到。它是在一套体系之上叠加了上下文判断力——它不会变成那套体系。

把可疑邮件转给AI，本身会不会带来风险？

它带来的是一个你必须有意识回答的数据处理问题。这些内容往往很敏感，而且正在离开你的租户。核对服务商的数据留存与训练条款，把这个决定记录在案；如果你受PDPO、PDPA或《个人信息保护法》约束，请确认这次传输被你用于其他云处理的那个合规依据所覆盖。

漏报该怎么处理？

默认它一定会发生，并把回复设计成"低风险判定永远读不出保证书的味道"。给每一次分析连同结果一起留痕，每周复核分歧，把漏报率当成一个真实数字来跟踪。如果员工把"看起来没问题"当成可以点击的许可，那这个工具是让情况变糟了，而不是变好。

附件和恶意链接怎么办？

这是最清楚的一条边界。模型能读到的是文件名和链接的可见文字，而这几乎说明不了什么。请在分析之前用代码解析链接落点，把附件检查交给有真正沙箱的网关。绝不要让模型对附件的评估，顶替对它的实际扫描。

一封邮件能攻击正在读它的AI吗？

能——提示词注入就是针对这套设计的那个显而易见的攻击。攻击者可以在正文里写下针对你的分析器的指令。请把不可信内容明确定界，绝不让模型输出在没有人工或确定性规则介入的情况下触发动作，并在信任它之前先用注入尝试测试自己的提示词。

它应该盯哪个邮箱？

一个共享上报邮箱，而且只盯这一个。这样权限范围小、数据足迹小，而且瞄准的正是那些已经越过其他所有控制措施的邮件——那恰恰是额外判断力最值得花钱的地方。

从哪里开始

先做只读版本：拉取被上报的邮件，跑一遍确定性富化，拿到判定，然后把它发到一个团队之外无人可见的IT私有频道。用真实上报跑两周，并给每一条打分。这两周里你对自身钓鱼风险敞口的了解，会超过任何一份厂商报告，而且你会知道这些回复是否好到可以发给员工。到那时再打开自动回复。如果你更希望把网关、分诊层和事件流程作为一整件事来建设，欢迎联系我们。