jazofra/CyberArkHound

## CyberArkHound 将 CyberArk PVWA 数据（用户、组、保险箱、账户、平台和权限）导出为兼容 BloodHound 的 OpenGraph JSON 文件，用于安全分析和攻击路径可视化。 ### 快速开始 **Windows:** ``` # 下载或构建 binary go build -o cyberarkhound.exe ./cmd/cyberarkhound # 运行 tool .\cyberarkhound.exe ` --pvwa https://pvwa.example.com ` --username svc-bloodhound ` --password $Env:CYBERARK_PASSWORD ` --output cyberark_export.json ` --target-domains corp.example.com ``` **Linux/macOS:** ``` # 构建 binary go build -o cyberarkhound ./cmd/cyberarkhound # 运行 tool ./cyberarkhound \ --pvwa https://pvwa.example.com \ --username svc-bloodhound \ --password "$CYBERARK_PASSWORD" \ --output cyberark_export.json \ --target-domains corp.example.com ``` 生成的 `cyberark_export.json` 文件可以直接导入到 BloodHound 中。 ### 功能特性 - **高性能**：Go 语言实现，支持并发处理和高效内存使用 - **健壮的 API 客户端**：具备指数退避重试逻辑和可选的 SSL 自定义 - **全面数据提取**：用户、组、保险箱、账户及其完整属性集 - **基于权限的访问建模**：直接账户访问 vs 权限提升路径 - **LDAP/目录同步跟踪**：识别同步用户与本地用户、同步组与本地组 - **外部 AD 实体推断**：自动检测与 Active Directory 的关系 - **账户活动跟踪**：可选的 `CyberArk_UsedAccount` 边显示实际使用模式 - **链接账户链分析**：可选的 `CyberArk_LinkedTo` 边映射登录/协调/启用账户依赖关系，用于凭证链遍历 - **保险箱创建者和 CPM 跟踪**：`CyberArk_Created` 和 `CyberArk_ManagedBy` 边显示谁创建和管理每个保险箱 - **基于平台的分组**：可选的 `CyberArk_Platform` 节点和 `CyberArk_UsesPlatform` 边用于共享攻击面分析 - **PSM 基础设施映射**：可选的 `CyberArk_PSMServer` 和 `CyberArk_ConnectionComponent` 节点以及边，显示每个平台和账户使用的 PSM 服务器和连接协议（RDP、SSH 等）；`CyberArk_PSMServerHostedOn` 外部边将 PSM 服务器链接到其 AD 计算机对象 - **双重控制感知**：每个账户的 `requiresApproval` 源自平台主策略设置（带审批人存在性回退）；`CyberArk_CanApprove` 边标识谁可以授权双重控制访问 - **主策略异常检测**：平台节点上的标志识别偏离主策略默认值的设置，用于审计和合规 - **平台数据弹性获取**：当 `/API/Platforms/` 不可用时，自动回退到 `/API/Platforms/Targets`，保留所有安全相关属性 - **富元数据**：个人详细信息、保险库授权、保险箱权限、账户管理状态 - **保险箱权限跟踪**：按用户/组统计保险箱访问权限及详情 - **保留外部边**：AD 同步关系单独存储，用于跨域分析 - **调试日志**：全面的诊断信息，便于故障排除 ### 所需 CyberArk 用户权限 要成功从 CyberArk PVWA 吸收数据，API 用户需要特定的保险库授权。运行此工具的用户必须拥有 **审计用户 (Audit Users)** 保险库授权，这提供了对保险库中所有用户和组的读取访问权限。 用户需要对 CyberArk 内的所有保险箱拥有 `list` 和 `查看保险箱成员 (View Safe members)` 权限（直接拥有或通过组成员身份获得），这将允许用户查看 CyberArk 中的所有账户和保险箱。 或者，用户可以是本地 CyberArk 保险库组 'Auditors' 的成员，这将授予用户对所有保险箱、账户和组的只读访问权限。但是，这也会授予查看会话（PSM）录像的权限，这是不建议的。 #### 推荐设置 为 BloodHound 数据收集创建一个专用的服务账户： 1. **创建保险库用户**：`bloodhound-collector`（或类似名称） 2. **授予保险库授权**：`审计用户 (Audit Users)` 3. **身份验证方法**：CyberArk 身份验证（也支持 LDAP/RADIUS） 4. **用户类型**：EPVUser（非 LDAP）或目录用户 5. **保险箱权限**：用户需要是环境中所有保险箱的成员，或者是拥有所有保险箱成员身份的组的成员。所需权限是 `list` 和 `查看保险箱成员 (View Safe Members)` 6. **将此账户存储在 CyberArk 中**：以确保根据 CyberArk 策略进行定期轮换 7. **使用 CCP/CP 检索凭据**：如果环境中使用了 CCP/CP，请使用它在需要时检索凭据 #### 工具可查看的内容 拥有 `审计用户 (Audit Users)` 授权，工具可以： - ✅ 列出所有保险库用户和组 - ✅ 查看用户组成员身份 对每个保险箱拥有 `list` 和 `查看保险箱成员 (View Safe Members)` 权限，工具可以： - ✅ 列出保险箱中的所有账户（无凭据） - ✅ 列出保险库中的所有保险箱 - ✅ 列出所有保险箱成员及其权限 #### 工具不能做什么： - ❌ **不能**检索或查看账户密码 - ❌ **不能**修改任何保险库对象 - ❌ **不能**修改平台应用程序设置 #### 使用的 API 端点 - `POST /API/Auth/CyberArk/Logon` - 身份验证 - `GET /API/safes` - 列出所有保险箱 - `GET /API/Safes/{safeUrlId}/Members` - 列出保险箱成员和权限 - `GET /API/Accounts` - 列出账户（按保险箱筛选） - `GET /API/Accounts/{accountId}` - 获取账户详情 - `GET /API/Accounts/{accountId}/Activities` - 获取账户活动日志（可选，需要 `--include-activity`） - `GET /API/Accounts/{accountId}/LinkedAccounts` - 获取链接账户：登录、协调、启用（可选，需要 `--include-linked-accounts`） - `GET /API/Platforms/` - 列出所有平台及完整配置（可选，需要 `--include-platforms`） - `GET /API/Platforms/Targets` - 列出目标平台及异常标志（可选，需要 `--include-platforms`；也用作 `/API/Platforms/` 失败时的回退） - `GET /API/Platforms/Targets/{id}/PrivilegedSessionManagement` - 获取每个平台的 PSM 连接器（可选，需要 `--include-platforms`） - `GET /API/PSM/Servers/` - 列出所有 PSM 服务器（可选，需要 `--include-psm`） - `GET /API/PSM/Connectors/` - 列出所有连接组件（可选，需要 `--include-psm`） - `GET /API/Users` - 列出所有用户 - `GET /API/UserGroups` - 列出所有组 - `GET /API/UserGroups/{groupId}` - 获取组详情及成员 - `POST /API/Auth/Logoff` - 会话清理 #### 安全注意事项 - `审计用户 (Audit Users)` 授权是只读的，不能修改保险库数据 - API 调用不会检索密码值 - 使用具有长/复杂密码的专用服务账户 - 定期轮换凭据 - 通过 PVWA 审计日志监控 API 使用情况 - 考虑对服务账户设置 IP 限制 - 将用户添加到 'Auditors' 组可以轻松提供所需权限，但会授予过多访问权限 ### 安装说明 **环境要求：** - Go 1.21 或更高版本 - Git（用于克隆仓库） **从源代码构建：** ``` # 克隆 repository git clone https://github.com/jazofra/CyberArkHound cd CyberArkHound # 构建 binary go build -o cyberarkhound.exe ./cmd/cyberarkhound # 或直接安装到 $GOPATH/bin go install ./cmd/cyberarkhound ``` **预编译二进制文件：** 从 [版本发布](https://github.com/jazofra/CyberArkHound/releases) 页面下载预编译的二进制文件。 ### 使用说明 **基本用法：** ``` .\cyberarkhound.exe ` --pvwa https://pvwa.example.com ` --username api_user ` --password $Env:CYBERARK_PASSWORD ` --output export.json ` --target-domains corp.example.com,lab.example.com ``` **包含活动跟踪：** ``` .\cyberarkhound.exe ` --pvwa https://pvwa.corp.com ` --username svc-bloodhound ` --password $Env:CYBERARK_PASSWORD ` --output cyberark_export.json ` --target-domains corp.example.com,lab.example.com ` --include-activity ` --activity-days 30 ` --workers 100 ``` **启用调试：** ``` .\cyberarkhound.exe ` --pvwa https://pvwa.corp.com ` --username svc-bloodhound ` --password $Env:CYBERARK_PASSWORD ` --output cyberark_export.json ` --target-domains corp.example.com ` --debug ` --log-level DEBUG ``` **大型环境性能提示：** - 将 `--workers` 增加到 100-200 以加快并行处理速度 - 使用 `--log-level WARNING` 减少日志开销 - 该工具使用原生 goroutine 进行真正的并行计算，实现高效内存管理 - 重新身份验证是单例化的：当多个 worker 同时收到 HTTP 401 时，只有一个进行重新身份验证，而其他 worker 等待并重新使用刷新的令牌——避免雷鸣式令牌洪泛 ### 命令行参数 **必需参数：** - `--pvwa` PVWA 基础 URL（例如，https://pvwa.example.com） - `--username` API 用户名 - `--password` API 密码（考虑使用环境变量） - `--output` 用于 BloodHound 导入的目标 JSON 文件 - `--target-domains` 一个或多个 AD 域名（逗号分隔），用于将账户链接到 AD 用户 **可选参数：** - `--workers` 并行操作的并发数（默认：50，大型环境推荐：100-200） - `--insecure` 禁用 SSL 验证（生产环境不推荐） - `--ca-bundle` 自定义 CA 证书包的路径，用于 SSL 验证 - `--auth-timeout` 身份验证超时时间（秒）（默认：360） - `--req-timeout` 请求超时时间（秒）（默认：360） - `--quiet` 禁止显示信息/调试日志 - `--debug` 启用调试日志并提供详细诊断信息 - `--log-level` 设置日志级别：DEBUG、INFO（默认）、WARNING、ERROR - `--safe-page-limit` 用于分页的保险箱页面大小（默认：1000；降低此值有助于处理响应缓慢的 PVWA） - `--max-reauth-attempts` HTTP 401 后放弃前的最大重新身份验证尝试次数（默认：5） **活动跟踪：** - `--include-activity` 包含账户活动数据（创建 `CyberArk_UsedAccount` 边） - `--activity-days` 回溯查找活动的天数（默认：3） - `--activity-limit` 从 API 获取的每个账户的最大活动数（默认：100） **链接账户与平台：** - `--include-linked-accounts` 包含链接账户数据（为登录/协调/启用账户链创建 `CyberArk_LinkedTo` 边） - `--include-platforms` 包含平台数据（创建 `CyberArk_Platform` 节点和 `CyberArk_UsesPlatform` 边） - `--include-psm` 包含 PSM 服务器和连接组件数据（创建 `CyberArk_PSMServer` 和 `CyberArk_ConnectionComponent` 节点以及链接边） **测试/开发：** - `--limit-users` 限制要处理的用户数量（0 = 无限制） - `--limit-groups` 限制要处理的组数量（0 = 无限制） - `--limit-safes` 限制要处理的保险箱数量（0 = 无限制） - `--test-safe` 仅处理匹配搜索词的保险箱 ### 边类型和权限解释 该工具根据用户/组对保险箱拥有的权限创建不同的边类型： #### CyberArk_HasAccessTo（用户/组 → 账户） **直接账户访问** - 用户/组可以立即使用或检索账户凭据： - `useAccounts`: 通过 PSM 连接使用账户，但无法查看密码 - `retrieveAccounts`: 检索并查看账户密码 **模式**：当用户对某个保险箱拥有这些权限时，会创建从该用户到该保险箱中**每个账户**的边。这清楚地显示了用户可以访问哪些账户。 **BloodHound 查询示例：** ``` // Find all accounts a user can access MATCH (u:CyberArk_User {name: "jdoe"})-[:CyberArk_HasAccessTo]->(a:CyberArk_Account) RETURN a.name // Find all users who can access a specific account MATCH (u:CyberArk_User)-[:CyberArk_HasAccessTo]->(a:CyberArk_Account {name: "prod-db-admin"}) RETURN u.name // Find LDAP users with direct account access MATCH (u:CyberArk_User {isLDAPSynced: true})-[:CyberArk_HasAccessTo]->(a:CyberArk_Account) RETURN u.name, a.name ``` #### CyberArk_CanGrantAccessTo（用户/组 → 保险箱） **权限提升** - 用户/组可以修改保险箱以授予自己账户访问权限： - `manageSafe`: 更新保险箱属性、恢复保险箱、删除保险箱 - `manageSafeMembers`: 添加/移除保险箱成员并修改其权限 **攻击路径**：拥有 `manageSafeMembers` 权限的用户可以添加自己并赋予 `retrieveAccounts` 权限，然后访问保险箱中的所有账户。此边指向**保险箱本身**，因为用户必须先提升权限才能访问账户。 **BloodHound 查询示例：** ``` // Find privilege escalation paths to accounts MATCH (u:CyberArk_User)-[:CyberArk_CanGrantAccessTo]->(s:CyberArk_Safe)-[:CyberArk_Contains]->(a:CyberArk_Account) RETURN u.name, s.name, a.name // Find users who can grant themselves access to production safes MATCH (u:CyberArk_User)-[:CyberArk_CanGrantAccessTo]->(s:CyberArk_Safe) WHERE s.safeName CONTAINS "prod" RETURN u.name, s.safeName ``` #### 边类型汇总 | 边 | 方向 | 来源 | 安全价值 | |------|-----------|--------|----------------| | `CyberArk_HasAccessTo` | 用户/组 → 账户 | 保险箱成员 `useAccounts`/`retrieveAccounts` | 直接凭据访问；`requiresApproval` 显示双重控制是否阻止检索 | | `CyberArk_CanGrantAccessTo` | 用户/组 → 保险箱 | 保险箱成员 `manageSafe`/`manageSafeMembers` | 权限提升——可以授予自己账户访问权限 | | `CyberArk_CanApprove` | 用户/组 → 保险箱 | 保险箱成员 `requestsAuthorizationLevel1`/`Level2` | 可以批准双重控制访问请求（L1/L2） | | `CyberArk_UsedAccount` | 用户 → 账户 | `GET /API/Accounts/{id}/Activities` | 实际使用审计跟踪——谁真正访问了什么 | | `CyberArk_LinkedTo` | 账户 → 账户 | `GET /API/Accounts/{id}/LinkedAccounts` | 登录/协调/启用凭据链——攻陷一个会传播到所有依赖项 | | `CyberArk_Created` | 用户 → 保险箱 | 现有 `Safe.Creator` 字段 | 显示谁创建了每个保险箱（隐含所有权/访问权限） | | `CyberArk_ManagedBy` | CPM 用户 → 保险箱 | 现有 `Safe.ManagingCPM` 字段 | CPM 账户拥有特权密码管理访问权限 | | `CyberArk_UsesPlatform` | 账户 → 平台 | `GET /API/Platforms/Targets` | 共享平台配置 = 共享攻击面 | | `CyberArk_UsesPSMServer` | 平台 → PSM 服务器 | 平台 `PSMServerID` 字段 | 哪个 PSM 服务器处理每个平台的会话 | | `CyberArk_ManagedByPSM` | 账户 → PSM 服务器 | 通过账户的平台派生 | 直接链接，用于查询哪个 PSM 服务器管理账户的会话 | | `CyberArk_HasConnectionComponent` | 平台 → 连接组件 | `GET /API/Platforms/Targets/{id}/PrivilegedSessionManagement` | 每个平台启用了哪些连接协议（RDP、SSH 等） | | `CyberArk_PSMServerHostedOn` | PSM 服务器 → AD 计算机 | PSM 服务器 `Address` 字段（大写） | 外部边——将 PSM 服务器映射到其 AD 计算机对象 | | `CyberArk_MemberOf` | 用户/组 → 组 | 组成员身份数据 | 基于组的权限继承 | | `CyberArk_Contains` | 保险箱 → 账户 | 账户的 `safeName` 字段 | 保险箱-账户包含关系 | | `CyberArk_InstanceContains` | 实例 → 用户/组/保险箱/平台/PSM 服务器/连接组件 | 派生（每个 PVWA 标签一个根） | 环境根包含——将所有对象限定到其 PVWA 实例 | | `CyberArk_SyncsToUser` | AD 用户 → CyberArk_User | 带有 `DC=` 的 LDAP DN | 外部边——AD 到 CyberArk 身份映射 | | `CyberArk_SyncsToGroup` | AD 组 → CyberArk_Group | 带有 `DC=` 的 LDAP DN | 外部边——AD 到 CyberArk 组映射 | | `CyberArk_SyncsToADUser` | CyberArk_Account → AD 用户 | 账户地址匹配目标域 | 外部边——凭据到 AD 用户映射 | | `CyberArk_CanConnect` | CyberArk_Account → AD 计算机 | 账户地址匹配目标域的地址子域（本地账户） | 外部边——凭据到 AD 计算机映射 | **注意**：像 `listAccounts`、`viewAuditLog`、`addAccounts`、`updateAccountContent` 这样的权限**不会**创建访问边，因为它们不允许检索密码或使用账户。 #### CyberArk_UsedAccount（用户 → 账户） - 可选 **实际账户使用** - 跟踪用户何时真正检索或使用了账户（不仅仅是权限）： - 当使用 `--include-activity` 标志时创建 - 基于 CyberArk 活动/审计日志（通过 `/API/Accounts/{accountId}/Activities`） - 显示过去 3 天（默认）的实际账户访问模式 - 有助于识别休眠账户 vs 活跃使用账户 - 每个用户-账户对一条边（聚合多个活动） **模式**：边从用户创建到他们在指定时间窗口（`--activity-days`）内实际访问过的账户。同一用户的多个活动被聚合为一条边，显示最近的操作。 **边属性**： - `lastUsedTime`: 最近访问的 ISO 8601 时间戳（例如，"2025-11-25T14:32:01+00:00"） - `lastActivity`: 执行的最近操作（例如，"CPM Verify Password", "RetrievePassword", "ShowPassword"） - `usageCount`: 在时间窗口内该用户访问该账户的总次数 - `inferred`: `false`（基于实际审计数据） **技术细节**： - 活动按 Unix 时间戳（Date 字段 >= current_time - days * 86400）筛选 - 仅处理回溯窗口内的活动 - 如果用户执行了多个操作，仅将最近的操作存储在 `lastActivity` 中 - `usageCount` 反映所有符合条件的活动，而不仅仅是最近的 - 活动获取使用并行处理（默认 50 个 worker） **BloodHound 查询示例：** ``` // Find who actually used high-value accounts MATCH (u:CyberArk_User)-[r:CyberArk_UsedAccount]->(a:CyberArk_Account) WHERE a.safeName CONTAINS "prod" RETURN u.name, a.name, r.lastUsedTime, r.lastActivity, r.usageCount ORDER BY r.lastUsedTime DESC // Find accounts with access permissions but no actual usage (dormant/unused) MATCH (u:CyberArk_User)-[:CyberArk_HasAccessTo]->(a:CyberArk_Account) WHERE NOT (u)-[:CyberArk_UsedAccount]->(a) RETURN u.name, a.name, a.safeName // Find users who accessed accounts they shouldn't have permission for (privilege escalation) MATCH (u:CyberArk_User)-[:CyberArk_UsedAccount]->(a:CyberArk_Account) WHERE NOT (u)-[:CyberArk_HasAccessTo]->(a) RETURN u.name, a.name // Find most active users MATCH (u:CyberArk_User)-[r:CyberArk_UsedAccount]->(a:CyberArk_Account) RETURN u.name, COUNT(a) as accountsUsed, SUM(r.usageCount) as totalAccesses ORDER BY totalAccesses DESC LIMIT 10 ``` **性能说明**：活动跟踪会显著增加 API 调用次数（每个账户一次）。对于大型环境（1000+ 个账户），预计： - 由于并行 API 请求，处理时间会增加 5-15 分钟 - 默认回溯期为 3 天，以平衡时效性与性能 - 使用 `--activity-days 7` 或 `--activity-days 30` 进行更长的历史分析 - 使用 `--activity-limit` 限制每个账户获取的活动数（默认：100） - 活动获取并行运行（50 个线程）以获得最佳性能 - 可以与初始数据收集分开运行，用于增量更新 #### 双重控制（访问确认）感知 CyberArk 的双重控制功能要求用户在检索密码之前获得授权保险箱成员的批准。CyberArkHound 使用平台策略数据和保险箱成员权限的组合来确定双重控制状态。 **CyberArk 双重控制的工作原理：** 双重控制由 **主策略 (Master Policy)** 规则"需要双重控制密码访问批准 (Require dual control password access approval)" 管理，该规则可以全局设置或针对每个平台覆盖。每个平台的有效策略通过 `/API/Platforms/` 端点的 `privilegedAccessWorkflows.requireDualControlPasswordAccessApproval` 字段公开。拥有 `requestsAuthorizationLevel1` 或 `requestsAuthorizationLevel2` 权限的保险箱成员充当 **审批人**，负责确认或拒绝访问请求。 **CyberArkHound 如何确定 `requiresApproval`：** `CyberArk_HasAccessTo` 边上的 `requiresApproval` 属性是**按账户**使用分层方法计算的： | 层级 | 来源 | 检查 | |-------|--------|-------| | 1. 平台策略（主要） | `GET /API/Platforms/` → `requireDualControlPasswordAccessApproval` | 在有效的主策略中，是否为该账户的平台启用了双重控制？ | | 2. 审批人存在性（执行） | 保险箱成员权限 → `requestsAuthorizationLevel1` / `Level2` | 保险箱中是否有至少一名成员可以批准请求？如果没有审批人，即使策略启用了双重控制，也无法执行。 | | 3. 成员绕过 | 保险箱成员权限 → `accessWithoutConfirmation` | 该特定成员是否可以绕过双重控制？如果为 `true`，则 `requiresApproval` 始终为 `false`。 | 一个账户的 `requiresApproval` 仅当**所有三个条件**都满足时才为 `true`： 1. 该账户的平台具有 `requireDualControlPasswordAccessApproval: true` 2. 保险箱中至少有一名拥有 L1/L2 批准权限的成员 3. 访问成员**没有** `accessWithoutConfirmation: true` **当平台数据不可用时的回退：** 当未使用 `--include-platforms` 时，无法检查平台策略。在这种情况下，CyberArkHound 会回退到 **审批人存在性启发式**：如果保险箱中拥有 L1/L2 批准权限的成员，则假定双重控制处于活动状态。这可能会产生误报（例如，审批人权限来自模板，但主策略禁用了双重控制）。使用 `--include-platforms` 可获得准确的双重控制检测。 **使用的 CyberArk 保险箱成员权限：** | 权限 | 类型 | 作用 | |------------|------|------| | `accessWithoutConfirmation` | bool | 成员可以绕过双重控制，无需批准即可检索密码 | | `requestsAuthorizationLevel1` | bool | 成员可以批准来自其他用户的 1 级访问请求 | | `requestsAuthorizationLevel2` | bool | 成员可以批准来自其他用户的 2 级访问请求 | **使用的平台策略字段（需要 `--include-platforms`）：** | 字段 | 来源 | 含义 | |-------|--------|---------| | `requireDualControlPasswordAccessApproval` | `GET /API/Platforms/` → `privilegedAccessWorkflows` | 该平台的有效主策略设置，包括任何平台级例外 | **CyberArk_HasAccessTo 上的边属性：** - `requiresApproval`: 如果成员在检索密码之前需要双重控制授权人的批准，则为 `true` - `requiresSessionMonitoring`: 如果该账户的平台要求 PSM 会话监控和隔离，则为 `true` - `recordsSessionActivity`: 如果该账户的平台记录并保存会话活动，则为 `true` **CyberArk_CanApprove 边属性：** - `approvalLevel`: 授权级别（1 或 2）——映射到 `requestsAuthorizationLevel1` / `requestsAuthorizationLevel2` 权限 **BloodHound 查询示例：** ``` // Users who can retrieve passwords WITHOUT any approval (highest risk) MATCH (u:CyberArk_User)-[r:CyberArk_HasAccessTo {requiresApproval: false}]->(a:CyberArk_Account) RETURN u.name, a.name, a.safeName // Users who REQUIRE approval — attack needs both accessor + approver MATCH (u:CyberArk_User)-[r:CyberArk_HasAccessTo {requiresApproval: true}]->(a:CyberArk_Account) RETURN u.name, a.name, a.safeName // Find approvers who can unlock access for dual-controlled safes MATCH (approver)-[r:CyberArk_CanApprove]->(s:CyberArk_Safe)-[:CyberArk_Contains]->(a:CyberArk_Account) RETURN approver.name, r.approvalLevel, s.safeName, COLLECT(a.name) // Full dual control attack path: need BOTH a user with access AND an approver MATCH (u:CyberArk_User)-[access:CyberArk_HasAccessTo {requiresApproval: true}]->(a:CyberArk_Account) MATCH (a)<-[:CyberArk_Contains]-(s:CyberArk_Safe)<-[approve:CyberArk_CanApprove]-(approver) RETURN u.name AS accessor, a.name AS account, approver.name AS approver, approve.approvalLevel // Users who are BOTH accessor and approver on the same safe (dual control bypass risk) MATCH (u)-[access:CyberArk_HasAccessTo {requiresApproval: true}]->(a:CyberArk_Account) MATCH (a)<-[:CyberArk_Contains]-(s:CyberArk_Safe)<-[:CyberArk_CanApprove]-(u) RETURN u.name, s.safeName, COLLECT(a.name) AS selfApprovableAccounts // Find platforms where dual control is enabled MATCH (p:CyberArk_Platform {requireDualControlPasswordAccessApproval: true}) RETURN p.name, p.systemType // Accounts on dual-control platforms but in safes without approvers (policy misconfiguration) MATCH (a:CyberArk_Account)-[:CyberArk_UsesPlatform]->(p:CyberArk_Platform {requireDualControlPasswordAccessApproval: true}) MATCH (s:CyberArk_Safe)-[:CyberArk_Contains]->(a) WHERE NOT ()-[:CyberArk_CanApprove]->(s) RETURN a.name, s.safeName, p.name AS platform // High-risk: accounts accessible WITHOUT session monitoring MATCH (u:CyberArk_User)-[r:CyberArk_HasAccessTo {requiresSessionMonitoring: false}]->(a:CyberArk_Account) RETURN u.name, a.name, a.safeName // Platforms that support RDP connections MATCH (p:CyberArk_Platform) WHERE 'PSM-RDP' IN p.connectionComponents RETURN p.name, p.connectionComponents // Platforms where dual control is DISABLED as an exception to Master Policy (high priority audit finding) MATCH (p:CyberArk_Platform) WHERE p.requireDualControlPasswordAccessApproval = false AND p.dualControlIsException = true RETURN p.name, p.systemType // Platforms where session monitoring is disabled as a Master Policy exception MATCH (p:CyberArk_Platform) WHERE p.requirePrivilegedSessionMonitoringAndIsolation = false AND p.sessionMonitoringIsException = true RETURN p.name, p.systemType // Find all PSM servers and their connected platforms MATCH (p:CyberArk_Platform)-[:CyberArk_UsesPSMServer]->(psm:CyberArk_PSMServer) RETURN psm.name, psm.address, COLLECT(p.name) AS platforms // Find accounts managed by a specific PSM server MATCH (a:CyberArk_Account)-[:CyberArk_ManagedByPSM]->(psm:CyberArk_PSMServer {name: "PSM Server Main"}) RETURN a.name, a.userName, a.safeName // Find platforms with RDP connection components enabled MATCH (p:CyberArk_Platform)-[:CyberArk_HasConnectionComponent]->(cc:CyberArk_ConnectionComponent {connectorId: "PSM-RDP"}) RETURN p.name, p.systemType // List all connection components and which platforms use them MATCH (p:CyberArk_Platform)-[:CyberArk_HasConnectionComponent]->(cc:CyberArk_ConnectionComponent) RETURN cc.connectorId, cc.displayName, COLLECT(p.name) AS platforms // Find AD Computers hosting PSM servers MATCH (psm:CyberArk_PSMServer)-[:CyberArk_PSMServerHostedOn]->(c:Computer) RETURN psm.name, c.name // Find accounts on platforms created from fallback data (investigate /API/Platforms/ failure) MATCH (a:CyberArk_Account)-[:CyberArk_UsesPlatform]->(p:CyberArk_Platform {dataSource: "targets-fallback"}) RETURN p.name, COUNT(a) AS accountCount ``` #### CyberArk_LinkedTo（账户 → 账户） - 可选 **链接账户依赖** - 映射凭据链，其中一个账户依赖另一个账户进行登录、协调或启用： - 当使用 `--include-linked-accounts` 标志时创建 - 基于 CyberArk 链接账户（通过 `/API/Accounts/{accountId}/LinkedAccounts`） - 链接类型：`logon`（ExtraPassID=1），`enable`（ExtraPassID=2），`reconcile`（ExtraPassID=3） - 对攻击路径分析至关重要：攻陷一个登录账户会获得对其所有依赖账户的访问权限 **边属性**： - `linkType`: 链接类型 — `logon`、`enable`、`reconcile` 或 `unknown` - `linkName`: 链接账户关系的名称 - `safeName`: 包含链接账户的保险箱 **BloodHound 查询示例：** ``` // Find all accounts that depend on a specific logon account MATCH (logon:CyberArk_Account {name: "svc-logon"})<-[r:CyberArk_LinkedTo {linkType: "logon"}]-(a:CyberArk_Account) RETURN a.name, a.safeName // Find credential chains: accounts linked through logon accounts MATCH path = (a:CyberArk_Account)-[:CyberArk_LinkedTo*1..3]->(target:CyberArk_Account) RETURN path // Find all reconcile account dependencies MATCH (a:CyberArk_Account)-[r:CyberArk_LinkedTo {linkType: "reconcile"}]->(reconciler:CyberArk_Account) RETURN a.name, reconciler.name, reconciler.safeName // Attack path: user with access to a logon account can reach all dependent accounts MATCH (u:CyberArk_User)-[:CyberArk_HasAccessTo]->(logon:CyberArk_Account)<-[:CyberArk_LinkedTo {linkType: "logon"}]-(dependent:CyberArk_Account) RETURN u.name, logon.name, COLLECT(dependent.name) as dependentAccounts ``` **性能说明**：链接账户获取为每个账户增加一次 API 调用。并行运行（默认 50 个 worker）。 #### CyberArk_Created（用户 → 保险箱） **保险箱创建者关系** - 显示哪个用户创建了每个保险箱： - 始终发出（无额外 API 调用——使用现有的 `Safe.Creator` 字段） - 有助于理解隐式访问和所有权 **边属性**： - `creatorId`: 创建者的保险库用户 ID **BloodHound 查询示例：** ``` // Find all safes created by a user MATCH (u:CyberArk_User)-[:CyberArk_Created]->(s:CyberArk_Safe) RETURN u.name, s.safeName // Find who created production safes MATCH (u:CyberArk_User)-[:CyberArk_Created]->(s:CyberArk_Safe) WHERE s.safeName CONTAINS "prod" RETURN u.name, s.safeName // Find users who created safes AND can grant access to them MATCH (u:CyberArk_User)-[:CyberArk_Created]->(s:CyberArk_Safe) WHERE (u)-[:CyberArk_CanGrantAccessTo]->(s) RETURN u.name, s.safeName ``` #### CyberArk_ManagedBy（CPM 用户 → 保险箱） **CPM 管理关系** - 显示哪个 CPM 组件管理每个保险箱的密码轮换： - 始终发出（无额外 API 调用——使用现有的 `Safe.ManagingCPM` 字段） - CPM 账户拥有管理和轮换密码的特权访问权限 **BloodHound 查询示例：** ``` // Find all safes managed by a specific CPM MATCH (cpm:CyberArk_User)-[:CyberArk_ManagedBy]->(s:CyberArk_Safe) WHERE cpm.name CONTAINS "CPM" RETURN cpm.name, COLLECT(s.safeName) as managedSafes // Find safes without CPM management (unmanaged passwords) MATCH (s:CyberArk_Safe) WHERE NOT ()-[:CyberArk_ManagedBy]->(s) RETURN s.safeName // Find all accounts reachable through a CPM's managed safes MATCH (cpm:CyberArk_User)-[:CyberArk_ManagedBy]->(s:CyberArk_Safe)-[:CyberArk_Contains]->(a:CyberArk_Account) RETURN cpm.name, COUNT(a) as accountCount ``` #### CyberArk_UsesPlatform（账户 → 平台） - 可选 **平台关联** - 显示每个账户使用哪个平台配置： - 当使用 `--include-platforms` 标志时创建 - 从 `/API/Platforms/Targets` 创建 `CyberArk_Platform` 节点 - 共享平台的账户共享配置、策略和潜在漏洞 **BloodHound 查询示例：** ``` // Find all accounts using a specific platform MATCH (a:CyberArk_Account)-[:CyberArk_UsesPlatform]->(p:CyberArk_Platform {name: "WinServerLocal"}) RETURN a.name, a.safeName // Find platforms with the most accounts (highest blast radius) MATCH (a:CyberArk_Account)-[:CyberArk_UsesPlatform]->(p:CyberArk_Platform) RETURN p.name, p.systemType, COUNT(a) as accountCount ORDER BY accountCount DESC // Find inactive platforms still in use MATCH (a:CyberArk_Account)-[:CyberArk_UsesPlatform]->(p:CyberArk_Platform {active: false}) RETURN p.name, COUNT(a) as accountsOnInactivePlatform ``` ### 节点属性 #### CyberArk_Instance 属性 - **标识**: `name`, `pvwaTag`（从 `--pvwa` 派生的 4 字符 PVWA 标签） - 环境根节点。每次运行会发出一个 `CyberArk_Instance` 节点，并通过 `CyberArk_InstanceContains` 链接到每个顶级对象（用户、组、保险箱、平台、PSM 服务器、连接组件）。账户通过其保险箱传递性地访问（`CyberArk_Instance` → `CyberArk_Safe` → `CyberArk_Contains` → `CyberArk_Account`）。 #### CyberArk_User 属性 - **标识**: `userId`, `name`, `userType`, `source`, `isLDAPSynced` - **状态**: `enabled`, `suspended`, `componentUser` - **身份验证**: `allowedAuthenticationMethods`, `vaultAuthorization` - **目录**: `distinguishedName`, `location`, `authorizedInterfaces` - **个人详情**: `firstName`, `lastName`, `email`, `businessEmail`, `businessPhone`, `mobilePhone`, `title`, `organization`, `department`, `profession`, `address`（街道、城市、州、邮编、国家） - **成员身份**: `groupsMembership`（组名列表） - **权限**: `safePermissions`（JSON 数组，包含 safeName、权限、hasDirectAccess、canGrantAccess） #### CyberArk_Group 属性 - **标识**: `groupId`, `name`, `groupType`, `isDirectorySynced` - **目录**: `directory`, `distinguishedName`, `location` - **元数据**: `description`, `memberCount` - **成员**: `members`（用户名列表） - **权限**: `safePermissions`（包含保险箱访问详情的 JSON 数组） #### CyberArk_Safe 属性 - **标识**: `safeName`, `safeUrlId`, `safeNumber` - **元数据**: `description`, `location`, `creator` - **CPM**: `managingCPM`, `olacEnabled` - **保留策略**: `numberOfVersionsRetention`, `numberOfDaysRetention`, `autoPurgeEnabled` - **时间戳**: `creationTime`, `lastModificationTime` - **设置**: `isExpiredMembershipEnable` #### CyberArk_Account 属性 - **标识**: `accountId`, `userName`, `platformId`, `address` - **BloodHound 名称**: `name`（设置为 `userName` 以避免与 OpenGraph 匹配中的 AD 用户名冲突） - **保险箱**: `safeName`, `safeUrlId` - **状态**: `status`, `enabled`, `secretType` - **管理**: `automaticManagementEnabled`, `manualManagementReason` - **时间戳**: `createdTime`, `lastModifiedTime`, `lastVerifiedTime`, `lastReconciledTime`, `categoryModificationTime` - **CPM**: `lastModifiedBy` - **扩展**: `platformAccountProperties` (JSON), `secretManagement` (JSON) #### CyberArk_Platform 属性（需要 `--include-platforms`） - **标识**: `platformId`, `name` - **配置**: `systemType`, `active`, `platformBaseID`, `platformType` - **元数据**: `description`, `allowedSafes` - **属性**: `requiredProperties`, `optionalProperties`（字段定义） - **链接账户**: `linkedAccountTypes`（例如，LogonAccount, ReconcileAccount） - **连接组件**: `connectionComponents`（启用的 PSM 连接器 ID 列表，例如，`["PSM-RDP", "PSM-SSH"]`） - **会话管理**: `psmServerID`, `requirePrivilegedSessionMonitoringAndIsolation`, `recordAndSaveSessionActivity` - **凭据管理**: `allowManualChange`, `performPeriodicChange`, `requirePasswordChangeEveryXDays`, `allowManualVerification`, `performPeriodicVerification`, `requirePasswordVerificationEveryXDays`, `allowManualReconciliation`, `automaticReconcileWhenUnsynched` - **特权访问工作流**: `requireDualControlPasswordAccessApproval`, `enforceCheckinCheckoutExclusiveAccess`, `enforceOnetimePasswordAccess`, `requireUsersToSpecifyReasonForAccess` - **主策略异常标志**: `dualControlIsException`, `exclusiveAccessIsException`, `otpIsException`, `reasonForAccessIsException`, `sessionMonitoringIsException`, `sessionRecordingIsException`, `verificationFrequencyIsException`, `changeFrequencyIsException` — 当平台设置偏离主策略默认值时为 `true` - **数据源**: `dataSource` — 当节点是从 `/API/Platforms/Targets`（而不是 `/API/Platforms/`）创建时设置为 `"targets-fallback"`（见下文回退行为） **平台数据回退：** 当 `GET /API/Platforms/` 失败（例如，由于损坏的平台定义导致 HTTP 500）时，CyberArkHound 会从 `GET /API` 响应创建平台节点。这些回退节点包含大多数安全相关属性（工作流、凭据管理、PSM 服务器、异常标志），但缺少 `description`、`platformBaseID`、`platformType`、`requiredProperties`、`optionalProperties` 和 `linkedAccountTypes`。回退节点被标记为 `dataSource: "targets-fallback"`。 #### CyberArk_PSMServer 属性（需要 `--include-psm`） - **标识**: `psmServerId`（例如，`"PSMServer_7ec0ecb"`） - **配置**: `name`（例如，`"PSM Server CYB-IS-12345"`），`address`（例如，`"10.10.10.20"`） #### CyberArk_ConnectionComponent 属性（需要 `--include-psm`） - **标识**: `connectorId`（例如，`"PSM-RDP"`, `"PSM-SSH"`） - **显示**: `displayName`（例如，`"RDP"`, `"SSH"`） ### 输出 生成的 JSON 结构遵循 BloodHound OpenGraph schema： 注意：CyberArk 节点的 `id` 值使用从 `--pvwa` 派生的 4 字符 PVWA 标签作为命名空间（例如，`causer-jdoe-APVA`），以避免吸收多个 PVWA 实例时发生冲突。 ``` { "metadata": { "source_kind": "CyberArkBase" }, "graph": { "nodes": [ { "id": "causer-jdoe-APVA", "kinds": ["CyberArk_User", "CyberArkBase"], "properties": { "name": "jdoe", "isLDAPSynced": true, "vaultAuthorization": "[\"Audit Users\", \"Safe Managers\"]", "safePermissions": "[{\"safeName\":\"Production\",\"permissions\":[\"useAccounts\",\"retrieveAccounts\"],\"hasDirectAccess\":true}]", "email": "jdoe@corp.com", "department": "IT Security" } }, { "id": "caaccount-12345-APVA", "kinds": ["CyberArk_Account", "CyberArkBase"], "properties": { "name": "prod-db-admin", "platformId": "WinServerLocal", "address": "prod-sql-01.corp.com", "safeName": "Production", "automaticManagementEnabled": true } } ], "edges": [ { "kind": "CyberArk_HasAccessTo", "start": "causer-jdoe-APVA", "end": "caaccount-12345-APVA", "properties": { "matchedPermissionNames": ["useAccounts", "retrieveAccounts"], "via": "casafe-Production-APVA", "viaSafeName": "Production" } } ] } } ``` **外部边**（AD 同步关系）也包含在同一结构中，并带有 `match_by` 元数据，用于跨域关联。 ``` { "metadata": { "source_kind": "CyberArkBase" }, "graph": { "nodes": [ { "id": "...", "kinds": ["CyberArk_User"], "properties": {"name": "..."} } ], "edges": [ { "kind": "CyberArk_HasAccessTo", "start": {"value": "...", "match_by": "id"}, "end": {"value": "...", "match_by": "id"} } ] } } ``` 外部边（CyberArk_SyncsToUser / CyberArk_SyncsToGroup / CyberArk_SyncsToADUser / CyberArk_CanConnect / CyberArk_PSMServerHostedOn）被包含在内，并在适当情况下将 `match_by` 设置为 `name`。 ### 数据流图 CyberArk 实体与推断的外部 AD 对象之间的高级关系可视化： ``` --- config: layout: elk --- flowchart TD User["fa:fa-user User"] -. CyberArk_SyncsToUser
(LDAP) .-> CyberArk_User["fa:fa-user CyberArk_User"] Group["fa:fa-user-group Group"] -. CyberArk_SyncsToGroup
(Directory) .-> CyberArk_Group["fa:fa-user-group CyberArk_Group"] CyberArk_Account["fa:fa-user-secret CyberArk_Account"] -. CyberArk_SyncsToADUser
(Domain Match) .-> User CyberArk_Account -. CyberArk_CanConnect
(Domain Match) .-> Computer["fa:fa-computer Computer"] CyberArk_User -- CyberArk_MemberOf --> CyberArk_Group CyberArk_Group -- CyberArk_MemberOf --> CyberArk_Group CyberArk_User == CyberArk_HasAccessTo
(useAccounts/retrieveAccounts) ==> CyberArk_Account CyberArk_Group == CyberArk_HasAccessTo
(useAccounts/retrieveAccounts) ==> CyberArk_Account CyberArk_User == CyberArk_UsedAccount
(actual usage) ==> CyberArk_Account CyberArk_User -. CyberArk_CanGrantAccessTo
(manageSafe/manageSafeMembers) .-> CyberArk_Safe["fa:fa-vault CyberArk_Safe"] CyberArk_Group -. CyberArk_CanGrantAccessTo
(manageSafe/manageSafeMembers) .-> CyberArk_Safe CyberArk_User -. CyberArk_CanApprove
(dual control) .-> CyberArk_Safe CyberArk_Group -. CyberArk_CanApprove
(dual control) .-> CyberArk_Safe CyberArk_Safe -- CyberArk_Contains --> CyberArk_Account CyberArk_User -. CyberArk_Created .-> CyberArk_Safe CyberArk_User -. CyberArk_ManagedBy
(CPM) .-> CyberArk_Safe CyberArk_Account -. CyberArk_LinkedTo
(logon/reconcile/enable) .-> CyberArk_Account CyberArk_Account -- CyberArk_UsesPlatform --> CyberArk_Platform["fa:fa-server CyberArk_Platform"] CyberArk_Account -- CyberArk_ManagedByPSM --> CyberArk_PSMServer["fa:fa-desktop CyberArk_PSMServer"] CyberArk_Platform -- CyberArk_UsesPSMServer --> CyberArk_PSMServer CyberArk_Platform -- CyberArk_HasConnectionComponent --> CyberArk_ConnectionComponent["fa:fa-plug CyberArk_ConnectionComponent"] CyberArk_PSMServer -. CyberArk_PSMServerHostedOn .-> Computer style User fill:#17E625,stroke:#0B8A14,stroke-width:2px style Computer fill:#FCAEA3,stroke:DF7E71,stroke-widthg:2px style CyberArk_User fill:#BFD6E3,stroke:#7BA3C0,stroke-width:2px style Group fill:#FFED29,stroke:#CCB900,stroke-width:2px style CyberArk_Group fill:#C8DCC0,stroke:#8FB888,stroke-width:2px style CyberArk_Account fill:#E7C8C8,stroke:#C09999,stroke-width:2px style CyberArk_Safe fill:#E8D8B3,stroke:#C0AC7F,stroke-width:2px style CyberArk_Platform fill:#D4B8D9,stroke:#A98CB3,stroke-width:2px style CyberArk_PSMServer fill:#A8D5BA,stroke:#7BB898,stroke-width:2px style CyberArk_ConnectionComponent fill:#B8C9E0,stroke:#8EA6C4,stroke-width:2px ``` **图例：** - **实线** (→)：CyberArk 内部关系（成员身份、包含、平台、PSM 服务器、连接组件） - **粗线** (⇒)：直接账户访问边（基于权限或实际使用） - **虚线** (⇢)：外部同步关系、权限提升、双重控制批准、链接账户、创建者/CPM 管理 ### BloodHound 自定义节点定义 文件 `cyberark_model.json` 通过 API Explorer `custom-nodes` 端点为 BloodHound 定义自定义节点类型（图标和颜色）： ``` { "custom_types": { "CyberArk_Account": {"icon": {"type": "font-awesome", "name": "user-secret", "color": "#E7C8C8"}}, "CyberArk_Group": {"icon": {"type": "font-awesome", "name": "user-group", "color": "#C8DCC0"}}, "CyberArk_Safe": {"icon": {"type": "font-awesome", "name": "vault", "color": "#E8D8B3"}}, "CyberArk_User": {"icon": {"type": "font-awesome", "name": "user", "color": "#BFD6E3"}}, "CyberArk_Platform": {"icon": {"type": "font-awesome", "name": "server", "color": "#D4B8D9"}}, "CyberArk_PSMServer": {"icon": {"type": "font-awesome", "name": "desktop", "color": "#A8D5BA"}}, "CyberArk_ConnectionComponent": {"icon": {"type": "font-awesome", "name": "plug", "color": "#B8C9E0"}} } } ``` #### 应用自定义类型 使用 BloodHound API（请调整主机和身份验证）： ``` curl -X POST -H "Content-Type: application/json" -d @cyberark_model.json https://bloodhound.example.com/api/custom-nodes ``` 或者，在导入导出的图之前，将其放入或合并到您现有的自定义工作流中。 加载后，BloodHound 将使用与上面图表匹配的有意义图标/颜色渲染 CyberArk 节点。 #### 维护 - 通过在 `custom_types` 下添加条目来扩展其他 CyberArk 派生类型。 - 保持调色板不同，以便快速视觉分类（避免使用接近重复的十六进制代码）。 - 如果分发给多个团队，请对文件进行版本控制（例如，`cyberark_model.v1.json`）。 ### 日志记录和详细程度控制 该工具提供灵活的日志记录控制，以在可见性和输出量之间取得平衡。 #### 日志级别 使用 `--log-level` 控制进度报告的频率： **WARNING/ERROR** - 最小输出，仅显示关键消息： ``` .\cyberarkhound.exe --pvwa ... --log-level WARNING --output export.json --target-domains corp.com ``` - 显示主要阶段的开始/结束 - 无中间进度更新 - 最适合自动化/定时运行 **INFO**（默认）- 平衡的进度更新： ``` .\cyberarkhound.exe --pvwa ... --log-level INFO --output export.json --target-domains corp.com ``` - 每 50 个用户/组更新进度 - 每 20 个保险箱更新进度 - 每 100 个账户/成员更新进度 - 导出时每 100 个节点更新进度 - 导出时每 500 条边更新进度 - 推荐用于交互式运行 **DEBUG** - 详细的进度信息，用于故障排除： ``` .\cyberarkhound.exe --pvwa ... --log-level DEBUG --output export.json --target-domains corp.com ``` - 每 10 个用户/组更新进度 - 每 5 个保险箱更新进度 - 每 25 个账户/成员/节点更新进度 - 每 100 条边更新进度 - 附加诊断信息 - 最适合故障排除或理解处理流程 #### 其他日志选项 - `--quiet` - 禁止显示大部分日志（覆盖 log-level） - `--debug` - 启用权限分析诊断 #### 示例输出（INFO 级别） ``` [2025-11-24 10:15:23] INFO cyberarkhound: Processing 500 users... [2025-11-24 10:15:24] INFO cyberarkhound: Processed 50/500 users (10.0%) [2025-11-24 10:15:25] INFO cyberarkhound: Processed 100/500 users (20.0%) ... [2025-11-24 10:15:30] INFO cyberarkhound: Processed 500/500 users (100.0%) [2025-11-24 10:15:30] INFO cyberarkhound: Processing 3000 accounts... [2025-11-24 10:15:35] INFO cyberarkhound: Processed 100/3000 accounts (3.3%) ... [2025-11-24 10:16:45] INFO cyberarkhound: === Collection Summary === [2025-11-24 10:16:45] INFO cyberarkhound: Total Nodes: 3780 [2025-11-24 10:16:45] INFO cyberarkhound: Nodes by Type: [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_User: 500 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Group: 80 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Safe: 150 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Account: 3000 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Platform: 50 [2025-11-24 10:16:45] INFO cyberarkhound: Total Internal Edges: 12350 [2025-11-24 10:16:45] INFO cyberarkhound: Internal Edges by Type: [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_MemberOf: 620 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Contains: 3000 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_HasAccessTo: 4200 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_CanGrantAccessTo: 310 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_CanApprove: 95 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_Created: 150 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_ManagedBy: 140 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_UsedAccount: 785 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_LinkedTo: 2100 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_UsesPlatform: 950 [2025-11-24 10:16:45] INFO cyberarkhound: Total External Edges: 1680 [2025-11-24 10:16:45] INFO cyberarkhound: External Edges by Type: [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_SyncsToUser: 480 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_SyncsToGroup: 60 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_SyncsToADUser: 1140 [2025-11-24 10:16:45] INFO cyberarkhound: CyberArk_PSMServerHostedOn: 4 [2025-11-24 10:16:45] INFO cyberarkhound: Memory stats: Alloc=85MB Sys=142MB NumGC=12 [2025-11-24 10:16:45] INFO cyberarkhound: Writing JSON to file: export.json [2025-11-24 10:16:45] INFO cyberarkhound: Writing compact JSON format... [2025-11-24 10:16:48] INFO cyberarkhound: Export complete! File written successfully. ``` #### 性能提示 - 对于大型环境（10K+ 对象），使用 `--log-level WARNING` 以最小化日志开销 - 仅在调查特定问题时使用 `--log-level DEBUG` - 进度更新对性能影响很小，但在非常大的环境中可能会填满日志文件 - 始终使用紧凑的 JSON 格式（不美化打印）以获得最佳写入性能 ### 开发说明 模块布局： ``` cmd/cyberarkhound/ main.go # CLI entry point / orchestration pkg/ client/ client.go # CyberArk PVWA API client models/ models.go # Data structures for API responses graph/ builder.go # OpenGraph construction pvwa_tag.go # PVWA URL tagging algorithm utils.go # Graph utilities, permission maps exporter/ exporter.go # BloodHound JSON export ``` ### 扩展 在 `pkg/graph/builder.go` 中添加新的边类型或属性映射。保持转换纯函数，避免在此处进行网络调用。对于其他导出格式，请创建一个新包（例如，`pkg/neo4j/exporter.go`）并复用现有的 OpenGraph 对象。 ### 安全说明 - 优先通过环境变量或安全的密钥存储提供凭据。 - 避免在受控测试环境之外使用 `--insecure`。 - 使用前验证自定义 CA 证书包的完整性。 ### 贡献指南 1. Fork 并创建功能分支 2. 如果引入复杂逻辑，请添加测试或最小重现脚本 3. 保持更改小而集中；如果行为发生变化，请更新 README 4. 提交 PR，说明理由和任何边界情况 ### 支持 提交问题以报告错误或增强请求。 ## 致谢 感谢 Siemens Healthineers 支持这项研究，也感谢帮助我开发的同事们。 - Julian Garcia - 感谢您对此项研究的合作，并为编码实践提供了宝贵见解。

标签：Active Directory集成, API客户端, BloodHound, Checkov, CyberArk, EVTX分析, Go语言, Homebrew安装, JSON, LDAP同步, OpenGraph, PVWA, SSL定制, 威胁建模, 安全信息与事件管理, 搜索引擎爬取, 攻击路径可视化, 攻击面分析, 数据导出, 日志审计, 权限管理, 模型越狱, 特权访问管理, 特权账户管理, 程序破解, 网络安全, 账户活动跟踪, 链分析, 隐私保护, 黑客工具