2023年7月14日(周五),安帝科技安服团队接到XX公司运维人员反馈,XX系统收到大量攻击事件告警通知,如下图:(告警内容:主机<*.*.1.136>存在大量扫描连接内网其它服务器的6379端口<redis>,正常情况下该主机不会向内网其它主机发送大量6379端口的连接请求。)安服人员第一时间响应客户请求,迅速进行分析研判,初步判断该主机可能已经遭受攻击。
图1:告警通知
根据天象平台告警通知内容提示,立即对目标主机(*.*.1.136)进行上机排查,发现该主机确实存在大量非正常业务的网络连接,此时基本可以判断该主机已经被攻陷。
图3:*.*.1.136通过6379扫描内网
根据恶意连接PID(17575)进一步排查该程序(或脚本)的相关信息,包括文件路径、行为动作、存储时间等,然后通过该文件的相关信息,排查在该文件落地前的历史命令,找出入口程序是Nginx还是Redis,或者其它,如果发现是哪个程序引入的,就可以对该程序的相关日志进行分析。
图4:TOP命令显示恶意程序
图5:恶意脚本路径
图6:恶意脚本内容
经过对恶意脚本进行分析,该脚本是由SystemdMiner、H2Miner两个挖矿团伙,通过组合利用PostgreSQL和Redis的未授权访问漏洞控制服务器,并写入/etc/cron.d/systemdd定时任务,执行后续恶意脚本,进行横向渗透,和下载挖矿程序并上传中毒服务器信息,完成后删除自身,从而达到控制大量主机或服务器进行挖矿操作。
图7:病毒攻击路径
针对上述病毒文件进行分析,该病毒只是后期利用的手段,并非攻击入口,要杜绝此类问题的再次发生,必须找到入侵入口。继续进一步排查发现,该服务器上还发现存在其它恶意事件——frpc代理请求(由于被攻击者均存在防火墙之后,且只开启了443端口,如果攻击想控制服务器,就需要应该类似rpc进行内网穿透工具实现反向代理),如下图:
图8:frpc代理告警
通过对DMZ区其它服务器进行上述恶意程序和IP(http://192.124.176.23/)排查,看看哪还有哪些服务器有类似事件,然后深入分析这些服务器的nginx日志、message日志、auth.log日志、cron、secure等日志,找出恶意攻击的初始入口点。
在分析*.*.1.37(https://xxxx.xxxxx.com/)服务器上的frpc程序时,发现从http://*.*.176.23下载了frp文件,通过查找该文件的存储路径,我们发现在*.*.1.37这个系统的web服务器目录下(/var/www/talent/public/uploads/annex/20200326)还包括多个可疑的php文件(php1.php、php2.php、2014.php等),因为uploads目录一般是用来存储用户上传的静态文件的,而php文件一般是攻击者用来上传webshell(webshell是黑客经常使用的一种恶意脚本,常见的webshell编写语言为asp、jsp和php等)来控制服务器的,需要进一步排查这些php文件,以及这些文件上传的路径。
图10:删除*.*.1.37病毒文件
经过分析,该系统目录的uploads路径上传文件有两种方法,一种是通过web页面的上传漏洞进入,一种是通过web服务器的其它漏洞上传进入。
通过进一步排查,发现web日志中存在如下访问记录:
对该命令进行分析发现,这是一条thinkphp框架的invokefunction RCE漏洞,它允许攻击者构造任意命令执行操作,进而控制服务器。此命令是从http://*.*.176.23下载了2014.txt的文件,然后保存在/var/www/talent/public/uploads/annex/20200326/目录下的2014.php,最后通过诸如“中国菜刀”、“冰蝎”、“蚁剑”等工具连接该服务器。类似下图:
图11:中国菜刀webshell连接示例
图12:中国菜刀webshell连接cmd示例
至此,我们已经可以肯定,该起攻击是事件是通过*.*.1.37这台服务器的web入口,利用thinkphp RCE漏洞写入WEBSHELL控制了该台服务器,然后利用PostgreSQL和Redis的未授权访问漏洞控制其它服务器,最后还在多台服务器上部署frpc程序,实现内网穿透远程控制的目的。
排查步骤如下:(因为被攻击的WEB服务器采用的是HTTPS协议,所以恶意攻击者上传的恶意文件也不能解密和识别)
-
通过分析*.*.1.136 Nginx日志,发现凌晨2-3点有异常访问的IP(*.*.232.28,*.*.192.15),但未能于此事件进行关联。 -
*.*.1.136未开启Redis日志记录功能。 -
该主机无其它对外开放端口。 -
*.*.1.37(https://xxxx.xxxx.com/)存在thinkphp RCE漏洞,导致攻击者上传了php恶意文件,进而控制服务器。随后利用其它漏洞对DMZ区其它服务器进行攻击。
根据次此DMZ区服务器中病毒事件,我们需要总结经验教训:
-
对DMZ区服务器进行漏洞扫描、补丁验证、漏洞修补;
-
针对DMZ服务器没有任何终端防护手段,我们可以通过安装万象终端管理系统,监控和管理关键文件、关键进程和访问行为的微隔离措施等;
-
因为被攻击的WEB服务器采用的是HTTPS协议,所以恶意攻击者上传的恶意文件不能解密和识别,需要将所有HTTPS的证书导致至APT设备中,实现恶意脚本检测的功能。
-
同时,由于APT的基本特性,只对已识别的告警数据进行存储,后续不能对未识别的流量进行有效的追溯,所有需要增加一台流量审计设备,对全流量进行存储,方便后续溯源审计。
-
没有哪一款杀毒软件可以杀掉所有病毒; -
没有哪一款流量审计(IDS、APT)设备可以识别所有攻击流量; -
没有哪一款防火墙防可以拦截所有的非法连接(正常端口的漏洞连接、端口复用等); -
加密数据越来越多,流量检测技术的有效性越来越小;
原文始发于微信公众号(信安404):某关键业务网络感染挖矿病毒事件应急响应处置回顾
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论