文章总结： 本文剖析不依赖密码窃取的两条攻击路径：一是利用陈年凭证与无MFA的SaaS本地账号，以Snowflake泄露事件为例，指出其因缺乏统一身份治理导致日志难审计，建议清理僵尸账号、强制MFA及IP白名单、接入SIEM并推进联邦化；二是通过JWT私钥失窃伪造令牌，以Storm-0558攻击美国政府邮箱为例，揭示崩溃转储含私钥且未脱敏、调试环境隔离失效等风险，强调密钥全生命周期管控、审计增强与验证逻辑完善。
综合评分： 85
文章分类： WEB安全,应用安全,安全运营,数据安全,安全建设

登录认证安全（中）不偷密码的入侵

原创

千里
千里

东方隐侠安全团队

2026年8月29日 01:37
江苏

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

上篇的三条路径，攻击者要么骗（AiTM钓鱼代理），要么偷（Infostealer拖库），要么磨（MFA疲劳轰炸），共同点是都在想办法突破认证环节。

而这篇的四条攻击路径完全不碰认证，让我们一起看一下实现细节。

路径四：陈年凭证 + 无MFA账号

和前面三个路径的利用不一样，路径四利用的是账号管理安全配置的不足。

T1110.004（Credential Stuffing，撞库）是拿A站泄露的密码去试B站，赌的是用户跨站复用密码，看运气的成分比较大；
T1078.004（Valid Accounts: Cloud Accounts，有效云账户）是直接使用偷来的目标账号凭证，这里可以参考路径二，购买log直接获取目标租户的账号密码。

成熟企业的身份生命周期是这样的：HR系统（入职/离职事件）→ AD/IdP（账号目录）→ SSO联邦（应用接入）→ 策略层（MFA强制、条件访问、密码轮换）。

在有统一认证体系的企业内网，IdP的目录范围代表安全管控能力的边界，只要是联邦进来的应用，账号全生命周期就有IdP托管，具体应用不需要在身份认证层面叠Buff。

但这套认证体系只是在本地管理上比较活泛，SaaS本地账号似乎是个例外。一般情况下，数据平台、云控制台、第三方工具的租户管理员，直接在产品控制台里给团队建账号，这些账号存在产品自己的认证存储里，不在IdP里。

它存在有合理性的一面：SAML集成要工作量，项目赶进度时先建本地账号是普遍操作；ETL任务、数据库驱动这类程序化访问也只能走本地凭证。

问题在于这个例外集合的属性：

数据仓库巨头Snowflake于2024年5月23日披露，其遭遇数据泄露，至少165家客户受到影响。由于Snowflake的客户包括LiveNation和桑坦德银行等行业巨头，此次事件极有可能成为历史上最严重的数据泄露事件之一。

Snowflake之所以被攻击，总结下来有如下原因：

客户租户的本地账号用用户名密码认证
MFA可用，但需要租户管理员主动开启
网络策略（IP白名单）可配置，默认不配

在讲路径二的时候，当时就说已经形成了一个供给体系：infostealer感染个人设备 → log入库 → 市场按域名检索。

路径四就是这套体系的定向应用，我们还是使用Snowflake事件来做案例说明：

所有Snowflake客户租户的访问域名都是<account>.snowflakecomputing.com。

这意味着买家在Russian Market这类市场的搜索框里输入snowflakecomputing.com一个词，返回的列表就是”全球范围内浏览器里存着Snowflake凭证、且设备被感染过的人”。每一条log都精确指向某个具体企业的数据仓库入口。不需要碰运气、不需要广撒网，检索即瞄准。

再看一条log是怎么积攒到四年后的：

某企业的员工或承包商，某次在个人笔记本上登录了公司租户（在家跑个报表、帮同事查个数），浏览器弹出”要保存密码吗”，点了保存。之后某个时刻这台个人设备被infostealer感染（伪装破解软件、假AI客户端，路径二第五步的感染渠道），凭证进log。设备可能早就清理了，人可能也都离职了，但企业内部这个SaaS应用的本地密码没换，log在市场的归档库里存放着。

这种利用陈年凭证 + 无MFA的攻击方式，是很难被日志审计察觉的：

