Decepticon Forensicator DFIR 技能目录实战：用 Volatility 3、plaso 与 Sigma 验证检测规则，闭合 Offensive Vaccine 闭环-平芜编程栈

【免费下载链接】Decepticon

Autonomous Hacking Agent for Red Team

项目地址：https://gitcode.com/gh_mirrors/de/Decepticon

本篇指南围绕 Decepticon 的Forensicator / DFIR Skill Catalog（SKILL.md）展开，讲解 Decepticon 如何让"每一次攻击都变成一次防御改进"：攻击 Agent 与检测规则生成 Agent 负责产出 Sigma / YARA 规则，Forensicator 则用 Volatility 3、plaso、sigma-cli 在真实内存转储、事件日志与取证工件上回放验证这些规则是否真的能命中。读完你将掌握：这个技能目录的定位与八个内联 Playbook、闭环验证的完整工作流、工具沙箱的用法，以及仓库中 Forensicator Agent 与 SIEM/EDR 推送工具链的源码级实现。

为什么需要"取证验证"这一环

Decepticon 的定位是同时产出攻击和检测规则。Red 侧执行完一次攻击后，Detector Agent 会生成描述预期检测模式的 Sigma 规则（例如"事件 4662 且带正确的ControlAccessRights"）；但规则写出来只是理论，只有把规则喂给真实取证工件（内存转储、事件日志、磁盘镜像），确认它确实能触发，检测才算被验证过。SKILL.md 的原话是："Without this catalog, detection rules are theoretical."——没有这个目录，检测规则就停留在理论层面。

这正是"Offensive Vaccine"（进攻性疫苗）闭环在操作侧的关键一步：攻击 → 检测规则 → 取证回放验证 → 修复验证。规则验证通过后，验证证据会写入 engagement 知识图谱，报告中的检测工程章节才有据可依。

技能目录的定位：内联技术参考，不是独立可加载 Skill

DFIR 目录与其说是一组 Skill，不如说是一份内联技术速查表。SKILL.md 中明确说明：

Inline technique reference — not separately loadable skills.The entries below are summarized here for direct use; there is no separateSKILL.mdto open for each. Do NOT call the skill loader on them — apply the technique with your tools using this summary and the Workflow in this file.

即：目录中的每项技术没有对应的独立SKILL.md，不要对它们调用 skill loader，而应直接依据这份摘要和文件中的 Workflow 用你的工具去执行。这也与 Forensicator Agent 的实现一致——它的技能源只挂载了目录本身与共享技能（见下文源码分析）。

八个内联 Playbook 速查

Technique	用途
volatility-windows	Volatility 3 Windows 插件：pslist、malfind、cmdline、netscan、dlllist、handles
volatility-linux	Volatility 3 Linux：linux.pslist、linux.bash、linux.malfind
plaso-timeline	psort + log2timeline；构建超级时间线（super-timeline）；在时间线上跑 Sigma 匹配器
sigma-cli-validation	sigma-cli convert + 对捕获的事件日志做 match
yara-scan	yara-x 对内存转储和磁盘镜像做扫描
event-log-mining	Windows 事件日志（.evtx）提取 + 关键事件 ID 参考
etw-trace	ETW provider 分类；.etl 文件提取
edr-validation	在目标上启用 Velociraptor / OSQuery 重放攻击；捕获工件

从仓库中 Forensicator Agent 的工具面（forensicator.py 的 docstring）可以确认这些技术在实现侧的落点：volatility3 负责内存分析，plaso/log2timeline 负责超级时间线，tshark/zeek 负责网络取证，regripper/evtx_dump 负责 Windows 工件。该 Agent 被明确标记为read / analysis oriented：只检查 engagement 工作区中捕获的证据，不发起攻击。

闭环验证工作流（Loop Closure Workflow）

SKILL.md 给出五步闭环，是整个目录的操作核心：

运行一个攻击技术——例如从 ad-operator Agent 执行dcsync。
Detector Agent 产出 Sigma 规则——描述预期的检测模式（如事件 4662 配合正确的ControlAccessRights等）。
Defender 将 Sigma 推送到客户 SIEM——通过sigma_to_splunk_savedsearch/sigma_to_sentinel_analyticrule/sigma_to_elastic_detection_rule等工具。
Forensicator 验证：
- 收集攻击发生时域控（DC）上的事件日志；
- 执行sigma-cli convert --target sqlite，并与日志文件做匹配；
- 若匹配数为0→ 检测规则有 bug，需要与 Detector 迭代；
- 若匹配数为N→ 检测有效，把验证证据记录到 engagement 知识图谱。
Patcher 提议修复；Forensicator 验证补丁不会破坏检测（确认规则在针对已修补构建的利用尝试上仍然触发）。

