记一次GPU服务器挖矿事件应急响应

2025-01-07 6 0

一、背景

2024年12月26日,我司收到托管机房的网络安全通报,认为我司服务器有挖矿行为,需要当天完成整改。

二、影响范围

同一内网的10台GPU服务器,版本均为ubuntu 20.04。

三、排查过程

从通报里面知道以下IP为异常IP,从这两个信息开始进行排查,查看威胁情报得知均为德国IP:

209.38.180.198:443 德国矿池

138.68.113.5:80 德国IP

3.1 进程分析

先把云安全中心高级版装上,运行全盘扫描,并且等待扫描过程中手工排查服务器,使用ss -ta命令发现服务器有和恶意IP连接

记一次GPU服务器挖矿事件应急响应插图

执行netstat -tnlpu | grep 209.38.180.198,想查看PID,结果未返回相关结果,反而过了10秒后出现阿里云告警:

怀疑netstat命令被黑客篡改,使用stat /usr/bin/netstat收集篡改时间,可以看到最后一次修改文件属性的时间是2024年9月19日 17:49。询问运维这台服务器什么时候购买的,是在几个月之前,因此基本可以推断入侵时间是在2024年9月19日左右。

为避免阿里云安全中心误报,把/usr/bin/netstat下载后丢到威胁情报进行查询,结果依然是报毒:

查看行为,有很多grep -v反向过滤矿池IP,导致无法使用netstat -tnlpu查看pid

接着阿里云不断报出了新的告警systemctl、top命令全部被篡改,基本可以确定不能继续使用系统命令进行排查

下载busybox进行应急

cd /root
wget https://www.busybox.net/downloads/binaries/1.35.0-x86_64-linux-musl/busybox
chmod u+x ./busybox
mv ./busybox /usr/bin/busybox

执行busybox top查看CPU占用最高的进程,发现存在异常进程/9ac8a281

记一次GPU服务器挖矿事件应急响应插图7

查看根目录,不存在/9ac8a281,怀疑文件已经被删掉了,恶意程序应该在内存里运行

cat /9ac8a281
cat: /9ac8a281: No such file or directory
cd /proc/4022388/
ls -al | grep exe

恶意文件/9ac8a281果然被删除了

记一次GPU服务器挖矿事件应急响应插图8

找运维从其他机器上拷贝了一个干净的systemctl到中毒机上,排查守护进程,发现异常服务63f55525.service

./systemctl list-units --type=service
 UNIT      LOAD      ACTIVE     SUB          DESCRIPTION                                                                     >
● 63f55525.service    not-found failed     failed       63f55525.service                                                                
……

执行./systemctl status 63f55525.service,看到加载恶意文件/9ac8a281

记一次GPU服务器挖矿事件应急响应插图9

查看这个守护进程的具体配置,找到恶意文件的位置/usr/bin/9ac8a28120cf5089

cat /usr/lib/systemd/system/63f55525.service

[Service]
Type=simple
User=root
TimeoutStartSec=1200
ExecStart=/usr/bin/9ac8a28120cf5089 9ac8a281

Restart=always
RestartSec=4h
KillMode=process

## 全局查找是否还有恶意文件
find / -name "9ac8a28*"

查看开机启动项、定时任务、系统账号、挂载,无异常

cat /var/spool/cron/crontabs
cat /etc/passwd
df -h
cat /proc/mounts
cat /etc/rc.local
cat: /etc/rc.local: No such file or directory
(base) root@gpua15:/var/spool/cron/crontabs# systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: inactive (dead)
       Docs: man:systemd-rc-local-generator(8)

使用unhide工具检查隐藏进程,发现上百个隐藏进程

apt install unhide
unhide proc

Used options: 
[*]Searching for Hidden processes through /proc stat scanning

Found HIDDEN PID: 5043
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 5044
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 5045
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 5046
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 5047
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 5048
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 6461
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/

Found HIDDEN PID: 6462
        Cmdline: "/9ac8a281"
        Executable: "/9ac8a281 (deleted)"
        Command: "9ac8a281"
        $USER=root
        $PWD=/
…………

3.2 遏制过程

##杀掉恶意进程
kill -9 4022388
kill -9 6462   #删除1个恶意隐藏进程后,其他也会消失,原理未知

