检查有关 NTLM 身份验证中继的 LDAP 保护

作者：Sec-Labs | 发布时间：2022-03-02 17:39:09

简介

项目主要用于检查有关 NTLM 身份验证中继的 LDAP 保护

项目地址

https://github.com/zyn3rgy/LdapRelayScan

LDAP 中继扫描

用于检查域控制器以获取有关 NTLM 身份验证中继的 LDAP 服务器保护的工具。如果您对基于错误的枚举的细节感兴趣，请参见下文。有关在确定缺少 LDAP 保护时可以执行的操作的详细信息，请参阅参考资料部分。

概括

尝试在域控制器上中继 NTLM 身份验证 LDAP 时，有几个服务器端保护。此工具尝试枚举的 LDAP 保护包括：

LDAPS -通道绑定
LDAP -服务器签名要求

可以从未经身份验证的角度确定通过 SSL/TLS 对 LDAP 执行通道绑定。这是因为在 LDAP 绑定过程中验证凭据之前，将发生与缺少正确执行通道绑定能力的 LDAP 客户端相关的错误。

但是，要确定是否强制执行标准 LDAP 的服务器端保护（服务器签名完整性要求），必须首先在 LDAP 绑定期间验证客户端凭据。识别执行此保护的潜在错误是从经过身份验证的角度识别的。

TL;DR - 可以未经身份验证检查 LDAPS，但检查 LDAP 需要身份验证。

用法

注意：DNS 需要正确解析。如果您正在通过 SOCKS 路由或在未加入域的主机上运行，请确保它正常工作。

该工具有两种方法，LDAPS（默认）和BOTH。LDAPS 只需要域控制器 IP 地址，因为此检查可以在未经身份验证的情况下执行。BOTH 方法将需要用户名和密码或 NT 哈希。Active Directory 域不是必需的，它将通过匿名 LDAP 绑定来确定。

例子

注意：在客户端使用 python3.9 测试，针对未修补的 Windows Server 2016 和最新的 Windows Server 2022

python3.9 LdapRelayScan.py -method LDAPS -dc-ip 10.0.0.20
python3.9 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 
python3.9 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -p badpassword2
python3.9 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -nthash e6ee750a1feb2c7ee50d46819a6e4d25

基于错误的枚举规范

[LDAPS] 通道绑定令牌要求

在自CVE-2017-8563以来已修补的域控制器上，已经存在强制执行 LDAPS 通道绑定的功能。特定策略被调用Domain Controller: LDAP server channel binding token requirements，可以设置为Never、When supported或Always。默认情况下也不需要这样做（在撰写本文时）。

在域控制器上通过 SSL/TLS 流量解密和监视 LDAP 允许在强制执行通道绑定与未强制执行通道绑定时识别绑定尝试期间的错误差异。当尝试使用无效凭据通过 SSL/TLS 绑定到 LDAP 时，您将收到预期的resultCode 49，并且您将在错误消息内容中看到data 52e。但是，当强制执行通道绑定并且 LDAP 客户端未计算并包含通道绑定令牌 (CBT) 时，resultCode 仍将为 49，但错误消息内容将包含data 80090346含义SEC_E_BAD_BINDINGS或客户端的 Supplied Support Provider Interface (SSPI)通道绑定不正确。

data 8009034注意： LDAP over SSL/TLS 绑定期间的错误提及[1] [2] [3] [4] [5]

“从不”vs“支持时”vs“总是”

此特定错误可以很容易地说明Domain Controller: LDAP server channel binding token requirements策略何时设置为Always. 只需使用不支持通道绑定的客户端尝试基于 NTLM 的 LDAPS 绑定，并data 80090346在响应中查找错误。但是，当策略未设置为Always时，设置为时又如何When supported呢？答案是：使用基于 NTLM 的身份验证绑定到 LDAPS，并故意错误计算通道绑定信息。

首先，我们需要一个支持通道绑定的 LDAP 客户端。SkelSec在msldap中对此的实现将用于实现 PoC。在 NTLM 质询/响应过程中，通道绑定显示为AV_PAIR值，特别是在 Type 3 或 AUTHENTICATE_MESSAGE中。下面是对域控制器上一些解密的 LDAPS 流量的另一种看法，以查看来自支持通道绑定的客户端的绑定尝试将是什么样子：

当相关政策设置为时，故意错误计算此值When supported将产生相同的data 80090346错误。这使我们能够从未经身份验证的角度区分当前存在的该策略的所有可能设置。

[LDAP] 服务器签名要求

在域控制器上，调用的策略Domain Controller: LDAP server signing requirements设置为None, Require signing，或者只是未定义。如果未定义，则默认为不需要签名（在撰写本文时）。当sicily NTLM或简单绑定尝试以8 的 resultCode响应时，识别此保护所需的错误，表示strongerAuthRequired. 仅当验证 LDAP 绑定期间的凭据时才会发生这种情况。

参考

一些宝贵的资源，用于将此材料的上下文化以及它如何适应常见的攻击场景。

@HackAndDo - NTLM 中继
@_nwodtuhs - NTLM 中继思维导图
@_dirkjan - PrivExchange、ADCS ESC8 编写、用于 RBCD 的 NTLM 继电器编写等
@domchell - Farmer的实现和解释
@elad_shamir -在多种情况下滥用 RBCD的详尽解释，以及影子凭证
@tifkin_ & @topotam77 - NTLM 身份验证强制方法
@skelsec -支持通道绑定的msldap

标签：工具分享