使用ntlmrelayx在任何地方進行中繼憑據

0x00 前言

      經過Fox-IT咱們可讓客戶瞭解其企業組織中出現的常見安全風險。當攻擊者能夠利用NT LAN Manager身份驗證協議（如下簡稱：NTLM身份驗證）時，憑據重用就有這樣的風險，即這種協議一般在Microsoft Active Directory中保持啓用狀態。NTLM認證中的不安全性已有超過15年。該協議可能被濫用，是經過一個被稱爲「中繼」的過程劫持受害者的會話，該過程經過將受害者的憑據轉發到與預期不一樣的服務來濫用受害者的憑據。在許多狀況下，默認狀況仍然支持和啓用NTLM身份驗證，即便它已被更安全的Kerberos替換爲默認身份驗證方法。

在本文中，咱們將演示如何使用NtlmRelayx將憑證中繼到LDAP、IMAP和MSSQL，NtlmRelayx是著名的smbrelayx工具的FOX IT擴展。要防護此類攻擊：

• 若是可能，請徹底禁用企業組織內的NTLM並切換到Kerberos。
• 若是沒法禁用NTLM，請參閱此文中討論的設置和指南，以下降憑據重用的風險。 

0x01 NTLM中繼簡要說明

NTLM身份驗證是一種基於挑戰 - 響應的協議。挑戰- 響應協議使用一個通用的共享祕密（在本例中是用戶密碼）來驗證客戶端。服務器發送一個質詢，客戶端回覆此質詢的響應。若是質詢與服務器計算的質詢相匹配，則接受身份驗證。NTLM身份驗證是一種複雜的協議，這裏只是簡單的闡述。能夠在http://davenport.sourceforge.net/ntlm.html中找到很是詳細的描述。

1.NTLM身份驗證流程

NTLM身份驗證協議有3個步驟：

1. 協商身份驗證：NTLM身份驗證的第一步是協議協商，以及客戶端支持的功能。在此階段，客戶端將身份驗證請求發送到服務器，包括客戶端接受的NTLM版本。
2. 服務器挑戰：服務器響應本身的消息，指示它接受的NTLM版本以及要使用的功能。此消息還包括「質詢」值，這在身份驗證中很重要。
3. 身份驗證響應：客戶端根據質詢返回響應，幷包含所屬的用戶名和域的密碼

交互3條消息後，服務器將回復一條消息，代表身份驗證成功，或者身份驗證失敗。根據使用的協議，客戶端與服務器之間的會話如今已通過身份驗證。此過程以下圖所示：

 

 

 

2.濫用NTLM

做爲攻擊者，若是客戶端可以被劫持鏈接到攻擊者，那麼這個過程可能會被濫用。如何作到這一點將在下一節中闡述。一旦攻擊者擁有一個進行身份驗證的鏈接客戶端，他們就能夠輕鬆地將3條消息轉發到客戶端和服務器之間的服務器，直到質詢 - 響應週期完成。

 

在鏈接經過身份驗證時，攻擊者能夠簡單地向客戶端發送錯誤消息，或者斷開鏈接。以後，攻擊者可使用該會話從中繼身份驗證的用戶中與服務器進行交互。

 3.跨協議（cross)中繼

NTLM身份驗證被封裝在其餘協議中，但不管上層協議如何，消息都是相同的。這容許在其餘協議中使用NTLM消息。例如，使用HTTP進行身份驗證的客戶端會在「受權」標頭中發送NTLM身份驗證消息。攻擊者能夠從HTTP標頭中取出這些消息，並在其餘協議（如SMB）中使用它們。

NTLM在多種協議中被支持，例如SMB，HTTP（S），LDAP，IMAP，SMTP，POP3和MSSQL。

4.得到中繼流量

還有一點還沒有解釋，那就是如何讓客戶端與攻擊者鏈接，而不是與真正的服務器鏈接。有幾種方法能夠得到可中繼的流量：

