将 C2 放入 C2loudflare

tl;dr如何在 Azure Snapshots、Cloudflare 和 Tmux Resurrect 的帮助下在 5 分钟内启动包含所有工具及其相应重定向器的整个 C2 基础设施。

我似乎时不时会偶然发现各种想法，如果将它们结合起来，可以大大提高我的整体工作效率。这些想法中的大多数本身并不是什么新鲜事，但如果结合使用，则可以真正提高您的工作效率，这就是我在今天的帖子中想要说明的。一个很好的例子是将 Cloudflare 工作器、应用程序和隧道与 Azure VM 快照和 Tmux Resurrect 结合起来，让您可以在 5 分钟内从单个 VM 启动整个 C2 基础设施。

在 JUMPSEC，我们已经从需要分配项目时间进行基础设施设置的系统转变为在某些情况下，我们只需要在测试第一天分配 5 分钟即可完成设置。为了帮助您了解此设置可以获得的效率，以及继续阅读的价值，以下是我们利用 Azure 和 Cloudflare 的典型“第一天”基础设施设置工作流程：

• 根据我们保存的“模板”快照在 Azure 中创建磁盘（2 分钟）

• 从该磁盘创建虚拟机（2 分钟）

• 登录虚拟机并使用tmux-resurrect插件，只需按一下键即可启动我们所有的服务器（1 分钟）

就这样，您只需要花费 5 分钟的时间。我们之前保存的快照是一个及时保存的 VM，没有客户端数据，但包含我们所有的工具，包括多个 C2 服务器、Ligolo 服务器、http 服务器、Tmux Resurrect、该重定向器 URL 的预构建负载，当然还有我们将在本博客中重点介绍的 Cloudflare 连接。

关于 Tmux Resurrect，可以将其视为一种工具，如果您在单个 tmux 会话中打开了 6 个命令提示符窗格，每个窗格都有自己的 C2 服务器或 Cloudflare 连接命令在运行，它允许您保存该视图。下次启动 tmux 并发出“Ctrl-r”命令时，它会“复活”该视图，因此它将启动您保存时之前运行的所有命令，从而立即启动所有服务器。这可以节省大量时间。

按照此处的指南，从这些磁盘创建快照、磁盘和 VM 也非常简单。在您满意模板 VM 已使您的所有服务器正常运行后，使用 Tmux Resurrect 配置启动它们，您可以直接对其进行快照。显然，您可以让多个快照模板连接到不同的 Cloudflare 重定向器，以便在您的团队中扩展它，这样测试人员就不会都使用同一个 Cloudflare Worker。

从现在开始，我们将重点关注 Cloudflare 配置方面，因为这是比较棘手的方面，也是本文的重点。鉴于此过程旨在简化生活，本文将更多地使用屏幕截图而不是文字，但我认为这是人们喜欢的（或者至少我希望如此）这种类型的文章。我们试图实现的基本目标可以在下面的图表中看到，我们可以将我们的工具（无论是 Ligolo、C2 代理还是文件请求）指向单个重定向器主机名，Cloudflare Worker 将使用该请求并将其重定向到我们云 VM 上的所需位置。

无论如何，让我们开始吧。

首先，有两点值得注意。首先，用于标头、域、隧道名称等的命名约定都是为了说明目的，因此我们尽可能地使它们显而易见，但请根据自己的需要进行调整。

其次，我认为在 Azure 或 AWS 中创建虚拟机并能够通过 SSH 进入虚拟机以及从 Cloudflare 购买域名或将域名转移到 Cloudflare 是我们的读者可以管理的事情。因此，我将重点介绍图中基础设施的其余部分。

除了购买域名，Cloudflare 的设置完全免费，这是一个很棒的功能，尽管您需要在帐户上注册信用卡。还值得注意的是，许多设置都是一次性的，因此如果配置量看起来很吓人，请放心，其中大部分都是一次性的。

首先，您需要设置一个 Cloudflare 帐户，因此请前往 Cloudflare.com 并注册一个帐户。如果您从他们那里购买了域名或最近将其转让给他们，您将看到您的域名列在“网站”下，如图所示。请注意突出显示的“零信任”区域，因为这是我们接下来要去的地方。

