01-背景与目标

1.1 事件概述

1.1.1 事件发现

本次分析基于一起真实的 Hetzner Cloud VPS 被入侵事件。受害服务器为 CX22 计划（2 vCPU，2GB RAM），位于新加坡数据中心，运行 Ubuntu 24.04 LTS 操作系统。该服务器托管了一个生产环境的 Web 应用程序，并实施了标准的安全加固措施：

• SSH 密钥认证（禁用密码登录）
• UFW 防火墙配置
• 定期安全更新

然而，这些传统的安全措施对于此次攻击向量完全无效，因为攻击者从未在客户机层面进行任何利用。

1.1.2 发现异常

异常最初通过以下迹象被发现：

1. CPU 使用率异常：服务器持续保持近 200% CPU 使用率（2 个核心满载）
2. 未知进程：发现名为 systemd-bench 的进程，但其行为与正常的 systemd 组件不符
3. 时间戳异常：/root/.ssh/authorized_keys 文件的修改时间戳位于 VM 关闭和启动序列之间，这在逻辑上是不可能的

1.1.3 初步调查

通过取证分析发现：

• 一个名为 sanya-key 的 SSH 密钥被添加到 Hetzner 控制台的 SSH 密钥列表
• 服务器被部署了 XMRig 6.25.0 挖矿程序，伪装成 systemd-bench
• 存在三层持久化机制，能够在二进制文件被删除后自动恢复
• 攻击者尝试部署 RemnaWave VPN 节点进行双重获利

1.2 问题陈述

1.2.1 核心问题

本次事件揭示了一个严重的安全盲点：云控制平面凭证泄露可导致 hypervisor 级入侵，完全绕过客户机层面的所有安全措施。

传统的安全加固措施（如 SSH 密钥认证、防火墙、入侵检测）对于此类攻击完全无效，因为攻击者是在虚拟机外部通过云提供商的 API 进行操作。

1.2.2 痛点分析

1.3 研究目标

1.3.1 主要目标

1. 完整还原攻击链条：从初始入侵到持久化建立的每个步骤
2. 分析攻击技术细节：Rescue Mode API 滥用、持久化架构、网络逃逸技术
3. 提取威胁情报：IOCs、攻击者基础设施、矿池数据
4. 提供检测与防御指南：基于主机、网络、云控制平面的检测方法

1.3.2 研究问题

本次研究试图回答以下核心问题：

1. 攻击者如何利用 Hetzner Rescue Mode API 实现入侵？
2. 为什么传统的 SSH 密钥限制和防火墙规则对此攻击无效？
3. 攻击者的持久化架构是如何设计的？如何彻底清除？
4. 如何检测和预防此类攻击？
5. 攻击活动的规模和经济模型是什么？

1.4 约束条件

1.4.1 分析范围

• 时间范围：2026 年 3 月 2 日至 3 月 8 日（事件发现和分析周期）
• 技术范围：Hetzner Cloud 基础设施、XMRig 挖矿程序、Linux 持久化技术
• 数据来源：单一受害服务器的取证数据、矿池公开仪表盘、攻击者基础设施分析

1.4.2 分析限制

1. 单一样本：分析基于单一受害服务器，可能无法代表攻击活动的全部变种
2. 时间窗口：攻击者可能在分析开始前已访问其他资源，但无法完全追踪
3. 攻击者身份：虽然存在归因指标，但无法 100% 确认攻击者真实身份
4. 矿池数据：仅能访问公开仪表盘数据，无法获取攻击者的实际提现记录

1.4.3 成功标准

本次分析的成功标准包括：

• 完整还原攻击时间线和攻击链条
• 详细分析攻击技术的实现机制
• 提取可操作的威胁情报指标（IOCs）
• 提供可落地的检测和防御建议
• 建立 MITRE ATT&CK 映射框架

1.5 云安全威胁背景

1.5.1 云加密劫持趋势

根据行业报告，云加密劫持已成为云安全的主要威胁之一：

• 增长趋势：2025 年云加密劫持事件同比增长 300%
• 目标选择：无服务器计算、容器编排、VPS 提供商是主要目标
• 攻击向量：API 密钥泄露、弱凭证、未修补的云管理漏洞

1.5.2 云控制平面风险

云控制平面（Cloud Control Plane）是管理云资源的核心接口，包括：

• 控制台 UI：Web 界面管理云资源
• API 接口：REST API 用于自动化操作
• CLI 工具：命令行界面管理资源

风险点：

1. 凭证泄露：密码、API 令牌、SSH 密钥被盗
2. 权限过大：单一凭证可执行敏感操作（如 Rescue Mode、快照、网络配置）
3. 监控缺失：缺乏对敏感 API 调用的实时监控和告警
4. 审计不足：API 调用日志保留期短或未启用

1.5.3 Hetzner Rescue Mode 机制

Rescue Mode 是 Hetzner Cloud 提供的一项维护功能，设计初衷是允许用户在系统无法启动时进行修复：

正常流程：
1. 用户在控制台启用 Rescue Mode
2. 指定用于访问 Rescue System 的 SSH 密钥
3. 重启服务器
4. VM 从内存中的 Debian Rescue System 启动
5. 用户 SSH 登录 Rescue System
6. 挂载原系统磁盘（/dev/sda）进行修复
7. 完成后重启回正常系统

攻击者滥用： 攻击者通过被盗的控制台凭证，将 Rescue Mode 武器化，在受害者 VM 离线时直接修改磁盘内容。

1.6 本章小结

本章介绍了 Hetzner 云加密劫持事件的背景信息，包括：

• 事件发现：通过 CPU 异常和时间戳异常发现入侵
• 核心问题：云控制平面凭证泄露导致 hypervisor 级入侵
• 研究目标：还原攻击链、分析技术细节、提供防御指南
• 约束条件：分析范围、数据来源、成功标准
• 威胁背景：云加密劫持趋势、控制平面风险、Rescue Mode 机制

下一章将深入分析攻击技术架构，包括 Rescue Mode 攻击链、持久化机制和网络逃逸技术。

参考资料

• Innora.ai 原始分析
• Hetzner Cloud 文档
• MITRE ATT&CK Cloud Matrix