NTLM 中继 - 让旧事物焕然一新

我已经进步了，记得在测试的第一个小时内，通过 Active Directory 证书服务 (ADCS) 错误配置或通过有权限的 SCCM NAA 帐户获取域管理员权限并不总是可行的。目前，我们在本地 AD 环境中的特权提升向量方面有很多选择，但我想看看在 ADCS 和 SCCM 出现之前被证明是卓有成效的其他一些错误配置，并继续让我在参与中快速获胜，例如：

• 缺乏 SMB 签名

• 缺少 LDAP 签名和/或通道绑定

• 机器帐户配额 > 0

• NTLM 中继

持续的漏洞利用在这里并不新鲜，只是旧事重提，但也许在匆忙滥用 ESC1 时，您忘记了一些滥用它们的现代技术。这些技术应该是您本地 AD 工具包的一部分，所以让我们深入了解细节。

下面是我最基本的 KENNEDY.local 家庭域名设置的图表，包括：

• 1x Windows 服务器作为域控制器：KENNEDY-DC (192.168.0.137)

• 1x Windows 服务器作为证书颁发机构：KENNEDY-CA (192.168.0.84)

• 1x Windows 10 工作站：ELISH（192.168.0.99）

• 1x Kali VM 充当攻击者（192.168.0.203）

用户将是：

• jkennedy（标准域用户）

• ekennedy（管理用户）

缺乏 SMB 签名

没有什么比放在共享中的 LNK 文件更能说明 SMB 签名漏洞的威力了。我最喜欢的演示工具是“ nxc ”上的“slinky”模块。

您可以使用以下命令建立所有 SMB 签名为“false”的机器的列表：

nxc smb targets.txt --gen-relay-list nosigning.txt

但在我的小实验室里，我可以像这样手动检查机器：

我们可以在上面看到 ELISH 机器没有签名，因此它无法确定谁通过 SMB 协议对其进行身份验证。

考虑到这一点，我们首先使用 nxc 来分析 KENNEDY-CA 机器，看看我们是否有任何可用的可写目录来放置我们的 LNK 文件，并且它识别了“共享”目录：

然后我们使用 slinky 在此共享上创建一个 LNK 文件，该文件指向我们的 Kali VM 192.168.0.203。现在，当任何人通过文件资源管理器（而不是命令行）进入该共享时，甚至无需单击它，LNK 文件就会被触发，他们的身份验证将被发送回攻击者的 Kali 机器。

回到攻击者的 Kali 机器，我们为任何传入的身份验证设置了一个ntlmrelayx 侦听器，如果收到任何身份验证，我们将目标对准 192.168.0.99 机器，我们知道该机器已禁用签名。此时，ntlmrelayx 可以自动打开与该机器的 socks 连接，作为使用其身份验证进入共享的用户。我们本质上是在进行中间人攻击。

当“ekennedy”进入共享后进行身份验证时，我们会得到一个命中，并且与没有签名的 192.168.0.99 机器打开一个 socks 连接，如下所示：

然后，ntlmrelayx 中会维护一个持久的 socks 连接，当您输入“socks”命令时可以看到该连接，如下所示：

然后，我们可以编辑 proxychains 配置文件，以允许我们访问到远程机器的 socks 连接，默认情况下使用端口 1080：

在“/etc/proxychains4.conf”中添加行“socks4 127.0.0.1 1080”

现在，我们可以利用代理链转储 sam 数据，因为“ekennedy”身份验证属于管理员。需要注意的是，此时使用 nxc 时我们不需要密码，因为我们使用的是已经通过 NTLM 身份验证的实时 socks 隧道。

现在，使用收到的哈希值完全控制这台机器已经很容易了。在上述场景中，ntlmrelayx 用于将“ekennedy”管理员身份验证中继到 1 台机器，但实际上它可以将其中继到 50 台关闭 SMB 签名的机器，因此可以打开 50 个管理员套接字连接以供选择。

这肯定在我真正的考试中发生过。

接下来是两种不太依赖运气的技巧，特别是当您不耐烦等待某人触发 LNK 文件时。

LDAP 签名 – RBCD

与 SMB 签名类似，LDAP 签名（或缺少签名）允许攻击者将 HTTP 身份验证发送到域控制器 (DC) 上可用的 LDAP 服务，但由于签名被禁用，DC 无法验证传入的身份验证是否来自发送它的实际机器。这再次打开了 MiTM 攻击的可能性。

首先，我们检查“KENNEDY-DC”机器，看是否强制执行 LDAP 签名或通道绑定，但事实并非如此。

然后，我们使用 nxc 的“webdav”模块在网络上运行 WebClient 的计算机（如下所示），我们可以看到“KENNEDY-CA”计算机已启用它。我们为什么对 webdav 感兴趣？好吧，我们可以强制 WebClient 服务通过 HTTP 向我们进行身份验证：

