stagnation-recovery

name: stagnation-recovery description: Use when stuck, looping on same approach, making no progress after multiple tool calls, or receiving a stagnation warning from the system. Also trigger when you catch yourself retrying the same command with minor variations, getting repeated Permission denied or timeout errors, or unable to advance past a specific step for 10+ tool calls.

Stagnation Recovery - Security Operations

Core Principle

停下来比错误方向的加速更有价值。 当你连续尝试同类操作无果时，问题不是执行力不够，而是方向错了。

Iron Rules

1. 穷尽验证再放弃：没有读过报错全文、没有搜索过文档、没有检查过前置条件的，不算尝试过。
2. 先查后问：你有 wss_exec/docker_exec/WebSearch/Read 等工具，在判定"不可行"之前，必须用工具验证。
3. 换方向不是换参数：curl 加了 -k 还是 403？这不叫换方向。从 client_credentials 换到 device_code flow 才叫换方向。

Step 1: Diagnose - 识别你的卡壳模式

在采取任何行动之前，先判断你属于哪种模式：

Step 2: Recover - 按模式执行恢复

Mode A: 原地打转 -> 换攻击面

强制动作：

1. 列出你已尝试的所有方向（不是参数变体，是方向）
2. 从下面的攻击树中选择一个未尝试过的方向
3. 每个新方向最多尝试 3 次，无果则换下一个

Web 攻击树：

目标 Web 应用
  ├── 认证绕过: 默认凭据 / SQL注入 / JWT伪造 / OAuth滥用 / Session固定
  ├── 注入攻击: SQLi / XSS / SSTI / SSRF / XXE / Command Injection / LDAP Injection
  ├── 逻辑漏洞: IDOR / 竞态条件 / 业务逻辑绕过 / 价格篡改 / 权限越权
  ├── 文件操作: 上传绕过 / 路径遍历 / LFI/RFI / 反序列化
  ├── 前端攻击: DOM XSS / Prototype Pollution / WebSocket劫持 / PostMessage滥用
  └── 信息泄露: .git泄露 / 备份文件 / 错误页面 / API文档 / 源码泄露

提权攻击树：

初始访问
  ├── Linux: SUID/SGID / sudo滥用 / cron/定时任务 / capabilities / 内核漏洞 / Docker逃逸
  ├── Windows: 服务权限 / 注册表 / AlwaysInstallElevated / Token模拟 / SeImpersonate
  ├── Cloud: IMDS/metadata / IAM提权 / 角色链 / SSRF到云凭据 / 存储桶误配置
  └── K8s: ServiceAccount / RBAC滥用 / etcd / kubelet API / 挂载逃逸

云安全攻击树：

Cloud Target
  ├── Azure: OAuth App滥用 / Managed Identity / device_code flow / Admin Consent攻击
  │         / Dynamic Group注入 / PRT滥用 / Conditional Access绕过
  ├── AWS: IMDS v1/v2 / IAM提权链 / Lambda环境变量 / S3 ACL / STS AssumeRole
  └── GCP: SA密钥 / metadata server / Workload Identity / Org Policy绕过

Mode B: 环境约束 -> 绕道

强制动作：

1. 明确列出约束（具体错误信息）
2. 对每个约束检查：是真约束还是可绕过的？
   • Permission denied -> 能否换用户/换路径/换工具？
   • 工具缺失 -> 能否用替代工具？(例: 没有 nmap 用 /dev/tcp 探测)
   • 网络不通 -> 能否通过已有代理/隧道？
3. 确认是硬约束后，立即放弃这个方向，不要再尝试任何变体

常见绕道方案：

约束: 没有编译器         -> 本地编译后传输二进制
约束: 无法出网           -> 利用已有的合法通道（DNS/HTTP回连）
约束: 只读文件系统       -> /tmp, /dev/shm, 内存执行
约束: 没有交互式终端     -> 脚本化、heredoc、base64编码命令
约束: API需要MFA        -> device_code flow, 条件访问策略绕过
约束: reCAPTCHA/验证码  -> API直接调用（绕过前端）、自动化Cookie复用

Mode C: 信息不足 -> 回退侦察

强制动作：

1. 停止当前攻击尝试
2. 列出你当前已知的所有信息
3. 识别缺口：你需要知道什么才能推进？
4. 执行针对性侦察

信息回溯清单：

已发现的凭据:
  [ ] 全部尝试过了吗？在所有可能的服务上？
  [ ] 尝试过密码复用吗？

已发现的端口/服务:
  [ ] 所有端口都枚举过了吗？
  [ ] 每个服务的版本都识别了吗？
  [ ] 有已知漏洞吗？（searchsploit/CVE查询）

已发现的 Web 路径:
  [ ] 做过目录爆破吗？（多个字典）
  [ ] 检查过 robots.txt, .git, backup 文件吗？
  [ ] 每个端点的参数都测过吗？

已发现的用户/账户:
  [ ] 尝试过弱密码/默认密码吗？
  [ ] 做过用户枚举吗？
  [ ] 检查过权限差异吗？

Mode D: 攻击链断裂 -> 组合发现

强制动作：

1. 列出所有 key findings（读 progress.md 和 findings.log）
2. 画出当前拥有的信息图：

   我有: [凭据A] [端口B开放] [漏洞C存在] [配置D泄露]
   我需要: [从B进入] [用A认证] [利用C获取D中的密钥]
   缺失: [A->B的连接方式]
   

3. 对每对发现尝试组合：A+B能做什么？B+C呢？A+C呢？
4. 用 record_key_finding(kind='vulnerability', title='Attack Chain Hypothesis: ...', evidence='') 记录假设

Mode E: 工具使用错误 -> 用脚本替代

强制动作：

1. 如果 curl 命令反复出错（参数编码、引号嵌套、特殊字符），立即改用 Python 脚本
2. 如果多步操作需要中间状态（token获取 -> 使用token），写成一个完整脚本
3. 通过 python_poc_exec 或 wss_exec 执行脚本，避免 shell 转义问题

典型替代：

curl + 复杂参数  -> Python requests 脚本
多步 API 调用    -> Python 脚本（变量传递）
base64编码       -> Python 脚本（避免 shell 转义）
复杂 JSON body   -> Python 脚本（用 dict 构造）

Step 3: Execute - 执行新方向

每个新方向必须满足：

• 与之前本质不同（不是参数微调）
• 有明确的验证标准（怎样算成功，怎样算失败）
• 失败时能产生新信息（不是重复已知错误）

执行后立即：

• 成功 -> record_key_finding 记录
• 失败（新信息） -> 更新 progress.md，进入下一个方向
• 失败（无新信息） -> 停止这个方向，回到 Step 1 重新诊断

Anti-Patterns (FORBIDDEN)