记一个真实的应急响应案例(2)挖矿病毒事件

admin 2023年12月4日01:13:46评论39 views字数 6559阅读21分51秒阅读模式

登录服务器时,发现密码错误,无法登录。

记一个真实的应急响应案例(2)挖矿病毒事件

打算登录云管平台重置密码,不小心看到安全告警,原来是中了挖矿病毒。

挖矿病毒的侵入性还是蛮大的,一般都会终止掉CPU占用超过20%的进程,以免计算资源不够挖矿,这常常导致正常业务被中断。

而改掉登录密码,一般是为了避免友商(其它挖矿病毒)通过口令爆破进来抢夺计算资源,这常常导致正常运维工作无法开展,也就是本文出现的情况。    

记一个真实的应急响应案例(2)挖矿病毒事件

重置密码竟然需要重启服务器,看来第一案发现场没了。

记一个真实的应急响应案例(2)挖矿病毒事件

事实证明第一案发现场确实没了,这病毒太不抗造了,一个重启就一蹶不振。

记一个真实的应急响应案例(2)挖矿病毒事件


整体排查思路


记一个真实的应急响应案例(2)挖矿病毒事件


恶意程序排查

一、网络排查

          

使用netstat -tunlap命令,未发现网络异常,没有预期的外联矿池行为、异常进程名称。

记一个真实的应急响应案例(2)挖矿病毒事件

          

二、进程排查

          

01、 网络进程排查

          

由于没有发现网络异常,因此不涉及网络相关进程排查。    

          

02、告警进程排查

          

使用ps -ef | grep和ps -ef | grep命令排查告警详情提到的进程ID和进程启动命令,并未发现异常进程。

记一个真实的应急响应案例(2)挖矿病毒事件

          

03、所有进程排查

          

使用pstree -as命令查看所有进程的名称和启动进程的命令CMD,并未发现异常进程,没有预期的名称是随机字符或与系统进程相似的进程存在。

记一个真实的应急响应案例(2)挖矿病毒事件

          

04、隐藏进程排查    

使用ps -ef | awk '{print}' | sort | uniq > 1 && ps -ef | awk '{print}' | sort | uniq > 2 && diff 1 2命令排查隐藏进程,并未发现异常进程。

记一个真实的应急响应案例(2)挖矿病毒事件

          

05、进程资源排查

          

使用top命令查看所有进程消耗资源的情况,并未发现异常进程,没有预期的CPU或MEM占用过高的进程。

记一个真实的应急响应案例(2)挖矿病毒事件

          

三、文件排查

              

01、告警文件排查

          

使用stat命令排查告警详情提到的恶意文件,并未发现异常文件。

记一个真实的应急响应案例(2)挖矿病毒事件

          

02、时间文件排查

          

使用find / -newerct命令排查告警详情提到的攻击发生时间,发现大量异常文件。

记一个真实的应急响应案例(2)挖矿病毒事件

001、/tmp/2mOsaG3ceM文件于2023-11-30 08:24:58被攻击者创建,经文件沙箱检测是恶意程序,后续需备份后删除。    

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

002、/etc/crontab文件于2023-11-30 08:25:01被攻击者篡改,添加了执行恶意程序的计划任务。后续需备份后删除计划任务/etc/crontab、备份后删除恶意程序/tmp/2mOsaG3ceM。

记一个真实的应急响应案例(2)挖矿病毒事件

003、/var/spool/cron/root文件于2023-11-30 08:25:01被攻击者篡改,添加了执行恶意程序的计划任务。后续需备份后删除计划任务/var/spool/cron/root、备份后删除恶意程序/tmp/2mOsaG3ceM。    

记一个真实的应急响应案例(2)挖矿病毒事件

004、/root/.bash_logout文件于2023-11-30 08:25:01被攻击者篡改,植入了用户退出bash时执行恶意程序的自动任务。后续需备份后删除/root/.bash_logout、备份后删除恶意程序/tmp/2mOsaG3ceM。