第 4 步的"0 命中 = 规则有 bug、N 命中 = 规则有效"判定标准，把检测规则的验证从"人肉肉眼审查"变成可量化的回放实验——这正是该目录最核心的实操价值。

工具沙箱（Tools Sandbox）

工具	组件	说明
Volatility 3	`vol`、`volshell`	已包含在操作员的 AGENTS.md 工具清单中
plaso	`log2timeline`、`psort`	时间线构建与排序
sigma-cli	`sigma convert`、`sigma check`	规则转换与校验
yara-x	`yr`	操作员已安装于`C:\Tools\yara-x\yr.exe`
Velociraptor + OSQuery	—	用于活体系统验证路径

使用上无需额外安装规划：Volatility 3 与 yara-x 是操作员既有工具，plaso 与 sigma-cli 是验证链的两大支柱——log2timeline把取证工件转成时间线、psort排序筛选；sigma convert把 Sigma 规则转成目标查询、sigma check校验规则本身。

源码级佐证一：Forensicator Agent 的只读边界与挂载点

forensicator.py 是消费这份目录的 Agent 实现，几个关键点：

技能源挂载：_SKILL_SOURCES = ["/skills/standard/dfir/", "/skills/shared/"]，与 SKILL.md 目录直接对应；
标准工具面：知识图谱 CRUD（kg_add_node/kg_add_edge/kg_query/kg_neighbors/kg_stats）、cve_lookup、payload_search、methodology_lookup，以及BASH_TOOLS——bash 在这里是只读分析用途；
注册：通过SUBAGENT_SPEC挂到父 Agentdecepticon下（parent_agents=("decepticon",)），priority=95，并在 graph_registry.py 中以STANDARD_GRAPHS["forensicator"] = "./decepticon/agents/standard/forensicator.py:graph"注册；
递归上限：_RECURSION_LIMIT = 250，因为多源取证分析（内存/日志/时间线交叉关联）耗轮次较多。

其系统提示词（forensicator.md）进一步定义了范围红线：

仅分析（ANALYSIS-ONLY）：绝不攻击、绝不修改活体主机、绝不改动证据；只在evidence/下的副本上工作；
绝不外带证据：证据留在 engagement 工作区，遵循plan/roe.json:data_handling；
保留证据链：分析前记录每个打开工件的哈希。

它的工作循环是：读 OPPLAN 目标 → 加载skills/standard/dfir/SKILL.md选择技术 → 分析证据（volatility3 内存 / plaso 超级时间线 / regripper + evtx 的 Windows 工件 / tshark-zeek 网络）→ 跨源关联 → 提取 IOC 并映射到 ATT&CK（每个 IOC 一个Indicator节点、每个观察到的技术一个Technique节点，链接到产生它的攻击Finding）→ 以 JSON 交接时间线、IOC 与检测缺口。

源码级佐证二：从"规则验证通过"到"规则上生产"的推送链

闭环第 3 步的 SIEM 推送在仓库中已有完整实现，位于 tools/defense：

sigma_to_splunk_savedsearch— Sigma → SPL，经 HEC/REST 推送为 Splunk saved search；
sigma_to_sentinel_analyticrule— Sigma → KQL，推送为 Microsoft Sentinel Scheduled Analytic Rule；
sigma_to_elastic_detection_rule— Sigma → Lucene，推送进 Elastic Detection Engine；
yara_to_defender_xdr_custom_detection— YARA → Defender XDR 自定义检测；
yara_to_crowdstrike_ioa— YARA → CrowdStrike Falcon IOA 风格自定义指示器；
list_siem_targets— 只读枚举当前 engagement ConOps 已配好凭据的 SIEM 端点。

所有推送工具共用三条契约（init.py）：

