Dkeyo/EventLogTriage
GitHub: Dkeyo/EventLogTriage
基于本地 LLM 和 MITRE 白名单验证的 PowerShell 工具包，用于在 Active Directory 实验环境中对 Windows Sysmon 事件进行自动化分诊，解决本地小模型产生虚假 ATT&CK 技术 ID 的问题。
Stars: 0 | Forks: 0
# EventLogTriage
用于 AI 辅助分诊 Windows Sysmon 事件的 PowerShell 工具包：收集 endpoint 遥测数据，使用本地 LLM 对其进行分类，并根据白名单验证每个 MITRE ATT&CK 声明，因为本地模型会产生幻觉并编造技术 ID。
在自建的 Active Directory 实验环境（Hyper-V、Windows Server 2019 DC + Windows 11 endpoint）中构建并测试。
## 为什么开发此工具
SOC L1 分析师将大部分时间耗费在重复的事件分诊上。本地 LLM（8B-14B）速度足够快且具有足够的私密性来提供帮助，但不能盲目信任它们。在对真实 Sysmon 事件进行模型评估期间，我观察到了两种不同的失败模式：
| 模型 | 失败模式 | 示例 |
|---|---|---|
| Llama 3.1 8B | **捏造** MITRE 技术 ID | 返回了不存在的 `T1160` |
| Bielik 11B v2.3 | **错误应用**真实 ID | 返回了有效的 ID（`T1059`、`T1105`），但将其归因于错误的行为 |
这一观察结果驱动了核心设计：模型输出的每个 MITRE ID 都会根据精心整理的白名单（[Data/valid-mitre-techniques.json](Data/valid-mitre-techniques.json)，37 项技术，ATT&CK v16）进行验证，并且模型被限制为只能从该列表中进行选择，而不是自由生成。
## 架构
```
flowchart LR
subgraph Lab["Hyper-V lab (isolated switch, domain renoma.pl)"]
DC["DC01\nWindows Server 2019 DC\n172.16.0.10"]
EP["WIN11-EP01\nWindows 11 endpoint\nSysmon (SwiftOnSecurity config)\n172.16.0.20"]
DC --- EP
end
subgraph Workstation["SOC-WKS01 (analyst workstation, workgroup)"]
MOD["EventLogTriage\nPowerShell module"]
LLM["Ollama (local LLM)\nLlama 3.1 / Bielik / Qwen"]
VAL["MITRE validation layer\n37-technique allowlist"]
end
EP -- "WinRM\n(explicit credentials)" --> MOD
MOD -- "formatted event" --> LLM
LLM -- "classification" --> VAL
VAL -- "validated verdict" --> ANALYST["Human analyst\n(final decision)"]
```
Pipeline：Sysmon → PowerShell 收集 → 本地 LLM 分类 → MITRE 验证 → 人工干预。
## 状态
阶段 1（数据收集层）已完成。
| 组件 | 状态 |
|---|---|
| `Get-RecentSysmonEvents`：本地 + 远程（WinRM）Sysmon 收集，标准化输出 | ✅ 完成 |
| `Test-WinRMConnection`：三态 WinRM 诊断（`Healthy` / `Inconclusive` / `Failed`） | ✅ 完成 |
| MITRE ATT&CK 白名单（37 项技术，机器可读的验证状态） | ✅ 完成 |
| Pester v5 测试套件（模拟了 `Get-WinEvent`、`Invoke-Command`、`Test-WSMan`） | ✅ 完成 |
| `Invoke-EventClassification`：带有约束选择 prompt 和白名单验证的 LLM 调用 | 🔨 进行中 |
| `Format-EventForLLM`：事件到 prompt 的转换 | 🔨 进行中 |
| 端到端 pipeline（`Invoke-EventTriage`） | 📋 计划中 |
已知的低优先级事项记录在 [FUTURE_WORK.md](FUTURE_WORK.md) 中。
## 用法
```
Import-Module .\EventLogTriage.psd1
# 本地计算机过去一小时内的关键 Sysmon 事件
Get-RecentSysmonEvents -Verbose
# 从 domain endpoint 进行远程收集（workgroup -> domain 需要显式凭据）
$cred = Get-Credential renoma\Administrator
Get-RecentSysmonEvents -ComputerName WIN11-EP01 -Credential $cred -HoursBack 4 -MaxEvents 200
# WinRM 不工作？诊断它。返回具体的修复命令。
Test-WinRMConnection -ComputerName WIN11-EP01 -Credential $cred
```
默认收集涵盖 Sysmon 事件 ID `1, 3, 7, 10, 11, 22`（ProcessCreate、NetworkConnect、ImageLoad、ProcessAccess、FileCreate、DnsQuery）。这些是根据 SwiftOnSecurity 的配置理念具有最高检测价值的事件。
## 关键设计决策
1. **MITRE ID 的白名单验证。** 存在性检查可捕获捏造的 ID；每个 ID 旁边存储的规范技术名称允许根据技术的实际含义对模型的推理进行健全性检查。永远不要盲目信任模型的 MITRE 字段。
2. **约束选择优于自由生成。** 系统 prompt 为模型提供了有效技术 ID 的固定列表；它是在进行选择，而不是发明创造。
3. **本地 LLM 优于云 API。** 事件日志包含主机名、用户名和文件路径。这些数据不应离开 SOC。Ollama 将所有内容保留在本地且可离线工作。
4. **三态 WinRM 诊断。** 匿名 WSMan `Identify` 成功*并不能*证明经过身份验证的远程控制就能正常工作。除非真正执行了凭据握手，否则 `Test-WinRMConnection` 拒绝报告 `Healthy` 状态。误报绿灯正是诊断工具决不能出现的 Bug。
5. **默认只读，操作需人工干预。** 工具负责收集和分类；任何改变状态的操作都必须由人工批准。
## 测试
```
Invoke-Pester -Path .\Tests
```
所有外部边界（`Get-WinEvent`、`Invoke-Command`、`Test-WSMan`、`Test-NetConnection`）均被模拟，因此该套件可以在任何没有实验环境的机器上运行。
## 实验环境
| 主机 | 角色 |
|---|---|
| SOC-WKS01 | 分析师工作站（工作组）；i5-12400F，RTX 3060 12GB，32GB RAM |
| DC01 | Windows Server 2019，`renoma.pl` 的域控制器 |
| WIN11-EP01 | Windows 11 endpoint，加入域，Sysmon 采用 SwiftOnSecurity 配置 |
工作组到域的划分是故意的：它强制要求进行真实跨边界 SOC 部署所需的显式凭据和 TrustedHosts 处理。
## 可能的扩展
Wazuh SIEM 集成、多模型投票、MCP 服务器接口。不在当前阶段的范围内。
标签：Active Directory, AI合规, AI风险缓解, Cloudflare, DLL 劫持, IPv6, Libemu, MITRE ATT&CK, Plaso, PowerShell, Sysmon, 大语言模型, 安全运营, 扫描框架, 本地大模型