记一个真实的应急响应案例(2)挖矿病毒事件

005、/tmp/.opass文件于2023-11-30 08:24:58被攻击者创建,从文件名判断是密码本,一般用于解密恶意程序,后续需备份后删除。

记一个真实的应急响应案例(2)挖矿病毒事件

006、/tmp/RgX48OS6BF文件于2023-11-30 10:36:40被攻击者改过,但从atime看2023-11-30 08:24:56就被创建,经文件沙箱检测是恶意程序,后续需备份后删除。    

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

007、/root/.ssh/authorized_keys文件于2023-11-30 08:24:58被攻击者篡改,经与系统管理员(我自己)确认,该 SSH公钥是被攻击者添加的。后续需备份后删除/root/.ssh/authorized_keys。

记一个真实的应急响应案例(2)挖矿病毒事件    

008、/etc/ssh/sshd_config文件于2023-11-30 08:25:01被攻击者篡改,对比配置相同的其它正常服务器的sshd_config文件多了PubkeyAuthentication yes配置,是攻击者为了公钥登录而添加的。后续若无公钥登录需求,需删除该配置。

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

          

03、敏感目录排查

          

使用find /tmp ! -type d -exec ls -lctr --full-time {} + 2>/dev/null命令排查临时目录,未发现新的异常文件。

记一个真实的应急响应案例(2)挖矿病毒事件

使用find $HOME ! -type d -exec ls -lctr --full-time {} + 2>/dev/null命令排查家目录,未发现新的异常文件。

记一个真实的应急响应案例(2)挖矿病毒事件

          

04、特权文件排查

          

使用find / -perm 2000 2>/dev/null命令排查特权文件,未发现异常文件。

记一个真实的应急响应案例(2)挖矿病毒事件


后门排查

 

一、账户后门排查

          

01、SSH账户

          

使用cat /etc/passwd | grep -v nologin$命令排查可以登录SSH的账户,发现只有root的/bin/bash可以登录,未发现异常账户。

记一个真实的应急响应案例(2)挖矿病毒事件

使用cat /etc/passwd | awk -F: '$3==0 {print $1}'命令排查UID是0的超级权限账户,发现只有root,未发现异常账户。

记一个真实的应急响应案例(2)挖矿病毒事件

使用cat /etc/shadow | awk -F: 'length($2)>2 {print $1}'命令排查有口令的SSH账户,发现root、polkitd、chrony都有口令,经与系统管理员(我自己)确认,未启用过polkitd和chrony账户。

排查/etc/shadow的ctime,发现是云管平台重置SSH密码并重启服务器的时间。排查/etc/passwd,发现polkitd和chrony用户都无法登录。因此推断polkitd和chrony账户的SSH口令是云管平台配置的,与攻击行为无关。

记一个真实的应急响应案例(2)挖矿病毒事件

使用cat /etc/shadow | awk -F: 'length($2)==0 {print $1,$2}'命令排查空口令的SSH账户,未发现异常账户。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

02、SSH密钥

          

/root/.ssh/authorized_keys文件已在“恶意程序排查 – 文件排查”时分析过,这里不再分析。

          

二、条件后门排查

         
01、 计划任务

          