• 以不安全的方式向以其解析IP的主機的流量  
• 濫用AutoDiscovery協議致使的流量   
• 經過中間人攻擊得到的流量  

4.不安全的名稱解析協議  

在Fox-IT中常常遇到使用不安全協議的名稱解析流量。工做站或服務器一般被配置爲網絡中再也不存在的主機或沒法使用DNS解析其主機名的主機。當這種狀況發生時，Windows工做站會退回到名稱解析協議，如NBNS和LLMNR，它們依賴廣播流量來請求同一網絡中的主機將主機名解析爲IP地址。因爲同一網段中的全部主機均可以查看此流量（取決於防火牆配置），所以任何主機均可以回覆請求。這使攻擊者有機會僞造所請求名稱的地址。該過程以下所示。

 

5.自動發現（WPAD)協議  

也許過去幾年黑客中最臭名昭著的功能是Windows代理自動檢測（WPAD）功能。此功能基本上會經過DNS查找名爲WPAD的主機名，若是不成功，則能夠經過上面描述的llmnr和nbns進行攻擊，而後鏈接到它能找到的第一個主機。濫用此功能變得更加容易，由於當提示進行身份驗證時，工做站將自動嘗試使用NTLM身份驗證進行驗證，而後攻擊者可能會中繼該身份驗證。微軟在2016年6月修補了這方面的一些問題，但有時Fox-IT仍在網絡中遇到這種狀況。

6.中間人攻擊  

攻擊者接管受害者流量的中間人攻擊一般在企業網絡中具備很大的破壞性，尤爲是在使用諸如ARP欺騙之類的技術時。可是，當企業設備鏈接到不受信任的網絡（例如公共WiFi網絡）時，攻擊者能夠攻擊受害者並攔截不受TLS保護的流量，將其重定向到受害者工做站信任的位置。而後，若是啓用了自動內部網檢測（這是默認設置），受害者將自動進行身份驗證。

 

 7.使用Ntlmrelayx在任何地方中繼NTLM

有幾種工具能夠濫用NTLM身份驗證。其中一個是smbrelayx，它是Core Security的impacket 庫的一部分。Ntlmrelayx是由Fox-IT開發的smbrelayx工具的擴展和部分重寫。它具備適用於各類協議的中繼功能。該工具接受多個目標，在每一個目標之間循環，以找到要進行身份驗證的系統。該工具具備一個SMB和HTTP服務器，從中它能夠將NTLM身份驗證中繼到SMB、HTTP（S）、IMAP、LDAP和MSSQL。

 8.中繼到SMB

中繼到smb是一種經典攻擊，它已是smbrelayx的一部分。若是您不熟悉此攻擊，中繼到SMB容許攻擊者在禁用了SMB簽名的主機上執行文件，前提是被中繼的用戶在設備上具備管理權限。對於非管理用戶，ntlmrelayx添加了啓動smbclient shell的選項，容許攻擊者與共享進行交互，例以下載或上傳文件。可使用交互式標誌（-i）完成此攻擊，該標誌將生成本地TCP shell，該shell能夠與例如netcat鏈接。

 

 9.中繼到LDAP

中繼到LDAP是Ntlmrelayx中的一個新增功能。LDAP是一個有趣的協議，由於它用於直接查詢目錄，該目錄包含了許多攻擊者感興趣的信息。更有趣的是，在默認狀況下，域中的全部賬戶（包括計算機賬戶）均可以讀取這些信息的大部分。這就是Ntlmrelayx與另外一個Fox IT開發工具ldapdomaindump集成的地方。此工具嘗試從域中收集儘量更多的信息，包括用戶，其組成員身份，域計算機和域策略。

除了收集信息以外，還能夠經過LDAP寫入目錄。若是ntlmrelayx遇到具備域管理員權限的用戶，它將建立一個新的域管理員賬戶，該賬戶當即使攻擊者能夠徹底控制域：

 10. 中繼到IMAP