##删除守护进程
./systemctl stop 63f55525.service
./systemctl disable 63f55525.service
rm -rf /usr/bin/9ac8a28120cf5089

重复3.1 进程分析步骤,未发现有新的恶意进程启动,服务器暂时恢复正常

3.3 恢复过程

1.删除后门,查看云安全中心,发现有异常可执行文件/etc/ssh/ssh_host_dsa_key.pub
记一次GPU服务器挖矿事件应急响应插图10

丢沙箱查看,是一个后门

记一次GPU服务器挖矿事件应急响应插图11

ping example.servidor.world,解析出来IP是138.68.113.5,跟通报文件里的恶意IP吻合,从情报和行为可以判断这是远控服务器的IP,而且可以看到还有另外一个远控IP 185.125.188.58

记一次GPU服务器挖矿事件应急响应插图12

清理后门,发现被锁定了,无法删除、移动、改权限,可以判断攻击者用chattr锁定了文件

记一次GPU服务器挖矿事件应急响应插图13

使用chattr -ia /etc/ssh/ssh_host_dsa_key.pub解锁,结果报错不存在该命令,提示让我使用vmlinux1来代替chattr执行(此处漏了截图),由于怕中毒,不敢用vmlinux1命令

下载/usr/bin/vmlinux1,上传到沙箱,结果为正常文件,但保守起见还是不敢用vmlinux1来代替chattr命令

记一次GPU服务器挖矿事件应急响应插图14

使用lsattr /etc/ssh/ssh_host_dsa_key.pub命令查看,结果lsattr命令也被黑客删除了

从干净的服务器上下载chattr和lsattr文件,上传到中毒服务器,再用lsattr查看,果然后门文件是被锁定了禁止变更

chmod +x ./chattr
chmod +x ./lsattr
mv ./lsattr /usr/bin
mv ./chattr /usr/bin
lsattr /etc/ssh/ssh_host_dsa_key.pub

记一次GPU服务器挖矿事件应急响应插图15

解锁并删除vmlinux1和后门文件

chattr -ia /usr/bin/vmlinux1
chattr -ia /etc/ssh/ssh_host_dsa_key.pub
rm -rf /usr/bin/vmlinux1
rm -rf /etc/ssh/ssh_host_dsa_key.pub

2.  恢复系统命令

根据云安全中心的扫描结果,得出以下文件均被替换

/usr/bin/uptime
/usr/bin/netstat
/usr/bin/top
/usr/bin/systemctl
/bin/systemctl
/sbin/runlevel

从干净的服务器上下载如上命令文件,打包并上传到中毒服务器进行替换即可

unzip 1.zip
cd 1
chattr -ia /usr/bin/netstat
chattr -ia /usr/bin/top
chattr -ia /usr/bin/uptime
chattr -ia /bin/systemctl
chattr -ia /usr/bin/systemctl
rm -rf /usr/bin/netstat
rm -rf /usr/bin/top
rm -rf /usr/bin/uptime
rm -rf /sbin/runlevel
rm -rf /bin/systemctl
rm -rf /usr/bin/systemctl
cp /root/1/netstat /usr/bin
cp /root/1/top /usr/bin
cp /root/1/uptime /usr/bin
chmod u+x /usr/bin/netstat
chmod u+x /usr/bin/top
chmod u+x /usr/bin/uptime
cp /root/1/systemctl /bin
cp /root/1/systemctl /usr/bin
chmod u+x /usr/bin/systemctl
chmod u+x /bin/systemctl
ln -s /bin/systemctl /sbin/runlevel

3.再次复检

  1. 运行云安全中心,并且再次执行unhide proc进行检查,无任何异常,基本可确定已完成恢复。

  2. 让托管机房监控网络防火墙日志,若还有告警则及时告知。

