企业官网建设流程全解析

BloodHound CE 内网侦察 API 实战指南：Python 驱动、Cypher 攻击路径查询与自动化采集

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills

导读

本指南以 conducting-internal-reconnaissance-with-bloodhound-ce 技能包中的 API 参考文档为骨架，系统讲解如何利用 Python 生态对 BloodHound Community Edition（CE）进行程序化侦察：从neo4j、bloodhound、requests三个核心库的安装与分工，到 Neo4j 驱动方法、关键 Cypher 攻击路径查询，再到bloodhound-python采集器命令行与仓库内置自动化脚本。读完本文，你将能够搭建一套"采集 AD 数据 → 导入图数据库 → 用 Cypher 找出通往域管的最短攻击路径 → 自动生成侦察报告"的完整内网侦察链路。

核心 Python 库：三层架构下的分工

API 参考文档给出的库清单构成了 BloodHound CE 程序化侦察的三层基础。下表完整继承自 api-reference.md，并补充了各自在链路中的职责：

三者对应了侦察链路的三个阶段：先用 bloodhound 库采集，再通过 CE 的 REST API（requests）导入，最后用 neo4j 驱动做图分析。仓库中的 agent.py 正是这一分工的落地实现——它用subprocess调用bloodhound-python完成采集，再用neo4j驱动连接图库执行查询，两个环节在同一个脚本中串联。

Neo4j 驱动核心方法：连接图库的四个动作

要对 BloodHound CE 背后的 Neo4j 图数据库执行 Cypher 查询，只需掌握 API 参考文档列出的四个驱动方法：

这些方法在仓库脚本中有完全对应的真实调用。以 agent.py 的run_recon为例，它展示了完整的连接生命周期：

driver = GraphDatabase.driver(neo4j_uri, auth=(neo4j_user, neo4j_password)) # ... 依次执行多条侦察查询 ... driver.close()

其中 URI 默认值为bolt://localhost:7687（见 agent.py），用户名默认neo4j，密码必须显式传入，这正对应 CE 图库的默认连接方式。值得注意的一点是，该脚本将所有查询封装为带with driver.session() as session:上下文的独立函数，例如query_shortest_path_to_da使用session.run配合$group参数占位符执行参数化查询（agent.py），这是生产环境中推荐的写法——参数化不仅能复用查询计划，也避免了将域名字符串直接拼进 Cypher 带来的语法与注入风险。

关键 Cypher 查询：五大侦察模式的完整实现

API 参考文档给出了一组"开箱即用"的关键查询模式，覆盖内网侦察最核心的五大场景。下面的表格逐条保留自原文档：

从模式到可执行查询：仓库中的实战版本

API 参考中的模式是"最小骨架"，要真正可执行还需要补全返回字段、过滤条件和目标节点名。仓库 SKILL.md 与 agent.py 给出了可直接复制的完整版本：

// 从已控主体到域管的最短路径 MATCH p=shortestPath((n {owned:true})-[*1..]->(m:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) RETURN p // 可 Kerberoasting 且可达域管的用户（同时过滤启用状态） MATCH (u:User {hasspn:true}) MATCH p=shortestPath((u)-[*1..]->(g:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"})) RETURN p // 域管成员会话所在的计算机（会话劫持候选） MATCH (c:Computer)-[:HasSession]->(u:User)-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}) RETURN c.name, u.name // ACL 滥用路径（GenericAll / GenericWrite / WriteDacl / WriteOwner / ForceChangePassword） MATCH p=(u:User)-[:GenericAll|GenericWrite|WriteDacl|WriteOwner|ForceChangePassword*1..]->(t) WHERE u.owned = true RETURN p // 可 DCSync 的用户（含经由组传递的权限） MATCH (u)-[:MemberOf*0..]->()-[:DCSync|GetChanges|GetChangesAll*1..]->(d:Domain) RETURN u.name, d.name // 非管理员可读 LAPS 密码的计算机 MATCH (c:Computer {haslaps:true}) MATCH p=(u:User)-[:ReadLAPSPassword]->(c) RETURN p

