AWS EC2 沦陷全记录
从 root 弱口令到 Kinsing + 木马 sshd 双重持久化

1. 执行摘要

一台公开暴露 SSH 的 AWS EC2 实例被完全攻陷，植入了两个独立恶意软件家族，沦为 SSH 爆破僵尸节点与加密货币挖矿宿主。

2. 服务器画像

用户账户

登录历史

SSH 日志里还有多条 root 成功认证的记录，但没有云端身份数据能证明这些访问是不是授权的。这是缺云控制面日志的直接后果，也是下文不少结论只能停在"疑似"的原因。

3. 入侵时间线

4. 根因分析：为什么爆破必然成功

4.1 根本原因

root 用的密码弱到什么程度？低到任何一份常见字典，第一轮就能把它翻出来。看个对照：

结论很清楚：只要密码落在字典里，破解时间就与"试多少次"无关，而与"它在列表第几行"有关。

4.2 一个常见疑问：试这么少次，为何没触发封锁？

这个疑问很自然，但它预设了两个不成立的前提。三个关键原因：

dpkg -l | grep fail2ban  →  (未安装)

机器A (俄罗斯)  →  你的服务器  试 "root"      失败
机器B (越南)    →  你的服务器  试 "123456"    失败
机器C (巴西)    →  你的服务器  试 "…"         ✅ 命中！

4.3 入侵链路重建

1. 攻击者此前已入侵数千台服务器，组成僵尸网络
2. 某台僵尸机器扫到本机 22 端口，字典命中弱口令
   一次即中，直接拿到 root shell
3. 执行 passwd root 改成自己知道的密码
   顺带给自建账号 liangjiang 设了密码
4. 注入后门 SSH 公钥（root@u911 的 RSA key）
5. 部署 work32 扫描器 + xmr 挖矿 + kworkers + linux_server64
6. 写入 crontab 双重持久化，清空 iptables
7. 注入 iptables 规则放行 C2 端口 8015
8. 6 天后二次植入木马 sshd 后门（端口 1919）
   加固后门，防止被清理

5. 威胁一：Kinsing 家族恶意软件

6. 威胁二：木马 sshd 后门

/root/.6400401235605125863/
  └── sshd  (30 MB, rwxr-xr-x, Oct 8 20:22)

7. 威胁三：后门 SSH 公钥

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDc3BlbiQaznPT8TScrs9YIzmrpI9Lpa4LtCjB5z0LuQ4o6XwvzomxAixn2F1jaUl175Cxcg3PmUsPOLE+WeWicKqL2YZ46SotjZgnS6JjXpuZVi7V0DSiXu0itlwWDC9m8huBvUBSIsDCsgb9OeG6rlrCyZgTW+qZciK+KZ8rwlFp3CFyxoF2122ueOnl5pAUCy1iHqGun03dMdUxA1d3KnxSZ3NQrYiH69dc8/YhV4SriOW9psc0pv9KeBLF0OXHtEAdbnSlwfk2uTjjBMK0nDidl7wS52Ygi/H4+P+4EXkSzf4Jj4/L6P3c5rLC3/l3RFdo1T7EQ8fH6NsTYJNZ7 root@u911

8. 威胁四：UFW 之下的 iptables 篡改

ACCEPT  udp dpt:12852     ← 攻击者注入的 UDP 放行规则
ACCEPT  tcp dpt:8015      ← 攻击者注入的 C2 端口放行规则

9. 威胁五：作为跳板攻击全球

10. 样本的静态解剖

把样本复制到本地隔离工作区后做了静态检查：file、sha256sum、strings -a -n 6、JSON 配置键检查。样本全程未执行，未在服务器上安装任何软件，也未运行 YARA、沙箱、反汇编或威胁情报库比对——这是下文多处结论保留"待确认"的原因。

11. IOC 汇总

文件路径

/usr/.work/                           # 整个目录（22 个文件）
/usr/.work/work32                     # 爆破扫描器（主进程）
/usr/.work/work64                     # 64 位扫描器
/usr/.work/xmr                        # XMRig 矿工
/usr/.work/kworkers                   # Kinsing 组件
/usr/.work/linux_server64             # C2 通信组件
/usr/.work/config.json                # XMRig 配置
/usr/.work/ks-script-JLpxkR           # 反取证脚本
/usr/.work/heartalive.lock            # 保活锁文件
/tmp/xmr                              # 矿工运行副本
/root/.6400401235605125863/sshd       # 木马 sshd 后门

哈希

网络指标

矿池      xmr.crypto-pool.fr:6666
C2 端口    8015/tcp（0.0.0.0）    ← 主端口，有 iptables ACCEPT 规则佐证
           8016/tcp               ← 亦曾关联 work32，无放行规则，疑为重启漂移
本地控制   14747/tcp（127.0.0.1）
后门端口   1919/tcp（木马 sshd）
异常放行   udp 12852 / tcp 8015（iptables 注入）

持久化与凭据

