凭据复用与横向移动
凭据复用的核心假设很简单：一个服务泄露的凭据，往往在其他服务上同样有效。运维与用户在多个系统里重复使用同一组密码或同一把密钥是常态。因此每拿到一组新凭据，都应立即在已发现的全部入口重放一轮，这通常比继续爆破更快打开局面。
仅限授权环境
凭据重放会产生认证日志并可能触发账户锁定，仅在授权范围内对已发现的入口做验证。
常见泄露源到重放面
| 泄露源 | 可重放面 |
|---|---|
Redis requirepass | FTP、SSH、数据库 |
wp-config.php / config.php 的 DB 密码 | SSH、su |
.env 文件（MQTT/DB/API 密钥） | 对应的各类服务 |
| 明文密码文件 | su、SSH |
| 配置中加密串解密后 | 远程管理协议 |
交叉复用关系
账号清单本身也藏着关系。从 DNS 枚举、邮箱枚举得到的账号列表里，**"A 的密码是 B 的用户名"**这类关系要专门试：用户名与密码互换、人名与机器名组合、服务名做后缀等变体都值得生成后重放。
重放方法
# SSH 与 su：直接试
ssh '<user>'@<host>
su '<user>'
# sudo：用 -S 从 stdin 喂密码
echo '<pass>' | sudo -S id
# 数据库
mysql -u '<user>' -p
redis-cli -a '<pass>'
# Web 面板：逐个登录验证
工作节奏
把"重放"固化成习惯动作，而不是想起来才做：
- 每拿到一组新凭据，立即在全部已发现入口（人 + 机器 + 服务）重放一轮。
- 按人名、机器名、服务名三个维度生成组合变体再试一轮。
- 结果记入入口矩阵，命中项标注来源凭据，便于后续扩大战果。
- 失败的凭据保留备用，新入口出现后再试一轮。
复核要点
- 重放成功后确认实际身份与权限，不要假设与泄露源一致。
- 有严格账户锁定策略的目标要克制重放，避免锁死账户影响授权测试。
- 密码会复用，SSH 私钥同样会复用，两条线都要查。
防御建议
- 禁止跨服务密码复用，不同系统使用不同凭据。
- 推广密码管理器，降低用户主动复用的动机。
- 凭据泄露即轮换，按"泄露一组、轮换一片"处理。
- 集中认证（SSO/LDAP）配合 MFA，收敛可重放的散点凭据。
- 监控同一凭据在多来源、多服务上的异常成功登录。