1. 事件开端凌晨的两条安全告警上周值班晚上十一点多安全平台的告警突然响了两条。第一条是某台服务器的CPU使用率持续15分钟超过90%第二条更直接——检测到该服务器与一个已知矿池地址建立外联通信。半夜看到这种组合告警基本可以判定是挖矿木马了。单看CPU飙高可能有别的解释比如业务高峰期或者定时任务跑批但一旦同时出现外联矿池的行为那问题就比较明确。我没有直接登服务器就动手而是先做了一件应急响应里最容易被忽略的事——确认这台机器上跑的是什么。这里想强调一个处置原则接到告警的第一反应不该是赶紧杀进程而是先搞清楚这台服务器承载什么业务、有没有其他节点可以顶替、能不能直接隔离。因为一旦误操作比如把还在跑批的业务进程当成木马干掉或者贸然重启服务器后果可能比木马本身更严重。确认了一下这台机器是某内部系统的单机节点不是核心数据服务影响面可控。于是按流程走处置先查封端口和恶意IP再做现场定位和清理整个过程从登录到基本控制住大约用了两个小时。2. 排查定位从CPU异常到挖矿木马实锤2.1 进程排查异常进程不会藏太久登录服务器之后我习惯性的第一屏操作还是top先看整体负载。单看下图的意思大家应该都懂系统满负载几个核心都跑满了User态占用非常高。接着按CPU降序直接锁定一个可疑进程进程名看起来是一串随机字符串。随手用ps -ef拉一下这个进程的详细信息能看到启动时间、运行用户、父进程PID。这里有个细节值得多说一句不要只看进程名。挖矿木马很多会伪装成系统进程名或者用看起来很正常的名字比如 php-fpm、kworker、java 之类所以我判断异常进程的要点是——启动时间是不是系统开机或者正常业务部署的时间点、运行用户是不是异常用户、CPU占用率是不是持续居高不下而不是只凭进程名。这一步我拿到了关键信息进程启动时间正好是三天前凌晨这个时间点没有发布、没有变更记录运行用户是www但这台机器不是Web服务器父进程是PID 1systemd典型的daemon型驻留方式实锤基本跑不掉了继续往下挖。top -c ps -ef | grep PID2.2 从进程反查文件与网络连接挖矿木马三个要素缺一不可恶意样本文件、外联矿池的网络连接、持久化机制。进程已经锁定接下来要找到它对应的文件。这个不一定要去翻目录直接用Linux的/proc文件系统就行ls -l /proc/PID/exe cat /proc/PID/cmdline lsof -p PID这里可以看到三个东西可执行文件的实际路径指向一个奇怪的路径比如/tmp/.x或/var/tmp/...命令行参数矿工程序通常有一堆参数比如指定矿池地址、钱包地址、线程数进程打开的文件列表能看到日志文件、配置文件等网络排查也是同步进行的。用netstat或ss查端口连接直接过滤这个PIDss -anop | grep PID结果就是刚才告警里提到的那个IP走的是SSH端口高位区间的一个端口。这里插一句很多挖矿木马用的外联端口不是常规80/443而是自定义高位端口千过滤的时候别只盯着常见端口看。2.3 持久化机制排查木马是怎么活下来的挖矿木马的驻留方式就那么几类但很多应急响应新手最容易漏掉的恰恰是这一环。进程杀了、文件删了结果几分钟后木马又自己起来了就是因为持久化没清干净。我排查持久化是这么做的按优先级逐个过定时任务crontab -l、/etc/crontab、/etc/cron.d/、/etc/cron.hourly/、/var/spool/cron/系统服务systemctl list-unit-files | grep enabled重点看近期修改过的service文件启动脚本/etc/rc.local、/etc/init.d/、~/.bashrc、~/.profileSSH后门~/.ssh/authorized_keys里有没有陌生的公钥结果不出所料在/etc/cron.d/里发现一个隐藏文件内容是一行定时任务每三分钟执行一次某个脚本。脚本内容我没急着看先复制存档因为这种东西是后面做溯源的关键证据。又检查了一下/root/.ssh/authorized_keys果然多了一条陌生的公钥——这属于典型的后门行为攻击者给自己留了个随时能回来的通道。这一步如果不检查光杀木马是没用的。3. 攻击入口还原这木马是怎么进来的3.1 矿机木马最常见的入侵路径处理过几次矿机事件之后你会发现攻击入口翻来覆去就那么几种对号入座就能省去大量排查时间入口类型具体途径典型特征弱口令爆破SSH、数据库、Redis等对外服务口令过于简单登录日志大量失败记录最终有成功记录未授权访问Redis空口令、Docker API暴露、Elasticsearch无认证直接可写入crontab或执行命令Web漏洞反序列化、上传漏洞、命令注入进程运行在Web应用用户下系统漏洞补丁长期未更新被已知漏洞利用通过漏洞利用工具下载样本落地这次的事件基本可以锁定为第一类——弱口令爆破。3.2 从日志里找证据我翻了/var/log/secureCentOS/RHEL系统和/var/log/auth.logDebian/Ubuntu系统的登录记录两头时间线一对情况就清楚了。在木马进程启动的那天凌晨这台机器从某个IP段发起了连续几百次SSH登录尝试用户名就是一个常见的弱口令。前面全是Failed password中间穿插着一次Accepted password for root时间跟恶意文件的创建时间几乎同步。这里建议大家排查的时候重点看这个时间交叉点成功登录的时间点恶意文件落地的时间点stat文件的 mtime/ctime挖矿进程启动的时间点三个时间点吻合就能把“入口——落地——执行”这条链还原出来。至于那个IP的地理归属和具体来源我不建议花太多精力去深挖因为挖矿木马基本都是批量扫描批量种攻击者的肉鸡也可能只是另一台被控机器溯源到这一步就够了。应急响应的重点永远是先止损、后修复而不是破案。4. 清除与恢复现场处置操作实录4.1 处置前准备先留证再动手我之前处理过几起应急事件也踩过“什么都还没留就把样本删了”的坑所以这次特意等了几分钟先把该存的东西全部打包cp /etc/cron.d/恶意文件 /root/recovery/sample_cron.txt cp /tmp/.x/挖矿程序 /root/recovery/miner_sample crontab -l /root/recovery/crontab_backup.txt ss -anop /root/recovery/network_connections.txt留证据这件事特别重要不只是为了写报告交差更实际的意义在于后续想分析这个木马的传播方式、回连地址、内部特征手里得有样本和原始数据。如果杀太快到时候想复盘就只能靠记忆了。4.2 网络隔离与外联封禁在确认这台机器不是核心业务之后我做的第一件事不是杀进程而是先切断外联。如果最后要保留样本做行为分析网络隔离是必须的前提即便是纯处置限制木马与矿池通信也能避免它继续“干活”。实操上分两步在防火墙上将外联目标IP加入黑名单在本地用iptables临时封禁该IPiptables -A OUTPUT -d 矿池IP -j DROP iptables -A INPUT -s 攻击者IP -j DROP注意这种操作是临时手段但能立刻止损。我见过有人不做隔离直接杀进程的案例结果木马在清理完后又换了端口重新连出去等于白忙。4.3 终止进程并清理文件网络隔离做完接下来才轮到杀进程。第一步先确认进程状态然后用kill结束它kill -9 PID杀掉之后稍等几秒再用top和ps确认没有自动拉起。这一步是有讲究的很多木马带了守护进程或者通过定时任务几分钟后重新拉起所以杀完进程之后至少要观察两个周期也就是定时任务执行周期的两倍确认没有复活才算初步控制住。如果出现反复拉起的情况建议直接用chattr i给恶意文件加锁或者先删除定时任务再杀进程顺序不能反。进程清理完之后就是文件清理。我把发现的恶意文件全部记录路径逐一删除rm -rf /tmp/.x rm -f /etc/cron.d/恶意文件 rm -f /usr/lib/.../... sed -i /恶意内容/d /root/.bashrc删除完之后把定时任务目录又过了一遍ls -la /etc/cron.d/把带着奇怪文件名和隐藏属性的文件全部找出来。这块真得细心很多应急响应失败就失败在只清了一半。4.4 账号与后门清理文件清理完成还有三类东西要处理第一是SSH公钥后门。直接编辑/root/.ssh/authorized_keys把陌生公钥那一行删掉。这里顺手检查了所有有home目录的用户确保不只是root被留了后门。第二是可疑系统账号。/etc/passwd、/etc/shadow都翻了一遍重点看有没有UID为0的非root账号或者最近新增的具备shell登录权限的账号。这次倒是干净没有这种问题。第三是密码整改。不管木马是不是通过弱口令进来的密码全部强制改一遍是必须的。而且这台机器用了多长时间没用过复杂密码可能连管理员自己都不清楚了。4.5 观察期别急着宣布恢复处置完成不代表可以撒手不管。我把定时任务清除、恶意文件删除、账号清理完之后没有立即交还业务而是先观察了12个小时。观察期间重点看三件事CPU使用率是否始终平稳是否还有新进程或新文件落地安全平台是否还在报外联告警我见过最尴尬的局面就是上午刚宣布处置完成下午同样的告警又来一遍。原因就是没观察够时间或者木马的备用路径没找干净。建议大家宁可把观察期拖长也不要为了赶进度提前收工。5. 溯源取证把攻击者的路径走一遍5.1 时间线重建清理完之后我把手头的信息整理成一条完整的时间线时间点事件三天前 02:15攻击者IP对SSH进行暴力破解三天前 02:43弱口令登录成功三天前 02:44恶意脚本落地到 /tmp 目录三天前 02:45下载矿工程序并设置 /etc/cron.d/ 定时任务三天前 02:46挖矿进程启动并连接矿池今天 23:10安全平台告警触发这个时间线看似简单但真正能把时间线完整还原出来的人并不多。还原的关键是不要只看单一日志而是把登录日志、文件时间戳、进程启动时间、网络连接日志几个维度对在一起交叉验证。5.2 恶意脚本的行为画像我把那个恶意脚本的完整逻辑拆了一遍。这类脚本通常干的事很固定写入一个自身标记避免被同类木马重复感染清理其他挖矿木马留下的文件和进程同行之间会互相攻击这也是挖矿木马的典型特征之一下载矿工程序并赋予可执行权限写入定时任务确保周期性拉起修改/root/.ssh/authorized_keys植入后门我手动复现了一遍它下载文件的URL路径尝试拉取了同一样本做对比。这一部分不在线描述具体域名了但方法可以分享用wget或者curl去访问同一个路径看返回值是否一致如果一致说明攻击源还在活动需要继续封堵。5.3 影响面评估单机处置结束后还有一个问题需要回答这木马是不是只感染了这台机器挖矿木马一般不太会主动做内网横向扩散相比勒索病毒它们的横向移动能力弱得多但并不意味着没有可能。我在同网段里抽查了几台服务器重点看了三方面是否有来自被感染机器的成功登录记录是否存在同样的恶意定时任务是否有外联同一个矿池IP的连接记录抽查结果正常只有这台机器本身中招。这是不幸中的万幸如果内网横传开了整个排查量会翻好几倍。6. 防复发加固从单台服务器到体系防御6.1 系统基础加固清单处置完成只是开始真正的收尾工作在这里。所有中招服务器我按下面这个清单做了一遍加固SSH服务整改禁止root直接登录PermitRootLogin no有条件就换密钥登录弱口令必须改密码策略强制长度和复杂度定期更新关闭非必要对外端口这台机器本身没有对外提供服务的需求我直接把不必要的端口全关了安装并配置主机安全Agent文件监控、进程监控、登录行为监控三件套漏洞补丁更新系统当前已知的高危漏洞补丁全部打上最小化原则卸载不需要的组件和依赖包减少攻击面这里想单独说一下SSH的处置逻辑——攻击者能进来核心原因就是弱口令。只改一个密码其实不够因为密码这种东西总有可能再次被猜中。更好的做法是直接用密钥登录彻底关掉密码认证。如果团队还没有统一的密钥管理系统至少也要把root密码禁用的规则落地。6.2 告警与监控策略调优告警为什么会到第二天才触发关键原因是挖矿进程的行为特征没有在第一时间被识别。这次告警其实是靠CPU阈值触发的说明平台之前没有部署针对外联矿池特征地址的IOC检测规则也没有针对可疑进程行为的检测模型。事后我把两条规则补上了主机外联已知恶意IP或矿池地址的实时告警参考了公开威胁情报库针对/tmp、/var/tmp目录下新增可执行文件的行为监控这里有一个经验告警规则宁可比全也不要比精。挖矿这类事件核心特征是和高频、稳定的数据源威胁情报、文件监控做关联而不是完全依赖单一设备的告警。6.3 从单点处置到批量巡检处置完一台机器后我还做了一件很重要的事把同网段、同配置的一批服务器全部拉出来做了批量巡检。这一批巡检清单包括find /tmp /var/tmp /dev/shm -name *.sh -type f -mtime -7 crontab -l cat /etc/cron.d/* ls -la /root/.ssh/authorized_keys cat /etc/passwd | grep -v /bin/false批量巡检这件事很多时候会被省略但我在实际工作中吃过亏——如果不做全网巡检第二台中招的机器可能在一周后才被发现到时候整个安全团队又要熬夜。所以这里强烈建议任何安全事件处置完毕后至少在相关网段做一轮“同因隐患排查”。7. 复盘总结命令速查与避坑心得7.1 应急处置速查表最后把这次用到的排查命令整理成一个速查表供大家直接复制使用排查目标推荐命令查看CPU高占用进程top -c/ps aux --sort-%cpu查看进程详情ps -efcat /proc/PID/cmdline查看进程落地文件ls -l /proc/PID/exelsof -p PID查看网络外联ss -anopnetstat -anop查看定时任务crontab -lcat /etc/crontabls /etc/cron.d/查看SSH后门cat /root/.ssh/authorized_keys查看异常账号cat /etc/passwdcat /etc/shadow查看系统服务systemctl list-unit-files查看登录日志grep Accepted /var/log/secure*这张表的逻辑是排查面全覆盖从进程到网络、从文件到持久化、从账号到日志。建议大家可以打印出来贴工位上或者存进自己常用的工具笔记里。7.2 这次踩过的坑第一个坑刚开始我只处理了定时任务和矿工程序直接忽略了SSH公钥后门。如果不是顺手多查了一步攻击者过几天就能重新连回来之前的工作全都白做。第二个坑清理完文件之后没有立刻做文件系统快照对比。后来想复盘木马具体改动了哪些系统文件时已经找不到原始状态了。如果条件允许建议处置前先做一次全盘hash清单比如find命令配合md5sum方便事后比对。第三个坑处置期间忘了通知业务方。虽然这台机器不是核心业务但数据平台上的临时任务还是被中断了业务同事第二天看到告警邮件才来找我。应急响应虽然是安全部门主导的事但上报和沟通不能漏。7.3 个人体会挖矿木马这种事件说难不难说简单也不简单。它不像零日漏洞利用那样需要高超的技巧更像是一次“照妖镜”把系统弱口令、补丁滞后、监控缺失、权限过大这些日常疏忽照得一清二楚。这次事件处置完我最大的感受是——应急响应拼的不是单一的技术环节而是完整的处置链条及时发现、准确判断、全面排查、干净处置、深入追溯、彻底加固。这个链条任何一个环节薄弱都可能让前面的努力白费。最后再多说一句如果你发现自己碰到的服务器也出现了CPU异常升高的情况不要慌按上面的流程一步步走先取证、再隔离、再清理、最后加固每一步都别省基本就能稳稳收住。安全这个活儿有时候考验的真的不是知识量而是能不能耐着性子把最基础的步骤做实做透。