Pirmakhanov/home-soc-lab

# 🛡️ 家庭 SOC 实验室 — Wazuh + Sysmon + MITRE ATT&CK 🌐 **语言:** **English** | [Русский](README.ru.md) [](https://wazuh.com/) [](https://learn.microsoft.com/sysinternals/downloads/sysmon) [](https://attack.mitre.org/) 一个记录我首次动手搭建小型 SOC 实验室并通过其检测 Windows 攻击技术的学习项目。在大学学习期间历时约 2 周端到端完成构建。 ## 📋 项目简介 我是一名信息安全专业的应届毕业生，正在寻找 SOC 实习生或初级职位。我注意到我的大部分课程都是理论性的，所以我决定建立这个实验室以获得实践经验： - 部署开源 SIEM (Wazuh) - 通过 Sysmon 收集端点遥测数据 - 生成真实的 Windows 攻击事件并观察它们在 SIEM 中的样貌 - 像 L1 分析师一样阅读和分类 SIEM 告警 这**不是**一个生产级别的设置——它是一个学习产物。下面我记录了我构建了什么，学到了什么，以及下次我会怎么做。 ## 📂 仓库结构 ``` home-soc-lab/ ├── README.md — English project report ├── README.ru.md — Russian version ├── LICENSE — MIT License └── images/ — Screenshots from Wazuh, Sysmon, and alert triage ``` ## 🏗️ 架构 ``` ┌─────────────────────────────────┐ ┌─────────────────────────────────┐ │ WIN11-VICTIM (192.168.100.36) │ │ WAZUH-SERVER (192.168.100.83) │ │ Windows 11 Enterprise Eval │ │ Amazon Linux 2023 │ │ │ │ │ │ ┌───────────────────────────┐ │ │ ┌───────────────────────────┐ │ │ │ Sysmon (sysmon-modular) │ │ │ │ Wazuh Manager │ │ │ │ • Process Create (EID 1) │ │ port 1514/TCP │ │ • Decoders + Rules │ │ │ │ • File Create (EID 11) │──┼─── (AES) ───────►│ │ • Alert Engine │ │ │ │ • Registry Set (EID 13) │ │ │ └────────────┬──────────────┘ │ │ └─────────────┬─────────────┘ │ │ │ │ │ │ │ │ ┌────────────▼──────────────┐ │ │ ┌─────────────▼─────────────┐ │ │ │ Wazuh Indexer │ │ │ │ Wazuh Agent v4.14.5 │ │ │ │ (OpenSearch fork) │ │ │ └───────────────────────────┘ │ │ └────────────┬──────────────┘ │ │ │ │ ┌────────────▼──────────────┐ │ │ ⚔️ Manual MITRE technique │ │ │ Wazuh Dashboard │ │ │ simulation via PowerShell │ │ │ (web UI) │ │ │ │ │ └───────────────────────────┘ │ └─────────────────────────────────┘ └─────────────────────────────────┘ Both VMs running in VirtualBox 7 on a single laptop (16 GB RAM, AMD Ryzen 7). ``` ## 🔧 技术栈 | 组件 | 版本 | 角色 | |-----------|---------|------| | Wazuh | 4.14.5 | 开源 SIEM/XDR | | Sysmon | 15.20 | 扩展 Windows 事件日志记录 | | sysmon-modular | 最新版 | Sysmon 的 MITRE 对齐配置 (由 Olaf Hartong 提供) | | VirtualBox | 7.x | Hypervisor | | Windows 11 Enterprise Evaluation | 25H2 (Build 26200.6584) | 受害者端点 (90 天试用版) | | PowerShell | 5.1 | 攻击模拟脚本 | ## 🚀 构建内容 ### 1. Wazuh 服务器 - 将预构建的 Wazuh OVA 导入到 VirtualBox - 4 GB RAM，2 个 vCPU，桥接网络 - 使用默认实验室凭据通过 `https://` 访问了仪表板（在任何非实验室部署中必须轮换凭据） ### 2. Windows 11 受害者虚拟机 - 手动安装 Win11 Enterprise Evaluation（无人值守安装卡住了——不得不重试） - 4 GB RAM，2 个 vCPU，启用 EFI - 禁用了 Defender 实时保护（仅在实验室环境中，事先通过 Windows 安全中心 GUI 禁用篡改保护后进行） - 在任何修改之前拍摄了 VirtualBox 快照——它后来救了我 ### 3. Sysmon - 从 Sysinternals 下载，应用了 [sysmon-modular](https://github.com/olafhartong/sysmon-modular) 配置 - 通过 `Sysmon64.exe -accepteula -i sysmonconfig.xml` 安装 ### 4. Wazuh Agent + 关键配置步骤 - 通过仪表板的“部署新 Agent”向导进行安装 - **我最初忽略的重要细节：** 默认的 Agent 配置没有订阅 Sysmon 通道。因此 Agent 虽然连接上了，但没有 Sysmon 事件流入 SIEM。 - 通过在 `C:\Program Files (x86)\ossec-agent\ossec.conf` 中添加以下内容修复： ``` Microsoft-Windows-Sysmon/Operational eventchannel ``` 在重启 Agent (`Restart-Service -Name Wazuh`) 后，Sysmon 事件开始出现在仪表板中。 ## ⚔️ 攻击场景 我在受害者机器上手动执行了 7 种基于 PowerShell 的攻击技术。我原本计划使用 Atomic Red Team，但从我所在地区下载 GitHub 文件的速度被限制在约 23 KB/s——因此我改为手动执行每项技术。这实际上变得更具教育意义，因为我现在了解了每个命令的作用。 | # | MITRE ID | 技术 | 战术 | |---|----------|-----------|--------| | 1 | T1059.001 | PowerShell — 凭据文件搜索 | Execution | | 2 | T1059.003 | Windows cmd 侦察 (whoami, net user, systeminfo) | Execution / Discovery | | 3 | T1218.011 | Rundll32 (LOLBin) | Defense Evasion | | 4 | T1547.001 | 注册表 Run 键持久化 | Persistence | | 5 | T1543.003 | Windows 服务创建 | Persistence | | 6 | T1003.001 | LSASS 进程访问 | Credential Access | | 7 | T1027 | 编码的 PowerShell (base64) | Defense Evasion | ## 🔍 Wazuh 捕获到的内容 在 Threat Hunting 中使用过滤器 `agent.name: Win11-Victim`（攻击执行后的 30 分钟窗口），Wazuh 显示了 **49 个 MITRE 标记的告警**以及许多额外的 Sysmon 事件。在 MITRE 矩阵中亮起的战术包括： - Execution - Persistence - Privilege Escalation - Defense Evasion - Credential Access - Command and Control **严重级别分布：** - Level 15 (Critical)：1 个告警 - Level 12 (High)：3 个告警 - Level 5–10：5 个告警 - Level 3–4：40+ 个告警  *MITRE ATT&CK 仪表板——在模拟 7 次攻击后，6 种战术亮起。显示了告警分布及其发生的时间线。*  *Threat Hunting 视图——在使用过滤器 `agent.name: Win11-Victim` 的 30 分钟窗口内有 58 个告警。可见的具体规则：编码的 PowerShell (Level 12)、文件释放 (Level 15)、服务创建 (Level 5)、发现活动 (Level 3)。*  *Wazuh 端点概览——Agent Win11-Victim 处于 Active 状态，版本 4.14.5。* ## 🎯 我分析的两个告警 这个项目最有用的部分是练习告警分类。有两个告警作为截然相反的案例脱颖而出。 ### 告警 1 — 真阳性：编码的 PowerShell (T1059.001) **规则 92057，Level 12** — *"Powershell.exe spawned a powershell process which executed a base64 encoded command"*  *Level 12 告警的展开 JSON。可见关键字段：带有 `-EncodedCommand` 标志和 base64 代码块的 `commandLine`，`integrityLevel: High`，`user: socadmin`，`parentProcessGuid`（父进程也是 PowerShell），带有用于 TI 源查询的 SHA256 的 `hashes`。* 梳理 JSON： - 用户：`WIN11-VICTIM\socadmin`，integrityLevel **High**，交互式会话 - 父进程也是 `powershell.exe`（链式启动，典型的混淆指标） - 命令行带有 `-EncodedCommand` 标志和一个 base64 代码块 - 解码了 base64（PowerShell 使用 **UTF-16 Little Endian**，而不是 UTF-8——很容易弄错）：`$s="hello from SOC-lab";Write-Host $s` 在我们的实验室中，载荷是无害的，但**其模式本身**（base64 + 链式启动 + 管理员权限）正是真实攻击者的行为。因此我将其标记为真阳性并写了分类记录。 ### 告警 2 — 假阳性：在 Temp 中创建文件 (T1105) **规则 92213，Level 15** — *"Executable file dropped in folder commonly used by malware"*  *Level 15 告警的展开 JSON。关键字段——值为 `__PSScriptPolicyTest_szs4ioxw.j3i.ps1` 的 `targetFilename`。注意：`processGuid` 与上方 Level 12 告警的 `ProcessGuid` 相匹配——这意味着该文件是由同一个 PowerShell 进程在启动 1 秒后创建的。* Level 15 听起来很吓人，但梳理 JSON： - 创建的文件：位于 `AppData\Local\Temp\` 中的 `__PSScriptPolicyTest_szs4ioxw.j3i.ps1` - 与编码的 PowerShell 具有相同的 `ProcessGuid`——所以是**同一个进程**在 1 秒后创建的文件 - 文件名 `__PSScriptPolicyTest_*` 是 PowerShell 自身用于 ExecutionPolicy 验证的已记录的内部机制 所以这个 Level 15 原来是一个**假阳性**——合法的 Windows 行为。主要的经验教训：严重级别并不等于真实的严重程度。你必须先阅读数据，然后再做出反应。 在生产环境中抑制此假阳性的一条简单规则调优如下所示： ``` 92213 __PSScriptPolicyTest_ FP suppression: PowerShell ExecutionPolicy test file ``` ## 🧱 我遇到的真实挑战 如实列出它们——这是让我学到最多的地方： - **Wazuh OVA 无法在启用 Secure Boot 的情况下启动**——必须在虚拟机设置中将其禁用 - **VirtualBox 中的无人值守 Win11 安装在升级对话框处卡住**——重新创建了虚拟机并手动安装 - **Atomic Red Team 下载被 GitHub 限速**（约 23 KB/s）——不得不转为手动执行技术，这反而促使我理解了每个命令 - **Defender Tamper Protection 阻止了从 PowerShell 执行 `Set-MpPreference`**——必须先通过 Windows 安全中心 GUI 禁用篡改保护，然后才能禁用实时保护 - **尽管 Agent 状态为 Active，但 Sysmon 事件未能到达 Wazuh**——原来是默认的 Agent 配置没有订阅 Sysmon 通道；需要将 `Microsoft-Windows-Sysmon/Operational` 的 `` 添加到 `ossec.conf` 中 - **会话之间网络发生变化**（家庭 Wi-Fi → 手机热点 → 家庭 Wi-Fi）——IP 发生了偏移，不得不重新检查连接性。今后我将在 VirtualBox 中使用 NAT Network 以摆脱对物理网络的依赖 - **主机 RAM 紧张**——16 GB 内存运行两个 4 GB 的虚拟机外加浏览器很不稳定；在每次会话前不得不关闭后台应用程序（Discord、Steam 等） ## 📈 我从这个项目中获得的收益 亲身实践并熟悉了： - Wazuh 仪表板导航、Agent 注册、基本配置 - Sysmon 安装及应用第三方 MITRE 对齐配置 - 在 SIEM 告警中阅读原始 Sysmon Event ID (1, 11, 13) - 阅读和解码 `-EncodedCommand` PowerShell 载荷 - 6 步告警分类工作流（阅读 → 上下文 → 重构 → 解码 → 分类 → 行动） - 根据上下文而非严重级别区分真阳性和假阳性 - 通过 `ProcessGuid` 跨进程关联事件 我**并不是**声称自己是其中任何一项的专家——只是我在这个实验室的实践中使用了它们。 ## 📚 经验教训 1. **严重性 ≠ 真实世界的影响。** 我调查的 Level 15 告警原来是一个假阳性（合法的 Windows 行为）。而 Level 12 才是真实的攻击模式。在做出反应之前务必进行调查。 2. **默认的工具配置往往是不够的。** 除非你告诉 Wazuh Agent 要读取哪些通道，否则它会很乐意在没有 Sysmon 可见性的情况下运行数小时。阅读文档是有回报的。 3. **`ProcessGuid` 用于关联比 `ProcessId` 更可靠。** 操作系统 PID 可以被重用；ProcessGuid 永远是唯一的。 4. **提前规划资源限制。** 一台 16 GB 内存的笔记本电脑可以运行两个虚拟机，但前提是保持主机干净。后台应用程序的累积非常快。 ## 🚧 我想采取的下一步行动 - 在 `local_rules.xml` 中编写一些我自己的自定义检测规则（到目前为止我只使用了捆绑的规则） - 添加一个 Linux 端点以比较跨平台检测 - 尝试集成 Active Directory + Domain Controller 以进行凭据盗窃场景模拟 ## 📖 参考 - [Wazuh 文档](https://documentation.wazuh.com/) - [Sysmon (Microsoft Sysinternals)](https://learn.microsoft.com/sysinternals/downloads/sysmon) - [sysmon-modular 作者 Olaf Hartong](https://github.com/olafhartong/sysmon-modular) - [MITRE ATT&CK 框架](https://attack.mitre.org/) ## 👤 关于我 **Erlan Pirmakhanov** — Satbayev University (阿拉木图，哈萨克斯坦) 信息安全专业应届毕业生，GPA 3.68 / 4.0。寻求 SOC 实习生或初级分析师职位。 这是我第一个端到端的实用安全项目。在此过程中，我官方文档和在线文章。还有很多我尚未涵盖的内容（自定义规则编写、真实的 Threat Hunting 查询、AD 集成）。很乐意在面试时更详细地讨论本 README 的任何部分。 📧 [pirmakhanoverlan@gmail.com](mailto:pirmakhanoverlan@gmail.com) 📄 [个人简历](https://hh.kz/resume/06a9299fff10757f930039ed1f79525a396257)

标签：AI合规, AMSI绕过, Cloudflare, Conpot, IP 地址批量处理, L1分析师, meg, MITRE ATT&CK, OPA, SOC实验室, Sysmon, Wazuh, Windows 11, Windows安全, 信息安全, 初学者项目, 威胁检测, 安全事件监控, 安全实训, 安全运营中心, 家庭实验室, 攻击模拟, 端点遥测, 网络安全, 网络安全审计, 网络映射, 隐私保护, 靶场, 驱动签名利用