我们很多时候都会面临这样的场景，当安全人员发现一些老账号的时候，运维或者开发团队常常说那是数据平台的自有账号，都已经深度使用了，不能随便更换或者停用。但这些账号不在IdP目录里，管不着，相关人员还会信誓旦旦说登录有密码保护着呢。

在Snowflake事件中，LOGIN_HISTORY通过SQL可以轻松查出：

SELECT&nbsp;event_timestamp, user_name, client_ip,
&nbsp; &nbsp; &nbsp; &nbsp;first_authentication_factor, second_authentication_factor,
&nbsp; &nbsp; &nbsp; &nbsp;reported_client_type, is_success
FROM&nbsp;TABLE(information_schema.login_history_by_user())
WHERE&nbsp;is_success =&nbsp;'YES'
ORDER&nbsp;BY&nbsp;event_timestamp&nbsp;DESC;

通过这条语句，就可以发现很多攻击者留下的痕迹，比如陌生IP、陌生客户端类型、secondauthenticationfactor为空（没开MFA）、登录后紧跟着全库盘点。

那漏掉攻击识别的原因是缺少这些日志数据吗，nonono，缺少的是发现这些价值数据的眼睛。

如何防御呢，网上能搜到一大把清单，这里讲讲落地时真正卡住的地方。

一是，最难的是”本地账号清零”。你去直接找业务说Snowflake出事了、账号要联邦化，对面回一句”系统跑着呢别动”，所以实际能推得动的做法是先跑一遍LOGIN_HISTORY，把两类账号挑出来：半年没人登录的、人已离职但账号还在登录的。拿这个清单去谈，可能会顺利一些，因为没人会为”别家出事了”停业务，但没人敢为”离职账号还在登录”辩护。

二是，MFA和IP白名单配置。数据类账号全部强制MFA，管理类账号加IP白名单，这两项在产品控制台里就是几个开关（Snowflake事后补的默认强制MFA，正是这个方向）。程序化访问的账号改走key-pair或OAuth短期凭证，这是工程活，排进季度。

三是，把LOGIN_HISTORY接进SIEM，要关注新IP/新设备登录、无第二因子的成功登录。前面那条SQL查出来的字段，本身就是这两条规则的数据源。

四是，联邦化按清单分批推进。先清僵尸账号（直接关），再迁活账号（约时间），过渡期保留的本地账号强制轮换、拒绝永久密码或永久token。SCIM自动化下线要同步上，不然今天清完，明天新员工入职又建出新的本地账号。

五是，要把把”SaaS控制台”写进资产清单，SaaS系统的用户要对自己系统的账号负责。这条不做，前面所有动作都会在半年后被新采购的SaaS悄悄清零。

路径五：签名密钥失窃与令牌伪造

这个路径主要运用的战法是T1649（Steal or Forge Authentication Certificates，窃取或伪造认证证书），这条攻击路径直接攻击的是认证方。

现在比较流行的云身份的运行时信任链，核心载体是JWT（JSON Web Token）。用户登录成功后，IdP签发的访问令牌就长这样：

eyJhbGciOiJSUzI1NiIsImtpZCI6IjFDMzBEQj... ←&nbsp;header
.eyJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29m... ←&nbsp;payload
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c&nbsp; ←&nbsp;signature

三段各自Base64解码后的内容：

// header：声明用什么算法、哪把密钥签的
{&nbsp;"alg":&nbsp;"RS256",&nbsp;"kid":&nbsp;"1C30DBJ9..."&nbsp;}

// payload：身份声明
{
&nbsp;&nbsp;"iss":&nbsp;"https://login.microsoftonline.com/{你的公司租户}/v2.0",
&nbsp;&nbsp;"sub":&nbsp;"6b1c2a3d-...",&nbsp;// 你这个人的唯一编号
&nbsp;&nbsp;"aud":&nbsp;"outlook.office365.com",&nbsp;// 这张通行证给谁看的
&nbsp;&nbsp;"exp":&nbsp;1718900000&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// 什么时候作废
}

签名是第三段：Sign(私钥, SHA256(header + "." + payload))。私钥只存在于IdP侧，从不外发。

资源服务器（比如Outlook服务）验证令牌的五步流程：

解析header → 取出kid（密钥编号）
拉取IdP公开的JWKS端点（公钥集合）→ 按kid找到对应公钥
用公钥验签 → 确认签名由对应私钥生成
检查payload：iss对不对（是不是我信任的签发者）、aud对不对（是不是发给我的）、exp过没过期
全过 → 放行