雖然在當前版本的Exchange中默認狀況下未啓用，但許多企業組織在其Exchange服務器上經過IMAP進行NTLM身份驗證。這容許中繼到IMAP，使攻擊者能夠直接訪問受害者的電子郵件。當中繼到IMAP時，ntlmrelayx能夠選擇在電子郵件中搜索關鍵字，或者只在用戶的指定收件箱中下載全部最新的電子郵件。

11.中繼到MSSQL

中繼到MSSQL目前僅做爲理論證實存在，但能夠在命令行上指定查詢，這些查詢將在數據庫的受害者上中被執行

0x02 緩解措施

那麼，在企業組織能夠作些什麼來抵禦這些攻擊呢？上述全部攻擊都濫用了NLTM身份驗證協議，所以惟一完整的解決方案是徹底禁用NTLM並切換到Kerberos。可是，許多企業組織都有不支持Kerberos身份驗證的舊產品或操做系統，所以禁用NTLM將對業務產生至關大的影響。做爲緩解措施，那麼能夠啓用多種設置以減小最小化的中間人攻擊風險。

• 啓用SMB簽名：SMB簽名將經過要求對全部流量進行簽名來阻止中繼到SMB。簽名要求用戶密碼對消息進行身份驗證，所以中繼鏈接的攻擊者沒法發送服務器接受的任何通訊，由於攻擊者沒有擁有受害者的密碼。
• 啓用LDAP簽名：與SMB簽名相似，LDAP簽名可防止與LDAP的未簽名鏈接。應該注意的是，經過TLS到LDAP的鏈接被認爲是簽名的，所以此設置不會阻止經過TLS到LDAP的中繼攻擊。
• 啓用身份驗證擴展保護：身份驗證的擴展保護有助於防止某些中繼攻擊，方法是確保用於鏈接到服務器的TLS通道與客戶端進行身份驗證時使用的通道相同。此設置主要適用於IIS。
• 啓用SPN目標名稱驗證：SPN目標名稱驗證是另外一種緩解措施，它能夠經過驗證客戶端認爲正在進行身份驗證的目標名稱來阻止中間人攻擊到SMB。若是名稱與服務器不匹配，則拒絕身份驗證。
• 確保內部網站使用HTTPS：當經過不安全的HTTP協議訪問內部網站時，用戶沒法驗證鏈接的真實性。經過強制全部內部網站僅經過HTTPS方法，中間人攻擊變得不那麼有效。

通常強化以防止中間人攻擊 

除了這些特定的服務器端設置以外，如下通常強化能夠防止NTLM中繼：

• 禁用自動Intranet檢測：若是域中須要NTLM身份驗證，請確保瀏覽器（主要是Internet Explorer）僅自動對受信任的網站進行身份驗證。經過組策略，能夠禁用自動Intranet檢測，而且只能自動對應應用自動身份驗證的內部網站白名單進行身份驗證。如上所述，強烈建議僅在此處使用HTTPS網站。
• 禁用Windows代理自動檢測：雖然WPAD的安全問題主要由Microsoft MS16-077安全更新解決，但仍然建議經過組策略禁用WPAD。
• 禁用LLMNR / NBNS：在配置良好的網絡中一般不須要這些不安全的名稱解析協議。禁用它們會減小攻擊者進行名稱解析欺騙的可能性，從而使攻擊者更難以欺騙受害者身份鏈接到攻擊者服務器。

0x03 獲取Ntlmrelayx

Ntlmrelayx已經提交到Impacket存儲庫中，能夠在Impacket 示例目錄中找到。

0x04 更多資源

咱們在嘗試理解NTLM方面的大部分研究都是在如下資源的幫助下完成的：

• http://davenport.sourceforge.net/ntlm.html（清楚的解釋，但有些部分已過期，基於在Microsoft開源以前對協議進行逆向）  
• http://ubiqx.org/cifs/SMB.html#SMB.8.5（與上面的相似）
• https://msdn.microsoft.com/en-us/library/cc236621.aspx（官方協議文檔，很是技術性） 
• https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx(LMCompatibilityLevel說明）