Decepticon BloodHound 数据分析技能指南：从授权采集上传到攻击路径查询

导读

本文围绕 Decepticon 红队自动化框架中的bloodhound-query技能展开，讲解在托管演练（Hosted engagement）与独立 OSS 运行时两种场景下，如何对已授权的 AD 采集数据进行 BloodHound 图分析：从 SharpHound ZIP 上传、领域概览与数据质量检查，到对象画像、暴露面检索、最短攻击路径与有界 Cypher 查询，再到 GUI 联动验证与证据落库。读完本文，你将掌握bloodhound_mcp_*与bhce_*两套工具面的完整调用序列、它们之间的隔离边界，以及如何避免"空图即安全"的误判。

技能定位：何时加载bloodhound-query

bloodhound-query技能文件位于 packages/decepticon/decepticon/skills/standard/ad/bloodhound-query/SKILL.md，其 frontmatter 明确了加载条件：

name: bloodhound-query description: Analyze authorized AD collection data in BloodHound CE with the active runtime's supported tools and mirrored GUI. metadata: subdomain: active-directory when_to_use: "bloodhound collection upload object profile exposure shortest path cypher active directory" mitre_attack: - T1087.002 # Account Discovery: Domain Account - T1018 # Remote System Discovery - T1482 # Domain Trust Discovery

从when_to_use关键词（collection upload/object profile/exposure/shortest path/cypher）可以看出，该技能聚焦的是采集数据之后的图分析阶段，而不是采集本身。它与同目录下的 bloodhound-bhce/SKILL.md 形成分工：后者负责"运行时选择与采集"，前者负责"上传后的查询与分析"。父技能 ad/SKILL.md 的技能目录将其定位为 "Authorized collection upload, coverage, object and path analysis"，并明确要求：发现一个主机名并不会自动填充 BloodHound 图，必须先有已授权领域的采集路径。

第一原则：收集 ≠ 分析，空图 ≠ 安全

技能开头即给出最关键的判定规则：

BloodHound analyzes collected AD data; discovering a domain or opening its viewer does not populate the graph. Work only with the authorized domain and an existing collection path. Report missing collection access rather than claiming an empty graph proves safety.

这包含三层约束：

1. 发现领域或打开查看器不产生数据——BloodHound 的图来自采集器（SharpHound / AzureHound / BloodHound.py）的输出，只有上传并成功摄取后图才会被填充；
2. 只对已授权领域、且存在采集路径的数据工作——超出授权范围的查询是越界行为；
3. 空图必须报告为"缺少采集访问"，而不是"证明安全"——这是评估结论上的关键红线：缺失的数据不能当作负面证据使用。

这与 ad/SKILL.md 工作流第 2 步一致："A discovered hostname alone does not populate BloodHound. Inspect collection coverage before interpreting absent results."

Hosted engagement：bloodhound_mcp_*工具面

在托管演练中，Decepticon 为演练提供演练隔离（engagement-isolated）的 BloodHound CE 伴生实例（独立 GUI + 一组bloodhound_mcp_*工具）。完整流程分四步。

步骤 1：上传已有采集包

如果/workspace下已存在兼容的 SharpHound ZIP，直接调用上传工具：

bloodhound_mcp_upload_collection(path=...)

• 路径必须指向/workspace下已授权的采集包；
• 必须核对返回的终端状态（terminal status）为Complete；出现PartiallyComplete/Failed/Cancelled时要如实上报部分或失败的摄取结果，不能当作成功处理。

这一"轮询至终端状态"的语义与源码实现一致：在 tools/ad/bh_tools.py 中，bhce_ingest_zip运行 BHCE v9.2.2 官方的三步上传流程（POST /api/v2/file-upload/start→POST /api/v2/file-upload/{job_id}→POST /api/v2/file-upload/{job_id}/end），随后以 2 秒间隔轮询GET /api/v2/file-upload/{job_id}，直到命中_TERMINAL_STATUSES = {"Complete", "Failed", "Cancelled", "PartiallyComplete"}或 600 秒超时（见bh_tools.py中的_UPLOAD_POLL_INTERVAL_SECONDS/_UPLOAD_POLL_TIMEOUT_SECONDS）。对应单元测试 tests/unit/ad/test_bh_tools.py 的test_bhce_ingest_zip_runs_three_step_and_polls_until_terminal验证了"三步各恰好一次 + 至少两次轮询"的行为契约。

步骤 2：无采集包时的授权采集

若/workspace中没有现成 ZIP，技能给出两条路径：

• 通过已授权立足点（foothold）采集，并将 ZIP 传回/workspace；
• 当存在可达且已授权的 DC、且/workspace有 Kerberos 缓存时，调用：

bloodhound_mcp_collect_domain(domain=..., dc=..., username=..., cache=...)

