圖解NTLM與Kerberos ── 為什麼驗證會「回退」到NTLM

即使被稱為「我們是Kerberos環境」的公司內部網路,只要取出稽核記錄,一定會看到NTLM出現。而且會出現的,通常都是理應支援Kerberos的應用程式。

只要把兩個通訊協定「試圖證明什麼」並排來看,原因就一目了然。本文將以圖解方式掌握NTLM與Kerberos的運作方式,並附上官方文件的佐證,整理在什麼條件下會回退到NTLM,以及為什麼Microsoft想要淘汰NTLM。

自家公司環境的盤點步驟(稽核原則的設定、事件的追查方式、修正順序),整理於對應的文章「NTLM廢除後,業務應用程式會停止運作嗎」中。

1. 先講結論

• NTLM只證明「持有密碼的雜湊值」這件事。認證資訊是由網域名稱、使用者名稱、密碼的單向雜湊組成,¹ 在現行Windows使用的NTLMv2中,則是用從該雜湊值導出的金鑰,計算並回傳對「伺服器挑戰值+時間+用戶端挑戰值+目標資訊」的HMAC(2.2節)。²
• Kerberos證明的是「誰、對哪個服務」。它以連線目的地的服務名稱(SPN)為鍵值發行票證,因此目的地不同的票證無法使用。³
• 決定性的差異有三個:是否有相互驗證、(在網域帳戶的驗證中)伺服器是否需要向網域控制站查詢、是否能進行委派。這些Microsoft都有明確說明(第5章)。⁴
• 回退到NTLM的最大原因是「名稱」。Kerberos若無法從連線目的地的名稱解析出SPN,就無從開始。直接輸入IP位址、SPN未登錄、工作群組、無法到達DC的網路路徑,是四大主因(第6章)。⁵⁶
• 「Kerberos失敗」與「回退到NTLM」是不同的現象。前者是選擇了Kerberos之後才發生錯誤的狀態(例如時間偏差),驗證本身會中止。後者是無法啟動Kerberos、而在不知不覺間切換到NTLM的狀態,業務仍能繼續運作。排查障礙時,請先從這二選一開始判斷(6.5節)。⁷
• 中繼攻擊之所以成立,是因為NTLM沒有綁定「正在向誰驗證」的機制。Pass-the-Hash之所以成立,是因為驗證所需要的正是雜湊值本身(第7章)。⁸¹
• NTLMv1已經遭到移除。對象是Windows 11版本24H2與Windows Server 2025。NTLMv2雖為非建議使用,但仍可運作(第8章)。⁹
• 應用程式應該撰寫的是Negotiate。Negotiate會在Kerberos與NTLM之間擇一,除非參與驗證的系統中有任一個無法使用Kerberos,否則就會選擇Kerberos。¹

2. NTLM在做什麼

NTLM(Windows Challenge/Response)正如其名,是一種挑戰/回應方式的驗證通訊協定。根據Microsoft的說明加以彙整,認證資訊是由互動式登入時取得的網域名稱、使用者名稱、密碼的單向雜湊組成,為了在不讓密碼流經線路的情況下完成驗證,要求驗證的一方會執行計算,以證明自己「能夠存取安全保存的NTLM認證資訊」。¹

這裡的重點在於,驗證所使用的材料不是密碼本身,而是密碼的雜湊值。這一點正是稍後會看到的Pass-the-Hash之所以成立的條件。

2.1. 若是網域帳戶,會有三方登場

在已經登入的使用者以網域帳戶存取伺服器上資源的情境(非互動式驗證)中,會涉及用戶端、伺服器、網域控制站三方。這時的特徵是伺服器本身不進行驗證計算,而是交由網域控制站代為計算。¹

sequenceDiagram
    autonumber
    participant C as 用戶端
    participant S as 伺服器
    participant DC as 網域控制站

    Note over C: 登入時計算密碼的雜湊值,<br/>並捨棄密碼本身
    C->>S: 使用者名稱(明文)
    S->>C: 8位元組亂數(挑戰值)
    Note over C: 用密碼的雜湊值<br/>加密挑戰值
    C->>S: 回應
    S->>DC: 使用者名稱 / 挑戰值 / 回應
    Note over DC: 從SAM取出雜湊值,<br/>執行相同的計算
    DC-->>S: 一致則驗證成功
    S-->>C: 允許存取

圖1: NTLM的非互動式驗證(網域帳戶的情況)

Microsoft所展示的概念性步驟如下(實際的計算方式會如後文所述在NTLMv2中有所變化,但登場角色與職責分工仍如本圖所示)。¹

