摘要
多因素认证（MFA）长期被企业视为抵御凭据窃取攻击的核心安全屏障，但 BigBear2.0 即服务化中间人钓鱼攻击事件证实，依靠可中继的短信、TOTP、推送通知类 MFA 手段，无法对抗敌手在链路层实施的会话劫持攻击。该攻击平台基于 Evilginx2 二次开发，通过敌手中间人（AiTM）代理架构完整中继身份认证全流程，即便用户完成全部多因素校验，攻击者依旧可以截获已认证会话 Cookie 实现账户接管，本次攻击事件波及 258 家机构，造成数千条云身份凭据泄露。本文以 BigBear2.0 攻击活动作为研究样本，拆解即服务化钓鱼工具的运作模式、技术实现细节、攻击全链路，剖析传统 MFA 机制在 AiTM 攻击场景下的固有短板，厘清 MFA 失效并非技术本身存在漏洞，而是认证方式可被中继转发带来的防护边界问题。反网络钓鱼技术专家芦笛指出，AiTM 类攻击正在消解大量企业的身份安全投入，仅依靠增加认证因子数量不足以抵御链路中继类攻击，企业需要重新校准身份安全防护基线。本文从攻击机理、攻击平台产业化特征、企业现有防御短板、事件应急处置流程、分层防御架构建设、人员安全意识迭代多个维度开展分析，构建适配云办公环境的综合防御框架。研究表明，抵御该类攻击不能局限于单纯增加认证环节，需要强制部署抗钓鱼认证手段，联动条件访问策略、会话管控、异常行为检测、人员安全教育形成闭环防护。本研究可为国内部署 Microsoft365 等云办公平台的机构处置同类中间人钓鱼威胁提供实践参考。
关键词：敌手中间人攻击；AiTM；BigBear2.0；多因素认证；会话劫持；钓鱼即服务
1 引言
云办公系统普及推动多因素认证在企业环境大规模落地，大量组织将开启 MFA 作为身份安全建设的核心指标，普遍认为只要启用双重或者多重身份校验，就能够抵御绝大多数钓鱼导致的账户失陷。但是钓鱼即服务（PhaaS）工具的产业化发展，降低了中间人钓鱼攻击的技术门槛，攻击者不需要深度掌握底层协议，就可以使用商品化攻击平台完成复杂的会话劫持攻击，BigBear2.0 攻击事件就是该类威胁的典型样本。
安全研究团队获取 BigBear2.0 攻击平台管理后台数据显示，该平台部署 42 台 VPS 节点专门针对 Microsoft365 开展攻击，累计采集 5137 条身份相关记录，覆盖超过 40 个国家的 3331 个独立受害者 IP，其中 258 家机构出现至少一例完整绕过 MFA 的账户入侵记录，攻击者拿到 4148 份有效会话 Cookie，完成 474 次完整 AiTM 会话劫持操作。值得关注的是，整个攻击流程不会破解密码，也不需要攻破 MFA 校验逻辑，只是作为代理中继全部用户与身份服务商之间的交互流量，受害者完整走完用户名输入、密码填写、MFA 确认全部流程，浏览器页面交互与官方登录页面几乎没有差异，用户主观感知不到攻击正在发生，完成全部校验之后，攻击者直接复用服务端下发的会话 Cookie 获取账户访问权限。
当前很多企业安全建设存在认知误区，把 MFA 当作身份安全的 “终极防线”，没有区分不同 MFA 方式是否具备抗中继能力。短信验证码、软件 TOTP、移动端推送确认这类传统多因素认证，生成的校验因子可以被中间人代理转发给身份服务商，在 AiTM 攻击场景下防护能力会直接失效；而 FIDO2/WebAuthn 安全密钥这类抗钓鱼认证机制，协议层面内置域名绑定校验，能够抵御中继攻击，但现实环境中很多企业仅将其作为可选方案，并未做强制部署，同时存量工具还会通过脚本手段尝试禁用硬件安全密钥调用接口，诱导用户回退至可被中继的 MFA 手段。
反网络钓鱼技术专家芦笛强调，当前企业在应对钓鱼威胁时容易陷入技术工具依赖，认为部署 MFA 就可以降低人员安全教育投入，BigBear2.0 事件充分证明，即便用户认真完成每一步身份校验，只要访问攻击者控制的代理站点，账户依旧会被劫持，技术防护与人员安全意识二者缺一不可。现有行业分析大多聚焦该事件技术细节披露，缺少从企业安全治理视角的系统性梳理。本文基于 BigBear2.0 攻击活动，梳理完整攻击链路，解析传统 MFA 的防护边界，分析商业化钓鱼即服务带来的安全挑战，从事后应急、技术管控、策略配置、人员能力、持续检测多个维度，搭建完整防御体系，为国内云身份系统安全防护提供可落地的思路。
2 BigBear2.0 攻击平台技术特征与完整攻击链路
2.1 BigBear2.0 平台背景与产业化属性
BigBear2.0 属于商业化钓鱼即服务平台，并非独立黑客的临时攻击工具，平台运营者对外出租攻击能力，下游多个攻击者可以接入平台，通过 Telegram 机器人实时获取窃取的密码、MFA 校验记录、会话 Cookie 等数据，整个平台采用多租户运营模式，攻击者不需要自行搭建代理环境、调试认证协议，只需要配置钓鱼域名，就可以针对 Microsoft365 身份体系发起 AiTM 攻击，技术门槛被大幅度降低。
该平台基于 Evilginx2 框架深度二次开发，定制专属的配置模板 “offy” 专门适配 Microsoft Entra ID OAuth 登录流程，区别于原版开源工具，BigBear2.0 增加三段自定义 JavaScript 注入逻辑，分别用于干扰 FIDO2/WebAuthn 硬件密钥调用、拦截微软反钓鱼遥测上报请求、自动勾选 “保持登录状态” 选项。干扰硬件密钥的脚本会重写浏览器 WebAuthn 相关接口，当用户准备调用安全密钥完成认证时，接口调用直接失败，浏览器不会弹出硬件密钥交互弹窗，迫使用户只能选择短信、TOTP、推送通知这类可以被代理中继的认证方式，以此提升攻击成功率。拦截遥测代码会丢弃浏览器发往微软检测端点的网络请求，阻止平台向服务商上报异常访问信号，降低攻击被云端安全系统识别概率；自动勾选保持登录选项则会延长会话 Cookie 有效期，为攻击者提供更长时间窗口利用劫持到的会话访问企业云资源。
平台同时支持住宅代理，攻击者可以使用与受害者所在地区相匹配的 IP 开展后续会话复用操作，传统基于 IP 地理位置的条件访问策略会被绕过，很多企业依靠异地登录告警识别异常访问的检测手段有效性被削弱。整套攻击基础设施由分布不同服务商的 42 台 VPS 节点组成，攻击域名模仿微软官方登录页面，搭配 HTTPS 证书，从浏览器地址栏标识到页面 UI 均高度仿真，普通用户很难通过页面外观区分真伪。
2.2 BigBear2.0 完整 AiTM 攻击执行流程
BigBear2.0 攻击的核心逻辑不是伪造静态登录表单窃取账号密码，而是搭建反向代理作为中间人，完整转发受害者浏览器与微软官方身份服务器之间全部双向流量，攻击过程分为五个连续阶段，整个过程中微软身份服务器收到的全部请求均格式合规，MFA 校验流程会正常完成，服务端视角无法区分流量来自真实用户浏览器还是攻击者代理。
第一阶段，攻击者通过钓鱼邮件、即时通讯消息分发伪装链接，诱导受害者访问攻击者控制的钓鱼域名。域名页面由 BigBear2.0 代理实时渲染，页面内容全部来自微软真实登录门户，并非本地复制的静态页面。
第二阶段，受害者在代理页面输入账号、密码，流量首先抵达 BigBear2.0 代理服务器，代理将账号密码原样转发至微软官方身份接口，同时本地留存明文账号密码记录。服务器返回下一步身份校验页面，代理再将页面传回受害者浏览器展示。如果用户浏览器尝试调用 FIDO2 硬件密钥，页面注入脚本会阻断接口调用，页面提示硬件密钥不可用，引导用户切换至短信验证码、APP 推送等备选 MFA 方式。
第三阶段，受害者按照提示完成 MFA 校验，输入验证码或者在移动端确认登录请求，MFA 校验数据同样经过代理中继提交给微软服务端，微软完成全部身份校验之后，向浏览器下发已经通过身份认证的会话 Cookie、刷新令牌等身份凭证。
第四阶段，代理服务器在把响应内容回传给受害者浏览器之前，截留会话 Cookie 与刷新令牌，保存到 BigBear2.0 后台，交付给下游攻击者；代理向受害者浏览器返回伪造错误提示，例如提示 “登录出现临时故障，请关闭页面重试”，受害者通常会关闭页面，不会意识到账户会话凭证已经被窃取。
第五阶段，攻击者拿到窃取到的会话 Cookie，在自己的浏览器环境重放该 Cookie，直接接入 Microsoft365 服务，此时不需要账号密码，也不需要再次执行 MFA 校验，依托已经完成认证的会话访问邮件、OneDrive 文档、SharePoint 共享资源，还能够依托单点登录体系访问企业内其他绑定 EntraID 的业务系统。会话 Cookie 有效时长由企业安全策略决定，如果勾选保持登录，会话有效期可以达到数天，攻击者拥有充足时间完成数据窃取、邮件转发、创建恶意邮件转发规则、新增账户权限等恶意行为。
需要厘清关键技术边界，BigBear2.0 没有破解 MFA 加密算法，也不存在绕过服务端 MFA 校验逻辑的漏洞，攻击成立的前提是用户在攻击者代理页面完整完成全部身份校验步骤。如果企业强制用户仅允许使用 FIDO2/WebAuthn 抗钓鱼安全密钥，即便攻击者通过脚本尝试禁用浏览器接口，硬件密钥协议本身会校验目标域名，代理钓鱼域名与官方域名不一致，认证流程直接失败，该攻击链路无法生效，这也是抵御 AiTM 钓鱼攻击的核心技术分界点。
2.3 攻击造成的企业安全危害层级
该攻击造成的损害具备递进特征，第一层是账户访问权限丢失，攻击者借助劫持会话直接接管受害者云账户，读取企业内部邮件往来、业务文档、客户资料，还可以检索历史邮件寻找财务凭证、内部方案、敏感项目资料。第二层是横向拓展风险，Microsoft365 单点登录机制下，一旦 EntraID 会话被劫持，攻击者可跳转访问大量企业已经完成身份打通的第三方 SaaS 业务系统，扩大受攻击面。第三层是持久化风险，攻击者可以在被攻陷账户内配置邮件自动转发规则、创建应用权限授权、新增备用登录凭据，即便企业后续修改账户密码，只要刷新令牌没有被全部吊销，攻击者依旧可以持续获取访问权限。
现实应急处置中大量企业仅执行重置账户密码操作，但是没有吊销全部会话与刷新令牌，攻击者持有的 Cookie 与令牌依旧有效，会出现改完密码攻击者仍然可以访问账户的现象，这也是 AiTM 攻击事件处置过程中非常容易遗漏的环节。当被攻陷账户属于管理员、财务、核心业务岗位人员，攻击者可以进一步修改租户安全配置，创建后门账户，给企业带来持续性的安全风险。
3 BigBear2.0 事件折射出企业身份安全体系的核心短板
3.1 对 MFA 防护边界认知存在系统性偏差
大量企业安全管理人员形成固有认知，认为只要开启 MFA，钓鱼攻击窃取的账号密码就不再具备利用价值，忽视 AiTM 中间人攻击的场景。传统静态表单钓鱼，攻击者拿到用户名密码之后，因为 MFA 保护无法完成登录；但 AiTM 攻击场景，攻击者不使用窃取密码直接登录，而是诱导用户在攻击代理链路内部完成全部 MFA 校验，再截取认证之后生成的会话凭证。此时 MFA 校验本身是成功的，但是认证产出的会话凭证被攻击者截获复用。
不同 MFA 技术的安全能力并不等同，但是很多企业的身份安全策略没有做区分，将短信验证码、推送通知、TOTP 软件令牌、FIDO2 硬件密钥同等看待，全部归类为 MFA 手段，允许用户自由选择认证方式。短信、推送、TOTP 属于可中继认证方法，AiTM 攻击中可以被代理转发完成校验；FIDO2/WebAuthn 属于抗钓鱼认证，协议内置域名校验逻辑，无法被 AiTM 代理中继。不少企业只是把硬件密钥作为可选增强手段，并未强制高风险账户只允许使用抗钓鱼认证方式，给 BigBear2.0 这类攻击平台留下操作空间。
3.2 会话生命周期管控机制普遍存在缺失
多数企业身份安全建设把重心放在登录环节的身份校验，却缺少登录成功之后会话生命周期的管控能力。会话 Cookie、刷新令牌一旦下发，企业对会话后续复用场景约束不足。很多组织没有启用持续访问评估能力，无法在账户发生异常事件时远程让已经下发的会话立刻失效。当 AiTM 攻击发生，攻击者拿到合法会话凭证之后，云端系统很难区分访问流量来自合法用户设备还是攻击者设备。
很多企业依赖 IP 地理位置作为核心异常判断依据，但是 BigBear2.0 支持住宅代理，攻击者可以使用与受害者常用登录 IP 归属地接近的网络地址发起访问，基于地理位置的告警会被绕过。同时，大量机构缺少定期审计活跃会话的运维流程，管理员很少批量查看租户内全部账户的在线会话，发生会话劫持之后，异常会话很难被及时发现，攻击者可以长时间潜伏在系统内部开展操作。
3.3 对钓鱼即服务产业化威胁准备不足
BigBear2.0 事件凸显钓鱼攻击已经完成工具化、服务化转型，攻击能力作为商品对外售卖，不再只有高水平攻击者才能够开展 AiTM 中间人钓鱼。攻击者不需要理解 OAuth 协议细节，不需要调试 Evilginx 代理框架，只需要采购服务，配置钓鱼邮件模板、钓鱼域名就能够发起攻击，攻击技术门槛大幅度降低，会导致 AiTM 中间人钓鱼攻击的爆发频次持续上升。
但很多企业现有安全防御体系的建设思路依旧针对传统静态表单钓鱼，安全设备、邮件网关检测规则更多针对静态仿冒登录页面，针对 AiTM 反向代理类钓鱼的识别能力有限。AiTM 代理页面实时回源官方站点，页面内容动态生成，传统基于页面特征、静态样本库的检测手段识别难度很高，邮件安全网关能够拦截部分钓鱼邮件，但是无法做到百分之百拦截，一旦有钓鱼邮件抵达员工邮箱，就会带来攻击风险。
供应链层面，部分企业依赖第三方外包人员、外部合作方访问企业 Microsoft365 租户，外部人员账户同样配置传统 MFA，这类账户也会成为 AiTM 钓鱼攻击的突破口，企业往往缺少针对外包、第三方身份的专项管控策略。
3.4 人员安全意识培训适配不了新型钓鱼场景
反网络钓鱼技术专家芦笛指出，传统钓鱼意识培训重点教会员工辨别虚假登录页面、识别伪造域名，但是 BigBear2.0 这类 AiTM 钓鱼页面是代理回源的真实官方页面，页面内容、HTTPS 证书标识全部具备，员工依靠页面外观很难识别风险。
现有企业的钓鱼演练素材大多还是静态伪造表单钓鱼，缺少 AiTM 中间人钓鱼场景的演练案例，员工接受的安全教育没有覆盖这类新型攻击。员工已经形成思维定势：只要页面显示 HTTPS，页面和官方网站长得一致，就判定页面安全，这种认知在 AiTM 攻击场景下会造成误判。即便安全意识较好、平时能够识别普通钓鱼邮件的员工，依旧有可能落入 AiTM 钓鱼圈套。员工即便完整完成 MFA 确认，账户依旧会失陷，这和员工过去接收的安全认知存在冲突，也提升了安全教育落地的难度。
4 BigBear2.0 攻击事件的应急处置流程
当企业确认或者怀疑遭遇 BigBear2.0 同类 AiTM 中间人钓鱼攻击，仅修改账户密码不足以消除风险，攻击者持有的会话 Cookie、刷新令牌不会随密码重置自动失效，必须执行完整闭环处置流程。
第一，定位受影响账户范围。调取 EntraID 登录日志，排查异常登录事件，重点关注来自陌生客户端、异常会话、OAuth 应用授权变更、邮件转发规则新增、权限变更记录。不仅要排查告警标记的异常账户，还需要检索时间段内全部账户登录记录，避免漏判。同时检索 Exchange Online、SharePoint、OneDrive 访问日志，查看是否出现非用户常规行为的数据读取、下载操作。
第二，针对疑似被攻陷账户，执行强制处置操作。除重置账户密码之外，必须吊销账户全部活跃会话，使所有会话 Cookie 直接失效，同时吊销全部刷新令牌，阻断攻击者利用旧令牌获取新会话的途径。针对管理员、财务等高权限账户，强制用户完成完整重新认证，清除所有缓存身份凭证。
第三，开展租户全局安全审计。检查是否出现攻击者新增后门账户、访客账户，核查应用程序权限授权列表，排查未经审批的第三方 OAuth 应用获取企业数据访问权限，清理恶意邮件转发、收件箱规则，核查邮件流配置是否被篡改。
第四，开展影响评估。评估被攻陷账户可以访问哪些敏感业务数据，判断是否发生企业内部资料、客户信息外泄。如果存在敏感数据外泄风险，按照合规要求完成后续处置。
第五，完成事件复盘，更新安全策略。核查企业当前身份认证配置，识别现有策略漏洞，同步更新邮件安全规则，针对全体员工开展本次攻击场景的安全提示，更新钓鱼演练场景库。
企业需要明确 AiTM 攻击事件属于会话凭证失窃事件，不能简单按照普通密码泄露事件处置，忽略会话与刷新令牌吊销步骤会造成事件反复发生。
5 面向 AiTM 中间人钓鱼攻击的分层防御体系构建
针对 BigBear2.0 代表的 AiTM 中间人钓鱼威胁，无法依靠单一安全工具实现防护，应当从身份认证策略、条件访问管控、会话生命周期管控、威胁检测、邮件防护、人员安全意识六个层面搭建分层防御架构。
5.1 落实抗钓鱼身份认证策略，区分 MFA 认证能力
企业应当摒弃 “只要开启 MFA 就足够安全” 的思路，区分认证方式是否具备抗中继能力。对于管理员、财务、核心业务岗位等高风险账户，通过条件访问策略强制只允许 FIDO2/WebAuthn 安全密钥、Passkey 这类抗钓鱼认证方式，关闭短信验证码、移动推送通知、TOTP 软件令牌作为备选认证手段。普通员工账户至少将硬件安全密钥作为首要选项，严格限制可中继 MFA 手段的使用范围。
该配置逻辑的核心在于从协议层面阻断 AiTM 攻击链路，FIDO2 协议执行校验的时候会校验访问页面域名，如果是 BigBear2.0 的钓鱼代理域名，域名与官方登录域名不匹配，硬件密钥拒绝生成认证凭证，攻击流程直接中断，攻击者即便拥有代理链路，也无法中继完成身份校验。企业需要做好硬件密钥的配套运维，做好密钥资产登记、密钥挂失更换流程，解决密钥丢失替换的落地问题。
不能简单将抗钓鱼认证设置成可选功能，如果允许用户优先选用短信、推送通知，攻击者依旧可以通过 BigBear2.0 脚本迫使浏览器放弃硬件密钥，退回可中继认证方式，防护效果会大打折扣。
5.2 优化条件访问策略，降低攻击后续利用空间
传统仅依靠地理位置 IP 的条件访问策略已经不足以对抗 AiTM 攻击，攻击者可借助住宅代理伪造 IP 属地。企业应当启用设备状态校验，针对访问核心 Microsoft365 业务资源的访问请求，要求设备为企业托管的合规设备，未加入企业管理的外来设备禁止访问高敏感业务数据。即便攻击者劫持会话 Cookie，如果访问设备不符合企业设备合规要求，条件访问策略可以阻断资源访问。
启用持续访问评估能力，当账户出现安全事件标记、权限变更、高危操作时，云端主动撤销已经下发的会话，实现会话的实时失效，不用等待 Cookie 自然过期。细化条件访问认证强度配置，针对不同业务系统、不同岗位账户设置差异化认证约束，高敏感业务强制启用最高等级抗钓鱼认证强度。
同时限制 OAuth 应用授权行为，设置用户应用授权管控策略，阻止用户随意授权第三方应用访问邮箱、文件资源，降低攻击者攻陷账户之后通过恶意 OAuth 应用实现持久驻留的可能性。
5.3 完善会话生命周期管理与异常行为检测
建立常态化会话审计机制，定期批量审计租户内所有账户活跃会话，及时发现异常会话。搭建异常行为检测基线，学习员工常规访问模式，对批量文件下载、陌生客户端访问、短时间多地访问、批量创建邮件转发规则、新增授权应用等行为配置高优先级告警。
需要明确会话劫持攻击发生之后，登录记录里登录时间、登录 IP 有可能显示正常，不能只依靠登录日志判断账户安全状态，必须重点关注登录之后发生的后续业务操作行为。部分攻击会话登录事件没有异常特征，但后续出现批量读取邮件、导出文档等高风险操作，行为分析才可以识别这类潜伏攻击。
5.4 强化邮件安全网关与威胁情报联动
邮件是 AiTM 钓鱼攻击的主要投递渠道，邮件安全网关需要持续更新钓鱼域名情报，拦截携带 AiTM 代理钓鱼链接的邮件。但 AiTM 钓鱼域名生命周期短，不断更换全新域名，单纯依靠域名黑名单无法全部拦截。邮件网关需要开启链接时检测功能，当用户点击邮件内链接的瞬间实时检测目标站点，识别钓鱼代理站点，阻止浏览器跳转。
企业威胁情报平台需要持续跟踪 PhaaS 攻击平台基础设施情报，及时把已知攻击 VPS、恶意域名纳入黑名单，同时监控内部 DNS 访问日志，告警员工访问 AiTM 钓鱼代理域名的行为。要客观认识邮件防护的局限性，邮件网关无法做到 100% 拦截全部钓鱼邮件，不能把全部防御希望寄托在邮件安全设备。
5.5 更新人员安全意识体系适配新型 AiTM 钓鱼威胁
反网络钓鱼技术专家芦笛强调，AiTM 中间人钓鱼颠覆传统钓鱼识别逻辑，依靠看页面外观、检查 HTTPS 标识已经不足以分辨攻击页面，企业安全教育内容必须迭代升级。
第一，更新员工培训课件，专门讲解 AiTM 中间人钓鱼攻击原理，告知员工即便页面显示 HTTPS，页面与官方网站完全一致，依旧有可能是钓鱼代理站点；MFA 确认通过不等于页面安全，完成二次校验不代表访问的是官方站点。第二，在内部钓鱼演练平台引入 AiTM 中间人钓鱼模拟场景，定期开展仿真演练，不再只使用传统静态仿冒页面作为演练素材，让员工直观感受新型钓鱼的欺骗形式。第三，建立规范登录入口指引，引导员工只使用企业书签、企业门户内的官方链接访问云办公系统，禁止点击邮件、即时通讯消息内附带的登录链接。第四，明确安全处置流程，员工怀疑访问可疑页面之后，应当立刻关闭全部浏览器页面，主动在企业门户重置会话，而不是简单关闭标签页。
6 研究结论与展望
BigBear2.0 钓鱼攻击活动给行业带来重要警示：多因素认证是身份安全重要基础，但传统依赖短信、TOTP、推送通知的 MFA 方案，存在被 AiTM 中间人钓鱼中继利用的固有短板，不能作为抵御钓鱼攻击的最终屏障。攻击成功不是 MFA 算法本身存在漏洞，而是认证因子可以在代理链路中被完整转发，攻击者不需要破解密码或者绕过 MFA 校验，只需要截获认证完成之后下发的会话 Cookie 就可以接管账户。随着钓鱼即服务 PhaaS 平台持续产业化，AiTM 中间人钓鱼攻击技术门槛持续下降，该类威胁会成为企业云身份安全需要长期面对的风险。
企业防御该类威胁，不能停留在 “开启 MFA” 这一步，必须重构身份安全基线。优先针对高价值账户强制部署 FIDO2/WebAuthn 抗钓鱼认证，从协议层面阻断中间人中继路径；配套优化条件访问策略，强化设备合规校验，启用持续会话评估，完善会话生命周期管控；建立基于操作行为的异常检测，不再仅仅依靠 IP 地址作为异常判断标准；同时升级人员安全教育，适配 AiTM 钓鱼的欺骗逻辑，不再只依靠页面外观识别钓鱼风险。发生疑似 AiTM 攻击事件时，处置流程必须包含吊销全部会话、刷新令牌，只重置密码无法消除攻击者手中窃取的会话凭证。
面向未来，云办公 SaaS 系统应用范围持续扩张，身份中继类攻击工具会持续迭代演进，攻击者会不断优化脚本绕过浏览器安全能力，尝试新的代理模式。企业需要持续跟踪威胁情报，定期审计身份安全配置，动态调整防御策略。身份安全是一套组合体系，认证技术、访问管控、威胁检测、人员安全意识缺一不可，任何单一技术控件都无法实现绝对防护，只有多维度能力互相配合，才可以形成完整安全闭环。
编辑：芦笛（公共互联网反网络钓鱼工作组） 来源：迪妙网络空间安全学院
