DNS over HTTPS for Cobalt Strike
Kyle Avery //
引言
近年来，为红队行动设置C2基础设施变得越来越麻烦。这对安全社区来说是一个胜利，因为这意味着供应商和专业人员已经从先前成功的技术中学习，并在其网络中实施了有效的缓解措施。
DNS over HTTPS（DoH）是一个被低估的命令与控制通道。本篇博客将展示如何利用DoH与Cobalt Strike配合使用，这种方式无需第三方账户或基础设施设置，使用有效的SSL证书加密流量，并将流量发送到信誉良好的域名。
现有技术
攻击者和进攻性安全专业人员已经使用不同的重定向器实现有一段时间了。我最初使用的重定向器是简单的Apache和Nginx服务器，配置了各种规则以根据预定义标准转发流量。
重定向器对于使基础设施更具弹性非常有用，但它们也可以绕过依赖域分类的防御。例如，一旦内容分发网络（CDN）对开发者变得更加可访问，攻击者就从传统的重定向器转向这些平台，因为它们通常向用户提供有效的域名甚至SSL证书，减少了攻击者的工作量。
后来发现了一种称为“域前置”的技术，并被许多测试人员大量使用。然而，最近CDN提供商一直在打击这种行为。许多网站完全阻止域前置或主动搜索使用它的人。特别是微软，已知会在我们操作过程中关闭Azure订阅。
我最近转向其他云服务，如Azure App Services和Cloudflare Workers，用于流量重定向。这些服务具有与传统CDN相同的好处，但监控较少。虽然这些服务运行良好，但云提供商可能随时开始以与监控CDN相同的专注度来监视这些服务。
DNS over HTTPS
传统的DNS信标相对容易检测。我从未在操作中使用过Cobalt Strike DNS监听器，限制我只能使用先前描述的HTTPS监听器和重定向器。
用于信标的DNS over HTTPS为我们提供了信誉良好的域名和有效的SSL证书，无需账户或任何重定向器配置。这进一步减少了操作员的设置时间，并消除了账户关闭的风险。
今日主题：Cobalt Strike的DNS over HTTPS
DNS over HTTPS的使用最初是由Austin Hudson在Twitter上向我介绍的。他在过去一年的推文详细介绍了他在实现这一能力方面的进展，并导致了一个开源工具：TitanLdr。这个Cobalt Strike用户定义反射加载器（UDRL）钩住Cobalt Strike信标的导入地址表（IAT），将负责进行传统DNS查询（DNSQuery_A）的API调用替换为一个向dns.google（8.8.8.8和8.8.4.4）发出DoH请求的函数。
这本身就是一个优秀的能力，但TitanLdr的DNSQuery_A钩子是通用的，足以与许多不同的DoH服务器配合使用！我已经测试了以下域名，并确认它们可以作为即插即用的替代品：
- dns.quad9.net
- mozilla.cloudflare-dns.com
- cloudflare-dns.com
- doh.opendns.com
- ordns.he.net
使用TitanLdr
TitanLdr是将此能力集成到Cobalt Strike的关键。你可以在这里获取原始的TitanLdr，它通过HTTPS服务器向单个DNS提供商发送信标：https://github.com/secidiot/TitanLdr。你可以在hooks目录中的DnsQuery_A.c文件的第111行更改DNS服务器。
TitanLdr/hooks/DnsQuery_A.c第111行（原始仓库）
此后，我分叉了TitanLdr以允许指定多个DoH服务器。每次进行回调时，信标将从硬编码列表中随机选择一个。如果你想使用多个DoH服务器，可以在这里下载我的分叉：https://github.com/kyleavery/TitanLdr。你可以在hooks目录中的DnsQuery_A.c文件的第116行修改服务器列表。
TitanLdr/hooks/DnsQuery_A.c第116行（分叉仓库）
下载后，你需要构建程序。这将需要一个安装了NASM和MinGW的Linux主机。一旦你有了这些程序，运行make命令以创建必要的文件。
构建TitanLdr
将Titan.cna Aggressor脚本导入Cobalt Strike，你就可以使用DoH了！像通常那样配置DNS监听器。Cobalt Strike文档更深入地介绍了如何配置此监听器。
配置DNS监听器
一旦信标运行，我们可以看到只进行了一个DNS请求来解析DoH服务器地址。之后，所有流量都是加密的HTTPS。
DoH信标网络流量
DNS over HTTPS的缺点
我们已经讨论了DNS over HTTPS信标相对于传统HTTPS信标的优点，但也有一些明确的缺点。
首先，需要更多的数据包来将相同的信息传回团队服务器。DNS TXT记录最多只能包含255个字符，这意味着我们只能在每个数据包中发送少量数据。
其次，我们对可用服务器的路径或域名没有控制权。对于环境或设备来说，拒绝出站443/TCP到流行或已知的DoH服务器列表似乎比阻止Microsoft的*.azurewebsites.net或Cloudflare的*.workers.dev更容易。你可以通过使用更晦涩的DoH服务器或构建自己的服务器并根据环境配置逐渐分类它们来解决这个问题。
潜在的检测方法
当前的检测技术在检测DNS over HTTPS时可能存在差距。
- 当前针对恶意HTTPS流量的检测通常利用域信誉，这使得它们对DoH可能无效，因为使用的域名是信誉良好的。
- 当前针对恶意DNS流量的检测通常监控许多DNS请求，这使得它们对DoH可能无效，因为流量不再使用DNS协议。
传统DNS监控和SSL检查的结合可能是一个潜在的解决方案，但我不知道目前有任何工具或产品这样做。
我的理解是，针对这种攻击的主要防御是阻止出站443/TCP到组织未使用的已知DoH服务器。我遇到的大多数网络仍然使用传统DNS，通常有一个本地DNS服务器作为Active Directory环境的一部分运行。在这种情况下，没有必要允许HTTPS流量到dns.google、cloudflare-dns.com或本文中提到的任何其他服务器。
结束语
绝对有更多的DNS over HTTPS服务器可以用于此配置。此外，用户可以设置自己的DoH服务器，甚至可能 behind a CDN或其他云服务，以引入这种技术的变体。
TitanLdr仅限于Cobalt Strike，但DoH实现可以移植到任何其他C2框架。
这种方法并非在所有情况下都是最好的，但它是工具包中的另一个工具，我希望你能利用它。如有任何问题或评论，请随时在Twitter @kyleavery_上联系我。
致谢
- 使用DNS over HTTPS进行C2的想法来自Austin Hudson的工作。没有他的TitanLdr项目，这种技术和博客就不会发生。Austin的代码和推文激发了我许多个人项目；我强烈推荐关注他。
- 我提到我目前使用两种重定向器服务用于传统HTTPS信标：Azure App Services和Cloudflare Workers。我最初在以下两个链接中发现了这些技术：