参数匹配规则：

采集模式有明确的分级约束：

• 默认从DCOnly开始——只采集域级对象，覆盖面最小、噪音最低；
• Default与Session模式必须显式提供计算机白名单（computer allowlist），否则不得使用；
• 严禁以 MCP 参数形式传递密码或哈希——凭据只能以缓存文件形式存在于/workspace。

步骤 3：上传完成后的分析序列

上传成功后，工具调用顺序应遵循"由总到分、语义工具优先"的原则：

1. 数据质量与概览先行：
   • bloodhound_mcp_data_quality—— 检查采集覆盖度，判断"缺边"是真实不存在还是采集不完整（这是空图误判的第一道防线）；
   • bloodhound_mcp_domain_overview—— 获取领域级对象统计。
2. 定向对象检索：
   • bloodhound_mcp_find_objects—— 按名称/属性搜索对象；
   • bloodhound_mcp_object_profile—— 查看单个主体的完整画像（成员关系、ACL、会话等）。
3. 有界问题分析：
   • bloodhound_mcp_exposure_finder—— 暴露面检索，用于"谁对什么有路径"类问题；
   • bloodhound_mcp_shortest_path—— 最短路径查询，用于"从 A 到 B 的最短可达路径"。
4. Cypher 兜底：
   • bloodhound_mcp_cypher_query——仅当上述语义工具无法回答某个只读问题时才使用；
   • 使用时必须约束返回行数（bound returned rows）与路径深度（path depth），防止无界查询拖垮伴生实例。

技能强调"语义工具优先、Cypher 兜底"的分层，与 dcsync/SKILL.md 的用法一致——它同样要求用bloodhound_mcp_exposure_finder/bloodhound_mcp_object_profile识别复制权限持有者，仅在针对特定主体时才用有界的只读bloodhound_mcp_cypher_query，且必须先做数据质量检查再解读"无暴露"结果。

步骤 4：GUI 联动验证与结果记录

• GUI 联动状态：在声称"操作员能在界面上看到某对象/路径"之前，必须先检查GUI follow 状态（follow status）——只有返回的联动状态才能证明远程查看器确实移动到了目标对象，打开查看器本身不算证据；
• 证据区分：候选图路径（candidate graph path）≠ 已由独立证据证明的动作（action proven by independent evidence），二者不可混同；
• 结果落库：确认后的结果必须通过当前演练的finding 与 OPPLAN 工具记录，图查询结果本身既不能授权对目标的操作，也不能证明入侵成功（与 ad/SKILL.md 工作流第 4 步一致）。

隔离边界：托管图 ≠ 独立实例

托管 MCP 图与任何独立 BloodHound 实例物理隔离，技能明确禁止在托管分析中调用：

• bhce_*工具（指向独立 OSS 实例）
• bh_ingest_zip（已弃用的自研摄取工具）
• bh_cypher
• 本机cypher-shell

这条边界的底层依据来自架构决策 docs/adr/0005-bloodhound-via-bhce-rest-client.md：BHCE 的dawgs驱动独占其 Neo4j schema，因此仓库为 BHCE 单独部署decepticon-bhce-neo4j与decepticon-bhce-api容器（指向独立的bloodhoundPostgres 库），与 Decepticon 自身的 KGStore 图（web/cloud/AD 融合图）物理分离。混用两套实例的数据会导致"把 A 实例的采集当成当前演练的 B 实例数据"的伪证据。

Standalone OSS runtime：bhce_*工具面

当托管 MCP 工具缺失、但注册了独立的bhce_*工具时，技能给出三个工具的完整用法：

关键约束：

• 先确认工具已注册再使用——不要假设某个固定版本或 schema 存在，以实际实例上报的能力为准（bloodhound-bhce/SKILL.md 同样强调 "Do not assume a fixed BloodHound version or schema; use the actual instance's reported capabilities"）；
• 绝不允许把另一个实例的数据当作当前演练的采集数据；
• bhce_cypher只用于有界只读查询。

源码视角：bhce_*如何工作

bhce_*工具面实现在 tools/ad/bh_tools.py，其底层是手写的 BHCE v9.2.2 REST 客户端 tools/ad/bhce_client.py。客户端通过环境变量构造（BHCE_URL/BHCE_TOKEN_ID/BHCE_TOKEN_KEY/BHCE_TIMEOUT，默认 30 秒），并实现 BHCE 官方的HMAC 三级签名链：

OperationKey = HMAC_SHA256(token_secret, METHOD || URI_PATH) # URI 含查询串 DateKey = HMAC_SHA256(OperationKey, RFC3339[:13]) # 截断到小时 BodyKey = HMAC_SHA256(DateKey, body_bytes) # 空 body 也执行第三次 HMAC Signature = base64(BodyKey)

