记一个真实的应急响应案例(5)kswapd0恶意程序事件

admin 2024年1月29日21:16:24评论49 views字数 6985阅读23分17秒阅读模式

技术交流可以关注公众号 OneMoreThink 或后台添加微信,欢迎提出宝贵建议。

目录

  1. 恶意程序排查

    1. 文件排查

      1. 告警文件排查

      2. 时间文件排查

      3. 敏感目录排查

      4. 特权文件排查

    2. 网络排查

    3. 进程排查

      1. 网络进程排查

      2. 所有进程排查

      3. 隐藏进程排查

      4. 进程资源排查

  2. 后门排查

    1. 账号后门排查

      1. SSH账户

      2. SSH密钥

    2. 条件后门排查

      1. 计划任务

      2. 启动项

      3. 自启服务

      4. 命令别名

  3. 溯源排查

    1. 日志分析

      1. 系统日志

      2. 中间件日志

      3. 数据库日志

      4. 安全设备日志

    2. 流量分析

    3. 内存分析

    4. 溯源结论

  4. 后续待办

    1. 终止恶意进程

    2. 备份后删除恶意程序

    3. 修复漏洞和后门

    4. 攻击回溯与防护

2024年01月27日20时21分,收到主机安全告警,立即上机开展排查。

记一个真实的应急响应案例(5)kswapd0恶意程序事件    

1、恶意程序排查

1.1、文件排查

1.1.1、告警文件排查

01、文件

使用命令stat /tmp/.X291-unix/.rsync/a/afile /tmp/.X291-unix/.rsync/a/a确认存在告警中的恶意文件/tmp/.X291-unix/.rsync/a/a

这个环节如果定位不到告警文件,可能是被恶意程序自身删除了,此时可以基于告警时间排查其他落地文件。如果还是没有,那可能要进行内存马查杀了。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

既然告警的恶意文件是shell脚本,那就使用命令cat /tmp/.X291-unix/.rsync/a/a看下内容,发现存在清空计划任务、外联恶意IP、检测系统类型等行为,确认该shell脚本是恶意文件。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

因为告警的恶意文件的路径比较特别,使用命令find /tmp/.X291-unix/ -type f -exec ls -lctr --full-time {} + 2>/dev/null查看路径下的其他文件,发现/tmp/.X291-unix/路径下有很多恶意文件,全部都由最先落地的/tmp/.X291-unix/dota3.tar.gz解压得来,所有这些恶意文件后续都需要备份后删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

02、进程

使用命令lsof /tmp/.X291-unix/.rsync/a/a未发现与告警文件相关的进程。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

03、网络

由于未发现与告警文件相关的进程,因此也不会存在与告警文件相关的网络连接。

1.1.2、时间文件排查

使用命令find / -newerct '2024-01-27 19:21:00' ! -newerct '2024-01-27 21:21:00' ! -path '/proc/*' ! -path '/sys/*' ! -path '/run/*' -type f -exec ls -lcr --full-time {} + 2>/dev/null(备注:ls命令没用-t参数,就是按文件名排序)排查恶意程序落地前后一小时相继落地的其它文件,发现4组可疑文件。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

