几个月前，我写了一篇关于利用Active Directory集成DNS（ADIDNS）的博客文章。在本文中，我将主要介绍攻击和防守方面的一些额外技巧。在继续阅读本文之前，我建议读者至少略读一遍我之前发表的那篇博文。

 

首先，在本文内容的开头，我想添加另外一个与名称解析相关的众所周知且有问题的默认设置。这也是之前那篇博文中所遗漏的内容。

WPAD

Web代理自动发现（WPAD）是我们所熟知的LLMNR和NBNS欺骗中常见的攻击目标。乍一看，WPAD似乎是通过ADIDNS添加的一条最明显的记录。经过身份验证的用户通常可以添加DNS记录，因为默认情况下是没有记录的。

如果你确实为WPAD添加了一条记录，你可能会发现你所添加的记录没有起任何作用。这是由于全局查询阻止列表的存在所导致的（GQBL），默认情况下阻止列表包含WPAD和ISATAP。

 

现代的Windows DNS服务器通常不会响应与GQBL中所列出的相匹配的主机发出的名称请求。为什么我要加上“通常”这两个字？因为，事实证明GQBL并不总是有效的，有方法可以绕过。

绕过GQBL

在我尝试使用通配符记录时，我注意到Windows DNS服务器忽略了GQBL并通过通配符响应了对WPAD的请求。在整个研究的过程中，到此时，我还没有开始使用LDAP。我只能通过动态更新添加记录。由于'*'字符在动态更新时无法正常绕过，因此我决定寻找能够与动态更新配合使用的GQBL绕过方法。

我发现的第一个方法是通过DNAME记录。如果DNS域中存在“wpad”的DNAME记录，那么Windows DNS服务器将会解析WPAD。

 

通常，DNAME记录不会解析与实际记录相匹配的请求。DNS服务器应仅响应映射域中主机的请求，例如“host.wpad.inveigh.net”。在这种情况下，'wpad.inveigh.net'的根将可以被解析。

奇怪的是，我发现Windows DNS服务器在满足某些条件时会响应对DNAME记录的根的请求。这种记录需要匹配GQBL上列出的主机并且GQBL要处于启用的状态。关于WPAD来说，默认启用的GQBL实际上会使事情变得更糟。

不幸的是，我无法使用DNAME记录来处理动态更新。所以，我需要回到研究的起点来寻找另一种绕过的方法。之后，我发现了一种为WPAD子域名添加NS记录的方法。

 

这个方法稍微复杂一些，因为要利用这个方法你需要设置NS记录指向你已经控制了的DNS服务器。在Kali中内置的DNSChef提供了一种简单的方法来设置DNS服务器，该服务器将应答收到的任何请求。

 

同样，我无法使用动态更新完成绕过。但当我最终开始选择使用LDAP后，所有这三种绕过方法都显得微不足道，不值一提。

请注意，2016年之后的服务器版本似乎与以前的服务器版本略有不同。如果你使用的记录类型期望指向DNS记录而不是IP地址的记录，则确实需要使用DNS记录。在大多数情况下，早期的DNS服务器版本使用的是IP地址。2016年之后的服务器版本中，如果现有的目标记录并不存在，你可能需要添加其他记录以根据攻击需要设置某些记录类型。

CVE-2018-8320

我在6月份将ADIDNS的研究结果转交给微软时，列出了三个绕过GQBL的方法的详细信息。他们告诉我，他们会为GQBL 分配CVE- 2018-8320编号并在10月份发布补丁。然后我公开了我研究ADIDNS的成果，同时没有提及到任何关于WPAD和GQBL的信息。

补丁确实在十月份发布了。以下是在完全修补了漏洞的系统上利用每种绕过方法后的情况。

 

通配符记录不再解析GQBL列表中列出的主机的请求。

 

DNAME记录不再解析GQBL列表中列出的主机的请求。

 

正如你在上面的屏幕截图中所看到的，NS记录依旧可以绕过GQBL。

 

域名后缀搜索顺序