ConOps 必须先声明端点：ConOps 需在conops.blue_team.<target>下声明 SIEM 端点（URL + 认证方式）。推送到未声明的端点会被拒绝，Agent 会收到指向缺失 ConOps 键的结构化错误。ConOps 文件位于/workspace/conops.json，schema 见 conops.py 的 docstring（splunk/sentinel/elastic/defender/crowdstrike各自的url/workspace_id/tenant_id等字段）；auth字段永远是对环境变量的引用（如hec_token:<env-var-name>），凭据明文不落盘。
规则带 Decepticon 作用域标签：每条推送的规则都带decepticon-eng-<slug>前缀标签，蓝队可以在 engagement 结束后识别并停用（例如 Splunk 中 saved search 名为decepticon-eng-<slug>::<title>）。
幂等：重复推送同一规则会按rule_id替换旧副本，而不是产生重复。

翻译层的行为可以看 splunk.py 的sigma_to_spl：支持selection + condition与and/or/not括号组合，字段修饰符支持contains/startswith/endswith；超出该子集的结构（如未知修饰符、未知 selection 名）会抛出SigmaConversionError而非静默生成错误查询。单元测试 test_defense.py 覆盖了这些边界（含"未知修饰符必须抛错"的用例）。YARA 侧（edr.py）会解析规则meta块：Defender 翻译要求能从 meta 提取 SHA256（否则报"无可提取指示器"的结构化错误）；CrowdStrike IOA 要求 meta 中声明indicator_type（sha256/sha1/md5/ipv4/ipv6/domain/filename）与indicator_value，纯字节模式 YARA 无法表达为 IOA 时会返回结构化错误引导 Agent 换目标。

端到端示例：DCSync 攻击的检测验证闭环

把 SKILL.md 的工作流套到具体攻击上：

ad-operator 在域控环境执行dcsync（secretsdump-just-dc）；
Detector 依据行为产出 Sigma 规则：匹配事件 ID 4662 + 正确ControlAccessRights；
Defender 调sigma_to_splunk_savedsearch（或按客户栈选择 Sentinel/Elastic）把规则推上 SIEM；
Forensicator 收集攻击时刻域控的 .evtx 日志 →sigma-cli convert --target sqlite转成可查询格式 → 对日志做 match：
- 0 命中 → 规则漏检，回炉给 Detector；
- N 命中 → 规则有效，验证证据入知识图谱；
Patcher 提出补丁，Forensicator 对修补后的构建重放利用尝试，确认规则仍能触发（即修复没有引入检测盲区）。

值得一提的是，仓库的 sample_rules.jsonl 里正好有 DCSync 的检测示例（DCEP-T1003.006-dcsync：actor.command_line含secretsdump且匹配re:-just-dc(?:-ntlm)?的组合条件），Kerberoasting、AS-REP Roasting、Pass-the-Hash、LSASS 转储等 ATT&CK 映射同样有对应条目——这些规则文件同时服务于 Blue Cell 的实时匹配（见下节），说明"规则写出来"之后至少有两条消费路径：SIEM 推送（生产）与本地回放匹配（验证）。

事实边界与使用前提

SKILL.md 是技能目录文档，描述的是验证链路的操作意图；相应的运行时（Forensicator Agent、defense 推送工具、Blue Cell 匹配器）在当前仓库中均已实现并注册。更宏观的"Offensive Vaccine"产品方向仍在演进中（offensive-vaccine.md 将其表述为 planned product direction），本文所述均为目录与现有代码可确认的范围。
验证依赖真实工件：需要攻击时刻的事件日志、内存转储或磁盘镜像，且这些证据只能来自 engagement 工作区内的副本；
推送工具强依赖 ConOps 声明：conops.blue_team.<target>未配置时工具直接拒绝，Agent 需先list_siem_targets确认目标已接线；
翻译器（Sigma→SPL/KQL/Lucene）只支持 Detector 实际产出的子集，超出子集的规则会得到结构化错误而非错误查询，这保证了"宁可报错，不可错转"。

为什么这是差异化能力

SKILL.md 自我定位为差异化能力：同类攻击型工具只做到"规则写出来"就停住，而 Decepticon 把闭环推进到"规则被验证为能在这类攻击、这家客户的栈上触发"。Offensive Vaccine 的承诺——每一次攻击都变成一次防御改进——只有在有人真正验证检测时才成立。没有 Forensicator，循环停在"规则已写"；有了它，循环完成于"规则已针对该攻击类别与客户环境验证生效"，验证证据同步进入知识图谱，成为报告检测工程章节和后续加固建议的事实基础。

相关深入阅读：技能目录 SKILL.md、Agent 实现 forensicator.py、系统提示词 forensicator.md、防御推送工具包 tools/defense、ConOps 解析 conops.py、Agent 编排矩阵 agents.md。