presenter是一个跨平台工具，用于在 Windows 网络中获得计算机中间位置，它使用 mDNS、LLMNR 和 NetBIOS-NS 协议以及 DHCPv6 DNS 接管攻击来实现本地名称解析欺骗。自去年以来，presenter已成为我们网络渗透测试中常用的工具。

中间人攻击和 NTLM 中继

自从十几年前HTTPS真正开始流行以来，针对互联网服务器连接的中间人攻击攻击变得不那么重要了，今天使用的大多数协议都能抵抗这种攻击。然而，在Windows域(Active Directory)中，情况就大不相同了，因为脆弱的NTLM认证协议(也称为NetNTLM)仍然广泛用于各种协议，如SMB、HTTP或LDAP。攻击身份验证协议可以让攻击者获得进入域的入口点，甚至是权限升级。

例如，如果我们可以观察到两个主机之间的NTLM身份验证，我们就会获得一个基于挑战-响应的NTLMv1或NTLMv2密码哈希(也称为NetNTLMv1/NetNTLMv2)。虽然破解弱密码的哈希值是非常有可能的，但如果我们不仅可以观察通信，而且可以拦截它，这往往是不必要的。

这就引出了令人难以置信的强大NTLM中继攻击。在大多数情况下，可以将截获的身份验证握手转发给另一台主机。这将赋予攻击者对所选主机的访问权，该主机具有发起被截获连接的用户的特权。在大多数情况下，NTLM中继会迅速导致整个域的攻击，因此是一种非常有价值的攻击技术。

进行这种攻击的首要前提是攻击者要处于中间位置。

DHCPv6 DNS接管

DHCPv6 DNS接管攻击是在没有IPv6配置的网络中获得中间人攻击位置的最优雅的攻击之一。大多数公司网络内部还没有使用IPv6。对攻击者来说，这是个好消息，因为他们可以自己为客户端提供IPv6配置。

这种攻击通过设置一个非法的DHCPv6服务器来实现。默认情况下，本地网段的Windows主机会在我们的服务器上运行，因为它们会定期扫描网络上的DHCPv6服务器，攻击者甚至可以通过发送ICMPv6路由器广告来加快速度。一旦发现DHCPv6服务器，Windows将请求一个地址，而presenter只会在链接本地地址范围 (fe80：：/64) 内生成一个地址，但它也会在地址旁边将自己宣传为 IPv6 可访问的 DNS 服务器。

现在Windows主机知道了两个DNS服务器：一个是ipv4可达的DNS服务器，它在攻击之前就知道了，另一个是IPv6可达的，攻击者控制的，位于链路本地IPv6网段的DNS服务器。但问题来了，默认情况下，Windows更喜欢通过IPv6可访问的DNS服务器，而不是通过IPv4可访问的DNS服务器。这意味着现在所有查询都被发送到攻击者控制的DNS服务器，从而为攻击者提供了一个中间位置。

--no-lnr 标志只是禁用本地名称解析攻击，我们将在下一节中介绍。

DHCPv6 DNS 接管行动

在发送 ICMPv6 路由器通告后，灰色的日志行表明研究人员的 DHCPv6 服务器已被 Windows 主机发现，并且DNS 服务器已被分配。几乎在那之后，研究人员就开始接收IPv4 (A)和IPv6 (AAAA)地址的DNS查询，然后攻击者可以用攻击系统的IP回复这些查询。这是一种非常强大的技术，因为它允许攻击者拦截系统的绝大多数传出连接。然而，这也意味着，如果你只是简单地攻击本地网段中的所有 Windows 主机而不是仔细选择目标，它可能会有点攻击性。

如开头所述，研究人员用作presenter的 DHCPv6 DNS 接管功能参考的原始实现称为 mitm6。

本地名称解析欺骗

presenter实现的另一种攻击技术是局部名称解析欺骗。此技术的目标是试图联系无法通过DNS解析地址的其他主机的主机。在这种情况下，他们基本上只是在本地网络内询问。Windows目前使用三种不同的协议来实现此目的：组播DNS (mDNS)、链路本地组播名称解析(LLMNR)和NetBIOS命名服务(NetBIOS- ns或NBNS)。顾名思义，它们都使用组播或广播到达网段中的所有主机，没有人阻止攻击者自己来回答查询。

