邮箱账号被接管后，为什么只改密码不够？会话与令牌该怎样彻底吊销？

「账号被盗了，赶紧改密码」是几乎所有人的第一反应。这个动作本身没错，但把它当作处置的终点，是账号接管（Account Takeover，ATO）事件中最常见、代价也最高的一个误判。

现代邮箱的访问路径远不止口令一条。至少还有以下几类，它们在改密码之后并不会自动失效：

• OAuth 令牌。RFC 6749 定义的 access token 是「持有即可用」的凭据——资源服务器只校验令牌本身，不会回头去问「这个用户的口令改了没有」。与之配套的 refresh token 生命周期更长，其设计目的正是在 access token 过期后无需用户再次参与就换出新的 access token。
• 已建立的 IMAP／POP 连接。RFC 9051 定义的 IMAP 会话在认证通过后进入已选中状态，只要 TCP 连接不断、服务端不主动踢，就可以持续收取邮件。
• 应用专用凭据。为不支持现代认证的客户端单独签发的凭据，通常独立于主口令管理。
• 邮箱委托与共享权限。攻击者若已把自己或某个受控账号加为代理人，改口令对这条路径毫无影响。

结论很直接：口令重置切断的是「重新登录」这条路，切不断「已经在里面」的那些路。处置必须把这些路径逐条覆盖。

顺序错了会造成两种后果：要么打草惊蛇让攻击者抢先破坏证据，要么留下缺口让其重新进入。建议按下列次序执行：

1. 先固定证据，再动配置。在做任何变更之前，先把当前的登录记录、邮箱规则、转发设置、委托权限、已授权应用列表导出留存。很多关键证据在你「清理」的那一刻就永久消失了，而这些恰恰是后续判定影响范围的依据。
2. 吊销全部会话与令牌。这一步应当与口令重置同时或紧接着完成，而不是等到几小时后想起来再补。
3. 重置口令，并要求下次登录强制改密。
4. 清理持久化手段。邮箱规则、自动转发、委托、应用专用凭据、OAuth 授权同意，逐项检查并清除非预期项。
5. 重新登记多因素认证。攻击者可能已注册了自己的第二因素。只重置口令而保留攻击者注册的 MFA 方法，等于把门锁换了却把新钥匙留给对方。
6. 最后才是恢复正常使用，并进入一段加强观察期。

NIST SP 800-61 Rev. 3 把事件响应放在 CSF 2.0 的框架下组织，强调遏制、根除与恢复不是一次性动作，而是需要与持续的检测、分析回路配合。上述顺序的实质，就是让「遏制」先于「根除」，让「根除」先于「恢复」。

RFC 7009 为 OAuth 2.0 增加了一个吊销端点（revocation endpoint）。客户端向该端点发起请求，携带 token 参数即待吊销的令牌，并可选携带 token_type_hint 参数提示令牌类型，其取值包括 access_token 与 refresh_token。

响应行为有两点值得注意，它们直接影响处置时的判断：

• 授权服务器吊销成功时返回 HTTP 200。而且——若客户端提交的令牌本来就是无效的，服务器同样返回 200。这一设计的用意是让吊销操作具备幂等性，客户端不必区分「本来无效」与「刚被吊销」。但对处置人员而言，这意味着「收到 200」并不等于「确实有一个活跃令牌被干掉了」，不能拿它当作影响范围的证据。
• 吊销 refresh token 的连带效果。RFC 7009 指出，若被吊销的是一个 refresh token，且授权服务器支持吊销 access token，则应当同时使基于同一次授权许可（authorization grant）签发的全部 access token 失效。因此优先吊销 refresh token，收益远大于逐个吊销 access token。

还有一个必须承认的现实边界：access token 是否立刻失效，取决于资源服务器如何校验它。如果资源服务器采用自包含令牌（令牌自带签名与有效期，无需回源查询），那么在令牌自然过期之前，它仍可能被接受。RFC 9700 作为 OAuth 2.0 安全最佳实践，对令牌的生命周期与绑定提出了系统性建议，其中就包括缩短 access token 有效期这一方向。

处置时的实际含义：吊销之后仍需保持一段观察期，直到覆盖最长的令牌有效期为止，不能吊销完就宣布结束。

协议层说清楚了「为什么」，落到具体平台还要知道「点哪里」。以下按能力类别归纳，具体入口以各平台官方文档为准。

1. 强制吊销用户全部刷新令牌与会话 Cookie。Microsoft Entra ID 提供了在紧急情况下吊销用户访问权限的操作路径，Microsoft Learn 的《Revoke user access in Microsoft Entra ID》一文对适用场景与影响作了说明；Google Workspace 管理控制台也提供了强制用户退出全部会话、重置登录 Cookie 的管理员操作。注意区分「让用户退出登录」与「吊销刷新令牌」——前者可能只清了浏览器会话，后者才真正断掉后台应用的持续访问。
2. 撤销可疑的 OAuth 应用授权同意。把该用户已授权的第三方应用逐个过一遍，撤销非业务必需的授权。
3. 作废应用专用凭据。全部作废后重新签发，不要挑着废。
4. 断开长连接。确认服务端在口令变更后是否会主动终止已有的 IMAP／POP 会话。不少部署的默认行为是不终止，需要显式配置或手工断开。
5. 重置 MFA 注册。清除全部已注册的认证器，要求用户在受控条件下重新登记。NIST SP 800-63B 对认证器的绑定、更换与失效管理提出了要求，重新登记环节本身也需要有身份核验，否则会成为新的薄弱点。

Microsoft Learn 的《Responding to a compromised email account》提供了一份面向失陷邮箱的处置流程，可作为动作清单的对照参考。

处置动作做完不等于生效。必须有一个独立的验证环节，否则很容易出现「以为处置完了，攻击者其实还在」的情况。

• 看认证日志有没有「断点」。吊销之后，来自可疑来源的成功认证记录应当归零。若仍有成功记录，说明还有未覆盖的凭据路径。
• 看邮件访问审计有没有继续。邮箱项目被读取、被外发的审计记录，是判断攻击者是否仍在的直接证据，比登录记录更贴近实际影响。
• 看令牌颁发记录。吊销后若仍观察到基于旧授权的令牌刷新成功，说明吊销未覆盖到该授权许可。
• 覆盖最长令牌有效期后再复核一次。这一步专门用来兜住自包含 access token 的残留窗口。
• 检查规则与转发有没有被重新创建。如果攻击者尚未被完全驱逐，被删掉的转发规则往往会在短时间内重新出现。这是判断「是否真的清干净了」最灵敏的一个指标，值得单独设置告警。

把上述验证项固化进处置单，作为事件关闭的必要条件——没有验证记录的处置，不能算处置完成。