GitShiryu/wazuh-siem-incident-response
GitHub: GitShiryu/wazuh-siem-incident-response
一份自托管 Wazuh SIEM 遭受加密货币挖矿程序入侵的真实事件响应案例研究,涵盖检测、遏制、根因分析与持续安全加固的完整流程。
Stars: 0 | Forks: 0
# 事件响应与安全加固:自托管 SIEM 中的加密货币挖矿程序
**类型:** 真实案例研究 — 事件响应 + 补救 + 持续安全加固
**环境:** 通过 Docker 自托管的 Wazuh(开源 SIEM),部署在生产服务器上
**状态:** 已遏制,根本原因已修复,安全加固进行中
## 执行摘要
- 一个 Monero 挖矿程序 (XMRig) 被发现运行**在 Wazuh manager 自己的 container 内** —— 这个本该检测此类入侵的工具,本身却成了入口点。
- 根本原因:未修复的严重 CVE (CVSS 9.9) + 从未更改的默认演示凭据 + 无需暴露在互联网上的管理端口。
- 磁盘证据表明,恶意二进制文件在文件系统中潜伏了数月,然后才开始主动挖矿 —— 直到 CPU 使用率飙升时才被注意到。
- 在几分钟内完成遏制;随后的工作窗口期内完成了全面补救(凭据轮换、端口隔离、大版本升级、持续检测),且未丢失数据。
- 安全加固工作的副作用:发现并修复了**第二个不相关的安全问题**(辅助脚本中的明文密钥) —— 这个发现仅仅是因为事件响应促使对服务器进行了更广泛的审查。
## 背景
通过 `docker compose` 运行的 SIEM Wazuh,单节点,监控一台生产服务器。一个本地 Wazuh agent 向它自己的 manager 汇报(这是小型环境中的常见设置,没有专用的远程收集基础设施)。
## 时间线(相对于检测当天 —— “第 0 天”)
- **第 0 天之前的几周到几个月:** 恶意二进制文件被植入到 manager container 内的 `/var/tmp` 中。磁盘时间戳(mtime/ctime)彼此不一致 —— 这表明该二进制文件在被激活前很久就被植入,这是静默持久化访问的典型行为。
- **第 0 天,清晨:** 针对 Wazuh API 和 agent enrollment 服务的多次探测尝试,来自 4 个不同的 IP —— 包括一次匿名 API 请求和无效的 agent 注册尝试。均未成功(没有伪造的 agent 被注册)。
- **第 0 天,下午:** 检测到 `xmrig` 进程在 manager container 内以 root 身份消耗约 230% 的 CPU,在一个公共矿池中挖矿。
- **第 0 天,几分钟后:** 遏制 —— container 被停止,IP 被封锁,管理端口被隔离。
- **第 0 天,稍晚:** 对服务器进行新的全面扫描确认了遏制状态(没有残留的恶意进程),并发现了同一活动的另外 2 次探测尝试,这些尝试也被封锁。
- **随后的安全加固环节:** 凭据轮换、大版本升级、实施持续检测、修复附带发现(暴露的密钥)。
## 检测
该进程在每次检查时都显示为全新的 PID 和 worker 名称 —— 这是 *double-fork*/重新 daemon 化的行为,是恶意软件用来在父进程死亡后存活并阻碍手动识别的一种技术。起初这给人一种合法 watchdog 的错觉,直到对该二进制文件(`/var/tmp/xmrig`,约 8.3MB)的分析确认它是一个挖矿程序。
## 根本原因
三个因素结合在一起,任何一个都不足以单独触发,但结合在一起却形成了一条完整的漏洞利用链:
1. **已知但未修复的漏洞** —— 正在使用的 Wazuh manager 版本处于受产品分布式 API 中不安全反序列化导致的严重 RCE CVE (CVSS 9.9) 影响的范围内,在该事件发生数月前就已公开报告存在大规模主动利用,被用于安装挖矿程序和 IoT 僵尸网络变体。
2. **从未更改的默认演示凭据** —— `docker-compose.yml` 使用了发布在 GitHub 项目官方仓库中的示例密码。这些密码是公开已知的,因此等同于没有密码。
3. **不必要的管理端口暴露** —— API、agent enrollment 和 indexer (OpenSearch) 被发布在 `0.0.0.0` 上,但实际上并没有这个必要;只有合法 agent 的事件接收端口需要可访问。
## 立即遏制
1. 停止受损的 container —— 立即终止了恶意进程。
2. 通过防火墙封锁探测尝试的源 IP(永久规则,重启后依然有效)。
3. 在 `docker-compose.yml` 中将管理端口限制为 `127.0.0.1`。
4. 从头重新创建了 stack(干净的运行文件系统),几小时后通过第二次全面扫描重新验证了遏制状态。
## 安全加固 —— 根本原因补救
**1. 凭据轮换。** 官方的密码更改工具在此部署中不起作用(该脚本假设是通过系统包安装的,但在该 container 中,文件直接打包在镜像内,没有等效的注册信息 —— 静默失败,`exit 0` 但未应用任何更改)。通过等效的手动流程进行了诊断和规避(使用产品自带哈希工具生成 hash,编辑内部用户文件,通过安全管理工具重新应用,并单独更改 API 端的凭据,因为它使用自己的身份验证系统)。总共轮换了 8 个凭据,在结束工作窗口前逐一进行了验证。
**2. 审查端口暴露。** 调查显示,所谓的“远程 agent”实际上是通过 loopback 连接的本地 agent —— 根本没有外部的 enrollment 端口合法使用者。该端口被直接限制为 `127.0.0.1`,彻底消除了攻击面,而不是使用 IP 白名单规则(只有存在真正的远程 agent 时才有意义)。
**3. 大版本升级(从根本上修补 CVE)。** 最初由于索引引擎数据迁移的风险而推迟。随后采用安全策略执行:在采取任何操作之前对所有 volume 进行完整备份,对自定义状态进行版本控制检查点(以便允许精确回滚),并有选择地将安全加固配置重新应用到新版本上(因为不同版本之间的配置结构发生了变化,例如证书路径、模块名称)。在此过程中,磁盘在索引迁移期间空间耗尽(新镜像耗尽了剩余空间) —— 通过删除旧镜像并在恢复之前释放日志空间得以解决。升级后的验证涵盖了 indexer 集群、身份验证、dashboard、agent 和告警集成,全部确认正常运行。
观察:从某个版本开始,索引引擎的变更方式阻止了降级 —— 只有完整的备份恢复才能回滚,因此是在完全知晓此风险的情况下才做出推进升级的决定。
**4. 持续检测(填补事件造成的实际缺口)。** 在此事件之前,对 Wazuh 本身的唯一监控形式是检查 dashboard 的 HTTP 运行时间 —— 如果挖矿程序静默运行数月且未导致服务宕机,这种方法是检测不到的。实施了一个自定义集成脚本(遵循产品官方内部脚本的模式),每当 Wazuh 自身生成高严重性事件时,该脚本就会向消息通道发送实时告警。在认为完成之前,使用了模拟告警进行了端到端测试。
## 附带发现 —— 明文密钥
在安全加固过程中,发现一个监控辅助脚本中包含来自通知服务的 API token,**在源代码中是明文硬编码的**,而这台服务器在最初检测之前的几周内其 root 访问权限就已经被入侵了。采取的行动:在源头撤销并重新生成了 token,重构脚本以从具有严格权限(仅允许 root 读取)的单独环境文件中加载密钥,并顺带修复了同一脚本中意外导致的代码重复(该重复会引起重复告警)。
## 经验教训
- **安全工具本身也是攻击面。** 过时且配置不当的 SIEM 本身就是高价值目标 —— 访问它会暴露组织自身的安全数据。
- **公共仓库中的默认凭据 = 没有凭据。** 文档/官方仓库中的任何示例密码都应被视为已泄露,即使在“内部”环境中也是如此。
- **运行时间检测不等于安全检测。** 监控服务是否返回 HTTP 200 并不能替代关于真实安全事件的告警 —— 两者解决的是不同的问题。
- **有状态系统的大版本升级在开始前就需要回滚计划**,特别是当底层数据引擎在版本之间可能存在不可逆的变更时。
- **事件响应是进行更广泛审计的好机会** —— 暴露密钥的发现不属于原始范围,但正是因为该事件促使对整个服务器进行更仔细的审查才得以被发现。
## 待办事项 / 下一步计划
- 将产品 API 的身份验证从用户名/密码迁移到证书/token,进一步减少对静态密钥的依赖。
- 在此工作期间在一个独立系统中发现的静态/可预测密钥(不在此事件范围内) —— 已标记在专门的环节中进行轮换。
## 附录 —— 入侵指标 (IOC)
- 二进制文件:`/var/tmp/xmrig`,约 8.334.576 字节
- 矿池:`auto.c3pool.org:33333`
- 关联的 Monero 钱包:`4Ap911cSUFCFo5mU94K9JMJPefty1iLJN3eLRkT28Y1B8vnZGSNMm7A6FJtRPrX4hebEEhL1juZLDNPXFk55zJmoFPgEhZU`
- 涉及探测/利用的 IP:`185.247.137.242`,`45.82.78.103`,`45.156.128.132`,`45.156.131.7`
- 利用的 CVE:Wazuh 分布式 API 中因不安全反序列化导致的 RCE(版本范围 < 4.9.1),CVSS 9.9
## 展现的技能
基础进程取证分析(double-fork、磁盘时间戳)· 压力下的事件分类与遏制· 多因素根本原因分析· Docker container 安全加固· 分布式系统中的安全凭据轮换· 针对有状态大版本升级的备份/回滚策略· 检测工程(填补真实的监控缺口)· 密钥安全管理· 结构化的事件技术文档记录。
标签:CISA项目, Wazuh, 加密货币挖矿木马, 安全事件响应, 案例研究, 系统加固, 请求拦截