ShotHound与BloodHound路径验证有何关联？

在红队的真实演练里，常常会碰到“路径验证”这道难题：血缘图里列出的提权链，究竟能否在当前网络条件下走通？ShotHound正是为了解决这类“可行性疑惑”而诞生的，它把 BloodHound 绘制的抽象关系映射到可执行的网络探测上。

ShotHound 的核心功能

ShotHound 采用 CornerShot 的“代理探测”机制，以极少的跳板主机（通常不超过两台）对目标网络执行端口可达性扫描。它把每一次探测结果包装成 JSON，直接对应到 BloodHound 中的节点属性：是否可达、延迟、过滤状态。因此，安全分析师不必再手动比对 Nmap 与血缘图，而是得到一张“可执行路径图”。

BloodHound 路径验证的技术原理

BloodHound 通过收集 AD 中的对象关系（如memberOf、hasSession）生成数百万条潜在提权路径。其查询语言 (Cypher) 能快速筛选出满足特定条件的链路，但始终假设网络连通性是理所当然的。若路径中某台服务器的 RDP 端口被防火墙阻断，图谱仍会误报可行性。

ShotHound 与 BloodHound 的协同机制

两者的结合点在于“属性注入”。ShotHound 将探测结果写回 BloodHound 的属性字段，例如hasNetworkAccess或portStatus。随后，分析师可以在 Cypher 中加入WHERE node.hasNetworkAccess = true的过滤条件，实现“可达路径”筛选。这样，原本需要手工验证的数千条链路，瞬间被压缩到几百条真正可执行的路径。

实战案例：从域控制器到高价值服务器的可达性检验

• 红队在已渗透的工作站 A 上部署 ShotHound，指定代理 B（同段子网）和目标服务器 C（IP 为 10.2.5.23）。
• ShotHound 通过 B 发起对 C 的 445、3389、5986 三端口探测，返回结果显示 445 为 open、3389 为 filtered、5986 为 unknown。
• 脚本自动将上述状态写入 BloodHound 的 hasNetworkAccess 属性，随后在图谱中执行 MATCH p=shortestPath((a:User)-[*]->(c:Computer)) WHERE c.hasNetworkAccess = true RETURN p。
• 最终得到的路径仅包含通过 445 端口的 SMB 共享，排除了原本被误判的 RDP 入口，省下了数小时的手工排查时间。

从技术角度看，ShotHound 把“网络可视化”从被动的拓扑图转化为主动的可达性数据；而 BloodHound 则把这些数据重新编织进权限提升的血缘网络，形成闭环验证。两者的协同让渗透团队在“找路”与“走路”之间不再有信息鸿沟。