Tauqeerkhan187/Detection-lab

GitHub: Tauqeerkhan187/Detection-lab

基于 Wazuh 的 SIEM 实验环境,通过自定义检测规则和关联逻辑将蜜罐活动转化为映射 MITRE ATT&CK 的分级安全告警。

Stars: 0 | Forks: 0

# 检测实验环境 **一个配备了自定义检测规则的 Wazuh SIEM 实验环境,能将原始的蜜罐活动转化为带有严重性评级并映射到 MITRE ATT&CK 的告警 —— 包括可以检测多步骤攻击序列而不仅仅是单个事件的关联规则。** 这是 [HoneyTrack](https://github.com/Tauqeerkhan187/HoneyTrack)(我自定义的 SSH/Telnet 蜜罐)的蓝队对应项目。HoneyTrack 负责捕获攻击者行为;而这个实验环境负责检测它们。两者结合形成了一个闭环:一边负责攻击生成,另一边负责检测工程。 ![MITRE ATT&CK 框架](https://static.pigsec.cn/wp-content/uploads/repos/cas/6c/6cfb0395e1a0e1e8d830df134f91b47eecedbfdc9b6d29e06d70876f5bba64be.png) ## 为什么构建这个项目 部署一个 SIEM 只是配置工作。*编写检测规则* 才是真正的工程。我想要一个能展示后者的项目 —— 接收真实的攻击者活动流,并构建出 SOC 分析师真正会依赖的规则、严重性模型和关联逻辑。 蜜罐为我提供了一个真实的攻击者行为实时数据源,这意味着每一条规则都可以针对真实捕获的事件进行测试,而不是凭空捏造的样本。 ## 核心功能 - **14 条自定义检测规则**,涵盖蜜罐输出的每一种事件类型,每条规则都映射到了特定的 MITRE ATT&CK 技术 - **关联规则** 可以检测 *行为序列* —— 例如,来自同一源的 payload 下载随后发生持久化操作,将触发一条描述整个沦陷过程的高严重性告警,而不是两个孤立的事件 - **镜像攻击生命周期的严重性模型** —— 侦察阶段为 3-5 级,植入阶段为 8-9 级,传入阶段为 10 级,持久化为 12 级,而关联后的 kill chain 则为 13 级 - **端到端日志 pipeline** —— 蜜罐生成的 JSON 由 Wazuh agent 发送,解码为可查询的字段,并由规则进行匹配,整个过程无需自定义解码器 - **经过验证的检测** —— 每条规则在部署前都使用 `wazuh-logtest` 进行了验证,并确认能在 dashboard 中实时触发 ## 架构 ``` [ Attacker ] │ SSH / Telnet ▼ ┌──────────────────────────┐ │ HoneyTrack honeypot │ captures session, writes JSON events │ (separate project) │ └────────────┬─────────────┘ │ data/logs/events.jsonl ▼ ┌──────────────────────────┐ │ Wazuh agent │ ships events over 1514/tcp │ (Linux endpoint) │ └────────────┬─────────────┘ │ ▼ ┌──────────────────────────────────────────────┐ │ Wazuh manager │ │ │ │ JSON decoder → custom rules → alerts │ │ (local_rules.xml) │ │ single-event + correlation │ └────────────┬─────────────────────────────────┘ │ ▼ ┌──────────────────────────┐ │ Wazuh dashboard │ Threat Hunting, MITRE ATT&CK, │ │ severity breakdown └──────────────────────────┘ ``` ## 检测目录 完整详情请参见 [`docs/detection-catalog.md`](docs/detection-catalog.md)。摘要: | 规则 | 检测内容 | ATT&CK | 级别 | |------|---------|--------|-------| | 100100 | 基础规则 —— 任意蜜罐事件 | — | 3 | | 100101 | 蜜罐会话已开启 | T1078 | 5 | | 100102 | 捕获到凭据尝试 | T1110 | 6 | | 100103 | 执行了命令 | T1059 | 5 | | 100104 | 传入工具传输 (wget/curl) | T1105 | 10 | | 100105 | 落地文件 | T1105 | 9 | | 100106 | 修改文件权限 | T1222 | 8 | | 100107 | 持久化尝试 (cron) | T1053 | 12 | | 100108 | 通过 sudo 提权 | T1548.003 | 8 | | 100109 | 执行解释器 | T1059.004 | 9 | | 100110 | 会话已关闭 | — | 3 | | **100120** | **暴力破解** —— 2分钟内尝试 5 次凭据 | T1110 | 10 | | **100121** | **脚本化攻击者** —— 60 秒内执行 10 条命令 | T1059 | 10 | | **100122** | **Kill chain** —— 下载后发生持久化 | T1105, T1053 | 13 | 加粗显示的三条规则是关联规则。它们的级别被刻意设定为高于构成它们的基础事件:一个行为序列比其中的任何单个步骤都更具实际意义。 ## 关联规则 集合中最有趣的检测: ``` 100107 100104 peer_ip HoneyTrack: kill chain - payload download followed by persistence from $(peer_ip) T1105 T1053 ``` 孤立来看,`crontab -e` 只是一条级别为 12 的持久化告警。但如果在此之前发生了来自同一源的 payload 下载,它就会变成一条级别为 13 的告警,携带横跨四个战术(Command and Control、Execution、Persistence 和 Privilege Escalation)的**双重**技术。这只是一条描述系统沦陷的告警,而不是需要分析师手动关联的两个独立事件。 ![Kill chain 告警](https://static.pigsec.cn/wp-content/uploads/repos/cas/fa/fa9dcf857cbf17dbb1896a8ecf9af7cbc25c5f21e26483a8b6a160e502998db9.png) ## 工作原理 **数据接入。** 蜜罐将每个事件作为单个 JSON 对象追加到 `data/logs/events.jsonl`。Wazuh agent 使用 `json` 监控该文件,因此每个字段(`peer_ip`、`event`、`value`、`protocol`)都会成为 SIEM 中可独立查询的字段 —— 无需自定义解码器。 **规则结构。** 一条基础规则(`100100`)匹配所有的蜜罐事件。子规则通过 `` 继承自该基础规则,并对 `event` 字段进行匹配,从而分配严重性和 ATT&CK 元数据。Wazuh 会自动将单个技术 ID 展开为其完整的战术和技术名称。 **事件关联。** Wazuh 的 `if_matched_sid`、`frequency` 和 `timeframe` 属性会对先前发生过的事件进行匹配,并通过 `` 按攻击者 IP 进行分组。关联计数器在触发后会重置,因此突发的大量活动只会产生一条告警,而不是在超过阈值后每个事件都产生一条告警。 ## 实验环境设置 | 组件 | 详情 | |-----------|---------| | SIEM | Wazuh 4.14 一体化部署 (indexer + manager + dashboard) | | SIEM 主机 | Ubuntu Server 24.04, 4 vCPU, 6 GB RAM, 无图形界面 | | 终端节点 | 运行 HoneyTrack + Wazuh agent 的 Ubuntu 虚拟机 | | 网络 | VirtualBox 仅主机模式 (隔离) + NAT 用于更新 | ### 复现步骤 ``` # 在 SIEM 主机上 curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh sudo bash ./wazuh-install.sh -a # 部署规则 sudo cp rules/local_rules.xml /var/ossec/etc/rules/local_rules.xml sudo systemctl restart wazuh-manager # 在端点上,将 config/ 中的 ingestion config 添加 # 到 /var/ossec/etc/ossec.conf,然后: sudo systemctl restart wazuh-agent ``` 在部署前验证规则: ``` sudo /var/ossec/bin/wazuh-logtest # 粘贴来自 samples/events.jsonl 的样本事件 ``` ## 范围与局限性 该实验环境运行在 **隔离的 VirtualBox 环境中**,其中的攻击者活动是由我针对自己的蜜罐生成的,而不是从互联网上捕获的。这是一个深思熟虑的决定:公开暴露蜜罐需要遵循最小权限执行、沙箱隔离以及默认拒绝的出口流量策略,以免使其成为安全隐患,而我将该项目的范围限定在展示检测工程上,不承担这类风险。 有一点值得一提:攻击者的 IP 是私有地址,因此 IOC 丰富化和地理定位查询不会返回任何结果。在经过强化的公开部署中,这些字段会被填充数据,而同样的规则可以不加修改地直接应用。 ## 路线图 - [ ] 带有 Sysmon 和配套检测的 Windows 终端节点 - [ ] 使用 Atomic Red Team 进行检测调优 - [ ] 每条规则的 Sigma 版本,以实现跨 SIEM 的可移植性 - [ ] 针对 12 级以上告警的告警集成(电子邮件 / webhook) ## 相关项目 - [HoneyTrack](https://github.com/Tauqeerkhan187/HoneyTrack) —— 产生该实验环境所检测遥测数据的自定义 SSH/Telnet 蜜罐。 ## 许可证 MIT
标签:Homebrew安装, Wazuh, 安全运营, 扫描框架, 蜜罐, 证书利用