01、/var/log/*
使用命令less 文件名逐个查看/var/log/下的5个日志文件,其中btmp文件是二进制,需要用命令lastb -f /var/log/btmp-20240127查看。全部文件都未发现异常,可忽略。

02、/tmp/.X291-unix/.rsync/*
该目录下的文件已在1.1.1、告警文件排查中分析过,后续全部需要备份后删除。

03、/root/.configrc5/*
该目录下的文件与/tmp/.X291-unix/.rsync/*目录下的极为相似,可以判定是被copy过来的,后续全部需要备份后删除。

04、/var/tmp/.systemcache436621
使用命令cat /var/tmp/.systemcache436621发现文件内容只有一个1,没有恶意内容,可能只是用来传递信号的,可以等后续的恶意样本分析结果再决定是否删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

05、/var/spool/cron/root
攻击者创建了很多定时任务,涉及/root/.configrc5/*/tmp/.X291-unix/.rsync/*目录下的恶意文件,后续需要删除该定时任务后门、备份并删除两个目录下的恶意文件。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

06、/usr/local/qcloud/YunJing/QuaraV2/package_d01cee3bf47bbe9cd18505e4189baa2e.zip
根据路径判断是腾讯云qcloud的主机安全产品云镜YunJing的安装包,使用unzip命令解压发现已经被解压过了,是一个名为YDQuaraV2的程序。拿到微步沙箱分析,发现不是恶意文件,可忽略。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

07、/tmp/up.txt
使用cat命令查看文件内容,发现是SSH服务的帐号密码。好家伙存我帐号密码干啥,难不成干完坏事了还会给我改回去?后续需要备份后删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

08、/etc/shadow-和/etc/shadow
使用cat命令查看/etc/shadow-内容,将密码拿去CMD5[1]解密,是123456,看来这是原本的shadow文件。那就纳闷了,/etc/shadow-文件保存SSH服务的旧密码不是更好吗,为什么还搞了/tmp/up.txt。不管怎么说,虽然不是恶意文件,但因为存在弱口令,后续也备份后删除吧。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

使用cat命令查看/etc/shadow内容,将密码拿去CMD5解密,但失败了,看来攻击者改了个强口令呀,安全意识真好,真是未知攻焉知防呀。后续需要修改root用户的密码。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

09、/etc/hosts.deny
使用cat命令发现攻击者清空了/etc/hosts.deny文件,应该是怕UEBA规则检测到攻击者的爆破成功与登陆行为后自动把攻击者的IP给封禁了,这对自动化攻击程序而言是致命的。但他这个清空/etc/hosts.deny文件的动作得经常做呀,万一我UEBA动作慢了,10多分钟后才完成攻击检测与封堵呢?后续没有待办。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.1.3、敏感目录排查

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

使用find $HOME ! -type d -exec ls -lctr --full-time {} + 2>/dev/null命令排查家目录,未发现新的可疑文件。但是发现了/root/.ssh/authorized_keys在一个意外的时间被修改了,使用cat命令查看发现被植入了攻击者的SSH公钥,后续需要备份后删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.1.4、特权文件排查

使用命令find / -perm -u=s -type f -exec ls -lctr --full-time {} + 2>/dev/null命令排查特权文件,未发现可疑文件。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.2、网络排查

使用命令netstat -tunlap发现14720/httpd进程在大量连接互联网,大概率是在漏洞扫描,后续需要终止该进程。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

除此之外,使用命令netstat -tunlap | grep -v "14720/httpd" | grep -v "WAIT"还发现可疑进程19080/./kswapd0,后续需要进一步分析,同时封禁对179.43.139.84对访问,因为威胁情报告诉我们这不是个好东西。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.3、进程排查

1.3.1、网络进程排查

使用命令pstree -asp 14720 | head发现可疑进程14720/httpd的所有父进程与子进程,一共520个,后续需要全部终止。所以说,刚才1.2、网络排查时发现异常进程,不应该直接kill掉,否则你只是kill掉1个恶意进程,而错过了这里的520个恶意进程。

使用命令ls -l /proc//cwd /proc//exe查看恶意进程的启动目录和启动程序,发现全都在1.1.1、告警文件排查发现的/tmp/.X291-unix/目录下,这些恶意程序后续全部需要备份后删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

使用命令pstree -asp 19080发现可疑进程19080/./kswapd0的所有父进程与子进程,后续需要全部终止。

使用命令ls -l /proc//cwd /proc//exe查看恶意进程的启动目录和启动程序,发现全都在1.1.2.3、时间文件排查发现的/root/.configrc5/目录下,这些恶意程序后续全部需要备份后删除。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.2.2、所有进程排查

使用命令pstree -as排查所有进程,通过进程名称和进程启动命令,并未发现新的可疑进程。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.2.3、隐藏进程排查

使用命令ps -ef | awk '{print}' | sort | uniq > 1ps -ef | awk '{print}' | sort | uniq > 2diff 1 2排查隐藏进程,除了已知的恶意进程19080/./kswapd外,没有新的收获。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

1.2.4、进程资源排查

使用命令top排查所有进程消耗资源的情况,除了已知的恶意进程19080和14720把CPU快干到了200%外,没有新的收获。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2、后门排查

2.1、账号后门排查

2.1.1、SSH账户

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2.1.2、SSH密钥

特权用户的/root/.ssh/authorized_keys文件已在1.1.3、敏感目录排查分析过,普通用户未发现SSH密钥文件。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2.2、条件后门排查

2.2.1、计划任务

使用命令find /var/spool/cron/ -type f -exec ls -lctr --full-time {} + 2>/dev/null排查计划任务,发现/var/spool/cron/root文件于2024-01-27 20:41:21被攻击者篡改,已在1.1.2.5进行分析。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

使用命令find /etc/*cron* -type f -exec ls -lctr --full-time {} + 2>/dev/null排查计划任务,对于可疑的计划任务使用cat命令查看,均未发现异常。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2.2.2、启动项

使用命令find /etc/rc.d/ -type f -exec ls -lctr --full-time {} + 2>/dev/null排查启动项,对于可疑的启动项使用cat命令查看,均未发现异常。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2.2.3、自启服务

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

2.2.4、命令别名

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

使用命令find / -name *bashrc* -type f -exec ls -lctr --full-time {} + 2>/dev/null排查可以配置命令别名的配置文件,未发现异常。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

3、溯源排查

3.1、日志分析

3.1.1、系统日志

01、安全日志secure

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

微步情报确认43.139.33.6是广州的恶意IP。使用命令cat /var/log/secure* | grep 43.139.33.6 | grep Failed | wc -l发现有5次登录失败记录,使用命令cat /var/log/secure* | grep 43.139.33.6 | grep Accepted | wc -l发现有1次登陆成功记录,看来是爆破成功了。

使用命令cat /var/log/secure* | grep 43.139.33.6查看登录时间,于2024-01-27 20:20:27爆破成功登陆SSH服务,与本次挖矿事件的攻击时间完全吻合,是本次挖矿事件的始作俑者。

但是腾讯云的告警短信,却没有这个恶意IP的口令爆破并成功登陆的告警,看来腾讯云对国内的恶意IP还是很友好的啊。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件    

微步情报确认213.57.175.148是北京的恶意IP。使用命令cat /var/log/secure* | grep 213.57.175.148 | grep Failed | wc -l发现有4次登录失败记录,使用命令cat /var/log/secure* | grep 213.57.175.148 | grep Accepted | wc -l发现有1次登陆成功记录,看来是爆破成功了。

使用命令cat /var/log/secure* | grep 213.57.175.148查看登录时间,于2024-01-27 19:53:02开始爆破,7秒钟后爆破成功,但与本次挖矿事件的攻击时间不吻合,与本次挖矿事件无关。

但是他爆破成功后竟然没跑自动化脚本,难道是想人工上来内网横向然后投放勒索病毒?不管怎么说,他都应该先把SSH弱口令改了的,不然到手的服务器也不会被本次挖矿病毒的攻击者给截胡了。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

02、登录日志last系列

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

记一个真实的应急响应案例(5)kswapd0恶意程序事件

03、命令日志history

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

3.1.2、中间件日志

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

3.1.3、数据库日志

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

3.1.4、安全设备日志

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

3.2、流量分析

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

3.3、内存分析

从当前已知情况来看,没有分析的必要。

3.4、溯源结论

01、2024-01-27 20:20:27

来自广州的攻击源IP地址43.139.33.6口令爆破成功后登录了SSH服务的root账号。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

02、2024-01-27 20:20:32至20:41:22

5秒钟后,攻击者上传并执行恶意程序/tmp/.X291-unix/*/root/.configrc5/*,修改后门配置/etc/shadow/root/.ssh/authorized_keys/var/spool/cron/root,整个过程持续21分钟。

值得一提的是,/root/.ssh/authorized_keys文件的修改时间不在该时间窗口内。

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

03、2024-01-27 20:21:02

恶意程序/tmp/.X291-unix/.rsync/a/a24-01-27 20:21:00被攻击者上传,2秒钟后的20:21:02腾讯主机安全就完成了威胁检测与告警通知,不得不说这实力杠杠的。

但值得一提的是,这次攻击者释放了40多个文件,只有这一个被检测出来。

记一个真实的应急响应案例(5)kswapd0恶意程序事件    

4、后续待办

4.1、终止恶意进程

序号

待办

原因

方法

1

终止恶意进程14720/httpd

大量连接互联网,大概率是在漏洞扫描。

kill -9 14720

……

2

终止恶意进程19080/./kswapd0

外联瑞士恶意IP地址179.43.139.84,具体功能尚未分析,大概率是远控后门。

Kill -9 19089

……

记一个真实的应急响应案例(5)kswapd0恶意程序事件

记一个真实的应急响应案例(5)kswapd0恶意程序事件

4.2、备份后删除恶意程序

序号

待办

原因

方法

1

备份后删除/tmp/.X291-unix/*

大量连接互联网,大概率是在漏洞扫描。

scp -r [email protected]:/tmp/.X291-unix/ ./

rm -rf /tmp/.X291-unix/

2

备份后删除/root/.configrc5/*

外联瑞士恶意IP地址179.43.139.84,具体功能尚未分析,大概率是远控后门。        

同上。

3

备份后删除/var/tmp/.systemcache436621

可能是恶意程序用来传递信号的。

同上。

4

备份后删除/tmp/up.txt

SSH服务的帐号密码。

同上。

4.3、修复漏洞和后门

序号

待办

原因

方法

1

修改root用户密码

弱口令漏洞被攻击者获取服务器权限

passwd root

2

备份后删除/root/.ssh/authorized_keys

攻击者的后门SSH密钥

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

rm -rf /root/.ssh/authorized_keys

3

备份后修改/var/spool/cron/root

攻击者的后门定时任务

1、打开文件:vim /var/spool/cron/root

2、移动位置:上下箭头移动到恶意代码行

3、删除代码:输入dd删除恶意代码

4、退出文件::wq

4.4、攻击回溯与防护

序号

待办

原因

方法

1

防护:在边界防火墙封堵对恶意IP地址179.43.139.84的访问请求。

179.43.139.84大概率是外联的远控服务器。

查询边界防火墙的操作手册。

2

回溯:在流量侧安全设备中查询最近7日是否存在相关访问请求,若存在,还需排查请求源设备是否中了挖矿病毒。

同上。

查询流量侧安全设备的操作手册。

参考资料

[1]

CMD5: https://cmd5.com/

原文始发于微信公众号(OneMoreThink):记一个真实的应急响应案例(5)kswapd0恶意程序事件

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年1月29日21:16:24
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   记一个真实的应急响应案例(5)kswapd0恶意程序事件https://cn-sec.com/archives/2439953.html

发表评论

匿名网友 填写信息