Cobalt Strike - DNS 监听器

这篇博文的目的是逐步记录如何在 Cobalt Strike（4.0 或更高版本）中与域名注册商（例如 GoDaddy）和 Microsoft Azure 云平台结合创建和配置 DNS 侦听器。在我研究这个主题的过程中，我发现的信息很少，所以我想借此机会记录这个过程并与其他人分享。

介绍

与其他命令和控制 (C2) 框架一样，Cobalt Strike 允许您创建不同类型的侦听器。最常见的选项包括通过 HTTP、HTTPS、DNS、SMB、TCP 等进行通信的侦听器。

SMB 和 TCP 侦听器通常用于后利用阶段，尤其是在初始访问之后的横向移动。相比之下，HTTP、HTTPS 或 DNS 变体通常用于获取对目标网络的初始访问权限或保持持久性。这些通信通道特别适合与目标系统进行初始接触并建立初始连接。

DNS 侦听器在此扮演着特殊角色，因为它们通常用作“长途服务器”，以确保网络或域的长期持久性。这使得它们成为持续运营的重要组件，在这些运营中，保持不被注意并永久存在于网络上至关重要。

在本文中，我们将详细介绍在 Microsoft Azure 和 GoDaddy 环境中使用 Cobalt Strike（版本 4.0 及更高版本）的 DNS 侦听器的可能设置的设置和配置。以下是我们将详细介绍的各个步骤的概述：

为什么 C2 流量要通过 DNS？

• C2域的选择标准

• 在 Azure 中创建和配置重定向器 VM

• 在 Azure 中创建和配置 Cobalt Strike VM

• GoDaddy 中的 DNS 配置

• 在 Cobalt Strike 中配置 DNS 侦听器

• 测试 DNS 侦听器

下图显示了本文中描述的在 Cobalt Strike 中使用 DNS 侦听器的概念的简化版本。它显示了由接收和转发 DNS 查询的重定向器 VM 和处理查询并用于 C2 通信的 Cobalt Strike VM 组成的基本架构。该图旨在帮助直观地了解不同组件之间的关系及其在整体概念中的功能。

DNS 监听器 - 为什么？

与 HTTP 或 HTTPS 侦听器相比，DNS 侦听器具有许多优势和特定用例，尤其是在伪装和网络持久性方面。下面列出了一些重要优势：

• 隐身和防火墙规避：

DNS 请求在许多网络上被视为合法流量，因此通常不会像 HTTP 或 HTTPS 流量那样受到密切监控。因此，DNS 侦听器可以帮助绕过防火墙或入侵检测/预防系统 (IDS/IPS) 等安全措施。

• 持久性和长期通信：

DNS 侦听器对于长期操作特别有用，因为 DNS 查询通常可以在网络上长时间不被察觉。这使得 DNS 侦听器成为维护网络或域持久性的理想选择。

• 处理受限网络：

在 HTTP/HTTPS 流量被阻止或密切监控的高度受限或监控网络中，DNS 可用作替代通信方法。由于几乎所有地方都必须允许 DNS 请求，因此 DNS 侦听器即使在这样的环境中也能实现通信。

• 域名信誉：

使用信誉良好的域名作为 DNS 侦听器可增加 DNS 查询保持无可疑性并不会被阻止或更严格审查的可能性。受信任的域名可以帮助绕过安全解决方案，例如内容过滤器或基于 DNS 的威胁检测系统。

当然，使用 DNS 侦听器并不只有优点，可能的缺点如下：

• 数据吞吐量有限：

DNS 并非为传输大量数据而设计，这限制了通信的带宽和速度。这使得 DNS 侦听器不太适合大数据传输或快速命令和控制通信。

• 复杂性增加：

实现和维护 DNS 侦听器比 HTTP 或 HTTPS 侦听器更复杂。

• 检测可能性：

尽管 DNS 流量通常较少受到监控，但这并不意味着它是完全不可见的。高级安全解决方案可以检测和分析 DNS 流量中的异常，例如异常频繁或大量的 DNS 请求。

