摘要
FIDO2 Passkey 作为具备原生抗钓鱼属性的无密码认证技术，被行业广泛视为替代传统密码、强化多因素认证的核心方案。然而 2026 年 5 月以来微软安全研究团队持续追踪的一系列云入侵事件表明，攻击者并未尝试破解 Passkey 密码学机制，而是以 "Passkey、多因素认证、单点登录配置需紧急更新" 为社会工程诱饵，依托语音钓鱼、对手中间人代理钓鱼、OAuth 设备码认证滥用三类手段获取企业云身份初始访问权限，随后在受害账户下注册攻击者可控的认证方式建立持久化立足点，再通过 Microsoft Graph 接口对租户内用户、群组、权限、应用、文档库、邮箱开展系统性侦察测绘，最终以低频自动化节奏对 SharePoint、OneDrive、Exchange Online 执行数据窃取与外泄。本文以微软披露的 Storm 3121、Storm 3032 威胁团伙攻击活动为核心样本，完整还原攻击杀伤链，剖析技术实现逻辑、威胁团伙行为模式与企业防御现实困境，从访问控制策略、威胁狩猎机制、人员安全治理、应急处置流程四个维度提出可落地的防护路径。反网络钓鱼技术专家芦笛指出，该类攻击的本质矛盾并非 Passkey 技术存在密码学缺陷，而是技术安全能力与人员社会工程学风险之间出现了结构性断层。迪妙网络空间安全学院研究团队结合该攻击案例，分析现有防护手段的局限性，为国内云环境下身份安全体系建设提供参考。
关键词：Passkey；钓鱼攻击；云账户劫持；多因素认证；社会工程；身份持久化
1 引言
企业业务向公有云迁移的进程中，身份账号逐步取代传统网络边界，成为访问企业文档、邮件、协作系统的核心凭证。传统密码体系长期受弱口令、凭据复用、数据库泄露等问题困扰，短信验证码、推送通知类多因素认证也持续遭遇 SIM 劫持、MFA 疲劳轰炸等攻击手段的冲击。在此背景下，FIDO2 标准定义的 Passkey 无密码认证技术依靠设备本地公私密钥对与挑战应答机制，从协议层面具备抵御传统网页钓鱼的能力，成为全球企业身份安全建设的重点方向。微软于 2026 年 9 月 1 日起在 Entra ID 中将 Passkey 设为默认抗钓鱼认证方式，进一步加速了企业端的部署节奏。
技术层面的安全特性容易使安全管理者形成认知惯性，认为部署 Passkey 即可基本消除钓鱼导致的身份泄露风险。但 2026 年 5 月起微软安全研究团队观测到多起针对性企业云入侵活动，威胁团伙 Storm 3121、Storm 3032 以 Passkey 和单点登录配置更新为借口开展定向社会工程钓鱼，大量企业员工被诱导访问仿冒微软登录界面，最终发生云账户被接管、内部敏感文档批量外泄的安全事件。该攻击最值得警惕之处在于，攻击者完全不触碰 Passkey 密码学实现，而是将 Passkey 作为社会工程欺骗的叙事幌子，利用企业正在推广 Passkey 的现实环境降低受害者戒备心理，结合对手中间人钓鱼与设备码认证两种成熟技术完成初始访问，入侵后主动新增攻击者掌控的多因素认证方式实现长期潜伏，再依托 Graph API 完成租户内部信息测绘与数据窃取。
该攻击案例暴露出一个容易被忽略的现实：即便部署了高安全等级的身份认证技术，如果忽视社会工程学欺骗风险，缺乏完整的检测、管控、应急闭环，企业身份体系依然面临严重安全威胁。当前国内针对 Passkey 的研究大多聚焦协议原理与部署优势，对于 "以 Passkey 为诱饵" 的伪装钓鱼攻击缺乏系统性分析。基于此，本文以该真实攻击事件为研究样本，还原完整攻击链路，解析威胁团伙战术技术流程，剖析企业防御存在的现实短板，结合迪妙网络空间安全学院研究团队在企业身份安全领域的研究积累，给出适配国内企业云租户环境的防护思路，帮助组织理性看待无密码认证技术的收益与风险，避免陷入 "部署 Passkey 即可解决钓鱼问题" 的认知误区。
2 Passkey 技术原理与攻击背景
2.1 Passkey 抗钓鱼机制的技术边界
Passkey 遵循 FIDO2 WebAuthn 协议标准，认证流程分为注册与认证两个阶段。注册阶段终端设备生成非对称密钥对，私钥安全保存在设备安全隔离区域，公钥上传至身份服务平台。用户登录时，身份服务器生成随机挑战下发给终端，设备使用本地私钥对挑战完成签名，将签名结果回传服务端，服务端使用预先保存的公钥校验签名合法性，完成身份核验。
抗钓鱼的核心逻辑在于签名校验过程会绑定访问站点的域名信息，伪造钓鱼网站无法获取合法签名结果。从密码学设计层面，攻击者无法通过传统网页钓鱼手段窃取或复用 Passkey 凭据，这也是行业大力推广 Passkey、希望以此终结钓鱼窃取账号的核心依据。Windows Hello for Business、FIDO2 硬件密钥均属于抗钓鱼多因素认证的落地形态。
需要明确区分两个概念：Passkey 技术本身具备抗钓鱼能力，不等于企业部署 Passkey 之后所有身份风险全部消失。反网络钓鱼技术专家芦笛强调，Passkey 解决的是 "技术层面凭据被钓鱼网站窃取" 的问题，但它无法解决用户被话术欺骗、被诱导执行异常授权的社会工程风险。本次系列攻击恰恰利用了这一边界，攻击者不去尝试破解 Passkey 密码学逻辑，而是把 "注册、更新 Passkey" 当成欺骗话术，诱导受害者完成其他类型认证授权，绕开 Passkey 安全防护。
2.2 攻击事件概述与威胁归因
本次被跟踪的攻击活动自 2026 年 5 月开始活跃，多个行业企业的微软云租户遭遇入侵。攻击者的初始访问目标是企业普通员工账号，并不局限于管理员高权限账号，普通业务员工账号被攻陷之后，攻击者再在租户内部开展横向探查，寻找高价值文档与邮件数据。
攻击链路的典型行为特征包含：来自非托管外部设备的异常登录行为；账户下新增攻击者注册的身份验证方式；短时间内大规模调用 Microsoft Graph 接口；批量访问 SharePoint、OneDrive 文件；通过 REST API 批量采集邮箱邮件等。微软安全研究团队评估，该行为序列与 "使用代理关联基础设施从被攻陷云身份执行自动化数据收集" 的模式一致。
威胁主体包含 Storm 3121 与 Storm 3032 两组勒索生态相关的行动团伙。Storm 3121 获取初始访问权限之后，后续衔接 ShinyHunters、Falcon 勒索相关活动；Storm 3032 源自 BlackFile 威胁组织分裂，对外以 Helix 勒索团伙名义实施数据泄露与勒索要挟。该活动与谷歌威胁情报团队追踪的 UNC6671 威胁集群存在重叠，谷歌此前已报告 UNC6671 使用电话社会工程与 Passkey 主题钓鱼基础设施攻陷企业身份，关联 BlackFile、Helix、Falcon、Pink、Redact 等多个勒索团伙。攻击者的收益模式是窃取企业内部商业文档、客户资料、财务邮件等敏感信息，以此向企业实施勒索，威胁对外公开泄露窃取的数据。
值得关注的攻击入口渠道有三类：第一，直接拨打员工个人手机号码开展语音钓鱼；第二，向员工私人手机发送包含钓鱼链接的短信；第三，利用已经被攻陷的企业账号，在 Microsoft Teams 内部向同单位其他员工发送欺骗消息。员工个人手机属于企业无法管控的 BYOD 设备，企业安全系统通常无法记录通话与原始短信内容，导致攻击前置欺骗环节处于企业安全检测视野之外，进一步提升事后溯源难度。
2.3 两类核心攻击技术：AiTM 中间人钓鱼与设备码钓鱼
本次攻击主要依靠两类技术拿到云会话权限，二者都不需要获取用户原始密码，也不需要破解 Passkey，仅仅依靠受害者在欺骗场景下完成合法身份确认。
对手中间人钓鱼，攻击者搭建反向代理钓鱼站点，页面视觉高度复刻微软官方登录页面，流量实时转发到真实微软身份服务。受害者在钓鱼页面输入账号密码、完成 MFA 校验，所有凭据、会话 Cookie、会话令牌被代理完整捕获，攻击者直接复用拿到的有效会话登录进入受害者云账户。整个过程用户看到的页面交互与真实登录几乎没有差异，受害者主观以为自己正在完成 Passkey 更新配置操作，实际完成的是普通身份认证，认证产物直接交给攻击者控制。
设备码钓鱼是对 OAuth2.0 设备授权许可流程的恶意滥用。该协议原始设计面向没有完整输入键盘的智能电视、IoT 设备，设备向身份服务商发起请求获取简短数字设备码，由用户在另外一台正常浏览器打开官方认证页面输入设备码，完成账号登录确认，授权这台受限设备访问账号资源。攻击者主动发起设备码申请拿到合法设备码，通过社会工程话术哄骗受害者打开微软真实官方网页输入该设备码并完成自身 MFA 校验。受害者在完全合法的微软页面完成全部操作，页面本身不存在伪造，但授权访问权限给到攻击者控制的客户端，攻击者直接获取访问令牌与刷新令牌，获得账户访问权限。迪妙网络空间安全学院研究团队针对该技术开展分析后提出，设备码钓鱼最大的防护难点在于用户交互全部发生在官方域名，传统 URL 黑名单、网页过滤手段无法拦截，识别该威胁只能依靠行为检测与策略限制。
3 Passkey 伪装钓鱼攻击完整杀伤链解析
整套攻击流程可以划分为社会工程诱饵投放、初始身份权限获取、账户持久化配置、租户内部侦察测绘、数据窃取与外泄五个阶段，各阶段前后衔接，形成闭环攻击链路。
3.1 第一阶段：社会工程诱饵投放与前期侦察
攻击者在正式接触受害者之前投入大量资源开展前期侦察，从社交网络、职业档案平台等公开来源搜集目标企业员工信息与组织架构，筛选适合作为初始入侵入口的员工个体。这一阶段的准备工作使得后续语音钓鱼话术能够准确引用员工姓名、部门信息，大幅提升欺骗可信度。
攻击者伪装为本单位 IT 运维服务台工作人员，核心话术统一围绕 Passkey、MFA、SSO 需要紧急升级，告知受害者如果不立刻操作，邮箱、云文档访问会中断。该话术具备很强迷惑性，尤其企业内部确实正在推进 Passkey 落地推广时，员工已经接收过内部 Passkey 升级通知，容易把诈骗电话、短信当成真实 IT 运维工作。
沟通载体优先选择员工私人手机号，脱离企业通信管控边界。通话完成之后引导受害者访问仿冒登录网页链接，或者发送短信附带钓鱼链接。当已经拿到一个企业账号之后，攻击者会优先使用企业内部 Teams 工具向其他同事发送消息，来自内部同事账号的消息大幅降低人员警惕心理。
为支撑欺骗操作，攻击者快速部署围绕 Passkey、SSO 注册、账户激活、身份验证等主题的钓鱼基础设施。常见手法是注册通用域名，将目标企业名称嵌入子域名，构造乍看熟悉的 URL，例如企业名称出现在secure-passkey.com、add-passkey.com、integratedsso.com等域名之下作为子域名。同一企业可能对应多个域名，便于攻击者按需轮换基础设施。这些域名常在注册后数小时内即投入运营，防御方几乎没有时间在员工接触之前识别并阻断。微软观测到的典型域名包括passkeyhelpdesk.com、setupmypasskey.com、keysyncos.com、oskeysync.com、oskeysetup.com、oskeyregister.com、syncmykey.com、myconnectkey.com、oskeyconnect.com、validationsetupac.com、portalsetuphub.com等，覆盖 Passkey 支持、SSO 集成、密钥同步、账户验证设置等多种欺骗主题。
反网络钓鱼技术专家芦笛指出，此处攻击者的策略非常巧妙，Passkey 更新只是欺骗借口，并不是攻击者真正目标。攻击者并不希望受害者成功注册属于自己的 Passkey，只是借用这个企业员工近期可能接触到的业务场景构建可信叙事，诱导受害者进入 AiTM 代理页面或者执行设备码授权操作。大量企业安全培训重点教育员工识别假冒网站，但针对冒充 IT 运维、结合企业正在落地的安全项目开展的语音钓鱼，员工认知防护普遍存在短板。
3.2 第二阶段：获取账户初始访问权限
受害者被说服之后按照攻击者指引开展操作，分为三种技术路径。
路径一，点击链接进入 AiTM 中间人代理钓鱼网站，输入账号密码、完成原有 MFA 验证，攻击者代理捕获会话令牌，直接获得该账户的云访问会话。微软在一个被调查的攻击序列中观测到，攻击始于来自非托管设备对 OfficeHome 应用的异常登录，MFA 完成后攻击者开始访问 My Sign Ins、My Apps 等身份门户，登录产物中的用户代理模式指示可能存在 AiTM 钓鱼。该会话持续约一小时，期间枚举敏感文件与内部应用。
路径二，攻击者给到一串设备授权码，指导受害者打开微软官方认证站点输入编码完成身份校验，受害者不知情情况下授权攻击者客户端获取 OAuth 令牌。在另一个被调查的攻击序列中，攻击者在 Passkey 诱饵之后使用设备码流程攻陷会话令牌，受害者在合法微软认证页面输入代码，该审批向攻击者控制的客户端签发令牌，攻击者随后重放被攻陷的令牌，有效绕过 MFA 并开展枚举与后续攻击推进。
路径三，攻击者使用此前已被攻陷的凭据登录，MFA 通过预先注册的 PhoneAppOTP 方式完成，表明攻击者在发起本次活动数天之前已经在该账户下注册了验证器应用。登录成功后攻击者遵循与其他序列相同的侦察模式，该活动主要使用基于 Node.js 与 Microsoft Graph 构建的自动化系统执行。
三种路径有共同特点：不需要攻破 Passkey 密码学；受害者主观认知是在处理 Passkey 配置业务；身份校验本身是受害者本人合法完成，安全系统记录的登录校验要素全部合规，静态安全规则很难直接拦截。
3.3 第三阶段：攻击者配置持久化身份认证方式
拿到初始会话之后，攻击者不会仅仅依赖当前临时会话，因为会话存在过期风险。攻击者访问账号安全信息管理模块，在受害账户之下注册新增属于攻击者掌控的身份验证手段，包含攻击者手机号、第三方验证器应用、软件一次性密码令牌等多种形式。
这一步是整个杀伤链中非常关键的节点，也是企业检测的重要信号。即便受害者后续修改账户登录密码，只要攻击者新增的 MFA 方式没有被清除，攻击者仍然可以使用新增认证方式继续绕过防护登录账户，维持长期控制。很多企业处置账号泄露事件仅仅重置员工密码，忽略核查账号下全部已注册身份验证方法，造成攻击残留，入侵者可以反复夺回账号控制权。
微软在实际调查中获取到攻击者添加软件令牌的真实日志样例。该日志记录显示，攻击者通过 Update user 操作在用户身份下新增了一条认证方法记录，设备名称标记为 NO_DEVICE，设备令牌标记为 NO_DEVICE_TOKEN，设备标签为 SoftwareTokenActivated，认证类型为软件 OTP，哈希函数为 hmacsha1。这条记录与用户原有的 iOS 设备验证器记录并列存在，从日志结构上可以清晰对比出新增条目。这一发现表明，攻击者不仅注册传统的手机号与验证器推送方式，还会使用纯软件 OTP 令牌作为持久化手段，此类方式不绑定物理设备，更难被用户察觉。
迪妙网络空间安全学院研究团队在分析多起同类入侵复盘案例后认为，新增陌生认证方式属于高置信度入侵告警信号，但现实中很多企业安全告警规则没有把 "登录之后短时间内新增身份验证方式" 作为高优先级告警，部分中小企业甚至没有开启该类行为审计日志采集，入侵痕迹难以被及时发现。攻击者完成持久化配置之后会话可以稳定维持，部分攻击会话持续一小时以上开展后续侦察活动。
3.4 第四阶段：租户域内 Graph 侦察测绘
获得稳定访问权限后，攻击者主要依托 Microsoft Graph API 作为操作接口。Microsoft Graph 是微软云统一编程接口，用户账号授权之后即可调用接口读取组织用户清单、用户组信息、权限分配关系、应用清单，同时访问 SharePoint 站点、OneDrive 个人云盘、Exchange 邮箱内容。
攻击者首先开展租户环境测绘，枚举的资源类别涵盖多个层面。租户配置层面，查询组织信息、已订阅服务许可证、已启用服务，识别租户规模与业务范围；目录枚举层面，查询用户列表、群组列表、群组成员关系、传递成员关系，构建身份地图，识别特权用户与敏感协作群组；权限与认证发现层面，查询目录角色、角色管理分配、已注册认证方法，探查身份控制与持久化机会；应用与授权发现层面，查询企业应用列表、服务主体、OAuth 权限授予、应用角色分配，映射可复用访问路径与高价值服务身份；SharePoint 与 OneDrive 发现层面，查询站点列表、文档库、驱动器、文件夹与文件，将宽泛的租户侦察转化为可收集的文件地图；邮箱发现层面，查询邮件消息、邮件文件夹、附件元数据，支撑情报收集与定向附件获取。
攻击者在整个攻击生命周期中刻意轮换基础设施，认证、侦察、外泄各阶段往往使用不同的 IP 地址，因此还原完整入侵需要跨阶段关联活动，而非依赖单一网络指标。该攻击凸显一个关键检测难点：Microsoft Graph 滥用在单次 API 调用层面很少显得可疑，对 /users、/groups、/sites 等端点的请求在企业环境中极为常见，但当同一身份、应用或访问令牌系统性遍历多个租户资源、评估权限与认证设置、随后访问邮件文件附件文档内容时，这些动作共同构成清晰的侦察到外泄链条。
普通业务员工账号权限有限，但大量企业存在权限配置宽松问题，普通员工依然能够访问大量部门共享文档库，攻击者通过普通账号就可以接触到足够用于勒索的数据，并不一定需要拿到全局管理员权限即可形成实质性业务损失。
3.5 第五阶段：低频持续数据窃取与外泄
完成侦察测绘之后，攻击者转入针对微软 365 工作负载的大规模数据收集阶段。微软观测到针对 SharePoint Online 与 OneDrive for Business 的高容量访问与下载活动，部分入侵延伸至 Exchange Online，通过 REST API 访问邮件内容。SharePoint 与 OneDrive 层面产生大量 FileAccessed 与 FileDownloaded 事件，表明对云托管文档与组织数据的系统性检索。
该活动频繁呈现自动化而非交互式用户行为的特征。多个案例中微软观测到 python httpx 用户代理关联高容量 SharePoint 与 OneDrive 访问模式。但用户代理本身不应被直接判定为恶意，需要结合数据容量、受影响身份、来源基础设施、前期侦察活动、身份被攻陷证据等 broader 上下文综合评估。
与快速 "打砸抢" 式外泄不同，本次攻击的数据窃取通常是有节制、可持续的，根据受害用户可访问文件与邮件内容的体量，持续数小时至数天不等。攻击者维持受控的收集节奏，任意一小时内访问的文件或邮件少于一千个，这种低频策略帮助活动混入正常企业使用流量，同时实现随时间推移逐步提取大量敏感数据。攻击者在侦察完成后才进入内容收集阶段，先定位高价值资源再执行下载，避免无差别大规模访问触发阈值告警。
数据窃取完成之后，威胁团伙所属勒索生态链条启动后续流程。威胁团伙留存窃取到的企业文档，向企业发起勒索，企业拒绝支付赎金的情况下威胁团伙将内部数据对外泄露出售，形成实质性数据安全事件，给企业带来声誉、合规、经济多重损失。
4 攻击事件折射的企业身份安全多重现实困境
该系列攻击事件不能简单归因为员工安全意识不足，其背后反映出身份安全建设中技术、策略、运维、人员认知多维度叠加的矛盾。
4.1 技术认知偏差与策略配置陷阱
Passkey 密码学层面抗钓鱼，不等于企业部署 Passkey 之后就可以免疫全部钓鱼类攻击。很多企业安全管理者形成片面认知，认为上线 FIDO2 Passkey 就解决钓鱼风险。但本次攻击清晰证明，攻击者可以不触碰 Passkey 协议本身，把 Passkey 当作话术道具，诱导受害者使用其他认证流程完成授权。
反网络钓鱼技术专家芦笛对此作出阐释：Passkey 解决的是 "钓鱼网页盗取凭据" 的传统风险，属于技术防护屏障，但它无法防御 "欺骗用户不去使用 Passkey，改用别的认证手段授权攻击者" 这类社会工程场景。如果企业仅仅完成 Passkey 部署，却缺少配套策略限制、行为检测、审计机制，身份体系依旧存在被攻陷路径。企业要客观区分技术组件能力边界，不能将单一认证技术当成身份安全的全部解决方案。
同时企业在落地 Passkey 条件访问策略时本身存在配置陷阱。迪妙网络空间安全学院研究团队调研国内多家企业微软云部署现状，发现部分组织配置条件访问策略时简单粗暴全局强制抗钓鱼 MFA，产生循环依赖问题：用户必须拥有 Passkey 才能够登录，但没有登录权限又无法注册 Passkey，为规避该障碍管理员会保留短信、推送 MFA 作为降级备选方案。一旦保留可被钓鱼的降级 MFA 选项，攻击者就有空间利用社会工程引导受害者走降级认证路径，Passkey 防护效果被直接消解。微软在缓解建议中专门指出，对安全信息注册操作不应强制抗钓鱼 MFA 以避免循环锁死，而应通过要求托管设备、指定位置、始终要求重新交互认证、高登录风险时阻断注册等组合策略加以约束，这一细节恰恰是很多企业配置时容易忽略的。
4.2 行为序列检测的现实难点
攻击前置社会工程环节发生在员工私人手机，通话、短信发生在企业 IT 管控边界之外，企业日志系统无法捕获原始欺骗沟通过程，安全团队只能看到攻击后半段云平台侧的行为日志。在很多调查中，员工对电话或短信的回忆成为解释入侵如何开始的最早、有时也是唯一证据，调查人员必须将这些口述报告与后续登录、设备码认证事件、令牌活动、认证方法变更关联起来才能重建攻击过程。
AiTM 中间人钓鱼输出的会话令牌来自受害者完整合法身份校验，登录事件日志中 MFA 校验结果显示成功，单纯依靠登录是否成功无法区分正常登录还是被钓鱼之后的登录。设备码钓鱼场景受害者全部操作在官方域名页面执行，网页层面没有恶意站点特征，传统网页防护工具无法识别威胁。
恶意行为不是单次登录失败，而是一组行为序列：陌生来源登录、短时间新增身份验证方法、大规模 Graph 接口调用、批量访问网盘与邮箱。不少企业安全监控只配置独立告警规则，针对单一事件设置告警阈值，缺少跨事件关联分析能力。单次新增 MFA 方式本身允许员工自助操作，属于合法功能；单次 Graph 接口调用也属于正常业务行为，单独看都不属于异常，只有将时序上连续发生的一组行为串联才能够识别入侵事件。很多中小型企业安全平台缺少行为关联狩猎能力，入侵发生之后很长时间无法感知。
微软在研究中反复强调，域名、IP 地址、托管服务提供商会快速变化，但身份攻陷、持久化、侦察、内容发现、外泄这一重复出现的序列提供了更持久的调查基础，防御者应当跨身份、Microsoft Graph、SharePoint、OneDrive、Exchange 信号调查这一序列。这一判断本身就说明，依赖传统单点指标检测的企业在该攻击面前存在结构性盲区。
4.3 BYOD 边界外社会工程的管控盲区
大量企业允许员工使用个人手机接收工作相关短信、接听业务电话，企业对于员工私人终端没有管控权限。攻击者直接联系私人手机号，绕过企业内部通讯渠道开展欺骗。企业安全培训内容大多聚焦企业邮箱、企业 IM 收到的钓鱼信息，针对私人手机接到冒充 IT 的诈骗电话的培训素材占比很低，员工缺少对应的处置经验。
攻击者利用个人 BYOD 渠道完成欺骗之后再入侵企业云账号，攻击路径跨越个人终端与企业云边界，传统边界安全设备无法覆盖这条攻击链路。如果受害者在未接入微软 Defender for Endpoint 的个人移动设备上打开钓鱼链接，相关活动可能完全不出现在终端遥测中，进一步压缩了可观测范围。
攻击者还会利用已攻陷账号在 Microsoft Teams 内向同单位员工发送 Passkey 主题消息，这种来自内部可信身份的消息使得请求显得合法，显著提升员工参与操作的可能性。企业内部协作工具本身被武器化为横向传播渠道，而很多企业对 Teams 内部消息的异常行为检测能力薄弱，难以识别账号被攻陷后向同事批量发送钓鱼消息的行为。
4.4 持久化机制放大事件处置难度
攻击者攻陷账号后的核心动作是新增自有认证方式实现账号持久化，该行为极大提升处置难度。很多企业安全事件应急流程习惯将重置账号密码作为主要处置手段，容易忽略核查账户下全部注册的身份验证方法，攻击者新增的手机号、验证器得不到清除，即便修改密码攻击者依旧可以持续访问。
微软明确指出，MFA 注册本身在完整凭据与会话重置之后无法独立存活，但当与被盗令牌、未撤销的会话、后续对有效凭据的访问结合时，它提供了持久的持久化机制。因此攻击者往往在入侵早期就建立 MFA 持久化以增加维持长期访问的可能性。这一技术细节意味着，仅重置密码而不撤销会话、不清除攻击者注册的认证方式，处置是不完整的。
当普通业务账号被攻陷之后，如果租户内部权限划分粗放、缺少最小权限原则约束，普通员工账号能够访问大量跨部门共享资源，攻击者借助普通账号就可以大范围搜集敏感信息，不需要拿到管理员账号即可造成重大损失。此外，攻击者可能创建恶意邮箱规则自动转发或删除邮件，掩盖入侵痕迹，如果应急处置不包含邮箱规则核查，攻击者的隐蔽通道可能继续存在。
5 面向该类 Passkey 伪装钓鱼攻击的综合防御策略
结合微软官方缓解方案以及迪妙网络空间安全学院研究团队的研究结论，防御该类攻击不能只依靠单一手段，需要从访问条件策略配置、威胁检测狩猎、人员安全治理、事件应急处置四个层面构建综合防护闭环。
5.1 优化条件访问策略，收缩攻击面
第一，按需阻断 OAuth 设备码授权流程。设备码协议只适用于无输入外设的智能设备，绝大多数企业员工日常办公完全不需要使用该授权流程。管理员在条件访问策略中将设备码认证流程进行阻断，业务确实存在需求的场景做最小范围人员豁免，从源头消除设备码钓鱼的执行基础。微软同样建议通过条件访问阻断设备码与认证传输流程，除非存在明确业务需求。
第二，合理部署抗钓鱼 MFA，规避策略配置陷阱。不要直接对 "注册安全信息" 这一用户动作强制要求抗钓鱼 MFA 以避免循环锁死，分阶段分角色推进 Passkey 落地，妥善设计用户注册引导路径，谨慎保留可被钓鱼的降级 MFA 选项。如果业务必须保留降级 MFA 方式，应当通过条件访问做上下文限制，例如只允许企业托管设备之上使用短信、推送 MFA，来自非托管外部设备访问时强制要求 FIDO2 抗钓鱼认证，使得 AiTM 中间人拿到凭据之后在外部设备上无法绕过强认证约束。对安全信息注册操作设置严格条件访问控制，包括要求始终重新交互认证、要求托管设备或指定位置、要求抗钓鱼 MFA 作为认证强度，以及在单独策略中对高登录风险条件阻断安全信息注册。
第三，开展设备上下文管控，敏感云资源优先限制企业托管设备访问。攻击者本次大量使用不受企业管理的外部非托管设备接入账号，通过条件访问策略对 SharePoint、OneDrive 等高敏感业务要求只有企业托管设备才能够访问，即便攻击者窃取会话令牌，在外部未管控设备上也无法访问核心业务数据，缩小泄露后果。对非托管设备的访问限制为仅 Web 会话且不允许下载或同步，同时禁用 SharePoint 与 OneDrive 中的匿名共享链接。
第四，清理租户内过度宽泛权限配置，落实最小权限原则。限制普通员工跨部门文档库访问权限，减少普通账号被攻陷之后的横向侦察数据获取范围。限制用户对应用的同意授权，要求管理员审批，定期审查持有 Mail.Read、Files.Read.All、Directory.Read.All 等高特权 Graph 权限的服务主体。
5.2 建立面向攻击链路的威胁检测与威胁狩猎机制
该攻击的识别核心不是单点告警，而是对时序关联行为做分析。迪妙网络空间安全学院研究团队提出，需要重点监控以下行为组合序列：陌生非托管设备完成登录之后短时间内发生新增身份验证方式注册；账号短时间产生大量 Microsoft Graph 批量查询用户、群组、文档库的 API 调用记录；账号集中批量下载 OneDrive、SharePoint 文档；通过 API 接口批量读取邮箱邮件；同一个账号出现跨地域、跨设备的突发访问爆发行为。
企业应当完整开启身份审计日志、Graph API 操作日志、邮箱审计日志采集，将日志汇总至安全运营平台。摒弃只依靠单条事件阈值告警的思路，构建行为序列检测规则：当 "异常来源登录" 和 "新增 MFA 认证手段" 在短时间窗口连续发生，标记为高优先级告警，安全运营人员第一时间介入核查。对 Graph 活动进行整体性评估，重点关注行为进展与跨事件关联，而非孤立的单个 API 请求。具体而言，应当识别同一身份在三十分钟内从同一 IP 触及多个侦察类别的行为，识别自动化分页、增量查询、搜索行为（如使用\(top、\)skip、$skiptoken、/delta、/search 等参数遍历大型结果集），识别侦察进展到内容收集的会话（即宽泛发现与内容检索在同一会话中先后出现）。
同时要开展常态化威胁狩猎，定期检索租户审计日志，批量排查租户内账号近期新增的身份验证方法，发现非员工本人操作新增的验证手段及时清除。不能只关注管理员账号，普通业务账号同样需要纳入狩猎范围，本次攻击初始入侵对象大量为普通员工账号。对外泄行为的狩猎需要覆盖 Exchange Online REST API 高容量事件、SharePoint 与 OneDrive 的 python httpx 用户代理访问、匿名代理来源的高容量文件访问等多个维度。
反网络钓鱼技术专家芦笛补充提示，安全运营团队不能将告警简单理解为 "登录失败就是风险，登录成功就没有风险"，AiTM 钓鱼攻击全部登录行为返回结果为成功，传统登录失败类告警对此完全无效，检测重心需要向登录之后的后续行为转移。同时不应将 IP 或域名匹配本身当作结论性证据，需要验证工作负载行为、受影响身份、持久化事件、数据访问容量，避免误报与漏报。
5.3 迭代人员安全意识治理，针对性应对语音钓鱼威胁
传统钓鱼培训重点训练识别钓鱼网页、恶意邮件，但本次攻击主要依靠语音钓鱼结合 Passkey 业务场景开展欺骗，企业安全培训需要补充对应场景内容。
明确告知全体员工：IT 运维部门不会通过私人手机号码致电员工要求立刻操作更新 Passkey、MFA、SSO 配置；凡是收到该类电话、私人短信，不要按照对方指引操作链接，应当挂断电话，使用企业内部官方公开联系方式回拨 IT 服务台进行核验，不要信任来电者提供的任何联系号码。同时提醒员工，即便是 Teams 内部同事发来的要求紧急修改认证配置的消息同样需要二次核实，攻击者会利用已经被攻陷的账号发送内部欺骗消息。
在 Passkey 项目内部推广宣传材料中同步说明安全边界，告知员工 Passkey 相关正规业务通知只会通过企业邮箱、企业办公系统推送，不会通过私人手机短信、陌生来电下达紧急操作指令。把社会工程欺骗场景融入常态化安全培训，而不是只讲解密码、网页钓鱼案例。培训中应当提供经过验证的渠道供员工报告未经请求的认证请求，建立畅通的上报机制。帮助台自身在执行凭据或 MFA 重置之前也应当通过严格流程验证用户身份，并对每一次此类重置操作产生告警，防止帮助台流程本身被社会工程利用。
5.4 完善账号被攻陷后的标准化应急处置流程
当发生疑似账号被劫持事件，处置流程不能止步于重置账号密码。完整处置步骤应当包括：第一，临时冻结该受害账号，阻断攻击者继续访问；第二，全面清点该账号下所有已经注册的身份验证方式，删除全部非用户本人登记的手机号、验证器应用、软件 OTP 令牌，这一步是清除持久化后门的关键；第三，撤销该账号所有活动会话与刷新令牌，防止攻击者持有的已有会话继续有效；第四，重置账号登录密码；第五，核查攻击者是否创建了恶意邮箱规则，如有则予以清除；第六，要求用户安全重新注册认证方法；第七，核查审计日志，回溯入侵时间窗口，排查攻击者调用 Graph API 读取过哪些文档、邮箱，评估哪些敏感数据存在外泄风险；第八，排查该账号是否被用于向租户其他账号传播钓鱼消息，评估是否发生横向扩散；第九，完成清理之后再恢复账号使用，同步告知当事人完整事件情况，开展复盘。
企业需要把上述流程固化为安全事件处置 SOP，避免处置过程遗漏清除攻击者新增认证手段，造成攻击反复复发。同时企业需要定期演练该类身份劫持场景应急响应，减少真实事件出现时处置疏漏。微软在缓解建议中同样强调，对确认被攻陷的身份应当撤销活动会话与刷新令牌、重置凭据、移除攻击者注册的认证方法、移除攻击者创建的邮箱规则、要求安全重新注册认证方法，这一完整处置链条与上述步骤一致。
6 讨论
Passkey 代表无密码身份认证的发展方向，它在密码学层面解决传统网页钓鱼威胁的价值不可否定，但本次攻击事件清晰证明，任何安全技术都存在能力边界，技术防护无法完全隔绝社会工程学带来的风险。攻击者本次战术上没有去突破 Passkey 密码学安全，而是巧妙借用 Passkey 正在企业内部落地这一现实环境，以此构建可信欺骗叙事，诱导受害者退回到更容易被攻击的认证路径，拿到初始访问，再依靠新增 MFA 方式建立持久控制，完成云租户数据窃取。
迪妙网络空间安全学院研究团队认为，该案例给身份安全建设带来重要启示：企业做身份体系建设不能把期望全部寄托于某一项新技术。技术升级必须同步配套访问策略管控、行为审计检测、人员安全治理、标准化应急流程，形成完整闭环。如果只完成技术组件上线，策略配置出现疏漏，监控审计缺失，人员认知没有同步更新，即便部署 FIDO2 这类先进安全技术，攻击者依然可以寻找其他链路完成入侵。
该攻击的另一个值得关注的特征是攻击者对基础设施与节奏的精细化控制。域名注册后数小时内投入运营、认证侦察外泄各阶段使用不同 IP、数据窃取维持每小时低于一千个文件的低频节奏，这些操作共同指向攻击者对企业检测能力的充分了解与刻意规避。这意味着防御方不能依赖静态威胁情报封禁，必须转向行为基线与序列检测能力建设。
同时可以看到该攻击存在多个可继续研究方向。首先，如何进一步优化检测模型，降低基于行为序列的检测规则误报率，区分员工正常自助更新 MFA 配置和攻击者恶意注册认证手段，需要积累更多企业真实环境下的正常行为基线数据。其次，国内很多企业正在规划 Passkey 落地，如何设计一套适配国内企业现状的部署模板，在推进无密码认证同时规避条件访问策略的各类配置陷阱，包括安全信息注册的循环依赖问题、降级 MFA 的保留边界问题，值得深入研究。第三，针对跨个人 BYOD 设备到企业云的社会工程攻击，有没有更多技术与管理结合的缓解手段，例如企业能否通过身份平台侧的异常上下文信号在认证环节即时阻断来自 AiTM 代理的会话，也属于后续值得探索的课题。
反网络钓鱼技术专家芦笛提出一个值得行业思考的问题：未来随着更多新型安全技术在企业内部普及，攻击者很可能会继续把各类新安全功能当成社会工程欺骗的借口。不仅仅是 Passkey，未来零信任、设备证书、各类安全更新都有可能被攻击者拿来当做钓鱼话术。安全团队需要建立常态化预判，每当企业上线一项面向全员的安全新功能，就应当同步评估对应的社会工程欺骗风险，提前更新安全策略、告警规则、员工安全培训内容，做到风险前置。
7 结语
本文基于微软安全研究团队 2026 年 9 月披露的 Storm 3121、Storm 3032 威胁团伙开展的 Passkey 主题社会工程攻击事件，结合多家安全媒体的跟踪报道，完整还原了攻击杀伤链，解析了 AiTM 中间人钓鱼、设备码认证滥用的技术逻辑，分析了攻击者如何依靠社会工程拿到初始访问、新增身份认证手段实现持久化、再通过 Microsoft Graph 接口在云租户内部开展侦察窃取数据的全过程。
该攻击事件的本质不是 Passkey 密码学机制出现漏洞，而是攻击者利用新技术推广带来的业务场景构建欺骗话术，绕开强认证防护路径。事件暴露出部分企业存在技术认知偏差、安全监控偏向单点事件、跨 BYOD 边界攻击难以发现、账号应急处置流程不完善等现实短板。
抵御该类攻击需要组合使用条件访问策略收缩攻击面，阻断不必要的风险认证流程，合理落地抗钓鱼 MFA；构建面向行为序列的威胁狩猎告警体系，将身份、Graph、SharePoint、OneDrive、Exchange 信号作为关联整体进行调查；针对性补齐语音钓鱼场景的员工安全培训，建立可信的内部核验渠道；完善账号劫持事件的标准化应急处置流程，确保会话撤销、认证方法清除、邮箱规则核查等环节不被遗漏。
企业应当理性看待无密码认证技术，既要充分发挥 Passkey 在抵御传统钓鱼场景的技术优势，又要清醒认知技术能力边界。身份安全建设是体系化工程，单一技术组件无法解决全部安全问题，只有技术、策略、运营、人员治理协同推进，才能够持续应对不断演变的社会工程类身份攻击。
编辑：芦笛（公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