点击您的域名后，您将看到一条重要信息，即您的“帐户 ID”。请记下此信息，因为后续将需要此信息。

现在按照之前突出显示的链接进入 Cloudflare 的“零信任”区域，我们将在这里将来自外界的各种隧道添加到我们的云虚拟机中。

进入“零信任”部分后，选择“网络”，然后选择“隧道”，然后单击“创建隧道”，这将创建一个可以在其中创建多个隧道的区域。

此时，系统将要求您创建第一个隧道或“公共主机名”。下图是我们使用的一些隧道（已删除），但只是为了让您了解，第一个“公共主机名”可能是https://sliver.yourDomain.com，任何到达该端点的 Sliver C2 数据都将通过该特定隧道路由到运行“cloudflared”的 VM，并将重定向到 https://127.0.0.1:443 上的 Sliver 侦听器。

需要指出的一点是，当您在“来源配置”下看到数字 1 时，它只是突出显示了一些额外的配置，对于 https 隧道，只需将“无 TLS 验证”切换为“已启用”即可确保数据绕过任何 TLS 检查：

现在，在您的 Cloudflare 隧道的“概览”区域中，您将获得一些需要在您的云 VM 上运行的代码，这些代码将启动隧道，调用 Cloudflare 以允许流量穿越它们。这包括您非常长的私人令牌。因此，单击您选择的操作系统，然后按照他们的说明在您的 VM 上安装他们称为“cloudflared”的 Cloudflare 隧道软件。

然后，要在您的虚拟机上启动隧道，请运行以下命令：

cloudflared tunnel run --token YourTokenHere

好的，让我们回到概览图来查看进度，我们现在已经完成了红色区域，所以我们已经完成了一半。干得好。

目前，您现在可以非常轻松地将数据发送到您的隧道中，问题是，其他人也可以这样做。对于隐蔽的红队来说，这不是一个好主意，所以我们需要为隧道增加一些保护。这就是设置的主力通过 Cloudflare 工作器发挥作用的地方。

Cloudflare Worker 带有自己的 Cloudflare URL，通常类似于 customworkername.customsubdomain.workers.dev，但也可以是您选择的域。出于演示目的，我们将其保留为众所周知的 Cloudflare Worker.dev 前缀。Worker 本质上是无服务器代码，它不断接收请求，在我们的例子中，将这些请求重定向到我们希望它们去的地方。

要创建我们的工作器，需要一些工具，并且需要部署一些代码，但这不一定需要在您的云 VM 上执行，可以从可以访问您的 Cloudflare 帐户的本地 Linux 系统上执行。

首先，如果您尚未安装它，请像这样安装 npm 包，它提供对 npx 命令的访问：

sudo apt install npm

接下来，查看我们在 Github repo 上提供的 Cloudflare 工作程序演示，该演示包含一个“src”文件夹，其中包含一个 index.js 文件（这是 Worker 用于运行的代码），它还包含一个 wrangler.toml 文件，其中包含 Worker 引用的变量：

https://github.com/JumpsecLabs/CloudflareRedirector

现在进入“CloudflareRedirector”文件夹并运行此命令来安装将工作程序部署到 Cloudflare 所需的 wrangler 文件。

npm install wrangler --save-dev

我们的文件夹中还将创建一个名为 node_modules 的文件夹和一个名为 package.json 的文件，但我们不需要关心这些。

接下来，我们需要对之前设置的 Cloudflare 帐户进行身份验证，因此发出此命令并登录 Cloudflare：

npx wrangler login

最后，在您选择的文本编辑器中打开 wrangler.toml 文件，并编辑下面用红色标出的字段，包括我们在本文开头找到的您的 accountid。URL 应与您之前设置的隧道 URL 相匹配。工作端点、customip、服务变量等可以在部署后重新调整，因此您可以保持原样。

可以在此处查看提供 Cloudflare 工作器要使用的变量的 wrangler.toml 文件。如前所述，详细的子域和标头用于演示目的，因此请进行相应调整。

填充完所有这些数据后，我们现在可以使用以下命令将 Worker 部署到 Cloudflare：

npx wrangler deploy

现在，当我们返回 Cloudflare 并转到“Workers & Pages”部分时，我们应该看到名为“redirector”的新 Worker，如下所示：

