多重跳板

企业网络的边界所在的主机，往往具有多个网络适配器，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特性

TCP Beacon

SMB Beacon

Pivot Beacon

一些 C2 框架的内置功能可以让代理变得更加得心应手，例如 CobaltStrike 的 P2P 监听器，有 TCP 监听器、SMB 监听器、 Pivot 监听器。TCP、SMB 监听器与 Pivot 监听器的方向相反，但是对于我们渗透进入更深的网段的帮助都是同样有效的。

P2P监听器允许Beacon之间将它们的通信连接起来形成一条链，在Cobalt Strike中分为TCP与SMB。连接 Beacon 在跳板、特权提升、以及任何需要额外生成一个新的Beacon的时候特别有用。如果手动在受害主机上执行P2P载荷，那么除非使用link或者connect命令，否则不会出现在UI上。

实际上，存在另外一种P2P监听器。跳板监听器与TCP监听器的工作原理相反。当生成一个TCP监听器的Beacon，Beacon作为TCP服务器并且等待连接进来的现存Beacon，即TCP客户端。跳板监听器并不在监听器菜单中创建，而是绑定在个体Beacon。现存的Beacon会绑定一个端口并且监听前来的连接，即作为TCP服务器，而使用了跳板监听器的Beacon载荷则是客户端。

为什么这很有用呢？在一些场合例如GPO的利用，我们不知道载荷何时被执行然后再使用connect命令进行连接，而当我们使用跳板监听器的话，新的Beacon会立刻显示而不用手动连接。