域渗透技巧之再谈利用ADIDNS绕过 GQBL
几个月前，我写了一篇关于利用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区域中后，如果匹配到了有效记录，系统将阻止有效的非完全限定请求下降到任何较低级别的域名后缀。
几个月前，我写了一篇关于利用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年之后的服务器版本中，如果现有的目标记录并不存在，你可能需要添加其他记录以根据攻击需要设置某些记录类型。 copyright 无奈人生
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区域中后，如果匹配到了有效记录，系统将阻止有效的非完全限定请求下降到任何较低级别的域名后缀。
www.wnhack.com