对比可见两个增强点：其一，原模式中的DOMAIN ADMINS@...需要替换为真实域名格式，如DOMAIN ADMINS@DOMAIN.LOCAL；其二，SKILL.md 版本加入了u.enabled = true、u.owned = true这类状态过滤，能显著减少噪声——例如 agent.py 的路径查询限定WHERE u.enabled = true，并在结果中按跳数升序取前 10 条：

result = session.run( "MATCH p=shortestPath((u:User)-[*1..]->(g:Group {name: $group})) " "WHERE u.enabled = true RETURN u.name AS user, length(p) AS hops " "ORDER BY hops LIMIT 10", group="DOMAIN ADMINS@DOMAIN.LOCAL", )

查询字段背后的对象属性语义

Cypher 模式中的属性名对应 BloodHound 采集到的 AD 对象属性，理解其语义才能正确解读结果：

• hasspn：用户是否注册了服务主体名称（SPN），为true即存在 Kerberoasting 面；
• dontreqpreauth：用户是否不需要 Kerberos 预认证，为true即存在 AS-REP Roasting 面；
• unconstraineddelegation：计算机是否配置了非约束委派，攻击者可借此窃取 TGT；
• admincount：对象是否属于特权组（AdminCount 标记）；
• haslaps：计算机是否启用 LAPS 本地管理员密码管理。

这些属性的解析逻辑在 process.py 中有系统化的实现，它读取 BloodHound JSON 导出后按hasspn、dontreqpreauth、admincount、unconstraineddelegation等字段批量归类用户与计算机，正是把 Cypher 查询逻辑平移到了离线的 JSON 分析场景。

BloodHound Python Ingestor：Linux 侧的采集命令行

当侦察机是 Linux 而非 Windows 时，API 参考文档推荐的采集工具是 BloodHound.py 命令行采集器：

bloodhound-python -d domain.local -u user -p pass -ns DC_IP -c all --zip

各参数含义：

采集方法（Collection Methods）

原文档列出了 7 种采集方法：all、group、localadmin、session、trusts、objectprops、acl。它们的覆盖范围如下：

• all：完整采集，包含其余所有方法的数据；
• group：组及其成员关系（MemberOf 边）；
• localadmin：各计算机上的本地管理员关系（AdminTo 边）；
• session：当前登录会话（HasSession 边）；
• trusts：域信任关系（TrustedBy 边）；
• objectprops：对象的基础属性（用户、计算机、OU、GPO 等）；
• acl：对象级 ACL 关系（GenericAll、WriteDACL、ForceChangePassword 等攻击边）。

其中acl是识别 ACL 滥用路径的数据基础，而session采集对实时性敏感，适合用循环模式持续收集。仓库 workflows.md 专门给出了低噪声采集建议：优先用DCOnly模式只查域控 LDAP，用--searchbase限定 OU 范围定向采集，用--loop --loopduration周期性采集会话。

agent.py 对采集器的封装

agent.py 将上述命令行封装为collect_bloodhound_data函数：它以 domain、username、password、dc_ip、method 为参数，通过subprocess调用bloodhound-python，并带 300 秒超时；当本机未安装 bloodhound 库时返回"Install: pip install bloodhound"的明确提示，采集超时则返回{"status": "timeout"}。脚本同时提供--collect开关与--domain、--ad-user、--ad-pass、--dc-ip参数，可在分析前先触发采集，形成"采集 → 分析"的一键流程。

从查询到报告：仓库内置的两段式自动化

API 参考文档聚焦于"查询接口"，而仓库脚本补全了它的下游——把查询结果与离线导出转成可交付的侦察报告。

agent.py：实时查询侦察报告

run_recon按固定顺序执行四类查询（agent.py）：

1. 到域管的最短路径：列出用户及跳数，按跳数升序；
2. 可 Kerberoasting 用户：附 SPN 列表与 AdminCount 标记，取前 10 条；
3. 非约束委派计算机：附操作系统信息；
4. 可 AS-REP Roasting 用户：附 AdminCount 标记。

输出以=分隔线分节打印，并可通过--output参数将结构化结果（paths_to_da、kerberoastable、unconstrained_delegation、asrep_roastable）写入 JSON 文件。其运行前提是 BloodHound CE 图库可达、且已完成数据导入。

process.py：离线导出分析报告