随请求携带三个认证头：Authorization: bhesignature <TOKEN_ID>、RequestDate: <完整 RFC3339>、Signature: <base64>。两个值得注意的细节：签名输入中的日期截断到小时、而请求头携带完整时间；客户端刻意匹配 BHCE服务端的签名行为（服务端将 query 字符串纳入RequestURI参与签名，而其 Go 客户端只签 path）——因为决定请求接受与否的是服务端。服务器时钟偏差窗口为 ±1 小时（ADR-0005 中明确指出文档页面上"2 小时"的说法不准确）。

签名兼容性由 tests/unit/ad/test_bhce_client.py 固定：测试向量来自对 BHCEcmd/api/src/api/signature.go的逐字crypto/hmac复现，而非用自研算法自证，从而保证与官方服务端验证器字节级兼容。

为什么不是bh_ingest_zip：ADR-0005 的弃用脉络

技能的"禁止bh_ingest_zip"要求背后是一次明确的架构迁移。docs/adr/0005-bloodhound-via-bhce-rest-client.md 记录了决策：不再用自研 Python/Cypher 重实现 BloodHound CE 的PostProcessedRelationships（ESC1/3/4/6/9/13、GoldenCert、DCSync、TrustedForNTAuth 等），改为直连官方 BHCE REST API——上游每发布一个新 ESC 类型、边重命名或 Properties 键变更，自研管线都要一轮 RFC + 正则 + 狗粮验证，成本不可持续。

因此旧工具面bh_ingest_zip、bh_ingest_json、dcsync_check、delegation_audit、gpo_audit、adcs_audit、adcs_post_process进入弃用通道：在 tools/ad/tools.py 中，它们每次调用都会触发DeprecationWarning，提示改用bhce_status/bhce_cypher/bhce_ingest_zip；保留一个次要周期后迁入decepticon.compat，再下一周期移除。唯一保留的自研工具是kerberos_classify——BHCE 没有对应的本地哈希/票据解析器。

从源码结构看，旧摄取管线（tools/ad/bloodhound.py）仍保留了完整的 BloodHound 5.x JSON → KGStore 映射能力（ingest_bloodhound_zip/merge_bloodhound_json），包括 PrimaryGroupSID 合成、会话方向保留、ContainedBy 翻转、信任关系四向拆分等五项"陷阱修复"，但它服务的是 KGStore 融合图，与 BHCE 托管图是两条不同的数据通道——这也再次印证了技能中"托管图与独立实例数据不得混用"的隔离要求。

端到端实战序列（对照速查）

以下是将上述规则串成一次完整分析的最小序列（托管演练场景）：

# 1. 已有采集包 → 上传并核验 bloodhound_mcp_upload_collection(path="/workspace/bh.zip") # 必须返回 terminal status = Complete # 2. 无采集包且授权 DC 可达、有 Kerberos 缓存 → 分级采集 bloodhound_mcp_collect_domain(domain="corp.local", dc="dc01.corp.local", username="svc_audit", cache="/workspace/krb.ccache") # 仅 DCOnly 起步 # 3. 质量与概览 bloodhound_mcp_data_quality bloodhound_mcp_domain_overview # 4. 定向对象与画像 bloodhound_mcp_find_objects(query="svc_*") bloodhound_mcp_object_profile(object_id="...") # 5. 有界问题 bloodhound_mcp_exposure_finder(start=..., target=...) bloodhound_mcp_shortest_path(start=..., target=..., max_depth=5) # 6. 兜底：语义工具答不了才用 Cypher（务必有界） bloodhound_mcp_cypher_query(query="MATCH (n)-[:GetChanges|GetChangesAll]->(:Domain) RETURN DISTINCT n.name, labels(n) LIMIT 25") # 7. 确认 GUI follow 状态 → finding / OPPLAN 工具落库

对应独立 OSS 运行时，将 1/6 两步替换为bhce_ingest_zip(path=...)（同样轮询至Complete）与bhce_cypher(query=..., include_properties=true)，并以bhce_status先行确认实例健康。

常见误用与规避

小结

bloodhound-query技能在 Decepticon 中承担 AD 分析"数据进入图之后的全部工作"：它用bloodhound_mcp_*完成托管演练的"上传 → 采集 → 质量检查 → 对象/暴露面/最短路径 → 有界 Cypher → GUI 验证 → 落库"闭环，用bhce_*支撑独立 OSS 运行时的等价能力，并以"空图不等于安全"的判定红线约束结论输出。背后是 ADR-0005 确立的"直连官方 BHCE REST API、弃用自研重实现"的架构方向，以及bhce_client.py对 HMAC 签名链的字节级兼容实现。对红队自动化而言，这套技能既是操作手册，也是"图结果本身不构成入侵证据"的纪律约束。