arjunarju123/Security-Operations-SOC---Enterprise-EDR-Threat-Hunting-Grid

# 🛡 安全运营中心 (SOC) —— 企业级 EDR 与威胁狩猎矩阵 ## 📌 项目概述 本项目展示了一个多平台安全运营中心 (SOC) 实验环境的设计与实施，该环境集成了与 MITRE ATT&CK 对齐的检测、响应、漏洞管理和对手模拟功能。 ## 🏗 实验架构 ``` Component Role -------------- --------------- Kali Linux Wazuh Manager Windows 11(zzz) Wazuh Agent Ubuntu server Wazuh Agent ``` ## 所有系统均配置为 **桥接网络模式** 以模拟真实的企业网络。确保 Agent 通过 TCP 1514 端口与 Manager 通信。 ## 📅 第 1 周 —— 基础设施与 Agent 部署 ### 🔧 使用的技术 - Wazuh (SIEM & EDR) - Sysmon (Windows 高级监控) - Hydra (暴力破解模拟) - Kali Linux - Ubuntu - Windows 11 (zzz) ### 🔎 可见性设置 - 在两个 Agent 上启用了系统日志监控。 - 验证了来自 Linux 和 Windows 的日志采集。 - 确认了 Agent 和 Manager 之间的心跳通信。 ## 🚪 关卡检查 ✔ 所有 Agent 在 Wazuh Dashboard 中显示“Active”状态。\ ✔ 心跳信号稳定。\ ✔ 初始日志已成功收集并索引。  ⚙ 配置 Sysmon 安装命令： $ Sysmon64.exe -accepteula -i sysmonconfig.xml Wazuh Agent 配置更新： C:\Program Files (x86)\ossec-agent\ossec.conf ``` Microsoft-Windows-Sysmon/Operational eventchannel ``` 配置后重启了 Wazuh Agent 服务。  ### Sysmon 检测结果 集成后，生成并验证了多个高保真度的安全警报。 🔍 观察到的检测 whoami.exe 的可疑执行 释放到 Windows 根目录的可执行文件 异常的命令提示符父进程 PowerShell 执行监控 应用程序兼容性数据库活动 多个警报在 Level 12（高严重性）触发。 这证实了： 规则解码正确 命令行可见性 父子进程追踪 可疑行为检测  ✅ 第 1 周状态：已完成 # 📅 第 2 周 —— 检测规则 (逻辑) ## 🔍 文件完整性监控 (FIM) - 监控关键目录 (/etc) - 检测未经授权的修改 - 生成实时警报 配置了 FIM (syscheck) 以实时监控敏感目录。 配置包括： - check_all="yes" - realtime="yes" ## 🐧 Ubuntu FIM 测试 ### 执行的测试 - 在受监控目录中创建了一个测试脚本文件。 - 手动修改了该文件。 - 观察到了实时警报生成。 文件位置： /var/ossec/etc/ossec.conf 在 部分中，添加了以下配置： ``` /etc/passwd /etc/shadow /etc/group /etc /usr/bin /bin ``` 更新配置后： sudo systemctl restart wazuh-agent  ### 结果 使用的测试命令： sudo nano /etc/passwd 结果： - 触发了文件修改警报 - 完整性校验和已更改 - 确认实时检测  ## 在 Dashboard 中查看 FIM 警报 导航至： Wazuh → Security Events 搜索过滤器： rule.groups:syscheck 或 Dashboard → Modules → Integrity Monitering ## 🪟 Windows FIM 测试 ### 执行的测试 - 在 Windows 系统上创建/修改了受监控的文件。 - 在 Wazuh Dashboard 中观察到了警报。 配置目录：C:\Program Files (x86)\ossec-agent\ossec.conf C:\Windows\System32\drivers\etc  ### 结果 - 成功触发了实时文件修改警报。  ## 🚨 漏洞检测 此任务的目标是配置 Wazuh Vulnerability Detector，以识别受监控系统中已安装软件包的已知漏洞。 启用了 Vulnerability Detector 模块。 ``` no --> yes ``` Windows 和 Ubuntu Provider 应用了相同的配置更改。  手动安装了易受攻击的 Apache2 版本以验证检测能力。 检测到漏洞并发出警报。   ### 实现的能力 - 检测已安装的易受攻击软件包 - 将软件版本映射到 CVE 数据库 - 显示： - CVE ID - 严重性级别 - 受影响的软件包 - 修复版本 ## 🚪 关卡检查 ✔ 在受监控的 FIM 目录中手动修改了文件。\ ✔ 数秒内 Dashboard 中出现高严重性警报。\ ✔ Vulnerability Detector 成功启用。\ ✅ 第 2 周状态：已完成 ## 第 3 周 – 主动响应 (入侵防御系统) # 🎯 目标 使用 Wazuh 配置并验证入侵防御系统 (IPS)。目标是检测 SSH 暴力破解攻击，并自动在目标主机 (ubuntu_22) 上触发防火墙拦截，以实时缓解威胁。 # 🔍 配置详情 主动响应在 Wazuh Manager 的 /var/ossec/etc/ossec.conf 文件中配置。  # ⚙ 主动响应设置 定义了以下参数以确保 Manager 命令 Agent 丢弃恶意流量： Command: firewall-drop (利用主机的本地防火墙拦截 IP)。 Location: local (在生成警报的特定 Agent 上执行响应)。 Timeout: 600 秒 (IP 在 10 分钟后自动解封)。 目标规则 ID 为了有效捕获暴力破解攻击，监控了以下规则： 5760: SSHD 认证失败。 5763: SSHD 暴力破解攻击检测。 5758: 超过最大认证尝试次数。 40111: 多次认证失败 (触发规则)。 2502: Syslog: 用户多次密码输入错误。 # 🧪 攻击模拟与验证 使用 Hydra 针对 Ubuntu SSH 服务模拟了 SSH 暴力破解攻击。 $ hydra -l root -P passwords.txt ssh://agent-ip  当使用 Hydra 执行暴力破解攻击时， 短时间内生成了多次 SSH 认证失败尝试。 /var/log/auth.log 中出现了重复的“authentication failed”条目。 超过阈值后，主动响应模块自动执行。 攻击者的 IP 被插入到 iptables DROP 规则中。 ## 🚪 关卡检查 目标主机上的手动验证 为了确认 IPS 在系统层面生效，在 ubuntu_22 Agent 上执行了以下检查： A. 主动响应日志 通过检查 Agent 的本地日志验证脚本是否成功执行： $ tail -n 5 /var/ossec/logs/active-responses.log  结果：日志确认使用 add 参数为攻击者 IP 调用了 firewall-drop.sh 脚本。 B. 防火墙规则 验证 IP 是否已添加到内核路由表： $ sudo iptables -L -n  结果：确认 INPUT 链中存在针对攻击者源 IP 的 DROP 规则。 输出： DROP all -- 10.41.55.89 0.0.0.0/0 C. 在 Wazuh Dashboard 中观察到的 SSH 暴力破解警报 记录的主动响应事件： “Host Blocked by firewall-drop Active Response”  ## 📊 安全影响 恶意 IP 在触发 Level 10 规则后数秒内被拦截，展示了实时自动化的入侵防御能力。 架构流程： Hydra 攻击 → SSH 日志 → Wazuh 规则 5763 触发 → 主动响应 → firewall-drop.sh → iptables DROP 规则应用 # 🧠 故障排除与经验教训 XML 格式：最初，配置被放置在 XML 注释标签 (``) 内，导致被 Manager 忽略。移除这些标签并重启 wazuh-manager 服务解决了该问题。 更高级别的规则 (例如 Level 10) 是 IPS 行为的有效触发器 Wazuh 可以作为自动化的入侵防御系统 (IPS) 运行 准确的规则选择对于正确的响应执行至关重要 # 🚀 结果 成功使用 Wazuh 主动响应实现了自动化 SSH 暴力破解缓解。 第 3 周：✅ 已完成 # 📘 第 4 周 – 威胁模拟与 MITRE 可视化 🔥 使用 AtomicRedTeam 进行勒索软件攻击模拟 ## 🎯 目标 使用 AtomicRedTeam 框架模拟常见的勒索软件行为，并在 SOC 实验室中验证检测。 模拟技术： T1490 – 抑制系统恢复 删除 Windows 卷影副本 Wazuh 中的检测验证 OpenSearch 中的 MITRE ATT&CK 映射与可视化 🏗️ 实验环境 🛡 Wazuh Manager – Kali Linux 🖥 Windows Server 2016 – 受监控端点 📊 Wazuh Dashboard 🔎 OpenSearch (MITRE ATT&CK 模块) 📡 Sysmon 已启用 📜 Event ID 4688 (进程创建) 已启用 ## 🔧 AtomicRedTeam 安装过程 步骤 1 – 绕过执行策略 PowerShell 默认阻止未签名脚本。 为当前用户更改了执行策略： Powershell $ Set-ExecutionPolicy Bypass CurrentUser 确认 Y 继续。 步骤 2 – 启用 TLS 1.2 修复了 SSL/TLS 安全通道错误 (如有需要)： $ [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 步骤 3 – 通过 GitHub 脚本安装 Atomic Red Team $ IEX(IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); 步骤 4 – 下载 Atomics $ Install-AtomicRedTeam -getAtomics -Force 验证文件夹是否存在： $ cd C:/AtomicRedTeam $ dir atomics 存储于： C:\AtomicRedTeam\atomics  ## ⚙ 自定义配置 1️⃣ Windows Agent – Sysmon 日志收集 文件： C:\Program Files (x86)\ossec-agent\ossec.conf 添加内容： ``` Microsoft-Windows-Sysmon/Operational eventchannel Security eventchannel ```  启用 Windows 审核策略 $ auditpol /set /subcategory:"Process Creation" /success:enable $ gpupdate /force 检查 gpedit.msc → 计算机配置 → 管理模板 → 系统 → 审核进程创建 → 在进程创建事件中包含命令行 = 已启用 🛡 自定义 Wazuh 检测规则  文件： /var/ossec/etc/rules/local_rules.xml ``` sysmon_eid1_detections vssadmin.exe delete shadows Shadow Copy Deletion Attempt (Possible Ransomware Behavior) T1490 ``` 重启 Wazuh： $ sudo systemctl restart wazuh-manager ## 🧪 攻击模拟 MITRE 技术： T1490 – 抑制系统恢复 执行的攻击命令： $ Invoke-AtomicTest T1490 -ShowDetails  或 手动触发 $ vssadmin.exe delete shadows /all /quiet 如果显示没有文件 - 则创建一个 $ wmic shadowcopy call create Volume='C:\' 再次触发 $ Invoke-AtomicTest T1490 -TestNumbers 1 -PathToAtomicsFolder 'C:\AtomicRedTeam\atomics'  ## 目的： 勒索软件家族通常删除卷影副本以： 阻止系统还原 增加运营影响 禁用备份恢复选项 ## 🔍 检测工作流 在 Windows Server 上执行攻击命令 Sysmon 生成 Event ID 1 (进程创建) 事件转发至 Wazuh Manager 触发自定义规则 警报索引至 OpenSearch 应用 MITRE 映射 Dashboard 收到警报  wazuh -> Module -> MITRE ATT&CK ## 📊 检测结果 执行攻击后： | Field | Value | |-------------|---------------------------| | Agent | windows_s16 | | Rule ID | 100200 | | Level | 12 (High) | | MITRE ID | T1490 | | Tactic | Impact | | Technique | Inhibit System Recovery | # ✅ 关卡检查 – 已完成 ✔ 勒索软件技术已模拟 ✔ 警报已生成 ✔ MITRE ATT&CK 映射已确认 ✔ Kill Chain 序列已可视化 ✔ 检测在 OpenSearch Dashboard 中可见 ## 🎓 展示的技能 使用 Atomic Red Team 进行威胁模拟 Windows 审核配置 Sysmon 事件分析 Wazuh 规则开发 MITRE ATT&CK 映射 OpenSearch 可视化 SOC 检测验证工作流 ## 面临的挑战 ⚠ 1. SSL/TLS 安全通道错误 问题： 从 GitHub 下载 Atomic Red Team 时 无法创建 SSL/TLS 安全通道 根本原因： 较旧的 Windows Server 版本默认不启用 TLS 1.2。 应用的解决方案： 启用 TLS 1.2解决从 GitHub 下载 Atomic Red Team 时的安全通道错误 ✔ 成功解决了 GitHub 下载问题。 2. 初始 MITRE ATT&CK 未映射 问题： 执行 T1490 (卷影副本删除) 攻击模拟后，警报最初未出现在 Wazuh Dashboard 中。 而不是： T1490 (Inhibit System Recovery) 根本原因 默认的 Wazuh 规则不包含针对与 T1490 技术相关的 vssadmin delete shadows 命令的特定检测规则。 解决方案： 我分析了系统事件日志以确认活动。 然后我创建了一个专门匹配以下内容的自定义 Wazuh 检测规则： vssadmin.exe delete shadows 该规则明确映射到 MITRE ATT&CK 技术 T1490 – Inhibit System Recovery。 重启 Wazuh Manager 重新运行模拟 警报在 Wazuh Dashboard 中成功生成，并正确映射到 MITRE ATT&CK Impact 战术 (T1490)。 ✔ 规则实施后检测正常工作 3. 理解卷影副本删除的前置条件 问题： T1490 测试需要现有的卷影副本。 如果不存在卷影副本，命令可能会返回： No items found that satisfy the query. 解决方案： 在执行攻击前手动创建卷影副本 ✔ 确保了逼真的勒索软件模拟。 ### 🏁 最终结论 该 SOC 实验室成功展示了与 MITRE ATT&CK 对齐的企业级检测工程、自动化响应、漏洞管理和勒索软件行为模拟。该环境复制了现实世界的 SOC 工作流，包括监控、检测、缓解和可视化。 ## 第 4 周：✅ 已完成 # 📌 展示的关键能力 - SIEM 部署与配置 (Wazuh) - 端点监控 (Sysmon) - 文件完整性监控 (FIM) - 漏洞管理 - 主动响应与 IPS - 威胁模拟 (Atomic Red Team) - MITRE ATT&CK 映射 - 检测工程

标签：AMSI绕过, Cloudflare, EDR, GPT, MITRE ATT&CK, Sysmon, TGT, Wazuh, x64dbg, 企业安全, 威胁检测, 安全实验室, 安全运营中心, 攻防演练, 漏洞管理, 网络安全, 网络映射, 网络资产管理, 脆弱性评估, 隐私保护, 靶场环境