以通行密钥为主题的社工攻击导致身份与云资源沦陷

来源机构：Microsoft Threat Intelligence（Microsoft Security）　|　原文：Passkey-themed social engineering leads to identity and cloud compromise　|　原文发布：2026-09-09　|　页面性质：中文翻译与摘录（非原创综述）

攻击链概览

Microsoft Security Research 正在追踪多账户范围的活跃云入侵活动：异常登录之后紧跟着攻击者新增的身份验证方法、高吞吐的 Microsoft Graph 活动、SharePoint 与 OneDrive 下载，以及通过 REST API 收集的邮件内容。Microsoft Security Research 评估认为，这一序列与利用代理关联基础设施对失陷云身份实施的自动化收集一致，该活动自 2026 年 5 月起被观测到。

该活动始于以身份为目标的社工与仿冒基础设施，经过身份验证持久化与云侦察，随后是目标数据访问以及符合数据收集与潜在外泄特征的活动。域名、IP 地址与托管商可能快速变化，但“身份沦陷→持久化→侦察→内容发现→外泄”这一反复出现的序列为调查提供了更持久的依据。防御者应跨身份、Microsoft Graph、SharePoint、OneDrive 与 Exchange 信号调查这一序列，并在确认失陷后撤销会话并移除未授权身份验证方法。

步骤 1–2：初始访问——passkey 与 SSO 诱饵

攻击通常始于用户个人手机号上的一通看似平常的电话或一条消息，对方自称来自组织的 IT 服务台。来电者制造紧迫感，声称必须立即更新 passkey、多重身份验证（MFA）或单点登录（SSO）配置以避免业务中断。员工被引导至与合法 Microsoft 登录体验高度相似的网站，并可能通过直接发送至其个人手机的 SMS 收到链接。

尽管频繁使用 passkey 主题诱饵，但 passkey 注册往往并非攻击者的真实目标。相反，passkey 话术只是一个有说服力的借口，用来引导受害者走过“攻击者居中”（AiTM）钓鱼或设备码（device code）身份验证流程。在 AiTM 场景中，攻击者窃取凭据与会话令牌；在设备码攻击中，受害者在不知情的情况下代表攻击者授权访问。这种初始交互可能留下极少的取证证据——若受害者在未纳入 Microsoft Defender for Endpoint 的个人移动设备上打开钓鱼链接，相关活动可能根本不出现在端点遥测中。在许多调查中，员工对电话或短信的回忆成为解释沦陷起因的最早、有时也是唯一的证据。

攻击者在攻击前投入大量预研，很可能从社交网络与职业档案平台等公开来源收集员工与组织架构信息。少数案例中，攻击者利用已失陷账户扩大触达：借助受信任的员工身份通过 Microsoft Teams 发送类似的 passkey 主题消息，使请求显得合法。攻击者快速部署围绕 passkey、SSO 注册、账户激活与身份核验等主题的钓鱼基础设施，常见手法是以目标组织名称为子域注册通用域名（例如 company-name.integratedsso[.]com、company-name.secure-passkey[.]com），令 URL 乍看熟悉；同一组织可能注册多个域名以便轮换基础设施。这些域名常以 Nicenic 注册商注册（此前勒索战役中曾出现），并在数小时内投入运营。

步骤 3–4：用户身份沦陷

在一例被调查序列中，活动始于从非托管设备（可能为攻击者所有）对 Microsoft OfficeHome 应用的异常登录，MFA 完成后攻击者开始访问 My Sign-Ins 等身份门户与 My Apps 等企业应用商店，登录产物（含用户代理特征）提示可能存在 AiTM 钓鱼；同一会话中攻击者进一步访问 Microsoft Approval Management 等管理应用，并主要通过 Graph API 枚举 SharePoint Online 与 OneDrive 中的敏感文件，会话持续约一小时。

在另一序列中，攻击者在 passkey 诱饵之后利用设备码流程篡夺会话令牌：设备码钓鱼中，用户被说服在合法 Microsoft 身份验证页面上输入一个代码，该批准向攻击者控制的客户端签发令牌，从而无需窃取浏览器 Cookie 即可访问被许可资源；随后攻击者重放失陷令牌，有效绕过 MFA 并进行枚举与后续推进。