这套体系成立的前提是什么？答案是验签通过就意味着IdP亲自签发。这种情况下，资源服务器和IdP之间没有别的信任通道，签名的有效性承载了签发行为的真实性。

签名一般通过非对称加密算法来实现，在整个信任链上，私钥是唯一不公开的东西，也是唯一必须严防死守的东西。攻击者手里任何偷来的令牌都会过期、都只代表一个用户，但私钥没有过期时间，能签出任意用户、任意权限、任意受众的令牌。

为了解释这个攻击路径，我们通过2023年Storm-0558拿到了微软的一份消费者签名私钥，用它伪造身份直接读取美国政府官员的邮箱，持续六周且全程没有发生过一次异常登录，这个事件的全过程来做详细解读。

先问一个问题，Outlook怎么识别一个请求是合法用户发的？

你在公司电脑上打开Outlook网页版，输入公司账号，跳到login.microsoftonline.com验密码、过MFA，完成这些步骤后，微软的身份系统会下发给你一张”电子通行证”，用于提交给Outlook，这张通行证本质是JWT令牌。

Outlook收到请求里带的JWT令牌后，主要核验：签发者（是不是信任的登录服务）、接收者（是不是开给我Outlook的）、验签名。

在这个过程中，Outlook并没有给微软官方的身份系统询问”这张通行证真是你发的吗”，它完全靠自己验签判断。因为验签能通过，唯一的解释是持有私钥的一方亲手签的，按说私钥永远只在微软身份系统的服务器里。

2023年4月：一次普通的崩溃

微软的消费者签名服务（给hotmail、outlook.com个人账号签令牌的系统）某天崩了。服务崩溃本身在微软内部是日常事件。Windows的错误报告机制会自动：把崩溃进程当时的内存完整快照写进一个 .dmp文件，也就是”崩溃转储”。工程师拿到它，就能离线还原进程死掉那一刻的状态，排查原因。

而在这个完整快照里面，也有签名服务运行时保存在内存的私钥。

按照标准流程，转储文件在离开生产环境前应该经过脱敏，把密钥类材料过滤掉，但当时微软却没有做这个动作。

接下来工程师要按例分析这次崩溃，得在自己工位的机器上打开这个文件。于是这份含私钥的转储，按照微软自己制定的标准调试流程，从隔离的生产网络，被复制到了连接互联网的公司调试环境。

2023年5月前：攻击者进入微软调试环境

根据MSRC事后披露，攻击者此前已经攻陷了一个微软企业租户的账号，而这个账号恰好拥有调试环境的访问权限。他们在调试环境里能看到的，就是工程师们日常调试用的各种文件。

通过披露的情况来看，就是这伙进入调试环境的攻击者，把消费者签名私钥提取了出来。微软在国会听证会说的是：”由于日志保留期限的限制，我们无法确定攻击者是如何从转储中获取密钥的，但这是最可能的路径。”

翻译一下，其实就是：私钥确实从这里出去的，怎么出去的查不到了，因为当时的日志已经删了。

2023年5月16日：伪造开始

拿到私钥后，Storm-0558要伪造一张通行证。他们构造的JWT大概是这样的：

{
&nbsp;&nbsp;"iss":&nbsp;"https://login.microsoftonline.com/{某美国政府部门租户}/v2.0",
&nbsp;&nbsp;"sub":&nbsp;"6b1c2a3d-...",&nbsp;// 目标官员的对象 ID
&nbsp;&nbsp;"aud":&nbsp;"outlook.office365.com",
&nbsp;&nbsp;"exp":&nbsp;<未来时间>
}

然后用偷来的私钥签名，直接发给Outlook的接口。

按设计，这张假通行证应该无法生效。因为微软同时跑着两套身份体系，分别是消费者体系（MSA，管hotmail、Xbox这些个人账号，有自己的密钥）和企业体系（Azure AD，管全世界的公司租户，有另外的密钥）。

按照两套体系的设计，应该是两套体系钥匙互不相通，也就是说消费者钥匙签的令牌，不能当企业令牌用。要注意，这时候攻击者只持有消费者体系的私钥。

