CobaltStrike-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 侦听器的可能设置的设置和配置。以下是我们将详细介绍的各个步骤的概述：

• 为什么通过 DNS 传输 C2 流量？
• C2 结构域的选择标准
• 在 Azure 中创建和配置重定向器 VM
• 在 Azure 中创建和配置 Cobalt Strike VM
• 在 GoDaddy 中配置 DNS
• 在 Cobalt Strike 中配置 DNS 侦听器
• 测试 DNS 侦听器

下图显示了本文中描述的在 Cobalt Strike 中使用 DNS 侦听器的概念的简化版本。它显示了基本架构，包括 Redirector VM（接收和转发 DNS 查询）和 Cobalt Strike VM（处理查询并用于 C2 通信）。该图旨在帮助可视化不同组件之间的关系及其在整体概念中的功能。

与 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 请求）可以通过高级安全解决方案进行检测和分析。

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

但是，在购买或注册域之前，应注意确保该域尽可能古老、具有良好的声誉并且不在安全供应商的黑名单上。

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

VM 的配置如下所述，因此应注意，仅讨论配置或更改的点。

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

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

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

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

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

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

我们还为 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 地址。

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

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

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

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

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

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

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

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

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

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

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

为了将 Azure 中重定向器 VM 上的传入 DNS 流量正确转发到 Cobalt Strike VM，我们使用 .目的是将重定向器虚拟机端口 53 （DNS） 上的所有传入请求转发到 Cobalt Strike 虚拟机内部 IP 地址的端口 53（在本例中）。

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

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

以下是一些其他有用的命令

# 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

会话运行后，我们设置转发。为此，我们运行以下命令，将通配符 IP 地址替换为我们自己的 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

当重定向设置完成并正常工作时，按 Ctrl+A，然后按 D 与会话分离。

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

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

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

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

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

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

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

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

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

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

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

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

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

此配置为在 Cobalt Strike 中安全受控的环境中使用基于 DNS 的 C2 流量奠定了坚实的基础。但是，请务必注意，从红队的角度来看，此配置并不能提供针对 Web 扫描程序、沙箱或蓝队的全面保护。如果您想更深入地提高安全性，您可能想看看 mgeeky 的 RedWarden。RedWarden 提供高级选项，以更好地保护您的 C2 基础设施免受检测。

 

原文始发于微信公众号（白帽子社区团队）：CobaltStrike-DNS侦听器