Cobalt Strike - CDN / 反向代理设置

介绍

在我上一篇博客文章Cobalt Strike - DNS 侦听器中 ，我们讨论了在 Microsoft Azure 和域名注册商 GoDaddy 的背景下在 Cobalt Strike 中设置 DNS 侦听器。DNS 侦听器当然是合理的，例如在长途服务器的背景下保持持久性，但它的缺点是 DNS 传输可能非常慢，并且不适合传输大量数据。

在本文中，我们将探讨如何在 Microsoft Azure 下的内容分发网络 (CDN) 环境中使用高信誉域，并与 C2 域和 Nginx 结合使用，作为我们红队基础设施的反向代理。接下来，我将概述所需的资源以及我们将详细介绍的主要主题。

• 选择 C2 域

• 在 Microsoft Azure 中创建并配置所需组件

• Nginx 反向代理的虚拟机

• Cobalt Strike Team 服务器的虚拟机

• 内容分发网络 (CDN)

• 配置 C2 域的 DNS

• Cobalt Strike 的配置

• Mallable Profile

• Listener

• Nginx 反向代理的配置

• 本文的目的是创建一个 C2 基础设施，允许通过 Azure CDN -> C2 域 -> Nginx 反向代理路径从目标主机上的植入物（信标）与 Cobalt Strike Team 服务器进行通信。下图以简化的形式展示了该概念。

C2 域的选择

实际上，对于我们计划的 CDN、Nginx 和 Cobalt Strike 的 C2 设置，选择一个域作为 C2 域并不是绝对必要的。但是，正如我们稍后将看到的，我们希望避免在 CDN 配置中将我们的 Nginx 反向代理的 IP 地址指定为源主机名。相反，我们倾向于在我们的 C2 域上下文中指定合法子域的 FQDN，它通过 A 记录指向我们的 Nginx 反向代理的公共 IP 地址。这乍一看可能很复杂，但随着文章的进展，它会变得更加清晰和易于理解。

但是，有几种选择可用于选择用作 C2 基础设施一部分的域名。一种是注册一个新域名并逐步建立，让它老化并建立声誉。另一方面，可以通过expireddomains.net等服务购买过期域名。在实践中，由于时间限制，通常需要购买可在红队交战期间在特定场景中使用的过期域名。

但是，在购买或注册域名之前，请确保域名足够老、信誉良好并且未被安全供应商列入黑名单。在 Azure 上创建 Nginx VM 并知道 VM 的公共 IP 后，我们将在稍后阶段处理域的 DNS 配置。

Microsoft Azure - 所需组件

为了实施我们计划的 C2 基础设施，我们需要 Microsoft Azure 中的以下组件：

• 用于 Nginx 反向代理的 Linux VM

• Cobalt Strike Team Server 的 Linux VM

• Edgio CDN 端点 

Azure - Nginx 虚拟机

第一步是创建 Linux VM，稍后它将充当 Nginx 反向代理。反向代理在命令和控制 (C2) 基础架构中起着核心作用，因为它处理传入流量并将其转发到实际的 C2 服务器。我们将在稍后的 Nginx 配置中详细解释反向代理的作用、它在 C2 上下文中的使用方式以及它与简单重定向器（例如 socat 或 iptables）的区别。

但是，首先我们将重点介绍如何在 Microsoft Azure 中创建和配置 Linux VM。

以下部分介绍如何配置虚拟机。请注意，我们仅讨论需要配置或更改的项目。

基本设置

假设我们有一个有效的 Azure 订阅，我们首先配置虚拟机 (VM) 的基本设置。我们将 VM 分配给资源组，为其命名，选择合适的区域和映像，并设置其他基本设置。下图显示了为我们的 Nginx VM 配置的基本设置。

在我上一篇文章《Cobalt Strike - DNS Listener》https://redops.at/en/blog/cobalt-strike-dns-listener，我们讨论了如何谨慎选择区域是配置中的一个关键因素。理想情况下，该区域应与目标的位置相匹配，以避免目标网络中传出的 DNS 请求出现异常。不匹配的区域可能看起来很可疑，并引起对流量的不必要的关注。