但Outlook验证流程执行后却成功了。它拿令牌的签名去公钥集合里对，对上了（这把钥匙的公钥确实在可用的公钥集合里）；看接收者，也对上了；看签发者字符串，攻击者用真实私钥签发的，也对上了。

乌龙发生了，原来缜密的验证流程，却自相矛盾的给另一个体系的签名验证通过了，因为没有检查”这把钥匙有没有资格给这个签发场景签名”。

2023年5月-6月：六周的邮件阅读

从5月16日起，Storm-0558用伪造的通行证开始读邮箱。受害名单最终确认为25个组织，几乎全是美国政府机构：国务院、商务部包括商务部长Gina Raimondo本人的邮箱、多名国会议员办公室。据统计，单美国国务院一家被读走的邮件就有6万封。

2023年6月16日：终被发现

美国国务院的安全团队，在6月中旬注意到某个邮箱出现了反常的访问行为，访问频率、访问方式不符合这个邮箱主人之前的使用习惯，一步步查下去，才发现这条伪造令牌的链路。并最终在6月25日由微软完成处置，修补验证逻辑、更换密钥、封堵伪造令牌。

需要注意，美国国务院安全团队能有权限与能力发现这个问题，还需要两个条件。第一，他们买的是E5级许可，开着增强审计，能够实现邮箱每一次被谁访问（MailItemsAccessed事件）都记在资源侧日志里；第二，他们的安全团队在花人力物力解读这些日志，并有一些行为分析模型来做技术支撑。当然事件之后，微软也宣布把基础审计日志免费开放给所有客户。

事实上，这个攻击模式有很多变种，比如：

黄金票据（2014起）：偷Windows域控上KRBTGT账户的哈希，之后想给域里任何人签Kerberos票据就签——整整十年前AD攻击的必修课
黄金SAML（2019起）：偷IdP的SAML签名证书私钥，伪造任意用户的登录断言，一个断言横跨受害企业的整个云租户
JWT私钥伪造（本文，2023）：偷OIDC体系的令牌签名私钥——同一个思路，搬到了云身份时代

攻击者攻击的重心都是想方设法获取算法所使用的密钥。密钥要在内存里用（所以进崩溃转储）、要在系统间流转（所以进调试环境）、要有人管理（所以有内部账号可以被攻陷）。只要有一处泄漏，整个认证体系就会失效。

密钥管理的整改，我有如下建议：

一是，私钥要使用HSM（硬件安全模块）相关的产品。签名运算在硬件里完成，私钥在常规进程内存里根本不出现，崩溃转储想泄密都没有泄密的对象。

二是，要把内存转储文件纳入敏感资产。任何要离开生产环境的内存快照，先做内容级的密钥材料扫描；调试环境的访问账号按线上资产对待，但是在很多公司，这件事的阻力在于”从来没出过事”为什么要做。

三是，资源侧审计全量开。本案唯一的目击者是邮箱访问日志（MailItemsAccessed事件），美国国务院能看见是因为买了E5开着增强审计，其余受害组织连目击者都没有。日志的存储成本和”出事后没有证据”的代价，放到一起算，这笔账不难算。

四是，修改评估方法论，密钥泄露的影响面按”密码学能力”评估，不按”已观测到的滥用”评估。微软最初评估”风险较低”，理由是没观测到大规模滥用，但其实Wiz的后续研究将他狠狠打脸，私钥理论上能签的受众远不止邮箱。观测不到滥用，可能是因为没开审计，也可能是因为攻击者还是比较克制的。

路径六：OAuth恶意应用

回顾前面的攻击路径：路径一偷会话（AiTM）、路径二买凭证（infostealer）、路径三让受害者开门（MFA疲劳）、路径四专挑没锁的门（陈年凭证）、路径五偷公章（密钥伪造）。

路径六是全新思路：让用户自己把权限授予给攻击者。

T1528（Steal Application Access Token，窃取应用访问令牌）对应OAuth授权码被盗、令牌落入攻击者之手；T1190（Exploit Public-Facing Application，利用面向公众的应用）在本文语境里对应攻击者把恶意OAuth应用本身当作利用面，部署一个看起来合法的应用等用户来授权。

先把OAuth 2.0授权码流程（企业里最常见的一种）的完整链路摆开。

假设有这样一个场景：你用一个第三方日程工具（AppX），它需要读你的日历。

1.你在AppX里点”连接日历”

2.AppX跳转浏览器到微软的授权端点：

