前言

应急响应的入门尝试…..

个人觉得应急响应害挺有意思的，望各位大佬赐教

墙裂推荐：Bypass大佬的应急响应笔记

这里有两个场景用来练手，记录下来

靶机一：挖矿肉鸡的自救

场景：ubuntu上的redis服务被攻击以至于被作为挖矿用的肉鸡，对挖矿服务进行溯源清除

过程

redis服务在docker中运行

在进入docker后，正常情况下，如果中了挖矿病毒，那么第一步就是定位，查看进程运行情况

top -c

可以看到这里一直在运行/usr/share/UlordRig/ulordrig

查看定时任务，关于定时任务参考文章：

https://zhidao.baidu.com/question/1946278177198010348.html

https://blog.csdn.net/shi588266/article/details/81514689

1	cat /etc/crontab

可以看到在定时任务中将会执行/usr/share/UlordRig/ulordrig

访问/usr/share/UlordRig

因为cron服务会定期访问/var/spool/cron的文件，所以有必要查看一下

1 2	cd /var/spool/cron cat root

这个文件中将会定期执行/usr/share/mycoin，将挖到的矿，放入指定的用户账户。

查找一下config.jso

1 2	cd / find / \| grep "config.jso"

也不知道这些config.json的内容，就都查看下

这些配置文件config.json，记录了矿池地址和挖矿的账户，此时我们可以利用这些信息反打一波，比如登录矿池把对应账户的余额转走，当然最稳妥的方式还是保留证据，制作快照方便日后取证

清除挖矿服务的点有

1	删除文件/etc/crontab中的关于挖矿服务的定时任务

1	删除文件/var/spool/cron/root中的关于挖矿服务的内容

1	删除文件夹/usr/share/UlordRig

1	删除文件夹/etc/mine_srv

1	删除文件夹/usr/share/mycoin

但是当我删除了这些文件后，发现进程中依然在执行ulordrig，猜测可能是内存中的木马还未被清除掉

1 2	kill 56 删除定时任务进程 killall ulordrig 删除所有ulordrig的进程

再次查看进程和网络连接

如果还是存在可疑进程，杀掉，然后再次查看本机服务。

从redis的攻击手法来看，写shell，写定时任务，写ssh等

分别去找这些地方是否有问题，crontab里的定时任务可能就是通过redis的攻击面写入的，挖矿程序可能是通过后门用户或者后门木马等上传的。

先查看/etc/passwd以及/etc/shadow

但是当我们将此用户删掉时整个docker就关闭了，所以可见这个用户是这个docker的入口进程….

这里的root用户如果在获得shell的情况下，也是可以获取到并爆破的，并且ssh连接，姑且意淫一下，查看一下/var/log文件夹中的内容

一无所获

查看一下.ssh

注意：这个公钥文件没有不可见字符，说明不是redis写进去的，攻击者拿到权限后，再回头修改这个文件的可能性不大，所以这个时候最好的解决办法是主动联系网站管理员询问这个公钥的信息，并协助管理员更换密钥

对于redis服务的攻击，查看redis.conf

这里的redis服务对公网开放，并且使用默认端口，并且redis服务由于配置中未requirepass，使得攻击者对此有机可乘

#过滤掉危险命令
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command KEYS ""
rename-command SHUTDOWN ""
rename-command DEL ""
rename-command EVAL ""

# 禁止外网访问
bind 127.0.0.1

# 增加口令
requirepass cookie123

#更换端口
port 5353

参考文章：http://www.safe6.cn/article/39

总结

由于挖矿程序并是完好可运行的，因此绝对不是攻击者通过 redis 写进来的，所以攻击者很可能有主机的shell（而且是 root 权限的 shell）应该及时通知管理员更换登录公钥，并检查整个内网段内有无跟本机相同的口令，建议整个内网更新口令

查看/etc/passwd,有个backdoor用户的euid是0，但是删掉后整个docker都关了，这个是docker的入口进程

给redis加口令，口令长度不小于10位，并且同时有大小写数字和字母

修改redis.conf的内容

建议修改redis和ssh的默认端口

redis不要暴露在公网中

不要使用root权限启动redis

靶机二：Nginx服务器的求生之路

前言

场景：一个web服务器，目前已经被黑客攻击，对木马文件进行溯源分析和清除。

过程

这是一台Nginx的web服务器，首先我们做一下常规的检查，查看进程，查看定时任务，查看/etc/passwd等。看看有没有异常之处。

可以参考：bypass应急响应笔记

一顿寻找，暂时没有发现什么可疑的点

既然是从web服务器进行入侵的，那么我们试着从入侵者的角度进行攻击

Nginx服务器在服务器配置不正确的情况下存在目录穿越漏洞

这里的/images没有闭合，所以存在目录穿越漏洞

在www文件下，我们可以发现这里有一个backup.zip，这里存在代码泄露的问题

下一步我们就是要去寻找如何能够getshell，因为我们作为排查人员，要学会排查查看日志

我们查看nginx的access.log

这样子我们就能对攻击者所做的操作有个更清晰一点的了解

将/var/log/nginx/access.log下载到本地

这里可以看到攻击者发现了目录穿越漏洞

攻击者访问/backend/ping

攻击者应该是通过此次写入shell

继续看日志

攻击者之后访问了2.php，.shell.php

访问2.php，目录中出现.wenshell.php

1	删除.webshell.php,.shell.php

但是删除后，再次访问该目录，以及再次访问2.php后出现404

目测这是一个不死马，删除不死马，参考:如何删除不死马

1
2
3

1.sh
rm .webshell.php
mkdir .webshell.php

除了不死马以外，可能还在webshell写缓存的问题

一个是查看Nginx服务器的缓存，一个是查看框架本身的缓存文件

在后者发现了shell文件，这个靶机是使用laravel框架，查看/www/config/session.php得到session文件的存放位置

这里也只是正常的session文件

1	find /www/storage \| xargs grep "eval("

清除视图缓存文件

1	php artisan view:clear

在手动排查后之后，以防万一，使用D盾对网站源码进行扫描

第一个后门文件：

参考:https://blog.csdn.net/csacs/article/details/90640601

第二个后门文件：误报吧

第三个后门文件：写入缓存木马的触发点

其余为框架正常功能点

ping功能的过滤是使用黑名单过滤，所以将会出现绕过过滤，命令执行的问题。

总结

1.目录穿越漏洞
	修改nignx配置文件，将/images和/build/assets改成/images/和/build/assets，并重启
2.日志
    建议设置nginx记录post的数据，从而方便复现和修复漏洞
3.代码泄露
    删除/www下的backup.zip
4.后门
    删除/www/public/下的所有php木马文件
    竞争脚本删除不死马，或者重启nginx来杀不死马（如果生产环境允许）
5.命令执行代码：
    ping功能的黑名单换成正则匹配
6.laravel功能：
    建议写个计划任务定时清除缓存

后话

应急响应的时候，常规查进程，查定时任务，查网络连接等，对各类日志要足够敏感，不能放过日志的审计，在溯源过程中，思考在攻击者攻击过程中可能会利用到的攻击面，从攻击者的思路入手。不管是攻击还是防守应急，最重要的还是思路的把握，希望能有更多的大佬赐教，弟弟实在太菜了。