四、入侵分析

  1. 询问托管机房的网络边界防火墙管理员,确认本地服务器无web端口映射到公网。

  2. 查看进程,发现有frp记一次GPU服务器挖矿事件应急响应插图16逐个端口访问进行检查,发现一个jupyter server登陆界面。Jupyter Notebook是基于网页的用于交互计算的应用程序。其可被应用于全过程计算:开发、文档编写、运行代码和展示结果。jupyter_server主要提供后台接口服务,前端应用和后台通信的主要接口,都在jupyter_server中。记一次GPU服务器挖矿事件应急响应插图17查看了版本后,网上查找是否该版本存在高危漏洞,未找到有用的信息。登陆服务器查找jupyter的登陆日志,结果安装该应用时未开启日志配置,只能放弃。
  3. 查看syslog和auth日志,发现存在大量ssh登陆失败日志,且用户名也不是我司员工姓名拼音,所以用户名应该是字典生成
    记一次GPU服务器挖矿事件应急响应插图18记一次GPU服务器挖矿事件应急响应插图19如果说是来自机房内网的SSH爆破导致的入侵,那为什么日志显示的IP是127.0.0.1呢?只能说这个日志很可疑,但无法实锤。
    由于没有保存9月19日左右的日志,很难继续找下去,只能放弃。
  4. cat /root/.ssh/authorized_keys文件,发现内网10台服务器的SSH公钥都加进去了,检查另外9台服务器,也是同样情况,这个作用是让这10台服务器可以互相免密使用root登录。经过验证,的确如此,这是后门维持权限的常用手法。

    记一次GPU服务器挖矿事件应急响应插图20

  5. 内网执行一次弱口令扫描,发现有5台服务器root存在弱口令。
  6. 继续查看网络防火墙日志,发现有2台服务器外联阿里云OSS的异常流量,询问研发,GPU服务器是要从OSS上拉取文件来进行训练,也就是说OSS里可能有病毒文件。
    记一次GPU服务器挖矿事件应急响应插图21

综合以上信息的,只能推断出本次事件的2种可能入侵路径,但是缺乏实锤证据:

  1. 攻击者通过托管机房内网其他中毒机器进行了横向移动,并通过弱口令爆破获得了我们其中几台服务器的权限,之后进一步扩大战果。
  2. 研发拉取OSS上的恶意文件后,可能不小心触发了后门/恶意可执行文件,导致服务器直接被控制。

五、经验小结

  1. 209.38.180.198:443是矿池,138.68.113.5:80 是黑客远控服务器,入侵时间是2024年9月19日 17:49之前。

  2. 在排查过程中有一点小小的运气成分,在GPUa15服务器上busybox top一下子就找到挖矿进程和PID了,而其他9台是偶发性的一直不出现。如果没有这个信息作为突破口,遏制过程不会这么顺利。

  3. 使用clamAV扫描以上恶意文件,结果是检测不出来,说明免费的linux杀毒软件能力有限。应急过程还是尽量别用免费的杀软,否则会被误导。

  4. 由于这批服务器是缺乏监控、日志和安全软件的,加上入侵时间比较早,导致现在难以进行入侵溯源分析,只能完成应急。结合第3点,个人建议安全建设初级阶段的企业,在预算有限的情况下,一定要把资源优先投入到基础设施中去(日志平台、FW、HIDS等),千万不要去追热点、追新技术和新概念。
  5. 企业在建设AI的过程中,一定要有安全意识,需要对训练用到的工具、应用软件、数据进行安全检测和充分的安全评估。

六、IOCs

IP和域名:
209.38.180.198:443
138.68.113.5:80
185.125.188.58
example.servidor.world

恶意文件sha256:
0b4322e157d7880c7b5c516e8511bb9ba44634d44d67ced757669cb6da3db45b
9f514a5486a1be365462790a119df48903235b8082df6bf478845a284faa6313
430337634977213389160c6b9287b0a10aac176ec1c7a74579f0331275a564f6
6f3e8b92ec45372aa64ba9d1873039067002fb84f2c51972b51102edcfd5244a
0f7364dad4c409d48eef8f9c1c29f3a2966ee1c1b5679e5a4692ad6c108bf731
430337634977213389160c6b9287b0a10aac176ec1c7a74579f0331275a564f6


4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途,否则一切后果请用户自负。

本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序,请支持正版,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解!

程序来源网络,不确保不包含木马病毒等危险内容,请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱:4ablog168#gmail.com(#换成@)

相关文章

JAVA安全 | 初探反射反序列化
2024年软件系统安全赛攻防赛web题CachedVisitor题解
企业防线的薄弱环节:深入了解供应链网络攻击的风险
震惊!?DLP还能这样用
展望网络安全前沿:2025年的关键预测
XSS漏洞很难发现吗???

发布评论