C2域的选择

在 Cobalt Strike 中，有多种方法可以选择与 DNS 侦听器结合使用的 C2 域（以下称为域）。一方面，您可以注册一个新域名，并逐步建立它，让它老化并建立声誉。另一方面，可以通过expireddomains.net等服务购买过期域名。在实践中，由于时间限制，通常需要购买过期域名，以便在红队参与的相应场景中使用。

然而，在购买或注册域名之前，应注意确保域名尽可能老旧、信誉良好并且不在安全供应商的黑名单上。

Azure - 重定向器 

我们首先在 Azure 中创建一个新的 VM，作为 Cobalt Strike Team Server 的 DNS 重定向器。此重定向器的任务是充当在目标上运行的植入程序（信标）与 Cobalt Strike Team Server 之间的链接，从而防止通过其公共 IP 地址直接访问团队服务器。但是，需要注意的是，使用简单的重定向器（例如socat或iptables）无法完全防止 EDR 沙箱、扫描仪、蓝队和类似安全措施的不必要访问。

下面描述了 VM 的配置，需要注意的是，只讨论配置或更改的点。

基本设置

下一步，我们从虚拟机 (VM) 的基本配置开始。前提条件是拥有有效的 Azure 订阅。然后，我们将 VM 分配给资源组、分配名称、选择合适的区域和合适的映像并进行其他基本设置。下图显示了我们新 VM 的配置基本设置，该 VM 将用作 DNS 重定向器。

配置中一个特别重要的方面是仔细选择区域。如果可能，该区域应与目标位置相匹配，以避免目标网络中传出的 DNS 查询出现异常。不匹配的区域可能会显得可疑，并引起对数据流量的不必要的关注。

磁盘设置

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

审查并创建虚拟机

这样就完成了我们的重定向器的 Linux VM 的配置。未列出的设置尚未更改，因此未明确提及。在最后一步中，我们在创建 VM 之前检查 VM 配置。

重定向器 - 配置网络设置

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

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

我们还打开了 DNS（UDP）端口。但是，与 SSH 不同，我们不会将其限制为特定 IP 地址。这很重要，因为在红队场景中，我们通常不会提前知道目标的公共 IP 地址。因此，我们需要无限制地接受传入重定向器的 DNS 请求。换句话说，限制对某些 IP 地址或域的 DNS 访问可能会导致我们的重定向器阻止来自目标的传入 DNS 请求，从而阻止正确重定向到 Cobalt Strike Team 服务器。

在 Azure 中完成重定向器 VM 的配置后，我们稍后将以相同的方式为 Cobalt Strike Team 服务器创建 VM。如后面有关为 Cobalt Strike Team 服务器配置传入规则的部分所述，我们希望将传入的 DNS 请求限制为重定向器 VM 的内部 IPv4 地址。为此，我们将重定向器 VM 的内部 IP 地址配置为静态 IPv4 地址。 

重要的是，Redirector VM 和 Cobalt Strike VM 都是同一虚拟网络的一部分。此配置允许两个 VM 使用其内部 IPv4 地址进行通信。如果没有此配置，则无法通过内部 IPv4 通信进行 DNS 重定向，并且我们将被迫在 DNS 上下文中使用 Cobalt Strike VM 的公共 IP 地址，这在本场景中是不可取的。

这完成了我们的重定向器 VM 的配置，我们可以继续创建 Cobalt Strike VM。

Azure - Cobalt Strike 

部署、配置和操作 Cobalt Strike Team Server 有多种方式。一方面，可以在您自己的内部网络内操作 Team Server。另一方面，也可以将团队服务器托管在 Microsoft Azure 等云平台上。

在我们的案例中，我们决定在 Microsoft Azure 中运行 Cobalt Strike Team Server。为此，我们在 Azure 中创建一个 VM，该 VM 位于与我们之前创建的 Redirector VM 相同的虚拟网络中。创建此 VM 与创建 Redirector VM 没有什么不同，因此可以以相同的方式完成。

