上个月做跨部门钓鱼演练复盘维护核心系统的一位同事看完数据后问我这次演练里为什么动态口令都输对了账号还是被判了“沦陷”这个问题问到了今年的痛点上。以前判断一个账号是否安全最核心的指标就是是否完成了多因素认证MFA。但BlackForce、GhostFrame这类AI钓鱼套件在威胁情报圈子里已经热了大半年它们把“绕过MFA”做成了标准功能攻击者不再需要猜密码也不再需要硬解动态口令而是在用户登录的同时实时中转请求、截获会话。换句话说传统防御体系里那道“MFA就是安全”的保险正在快速失效。这篇文章我想从防守方视角把这些套件的运作逻辑拆开聊清楚也整理一下我们现在还能落地的防御动作。1. 威胁风向变了黑产把钓鱼做成了SaaS生意1.1 先认清AI钓鱼套件这个新物种传统钓鱼邮件是典型的“广撒网、低转化”。攻击者批量注册域名、套用通用模板赌的是总有几个粗心的员工点进去。这种玩法在URL信誉库和邮件网关面前已经很吃力了因为静态模板的指纹太好识别域名也往往活不过24小时。AI钓鱼套件完全是另一套逻辑。它像一个“自动化的钓鱼即服务”平台攻击者只需要选定目标企业系统会自动根据目标的邮箱后缀、官网配色、常用系统生成高度仿真的钓鱼门户。更关键的是这个门户不是死页面而是和真实系统实时连通。我从捕获到的样本里观察过一个典型场景受害者收到的邮件是一封和官方通知排版几乎一致的IT系统升级提醒点开链接后弹出的登录页连SSL证书都正常底层却在和真实的办公系统保持会话。受害者从头到尾没有见过任何“假页面”他输入的所有信息都在他不知情的情况下被中转。这种模式的变化是根本性的。以前钓鱼工具是“做一张假的登录页等着受害者把密码送上来”现在是“搭一座通往真实站点的桥受害者自己把身份信息送过去”。攻击者的角色从一个伪造者变成了一个旁观者。1.2 BlackForce、GhostFrame情报圈里的“当红代号”BlackForce和GhostFrame这两个代号在过去的半年里频繁出现在威胁情报共享群和几份公开的研究报告里。需要说明的是要准确统计它们造成的受害规模还比较难但有几个共同特征已经非常明显订阅制售卖、更新频率高、强调MFA绕过能力。从公开报告和我们自己捕获到的样本看BlackForce更偏向页面生成和分发它能在极短时间内生成高仿真的钓鱼门户GhostFrame则侧重会话维持与数据提取负责在攻击链路中段做流量的双向转发。两者经常被组合使用分工类似“做壳”和“做芯”。这次事件里提到的四大工具除了BlackForce和GhostFrame另外两个的公开信息更少但从交流中得知它们的功能边界差异不大核心能力都集中在绕过MFA。最值得警惕的是地下社群里甚至已经出现了渠道分销和区域代理的模式说明这类工具的运营已经相当成熟。它们不再是某个黑客独自编写的脚本而是一套有人维护、有人推广、按版本迭代的商业化产品。1.3 为什么攻击者集体转向AI套件原因并不复杂性价比。钓鱼攻击链路里最贵的环节是人——写社工程序、写代码、维护服务器。AI套件把这部分全部标准化了按订阅收费折合几百美元一个月对攻击者来说像买软件服务一样方便对黑产平台来说又是稳定的现金牛。经济模型一成立整个产业链就会迅速膨胀。还有一个推动力来自攻防对抗的升级。传统钓鱼邮件被安全产品识别得太熟URL信誉库的拦截率越来越高攻击者需要更定制化的内容来提高转化率。AI生成的门户页面每一次都是动态的通信域名往往托管在被攻破的合法站点或公共云服务上信誉分天然偏高这就让检测变得异常困难。勒索软件组织、商业间谍活动以及以窃取云账号为生的黑产团伙都在用类似框架。之前他们还要雇人手动搭建钓鱼环境现在只要输入目标域名几分钟内就能生成一套可用的攻击链。攻击门槛降低的直接结果就是受害企业范围从“被选中”变成了“被路过”。2. 绕过MFA的底层逻辑攻击者抢的是“会话”不是“密码”2.1 核心手法中间人实时中继先纠正一个常见误区这类套件不是破解了MFA的算法没有暴力破解也没有利用什么漏洞。它玩的是身份链路里的中间位置。我习惯用一个类比来解释想象你委托一位“熟人”去银行柜台替你办业务。银行要验证你的身份这位“熟人”便在电话里向你转述问题你回答了他把答案转述给银行。整个过程银行的验证流程是完整跑通的但你不知道的是站在中间的那个人把你说过的每一个字都记了下来包括最终拿到的那张业务回执。实际攻击里也是这个逻辑。受害者的浏览器访问攻击者准备的登录门户门户后端主动和真正的目标站点建立连接。受害者输入账号、密码攻击者原样转发给真实站点真实站点返回MFA挑战攻击者再把挑战原样渲染给受害者受害者在钓鱼页面上输入的动态口令同样被实时转发。认证一旦成功真实站点发放的会话Cookie也会经过攻击者的服务器攻击者顺手就复制了一份。这不是什么高深魔法但技术门槛曾经不低。过去要做中间人攻击需要自己处理双向流量、证书、会话保持而现在套件把这些全部打包攻击者只需要填一个目标域名。这也是为什么我会强调MFA在链路里的验证环节被“架空”了。2.2 真正的战利品会话Cookie而不是密码很多人以为攻击者想要的是密码其实密码只是第一步。AI套件真正想拿的是认证完成后服务器签发的会话凭证通常是一个Cookie或者Token。攻击者可以直接把它导入自己的浏览器以受害者的身份进入系统全程不需要重新登录也不需要再触发一次MFA挑战。这也就解释了为什么很多企业排查时会看到日志显示“同一账号从两个完全不同的IP和浏览器同时发起访问”——一个是受害者本人另一个是拿着会话凭证的攻击者。会话凭证的有效期通常从几十分钟到几天不等如果攻击者捞到的是“记住此设备”这类长效凭证那风险窗口还会被拉得更长。有些套件还会顺手利用单点登录的特性把受害者在该身份体系下已经登录过的其他系统也一并接管。密码可以改但一个有效的会话凭证几乎等同于临时的身份本身在它过期或失效之前攻击者可以随时“扮演”受害者。2.3 浏览器之内的浏览器把“真登录页”搬进假页面的障眼法新一代套件还有一个很常见的交互设计在钓鱼页面里嵌入一个iframe让真正的登录页在一个小窗口里“嵌套”显示。受害者看到的是官方页面所以很安心地输入全部信息。实际上这个假页面和真页面之间刚好坐着攻击者的中继服务。我们做模拟演练时曾经尝试让技术同事不看报告的情况下识别这种页面大多数人会被页面上的官方logo和加载动效骗过去。真正能第一时间发现的反而是一些对登录页面细节异常敏感的非技术岗位员工——他们虽然不知道什么叫会话劫持但直觉告诉他们“今天这个页面好像不太一样”。这个现象让我意识到单纯依赖员工“识别假页面”已经走到了尽头。我们需要把识别任务从“视觉上找不同”变成“流程上找异常”比如登录后出现的一个额外的验证步骤或一个从未见过的审批请求。2.4 辅助手段MFA疲劳轰炸、邮件转发规则绕过MFA不只是靠中继。在不能拿到动态口令的情况下攻击者会启动疲劳轰炸短时间内给受害者推送大量MFA审批请求直到受害者不胜其烦随手点了“允许”。这种手法不需要抢Cookie只需要用户一次误操作。除了在登录环节动手脚攻击者进入邮箱后还会增加邮件转发规则把包含关键词的邮件自动转发到攻击者控制的外部邮箱。这是最隐蔽的动作之一很多受害者甚至在事件结束后都不知道自己的邮件一直在被实时外传。所以防御端的检查清单里除了登录日志邮件转发规则的审计也一样重要。还有一个容易被忽略的点攻击者会在登录异常触发风控时利用已经掌握的会话凭证来自动批准自家的高风险操作比如修改绑定手机、添加新的认证方式。这让安全团队从日志里看到的操作者身份始终是“合法用户”进一步加大了溯源难度。3. 传统防御为什么失灵三个被高估的“安全幻觉”3.1 邮件网关和URL信誉库拦不住定制化页面邮件网关擅长拦截已知恶意域名和附件但AI套件生成的钓鱼域名生命周期极短页面内容完全动态信誉库还没收录就已经完成了一轮攻击。更麻烦的是套件会选择托管在被攻破站点或者公共云服务上的域名这类域名天然有较好的信誉评分。我们团队做过一次抽样在捕获到的钓鱼链接里有相当一部分域名的Whois信息还带着正规公司的注册信息。这说明攻击者也学会了“用合法身份掩盖非法行为”安全设备如果只看声誉库基本等于睁一只眼闭一只眼。最大的盲区在于邮件本身变得太“干净”了。正文里没有附件链接指向一个看起来完全正常的网站没有宏文档没有可执行的exe传统的沙箱和附件检测在整条链路里根本找不到落点因为真正的战场发生在浏览器与真实站点之间。3.2 安全意识培训的“认知上限”很多单位的安全意识培训还在教员工“不要点击陌生链接、注意核对网址拼写”。但这些建议在AI克隆页面面前已经不够用了。攻击者能克隆出和真实系统几乎一样的登录界面Logo、颜色、字体都是自动抓取生成普通员工很难在几秒钟内识别出区别。我不建议把责任全部推给员工。更合理的设计是让安全意识培训回到“识别异常行为的信号”上比如异常登录验证、突然出现的审批请求、非工作时间的登录提醒。这些流程性信号比让员工辨认网址拼写可靠得多。培训内容也应该从“你可能会遇到什么”转向“你遇到后应该怎么做”例如如何快速上报、如何通过安全渠道验证邮件真实性。员工要变成防线的一部分而不是只看网址的检查器。3.3 “有MFA就安全”这个认知误区前几年我们习惯把MFA当成万能药。数据泄露事件发生后首先问“有没有开MFA”甚至审计合规也只盯着MFA覆盖率。但在中间人攻击的语境下MFA的验证入口已经被攻击者“安排”了受害者只是和一个伪装的前台在对话。你输入了正确的口令并不代表登录请求一定来自你本人。这里不是唱衰MFA。MFA依然是低成本高效率的安全控制但不能是唯一控制。真正能防住这套攻击的是把认证、会话、设备、行为、访问策略作为一个整体来思考。只看某一环就会被绕过去。现实中我还见过一种情况企业确实开了MFA但默认允许“记住设备90天”导致攻击者只要偷到一次有效会话就能持续使用90天。这个配置让MFA形同虚设而且用户根本感知不到问题所在因为他们看到的始终是“已经登录成功”。4. 咱们现在能落地的防御五件马上能做的事4.1 把“有没有MFA”改成“这次登录合规吗”条件访问策略是第一步。不要只看是否完成MFA而要看登录的上下文是否合规设备是否受管理、地理位置是否异常、IP信誉是否正常、登录频率是否异常。现在主流身份平台都支持类似的策略比如Entra ID里的条件访问、Okta里的策略引擎。实操建议是先开报告模式或者日志模式跑一两个星期看看会不会误伤正常用户再切强制模式。不要第一天就全公司强制阻断否则你的电话会被打爆。报告模式的意义在于你能看见如果启用了这条策略有多少合法用户会被影响再根据误杀率调整规则。条件访问策略的经典配置示例要求登录设备必须为合规设备、对不受管理设备只开放沙箱访问、对异常地理位置直接拒绝、对管理员账号启用更严格的会话策略。这些配置不一定每个企业都执行相同标准但起点就是把“合规”的门槛立起来。4.2 给登录日志加一个“异常信号”监控我建议重点盯几个相对普适的信号短时间内异地登录、同一账号同时在线会话数量异常、会话在登录完成几分钟内出现新的IP访问、UserAgent和设备信息发生跳变。这些信号不一定单独说明什么但组合出现时一定要及时介入。监控维度异常信号建议动作登录位置同一账号短时间内跨越非临近地理区域标记风险触发二次验证或人工复核登录频率同一账号连续多次MFA挑战失败临时锁定账号通知用户会话行为认证成功后的Cookie在不同IP/UserAgent使用强制会话失效检查是否已有横向动作邮箱规则新增转发规则特别是转发到外部域自动告警并通知安全团队应用授权新增OAuth应用授权且权限范围包含邮件读取接入审批流程禁止自主授权这些监控不需要一开始就上AI分析用SIEM规则就能覆盖大部分场景。关键是别把日志存在那边不管要有人或者有自动化任务定期去看。我在实际执行中有一个经验宁可少设告警把告警的误报率压到最低也不要一次性上一堆规则导致告警疲劳。三条精准规则的效果远大于二十条噪音规则。4.3 设计一个“一键应急”剧本并真的演练一次很多企业有制度、有流程但没有演练。你可以把应急流程拆成几个动作确认事件后强制下线该用户所有会话、重置账号凭据、审计邮箱转发规则、检查OAuth应用授权、保留日志用于取证。这个剧本一定要在非生产环境或者指定测试账号走一遍。比如强制下线指令库里是有现成命令的但命令的权限够不够、执行链路通不通、会不会把用户正常会话也一并踢掉平时不演练根本不知道。我见过不少团队事件发生了才在文档里临时找命令白白多花了几个小时。建议每年至少做一次钓鱼事件应急演练模拟从“用户点击钓鱼链接”到“安全团队介入处理”的完整流程。演练结束后要复盘时间线记录每一步耗时再针对性优化。4.4 别忘了最基础的账号健康度治理攻击者要成功完成中间人攻击前提是知道你的账号名和一定的目标人信息。这提醒我们要定期做账号健康度检查清理僵尸账号、禁用离职员工的会话、检查高风险账号是否开启了强认证。账号基数越小攻击面越小。我在多个客户的日志里都看到过长期不用的服务账号突然有了新登录记录。这类账号往往权限很大又没有绑定MFA是最容易被利用的资源。账号健康度治理听起来很基础但在AI钓鱼套件面前它反而是成本最低、见效最快的防线。建议每季度做一次账号盘点把超过90天未登录的账号列为风险项要求负责人确认是否需要继续保留。对特权账号强制启用更强的认证策略和会话策略防止一波攻击直接打到核心系统。4.5 给管理层的优先级清单如果只能向管理层汇报一页纸我建议用这个表格优先级动作目标P0开启登录日志和会话日志的集中采集保证事件发生时有据可查P0上线条件访问策略先报告模式减少误伤逐步加严P1建立Cookie异常检测和会话强制下线能力发现异常后能快速止损P1邮件转发规则审计和异常告警防止邮箱被持续外传P2面向全员做“异常登录提示”场景演练提升员工对流程异常的敏感度P0说的是“能不能看见”P1说的是“能不能处置”P2说的是“人能不能配合”。这三个层次缺一不可但很多团队往往只做了P2结果员工识别不了安全团队也看不见。按这个表格去补优先级就不会偏。5. 已经被钓了怎么办事件排查与还原5.1 从日志里反推攻击链如果发生类似事件第一时间要拉三类日志身份认证日志、邮箱审计日志、终端登录日志。时间线从用户汇报可疑邮件或接到MFA异常提示的那一刻往前推3到6个小时。重点看在这段时间内有没有成功的MFA完成记录、有没有异常的登录来源。不要只看失败日志。攻击者在中继模式下通常会有一次成功的、“干净”的认证这个成功记录本身极为关键因为它能告诉我们攻击者拿到了哪些会话、后续从哪个源IP激活了会话。把这条链还原出来才算真正看清了攻击路径。有条件的话还需要确认受害者账号在事件后是否被用作跳板去访问了其他内部系统。尤其是多账号同时受到同一封钓鱼邮件影响时要立即按批次处理防止攻击者在内部横向移动。5.2 快速排查清单检测点检测方法处置建议登录IP与UserAgent登录日志筛选异常IP/UA组合强制下线会话并记录风险等级并发会话查同一账号最近24小时活跃会话要求用户确认所有已登录设备邮箱转发规则审计规则列表查外部转发地址删除异常规则并保留记录OAuth应用授权查企业应用授权列表中的第三方集成删除恶意应用授权吊销权限MFA审批记录查推送记录中的“允许”事件找出时间点比对口令下发时间Cookie异常使用查认证后的会话是否出现新IP立即强制会话失效评估影响范围把这些检查项跑一遍基本能判断账号是否已经被完全接管。如果发现攻击者已经修改了账号的安全信息比如换绑手机那就需要走身份恢复流程必要时联系平台支持人员介入。5.3 一次事件还原的常见时间线结合我们处理过的一个典型场景流程往往是这样的周五下午三点用户收到一封看起来来自HR系统的提醒邮件点击后跳转到克隆登录页输入了账号和MFA口令。四点左右攻击者利用偷到的会话Cookie以该用户身份登录了云管理后台创建了一个新的API密钥。周一上午安全团队从异常API调用告警中发现这个密钥顺藤摸瓜拉到登录日志才发现周五已经发生了钓鱼事件。这里的关键教训是攻击者往往不会马上利用窃取的会话而是等到几天后风头过去再动手。这就更考验日志的留存时长和回溯分析能力。建议日志至少保留90天条件允许的话延长到180天因为很多攻击事件的发现周期远超预期。从告警到溯源整个处置链路里最耗时间的往往不是技术分析而是确认“这个登录是不是用户本人操作”。所以我在内部推动了一件事给每个高风险账号设定动态验证机制凡是出现非常规上下文登录就自动生成一条待确认工单推送给用户用户只需要回一个“是”或“否”。这比事后翻日志高效得多。说回开头那位运维同事的问题动态口令都输对了为什么账号还是保不住因为攻击者抢走的是你的整段身份会话而不是几个字符。我在实际排查中的一个体会是AI钓鱼套件的迭代速度还会更快但防守方反而要回到最基础的事情上把每一次登录的上下文看明白把会话生命周期管起来把应急动作练到不用翻文档就能执行。这些事确实不够“炫酷”但至少能让我们在武器升级的攻防竞赛里站得住脚。