1. (僅限互動式驗證)使用者輸入網域名稱、使用者名稱、密碼。用戶端計算密碼的密碼學雜湊值,並捨棄實際的密碼。
2. 用戶端將使用者名稱以明文傳送給伺服器。
3. 伺服器產生8位元組的亂數(挑戰值、nonce)並傳送給用戶端。
4. 用戶端用使用者密碼的雜湊值加密這個挑戰值,並回傳結果(回應)。
5. 伺服器將使用者名稱、傳送給用戶端的挑戰值、收到的回應這三項資訊,傳送給網域控制站。
6. 網域控制站根據使用者名稱從SAM資料庫取出密碼雜湊值,並用它加密挑戰值。
7. 將自己計算出的結果與用戶端的回應比對,一致則驗證成功。

2.2. 實際的計算 ── NTLMv2稍微複雜一些

以上7個步驟,是Microsoft在概觀頁面所說明的基本形式。現行Windows實際使用的NTLMv2,比「用密碼的雜湊值加密挑戰值」還要再複雜一個層次。規格書([MS-NLMP])對此有如下定義。²

• 回應金鑰為 NTOWFv2 = HMAC_MD5( MD4(UNICODE(密碼)), 大寫化的使用者名稱 + 網域名稱 )
• 用戶端會將回應版本、時間、用戶端產生的8位元組挑戰值、目標資訊(AV配對)連接起來,建立 temp
• 作為回應核心的 NTProofStr = HMAC_MD5( 回應金鑰, 伺服器的挑戰值 + temp )

若只擷取材料與處理流程,就會得到下面這張圖。