第三种模式是攻击者使用此前已失陷的凭据登录，并用早前注册的 PhoneAppOTP 方法批准 MFA，表明攻击者在发起战役数日前就已注册好身份验证器应用；登录成功后沿用相同的侦察模式，主要由基于 Node.js 与 Microsoft Graph 的自动化系统执行。

步骤 5：注册新 MFA 设备以实现持久化

初始访问后，攻击者的首要目标是把临时沦陷转化为持久立足点。攻击者注册其控制的 MFA 方法——通常是登记新手机号、身份验证器应用或基于软件的 OTP 令牌——从而在被害者身份中插入一个攻击者控制的因子，使未来的身份验证挑战无需用户参与即可满足。MFA 注册本身无法在完整的凭据与会话重置后幸存，但结合失窃令牌、未撤销会话或后续对有效凭据的访问，它提供了持久的持久化机制；因此攻击者常在入侵早期建立 MFA 持久化，以提高长期维持访问的概率。

步骤 6：Microsoft Graph 侦察

建立 MFA 持久化后，攻击者以失陷身份发起广泛的内部侦察阶段，使用 Microsoft Graph 清点租户内的用户、组、权限、资源与可访问内容。攻击者在整个生命周期中刻意轮换基础设施，认证、侦察与外泄常使用不同 IP，因此还原完整入侵需要跨多阶段关联活动，而非依赖单一网络指标。

该攻击凸显一个关键检测难题：Microsoft Graph 滥用在单条 API 调用层面很少显得可疑——对 /users、/groups、/sites 等端点的请求在企业环境中司空见惯。但当同一身份、应用或访问令牌系统性地遍历多个租户资源、评估权限与身份验证设置、继而访问邮件/文件/附件/文档内容时，这些行为整体构成清晰的“侦察→外泄”链条。这强有力地说明：Graph 活动必须整体评估，重在行为演进与跨事件关联，而非孤立地看待单个 API 请求。

步骤 7–8：高吞吐云数据收集与疑似外泄

侦察之后，攻击者利用失陷身份转入跨 Microsoft 365 工作负载的大规模数据收集。Microsoft 观测到针对 SharePoint Online 与 OneDrive for Business 的高吞吐访问与下载，部分入侵延伸至通过 REST API 访问邮件内容的 Exchange Online；跨 SharePoint 与 OneDrive 的活动产生大量 FileAccessed 与 FileDownloaded 事件，表明对云托管文档与组织数据的系统性检索。

活动频繁呈现自动化而非交互式用户行为特征：多例中出现与高吞吐 SharePoint / OneDrive 访问模式关联的 python-httpx 用户代理。但仅凭用户代理不应判定为恶意，应结合数据量、受影响身份、源基础设施、先前侦察活动与身份沦陷证据综合评估。与“快进快出”不同，数据外泄通常是有节制且持续的，常跨数小时至数天；攻击者一般将收集节奏控制在任一小时内访问少于 1000 个文件或邮件，以此令活动混入正常企业用量，同时随时间逐步抽取大量敏感数据。

归因

Microsoft Threat Intelligence 评估认为，本战役中观测到的初始访问活动被一系列威胁行为者使用，包括 Storm-3121、Storm-3032 及其他。Storm-3121 实施的初始访问活动最终导向 ShinyHunters 与 Falcon 勒索；Storm-3032 代表从 BlackFile 组织分裂出来、现以 Helix 勒索旗号运作的一批行为者。Microsoft Defender 已对来自 Storm-3121、Storm-3032 及同一生态中其他操作者的已知战术、技术与过程（TTP）提供检测覆盖。

缓解与防护指引

Microsoft 建议组织将身份与云工作负载信号作为一个关联序列来调查，优先关注“异常登录→身份验证方法注册→Microsoft Graph 侦察→令牌签发→异常 SaaS 下载或邮箱活动”这一链条。

调查

审查具有风险或异常登录的用户的“新注册身份验证方法与设备”，在核实用户后移除未授权方法；调查涉及目录枚举、角色发现、服务主体发现、SharePoint、OneDrive 或敏感度标签发现的高吞吐或程序化 Microsoft Graph 活动；将 SharePoint / OneDrive 下载异常、Exchange REST 活动、邮箱或附件搜索与身份及身份验证事件相关联。

遏制与修复（确认失陷后）