Cobalt Strike - 配置网络设置

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

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

我们还允许通过 UDP 进行 DNS 流量，但与 Redirector VM 不同，我们将传入连接限制到特定 IP 地址。在这种情况下，我们仅允许来自重定向器的内部 IPv4 地址（在本例中为10.0.0.8）的传入 DNS 请求。此配置可确保只有重定向器可以将 DNS 查询转发到 Cobalt Strike VM，从而进一步提高流量的安全性和控制力。

我们还将把 Cobalt Strike VM 的内部 IPv4 地址配置为静态 IP。此步骤至关重要，因为我们稍后将iptables在重定向器 VM 上使用它将所有发往端口 53（DNS）的流量重定向到 Cobalt Strike VM 的内部 IPv4 地址。 

通过将 Cobalt Strike VM 的内部 IP 设置为静态，类似于重定向器 VM 的配置，我们确保重定向器 VM 上的传入 DNS 数据包始终正确地转发到 Cobalt Strike VM。

摘要 Azure

我们在 Microsoft Azure 中的准备工作现已完成。我们为 Cobalt Strike 团队服务器创建了一个 VM，并将其配置为仅接受来自特定公共 IP 地址的端口 22（SSH）和端口 50050（Cobalt Strike 客户端）上的传入连接。我们还调整了传入规则，以仅允许来自重定向器的内部 IPv4 地址（在本例中10.0.0.8）的 DNS UDP 连接。

重定向器也以相同的方式创建和配置，以确保两个虚拟机之间安全且有针对性的通信。如前所述，两个虚拟机位于同一个虚拟网络上非常重要。这允许通过内部 IPv4 地址进行通信，这对于 DNS 重定向概念的顺利运行是必不可少的。

流量重定向

为了将 Azure 中 Redirector VM 上的传入 DNS 流量正确转发到 Cobalt Strike VM，我们配置了转发iptables。目的是将 Redirector VM 端口 53（DNS）上的所有传入请求转发到 Cobalt Strike VM 内部 IP 地址的端口 53（在本例中为10.0.0.5）。

第一步是建立与 Redirector VM 的 SSH 连接，例如使用 Putty。成功登录后，建议使用screen以下命令在 SSH 连接中打开一个新的终端会话。这将防止在 SSH 会话中断时终止 Cobalt Strike Team 服务器。 

# Start a new screen session with a specific name
screen -S CSDNS # Creates a new screen session named "CSDNS"

这里还有一些其他有用的 screen命令。

# Detach from the current screen session
# Press Ctrl + A, then D # This will detach from the "CSDNS" session without closing it

# List all active screen sessions
screen -ls # Shows a list of all current screen sessions

# Reattach to an existing screen session
screen -r CSDNS # Reattaches to the "CSDNS" session

# Terminate the screen session
# Inside the screen session, type:
exit  # Ends the "CSDNS" screen session

会话运行后，我们设置iptables转发。为此，我们运行以下命令，将通配符 IP 地址替换10.0.0.5为我们自己的 Cobalt Strike VM 的内部 IPv4 地址。

# Allow incoming DNS requests on port 53 (UDP and TCP)
iptables -I INPUT -p udp --dport 53 -j ACCEPT

# Forward incoming DNS traffic to the internal IP 10.0.0.5 on port 53 (UDP and TCP)
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.0.0.5:53

# Allow forwarding of the DNS traffic
iptables -I FORWARD -p udp --dport 53 -j ACCEPT

# Enable masquerading for NAT (source NAT) to ensure proper routing of responses
iptables -t nat -A POSTROUTING -j MASQUERADE

# Enable IP forwarding (required for routing packets)
sysctl net.ipv4.ip_forward=1

当重定向设置iptables完成并正常工作后，按 Ctrl+A，然后按 D 退出会话。

DNS 配置

在本例中，我们将使用 GoDaddy 作为我们的注册商，并了解如何为我们的域配置 DNS。首先，我们在 DNS 中创建一个“A”记录并为其命名，例如“info”。此“A”记录配置为指向 Azure 中重定向器 VM 的公共 IPv4 地址。