在我之前发表的博文中，我推荐了管理员控制的通配符记录，作为ADIDNS通配符攻击和LLMNR / NBNS欺骗攻击的防御手段。在r/netsec上进行的对话讨论中，有几个人指出，当通过组策略将多个域名后缀分配给搜索列表时，通配符记录可能会导致一些问题。

 

在进行了一些测试后，我确认他们的说法是正确的。当我把通配符放置在较高级别的域名后缀的DNS区域中后，如果匹配到了有效记录，系统将阻止有效的非完全限定请求下降到任何较低级别的域名后缀。

 

这种情况导致产生了一种全新的攻击方式。利用这个特性，你可以定位对现有记录的请求，而不是在DNS区域中定位不存在的记录。如果可以将记录添加到作为域名后缀的DNS区域，则可以在任何优先级较低的域名后缀中定位有效主机。对目标主机的非完全限定请求将全部由你所添加的记录来响应。

 

注意，执行通配符攻击时应考虑DNS后缀。如果你发现具有多个DNS后缀的搜索列表，那么在注入除了列表中的最后一个DNS区域之外的任何记录时，通配符攻击可能会发生中断。

利用网络钓鱼发起ADIDNS攻击

使用LLMNR / NBNS欺骗，欺骗工具必须在整个攻击过程中持续运行。然而，ADIDNS攻击仅可以通过一点初始化操作就可以进行。因此，我认为通过网络钓鱼更容易实现ADIDNS攻击。在这种攻击场景中，只有一个AD连接的网络钓鱼目标需要执行有效负载，目的是为了添加可能向远程攻击者控制的系统发送流量的记录。你可以将这些记录用于C2等事件或设置为其他网络钓鱼攻击。

 

上图是使用我编写的PowerShell工具添加一条指向公共IP的记录的示例。对于在实际场景中的网络钓鱼攻击，你可以使用更多合适的载荷。

这是NS记录可以帮助攻击的另一个领域。设置NS记录后，你只需通过自己的DNS服务器将其他记录添加到受控子域即可。

域名劫持

当公司的内部AD域名与其公共域名相匹配时，来自外部的ADIDNS攻击就变得特别有趣了。在这种情况下，你可以利用公共域名的信任关系来绕过内容过滤。

 

当然，这种技术也存在局限性。因为你只能影响使用了目标ADIDNS进行名称解析的资源。记录本身或任何相应的事件ID也有可能让你的攻击行为暴露。最重要的是，由于缺乏域名所有权，你将很难为HTTPS流量设置可信证书。

利用AD穿墙外连C2服务器

不久前，harmj0y发布了一篇关于使用AD作为C2信道的有趣博文。这与ADIDNS有什么关系？查看那篇文章后，可以发现，在添加dnsNode对象时，经过身份验证的用户会在创建时获得完全控制权。dnsNode对象还包含了许多可写属性。这导致dnsNode对象成为了C2的备选对象以及利用AD穿墙外连C2服务器的技术。

当然，纯粹基于DNS的C2和穿墙技术也是有可能的。

再谈ADIDNS防御

如上所述，如果你使用具有多个DNS后缀的搜索列表，那么管理员控制的通配符A记录可能会导致一些问题。或者，你可以使用不会解析名称请求的记录类型（如TXT记录）创建通配符。

 

由于所有记录类型都存储在dnsNode对象中，因此添加任何形式的通配符记录都会阻止非特权用户添加自己的名为“*”的dnsNode对象。不幸的是，不起解析作用的通配符记录不具有防御LLMNR和NBNS欺骗攻击的能力。

 

总得来说，锁定DNS区域的权限是缓解经过身份验证的用户发起ADIDNS攻击的最简便的方法。根据你的设置，你可以利用DHCP 中的专用DNS动态更新帐户。这可能需要你完全删除“已验证用户”下面的“创建所有子对象”权限。

最后，请记住，非完全限定名称请求可以实现许多名称解析攻击。用户生成的此类请求很难完全消除。但是，对于系统和应用程序配置，我建议尽可能的使用完全限定的域名。