在这个 C2 配置中，我们也可以根据这个标准选择区域。但是，在这种特殊情况下，如果区域与目标位置不完全匹配，从 OPSEC 的角度来看，这并不那么重要。这是因为此架构中的 Nginx 反向代理“仅”充当 Azure 的 CDN 和 Cobalt Strike Team 服务器之间的中介，而不是信标和 Cobalt Strike Team 服务器之间的直接中介。换句话说，目标主机上的信标首先连接到 CDN。只有这样，流量才会通过原始主机名传递到 GoDaddy DNS 服务器，最后传递到 Azure Nginx 反向代理。

磁盘设置

如下图所示，我们将‘OS 磁盘类型’设置为‘标准 SSD（本地冗余存储）’。其余配置保持不变。

审查并创建虚拟机

这样就完成了我们的重定向器的 Linux VM 的配置。未列出的设置没有更改，因此未明确提及。最后一步是在构建 VM 之前验证 VM 配置。

Nginx - 配置网络设置

现在已经创建了虚拟机，我们可以继续配置网络设置。在本节中，我们将仅关注已自定义或添加的配置项。由于我们在创建虚拟机时禁用了所有传入端口，因此我们将首先调整这些设置以满足我们的需求。

如下图所示，我们将允许 SSH 访问我们的 Nginx VM，但将其限制为特定的 IP 地址。这意味着只能从这些授权的 IP 地址通过 SSH 访问 VM，从而防止未经授权的访问。

我们还为 HTTPS 连接打开端口，但与 SSH 不同，我们不会将其限制为特定的 IP 地址。这一点尤其重要，因为在红队场景中，我们通常不会提前知道目标的公共 IP 地址。将 HTTPS 访问限制为特定的 IP 地址或范围可能会导致我们的重定向器阻止来自目标的传入 HTTPS 请求，从而阻止它们正确重定向到 Cobalt Strike Team 服务器。因此，我们允许 HTTPS 请求而不受限制。

一旦完成入站规则的配置，我们将需要为 Nginx VM（在本例中为10.3.0.4）分配一个内部静态 IPv4 地址。这是必要的，以便我们稍后可以配置 Cobalt Strike VM（我们将在下一步创建）的入站规则，以便仅接受来自 Nginx VM 内部 IPv4 的传入 HTTPS 请求。重要提示：此概念要求 Nginx VM 和 Cobalt Strike VM 位于同一个虚拟网络上。

Azure 中 Nginx VM 的配置已经完成，但在我们开始在此 VM 上安装和配置 Nginx 之前，我们将首先在 Azure 中创建我们需要的其余组件，即 Cobalt Strike Team 服务器和 Edgio CDN 的 VM。

Azure-Cobalt Strike 虚拟机

Cobalt Strike Team 服务器的 VM 可以采用与 Nginx VM 相同的方式创建。我们使用相同的 Linux 映像“Debian 12 Bookworm”，基本设置的配置相同，只有传入规则的配置略有不同。

Cobalt Strike - 配置网络设置

我们还为 Cobalt Strike VM 的入站规则配置了必要的网络配置。与 Nginx VM 一样，Cobalt Strike VM 只能通过 SSH 从特定 IP 地址访问。这可确保只有授权用户才能访问 VM。

我们还开放了端口 50050，用于连接 Cobalt Strike 客户端和 Cobalt Strike 团队服务器。同样，我们将此端口的访问限制为某些 IP 地址，以确保只有授权的 IP 才能通过端口 50050 与团队服务器进行通信。

我们还允许 HTTPS 流量进入 Cobalt Strike VM，但与 Nginx VM 不同，我们将传入连接限制到某些 IP 地址。在这种情况下，我们仅允许来自 Nginx VM 内部 IPv4 地址的传入请求（在此示例中10.3.0.4为 HTTPS 上下文中）。此配置可确保我们的 Cobalt Strike Team 服务器通常仅接受来自 Nginx 反向代理的传入 HTTP 流量。

此措施通过严格限制对授权通信渠道和 IP 地址的访问、最大限度地减少攻击面并保护我们的 Cobalt Strike Team 服务器的完整性，提高了 Cobalt Strike 基础设施的安全性。

我们还为 Cobalt Strike VM 分配了一个静态 IP 地址（10.3.0.5），用于内部 IPv4，稍后将在 Nginx 配置中使用该地址。这可确保 Nginx VM 和 Cobalt Strike VM 之间的通信保持稳定且可预测，这在配置反向代理时尤为重要。

