需要学习资源，请点击开挂教学楼
需要学习资源，请点击开挂教学楼
WPAD是什么？
Web代理自动发现（WPAD）是LLMNR和NBNS欺骗过程中的常见目标。WPAD乍看之下跟ADIDNS中的其他记录没什么太大区别，如果ADIDNS默认没有这条记录的话，认证用户可以直接添加这个记录。
如果你添加了一条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’的root记录可以正常解析。
奇怪的是，我发现Windows DNS服务器在满足某些条件时会响应DNAME记录的root请求。这种记录需要匹配GQBL中的主机且GQBL要处于启用的状态。对于WPAD来说，默认开启GQBL可能会更加危险。但是，我无法使用DNAME记录来处理动态更新。所以我得寻找另一种绕过的方法。随后，我发现了一种为WPAD子域名添加NS记录的方法。
这种方法比较复杂，因为需要设置NS记录指向一台可控制的DNS服务器。不过使用Kali自带的DNSchef是一种设置DNS服务器来提供应答接收的请求的简单方法。
但此时我仍然无法使用动态更新完成绕过，不过在选择使用LDAP后，一切都变得明朗了。
CVE-2018-8320
我在发现了这个问题之后，便立刻将研究成果提交给了微软，微软方面也为该漏洞分配了CVE编号（CVE-2018-8320），并发布了漏洞修复补丁。下面是我在修复漏洞后的系统上测试的结果。
通配符记录已不再解析GQBL列表中主机的请求了：
DNAME记录已不再解析GQBL列表中主机的请求了：
但是正如你所看到的那样，NS记录仍然可以绕过GQBL。
域名后缀搜索顺序
此前我曾建议使用管理员控制的通配符记录来预防ADIDNS通配符攻击和LLMNR / NBNS欺骗攻击。但也有研究人员指出，当通过组策略将多个域名后缀分配给搜索列表时，通配符记录可能会存在问题。
测试之后，我