对确认失陷的身份撤销活动会话与刷新令牌、重置凭据、移除攻击者注册的身份验证方法、移除攻击者创建的邮箱规则，并要求安全地重新注册身份验证方法。

降低未来风险

不要仅凭 IP 或域名匹配即下定论，应核实工作负载行为、受影响身份、持久化事件与数据访问量。通过 Conditional Access 强制抗钓鱼 MFA（FIDO2 / passkeys、Windows Hello for Business）；强制要求 Exchange、SharePoint 与 Graph 特权应用必须使用受管理、合规设备访问的 Conditional Access；对安全信息注册实施严格的 Conditional Access 控制（将所需登录频率设为 always、要求受管理设备/命名位置、要求以抗钓鱼 MFA 作为所需身份验证强度，并以独立策略在高登录风险条件下阻止安全信息注册）；对风险登录与风险用户实施基于风险的访问策略（以抗钓鱼 MFA 或安全改密修复高风险，在最高风险级别阻止访问）；培训用户识别针对 MFA 与 passkey 注册的语音与邮件钓鱼，并提供经核实的渠道上报非主动的身份验证请求；除非存在明确业务需要，否则通过 Conditional Access 阻止设备码（device code）与身份验证传输（authentication transfer）流程；限制用户对应用的同意、要求管理员审批，并定期审查持有 Mail.Read、Files.Read.All、Directory.Read.All 等高特权 Graph 权限的服务主体；限制非托管设备仅以“无下载/无同步”的 Web 会话访问，并在 SharePoint 与 OneDrive 中禁用匿名共享链接；启用 Microsoft Graph 活动日志与邮箱审计，并对异常枚举、身份验证方法注册与高吞吐文件/邮件访问告警；在教育培训上，任何由服务台发起的凭据或 MFA 重置前须通过严格流程核实用户身份，并对每一次此类重置告警。

了解更多

获取 Microsoft Threat Intelligence 社区的最新安全研究，请访问 Microsoft Threat Intelligence Blog（https://aka.ms/threatintelblog）；可在 LinkedIn、X（原 Twitter，@MsftSecIntel）与 Bluesky（threatintel.microsoft.com）上关注以接收新发布通知并参与讨论；收听 Microsoft Threat Intelligence 播客。相关文档包括：Zero Trust for AI 工作坊（https://microsoft.github.io/zerotrustassessment/）、Microsoft 365 Copilot AI 安全文档，以及如何使用 Microsoft Defender 保护 Copilot Studio 代理。

常见问题（答案均取自上述人类原文章节）

为什么 device code（设备码）流程能够绕过 MFA？

在设备码钓鱼中，用户被说服在合法的 Microsoft 身份验证页面上输入攻击者提供的代码，这一批准向攻击者控制的客户端签发合法 OAuth 令牌，从而无需窃取浏览器 Cookie 即可访问被许可资源。由于令牌本身就是攻击者拿到的东西（而非仅密码），且批准发生在微软合法认证页上，传统的第二重 MFA 质询被“用户主动批准”这一合法动作所满足，因此 MFA 被有效绕过。Microsoft 建议在无明确业务需要时通过 Conditional Access 阻止设备码流程。

确认身份失陷后，应立即执行哪些处置清单？

对确认失陷的身份：1）撤销活动会话与刷新令牌；2）重置凭据；3）移除攻击者注册的身份验证方法（新手机号、身份验证器应用、软件 OTP）；4）移除攻击者创建的邮箱规则；5）要求用户安全地重新注册身份验证方法。注意：仅重置密码不足以清除持久化——必须同步撤销会话/令牌并移除攻击者新增的 MFA 因子，否则攻击者仍可凭其控制的因子重新登录。

抗钓鱼 MFA（FIDO2 / passkey / Windows Hello for Business）在此战役中起什么作用？

本战役中攻击者用 passkey 话术把受害者引向 AiTM 反向代理或设备码流程，从而窃取凭据/会话令牌或获取合法令牌。抗钓鱼 MFA 将身份验证断言绑定到来源（origin），使 AiTM 代理无法在中途截获可用令牌，假冒的 passkey 诱饵也无法诱使绑定到错误来源。Microsoft 建议通过 Conditional Access 强制使用 FIDO2 / passkeys、Windows Hello for Business 等抗钓鱼 MFA，并配合要求受管理合规设备访问 Exchange / SharePoint / Graph 特权应用，以及基于风险的访问策略。