crontab          0 * * * * root /usr/.work/work32（root crontab + /etc/crontab 双写）
后门公钥          ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDc3Bl… root@u911
sshd_config      PermitRootLogin=yes + PasswordAuthentication=yes
XMR 钱包          47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV
进程名            work32 / work64 / xmr / kworkers / linux_server64 / multics.x64 / multicsr100rc20_x64
异常账号          liangjiang（攻击者创建，非业务账号）
家族特征文件      ks-script-JLpxkR / kworkers / linux_server64 / heartalive.lock

12. 处置：五阶段，以及重建 vs 清理

阶段 1：立即隔离（0–1 小时）

1. 网络隔离
   修改安全组，仅保留运维访问端口，切断对外爆破
2. 终止恶意进程
   kill -9 77737 77879 271789 —— 注意别碰 PID 271825 的系统 sshd
3. 不要重启
   重启可能触发 crontab 重新拉起恶意软件；先改 crontab 再说

阶段 2：证据保全（1–2 小时）

1. 创建 EBS 快照
   对根卷和所有数据卷创建快照 —— 这一步决定了后面还能不能做离线取证
2. 采集云控制面证据
   CloudTrail、VPC Flow Logs、GuardDuty
3. 导出关键文件
   authorized_keys、crontab、sshd_config、/usr/.work/ 全目录
4. 保存进程 / 网络信息
   ps、ss、netstat 输出

阶段 3：清除与重建（2–4 小时）

首选方案：全新重建主机，从快照离线分析后，仅迁移核验过的数据与配置。

次选方案（若必须在线清除）：

rm -rf /usr/.work/
rm -rf /root/.6400401235605125863/
rm -f  /tmp/xmr
# 清理 crontab 恶意条目（root crontab + /etc/crontab 双处）
# 删除 /root/.ssh/authorized_keys 中 root@u911 的 RSA 公钥
# 恢复 sshd_config：PermitRootLogin prohibit-password / PasswordAuthentication no
# 清理 iptables 注入规则：udp 12852 / tcp 8015（并复查是否另有 8016 相关规则）
# 删除攻击者创建的账号：userdel -r liangjiang
# 重置 root 密码为强密码
# 检查 /var/etc/bin 下是否残留 multicsr100rc20_x64

阶段 4：凭据轮换（4–24 小时）

1. root 密码
   立即改为强密码（当前弱口令已在进程命令行中明文暴露）
2. SSH 密钥对
   废弃现有密钥，生成新密钥——/root/.ssh/ 下所有私钥应按已窃取处理
3. AWS IAM 凭据
   轮换所有 AK/SK，检查实例角色是否被滥用
4. 业务服务凭据
   轮换对外服务的口令与 UUID
5. 证书账户密钥
   重新注册 ACME 账户
6. 其他秘密
   应用 / API token、证书私钥；linux_server64 中疑似调试器口令若确认可用，按暴露秘密撤销

阶段 5：加固与监控（24–48 小时）

1. SSH 加固
   禁用密码登录，仅允许密钥认证；禁止 root 直接登录
2. 防火墙
   iptables / 安全组只开必要端口，限制不必要的出站（本次事件的伤害主要在出站方向）
3. 入侵检测
   部署 AIDE、auditd、fail2ban —— 但要清楚 fail2ban 挡不住分布式低速爆破，它只是降低噪音
4. 监控告警
   CPU 异常、异常网络连接、新增监听端口告警
5. 启用 GuardDuty
   持续监控；同时向 AWS 报备滥用情况，降低封号风险

13. 证据边界与未确认事项

13.1 这些证据能撑多重的结论

结论能走多远，取决于证据站得多稳。这次用到的证据按强度分三档：

13.2 未确认事项

• 攻击者源 IP —— 缺 CloudTrail / VPC Flow Logs，无法确认。
• 完整入侵路径 —— 是仅通过 SSH 弱口令，还是也用了已泄露的密钥？不能排除后者。
• 数据外泄评估 —— 攻击者是否下载了敏感数据，需离线分析快照。
• AWS API 调用 —— 是否使用过 AWS CLI / API？需查 CloudTrail。
• 唯一目标 IP 数 —— 2766 条连接对应多少唯一受害主机？需进一步分析 ss 输出。
• 实际挖矿收益 —— 未取得矿池侧记录与钱包流水，无法确认挖矿量与经济影响。
• kworkers / linux_server64 的真实功能 —— 静态层面未定性，需离线解包与反汇编。
• auth.sh / secure.sh 是否真的运行过 —— /etc/hosts.deny 取证时为空，倾向"未运行"，但未证实。
• 上一任攻击者（multics.x64）的残留 —— /var/etc/bin 等路径是否还有后门？
• 是否存在未覆盖的持久化 —— PAM、系统二进制替换、容器、内核模块等均未排查。
• C2 通信内容 —— 8015 / 8016 端口流量均未抓包，两个端口各自承担什么职能也待确认。
• root cron 条目是否真实执行成功 —— 用户 crontab 中带 root 字段的写法格式可疑，需单独验证。

13.3 待补齐的云侧证据