从攻击者的 Kali 机器，我们现在启动 ntlmrelayx 来瞄准“KENNEDY-DC”的 LDAPS，并在执行此操作时使用“委托访问”标志对该机器发起 RBCD 攻击。

简单来说，委托访问就是在网络上创建新机器，并授予新机器对已将身份验证传递给 DC 的机器的权限。这些权限允许我们作为攻击者冒充机器上的任何其他人（例如管理员）。

现在要强制 WebClient 对 ntlmrelayx 进行身份验证，我们首先启动Responder。确保其 HTTP 和 SMB 服务器已关闭，因为我们不想使用此工具捕获身份验证，而是使用 ntlmrelayx。

我们使用 Responder 的唯一原因是在网络上为我们提供“机器名称”，我们可以使用它来宣传自己并接收 Kali 机器的身份验证。此机器名称如下所示：

我们现在强制“KENNEDY-CA”（192.168.0.84）机器通过 HTTP 向我们的攻击者 Kali Responder 机器进行身份验证，然后将该身份验证转发到“KENNEDY-DC”，后者将无法验证谁在对其进行身份验证。对我们的 Responder 机器的回调反而会到达我们的 ntlmrelayx 服务器，该服务器正在监听端口 80：

执行该命令后，ntlmrelayx 将身份验证转发到禁用 LDAP 签名的“KENNEDY-DC”，然后我们在网络上收到一台具有随机名称的新机器，名为“KQCLXPVT$”。这台新机器还将提供在“KENNEDY-CA”服务器上模拟用户所需的附加信息。

现在可以在 Active Directory 中看到这台新机器，如下所示：

使用我为 nxc 编写的名为“group-mem”的模块，我们现在可以通过查找特权“域管理员”成员来查看我们想要模仿的人：

选择“ekennedy”后，我们现在可以通过 impacket 的 getST.py 命令使用我们的新机器帐户用户名和密码来模拟他们。

这将为我们提供该特定机器上的 cifs 服务的“ekennedy”服务票（又名银票），该票不能在其他地方使用。

我们可以将其导入到我们的 Kali 内存中，如下所示：

然后，我们可以通过在命令行上指定“-k”标志在各种工具中使用此票证，这样它将直接从我们设置的 KRB5CCNAME 变量中获取票证。

在这里我使用secretsdump 从机器内存中转储哈希值，就像密码一样，我们可以使用它以管理员身份访问机器，例如：

LDAP 签名 – 影子凭证

这项技术与前一项非常相似，因此我将简要介绍它。使用这项技术的主要好处是它不依赖于在网络上创建新机器，当某些组织将“机器帐户配额”设置为零时，这会很有用。请记住，默认情况下，普通 AD 用户可以添加 10，这太疯狂了！

如果我们可以修改计算机的属性“msDS-KeyCredentialLink”，并以我们可控制的证书形式附加备用凭据，则此技术允许攻击者接管 AD 计算机帐户。然后，此证书将允许我们控制该计算机。

因此，我们再次将我们值得信赖的 ntlmrelayx 设置为目标“KENNEDY-DC”，没有使用 LDAP 签名，但指定了两个不同的标志。它们是影子凭证，用于告诉它我们正在进行什么攻击，然后是影子目标，用于指定我们瞄准的机器。在这种情况下，我们瞄准的机器再次是运行 WebClient 的“KENNEDY-CA”机器，因此我们可以像前面所示的那样将其强制转向我们。

我们再次使用 Responder 提供机器名称，并使用 PetitPotam 向我们执行强制操作，如下所示：

ntlmrelayx 再次受到攻击，但这一次我们无法冒充受害者机器上的任何其他人，而是收到了该机器帐户的证书。

上面非常方便，ntlmrelayx 提供了接下来要与工具gettgtpkinit.py一起使用的命令 ，将证书转换为机器的 TGT（票证授予票证）。TGT 与 Kerberos 世界中的用户名和密码一样好，因此我们可以使用它来充当我们要攻击的机器。

运行该命令后，TGT 将保存到文件：

我们再次将其导入到我们的变量中以供我们的工具使用：

然后再次使用“-k”标志运行 secretsdump，以使用 TGT 转储机器的所有哈希值，从而让我们完全接管。

好了，至此，我对一些较老的对手技术的小小探索就结束了，这些技术曾帮助我攻陷了无数 Active Directory 环境。虽然这些技术比较老，但它们仍然是非常真实且可用的攻击路径，因此希望这能为测试人员提供一些额外的见解，并为防御者提供一些洞察力，让他们了解对手在其 Active Directory 域中可能采取的攻击路径。

您可以采取一些补救措施来阻止您域中的这些攻击，其中包括：

• 启用 SMB 签名

• 启用 LDAP 签名

• 将“机器帐户配额”设置为零

• 尝试从 NTLM 转向 Kerberos

直到下一次。