flowchart TD
    PW["密碼"] --> MD4["MD4（UNICODE（密碼））<br/>= NT雜湊"]
    UD["大寫化的使用者名稱<br/>+ 網域名稱"] --> H1["HMAC_MD5"]
    MD4 -->|"作為金鑰使用"| H1
    H1 --> KEY["回應金鑰 NTOWFv2"]

    MAT["回應版本 / 時間 /<br/>用戶端的8位元組挑戰值 /<br/>目標資訊（AV配對）"] --> TEMP["temp"]

    SC["伺服器的挑戰值"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"作為金鑰使用"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

圖2: NTLMv2回應值的產生過程(密碼 → NT雜湊 → 回應金鑰 → HMAC)

也就是說,實際上計算的是不只混入伺服器的挑戰值,還混入了用戶端的亂數、時間、目的地資訊的HMAC。驗證端也會重現相同的計算。若帳戶存在於Active Directory中,就會把挑戰值與回應的組合傳送到網域控制站進行驗證;若是伺服器本機帳戶,則會使用伺服器自行保存的OWF來計算預期值。²

對本文的討論而言,重要的是即使變得複雜,以下兩點依然不變。

1. 金鑰的材料,如今依然是密碼的雜湊值。NTOWFv2 的出發點是 MD4(UNICODE(密碼)),也就是NT雜湊本身。² 這正是Pass-the-Hash之所以成立的原因(7.2節)。
2. 用戶端並未驗證伺服器是否為真品。Microsoft所說明的「NTLM沒有相互驗證」,在NTLMv2中依然不變。⁴

後續的說明,都是建立在這兩點之上。

2.3. 若是本機帳戶,兩方就能完成

若是本機帳戶,這張圖的右側就會消失。資源伺服器在帳戶為網域帳戶時,會向該網域的網域控制站上的驗證服務查詢,但若是本機帳戶,則會參照本機的帳戶資料庫。¹⁰ 也就是說,若是工作群組電腦,或是用檔案伺服器的本機帳戶連線到共用資料夾,網域控制站就不會登場,而是變成伺服器查看自己的SAM並自行判定的雙方往返。

這個差異,直接關係到6.3節所討論的「因為是本機帳戶所以無法使用Kerberos」這種相依性的盤點。即使查看網域控制站的稽核記錄,也不會看到這條路徑上的NTLM。

2.4. 從此設計衍生出的三個結論

檢視圖1,就能直接看出稍後會成為問題的特性。

• 伺服器沒有向用戶端證明任何事。這段往返是單向的,完全沒有伺服器用來證明「自己是真品」的步驟。
• 伺服器只有在自己持有雜湊值時才能判定。資源伺服器每次需要新的存取權杖時,若是網域帳戶就必須向網域控制站的驗證服務查詢,若是本機帳戶則必須參照本機的帳戶資料庫。¹⁰網域帳戶的驗證之所以要仰賴網域控制站,原因就在這裡。
• 回應「僅限於該次挑戰值」有效,但不會綁定目的地。由於每次的挑戰值都不同,無法重複使用同一個回應。但因為沒有能夠證明「這個回應是要給哪台伺服器」的要素,即使被轉手送到別的伺服器,也無從察覺。

3. 伺服器為什麼要詢問網域控制站

在網域帳戶的驗證中,只有網域控制站端的帳戶資料庫持有密碼的雜湊值。資源伺服器並不知道該使用者的雜湊值,因此無法靠自己完成驗證。所以每次驗證都必須向網域控制站查詢(傳遞驗證)。¹⁰¹(若是本機帳戶,伺服器會查閱自己的SAM並自行判定。以下關於依賴網域控制站的討論,說的是網域帳戶的情況。)

這在安全性與維運兩方面都要付出代價。Microsoft說明,在Kerberos出現之前的NTLM驗證中,應用程式伺服器每次驗證用戶端或服務時都必須連線到網域控制站,相對地,在Kerberos中,可更新的工作階段票證取代了傳遞驗證,除非需要驗證PAC(特殊權限屬性憑證),否則伺服器不需要前往網域控制站。⁴

也就是說,遷移到Kerberos既是安全性的議題,同時也是減少對網域控制站依賴的議題。

4. Kerberos在做什麼

Kerberos的構想與NTLM明顯不同。它是一種不需要每次驗證都重新確認身分,而是一開始只做一次身分確認、取得「票證」,之後就出示該票證的方式。

KDC(金鑰發布中心)在網域控制站上運作,並將Active Directory Domain Services的資料庫作為安全帳戶資料庫使用。⁴

sequenceDiagram
    autonumber
    participant C as 用戶端
    participant KDC as KDC (網域控制站)
    participant S as 服務 (以SPN識別)

    Note over C,KDC: AS交換 ── 身分確認與取得TGT
    C->>KDC: KRB_AS_REQ<br/>(使用者名稱 + 以長期金鑰加密的時間)
    Note over KDC: 若能以長期金鑰解密,即為本人
    KDC-->>C: KRB_AS_REP<br/>TGT(以krbtgt的金鑰加密) + 工作階段金鑰

    Note over C,KDC: TGS交換 ── 取得服務票證
    C->>KDC: KRB_TGS_REQ<br/>(TGT + 連線目的地的SPN + 驗證子)
    Note over KDC: 從SPN查出服務帳戶,<br/>並以其長期金鑰加密票證
    KDC-->>C: KRB_TGS_REP<br/>服務票證 + 工作階段金鑰

    Note over C,S: AP交換 ── 向服務出示
    C->>S: KRB_AP_REQ<br/>(服務票證 + 驗證子)
    Note over S: 能以自己的長期金鑰解密<br/>= 是給自己的票證
    S-->>C: KRB_AP_REP(若要求相互驗證)

圖3: Kerberos的三種交換(AS / TGS / AP)

圖例 ── AS = Authentication Service(驗證服務)、TGS = Ticket Granting Service(票證授予服務)、AP = Application(應用程式)。訊息名稱中的 _REQ 代表要求,_REP 代表回應。例如 KRB_TGS_REQ 即代表「向票證授予服務發出的要求」。

4.1. AS交換 ── 僅一次的身分確認

用戶端會向KDC傳送使用者名稱、網域名稱,以及用自己的長期金鑰(從密碼導出的金鑰)加密的時間戳記。這就是預先驗證(pre-authentication)。KDC若能以該長期金鑰解密,且時間戳記有效,就會判定「是本人」。³

KDC會回傳TGT(票證授予票證)。由於TGT是以KDC自身的長期金鑰(krbtgt帳戶的金鑰)加密的,用戶端無法讀取其內容。同時,用戶端與KDC之間所使用的工作階段金鑰,會以用戶端的長期金鑰加密後一併傳遞。³

這裡要掌握的重點是,時間戳記是驗證的一部分。Kerberos之所以對時間同步要求嚴格,原因就在這裡,預設容許的時間差為5分鐘。⁷ 一旦超出這個範圍,預先驗證就無法通過,Kerberos驗證本身就會以錯誤失敗(Windows的時間同步整理於「Windows時間同步(w32time)指南」)。這種「Kerberos失敗」與「回退到NTLM」是不同的現象。相關區分將在6.4節說明。

4.2. TGS交換 ── 申告「要連線到哪個服務」

這裡正是與NTLM決定性的分歧點。用戶端會將想要連線的服務名稱(SPN)告知KDC,並附上TGT與驗證子,要求取得服務票證。³

KDC會尋找對應該SPN的服務帳戶,用該帳戶的長期金鑰加密服務票證後回傳。³ 因此,

• 若無法解析出SPN,就不會發行票證。若服務帳戶沒有登錄SPN,KDC就無法鎖定對方。即使連線目的地是以IP位址指定,在預設情況下也不會嘗試Kerberos(6.1節)。
• 票證是「該目的地專用」的。由於無法用其他服務的長期金鑰解密,因此無法改變目的地重複使用。

4.3. AP交換 ── 向服務出示與相互驗證

用戶端會向服務出示服務票證與驗證子。服務會用自己的長期金鑰解密票證,取出其中的工作階段金鑰與授權資訊。能夠成功解密這件事本身,就是「這張票證是給自己的」的證明。³

若用戶端要求相互驗證,服務會用工作階段金鑰加密收到的時間戳記並回傳。用戶端透過驗證這個回傳值,就能確認對方是真正的服務。³ 這是NTLM所沒有的步驟。

5. 決定性的差異

「委派」這一列,在實務上還會進一步細分。委派可分為無限制委派、約束委派(constrained delegation)、資源型約束委派(RBCD)等種類,在前端Web應用程式以使用者的身分連線到後端SQL Server之類的架構中,選擇哪一種就會成為設計上的爭論點。本文不會深入探討,但請記住這些是日後查詢Kerberos委派時的下一步搜尋關鍵字。

這張表格下方兩列,直接就是「回退到NTLM的原因」。因為Kerberos的優勢(綁定目的地、驗證對方)是建立在能夠正確解析出名稱的基礎之上。

6. 為什麼會「回退」到NTLM

即使應用程式沒有直接指定NTLM,NTLM仍然會被使用。這是因為Negotiate就是這樣運作的。根據Microsoft的說明,Negotiate會在Kerberos與NTLM之間擇一,除非參與驗證的系統中有任一個無法使用Kerberos,否則就會選擇Kerberos。¹

也就是說,「變成NTLM」在絕大多數情況下,都只是「Kerberos無法使用」的另一種說法。

flowchart TD
    START["以 Negotiate 開始驗證"]
    Q1{"是網域<br/>帳戶嗎？"}
    Q2{"能否從連線目的地<br/>名稱建立 SPN？"}
    Q3{"該 SPN 是否<br/>已登錄？"}
    Q4{"能否連線<br/>到 KDC？"}
    KRB["以 Kerberos 驗證"]
    NTLM["回退到 NTLM"]

    START --> Q1
    Q1 -->|"否<br/>（工作群組／本機帳戶）"| NTLM
    Q1 -->|是| Q2
    Q2 -->|"否<br/>（直接輸入 IP 位址）"| NTLM
    Q2 -->|是| Q3
    Q3 -->|"否<br/>（SPN 未登錄／以別名存取）"| NTLM
    Q3 -->|是| Q4
    Q4 -->|"否<br/>（據點／VPN／FW）"| NTLM
    Q4 -->|是| KRB

圖4: Negotiate回退到NTLM的分歧

先以條件、原因、修正方式三個欄位,列出四大主因。詳情將在6.1節之後說明。

6.1. 以IP位址連線

這是最常見的原因。Microsoft明確指出,在預設情況下,若主機名稱是IP位址,Windows不會對該主機嘗試Kerberos驗證,而是回退到NTLM等其他有效的驗證通訊協定。¹¹ 稽核指南也寫道,若事件8001的「目標伺服器」既不是NetBIOS格式也不是FQDN格式,就不會使用Kerberos。⁵

而且,官方文件也列出了造成這種情況的原因:由於設定錯誤或供應商文件的緣故,使用IP位址而非DNS名稱的應用程式。⁵ 實務上也經常看到「因為名稱解析不穩定」而在過去改寫成IP位址的設定,就這樣一直保留至今的案例。

不過,這只是預設行為,並非絕對的限制。在Windows 10版本1507以及Windows Server 2016以後,有一套機制可以讓IP位址作為SPN的主機名稱使用。只要將用戶端的登錄值 TryIPSPN 設為1,並以 Setspn -s <服務類別>/<IP位址> <帳戶> 的形式手動登錄IP位址的SPN,即使目的地是IP位址,Kerberos也能成立。所要登錄的是用戶端實際要求的服務類別,如共用資料夾這類會對應到 HOST 的服務,只要 host/192.168.1.1 就夠了,但若是Web則需要 HTTP/192.168.1.1,SQL Server則需要連同連接埠一併登錄成 MSSQLSvc/192.168.1.1:1433 這樣的另一個SPN。即使只登錄了 host/,只要與所要求的SPN不一致,Kerberos就無法成立。Microsoft將這項功能定位為正是為了減少停用NTLM所帶來的影響。¹¹

話雖如此,這並非首選方案。Microsoft自己也表示,由於IP位址是暫時性的,可能因租約到期與更新而引發衝突或驗證失敗,通常不應取代主機名稱使用,以IP位址為基礎的SPN登錄屬於手動作業,應該只在無法切換為DNS主機名稱時才使用。¹¹ 對於稽核時發現的IP位址直接輸入,請優先考慮改為FQDN。TryIPSPN 是留給那些無論如何都做不到的對象的最後手段。

6.2. 未登錄SPN

這是第二常見的原因。Microsoft列舉了明明支援Kerberos卻仍使用NTLM的應用程式類型,其中之一就是SPN未正確設定的應用程式。⁵

如同在圖3的TGS交換中所見,KDC會從SPN查出服務帳戶,並用它來加密票證。若沒有SPN,KDC就無法鎖定「該服務的金鑰」。即使是以DNS別名(CNAME)或自訂主機名稱存取,只要沒有登錄該名稱的SPN,也會發生同樣的情況。這是一種應用程式運作正常,卻只有名稱沒有登記在名冊上的狀態。

6.3. 原本就在Active Directory之外

工作群組架構的終端裝置,或使用本機帳戶進行的共用存取,都不在Kerberos的舞台之上。Microsoft也表示,組態為工作群組成員的系統之Windows驗證,以及網域控制站以外的本機登入驗證,都會使用、也必須使用NTLM。¹⁰

這正是無法單純「禁止」NTLM的原因。第2階段預計提供的本機KDC,正是為了填補這個缺口的功能。⁶ 不過,請認知到能夠填補的,僅限於相互支援的Windows之間。若對象是舊版Windows,或NAS、多功能事務機等其他廠商的裝置,即使本機KDC問世,本機帳戶驗證也不會自動變成Kerberos。這種分類方式在實務篇的第5章、第6章中有說明。

6.4. 無法連線到KDC

在據點或透過VPN無法連線到網域控制站、Kerberos所需的連接埠被防火牆封鎖等網路路徑上的問題,同樣會引發回退。⁶ 由於無法與KDC通訊就無法取得票證,Negotiate只好選擇剩下的選項——NTLM。

6.5. 不要混淆「Kerberos失敗」與「回退到NTLM」

最後,先把容易混淆但實際上不同的兩件事分開來看。到目前為止的6.1〜6.4,全都是「無法啟動Kerberos」的情況。因為無法啟動,Negotiate才會選擇NTLM。

另一方面,選擇了Kerberos之後才失敗的情況則完全不同。最具代表性的例子就是時間偏差。若能解析出SPN且也連得到KDC,Negotiate就會先選擇Kerberos。之後若時間超出容許誤差(預設5分鐘),預先驗證就無法通過,會以Kerberos的錯誤形式失敗。⁷ 即使所選的通訊協定失敗了,Negotiate也不會自動切換到NTLM重試(除非應用程式明確以其他方式重試)。

這在實務上的意義很單純。即使搜尋事件8001來追查時間偏差造成的障礙,也找不到答案。症狀也不一樣。

請先分辨清楚「是回退到NTLM,還是Kerberos本身故障」,再開始調查。

7. 從攻擊角度看的差異 ── 中繼攻擊與Pass-the-Hash

Microsoft在原則設定的文件中明確指出,NTLM及NTLMv2驗證易受SMB中繼、中間人攻擊、暴力破解攻擊等各種惡意攻擊影響。⁸ 至於為什麼會如此,回頭看圖1就能解釋。

7.1. 中繼攻擊 ── 不綁定目的地的結果

sequenceDiagram
    autonumber
    participant V as 受害者的電腦
    participant A as 攻擊者的伺服器
    participant T as 真正的伺服器

    Note over V,A: 誘導至攻擊者的伺服器
    V->>A: 開始驗證(使用者名稱)
    A->>T: 以同一使用者開始驗證
    T-->>A: 挑戰值
    A-->>V: 將該挑戰值原封不動地轉送
    Note over V: 無法分辨是否<br/>來自真正的伺服器
    V->>A: 回應(以雜湊值導出的金鑰計算)
    A->>T: 將該回應原封不動地轉送
    Note over T: 若未要求簽章<br/>也未要求通道繫結
    T-->>A: 驗證成功 → 以受害者身分建立連線

圖5: NTLM中繼的成立(對象未使用簽章、通道繫結的情況)

攻擊者不需要知道密碼,也不需要知道雜湊值。只要把挑戰值與回應原封不動地從一邊轉送到另一邊即可。之所以能夠成立,是因為用戶端沒有辦法確認「這個回應是否真的送到了預期的對象手上」。

不過,並非對任何對象中繼都能得逞。被中繼的往返內容是否能成為可用的工作階段,取決於連線目的地的防禦措施。

• 對要求SMB簽章的對象無法得逞。Microsoft明確指出,附加在所有SMB訊息上的簽章包含整個訊息的雜湊值,因為會確認傳送端與接收端的身分,所以能防止中繼攻擊。¹² 此外,網域控制站在預設情況下會要求連線來源使用SMB簽章。¹²
• 對強制執行Extended Protection for Authentication(通道繫結)的服務也無法得逞。因為它會將驗證綁定到其下層的TLS通道,使得中繼到另一個通道的驗證無法通過。

換句話說,圖5所描繪的,是在既未套用簽章也未套用通道繫結、且會接受NTLM的對象這個條件下才能成立的路徑。反過來說,這也代表實務上現在就有可以採取的對策。與盤點NTLM並行,確認SMB簽章的要求狀況,是有價值的。

在Kerberos中,一開始就無法進行同樣形式的中繼。由於服務票證是以目的地服務的長期金鑰加密,即使拿到別的服務也無法解密。³ 此外,用戶端還能透過相互驗證來確認對方是否為真品。⁴

Microsoft之所以提供SMB用戶端的NTLM封鎖功能,理由正是如此。官方說明其目的在於防止讓惡意伺服器誘使用戶端傳送NTLM要求的手法。¹³ 此外,在SMB簽章相關的建議中,Microsoft也提到應使用Kerberos而非NTLMv2,以確保工作階段金鑰從一開始就處於強度足夠的狀態,以及不要以IP位址或CNAME記錄連線到共用資料夾(因為這樣會使用NTLM而非Kerberos)。¹² 這與6.1節、6.2節所談的是同一件事。

7.2. Pass-the-Hash ── 雜湊值等同於密碼

flowchart LR
    P["密碼"] -->|"單向雜湊"| H["密碼的雜湊值"]
    H -->|"導出回應金鑰<br/>並計算HMAC"| R["回應"]
    R --> AUTH["驗證成功"]
    STEAL["從終端裝置<br/>竊取雜湊值"] --> H
    NOTE["不需要<br/>明文密碼"] -.-> STEAL

圖6: 驗證所需要的是雜湊值,而不是明文密碼

NTLM的認證資訊是密碼的單向雜湊值。¹ 在NTLMv2中,是以該 MD4(UNICODE(密碼)) 為金鑰導出回應金鑰,再用該金鑰計算HMAC來產生回應。² 即使計算的形式改變了,出發點是雜湊值這一點依然不變。也就是說,驗證所需要的是雜湊值,而不是明文密碼。

這個結論在維運上有著相當沉重的意義。即使把密碼設得又長又複雜,也堵不住雜湊值被竊取的路徑。Microsoft也將Pass-the-Hash與暴力破解、破解密碼並列,列為SMB的NTLM封鎖功能所要對抗的攻擊之一。¹³

Kerberos雖然也存在長期金鑰,但在日常驗證中往來的是有效期限內的票證與工作階段金鑰。³ 一旦被竊取,其有效範圍是不同的。

8. NTLMv1、NTLMv2與「移除」

NTLM並不是單一的通訊協定,而是包含LAN Manager版本1、2與NTLM版本1、2在內的一組驗證通訊協定。¹⁰

目前的處理方式區分如下。

換言之,並不是「因為是NTLMv2所以暫時放著不管也沒關係」。不過優先順序很明確:只會說NTLMv1的裝置或主機是最優先事項。若稽核記錄中出現記載為 NTLM V1 的主機,直接升級到新版Windows就會導致驗證無法通過。版本的辨別方式(查看安全性記錄中的「套件名稱 (僅限 NTLM)」)在實務篇文章的4.4節有說明。⁵

此外,限制NTLM的稽核及封鎖原則,對NTLMv1與NTLMv2兩者具有相同的效果。⁵ 套用限制時,行為並不會因版本而異。

9. 接下來會如何發展

Microsoft所指出的方向有三個。

第一,是在應用程式端使用Negotiate。應該將NTLM呼叫替換為Negotiate呼叫,這正是非建議使用公告本身所附帶的指示。⁹ 官方也明確指出,應用程式不應直接存取NTLM安全套件。¹

第二,是減少原本就需要用到NTLM的場合。預計於第2階段(2026年下半年)提供的IAKerb與本機KDC,正屬於此類。⁶ 這是要從通訊協定端填補6.3節所看到的兩個缺口——「因為是本機帳戶所以無法使用Kerberos」、「因為連不到網域控制站所以無法使用Kerberos」——的嘗試。不過,能夠填補的範圍是有限的。IAKerb所解決的是與網域控制站的連線可達性,而不是對方是否支援。本機KDC也一樣,只有在相互支援的Windows之間才有效。若對象是其他廠商的NAS或多功能事務機,即使等到第2階段,狀況也不會改變,因此必須自行從裝置更換、加入網域、切換為其他通訊協定、例外管理當中擇一選擇。

第三,是改變預設值。在第3階段,計畫在下一個主要版本中將網路NTLM驗證預設為停用。⁶ 不過官方也表示,仍可透過原則重新啟用。

這個順序是有意義的。因為是「先消除使用的理由,再改變預設值」的順序,所以事先將目前公司內部殘留的NTLM相依性,分為可望在第2階段解決的項目(相互支援的Windows之間的本機帳戶驗證、DC連線可達性),以及必須自行修正的項目(直接輸入IP位址、SPN未登錄,以及舊版Windows或其他廠商裝置為對象的本機帳戶驗證),就能避免做無謂的工程。若把最後這一項歸類為「等待第2階段」,一旦預設停用生效,就會以障礙的形式浮上檯面。具體的分類步驟整理於實務篇。

10. 總結

• NTLM是一種以挑戰/回應方式證明「持有密碼的雜湊值」的通訊協定。判定作業若是網域帳戶就由網域控制站代行,若是本機帳戶則由伺服器自行查閱自己的SAM進行。¹¹⁰
• Kerberos證明的是「誰、對哪個服務」。服務票證是以目的地服務的長期金鑰加密,因此無法改變目的地重複使用。³
• 決定性的差異在於:是否有相互驗證、每次驗證是否需要查詢DC、能否進行委派。⁴
• 回退到NTLM,幾乎都是發生在「無法啟動Kerberos」的時候。直接輸入IP位址、SPN未登錄、位於Active Directory之外、無法連線到KDC,是四大主因。⁵⁶¹¹
• 另一方面,像時間偏差這種選擇了Kerberos之後才失敗的問題,不會以回退到NTLM的形式出現,而是以驗證錯誤的形式呈現。即使搜尋事件8001也找不到。⁷
• 中繼攻擊之所以成立,是因為NTLM的回應不會綁定目的地。Pass-the-Hash之所以成立,是因為驗證所需要的正是雜湊值本身。⁸¹¹³
• NTLMv1已經遭到移除(Windows 11 24H2 / Windows Server 2025),包含NTLMv2在內的所有版本均為非建議使用。⁹
• 應用程式應該撰寫的是Negotiate。在此基礎上,將連線目的地的名稱統一為FQDN、並登錄SPN,就是讓Kerberos得以成立的實務內容。¹⁵

相關文章

• NTLM廢除會讓業務應用程式停擺嗎 ── 稽核記錄的擷取方式,以及消除相依性的順序
• 網路磁碟機與 UNC 路徑的陷阱 ── 業務應用程式處理檔案伺服器(共用資料夾)的實務
• Windows的時間同步(w32time)與業務系統 ── 從機制原理解決「日誌時間戳記對不上」的問題
• 使用 Get-WinEvent 有效率地調查事件記錄 ── 篩選的速度決定調查所需的時間
• PowerShell 中安全處理認證資訊 ── 把明文密碼逐出腳本
• Windows 的 TPM 是什麼 ── 圖解「不讓金鑰外流的保險箱」與測量啟動
• 資訊安全10大威脅 2026 ── 排行榜的正確解讀方式,以及中小企業真正該做的對策

相關諮詢領域

合同會社小村軟體承接因驗證方式檢討而生的Windows業務應用程式改造,以及Kerberos/NTLM相關驗證問題的原因調查。

• Windows應用程式開發
• 缺陷調查・原因解析
• 既有資產活用・遷移支援
• 聯絡我們

參考連結

</content>

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

NTLM與Kerberos,說到底差異在哪裡？

最大的差異在於「能不能確認對方的身分」。Microsoft明確指出,在NTLM中,用戶端無法驗證伺服器的身分,某個伺服器也無法驗證另一個伺服器的身分。NTLM是為「可以假設伺服器是真品」的環境所設計的,而Kerberos並不做這樣的假設。第二個差異是伺服器是否需要向網域控制站查詢。在NTLM中,若以網域帳戶進行驗證,應用程式伺服器每次驗證用戶端時都會連線到網域控制站(若是伺服器本機帳戶,伺服器會查閱自己的帳戶資料庫並自行判定,因此不會用到網域控制站)。在Kerberos中,可更新的工作階段票證取代了這種傳遞驗證(pass-through authentication),因此除非需要驗證PAC,否則伺服器不需要前往網域控制站。第三個差異是Kerberos支援服務委派(服務代表用戶端連線到其他服務的機制)。

明明應該支援Kerberos,為什麼卻變成NTLM？

Kerberos是以「連線目的地的名稱」為鍵值來發行票證的機制,因此名稱無法解析就無法成立。用戶端會向KDC出示連線目的地的SPN(服務主體名稱)以要求服務票證,但在預設情況下,若主機名稱是IP位址,Windows不會嘗試Kerberos驗證;而如果服務帳戶沒有登錄SPN,KDC也就無法發出票證。Microsoft的稽核指南也寫道,若事件8001的「目標伺服器」既不是NetBIOS名稱也不是FQDN形式,就不會使用Kerberos(至於IP位址,可以在用戶端設定TryIPSPN並手動登錄IP位址的SPN,例外地讓Kerberos成立,但這被視為「無法改成DNS名稱時的最後手段」)。除此之外,工作群組電腦或本機帳戶的驗證(原本就在Active Directory之外)、無法連線到網域控制站的據點、對沒有信任關係的對象進行驗證,也都是Kerberos無法成立的條件。由於Negotiate在無法使用Kerberos時會選擇NTLM,因此在這些情況下就會「回退」到NTLM。

NTLM中繼攻擊是什麼？為什麼會成立？

這是一種攻擊者將受害者誘導至自己的伺服器,再將收到的NTLM驗證往返內容原封不動地中繼給真正的伺服器,藉此冒充受害者的攻擊。之所以能成立,是因為NTLM的挑戰/回應機制沒有綁定「正在向誰驗證」的機制。用戶端只是根據伺服器發出的挑戰值計算並回傳回應值,用戶端本身沒有辦法確認這個回應值究竟是要送給真正的伺服器,還是被攻擊者中繼出去的。Microsoft自己也在原則設定的文件中明確指出,NTLM及NTLMv2驗證易受SMB中繼、中間人攻擊、暴力破解攻擊等各種惡意攻擊影響。不過,並非對任何對象中繼都能得逞。若連線目的地要求SMB簽章,由於簽章會確認傳送端與接收端的身分,中繼便無法成立;強制執行Extended Protection for Authentication(通道繫結)的服務也是如此。反過來說,沒有套用簽章也沒有通道繫結、且會接受NTLM的對象,就成為攻擊目標。在Kerberos中,由於服務票證是以該服務的長期金鑰加密,即使把目的地不同的票證拿到另一個服務,也無法解密。

Pass-the-Hash是指不用破解密碼就能冒充身分嗎？

沒錯。NTLM的認證資訊是由網域名稱、使用者名稱、密碼的單向雜湊組成。在現行Windows使用的NTLMv2中,回應金鑰是以密碼的MD4雜湊(NT雜湊)為金鑰,以HMAC方式導出,再用該金鑰對伺服器挑戰值、時間、用戶端挑戰值、目標資訊彙整而成的內容計算HMAC。這已經不只是單純把挑戰值加密而已,但出發點是密碼的雜湊值,這一點並沒有改變。也就是說,驗證所需要的是雜湊值,而不是明文密碼。因此,能從終端裝置的記憶體等處取出雜湊值的攻擊者,不需要破解密碼就能以該使用者的身分完成驗證。即使把密碼設得又長又複雜,也堵不住這條路徑。Microsoft之所以提供SMB用戶端的NTLM封鎖功能,其中一個理由正是為了對抗Pass-the-Hash攻擊。

只要使用NTLMv2,暫時就算安全嗎？

NTLMv2確實比NTLMv1更強,但並沒有因此被排除在非建議使用(deprecated)之外。Microsoft的非建議使用功能清單指出,包含LANMAN、NTLMv1、NTLMv2在內的所有版本NTLM,都不再是積極開發的對象,屬於非建議使用。限制原則的行為也一樣,官方說明稽核與封鎖原則對這兩個版本具有相同效果。另一方面,NTLMv1的處理方式不同,不只是非建議使用,而是已進入移除階段,自Windows 11版本24H2與Windows Server 2025起已遭移除。因此結論不是「因為是NTLMv2所以暫時可以放著不管」,而是「NTLMv1現在就是期限,NTLMv2則要為未來的預設停用推進盤點」。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。