这样就完成了 Cobalt Strike VM 的基本配置。为了完成设置，我们稍后将介绍 Malleable Profile 和 Cobalt Strike Listener 的配置。

C2 域 - DNS

在我们开始在 Azure 中设置 CDN 之前，我们需要在 C2 域中创建一个 DNS 条目，该条目稍后将在 CDN 配置中用作我们的 CDN 端点指向的原始主机名。

如下图所示，我们首先为子域名选择一个名称（本例中为“docs”），该名称将与我们的 C2 域名结合使用。然后通过 A 记录将此名称指向我们的 Nginx VM 的公共 IP 地址。这可确保目标处的植入物（信标）使用源主机名通过 CDN 和 C2 域名与 Nginx VM 进行通信。

Azure - CDN 端点

下一步是在 Microsoft Azure 中创建 CDN 端点，我们将使用它来传达我们的命令和控制流量。无需过多介绍内容分发网络 (CDN) 的工作原理，只需说它们在我们的环境中起着至关重要的作用。它们允许我们使用声誉很高的 Microsoft Azure 域（例如 ajax.microsoft.com）来有效地伪装我们的命令和控制流量。

通过使用 CDN，我们可以通过受信任且常用的基础设施路由流量，从而更难检测和阻止我们的活动。这在红队场景中是一个主要优势，因为红队场景的目标是保持低调并避免可疑的互联网流量。第一步是在 Azure 中设置 CDN，如下图所示。

接下来我们需要选择一个报价并选择“标准 Edgio”选项。

下一步是对我们的 CDN 配置文件进行基本配置。与虚拟机一样，我们需要有一个有效的 Azure 订阅，并选择包含 Nginx 和 Cobalt Strike 虚拟机的资源组。CDN 的名称可以自由选择，如果尚未分配，CDN 端点名称也可以自由选择。在此示例中，我们将使用xyz-cache.azuredge.net。

我们将“来源类型”设置为“自定义来源”。在“来源主机名”下，我们输入 C2 域子域的 FQDN，该 FQDN 是我们之前在 C2 域的 DNS 中创建的，它通过 A 记录指向 Azure 上的 Nginx VM 的公共 IP。换句话说，如果我们的 C2 域名是，domain.com并且我们在 DNS 中定义了一个子域，例如“docs”，指向 Nginx VM 的公共 IP，那么在本例中我们将输入docs.domain.com“来源主机名”。

此配置可确保对 CDN 端点的所有请求都重定向到我们 C2 域的相应子域，而该子域又直接指向 Azure 中 Nginx VM 的公共 IP。通过这种方式，我们可以有效地屏蔽通过 CDN 的命令和控制流量，并确保它最终正确到达我们的 Nginx VM。

然后就可以创建我们的 CDN 端点了。部署可能需要一段时间，但几分钟内即可完成。

CDN - 配置

现在我们已经创建了 CDN，我们需要对其进行配置。第一步是在概览中选择我们的端点，在本例中xyz-cache.azureedge.net为 ，如下所示。

最后，禁用压缩并点击“保存”确认。

我们还想如下更改“缓存规则”配置，将“缓存行为”设置为“绕过缓存”，然后使用“保存”按钮确认更改的配置。

这样就完成了我们的 CDN 端点的配置。

摘要 Azure

我们在 Microsoft Azure 上的准备工作现已完成。我们已成功安装并配置了 Nginx 反向代理的 VM 和 Cobalt Strike Team 服务器的 VM。两个 VM 都有一个内部静态 IPv4 地址，位于同一个虚拟网络上，因此可以在内部相互通信。

出于安全原因，我们将两个虚拟机配置为仅允许来自特定 IP 地址的传入 SSH 连接，以便我们可以控制谁可以通过 SSH 进行连接。此外，两个虚拟机都允许传入 HTTPS 连接，我们的 Nginx VM 可以不受限制地接受 HTTPS 请求，而 Cobalt Strike VM 仅允许来自 Nginx VM 内部 IPv4 地址的传入 HTTPS 连接。

我们还在 Cobalt Strike VM 上打开了端口 50050，这是 Cobalt Strike Team 服务器和客户端之间通信所必需的。与 SSH 连接类似，我们限制了对某些 IP 地址的访问，以便精确控制谁可以通过 Cobalt Strike 客户端从哪个 IP 地址连接到团队服务器。通过这种配置，我们为 C2 基础设施的安全和受控管理奠定了坚实的基础。