https://login.microsoftonline.com/{你的租户}/oauth2/v2.0/authorize
&nbsp; &nbsp; ?client_id=xxx ← AppX 在微软注册的应用 ID
&nbsp; &nbsp; &redirect_uri=https://appx.com/callback
&nbsp; &nbsp; &scope=Calendar.Read ← 申请的权限
&nbsp; &nbsp; &response_type=code
&nbsp; &nbsp; &state=xyz

3.你看到微软官方页面：”AppX请求读取你的日历” → 点”接受”

4.微软跳回https://appx.com/callback?code=AUTH_CODE（授权码，5-10分钟有效，只能用一次）

5.AppX后端拿code + client_secret去令牌端点换正式令牌：POST /oauth2/v2.0/token → 返回access_token（1小时）+ refresh_token（90天，可续）

6.AppX用access_token调Graph API读你的日历

7.access_token过期后，AppX用refresh_token自动换新的——无需你再登录、无需你再点任何东西，最长可滚动续期90天

这套流程设计上非常聪明，第3步到第5步就是它聪明的地方：密码全程只在第3步出现（在微软页面输入，AppX碰不到），之后全依赖生成的令牌，可以确保用户不需要把密码交给第三方，第三方拿到的令牌又限定死了权限范围（scope）。

而这条链放到攻击者眼里，却产生了如下攻击成功的可能性：

第3步的”接受”是一次性的、不可撤销粒度的：用户看到”读取日历”，点接受，那么Calendar.Read这个权限就给出去了。但同一个scope体系里还住着Mail.Read（读全部邮件）、Contacts.Read（全部通讯录）、User.ReadWrite.All（改用户资料）。弹窗上多列一行待读取的资源，用户一般难以分辨或者关注
第5步拿到的refresh_token生命周期是90天起：授权一次，访问权90天。这90天里用户即使依赖密码过期策略有过更改，但refresh_token并不依赖密码而存在，仍旧可以实现90天有效
第6步的流量走Graph API：与用户本人访问的流量走同一条通道、用同一个身份。邮件被API批量读取时，在日志里与用户用手机Outlook收邮件无法区分，除非有人专门分析API调用模式，因此难以进行异常行为分析

那在这种条件下，该怎么实现所谓的OAuth钓鱼呢？那就是攻击者把自己注册的应用塞进上面第2步的位置，诱导用户完成第3步。

我们接下来以2022年被广泛分析的伪GiftedOutlaws（”诸侯”）行动为例：

准备阶段——注册一个看起来人畜无害的应用：

攻击者在 Microsoft/Google 注册应用：
&nbsp; 名称:&nbsp;"PDF Editor"、"Calendar Enhancer"、"Sign-In Validator"......
&nbsp; 图标: 仿知名软件
&nbsp; 权限申请: Mail.Read、Contacts.Read、User.ReadBasic.All
&nbsp; redirect_uri: 指向攻击者控制的回调地址

注册成本: 一个免费账号，几分钟，不需要任何企业资质审核

微软/Google的应用注册是开放的，任何拥有账号的人都能注册应用、申请这些读权限。平台对”读取全部邮件”这类高敏scope的审核，当时（现在依然）依赖事后滥用检测，而非事前人工审核。

投递阶段——把授权链接送进用户邮箱：

邮件正文示例（真实样本改写）：

"We tried to deliver your document but you are not enabled to
view&nbsp;files&nbsp;sent from your employees.

