最近，我复核了一份云主机入侵事件的本地取证记录。与此同时，也有多名群友反馈遇到异常。公开记录之前，先把能确认的事实和仍待验证的猜测分开：现有材料能确认一台虚拟机被入侵，但不足以证明云服务商平台、宿主机或其他客户实例遭到入侵。

本文隐去了受影响主机地址、攻击来源地址、密钥指纹和恶意程序内置认证信息。群友反馈尚未逐一取得原始日志核验，不能据此直接归因。

已确认的个案

取证发生在 2026 年 10 月 27 日、主机重装前。目标是一台运行 AlmaLinux 10.2 的香港云主机。SSH 日志记录到 10 月 24 日有多个来源成功以 root 密码登录：同一个来源在恶意文件创建前后各成功登录一次，随后还有四个不同来源登录。

其中一次约 11 秒的会话创建了一个 Python SOCKS5 代理程序和配套的 systemd 服务。服务设置为开机启动并在退出后自动重启，同时尝试放行代理监听端口。10 月 27 日采集时，代理仍在运行，并有多个外部连接。

从连接目标看，部分流量可能与账号撞库有关；这是根据网络目的地址作出的推测，不是目标平台确认的调查结论。可以确认的是，这台机器被用作他人流量的出口。

取证报告记录的处置是：先保存证据，再于 10 月 27 日重装为 Debian 13，改用仅密钥 SSH。这是本地记录中的处置情况，不代表我在本文发布时重新验证了线上主机状态。

这次能证明什么，不能证明什么

现有证据较有力地支持以下结论：

  • root 的 SSH 密码认证曾成功，且恶意程序与持久化服务在一次成功登录后被创建。
  • 被发现的程序是 SOCKS5 CONNECT 代理；采集时监听 TCP 45139。
  • 检查没有报告额外 shell 用户、软件包二进制被替换、ld.so.preload 或外置内核模块。

但证据也有明显缺口：

  • 成功登录来源在这台主机上此前没有失败认证记录。因此，不能断言密码就是由这台机器上的暴力破解得到；密码复用、外部泄漏或其他凭据获取途径仍有可能。
  • auditd 日志轮转后无法覆盖最早的入侵时段。主机已经重装，完整命令历史、数据访问情况和潜在外传情况都无法从现有记录中还原。
  • 软件包校验和有限 IOC 检查没有发现特定痕迹，不等于能证明 root 权限下没有其他活动。
  • 多名群友报告异常是需要服务商优先关联调查的线索；在逐一核对原始证据之前，不能称为已确认的同一事件或服务商级入侵。

特别需要区分的是：本次取证的主机当时允许 root 密码登录。 所以它不能证明“仅密钥 SSH 主机被绕过”。仅密钥登录能降低密码猜测和密码复用风险，但无法单独排除私钥被窃、云账号/API 被盗、控制台或救援模式操作、cloud-init 注入等路径。

请服务商核查的平台侧记录

如果多个相互独立的客户在相近时间发现异常，单独清理每一台虚拟机可能会错过共同原因。服务商应保全相关日志，并根据客户私下提交的实例标识和 UTC 时间，检查：

  1. 云账号登录、MFA 变更、API Token 创建或调用、SSH 公钥变更。
  2. 控制台/VNC/KVM、救援模式、重装、快照和镜像操作记录。
  3. cloud-init、user-data、启动脚本、元数据服务、镜像模板及安全组/防火墙变更。
  4. 实例所在宿主机或集群的迁移、维护、虚拟化管理访问和特权操作记录。
  5. 同区域、相近时间的其他客户报告是否与共同控制面、宿主、镜像或配置变更有关。
  6. 每类日志的覆盖范围和保留期限；已重装实例是否仍有服务商侧快照、磁盘或宿主审计证据。

请服务商逐项说明“已检查”“日志不可用”或“未检查”，并给出结论依据和置信度。只回复“平台运行正常”无法回答日志保全与跨实例关联的问题。

其他用户可以先做什么

发现异常时

  • 先记录实例 ID、云账号、发现时间（UTC）、现象和告警。避免先清日志或立即重装；在不扩大影响的前提下隔离实例并保存快照、磁盘副本、控制面审计与网络记录。
  • 从干净设备检查云账号登录、MFA、API Token、SSH Key、控制台/救援操作、快照、user-data 和防火墙变更。撤销不认识的 Token，启用 MFA，并检查账号通知和账单联系人。
  • 检查 SSH 成功登录记录、root 登录策略、未知用户和 authorized_keys；再核对 systemd service/timer、cron、sudoers、启动脚本、监听端口和近期新增文件。
  • 若确认系统级失陷，保存证据后从可信镜像重建，并从干净设备轮换主机能访问到的 SSH 私钥、应用凭据、数据库口令和云 API 凭据。不要在疑似失陷主机上输入新凭据。
  • 把 SSH、sudo、systemd、audit、云防火墙和控制面日志保存到实例之外，注明时区并设置足够的保留时间。日志轮转可能让关键时间段永久缺失。

本个案的检索线索

这些线索只对应本次个案，不是通用恶意软件签名。发现匹配时要结合创建时间、文件哈希、服务定义和网络连接判断，不要只按名称就删除：

  • TCP 监听端口：45139。
  • 可疑 systemd unit：systemd-hwdb-sync.service。
  • 伪装进程名：kworker/0:5H；若它实际对应 Python 进程、独立服务 cgroup 和异常监听端口，更值得调查。
  • 可疑程序路径：/var/cache/.locale-cache-4h6cu8/hwdb-index.dat。

我整理了一个只读 Bash 检查脚本，用于在 Debian、AlmaLinux 等 systemd Linux 上查找这些已知特征。它不会联网、删除文件、停止服务或改防火墙；命中时只报告线索，不自动清理。建议先查看脚本内容，再以 root 运行以获得完整进程和监听信息。

下载事件 IOC 检查脚本

SHA-256：4f9366472ace2a02a0564dddbf7743510c45380ca7621c78f77ac9747934537b

运行示例：

sudo bash check-cloud-vm-incident-iocs.sh

脚本返回 1 表示命中至少一项可疑指标，返回 0 表示没有命中已知特征。没有命中不等于主机干净；它不检查云服务商控制面、完整认证日志或未知恶意行为。

本文不提供恶意程序样本、代理认证信息、目标主机地址或攻击来源地址。样本应通过认证工单安全传递，并只在隔离环境分析。

怎样汇总群友报告

每位遇到异常的用户可以通过私下渠道向服务商提交完整实例标识和日志。公开群里建议只分享脱敏信息：云厂商/产品/区域、系统版本、首次发现时间（UTC）、SSH 登录方式、是否启用 MFA、观察到的迹象、日志覆盖时间、是否已快照或重装、服务商工单号。

请标明哪些内容来自原始日志或取证，哪些只是观察或猜测。不要在公开群发送公网 IP、完整日志、私钥、Token、密码、未脱敏快照或包含其他用户数据的文件。多份相近时间、相似且可验证的迹象有助于服务商做关联分析；仅有 SSH 扫描或单个成功登录记录，不能独立证明云平台遭到入侵。

事件响应中保全主机、网络和控制面日志的做法，也见 CISA 联邦网络安全事件与漏洞响应手册。云服务日志的生成、留存和客户可见性问题，可参考 CISA Secure by Design 的相关原则。