当您转到工作器的“设置”选项卡并查看变量时，您可以看到刚刚部署到 Cloudflare 的所有数据。您可以按照所示在 GUI 中编辑这些数据，但另一个部署将覆盖这些数据，因此如果预计有许多部署，您最好在 wrangler.toml 文件中进行更改并重新部署。

您还可以单击“编辑代码”，它将显示该工作人员使用的代码，该代码本质上是我们从存储库中签出的 src 文件夹中的 index.js 文件。以下只是该文件开头的片段：

此时，可能值得花一些时间来解释我们部署的工作代码如何运行。本质上，我们在开始时指定一些常量，我们将使用这些常量在传入的 http 请求中查找标头数据。我们还指定了自定义常量来存储我们通过 wrangler.toml 手动输入的值，例如 SLIVER_HEADER 的值为 MY-SLIVER。

现在，当请求进入时，工作器会通过多个“if”语句检查传入的标头值是否等于例如“MY-SLIVER”的“SLIVER_HEADER ”文本。如果匹配，我们将创建一个新请求并将其发送到链接到我们自定义 SLIVERENDPOINT 的 sliverUrl，该 SLIVERENDPOINT 应链接到 Sliver 隧道的 URL。

代码继续像这样进行其他“if”检查，例如下面这个将我们的请求重定向到我们的文件服务器。在 http 请求没有我们期望的自定义标头的情况下，代码会检查 IP 是否是我们可能希望允许进入内部文件服务器的 IP。然后我们将其重定向到指向我们内部 http 服务器的隧道。此 IP 可以在 wrangler.toml 中的 CUSTOM_IP 下或通过 Cloudflare 网站设置。

因此，在我们的案例中，我们可能有一个自定义标头，用于在我们的 VM 或 Ligolo 服务器上运行的多个 C2。但请记住，要通过 Cloudflare websockets 使用 Ligolo，您将需要 ligolo-ng 的这个分支：

https://github.com/virusvfv/ligolo-ng/tree/Websockets

无论如何，您可能还注意到，两个新的标头值（“CF-Access-Client-Id”和“CF-Access-Client-Secret”）也通过代码添加到了新请求中，但我稍后会讲到这一点。

现在您的工作器已部署，您可以在工作器的“设置”区域的“触发器”区域中查看其 URL，如下所示。在这里，您可以设置自定义域或采用 Cloudflare 提供的域。

当您决定使用哪个 URL 后，请返回并编辑 wrangler.toml 中的变量“WORKER_ENDPOINT”并重新部署它，或者通过 Cloudflare gui 自动重新部署工作者。

还值得一提的是，如果传入的请求出现任何问题，重定向器的日志记录功能会派上用场。您可以单击“日志”下的“开始日志流”，这将允许您查看进入工作器的所有请求。如果您还想查看进入隧道的请求，也可以查看隧道上的日志记录。我们认为，之前在 Cloudflare 或其他域前端设置中存在的调试可见性不足的一些缺点现在已通过所有这些出色的日志记录功能得到缓解。

再退一步来说，这就是我们现在所取得的进展，只剩下最后一块红色拼图需要完成。

我们现在有一个可以接收自定义 http 请求的 Worker，并且我们有隧道来接收请求并将其隧道传输到我们的云 VM 基础架构。我们遇到的最后一个问题是，尽管我们现在有一个将数据传送到隧道的 Worker，但隧道 URL 仍然可以被外界访问，因此我们的 Worker 可以被绕过。

为了纠正这个问题，我们需要在隧道“入口”中添加“零信任”检查，我们通过将 Cloudflare 应用程序作为入口点来实现这一点。这些应用程序还可以附加进入的先决条件，称为“策略”。通过一些进一步的屏幕截图可以更容易地解释这一点。

我们必须首先创建一个“服务令牌”，Workers 等自动化系统会使用该令牌根据我们的零信任策略进行身份验证。在 Cloudflare 零信任区域中，我们转到“访问”，然后转到“服务身份验证”，然后单击“创建服务令牌”，并提供名称和有效期。

