多重跳板

企业网络的边界所在的主机，往往具有多个网络适配器，1 个面向公共网络，至少 1 个面向企业内部网络，因此在我们进入边界之后需要以此主机作为跳板，继而访问内部网络。不过，即便在企业内部也可以有多个网段，因此也会有存在着多个适配器的主机。

考虑下述可能的情况：
1：面向公网的主机 Web01 有着两张网卡，一张面向公网，一张的网段是 172.16.1.1/24。
2：内网中的一台主机 Uat01 也有着两张网卡，一张的网段是 172.16.1.1/24，另一张为 10.10.10.1/24。
除此之外，还有可能存在其他内网网段。我们可以轻松地在 Web01 的 Beacon 上运行 socks 1080，这使得我们可以通过 Socks 代理访问到 172.16.1.1/24 网段的主机。那么如果我们想访问 10.10.10.1/24 网段，该如何利用 C2 内置功能以及其他工具实现呢？

虽然在我们的靶场里，不存在第 2 个内网网段以直接供我们参考，但我们可以构造这样一个网络环境：我们的团队服务器都是搭建在 VPS 上的，并且为了保护团队服务器的安全性，暴露最少的端口在公网上。因为在任意一个 Beacon 上运行了 socks 1080 的命令，因此团队服务器是一个 Socks 服务器。但如果想从我们的 VM 上运行工具，那么即跨越了 2 层网络：个人 VM 到团队服务器，团队服务器到内网主机。

以我个人使用配置为例，我的 VM 内网网段是 192.168.0.1/24，我的 VPS 的内网网段是 172.26.5.1/24，而靶场的内网网段是 172.16.1.1/24。那么，我应该怎么做使得可以在个人主机的 VM 上使用工具并最终将流量隧道至靶场的内网主机呢？(我们这里不是为了刻意把问题复杂化，而是模拟一个多层的网络环境，考虑到靶场内只有 1 个内网段)

Socks 链

Socks + 端口转发

这是我个人偏好的方法。为了保证 VPS 的安全性，我们尽可能少地暴露端口在公网，甚至在供应商的 VPS 控制面板中配置了 IP 白名单，只允许少数 IP 访问 VPS 的特定端口，例如只有我们的个人主机才可以通过 SSH 访问 VPS。那么，我们可以将团队服务器的 Socks 端口转发到 VM 的 1080 端口，然后配合 proxychains 即可。

如果想要访问在 Dc03 上的 ADCS 网页终端，我们直接在 curl 前加上 proxychains 即可。

多重 Socks

或者，我们往 Socks 代理链中增加一环。修改 /etc/proxychains4.conf 文件的代理链

[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
 socks4  127.0.0.1 1080
 socks4  <VPS 内网段> 1080

通过 SSH 在 VM 本地配置 Socks 代理

最后，使用 proxychains curl 访问 ADCS 网页终端：

我们可以看到 127.0.0.1:1080 ... 172.26.5.81:1080 ... 172.16.1.31:80 这条代理链。

C2特性

在 CS 中，P2P Beacon 也可以协助我们实现对受到更加严格的网络隔离的主机进行控制。首先，我们需要创建这类 Beacon 的监听器。

TCP Beacon

创建 TCP 监听器 是很简单的，只有监听器名称是强制指定的，但更换端口是建议的。该监听器的载荷被执行后，并不会返回团队服务器新的会话，而是会给本机开放一个指定端口，使其成为一个 TCP 服务器，以此和其他主机进行通信。

我们将 TCP Beacon 上传到 Dc05 上。在实际情景中，我们能对这样的受害主机进行命令执行 (例如通过 WinRM，RDP 等)，但因为网络隔离的原因，并不能直接连接到团队服务器。执行后，发现 4444 端口果然开启了。

在 Web02 的 Beacon 交互中，执行命令 connect 172.16.1.51 4444，我们就能看到 Dc05 的会话出现在团队服务器上了。

需要注意的是，我们看箭头方向，是从 Web02 指向 Dc05 的，因为 Dc05 是 TCP 服务器。

SMB Beacon

创建一个 SMB 监听器同样很简单，我们只需要指定监听器名称即可，但更换命名管道的名称对特征的规避是有必要的。该监听器所对应的载荷被执行后，会给本机开启一个命名管道服务器，监听新的连接，以此和其他主机进行通信。

同样的，在 Dc05 上运行 SMB Beacon，我们依旧不会看到新的会话上线。回到 Web02 的交互中，执行 link 172.16.1.51，然后我们就能看到 Dc05 通过 SMB 监听器上线了。箭头方向依旧是从 Web02 指向 Dc05 的，因为 Dc05 是命名管道服务器。

总结一下，SMB 和 TCP 监听器，这 2 个 P2P 监听器与 HTTP/HTTPS 的不同与优势在于以下这些：

1：执行了 P2P 载荷的受害主机不与 C2 服务器直接通信，而是在受害主机之间形成一条父子关系的通信链。正因为不直接与 C2 服务器通信，从而减少 C2 通信被发现的机会。

2：一般来说，内部网络的网络控制会更宽松一些，因此可以绕过一些网络隔离限制。

3：如果开启命名管道/TCP 服务器的会话断了，连接至其的受害主机也全部失去连接。

当在受害主机 2 执行了 命名管道/TCP 监听器的载荷，我们在 C2 服务器上不会看到他们的会话，而他们会因此充当命名管道/TCP 服务器。这时候，我们在受害主机 1的 Beacon 会话中连接到它们。通信链如下图所示：

Pivot Beacon

跳板监听器，是以受害主机作为其他主机的转发器，在监听器面板中无法创建，而是选择一个受害主机，以此创建跳板监听器。

我们选择 Web02 并为其创建一个跳板监听器。

随后，我们发现 Web02 开启了 5555 端口。

在 Dc05 上执行跳板监听器的载荷，我们立刻就获得了 Dc05 的新会话。与之前的不同的是，箭头是从 Dc05 指向 Web02 的。

与 SMB/TCP 监听器有所不同的是，如果受害主机 2 执行了其载荷，会直接连接到受害主机 1，进而间接连接到 C2 服务器。通信链如下图所示：