使用find /etc/*cron* ! -type d -exec ls -lctr --full-time {} + 2>/dev/null命令排查计划任务,发现/etc/crontab文件于2023-11-30 08:25:01被攻击者篡改。由于已在“恶意程序排查 – 文件排查”时分析过,这里不再分析。

记一个真实的应急响应案例(2)挖矿病毒事件

使用find /var/spool/cron -type f -exec ls -lctr --full-time {} + 2>/dev/null命令排查计划任务,发现/var/spool/cron/root文件于2023-11-30 08:25:01被攻击者篡改。由于已在“恶意程序排查 – 文件排查”时分析过,这里不再分析。

记一个真实的应急响应案例(2)挖矿病毒事件

          

02、启动项

          

使用find /etc/rc.d/ -type f -exec ls -lctr --full-time {} + 2>/dev/null命令排查启动项,发现ctime都是2019-07-11的,未发现异常。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

03、自启服务

          

使用chkconfig --list和service --status-all命令排查自启服务,未发现异常。

记一个真实的应急响应案例(2)挖矿病毒事件

          

04、命令别名

使用alias命令排查命令别名,未发现异常。

记一个真实的应急响应案例(2)挖矿病毒事件

使用find / -name *bashrc* -type f -exec ls -lctr --full-time {} + 2>/dev/null命令排查命令别名,发现ctime都是2019-07-11的,未发现异常。

记一个真实的应急响应案例(2)挖矿病毒事件


溯源排查


一、日志分析

          

01、系统日志

          

001、安全日志secure

使用cat /var/log/secure* | grep Accepted | awk '{print $11}' | sort | uniq -c | sort -nr命令,发现恶意IP地址8.219.176.16成功登录过一次SSH。

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

使用cat /var/log/secure* | grep 8.219.176.16 | grep Failed | wc -l命令,发现恶意IP地址8.219.176.16没有一次登录失败。

记一个真实的应急响应案例(2)挖矿病毒事件

使用cat /var/log/secure* | grep 8.219.176.16命令,查看恶意IP地址的登录时间,是2023-11-30 08:24:40。

记一个真实的应急响应案例(2)挖矿病毒事件

002、登录日志last系列

使用lastlog(/var/log/lastlog)查看用户最后登录系统的信息,使用w(/var/run/utmp)查看用户正在登录系统的信息,均未发现异常。    

记一个真实的应急响应案例(2)挖矿病毒事件

003、命令日志history

使用history(/root/.bash_history)命令查看历史命令,未发现攻击者使用过的命令。

          

02、中间件日志

没有运行中间件服务,不涉及中间件日志排查。

          

03、数据库日志

没有运行数据库服务,不涉及数据库日志排查。

          

04、安全设备日志

没有部署安全设备,不涉及安全产品日志排查。

          

二、流量分析

没有部署流量采集产品,不涉及流量排查。

              

三、内存分析

服务器在重置SSH密码时被重启过,内存已丢失,没有分析价值。

          

四、溯源结论

          

01、2023-11-30 08:24:40

攻击源IP地址8.219.176.16(威胁情报恶意IP、新加坡、阿里云)于2023-11-30 08:24:40登录SSH服务的root账户,没有失败登录记录,只有一次成功登录记录。

记一个真实的应急响应案例(2)挖矿病毒事件

          

02、2023-11-30 08:24:58

18秒后,攻击者于2023-11-30 08:24:58至08:25:01,上传恶意程序/tmp/2mOsaG3ceM,并为该恶意程序添加定时任务/var/spool/cron/root和/etc/crontab、添加条件任务/root/.bash_logout。

同时创建SSH密钥/root/.ssh/authorized_keys,并修改配置/etc/ssh/sshd_config允许密钥登录。

同时上传密码文件/tmp/.opass,并上传恶意程序/tmp/RgX48OS6BF(VirusTotal提示需要密码打开)。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

03、2023-11-30 08:34:25

10分钟后,攻击者执行的挖矿程序于2023-11-30 08:34:25被阿里云盾检测到。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

04、2023-12-01 09:34:24

一天后,重置SSH密码时重启了服务器,恶意进程结束后不再重启。    

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

          

工具排查

01、chkrootkit

         1. wget ftp://ftp.chkrootkit.org/pub/seg/pac/chkrootkit.tar.gz

         2. tar -zxvf chkrootkit.tar.gz

         3. cd chkrootkit-<版本>

         4. ./chkrootkit > result.txt

         5. cat result.txt | grep -v "nothing found|not infected|not found|not tested"

新发现异常文件/usr/lib/debug/usr/.dwz,但ctime是2019-07-11,且文件实际不存在。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

02、rkhunter

         1. yum -y install rkhunter

或者    

         1. 浏览器下载https://sourceforge.net/projects/rkhunter/files/latest/download

         2. tar -zxvf rkhunter-<版本>.tar.gz;

         3. cd rkhunter-<版本>

         4. ./installer.sh --install

然后

         1. rkhunter -c –sk

         2. cat /var/log/rkhunter/rkhunter.log | grep -C 2 Warning

逐个排查Warning,并未发现异常。    

记一个真实的应急响应案例(2)挖矿病毒事件

          

03、GScan

         1. git clone https://github.com/grayddq/GScan.git

         2. cd GScan

         3. python GScan.py

工具发现攻击者上传SSH密钥,之前已处置过。    

记一个真实的应急响应案例(2)挖矿病毒事件

记一个真实的应急响应案例(2)挖矿病毒事件

          

后续待办

序号

待办

原因

方法

1        

备份后删除文件:/tmp/2mOsaG3ceM、/tmp/RgX48OS6BF、/tmp/.opass。

是恶意程序

scp [email protected]:/tmp/2mOsaG3ceM C:UsersonemorethinkDesktop

rm -rf /tmp/2mOsaG3ceM

                  

scp [email protected]:/tmp/RgX48OS6BF C:UsersonemorethinkDesktop

rm -rf /tmp/RgX48OS6BF

                  

scp [email protected]:/tmp/.opass C:UsersonemorethinkDesktop

rm -rf /tmp/.opass

2        

备份后删除文件:/etc/crontab、/var/spool/cron/root、/root/.bash_logout。

启动恶意程序的定时任务和条件任务。

scp [email protected]:/etc/crontab C:UsersonemorethinkDesktop

rm -rf /etc/crontab

                  

scp [email protected]:/var/spool/cron/root C:UsersonemorethinkDesktop

rm -rf /var/spool/cron/root

                  

scp [email protected]:/root/.bash_logout C:UsersonemorethinkDesktop

rm -rf /root/.bash_logout

3

备份后删除文件:/root/.ssh/authorized_keys。

攻击者添加了SSH密钥后门

scp [email protected]:/root/.ssh/authorized_keys C:UsersonemorethinkDesktop

rm -rf /root/.ssh/authorized_keys

4

修改配置文件禁止SSH密钥登录:/etc/ssh/sshd_config。

是攻击者为了公钥登录而启用的配置。

sed -i 's/PubkeyAuthentication yes/PubkeyAuthentication no/g' /etc/ssh/sshd_config

5

修改SSH服务的root账号的密码

root账号被攻击者成功登录

passwd root

          

修改配置文件禁止SSH密钥登录时,发现/etc/ssh/sshd_config无法被修改,被添加了i属性,需要先取消i属性后才能修改。    

记一个真实的应急响应案例(2)挖矿病毒事件

排查发现,其它需要删除的文件也有部分被添加了i属性,需要先取消i属性后才能删除。

记一个真实的应急响应案例(2)挖矿病毒事件

          

其它说明

1、后面如果想练习这个环境,在自己的Linux环境执行计划任务中的命令即可。建议使用Host-Only模式(仅主机模式)的虚拟机,以避免蠕虫扩散,事态不可控时可以执行如下命令终止全部恶意进程,或者断网或关机。    

记一个真实的应急响应案例(2)挖矿病毒事件

         

2、有一个存疑的点,恶意程序的计划任务是每分钟执行一次,但实际并未生效,即时重启crond也没用,但手动执行计划任务中的命令又可以成功。

记一个真实的应急响应案例(2)挖矿病毒事件

原文始发于微信公众号(OneMoreThink):记一个真实的应急响应案例(2)挖矿病毒事件

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年12月4日01:13:46
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   记一个真实的应急响应案例(2)挖矿病毒事件https://cn-sec.com/archives/2264743.html

发表评论

匿名网友 填写信息