凌晨两点半值班电话把我从床上拽了起来。监控大屏上数据中心测试网段的一台Linux服务器CPU负载已经连续15分钟超过90%。我第一反应是夜间批量任务出问题但远程登录看一眼后后背就有点发凉top命令刷出一长串十几位随机字符串命名的进程占满了几乎所有的核CPU时间还在疯涨。这台机器是测试数据库没有任何重负载任务在跑不存在“正常业务打满CPU”的可能性。中招了而且是挖矿木马。当天的处置最终定性为Outlaw僵尸网络与“魔铲”挖矿工具链在银行测试环境中的联合入侵。攻击者先通过SSH爆破获取权限随后投递了两套彼此独立的挖矿程序在同一台机器上完成持久化并同时开挖把CPU彻底打爆。这个过程里既有老生常谈的弱口令问题也有测试环境被边缘化、安全管控缺失的深层原因。我把这一整次的应急过程、溯源思路、清理步骤和事后反思完整记下来希望对做安全运营和应急响应的同行有实际参考价值——尤其是那些和我一样曾经觉得“测试环境而已影响不大”的人。1. 事件首发告警、进程与第一判断1.1 告警特征CPU持续走高并非偶然监控系统发出的告警信息其实很简单测试网段某台服务器CPU使用率连续15分钟超过90%触发“高资源占用”规则。按照日常经验测试环境偶尔也会有大批量作业把资源跑满通常持续几分钟就会回落。但这一次不同曲线非常平稳地贴在90%以上没有半点波动明显是有人为控制的持续行为。登录服务器之前我先看了一眼监控平台的网络流量数据发现这台机器存在稳定的TCP外联目的端口是常见矿池端口目的IP来自境外。到这里我心里基本已经给事件定了性不是批量任务不是环境Bug是挖矿木马。远程登录后top命令给出了更直观的证据——多个随机字符串进程占据了CPU头部位置单个进程CPU占用率高得离谱而且进程数量不止一个。1.2 测试环境为什么会成为目标很多非安全岗位的同事听说挖矿木马进了银行测试环境第一反应是“测试环境有什么好挖的”。这正是安全运营中最危险的认知误区。挖矿木马对目标的价值判断和人类完全不同它不看数据值多少钱只看CPU算力够不够、安全门槛高不高、被发现的概率大不大。测试环境的机器硬件配置通常不差很多都是和正式环境同规格的设备CPU性能足够挖矿。更重要的是测试环境的管控思路普遍宽松安全设备覆盖不全面运维人员响应也不及时即使中招了攻击者也能安稳地挖上很久。这就像一个安保团队把所有人员都安排在正门结果小偷发现侧门连门锁都没装。本次事件中的这台服务器就是一个典型的“侧门受害者”。2. 攻击链还原Outlaw与魔铲的联合套路2.1 Outlaw僵尸网络的典型行为Outlaw是近年来活跃度较高的挖矿类僵尸网络家族2018年前后大规模出现核心目的就是挖门罗币。它的初始入侵手法以SSH弱口令扫描为主通过对互联网大范围扫描找到开放22端口且口令薄弱的机器然后批量尝试登录成功后投递恶意脚本。这次事件中发现的Outlaw组件结构与公开分析报告中描述的基本一致攻击脚本会下载一个内含多个工具的压缩包落地位置通常在/tmp或者/var/tmp这类容易混淆视听的地方落地后会立即注册crontab定时任务确保即使进程被手动清理过几分钟还会被重新拉起来同时释放一份SSH后门让攻击者后续可以随时重新进入。值得注意的是Outlaw的旧版本中普遍存在“互杀”逻辑也就是发现其他挖矿进程就会主动杀掉以独占CPU资源。但本次这台机器上Outlaw与魔铲的挖矿进程形成了共存局面说明要么攻击者投放的是同一套工具链只是新旧组件之间的互杀机制没有生效要么两个家族分别瞄上了这台机器只是Outlaw的清理逻辑对魔铲的进程保护没有起作用。无论哪种解释双挖矿共存的局面都显著增加了处置难度。2.2 “魔铲”挖矿工具的横向扩散特点“魔铲”这个名字在安全圈内并不陌生它本质上是一套高度自动化的挖矿工具集之所以被叫“铲”大概是因为它在挖矿这件事上挖得又快又彻底。相比Outlaw偏重口令爆破的做法魔铲更依赖已知漏洞利用模块进行横向扩散比如常见的未授权访问漏洞、反序列化漏洞、远程命令执行漏洞等。拿到一台机器后它会复制自身、修改定时任务、关闭系统安全服务、植入守护进程甚至会把系统中的安全软件进程结束掉。本次这台机器上的魔铲组件特征表现为典型的“下载器矿工程序守护脚本”三段式结构。下载器负责从指定URL拉取最新的矿工程序矿工程序负责连接矿池计算守护脚本则负责检查矿工进程是否存活一旦发现被杀就立刻重启。这种三段式结构极大提高了清除难度只杀掉矿工程序没有任何意义守护脚本会在一分钟内把它重新拉起来。2.3 双挖矿叠加带来的真实风险双挖矿威胁叠加不是说两台挖矿木马同时运行、CPU多吃点那么简单。它带来的是整个安全运营层面的复杂度提升第一归因困难。两套工具链都有各自的外联IP、配置文件和持久化机制安全人员需要分别分析判断哪条才是真正的入侵入口这比单一挖矿事件要多花好几倍的时间。第二证据相互污染。两套工具链都会修改crontab、系统配置和文件时间戳导致攻击时间线的重建变得非常困难。比如Outlaw改过一遍crontab魔铲又改一遍最后留下的定时任务列表可能混杂着两套工具的痕迹要逐条分辨来源。第三被利用的跳板风险。挖矿木马往往携带后门组件一旦被其他攻击者发现这台机器已经失陷完全有可能顺着后门进入内网。测试环境虽然隔离等级不高但往往与正式网段存在运维通道如果真的被利用后果就不是多挖几天CPU的问题了。3. 溯源分析从日志与样本还原入侵路径3.1 时间线重建让攻击过程说话应急响应的第一步不是杀毒而是先搞清楚发生了什么。我在现场做的最重要的一件事就是整理出完整的攻防时间线。主要依据是三类数据系统登录日志、命令历史、各类文件的创建时间戳。系统登录日志是最有价值的。这台机器开启了SSH账号密码认证/var/log/secure日志里记录了所有登录尝试。我按时间顺序提取了其中所有失败记录和成功记录很快锁定了攻击者的源IP在感染窗口期内有一个来自境外IP的账号从凌晨1点23分开始持续尝试登录分别尝试了root、admin、test等多个用户名最终在凌晨1点47分通过一个遗留测试账号成功登录。结合登录成功的时间点再去翻这个账号的命令历史.bash_history和文件系统时间就能串起整个攻击过程。大致的时间线整理如下时间事件01:23境外IP开始SSH爆破01:47攻击者通过测试账号成功登录01:50攻击者下载恶意压缩包到/tmp01:52解压并执行恶意脚本01:55修改crontab写入定时任务02:01挖矿进程启动并外联矿池02:15监控平台告警触发3.2 样本静态分析从脚本看行为逻辑拿到恶意压缩包和落地脚本后我没有急着删先做了一轮静态分析。先用file命令看了一下文件类型发现是经过UPX加壳的ELF可执行文件这是挖矿木马最常用的免杀手段之一。加壳可以改变文件特征让传统杀毒软件的静态特征匹配失效。真正信息量最大的还是那些shell脚本。把核心脚本用文本方式打开后逻辑非常清晰脚本先检测当前用户权限如果是root权限就继续执行然后下载远程服务器上的矿工程序接着检查系统中是否已经存在crontab任务不存在就写入。脚本里还有一段循环检测逻辑每隔几分钟检查一次进程是否存活如果进程被杀死就再次拉起。这段脚本用极简的几行代码完成了一个完整的自我修复闭环属于比较典型的实战型攻击工具。在分析过程中我还发现Outlaw组件带有一个SSH后门文件它会在系统原有的SSH配置中追加一个特殊配置允许攻击者通过特定密钥直接免密登录。这意味着即使清理了挖矿程序只要这个后门没有移除攻击者随时还能回来。这种后门的隐蔽性极高不直接检查SSH配置文件很难发现。3.3 证据保全与处置留痕在银行环境做应急响应有一点和其他行业很不一样证据保全必须做得非常规范。我这次处置的第一步不是清理而是把所有关键样本复制了一份保存包括恶意脚本、挖矿程序、crontab导出文件、sshd配置文件和登录日志切片。这些证据不仅用于本次事件的分析也是后续流程中可能需要提交的正式材料。每一步操作都记录下来是个好习惯。我在整个处置过程中记录下自己执行过的每一条命令什么时候杀的进程、删了哪些文件、改了哪个配置全部留痕。这样做的好处一是避免误操作导致二次事故二是后续如果要追责复盘有据可查。4. 应急处置与清除整改实操4.1 断网还是不断一个被讨论过无数次的决策很多刚从事故现场回来的同事都会问同一个问题发现中招了第一件事难道不是拔网线吗我的经验是盲断网在绝大部分场景下都不是最优选择。试想一下如果你拔了网线远程登录通道立刻中断后续取证、分析、清理都只能通过人工到机房操作效率极低。万一这台机器上还跑着什么业务断网的影响面会从“一台服务器中病毒”迅速扩大到“业务中断”。正确的思路是“隔离但保持可控”。我在交换机侧把目标服务器的端口从原有业务VLAN中移出直接划到一个临时的隔离VLAN这个VLAN只允许访问安全分析跳板机禁止访问其他任何机器同时保留了对公网矿池地址的可见性用于观察外联行为。这样既切断了挖矿木马正常使用带宽的能力也控制了横向传播风险又给我们保留了远程分析和取证的通道。整个过程几分钟内完成远比拔网线稳妥。4.2 清理核心步骤先杀进程还是先删文件清理挖矿木马有一个非常经典的顺序问题到底先杀进程还是先删文件我的建议是先断能、再清调度、后杀进程、最后删文件。挖矿木马的生命力核心不是进程而是实现“自我复活”的调度机制。如果先杀进程crontab里的定时任务在一分钟内就会把进程重新拉起来你杀掉10次它就重启11次毫无意义。正确顺序是先清理任务调度删除crontab中的恶意条目删除/etc/cron.d下的恶意脚本清理/etc/rc.local以及systemd服务中注册的自启动项。把这些重生机制全部删除后再杀掉进程此时进程才是真正死透了最后删除磁盘上残留的恶意文件。我在实际操作中按以下顺序执行先导出当前crontab内容保留证据后清空恶意条目逐个检查/etc/cron.d、/etc/cron.hourly、/etc/crontab文件删除一切指向/tmp目录恶意脚本的任务检查systemd服务列表禁用异常服务单元用ps命令定位所有挖矿相关进程一次性kill掉清除/tmp、/var/tmp下的恶意压缩包和脚本文件检查SSH配置移除攻击者注入的后门配置和密钥最后用进程扫描和文件扫描确认无残留。这套顺序执行下来基本可以杜绝“杀完又复活”的问题。如果你发现清理完过一会儿进程又回来了不用怀疑一定是还有某个定时任务或者自启动项没有被找到。4.3 挖矿检测自查一分钟定位可疑进程清除结束之后还有一个重要环节是确认同一个网段的其他机器没有同样的感染。这里分享几个我在现场反复使用的实用检测命令不算高深但真的能救命检查CPU异常的进程优先关注ps输出时间长的ps aux --sort-%cpu | head -20检查/tmp和/var/tmp目录下近期生成的隐藏文件find /tmp /var/tmp -type f -mtime 0 -mtime -30 -exec ls -lah {} \;检查所有用户的定时任务不只是当前用户for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2/dev/null; done ls -la /etc/cron.*很多挖矿木马会把挖矿文件伪装成看似正常的系统文件名。比较推荐的做法是直接检查/proc目录下的进程启动命令即使系统进程列表被rootkit隐藏从/proc/PID/cmdline也能看到真实命令for p in /proc/[0-9]*; do echo -n $p ; cat $p/cmdline 2/dev/null | tr \0 ; echo; done | grep -Ev \[ | head这套方法能覆盖大多数场景但如果遇到使用内核级rootkit的样本还需要借助专门的行为检测工具和干净的系统环境来分析。4.4 恢复验证不能只以CPU降下来为准清理完成后我留了24小时的观察窗口而不是急着把机器恢复投入使用。观察期间重点关注三个指标CPU是否回落到底噪水平、是否还有到矿池IP的外联流量、系统日志里是否还有异常的登录记录。这三项中任何一项异常都必须重新进入排查流程。这台机器在清理后的第一个小时内CPU就回落到正常水平但网络层面仍偶发出现到境外IP的握手请求。进一步追踪发现是魔铲组件中另一个守护脚本残留藏在/usr/lib/x86_64-linux-gnu目录下伪装成动态链接库文件。这个文件不在我的第一轮清理范围内因为它的文件名极具迷惑性没有专门工具的话大多数管理员根本不会注意到。这让我意识到一次合格的清除必须做到“多次检查、交叉验证”不能寄希望于一轮命令就解决所有问题。5. 纵深防御反思这次事件真正的问题不在挖矿5.1 六个被忽视的盲区整起事件处置完之后我花了很长时间复盘想找到真正让攻击者长驱直入的深层原因。表面上看是SSH弱口令问题但往深了挖至少存在六个系统性的盲区需要正视第一测试环境安全投入过低。主机安全Agent没有覆盖到测试网段EDR、HIDS这类关键检测手段在正式环境部署得很齐全测试环境却基本处于裸奔状态导致攻击者从入侵到被发现的几个小时里我们完全没有任何主动发现能力只能靠监控平台级别比较低的CPU告警来感知。第二东西向流量基本没有控制。我们的网络边界上防火墙、IDS一应俱全但整个内部网络之间的访问控制非常松散测试网段甚至可以访问数据中心里几乎所有的其他网段。一旦这台机器被攻破它就变成了一个横向移动的跳板。第三出站流量未做策略限制。内网服务器向外网发起连接没有经过审批或白名单控制一台服务器可以自由连接任何公网矿池。这在很多传统架构里是常态但恰恰是挖矿木马能持续存活的土壤。第四账号管理长期混乱。这台机器上遗留了多个测试账号密码强度极弱离职人员账号移交流程没有落实。攻击者爆破成功利用的是半年前就闲置的测试账号这个账号的生命周期管理基本处于失控状态。第五安全基线与异常检测体系缺失。我们说不清楚这台机器平时的CPU基线是多少、正常外联对象有哪些、进程白名单是什么所以当挖矿进程跑起来时除了“CPU太高”之外没有任何一台设备能告诉我们是哪里出了问题。第六事件响应流程对测试环境存在盲区。日常安全巡检和值班值守的资源全部向正式系统倾斜测试环境不在应急响应的重点保障范围内。这台机器告警后15分钟才有人登录上去看而这个时间窗口足够挖矿木马完成下载、植入和开挖的全套动作。5.2 分层防御体系需要补的课基于这次事件我把后续要落地的改进措施整理成了一张行动清单这里也分享给同行网络层对测试环境单独划分VLAN禁止与生产网段直连所有跨区访问必须经过防火墙并且白名单化限制全部服务器出站互联网访问只允许通过统一的代理或前置机访问外部资源。主机层强制关闭SSH密码登录全面改为密钥认证对于必须使用密码的场景部署登录失败自动封禁策略回收闲置测试账号并建立账号生命周期管理制度主机安全Agent覆盖范围扩大到所有服务器不得因为“测试环境”缩减检测覆盖面。检测层建立基于行为的异常检测规则重点覆盖CPU突变、异常外联、定时任务变更、隐藏进程等场景接入矿池IP情报库及时发现到矿池的通信行为定期做安全基线扫描持续发现偏离基线的设备。流程层把测试环境纳入常规应急响应范围明确处置时限、响应人员、汇报路径定期组织全面排查和修复行动把测试环境的失陷当作正式环境失陷来严肃对待。5.3 几个当天就能落地的低成本措施除了上面这些动辄要写几个方案才能推动的大动作我也整理了几个当天就能落地的低成本措施供同行参考先在核心服务器上禁用密码登录只保留密钥认证这是对付SSH爆破最直接有效的手段五分钟就能做完。然后统一检查一遍测试环境里所有账号的登录权限把长期没人使用的账号全部禁用或删除。这个不需要申请任何预算只需要一份清单和一点耐心。再在监控平台加一条简单的规则任何服务器对外连接非标准端口的流量直接告警。矿池通信大多数走非标准端口抓到这类流量基本就等于抓到了挖矿行为。这条规则上线当天我们就又发现了两台存在可疑外联的机器。最后把安全Agent的安装范围从“生产必须装”扩展为“所有服务器必须装”这个说难也不难难的是打破“测试环境可以不管”的惯性思维。我不太想说太多“以后要重视安全”这类空话因为安全意识的建立从来不是靠口号靠的是每一次真实事件中积累的细节和教训。这次事件给团队带来的最大变化其实是整个团队再也不觉得“测试环境”这四个字可以成为安全管控缺失的挡箭牌了。一台服务器的价值确实只是几块CPU但一个被打出洞的网络价值归零。整个处置过程持续了将近三十个小时最累的不是通宵清理样本而是反复验证“是不是真的清干净了”的那种心理压力。希望这份处置记录能帮大家少踩一些我踩过的坑。