当需要离线分析采集的 JSON 导出时，process.py 提供了第二套分析管线：

python process.py <bloodhound_users.json> [bloodhound_computers.json]

它从 JSON 中抽取对象属性，对用户统计总数、启用数、可 Kerberoasting、可 AS-REP Roasting、AdminCount、密码不必需（passwordnotreqd）等指标；对计算机统计非约束/约束委派、LAPS 启用状态、过时操作系统（Windows 2003/2008/XP/Vista/7）、域控数量等指标（process.py）。最终生成的报告内置了"优先级攻击向量"排序：Kerberoasting → AS-REP Roasting → 非约束委派 → ACL 路径 → GPO 路径 → 过时系统利用，同时自动落盘为带时间戳的bloodhound_analysis_*.txt文件。

两套脚本互为补充：agent.py 面向在线图库做实时查询，process.py 面向离线导出做批量盘点，覆盖了 API 参考文档中neo4j驱动与bloodhound采集器两条主线。

采集 → 分析 → 规划：完整侦察工作流

把 API 参考文档嵌入更大的任务上下文，仓库 SKILL.md 与 workflows.md 给出了从部署到报告的标准六阶段流程：

1. 部署：用 Docker Compose 拉起 BloodHound CE（docker compose up -d），从docker compose logs | grep "Initial Password"获取初始密码并立即修改；
2. 采集：Windows 上用 SharpHound v2（.\SharpHound.exe -c All --outputdirectory C:\Temp），Linux 上用bloodhound-python，会话类数据用--loop --loopduration 02:00:00循环收集，ZIP 回传分析机；
3. 导入与标记：Web 界面 File Ingest 上传，将失陷账号标记为 Owned，设置高价值目标；
4. 分析：运行内置查询（最短路径到域管、Kerberoastable、AS-REP Roastable、DCSync 权限、非约束委派）与本指南所述的自定义 Cypher；
5. 攻击规划：按跳数、隐蔽性、工具可用性与检出概率为路径打分排序；
6. 报告：用 template.md 结构化呈现，包括 Engagement Details、Collection Summary、Attack Paths Identified、High-Value Findings 与 Remediation Priority 五个区块。

其中第五阶段的路径优先排序原则（跳数越少优先级越高、优先选择低噪声技术、逐跳确认工具与 OPSEC 措施）直接决定了 API 查询结果的价值排序方式——查询只是发现，规划才是产出。

MITRE ATT&CK 映射

API 参考文档将侦察行为映射到三个 MITRE ATT&CK Discovery 战术技术，仓库 standards.md 则给出了更完整的七项映射：

这套映射的价值在于双重视角：攻击者视角下，它说明 BloodHound 侦察在 ATT&CK 中的战术定位（全部属于 Discovery 阶段，是横向移动与提权的前置动作）；防御者视角下，它可用于对照检测日志——例如 T1069.002（域组枚举）与 T1482（信任发现）对应的 LDAP 查询模式，往往是攻击者开始"画地图"的信号。技能元数据中同时还声明了 NIST CSF（ID.RA-01、GV.OV-02、DE.AE-07）与 D3FEND 技术的映射，可结合 SKILL.md 头部 frontmatter 查阅。

使用前提与合法边界

本技能及文中所有命令均面向已获授权的渗透测试与教育环境。SKILL.md 与两个脚本头部都明确声明：未获对方书面许可对系统实施侦察属违法行为。使用前请确认：具备对目标环境的安全测试授权；使用实验室/测试环境验证流程；所有采集与分析行为在授权范围内进行。文中命令展示的凭据、域名、IP 均为占位符，须按实际环境替换。

小结

本文以 API 参考文档为骨架，串联了 BloodHound CE 程序化侦察的完整技术栈：三个 Python 库的分工与安装、Neo4j 驱动的四个核心方法、五类关键 Cypher 查询模式及其完整可执行版本、bloodhound-python采集器的参数与采集方法语义，并通过仓库内置的 agent.py 与 process.py 展示了从查询到报告的一体化落地。无论是需要快速验证 AD 加固效果，还是要从低权限立足点出发绘制通往域管的攻击路径，这套"采集器 + 图数据库 + Cypher + 脚本"的组合都能直接投入实战。

【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills