问题背景

公司办公协作与 VPN 入口接入了统一身份认证平台，管理员与高权限账号普遍开启了「推送确认」式 MFA：手机 App 弹出「是否允许登录」→ 点同意即可完成第二因子。表面上比短信 OTP 更省事，也规避了短信被劫持的风险，因此在推广时被当作「最佳实践」全量落地。

某周一早高峰前约 20 分钟，值班群突然收到 NDR 告警：境外 IP 成功登录了一名域管理员的 SaaS 控制台，随后出现了异常 API 调用与新建子账号尝试。当事人坚称自己没在出差、没丢手机，但也承认「凌晨手机弹了十几次登录确认，烦得不行随手点了一次同意」。看似「MFA 都开了还被打穿」的诡异事故，实际指向一类近年明显抬头、却仍常被忽视的攻击手法——MFA 疲劳攻击（MFA Fatigue / Push Bombing）。

故障现象

1. 告警侧：安全平台在 06:12 报「高权限账号异地登录成功」；来源 IP 归属境外云厂商 ASN，与当事人常用出口完全不符；UA 为常见自动化库特征，并非公司标准浏览器。
2. 当事人侧：凌晨 01:30–02:10 期间手机 Authenticator / 企业 MFA App 连续弹出 20 余次登录确认；当事人在半睡半醒状态点过至少一次「允许」，之后把通知静音继续睡。
3. 会话侧：控制台审计显示该账号在同意推送后约 40 秒建立会话，随即枚举组织成员、尝试创建低权限运维子账号、拉取部分敏感配置导出任务；部分动作被既有 Conditional Access / 权限边界拦下，但已完成的登录会话本身合法。
4. 表象矛盾：密码没有泄露告警（实际可能已通过钓鱼/凭证库撞库获得）、MFA 日志显示「用户已批准」，SIEM 初看像「本人误操作」，容易被误判为误报而放过。

业务侧暂时没有大规模中断，但若攻击者再走一步完成权限持久化或改邮件转发规则，后果会从「惊出一身汗」变成「真出事」。

排查过程

1. 先按账号被接管应急，而不是先争辩「是不是本人点的」

接到告警后，值班按高权限账号失陷流程处理，而不是跟当事人纠缠「你到底点没点」：

• 立即在 IdP 强制签退该账号全部活动会话（SaaS + VPN + 邮箱相关 SSO）
• 禁用该账号临时登录，改由备用紧急管理员接管变更窗口
• 吊销其现有 Refresh Token / App Password / 个人访问令牌（PAT）
• 保留完整审计日志与 MFA 推送记录，禁止「先重置再看」把证据冲掉

这一步很关键：疲劳攻击的特点是 第二因子在日志里显示「用户批准」，如果先按误报关闭工单，会把真正的会话窗口白白留给攻击者。

2. 对照 MFA 推送时间线与登录审计

把 IdP 的 MFA challenge 日志与 sign-in 日志按时间对齐后，时间线非常干净：

当事人口述与日志高度吻合。攻击者不需要拦截短信，也不需要突破 TOTP 种子，只需要：已经掌握密码 + 把推送点得你生不如死 + 赌你会有一次手滑点同意。

3. 核实密码从哪来，排除「纯撞库碰运气」

继续追查第一因子：

• 密码管理/暗网监测：该管理员旧邮箱曾出现在历史泄露集合（一年前某外部站点），存在凭证复用可能
• 邮件网关：前两周有一封仿冒「VPN 证书即将过期，请立即重登」的钓鱼邮件被当事人点过链接；链接指向高度仿冒的 SSO 页（证书与域名只差一个字符级欺骗）
• 浏览器扩展与主机 EDR：未发现木马或会话劫持痕迹，主机本身干净

综合判断：第一因子大概率来自钓鱼页收获的当前密码，第二因子则靠疲劳攻击「社会工程掉」。这不是 MFA 失效，而是 推送确认这种「用户可被烦到投降」的 MFA 形态被针对了。

4. 评估横向与持久化是否已落地

接管窗口大约 10 分钟，我们重点核验：

• 是否新建了后门用户 / 应用注册（Enterprise Application）/ 高权限 OAuth 授权
• 是否改了邮箱收发规则、委派、邮件转发
• 是否下载了密钥、证书、备份码、API Token
• 是否在 VPN / 堡垒机侧留下新的设备信任

结果：新建子账号动作被角色边界拒绝；发现 1 条草稿态的邮件转发规则未生效即被我们删掉；未发现新的应用注册与持久化令牌。整体属于 早期发现、损失可控，但路径已经完整跑通，绝不能只「重置密码了事」。

5. 对照控制策略，定位「为何推送能被炸 20 多次」

在 IdP 策略里发现几个放大问题的配置：

1. MFA 方法优先级把「手机推送」放在第一位，未对管理员强制更强因子（FIDO2 / 硬件密钥 / 数字 TOTP）
2. 无「推送频率/拒绝阈值」熔断：同一账号短时间海量 push 不会自动锁定或降级验证
3. 异地 + 高风险登录只做了告警，没有「必须强校验」的 Conditional Access 阻断
4. 管理员备份码存在个人备忘录明文，存在二次泄露面（本次未用到，但是隐患）
5. 用户侧 没有「我并未尝试登录，一键举报并锁号」的显式入口教育，大多数人只知道点允许/忽略

到这里根因链完整：密码被钓鱼 → 推送 MFA 可被轰炸 → 用户疲劳误点 → 会话建立 → 高权限操作窗口打开。

解决方案

止血（分钟级）

1. 强制下线并临时禁用被接管账号，轮换密码与全部会话令牌
2. 撤销可疑 OAuth 授权、删除未生效转发规则，全量审计近 24h 目录变更
3. 对该管理员改用 临时硬件密钥 + 排除推送 的紧急登录方式恢复工作
4. 对同类高权限账号做一次「是否存在异常 Approved 推送」回溯扫描

根治（策略与形态改造）

1. 高权限账号禁用纯推送 MFA
   域管、云管、VPN 超级管理员、CI 管理员一律改为：

   • FIDO2 / 安全密钥（首选）
   • 或 号码匹配（Number Matching）推送（必须输入屏幕随机码，不能盲点同意）
   • 或 TOTP 作为过渡，但禁止「一键 Allow」

2. 打开号码匹配与推送风暴防护

   • 启用来源侧显示的两位数/三位数核对，用户必须输入才能通过
   • 同一账号 N 分钟内推送超过阈值 → 自动锁定 + 告警到 SOC
   • 连续拒绝/超时达到阈值 → 视为攻击，触发密码重置工单

3. Conditional Access 收紧

   • 管理员角色：禁止未知国家/非托管设备直接过
   • 高风险登录：强制「更强因子」而不是「再推一次同样的 Allow」
   • 敏感操作（改 MFA 方法、加全局管理员、导出密钥）二次认证且审计

4. 第一因子治理同步做

   • 全员禁用已知泄露密码复用（与 Have I Been Pwned 类接口对接）
   • 高仿冒 SSO 域名加入网关拦截与浏览器安全标记
   • 管理员禁止在个人备忘录存备份码，改用离线保险柜/密封信封流程

5. 演练与宣教

   • 把「手机半夜疯狂弹 MFA」写进安全意识课：正确动作是 全部拒绝 + 上报 + 改密，而不是点掉了事
   • 红队每季度做一次可控的疲劳攻击演练，验证熔断是否生效

根因分析

一句话：不是“开了 MFA 就安全”，而是“开了哪种 MFA、对谁开、炸了会不会熔断”共同决定上限。 疲劳攻击精准打在「人会烦、会手滑」这一环。

预防措施

1. 权限分级 MFA 矩阵（写进制度，不只是建议）

   • 普通员工：号码匹配推送或 TOTP
   • 管理员 / 能碰生产变更的角色：FIDO2 强制，禁用一键 Allow
   • 突破玻璃账号：双人保管硬件密钥

2. 把「推送轰炸」做成独立检测用例
   SIEM 规则示例：mfa_push_count > 5 in 10min AND approved == true AND impossible_travel → 自动锁号 + P1 工单，不等人工研判。

3. 定期审计 MFA 方法登记表
   谁还在用 SMS、谁还在用无号码匹配的 push、谁登记了过多备份设备，按季度出清单整改。

4. 钓鱼与凭证泄露前置拦截
   邮件网关强化仿冒 SSO 检测；密码策略禁止复用；高权限账号缩短会话寿命、禁用长期 PAT。

5. 应急手册补一页
   「收到异常 MFA 推送」标准动作：全部拒绝 → 官方渠道改密 → 通知 SOC → 检查邮箱转发/应用授权。把「点同意图清静」明确列为违规操作。

总结

这起事故里，攻击者没有绕过密码哈希，也没有攻破 TOTP 种子，只是用已经到手的密码配上一轮「推送到你崩溃」的社会工程，让管理员自己完成了第二因子。日志里干干净净写着 Approved，若只看表面，会误判成「用户误操作」。

处理顺序应当是：先当失陷封会话，再对齐推送与登录时间线，再追第一因子来源，最后改 MFA 形态与熔断策略。技术上优先把管理员从「一键 Allow」迁到 FIDO2 或号码匹配；运营上把推送风暴做成自动锁号信号。MFA 仍然值得做，但选错形态、又缺少阈值防护时，它会从盾牌变成催人点同意的门铃。