تشغيل أي مهارة في Manus بنقرة واحدة

stagnation-recovery

النجوم٥١١

التفرعات٤٨

آخر تحديث٢٥ أبريل ٢٠٢٦ في ٠٨:٠٠

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.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

yhy0

yhy0/CHYing-agent

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

المهن الحاسوبية الأخرىمهن الحاسوب والرياضيات·SOC 15-1299

SKILL.md

readonly

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

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

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

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

模式	信号	根因
A: 原地打转	反复执行同一工具、只改参数/flag	方向错误，需要换攻击面
B: 环境约束	Permission denied, 工具缺失, 网络不通	硬限制，需要绕道或换工具链
C: 信息不足	盲目尝试、猜测 API 端点/参数	缺少侦察，需要回退到信息收集
D: 攻击链断裂	有多个发现但无法串联	需要停下来组合攻击链
E: 工具使用错误	命令语法错、参数编码错、curl 格式错	需要读文档或用脚本替代手工命令

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

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

强制动作：

列出你已尝试的所有方向（不是参数变体，是方向）
从下面的攻击树中选择一个未尝试过的方向
每个新方向最多尝试 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: 环境约束 -> 绕道

强制动作：

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

常见绕道方案：

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

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

强制动作：

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

信息回溯清单：

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

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

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

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

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

强制动作：

列出所有 key findings（读 progress.md 和 findings.log）

画出当前拥有的信息图：

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

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

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

强制动作：

如果 curl 命令反复出错（参数编码、引号嵌套、特殊字符），立即改用 Python 脚本
如果多步操作需要中间状态（token获取 -> 使用token），写成一个完整脚本
通过 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)

行为	为什么错	应该做什么
curl 换个 flag 重试 5 次	同一方向的参数微调	换攻击向量或用 Python 脚本
反复刷新页面等状态变化	被动等待	分析为什么状态没变
连续 take_snapshot 10 次	观察不等于行动	分析页面内容，决定下一步操作
猜测 API 端点格式	没有侦察就攻击	先找到文档/源码/目录列表
报错后不读报错内容	浪费信息	逐字读错误信息，提取线索
有凭据但没在所有服务上试	遗漏攻击面	系统性地在每个服务上尝试
device_code 过期后重新获取但不改流程	不解决根因	写脚本一次性完成整个 flow

المزيد من هذا المستودع

نفس المستودع

ai-security

yhy0/CHYing-agent

Use when facing AI security challenges involving prompt injection, LLM jailbreaks, or AI agent exploitation

2026-04-25511

binary

yhy0/CHYing-agent

Use when facing binary exploitation (PWN) or reverse engineering challenges involving memory corruption, ROP chains, shellcode, binary analysis, decompilation, unpacking, or dynamic tracing

2026-04-25511

cryptography

yhy0/CHYing-agent

Use when facing cryptography challenges involving cipher analysis, key recovery, mathematical attacks, or protocol weaknesses

2026-04-25511

file-transfer

yhy0/CHYing-agent

Use when transferring files between remote environments and local Docker containers via litterbox.catbox.moe relay or base64 chunked fallback

2026-04-25511

forensics-misc

yhy0/CHYing-agent

Use when facing digital forensics or misc challenges involving disk images, memory dumps, network captures, steganography, file format analysis, encoding puzzles, sandbox escapes, or archive manipulation

2026-04-25511

infra-exploit

yhy0/CHYing-agent

Use when conducting penetration testing, post-exploitation, lateral movement, domain attacks, cloud exploitation (AWS/GCP/Azure), container escape, or Kubernetes cluster attacks

2026-04-25511

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

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

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

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

模式	信号	根因
A: 原地打转	反复执行同一工具、只改参数/flag	方向错误，需要换攻击面
B: 环境约束	Permission denied, 工具缺失, 网络不通	硬限制，需要绕道或换工具链
C: 信息不足	盲目尝试、猜测 API 端点/参数	缺少侦察，需要回退到信息收集
D: 攻击链断裂	有多个发现但无法串联	需要停下来组合攻击链
E: 工具使用错误	命令语法错、参数编码错、curl 格式错	需要读文档或用脚本替代手工命令

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

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

强制动作：

列出你已尝试的所有方向（不是参数变体，是方向）
从下面的攻击树中选择一个未尝试过的方向
每个新方向最多尝试 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: 环境约束 -> 绕道

强制动作：

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

常见绕道方案：

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

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

强制动作：

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

信息回溯清单：

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

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

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

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

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

强制动作：

列出所有 key findings（读 progress.md 和 findings.log）

画出当前拥有的信息图：

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

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

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

强制动作：

如果 curl 命令反复出错（参数编码、引号嵌套、特殊字符），立即改用 Python 脚本
如果多步操作需要中间状态（token获取 -> 使用token），写成一个完整脚本
通过 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)

行为	为什么错	应该做什么
curl 换个 flag 重试 5 次	同一方向的参数微调	换攻击向量或用 Python 脚本
反复刷新页面等状态变化	被动等待	分析为什么状态没变
连续 take_snapshot 10 次	观察不等于行动	分析页面内容，决定下一步操作
猜测 API 端点格式	没有侦察就攻击	先找到文档/源码/目录列表
报错后不读报错内容	浪费信息	逐字读错误信息，提取线索
有凭据但没在所有服务上试	遗漏攻击面	系统性地在每个服务上尝试
device_code 过期后重新获取但不改流程	不解决根因	写脚本一次性完成整个 flow