[ Click here: hxxps://login.microsofthelp[.]com/?client_id=... ]

You will&nbsp;be&nbsp;automatically redirected&nbsp;to&nbsp;the document after&nbsp;sign-in."

链接指向的不是微软官网，是攻击者注册的应用发起的OAuth授权端点。用户点击后跳到的是真正的微软登录页（第2步的授权页是微软托管的），页面显示”PDF Editor想要读取你的邮件”。

这时候，域名是真的、证书是真的、登录流程是真的。用户登录并点”接受”，第3步完成。

收割阶段：

用户点完接受，redirecturi指回攻击者，授权码到手，refreshtoken也被攻击者获取。由此：

攻击者每90天滚动续期，持续读邮件
读邮件可以接收下一层钓鱼邮件的验证码、看MFA重置邮件、了解组织架构（谁管谁、谁和谁常联系）定向下一轮
兴趣列表显示这类行动的目标集中在教育、政府、国防承包商、中小企业，这又恰好是MFA普及率不那么高的那批组织，同时是邮件里高价值内容（课件、标书、人事）密度最高的那批
循环利用过程：看到密码重置邮件 → 用邮件里的链接发起重置 → 新密码发到这个被监控的邮箱里 → 账号所有权完成转移，全程不需要碰任何MFA

这条路径的伪装性有多高呢，我们可以分析一下：

| 动作 | 平台视角 | 用户感知 |
| — | — | — |
| 注册应用 | 开放平台的正常开发者行为 | 无 |
| 发钓鱼邮件 | （邮件投递本身） | 收到”无法查看文件”提醒，点链接 |
| 跳授权页 | OAuth正常流程 | 看到微软官网，登录（放心） |
| 点”接受” | 用户同意授权（有用户点击记录） | “读取邮件？应该的，看文档嘛” |
| 换令牌 | 授权码流程正常运转 | 无感知 |
| 读邮件 | Graph API正常调用，身份是用户本人 | 无 |
| 90天续期 | refresh_token机制设计如此 | 无 |

因此，一切的一切，都发生于用户点”接受”的那一刻，之后的一切API调用，攻击者都通过冒用这个用户的身份。

防御方法有这些步骤：

第一步，关掉用户自主同意（Entra ID → Consent preferences），或限定白名单scope，所有应用授权走IT审批。这是个当天能完成的配置变更，直接消灭GiftedOutlaws的攻击入口。这种情况下，用户不用私自完成点击”接受”，攻击者的应用永远拿不到授权码。

第二步，OAuth授权列表的定期审计。每月一次全量导出，diff上月的差异。正常企业的授权列表变化很慢，每月新增的那几个，一封邮件就能检查完。

第三步，高敏scope告警进SIEM。Mail.Read、Contacts.Read这类授权事件，任何新增都人工确认。前面说过，这条路径从授权到被发现平均隔着很久，告警的价值就是把”很久”压到当天。

第四步，进行用户教育。比如”看到授权弹窗多想一秒”这样的意识培养，也是有价值的。

路径七：恢复流程劫持

回到开头那个Reddit问题：”登录本身完全合法，零告警，怎么检出？”

前六条路径给了六种答案，第七条是最极端的一种：这次登录确实合法，密码是正规流程重置的，MFA设备是正规流程注册的，每一步都有工单、有审批、有审计记录。系统没有被骗，系统只是按流程办事。

路径七的技战法是：

T1566.004（语音钓鱼，vishing）打电话时攻击的第一步；
T1098.005（账户操纵：设备注册）把攻击者自己的设备注册成账号的合法MFA因子。

现在，请大家思考每个MFA体系都躲不掉的问题：用户手机丢了怎么办？

换手机号、丢硬件钥匙、手机掉水里，这些是真实日常可能发生的事情。如果没有任何补救机制，用户会被永久锁死在账号外面，IT服务台会被打爆。所以每个身份体系都必须有一条恢复流程（account recovery）：忘记密码、丢失全部因子时，证明”我是这个账号的主人”，然后重置一切。

那么，在一个因子都不持有的前提下，怎么判定确实是用户本人呢？

我们平时可能多用人脸识别或者证明自己知悉隐秘的相关业务信息，来证明我们就是用户本人，但是业界更多充斥着这些方案：

MGM Resorts（美高梅，拉斯维加斯最大的赌场集团之一，旗下百乐宫、Mandalay Bay都是它的）。

2023年9月11日，一场针对它的攻击开始了：

1.准备工作。10分钟的LinkedIn研究。攻击组织Scattered Spider（Mandiant编号UNC3944，微软称Octo Tempest，一群19-22岁的英裔美国年轻人，后来多人被捕并在庭审中供述了作业细节）在LinkedIn上找到一名MGM员工。公开资料里的姓名、职位、工号、在职时间，帮助台核验身份要问的那些东西，LinkedIn上都有。

2.打电话。攻击者致电MGM的IT服务台，冒充这名员工：”我换了个新手机，MFA迁移不过去，账号锁死了，帮我重置一下。”服务台按流程核验身份，问的问题，第一步已经基本可以找到答案。

3.成功重置。服务台执行了密码重置、清除了原有MFA绑定。这是服务台每天做几十次的标准操作，工单、审批、审计记录一应俱全。

4.注册自己的设备。重置完成后，攻击者立刻在MFA流程里注册了自己的设备，这一步之后，攻击者持有的是这个账号的合法第二因子。

5.进入与横移。MGM的身份平台是Okta，攻击者用新因子登录后横向移动，在内网找到了一个权限极高的服务账号，据报道该账号拥有域管级别的权限。9月11日，ALPHV/BlackCat勒索软件落地，同时照例做了双重勒索（加密 + 窃数据威胁曝光）。

6.业务崩溃。赌场是7×24小时的现金业务，断网等于停业。MGM最后认下的损失约1亿美元。

针对帮助台的整改，首先要分析到这个帮助台地位极其重要，已经相当于身份体系的根CA，可以这么认为，只要坐席说这个人是本人，系统就认定是本人。因此，根CA的核验强度必须匹配它的权力。

需要在三方面进行提升：注册时预存一组只有本人知道的口令短语（核验时问，LinkedIn上查不到）；回调已登记的号码而非来电号码（SIM劫持防不了，但冒充来电防得住）；高敏操作（MFA重绑、恢复方式修改）要求二次核验或管理审批。

重置动作要”冷却”：密码重置或因子重绑后的几小时内，限制敏感操作，比如改恢复邮箱、注册新因子、下载通讯录。MGM的攻击链是”重置→立刻注册自己的设备”，中间只要插进一个几小时的冷却期，社工制造的紧迫感就撑不住了。真实用户换机会觉得麻烦，但能接受；攻击者的时间线断在这里。

检测规则需要补充：密码重置 → MFA因子变更 → 新设备登录，短窗口内三连，在正常用户身上是低频组合，可以直接建告警。

制度增强：员工公开信息与核验问题解耦。Scattered Spider用10分钟的LinkedIn研究就凑齐了核验答案，说明核验问题本身已经公开化，公开信息一律不能作为核验依据。

为什么传统检测全都失效

回归到思考开头Reddit那个问题”登录完全合法、零告警，怎么检测？”

现在可以给出完整的结构性回答。先把七条路径和传统检测层做个全面交锋：

总的来说，存在三种类型的绕过：

绕过一：一般的安全软件检测传统上的异常事件，而这些攻击只从单条行为日志看基本都是正常事件。一般所关注的失败登录（暴力破解）、恶意进程（恶意软件）、异常流量（DDoS/扫描）、恶意签名（病毒），在上述的七条路径里都没有触发，全部都是密码对的、流程合法、令牌验证无误、授权是用户亲手点的。

绕过二：实质攻击行为的出现是必然滞后的，而传统的身份认证平台，比如MFA的全部检查只发生登录那几秒的过程。路径一的Cookie重放发生在登录之后数小时、伪造令牌压根跳过登录、refresh token让一次点击管九十天——检测全押在登录环节，攻击全部发生在登录之后。

绕过三：账号资产并没有全面管理和监控。SaaS本地账号不在IdP目录（路径四）、完整审计日志当年是付费特权（路径五，美国国务院能看见是因为买了E5）、帮助台是电话流程不是系统（路径七）。这些资产从创建之初，就没被当成身份资产登记进监控清单。

三种绕过方式共同指向一个结论：问题不在检测能力，在检测对象。检测全部压在认证环节（密码对不对、因子全不全），而七条路径里有四条根本不经过认证——会话重放、令牌伪造、用户亲手点的授权、帮助台发起的重置，每一条都在检测覆盖范围之外。这也就是ITDR这个品类安全产品要解决的问题。

七条路径全部摆完，传统检测为什么全线失明也有了答案：不是检测能力不行，是检测对象错了。

下篇讲ITDR，为身份认证攻击找一个出口，敬请期待～

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：东方隐侠安全团队千里
千里《登录认证安全（中）不偷密码的入侵》

Tags: WEB安全安全建设安全运营应用安全数据安全

你可能错过

智能漏洞挖掘工作台：静态分析 → 模糊测试（AFL++）→ 崩溃分析 → CNVD 报告闭环

HTTPS时代：企业如何用好流量分析产品

深度硬核 | 区块链变身C2跳板？新型JS远控木马攻击链全解析

Agent 想攻击我的网站？say,NO !