但首先，先了解一下使用本地名称解析的情况。经常遇到的情况之一就是网络共享已经不存在了。Active Directory DNS服务器早就忘记它们了，但是一些客户端仍然尝试挂载它们，例如，因为它们仍然在一些软件或服务中配置。有时，在引用主机名而不附加域名时，人们也只是出于方便而选择使用本地名称解析而不是 DNS。

攻击技术本身非常简单：侦听本地名称解析查询并使用攻击系统的地址进行回答。就这么简单。那么让我们来看看这三种协议之间的区别。

mDNS

mDNS基本上只是普通的旧DNS，用于在IPv4上操作时使用组播地址224.0.0.251，在IPv6上操作时使用ff02::fb。它使用UDP端口5353，该端口在Linux上被认为是一个高级端口，通常不需要特殊权限即可绑定。默认情况下，Windows不公开该端口上的任何服务，因此通常允许用户绑定到该端口。

LLMNR

LLMNR是由微软开发的NetBIOS-NS的继承者，与mDNS一样，它非常类似于常规的DNS协议。它使用多播地址 224.0.0.252 (IPv4) 和 ff02::1:3 (IPv6) 以及高 UDP 端口 5355。通常也可以绑定到 Windows 主机上的此端口。

NetBIOS-NS

NetBIOS-NS的工作方式略有不同。因为它使用广播而不是组播，使用 UDP 端口 137 并且只能在 IPv4 上运行。在Linux上，绑定到这个端口通常需要提升权限，而在Windows上，它通常被内置的NetBIOS服务(可以禁用)占用。就一般结构而言，该协议有点类似于DNS。事实上，我们设法在pretender中使用常规的DNS库来实现NetBIOS-NS。它只支持用于解析IPv4地址的单一查询类型(类型32映射到常规DNS类型NIMLOC，目前未使用)。最明显的区别之一是荒谬的查询名称编码。例如，这种不区分大小写的编码将WORKGROUP映射到FHEPFCELEHFCEPFFFACACACACACACAAA。

与DNS相比，查询还包含所谓的后缀，这些后缀揭示了查询的上下文。例如，后缀可以表明执行了查询来定位工作站、文件服务器甚至是Exchange服务器。分析这些后缀也有助于我们理解为什么特定查询会发生在客户端网络中。

本地名称解析欺骗

以下是使用presenter的本地名称解析欺骗示例。同样，标志——no-dhcp-dns仅用于禁用上述DHCPv6 DNS接管攻击。

可以清楚地看到，如果Windows想要解决一些问题，它通常会尝试所有的方法：IPv4, IPv6, mDNS, LLMNR, NetBIOS-NS, A, AAAA, ANY和所有可能的组合。因此，如果特权不允许监听端口137，那么仍然有可能使用其他协议接收和欺骗所有查询。

当查看NetBIOS-NS查询时，查询后缀也可以在以上示例中看到。这样就可以使用File Share后缀查询名称NETSHARE，这可能表示试图访问SMB共享，而使用Primary DC后缀查询WORKGROUP。

还可以首先只监控网络上看到的本地名称解析查询，并在执行攻击之前重复它们。通过——dry标志，可以为presenter启用合适的监控模式。如果没有回答重复的查询，则这些名称很可能属于不再存在或当前不可用的系统。仅欺骗这些查询可能不会导致中断，从而使客户更满意。

虽然所讨论的攻击非常强大，尤其是与NTLM中继相结合时，但它们并不是特别新的。在开发presenter之前，攻击者使用mitm6进行DHCPv6 DNS接管，使用Responder进行本地名称解析欺骗。然而，pretender在很多方面都不同于这些项目，它为渗透测试者提供了很多帮助。在本节中，我们将了解在各种场景中使用presenter的优势。

注意事项

除了本地名称解析欺骗之外，Responder的主要目的还包括接受使用各种协议的后续连接，并转储身份验证尝试期间产生的NTLM哈希。在测试环境中记录此类攻击时，这会使事情变得非常复杂。我们需要两种不同的工具（Responder 和 mitm6）来获得计算机在中间的位置。在利用这个位置时，我们再次需要 Responder，还需要 Impacket 的 ntlmrelayx.py。

为了更好地进行渗透测试，必须了解一个相当复杂的攻击链，。

跨平台编译

如上所述，所有技术都只针对攻击系统的本地网段内的计算机。在实践中，这种限制在某些场景中会大大降低有效性。例如，网络渗透测试的起点可以是一个仅用于Linux服务器的网段中的系统，或者是一个与管理员使用的网段分离的客户端网络。这样就可以产生高度特权连接。在这些情况下，我们不需要在专门的攻击系统上运行攻击，而需要在更合适的网段中的某些受攻击系统上运行攻击。

