gebruder/wirken-siem

# wirken-siem 用于 Wirken audit schema 的检测内容。本仓库提供了保存的搜索、监控器、分析规则，以及一个参考 webhook 消费者，SOC 团队无需阅读上游代码即可直接接入。其版本号跟踪的是 audit schema，而不是 wirken 二进制文件。 ## 兼容性 | wirken-siem | Wirken audit schema | |-------------|---------------------| | 0.1 | 1.3.x, 1.4.x | Wirken 1.4.0 在 `LlmRequest` 和 `LlmResponse` 中增加了 `credential_id: Option`。这些变体不会被本仓库中的任何检测规则所使用，因此该字段的增加仅供参考，现有的检测内容无需修改即可继续正常工作。 ## 字段索引 检测内容从这些带有类型的 `SessionEvent` 变体以及旧版的 `AuditEvent` 结构中读取数据。在 1.3.1 版本增加了身份字段之后，下面列出的每一个变体都携带了 `agent_id` 以及一对 1.3.x 类型的 `adapter_id` / `sender_id`（如下所列）。 | 变体 | 身份字段 | 被检测项使用 | |------------------------|-------------------------------------------------------------------------|-------------------| | `AssistantToolCalls` | `agent_id`, `adapter_id?`, `sender_id?`, `calls[].{id,name,arguments}` | 1, 2, 3, 4 | | `ToolResult` | `agent_id`, `adapter_id?`, `sender_id?`, `call_id`, `tool_name`, `success`, `output` | 2 | | `HttpFetch` | `agent_id?`, `skill_name?`, `host`, `url`, `outcome`, `http_status_code?`, `bytes` | (此无；已保留) | | `AuditLegacy` | `actor_kind`, `actor_id`, `action`, `target`, `detail` | 6 | 每个类型化事件上的行元数据：`session_id`、`seq`、`ts`、`trust`、`kind`。转发器将每行封装在一个针对特定目标的信封中；有关每个目标的具体字段名称，请参见平台 README。 ## 检测摘要 | # | 标题 | 源变体 | 严重性基线 | |----|------------------------------------|--------------------------------|-------------------| | 1 | Shell 驱动的出站获取 | `AssistantToolCalls` | medium | | 2 | 子进程 fork 配对 | `AssistantToolCalls` + `ToolResult` | low (info) | | 3 | 通过 `write_file` 写入二进制文件 | `AssistantToolCalls` | high | | 4 | 执行位于 Skill 目录中的二进制文件 | `AssistantToolCalls` | high | | 6 | 链篡改关联 | `AuditLegacy` (`audit.chain_broken`) | high; 当告警日志缺失时为 critical | 有意省略了检测项 5。它最初用于跟踪不可达的 `Action::SkillInstall` Tier 3 变体；该变体在 Wirken 1.4.0 中已被移除，因为安装 CLI 是由操作员输入的，并受注册表锚定的签名验证所控制，而非依赖层级分类。运行时检测没有任何可以触发的依据；安装姿态是在 wirken 端的签名验证边界处捕获的。 ## 布局 - `splunk/` 保存的搜索、宏、事件类型；通过 HEC `sourcetype=wirken:audit`（旧版）和 `sourcetype=wirken:session`（类型化）进行摄取。 - `datadog/` 监控器 JSON 和仪表板 JSON；通过 Datadog Log Intake 在 `@ddsource:wirken` 下进行摄取。 - `sentinel/` 分析规则 YAML 和工作簿 JSON；通过 DCR 流 `Custom-WirkenAudit_CL` 和 `Custom-WirkenSession_CL` 进行摄取。 - `webhook/` 参考 Python 消费者，用于验证基于原始 POST 主体的 `X-Wirken-Signature` HMAC，然后在进程内运行这五条规则。 ## 操作说明 ### Tier 3 拒绝但检测 检测项 1（shell 出站获取）和 4（位于 Skill 目录中的二进制执行）会在 Wirken 的运行时权限层级判定之前，于 `AssistantToolCalls` 上触发。检测内容捕捉的是模型的尝试意图；该操作随后是否实际运行取决于通道： - **没有人工审批循环的通道**（`webchat`、`cron`、无人值守子代理）：Tier 3 动词会自动拒绝。配对的 `ToolResult` 会带有 `success: false`，且模型的请求不会被执行。检测依然会触发，因为这两条规则的源变体是 `AssistantToolCalls`，它记录了在调用瞬间模型的意图。 - **带有人工审批循环的通道**（Telegram、Signal、Slack、Discord 及其他与适配器绑定的通道）：系统会提示操作员批准或拒绝该工具调用。无论哪种情况检测都会触发；配对的 `ToolResult` 是否指示成功取决于操作员的决策。 这是正确的形态：检测是对 LLM 行为的记录。而层级控制是 wirken 的强制执行机制。将它们视为相同的信号会混淆“模型尝试做了 X”和“X 已经发生”这两个概念，而 SOC 团队需要同时掌握这两种信息。 参考：来自 Wirken 1.4.0 版本发布验证的冒烟测试发现。 ## 本仓库不是什么 - 不是一个 Splunk 应用程序、Datadog Terraform 模块，或 Sentinel 解决方案包。优先提供基础内容；当操作员大规模采用这些内容时，再考虑进行打包。 - 不是一个文档站点。上面的字段索引是唯一的文字说明；其余全是规则。 - 不是 audit schema 的参考文档。相关内容位于 `wirken/docs/audit-schema.md`（即将推出）。

标签：AMSI绕过, API安全, DLL 劫持, JSON输出, LLM, Python, Unmanaged PE, Webhook, 云计算, 力导向图, 大语言模型, 威胁检测, 安全运营, 异常检测, 扫描框架, 无后门, 无线安全, 规则引擎, 逆向工具