问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
SkidMap复杂挖矿新变种排查
安全管理
本次应急响应遇到入行以来排查过的最复杂挖矿——SkidMap。直接击穿我脆弱的知识体系，前后搞了很久才定性并清理，多亏网上前人公开的分析文章才让我能一步步溯源。故将排查内容整理出来，成为下一个前人供同行继续前进。
现象定性： ===== top 一切正常，但是 CPU 爆满：  netstat -tunp 看见一个可疑外联，但是似乎并没有建立连接，无法定位其 PID 进程，那就没法定位执行文件了：  上微步上看是恶意外联，确认中了病毒。  用 tcpdump 查看一下外联域名，涉及多个域名：c443.softgoldinformation.com、c80.softgoldinformation.com、log.softgoldinformation.com  根据威胁情报，明确是一个叫做 SkidMap 家族的挖矿病毒。  开始排查： ===== 到这里我还没意识到问题的严重性，依旧以为是普通的挖矿病毒，按照常规方式进行排查 **根据外连信息进行排查** 第一个想法，按照以往的思维通过 lsof -i:port 定位连接中的进程，但是每一次运行 netstat -tunp 时显示的端口都不一样，根据以往的经验，可能是连接并没有建立，就是所以恶意程序是由计划任务或母体程序持续拉起的，每次尝试连接后，如果失败就退出，然后换一个进程。如果成功就建立连接，然后由于互斥体的存在就只能有一个进程。  由于怀疑进程是持续重启的，通信端口转瞬即逝，所以写个批处理命令在 tcpdump 捕获到端口的同时通过 lsof -i: 或 ss 来截获并输出，但是都无所获： ```js sudo tcpdump -i any udp port 53 -n -l | \ awk '/softgoldinformation\.com/ { split($3, a, "."); ip = a[1]"."a[2]"."a[3]"."a[4]; port = a[5]; addr = ip ":" port; if (addr != "8.8.8.8:53") { sub(/:$/, "", addr); print port; system("lsof -iUDP:" port); } }' ********************************************************************** sudo tcpdump -i any udp port 53 -n -l | \ awk '/softgoldinformation\.com/ { split($3, a, "."); ip = a[1]"."a[2]"."a[3]"."a[4]; port = a[5]; addr = ip ":" port; if (addr != "8.8.8.8:53") { sub(/:$/, "", addr); print "Port: " port; system("ss -lunp | grep \":" port "\""); } }' ```  **尝试其它排查线索：** 常规排查计划任务，一无所获：  排查系统服务，也没看出个所以然：   查看 Linux “预加载库”配置文件，看是否存在内核 HOOK：包括 LD\_PRELOAD 环境变量、root 用户设置、是否被加入了全局配置、/etc/ld.so.preload 文件，结果都没有发现。  保险起见下个 rkhunter 排查一下，也没发现什么 rookit  最后用 unhide 看下有没有什么隐藏进程，发现还是没有：  至此陷入一个困境，怎么定位到发出这个 \*.softgoldinformation.com 连接的进程。 **资料收集** ======== 卡住之后就开始全网搜集资料了，把微步上的域名网页资料都点了个遍，后来发现根本不够用，网页上的博客要不就讲得太简略了，要不就排查方式对不上：  最后搜罗全网，发现微信公众号的文章比较多且质量高，列出相关文章如下： Linux | 揭秘SkidMap Rootkit复杂挖矿活动（二） <https://mp.weixin.qq.com/s/wlpZ1zfKjtA2YUspTse60w> Linux | 揭秘SkidMap Rootkit复杂挖矿活动（一） [https://mp.weixin.qq.com/s/BwIKcuVJ3VpEa0sPXhbV\\\_A](https://mp.weixin.qq.com/s/BwIKcuVJ3VpEa0sPXhbV%5C_A) 记一次挖矿病毒的溯源 <https://mp.weixin.qq.com/s/kbGSMhHm32LntUlsxpS1bw> SkidMap病毒利用Redis未授权访问漏洞攻击，数千台云主机沦为矿机 [https://mp.weixin.qq.com/s/r6ix1nubOdtA7pyUwJ\\\_4Sw](https://mp.weixin.qq.com/s/r6ix1nubOdtA7pyUwJ%5C_4Sw) Linux | SkidMap 内核态 Rootkit 取证分析 <https://mp.weixin.qq.com/s/NOSlERGuBrACP3q0S3VwfQ> Linux Rootkit对抗无从下手？LinuxAR给出答案 [https://mp.weixin.qq.com/s/nGpe5\\\_E1pw4C6rdT9dKfSQ](https://mp.weixin.qq.com/s/nGpe5%5C_E1pw4C6rdT9dKfSQ) 服务器真的没有异常吗？挖矿病毒Skidmap伪造CPU使用率 <https://mp.weixin.qq.com/s/LR6TFxPfNrQC9faAH5hEBg> 根据博客手法定性 -------- 在[安全狗威胁情报中心的博客](https://unsafe.sh/go-139148.html)中发现排查入口点是挂载点，但是执行 findmnt 时并没有文章提到的现象。  在 TahirSec 的博客[Linux | 揭秘SkidMap Rootkit复杂挖矿活动（一）](https://mp.weixin.qq.com/s/BwIKcuVJ3VpEa0sPXhbV_A) 中发现 netstat 行为一致，是本次事件相似度最高的文章了，但是它用到了深信服的 LinuxAR 工具，我并没有。  然后就懵了，也不知道是不是这篇博客上的样本逻辑，最后通读全文，测了一下 ssh，才最终确认是这篇博客写的，但是一个变种，很多行为对不上了  继续测试一下，确认 rootkit 被加载了，reviews 文件无法展示，但是用绝对路径能访问到，尝试了 busybox 也不行，当然这也是因为病毒 rootkit 做了排查工具的对抗。  如何卸载驱动？ ======= 后面操作基本按照 [Linux | 揭秘SkidMap Rootkit复杂挖矿活动（二）](https://mp.weixin.qq.com/s/wlpZ1zfKjtA2YUspTse60w) 来排查了，先是替换了系统命令 rm 为 cp，希望拦截所有删除文件的操作来得到样本进行分析，但也只拿到部分文件如 mcpuinfotest.ko 和 kmeminfotest.ko 这两个驱动文件。  释放它的母体 reviews 和 mldconfigs 死活拿不到，怀疑是没有调用系统的 rm 命令，后来也从释放得 systemdtest-udeved.xxxxx 程序也证实了调用的是 remove() 底层函数 !  systemdtest-udeved.xxxx 的执行逻辑 后来想了想既然它是开机自动释放——执行——删除的，既然拦不住它的删除操作，是否可以在它删除之前 copy 一份到别的地方呢？只要能拿到母体 reviews mldconfigs 就能拿到后面大部分文件了，于是写入如下的系统服务，后来干脆加上 rm -f 删除它使 cpu 先降低下来从而没那么卡。 ```js /usr/local/bin/clean_targets.sh #!/bin/bash while true; do cp -f /usr/bin/reviews ~/rev cp -f /usr/bin/mldconfigs ~/mld rm -f /usr/bin/reviews rm -f /usr/bin/mldconfigs done /etc/systemd/system/clean-targets.service [Unit] Description=Clean Targets Script After=network.target [Service] ExecStart=/usr/local/bin/clean_targets.sh Restart=always User=root Group=root StandardOutput=null StandardError=null [Install] WantedBy=multi-user.target ```   reviews 和 mldconfigs 分析 ======================= reviews|mldconfigs 有着同样的 hash，该变种比前面提到的文章还多替换了一个 sshd 文件，并且替换文件后时间戳对齐原始 ssh 的时间戳。这三个被替换文件的执行时机分别是：ssh——登录远程服务器时手动执行(非开机自启动)、scp——远程拷贝文件时手动执行(非开机自启动)、sshd——开启 ssh 服务时执行（开机启动）   其中 ssh 逻辑变化了一点，从原来的明文 /usr/include/olog.h 变成了 bash64 加密方式，scp 同理，其它像 sshd 的并没有细看。  重装被覆盖的文件 ```js 一、恶意 ssh 6f5eadc422f1ddfdccd2c153a18757f6 /usr/bin/ssh（恶意） 覆盖安装 ssh yum update openssh openssh-server openssh-clients yum reinstall openssh openssh-server openssh-clients 重启 ssh 服务 sudo systemctl restart sshd sudo systemctl enable sshd 二、恶意 scp b35f4dd15cd06b38b06fe11905ec09cc /usr/bin/scp 覆盖安装 yum reinstall -y openssh-clients 三、恶意 sshd 9aff2860829cfc841151eb84f7458426 /usr/sbin/sshd 覆盖安装 yum reinstall -y openssh-server ``` ### 释放的恶意驱动 mcpuinfotest.ko 和 kmeminfotest.ko 内核模块 kmeminfo.ko 和 mcpuinfotest.ko 的逻辑基本没变，分别执行隐藏和拦截操作，并且 mcpuinfo.ko 禁止运行市面上常见的监控和取证工具。  mcpuinfotest.ko  kmeminfo.ko 其它的文件在此不一一分析了，大部分样本只有少量逻辑变动，这里注重排查清理。 释放 mldconfigs|reviews 的文件溯源 =========================== 通过查看日志发现 mldconfigs|reviews 一直被释放，但其实由于驱动已经被卸载，到这里就可以用 auditd 写规则监控谁释放的 mldconfigs|reviews 了。 ```js vim /etc/audit/rules.d/backdoor\_watch.rules \-w /usr/bin/reviews -p wa -k watch\_reviews \-w /usr/bin/mldconfigs -p wa -k watch\_mldconfigs ```  通过查看 audit 的监控日志发现是 /usr/bin/selinuxdefconed (0eb093097948e2ba67f437171510bace) 释放了 mldconfigs|reviews 这两个文件，  那继续疑问，/usr/bin/selinuxdefconed 又是怎么开机启动的呢？于是继续写一个 audit 的监控任务，看看是谁启动的 selinuxdefconed： ```js \-w /usr/bin/selinuxdefconed -p x -k selinuxdefconed\_exec ```  结果发现日志里面没有明写，但是有多个执行 selinuxdefconed 的 ppid 的日志，那就查看 /var/log/audit/audit.log 中关于 /usr/bin/selinuxdefconed 执行 ppid 的信息，结果发现是 /usr/bin/kmod (f2e0a67781790abd8002cd9b6646f348) 的程序启动的，第一个猜测就是它也被篡改了。  kmod 是 Linux 系统中用于管理内核模块的工具，在加载或卸载内核模块时会被调用，特别是在开机自动加载常用驱动模块时，由此实现开机自启动调用。逆向 kmod 发现其在执行正常内核管理逻辑之后还多嵌入了一个恶意函数，其执行 /usr/bin/selinuxdefconed、/lib/x86\_64-linux-gnu/gconv/libpci.so.3.0.1、/usr/lib64/gconv/libpci.so.3.0.1 三个中的一个，通过 md5sum 查询发现其为同一个文件。   selinuxdefconed 分析 ================== 从 selinuxdefconed 中可以看到其去除了各个关键系统目录的不可变和仅追加属性，使其可写可替换，然后还替换了 /usr/bin/kmod、/usr/bin/swapon、/usr/sbin/agetty 三个文件，并释放 mldconfigs 和 agetty 核心文件。  其中 /usr/sbin/agetty 在用户ssh登录时执行，读取 /var/run/postmaped 判断是否已经执行 mldconfig 或 review，若未执行，则利用memfd或shm的方式，内存加载mldconfig 或 review。逻辑同被篡改的 tty  重装 /usr/bin/kmod、/usr/bin/swapon、/usr/sbin/agetty ```js 一、恶意 agetty 414ea833703275343a4ac7205abf6a4b /usr/sbin/agetty 覆盖安装： yum reinstall util-linux 二、恶意 kmod f2e0a67781790abd8002cd9b6646f348 /usr/bin/kmod 覆盖安装： yum reinstall -y kmod 三、恶意 swapon 81c8376ede6bbf603fc53e6586ab1a8b /usr/sbin/swapon 覆盖安装： yum reinstall -y util-linux ``` 回顾排查 ==== 拿到 selinuxdefconed 并清理重装了它后续的文件后再重启已经恢复正常了，向上应该还有释放 selinuxdefconed 的文件，但是不知道怎么找了。在 vt 上显示其父文件名为 bot，但是全局查找并没有发现该文件名，本来打算就此结束的，但是在收尾阶段整理的时候又有了新的发现。  收尾的时候在这里抽取前面未删除的文件查看一下修改日期，发现大部分是 2012-02-22 日，再用 find 命令批量查询一下这个时间的文件，得到如下列表。  其中发现一个可疑文件 libperl\_common.so.5.0，抱着怀疑的态度还是上 vt 查了md5：4968b16e23e6854f827539320efdc6b3  VT 全0，但显示的名称是 authorized\_key：authorized\_key 是 ssh 的配置文件指定哪些公钥可以用于免密码登录当前用户的 SSH 会话  但是查看 relations 发现其为 gif 的释放文件，gif 是[博客](https://mp.weixin.qq.com/s/wlpZ1zfKjtA2YUspTse60w)中通过 redis 漏洞进来的首发执行文件（b是脚本）：  libperl\_common.so.5.0 的内容如下，记录了攻击者的公钥，方便攻击者后续登录： ```js ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtNw4sDrVPO1dELkT5ag+Wa5ewywgEGC6oQJ7ugP01cUJR+6UVnx6DipvZuqWFAkA9Zm7sJUrY6K430wFv82ZNWkbJOjcf1lhl4++njRt1vxwmTheSecwlDvk5fRf6086rm2HmmdvvsUsvSaowbDD23WNXfI3rAibluVhjNmqcFfLvB5DWO8E42zkq8jk1CWdM95D/mtDzCIrxbg/azBdfsXCU1hP8JvjAgDCkelc7NIesmT6ibG4uqeNg2IWiX/M0YG8T9hWoOHJasTl+Ub+gU34Imz21l9JJ66yQtD0GtgszFJBS4AelNSrVOjHEouR9Bx6AToB515nKJ7NEvGSz root@vps1 ``` 尝试全局搜索 vt 上提到的别名，看看能不能找到点东西，发现了一个 crypted 残留下来：  其 md5 为 fbf6bb336f808d1adf037599a08ba8e0，同样扔上 vt 查看，只有阿里云一家查杀：  同样查看 Relations，只有 Dropped Files，没有 Parents 了，那这就是我目前能定位到的最初文件了。  crypted 的逻辑大差不差，除了都以 base64 解密方式获取关键字符串外，没有什么明显的变化。  查看一下[微步沙箱](https://s.threatbook.com/report/file/1a698a6c4f1c78ea5caeb43b37a8f830f102e90aa66b71c2a8f7b46ad67b2017)跑出来的进程树，基本都跑出来了，前面排查中的文件也能在里面被发现，由此结束样本排查，根据这个沙箱跑出来的结果进行系统文件替换与还原即可。  参考链接： ===== [Linux | 揭秘SkidMap Rootkit复杂挖矿活动（二）](https://mp.weixin.qq.com/s/wlpZ1zfKjtA2YUspTse60w) [Linux | 揭秘SkidMap Rootkit复杂挖矿活动（一）](https://mp.weixin.qq.com/s/BwIKcuVJ3VpEa0sPXhbV%5C_A) [记一次挖矿病毒的溯源](https://mp.weixin.qq.com/s/kbGSMhHm32LntUlsxpS1bw) [SkidMap病毒利用Redis未授权访问漏洞攻击，数千台云主机沦为矿机](https://mp.weixin.qq.com/s/r6ix1nubOdtA7pyUwJ%5C_4Sw) [Linux | SkidMap 内核态 Rootkit 取证分析](https://mp.weixin.qq.com/s/NOSlERGuBrACP3q0S3VwfQ) [Linux Rootkit对抗无从下手？LinuxAR给出答案](https://mp.weixin.qq.com/s/nGpe5%5C_E1pw4C6rdT9dKfSQ) [服务器真的没有异常吗？挖矿病毒Skidmap伪造CPU使用率](https://mp.weixin.qq.com/s/LR6TFxPfNrQC9faAH5hEBg)
发表于 2025-08-18 09:00:02
阅读 ( 289 )
分类：
应急响应
2 推荐
收藏
0 条评论
请先
登录
后评论
沐一·林
21 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