Nginx - 反向代理

在下一步中，我们将通过 SSH 连接到我们的 Nginx VM，并开始安装和配置 Nginx 反向代理。但是，在深入了解配置细节之前，重要的是要了解什么是反向代理，如何在命令和控制 (C2) 流量环境中使用它，以及它与简单的重定向器（如 socat 或 iptables）有何不同。

什么是反向代理？

反向代理（在我们的例子中是 Nginx）是一种服务器，它接收来自客户端（目标处的植入物 - 信标）的请求并将其转发到后端服务器（在我们的例子中是我们的 Cobalt Strike Team 服务器）。简而言之，我们 C2 设置中的反向代理充当客户端（信标）和后端服务器（团队服务器）之间的中介，客户端不直接联系实际的后端服务器，简而言之，甚至不知道哪个服务器位于 Nginx 反向代理后面。因此，反向代理隐藏了后端服务器的身份和位置，保护它免受直接攻击。

此外，反向代理还提供了许多好处，例如通过将传入流量分布到多个后端服务器以避免拥塞来实现负载平衡。它还可以充当安全屏障，在请求到达后端服务器之前对其进行过滤并提供 SSL/TLS 终止，从而简化加密证书的管理。此外，反向代理可以缓存内容以缩短响应时间并减少后端服务器的负载。

相比之下，传统代理服务器（也称为正向代理）在客户端工作。正向代理由客户端用来向互联网发送请求，并可能过滤内容或控制访问，而反向代理位于服务器端并管理来自客户端的传入请求。因此，正向代理充当客户端的代理，而反向代理充当服务器的代理。

这一区别对于理解网络基础设施中两种代理的各自作用至关重要。正向代理在客户端进行控制，而反向代理则在服务器端实现高效、安全的流量管理。

C2 环境中的反向代理

作为我们 C2 基础设施的一部分，我们使用 Nginx 反向代理作为智能中介，将来自信标的 HTTPS 请求转发到 Cobalt Strike Team 服务器。与使用 socat 或 iptables 等简单重定向器不同，Nginx 反向代理允许在配置中定义特定条件，这些重定向器会将所有传入的 HTTPS 请求无差别地转发到 Cobalt Strike Team 服务器。

例如，使用 Nginx，我们可以指定仅将包含特定 URI 或主机标头（如 Cobalt Strike Team Mallable 配置文件中所定义）的 HTTPS 请求传递到 Cobalt Strike Team 服务器。这意味着 Nginx 反向代理能够智能地过滤传入的 HTTPS 请求。只有符合我们定义的标准且发往 Cobalt Strike Team 服务器的请求才会被实际转发。

这种方法可保护命令和控制服务器免受蓝队安全措施、自动扫描器、沙箱和其他潜在威胁的不必要访问，从而显著提高我们 C2 基础设施的安全性。通过使用 Nginx 过滤合法流量，我们为 C2 基础设施的安全性和效率做出了重大贡献。

Nginx - 设置

现在我们已经介绍了命令和控制背景下的反向代理的理论方面，我们可以继续讨论安装和配置的实际方面。

SSL 证书

在开始配置 Nginx 之前，我们将使用 Certbot 为我们的 C2 域创建一个 SSL 证书，我们将在 Nginx VM 上使用该证书。这是必要的，因为我们的 Cobalt Strike 服务器不会使用专用的 SSL 证书。

但是，由于我们的 CDN 在第 7 层（应用层）上运行，因此远程对等端（在本例中为我们的 Nginx 反向代理）必须具有有效的 SSL 证书。这可确保 CDN 服务能够与我们的代理正常通信，而不会触发安全警告。

以下 certbot 命令可用于创建 SSL 证书，其中 domain.com 必须替换为您自己的 C2 域名。

certbot certonly --manual --preferred-challenges=dns --email [email protected] --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d '*.domain.com' -d 'domain.com'

这是确保 CDN 服务能够成功访问 Nginx 实例的重要步骤，因为第 7 层通信需要有效的 SSL 证书。

在 C2 域的 DNS 中输入这两个条目后，您应该等待大约 5-10 分钟，然后按 Enter 键完成颁发 Certbot 证书的过程。这个等待时间很重要，因为 DNS 更改可能需要一些时间才能在全球范围内传播，并且新的 TXT 记录也可能需要一些时间才能完全处理。

