应急响应靶机——WhereIS?
用户名及密码：zgsf/zgsf
下载资源还有个解题.exe:
1、攻击者的两个ip地址
2、flag1和flag2
3、后门程序进程名称
4、攻击者的提权方式(输入程序名称即可)
之前的命令：
1、攻击者的两个ip地址
先获得root权限，查看一下历史命令记录：
看样子攻击者在/桌面/tmp目录可能写了一个脚本upgrade.sh和对system.log文件进行了一些操作
赋予“开启环境.sh”执行权限：
但是发现upgrade.sh文件消失了
find命令查看upgrade.sh文件在哪
呃，应该是删掉了？先看看system.log文件在哪吧
find / -name 'system.log' 2>/dev/null
找到system.log的文件路径/home/.system_config/system.log
cat命令查看system.log文件内容：
看样子，第一个攻击者IP应该是192.168.31.64
本来想直接用grep命令搜索含有“192.168.31.64”的文件的内容的，但没反应：
grep -rnw '/' -e "192.168.31.64" 2>/dev/null
直接看看计划任务程序：
cat /etc/crontab
只有这一个任务计划程序，这应该是攻击者留下的恶意脚本，查看一下
很明显这是个反弹shell，通过 TCP 连接到192.168.31.64:1133并提供对系统的远程控制
攻击者第一个IP就是192.168.31.64
查看靶机IP时发现还有个docker，从这入手分析一下：
docker ps -a
可以看到容器有rabbitmq，webdav，phpadmin，think，nignx，mysql，而且只有webdav容器正在运行，其他容器都处于Exited状态，查询了一下相关资料：
其中thinkphp的漏洞风险更大，优先去排查该容器
启动think容器并查看是否成功启动：
docker start 1d1aa8b3f126
docker ps
进入think容器：
docker exec -it 1d1aa8b3f126 sh
ls -a
thinkphp框架的默认日志路径是:
ThinkPHP 5.1/6.x/7.x/8.x runtime/log/
ThinkPHP 3.x/5.0 runtime/Logs/
顺着路径下去访问，发现有个22.log：
查看22.log文件内容：
可以看到192.168.31.251进行恶意操作,执行远程命令，显示phpinfo
攻击者第二个IP就是192.168.31.251
答案：192.168.31.64和192.168.31.251
2、flag1和flag2
本来想直接
find / -name *flag*查找关键词“flag”
grep -Ern "\{[^\}]*\}" /查找关键词括号“{}”
但结果太多了，换种思路
先前history命令看到还进入了/home/.system_config目录，先去看看吧：
ls -a发现有个systemd_null文件，cat命令查看发现贼多信息，看不过来
没有头绪了，看看别人的WP，发现在/home目录下有个.system文件，cat命令查看一下找到flag：
找到第一个flag：
SYS{ZGSFYYDSadmin}
第二个flag也是找不到了，看了别人的WP才知道需要查看容器内文件变化：
最后在nginx容器里发现有个index.html和www.txt，这并不常见：
docker diff 2da3b55bd66c
启动nginx容器，并进去查看这两个文件内容：
docker start 2da3b55bd66c
docker exec -it 2da3b55bd66c sh
找到第二个flag：
zgsf{yerhawtigouhegih}
答案：SYS{ZGSFYYDSadmin}和zgsf{yerhawtigouhegih}
3、后门程序进程名称
上传whoamifuck.sh并赋予权限：
chmod 777 whoamifuck.sh
查看一下whoamifuck.sh的命令：
./whoamifuck.sh -h
查看是否存在的webshell文件：
./whoamifuck.sh -w /
发现存在一个peiqi.php文件，但感觉不是什么后门程序进程
根据先前的history命令看到的历史命令提及到system.log，觉得应该从这里入手：
这个命令是在后台启动一个system_null文件，并让它监听靶机的8899端口，同时将输出日志保存到system.log文件
但还有个就是systemd_null文件，并让它监听靶机的8896端口，同时将输出日志保存到system.log文件
猜测应该是打错文件名了，正确的应该是systemd_null文件，因为前面看到了有个systemd_null文件
用find命令各自检索一下文件名：
find / -name system_null
find / -name systemd_null
发现只有systemd_null文件的文件路径
先查看一下system.log文件内容：
这时候突然想起来这就是第一问的操作，那后门程序进程名就是systemd_null
答案：systemd_null
4、攻击者的提权方式(输入程序名称即可)
根据第一问和第二问通过docker容器获得的答案，猜测应该是通过docker来提权，直接journalctl _COMM=sudo > sudo.txt，使用systemd的系统查看sudo命令的历史，保存为sudo.txt文件
发现还有安装docker容器的命令，但还是那个问题，关键词“docker”太多了，没法确定，换种思路
经了解，攻击者获取到docker的权限之后是利用的容器逃逸进行的提权，而容器逃逸需要一定条件，去检查docker.sock是否可访问
find / -name docker.sock
发现有两个docker.sock，先看看第一个
ls -la /var/run/docker.sock
但docker.sock文件大小是0，有点奇怪，再看看另一个docker.sock文件：
发现文件大小也是0，可权限不太一样，但还是确定了通过docker提权
答案：docker
答案总结：
1、192.168.31.64和192.168.31.251
2、SYS{ZGSFYYDSadmin}和zgsf{yerhawtigouhegih}
3、systemd_null
4、docker
原来有提示6个字符啊，那大概都猜得出来是docker，成功攻克该靶机！