这将为我们生成一个令牌，您的 Worker 可以使用它来访问我们的隧道所在的“零信任”区域。令牌仅在此时可见，因此请记下“CF-Access-Client-Id”和“CF-Access-Client-Secret”字段并将它们填充到您的 wrangler.toml 文件中，然后重新部署该文件或手动将它们添加到您的 Worker 的变量区域中。

现在我们的 Worker 可以使用令牌进入 Cloudflare 的零信任隧道，但我们仍然需要在隧道本身上添加对此令牌 ID 的检查。

为此，我们创建了 3 个指向 3 个隧道 URL 的应用程序，如下所示。单击“添加应用程序”并选择“自托管”：

选择名称和应用程序要链接到的隧道。因此，如果您的隧道是 sliver.mydomain.com，请在下面的编辑区域中添加这些详细信息。

接下来，我们选择使用哪些策略来允许或拒绝数据通过应用程序进入隧道。在这里，我们选择我们之前设置的 Service-Auth 访问权限，因此只有具有“CF-Access-Client-Id”和“CF-Access-Client-Secret”这两个标头值的请求才被允许访问，即只有通过我们聪明的 Worker（现在会自动添加这两个标头）的数据才能进入。这里容易犯的一个错误是没有在“操作”下拉菜单下选择“服务授权”，因此请确保选择了该选项。

当您为 Ligolo 或 C2 创建策略时，策略的其余设置可以保持不变，因此如果仅使用 C2 和 Ligolo，请完全按照上述方法创建两个应用程序。对于文件访问，添加第二个旁路策略很有用，我现在将解释原因。

如果您创建另一个名为“文件”的应用程序以允许访问您的远程文件服务器，我们可以限制仅从特定 IP 进入的请求，但我们也可以允许拥有该 IP 之外的特定电子邮件地址的特权用户直接进入文件隧道。这适用于团队可能想要访问其远程 VM 文件但不想继续向 Worker 添加多个自定义 IP 或不需要通过 wget、certutil 等进行命令行访问的情况。

为此，添加另一个名为“电子邮件”的策略，并在底部添加“包含”电子邮件选择器并输入特定的电子邮件地址，或者如果您在团队中工作，您可能希望允许所有以 mycompany.com 结尾的电子邮件地址。

接下来会发生什么呢？当你直接访问文件隧道 URL（https://files.yourdomain.com）时，绕过 Worker 重定向器的 IP 检查，你仍然可以访问它，并且你将看到如下所示的网页：

然后，您可以输入您的电子邮件地址john.doe@mycompany.com，如果该电子邮件符合政策要求，您将收到一封包含代码的电子邮件，以便通过隧道进行访问。

然后，您就可以通过浏览器访问这样的文件，这非常有用。

在此配置过程结束时，您现在应该有一堆指向您的隧道的应用程序（如图所示），它们通过策略充当它们的看门人，因此具有零信任方面：

因此，如果您还听我的，这就是我们现在通过 Cloudflare 访问云基础设施所需的全部内容。总结一下，现在一切都开始运作了：

1. 我们更新 Cloudflare，正如我所展示的，以期望我们的自定义标头值。

2. 如果我们想要从特定 IP 抓取文件，我们会更新 Cloudflare 以期望自定义 IP。

3. 我们可以生成一个带有自定义标头的 C2Ligolo 代理。因此，以 Ligolo-ng 的分支 websockets 版本为例，您可以执行以下操作：ligolosockets.exe -connect https://redirector.myname.workers.dev:443 -ua MY-LIGOLO

4. 我们将所有请求发送到 Worker 重定向器 URL，而不是直接发送到隧道，因为 Worker 将添加进入隧道所需的零信任标头值。除了通过电子邮件登录我们的文件服务器外，直接访问它们将不再有效。

5. 工作人员将请求传递给位于隧道前面的应用程序，然后该应用程序检查服务身份验证令牌以确保其匹配。

6. 如果服务身份验证令牌匹配，则请求将定向到该特定隧道。然后，该请求将流入我们的云虚拟机的内部 URL（在隧道配置中指定），以便为我们提供连接。

上述 Cloudflare 配置与 Azure 快照和 Tmux Resurrect 相结合，在快速构建红队基础设施方面是一个非常好的组合。我们希望您发现这很有用，并且我们认为，如果您想加快基础设施的创建速度，您和您的团队值得尝试这种设置。