mitm6和Responder都是用Python编写的，所以需要提供合适的Python运行时以及所需的库，如果可能的话，我们希望避免在客户的系统上安装软件。另外，mitm6捕获原始数据包，这需要一个特殊的Windows驱动程序，而Responder只有一个Windows的实验beta版本。此外，Python和所需的库通常都不支持mips这样的架构，而mips通常用于路由器。

假如我们已经设法破坏了一个连接到域管理员使用的本地网段的基于mips的路由器。使用pretender和一个标准的Go安装，我们可以这样为路由器编译它：

只需要更改一两个环境变量，就可以设置交叉编译器工具链。对于其他架构，如ARM或其他操作系统，如Windows、macOS或BSD，这也是一样的。因此，我们获得了一个单一的静态二进制文件，它将在受攻击的系统上工作，使我们能够攻击不同的网段。然后，我们可以指示presenter使用我们的专用攻击系统在原始网段中的地址（例如 10.0.0.5 和 fe80::5）来回答名称查询，如下所示：

编译时配置

假设我们在一个网段中发现了Windows计算机的远程代码执行漏洞，且这个漏洞只允许我们运行一个没有任何参数的二进制文件，并且在它终止后我们只接收到标准输出。每个命令行配置标志的默认值可以在编译时重新配置，这样我们就可以为这个特殊用例生成一个预先配置的二进制文件：

在本示例中，我们生成了一个二进制文件，它会自动选择被攻击计算机的正确网络接口，用攻击系统的IPv4地址回答名称查询，在五分钟后自动终止，而不是连续运行，并将标准错误重定向到标准输出，这样我们就可以看到可能发生的任何错误。这种灵活性让presenter在各种特殊情况下大放异彩。

我们总是使用 vendorStopAfter 变量（对应于 --stop-after）来构建presenter，以确保我们不会无意中让presenter运行时间超过必要的时间，以避免对客户网络造成不必要的干扰。

详细的日志记录

在渗透测试期间，尽可能多地了解正在发生的事情总是很重要的。对于此处讨论的名称解析欺骗攻击尤其如此。如果你确切地知道谁在请求哪个名称以及可能为什么请求该名称，则可以更轻松地定位特定主机以最大程度地减少中断和检测。借助详细信息，还可以将查询链接到 ntlmrelayx.py 中的中继连接，以便向客户端准确解释如何将域管理员的连接中继到高价值目标。为此，presenter旨在提供尽可能多的有关传入连接的信息。

虽然IP地址很好，但如果知道相应的主机名就更好了。在Windows网络中，从IP获取主机名的一种方法是反向DNS查找。然而，这只在通过IPv4执行反向查找时有效，至少在通常不使用IPv6的网络中有效。当使用presenter时，特别是在执行DHCPv6 DNS接管攻击时，通常只会暴露目标系统的IPv6地址。在本例中，不可能执行反向DNS查找来找到相应的主机名。我们也不能从IPv6地址了解到任何东西，因为默认情况下，Windows不使用从MAC地址生成的EUI-64 IPv6地址，而是使用随机地址。然而，presenter仍然能够提供帮助。每个IPv6地址都通过ARP缓存中的共享MAC地址与对应的IPv4地址进行匹配。有了相应的IPv4地址，反向DNS查找很可能会成功。因此，伪主机不仅显示IPv6地址，而且还显示同一主机的已知IPv4地址以及主机名。如果这个推断不成功，就在MAC地址供应商表中进行查找。日志示例如下：

在这个示例中，我们首先看到一个基于ipv4的mDNS查询。反向查找不成功，因此只显示从MAC地址推断出的网络接口厂商PcsCompu。随后，通过IPv6接收相同的查询。该地址是由Windows主机本身生成的，但它可以与第一次查询产生的IPv4地址匹配。

即使网络的DNS服务器不允许反向查找，我们仍然可以获得主机名，因为默认情况下，Windows将其包含在DHCPv6查询中。通过缓存这些信息，我们可以稍后将IPv6地址与其主机名关联起来。通过MAC地址，我们还可以将IPv4地址与主机名绑定。

理想情况下，该信息允许我们向客户提供详细的解释，但presenter并不止步于此。它还可以使用——log选项生成JSON格式的可查询日志。

本文翻译自：https://blog.redteam-pentesting.de/2022/introducing-pretender/如若转载，请注明原文地址