等待时间可确保 Let's Encrypt 能够正确识别和验证 TXT 记录，以便成功完成证书颁发过程。等待时间过后，按 Enter 继续 Certbot 过程，并将颁发 C2 域的 SSL 证书。

这完成了 SSL 证书的创建，我们可以开始实际安装和配置 Nginx 反向代理。

Nginx 配置

如果 Nginx 尚未安装在 Linux VM 上，我们使用以下命令在 Ubuntu 上安装它。

apt install nginx

下一步是使用以下命令删除包含 nginx 默认配置的文件

rm /etc/nginx/sites-enabled/default

现在我们将为 Nginx 创建一个新的默认配置文件，在其中我们将配置我们的反向代理配置。

nano /etc/nginx/sites-enabled/default

对于新的默认配置，我们将使用以下参数，当然domain.com必须用您自己的 C2 域替换。在此配置中，我们定义了使用 Certbot 创建的 SSL 证书的路径。我们还使用 proxy_pass 参数来定义将有效 HTTPS 请求重定向到的 IP 地址。这是 Cobalt Strike Team 服务器的内部 IPv4 地址，由于这是 HTTPS 流量，因此我们使用端口 443。

此配置的一个重要方面是 Nginx 反向代理使用什么标准来决定传入的 HTTPS 请求是否合法并应转发到 Cobalt Strike Team 服务器。此决定是通过定义 GET 和 POST 请求的 URI 来做出的，这些 URI 随后会输入到 Cobalt Strike Malleable 配置文件中。在本例中，我们分别用于lib-8f74c3d1.min.jsGET 请求和app.7e5b9f2a.bundle.jsPOST 请求。

简单来说，这意味着当我们完成 Cobalt Strike Malleable 配置文件的配置，例如，使用配置的侦听器创建测试有效负载时，定义的 URI 也将包含在该有效负载中。当信标最终尝试通过 CDN -> DNS -> Nginx 路由连接到团队服务器时，Nginx 反向代理将识别这些 URI 为传入 HTTPS 请求的合法部分。这允许代理将请求识别为来自我们的 Cobalt Strike 信标的合法流量，并相应地将 HTTPS 流量转发到团队服务器。

这种方法可确保只有经过特殊配置的请求才会通过 Nginx 反向代理，从而在外部网络和 Cobalt Strike 团队服务器之间提供额外的安全和过滤层。