此外，还会创建两个指向之前创建的“A”记录的名称服务器记录。这两个名称服务器的名称是任意的，在本例中我们使用“blog”和“login”。这些名称服务器稍后将在 Cobalt Strike 的侦听器配置中使用。

一旦我们域的 DNS 配置完成，我们就可以继续在 Cobalt Strike 客户端中设置 DNS 侦听器。

Cobalt Strike - DNS 监听器

要将我们的域与 Cobalt Strike 中的 DNS 侦听器结合使用，我们需要创建一个新的侦听器。对于有效负载，我们选择“Beacon DNS”选项。然后，我们将两个先前创建的名称服务器条目的完全限定域名 (FQDN) 添加为“DNS 主机”。我们为重定向器 VM 配置的“A”记录条目的 FQDN 输入为“DNS 主机 (Stager)”。其余 DNS 侦听器设置可以保持不变。

此配置将允许 DNS 侦听器通过正确配置的 DNS 记录处理查询，从而建立信标和 Cobalt Strike Team 服务器之间的连接。

DNS 侦听器测试

如果到目前为止所有配置都正确，则所有准备工作都应已完成，并且应该可以在我们的域上下文中通过 DNS 与我们的 Cobalt Strike Team 服务器进行通信。为了检查这一点，作为第一个测试，我们将在我们域的两个名称服务器的 FQDN 上运行 nslookup 命令。

如果配置成功，我们将收到0.0.0.0来自 Cobalt Strike Team 服务器的 IP 地址响应，如下所示。此响应表明 Cobalt Strike Team 服务器上的 DNS 侦听器已正确配置，并且可以通过配置的 DNS 记录处理查询。

DNS-Beacon 测试

最后，我们通过创建“Windows Stageless Payload”并选择我们的 DNS 侦听器作为侦听器来检查 DNS 侦听器的功能。无需更改此测试的有效负载配置中的任何其他设置。

一旦我们创建了有效载荷，我们就可以运行它并查看它是否成功连接到 Cobalt Strike Team 服务器。如果 DNS 侦听器正常工作，则信标应该通过 DNS 成功连接到团队服务器，确认配置成功。

接下来，我们在实验室中禁用 AV/EPP/EDR 的主机上运行生成的代码beacon_x64.exe。如果一切顺利，我们的 Cobalt Strike DNS 有效负载应该能够成功与 DNS 侦听器通信。这意味着信标已通过 DNS 连接到 Cobalt Strike Team 服务器，确认整个配置成功。如果连接成功，您将在 Cobalt Strike 界面中看到此信息，其中信标将作为活动代理出现。

要完成 DNS 信标的初始化，我们需要与 DNS 信标进行交互并执行签到。只有这样，我们才能使用 DNS 信标进行通信或后续利用。

概括

在这篇博文中，我们介绍了一种通过 DNS Beacon 或 DNS Listener 使用 C2 流量的可能设置。我们在 Microsoft Azure 中创建了两个虚拟机：一个重定向器虚拟机，它从我们的 DNS Beacon 接收 DNS 查询，并使用 Linux 下端口 53 上的 iptables 将它们转发到 Cobalt Strike VM 的内部 IPv4 地址，该 VM 也是在 Azure 中创建的。

此外，还讨论了 DNS 配置，解释了使用 iptables 正确路由所需的命令，解释了 Cobalt Strike（从 4.0 版开始）的 DNS 侦听器的设置，最后描述了检查 DNS 侦听器功能的步骤。

此配置为在 Cobalt Strike 内安全且受控的环境中使用基于 DNS 的 C2 流量提供了坚实的基础。但是，需要注意的是，从红队的角度来看，此配置无法提供针对网络扫描器、沙箱或蓝队的完全保护。如果您想更深入地了解并提高安全性，您可能需要查看mgeeky 的RedWarden。RedWarden提供高级选项，以更好地保护您的 C2 基础设施免受检测。