server {    listen 443 ssl default_server;           # Listen on port 443 for HTTPS as the default server for this IP.    listen [::]:443 ssl default_server;      # Listen on port 443 for HTTPS on all IPv6 addresses as the default server.    ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;  # Path to the SSL certificate file.    ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;  # Path to the SSL certificate private key file.    client_max_body_size 200M;               # Set the maximum allowed size of client request body to 200MB.    root /var/www/html;                      # Set the document root to serve files from /var/www/html.    server_name _;                           # Catch-all server block (matches any server name).    location ~ ^/(lib-8f74c3d1.min.js|app.7e5b9f2a.bundle.js) {        client_max_body_size 200M;           # Override the client body size limit to 200MB for these specific files.        proxy_pass https://10.3.0.5:443;     # Proxy requests for these files to another server at 10.3.0.5 over HTTPS.    }}

这样就完成了 Nginx 反向代理的配置。一旦我们保存并关闭默认配置文件，我们将使用以下命令确保 Nginx 在重启后自动启动。

sudo systemctl enable nginx

下一步是重新启动 Nginx 服务以确保安装并使用新的默认配置。

sudo systemctl restart nginx

最后，我们将使用以下命令来检查nginx服务是否正常运行。

sudo systemctl status nginx

如果 Nginx 服务运行正确且配置正确，我们就完成了 Nginx 反向代理的配置，可以继续配置 Cobalt Strike。

Cobalt Strike - 设置

对于 Cobalt Strike，我们需要配置两件事：在服务器端（Team Server），我们需要正确配置可调整配置文件；在客户端，我们需要正确创建 Cobalt Strike 监听器。我们将从可调整配置文件开始。

Mallable 配置文件 - 配置

Malleable 配置文件是 Cobalt Strike 的一个关键组件，它允许自定义和混淆信标的网络行为，使其看起来像是合法的网络流量，从而更难被检测到。仔细配置 Malleable 配置文件对于确保信标和团队服务器之间的通信保持谨慎和无法被安全解决方案检测到至关重要。Malleable 配置文件定义了网络通信的各个方面，例如 HTTP 标头、URI、POST 数据和信标用于与团队服务器通信的其他参数。这些自定义对于使 C2 流量看起来像是合法的网络流量是必要的，从而最大限度地降低被安全解决方案检测和阻止的可能性。

URI

GET 和 POST 请求的 URI 必须配置为与 Nginx 配置中定义的 URI 匹配。在我们的例子中，这些是 lib-8f74c3d1.min.js用于 GET 请求和 app.7e5b9f2a.bundle.jsPOST 请求的。这些 URI 不仅用于通过模仿合法的 Web 请求来伪装信标流量，而且在 Nginx 反向代理的功能中起着核心作用。代理使用这些 URI 来确定请求是否是来自信标的合法 HTTPS 请求。换句话说，只有当 URI 正确匹配时，HTTPS 流量才会从 Nginx 反向代理转发到 Cobalt Strike Team 服务器。否则，请求将不会被转发，从而提供额外的安全性并阻止来自扫描仪、机器人、蓝队等的不需要的访问。

要配置这一点，请打开适当的 Malleable 配置文件，例如webbug.profile，并在 GET 和 POST 部分添加适当的条目。GET 和 POST 的动词应该已经存在，您只需要添加 GET 和 POST 的 URI。GET 和 POST 的 URI 不同很重要，以便 Cobalt Strike 和 Nginx 可以区分这两种 HTTP 方法。在我们的示例中，我们使用 GET 的 URIlib-8f74c3d1.min.js和 POST 的 URI app.7e5b9f2a.bundle.js。这些 URI 必须与 Nginx 配置中指定的 URI 完全匹配，以确保 Nginx 反向代理正确处理流量。如果 URI 匹配，则 HTTPS 流量将被转发到 Cobalt Strike Team 服务器，否则请求将被阻止。

Host

还必须正确定义 Host 标头，以确保通过 CDN 的通信顺利进行。此标头告知 CDN 所寻址的域或子域，对于将请求正确转发到 Nginx 反向代理并最终转发到 Cobalt Strike Team 服务器至关重要。因此，有必要将参数添加Host到 GET 和 POST 请求的 Malleable 配置文件中，并将我们为 CDN 选择的端点名称指定为值。在本例中它将是xyz-cache.azureedge.net。标头的值当然必须适应您自己的 CDN 端点名称。

这样就完成了 Mallable 配置文件的配置，所示的配置可确保信标生成所需的流量，这些流量被 CDN 和 Nginx 反向代理接受并正确转发。

Cobalt Strike-监听器

最后，我们需要配置我们的 Cobalt Strike 侦听器。为此，我们创建一个 HTTPS 侦听器。在字段中Hosts，我们输入要用来隐藏 C2 流量的 CDN 域。这些域是我们之前为 CDN 配置的端点，在信标和 Cobalt Strike Team 服务器之间的通信中起着核心作用。

这完成了 Cobalt Strike 和我们的 C2 基础设施的配置，其中包括 CDN、DNS、Nginx、Cobalt Strike Team 服务器和客户端。

C2-设置-测试

最后，我们要测试 C2 配置的功能。有几种方法可以做到这一点。我们可以使用 运行测试curl，也可以使用 Cobalt Strike 创建测试有效负载，并查看 Cobalt Strike 客户端中是否打开了命令和控制连接。

第一步是使用以下curl命令测试 Nginx 是否会将我们的请求转发到 Cobalt Strike 团队服务器。该命令通过 CDN 模拟 POST 请求。仔细查看该命令，我们可以看到 CDN 域已正确指定，但 POST URI 与false_uri.js我们在 Nginx 和 Cobalt Strike 的 Malleable 配置文件中定义的 URI 不匹配。我们无论如何都要运行该命令，看看会发生什么。 

curl -X POST https://ajax.microsoft.com/false_uri.js -d test -H "host: xyz-cache.azureedge.net"

由于 URI 与 Malleable 配置文件和 Nginx 配置中定义的 URI 不匹配，Nginx 可以阻止该请求，而不会将其转发到 Cobalt Strike Team 服务器。这表明安全机制正常运行。请不要对我在本例中隐藏了主机名这一事实感到困惑，因为我在这个测试中使用了现成的设置，并且不想透露 CDN 的端点名称。

下一步是curl再次使用该命令，但这次使用我们在 Nginx 和 Malleable 配置文件中定义的正确 URI。同样，我使用的是预构建的配置，因此出于安全原因，我已将正确的 URI 像素化。此测试表明，通过路径 CDN -> DNS C2 域 -> Nginx 反向代理 -> Cobalt Strike Team 服务器成功建立了连接。

与之前使用错误 URI 的测试相比，我们现在可以看到请求被正确处理并转发到 Cobalt Strike Team 服务器。这证实了我们的 C2 基础设施配置正确并按计划运行。

此测试可确保我们的 C2 基础架构的所有组件都能正确通信，并且 Nginx 反向代理能够可靠地将合法请求路由到 Cobalt Strike 团队服务器。作为附加测试，我们可以在 HTTPS CDN 侦听器的上下文中使用 Cobalt Strike 运行有效负载，以确保从信标到团队服务器的 C2 通道正确打开。

在这种情况下，我们配置了 Nginx 和 Cobalt Strike 侦听器，以便所有通信都通过 HTTPS 进行，这使得使用 Wireshark 等工具分析流量变得困难，因为流量是加密的。但是，如果您想使用 Wireshark 更仔细地检查 C2 流量，您可以扩展 Nginx 配置以允许通过端口 80 进行未加密的流量。这将涉及在 Cobalt Strike 下设置 HTTP 侦听器并使用 HTTP 而不是 HTTPS 重复测试。这种方法允许详细分析和了解未加密的 C2 流量。

我将留给读者设置 HTTP 配置并分析未加密的流量。这是一个很好的机会来熟悉本文中的 C2 配置的工作原理。

概括

在本文中，我们介绍了一种使用 Microsoft Azure CDN、C2 域和 Nginx 反向代理为 Cobalt Strike 设置 C2 的可能方法，用于 Beacon 和 Team Server 之间的 C2 通信。设置 CDN 时，需要定义端点名称，例如 xyz-cache.azureedge.net。作为原始主机，我们定义了 C2 域子域的 FQDN，它通过 A 记录指向 Nginx 反向代理的公共 IP，例如docs.domain.com。

Nginx 反向代理已配置为通过 HTTPS 与 CDN 通信，并且仅当 GET 和 POST 的 URI 正确时才将传入的 HTTPS 请求转发到 Cobalt Strike Team 服务器。与定义的 URI 不匹配的请求将被拒绝并且不会转发到团队服务器。

此 C2 设置为高级 C2 基础架构提供了坚实的基础，该基础架构的功能超出了简单重定向器的功能，例如，socat或iptables将传入的 HTTPS 请求转发到团队服务器而不进行过滤。使用 Nginx，我们可以更好地保护我们的团队服务器免受扫描仪、机器人或蓝队的不必要访问。因此，建议选择难以猜测的 GET 和 POST URI。使用 CDN 还允许我们将 C2 流量隐藏在合法的 CDN 流量中，并使用声誉很高的域来执行我们的命令和控制流量。

我们还研究了如何配置 Malleable 配置文件，以确保通过 CDN 和 Nginx 的通信顺利进行。为了确保通过 CDN 的通信正确无误，我们添加了 GET 和 POST 的主机标头，并输入了我们的 CDN 端点名称 ( xyz-edge.azureedge.net)。为了确保 Nginx 反向代理可以正确地将来自信标的传入连接转发到团队服务器，我们在 Malleable 配置文件中为 GET ( lib-8f74c3d1.min.js) 和 POST ( app.7e5b9f2a.bundle.js) 定义了与 Nginx 配置中使用的相同的 URI。在创建每个 Cobalt Strike 有效负载时都会考虑 Malleable 配置文件配置，以便反向代理可以识别来自信标的传入 HTTPS 连接并将其正确转发到团队服务器。

总体而言，此处显示的 Cobalt Strike C2 设置由 Edgio CDN、C2 域和 Nginx 反向代理组成，通过集成多层安全性并使扫描仪、机器人、蓝队等更难以检测命令和控制流量以及 Cobalt Strike 团队服务器，为良好、安全的 C2 通信环境提供了坚实的基础。