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

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

這裡所說的「回退到NTLM」，並不是驗證因錯誤而中止，而是在無法使用Kerberos的情況下切換成NTLM。即使業務照常運作，也不代表實際使用的就是你期待的驗證方式。

本文會先用圖比較NTLM與Kerberos各自以什麼為材料、確認的又是誰。只要看懂這項差異，連線目的地的名稱或帳戶種類為什麼會讓驗證切換到NTLM，以及中繼攻擊與Pass-the-Hash為什麼會成立，都能從同一套機制說明。

閱讀的順序是機制上的差異 → 切換的條件 → 防禦與遷移的判斷。如果目的是排查故障，請先分清楚是「以NTLM在運作」還是「驗證本身停住了」，再從第1章依目的整理的導覽前往第6章。

自家環境的盤點步驟（稽核原則的設定、事件的追查方式、修正順序），整理於對應的文章「NTLM廢除會讓業務應用程式停擺嗎」。

1. 先講結論

一開始要掌握的是驗證的材料、切換到NTLM的條件、安全性與遷移方針這三點。

掌握機制上的差異

NTLM是以雜湊值為基礎產生回應，Kerberos則使用指定了連線目的地的票證。 NTLM的認證資訊是網域名稱、使用者名稱，再加上密碼的單向雜湊。¹ 在NTLMv2中，會用從該雜湊值導出的金鑰，以伺服器的挑戰值、時間、用戶端的挑戰值、目標資訊為材料計算HMAC（2.2節）。²

另一方面，Kerberos是以SPN（連線目的地的服務名稱）為依據發行服務票證，確認的是「誰、對哪個服務」。³ 這項差異衍生出相互驗證、網域帳戶驗證時對網域控制站的查詢、對其他服務的委派這三個不同之處（第5章）。⁴

區分「切換」與「驗證錯誤」

「以NTLM運作」與「因Kerberos錯誤而停住」，要從不同的入口調查。 切換到NTLM的主要原因是直接輸入IP位址、SPN未登錄、工作群組，以及無法連線到網域控制站的網路路徑。其中又以能否從連線目的地的名稱解析出SPN最為關鍵（第6章）。⁵⁶

相對地，像時間偏差這種在Kerberos已經被選用之後才失敗的問題，是驗證本身停住的問題。不要以為失敗之後就一定會改用NTLM重試（6.5節）。⁷

掌握安全性與遷移方針

即使使用NTLMv2，中繼攻擊與Pass-the-Hash的問題依然存在。 中繼源自驗證往返不綁定目的地，Pass-the-Hash則源自雜湊值本身就是驗證的材料。包括連線目的地是否要求SMB簽章或通道繫結在內，第7章會逐一確認成立條件。⁸¹

NTLMv1已在Windows 11版本24H2與Windows Server 2025中移除。NTLMv2雖然仍可運作，但屬於非建議使用的對象（第8章）。⁹ 應用程式不應直接指定NTLM，而要使用優先選擇Kerberos的Negotiate，並在此之上整備能讓Kerberos成立的名稱、SPN與連線路徑。¹

依目的與症狀閱讀

本文說明的是機制與判斷。要實際進行稽核設定與盤點的步驟，請前往開頭介紹的實務篇。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 35 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. NTLM在做什麼

本章會先分開產生回應的一方與驗證的一方。先看網域帳戶情境下三方的往返，再確認NTLMv2實際的計算方式，以及本機帳戶時的差異。

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

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

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

假設已經登入的使用者，要以網域帳戶存取伺服器上的資源。這屬於非互動式驗證，登場的有下列三方。¹

重點在於，資源伺服器並不是自行驗證網域使用者的回應，而是把計算交給網域控制站。

圖1與其下的7個步驟，是Microsoft概觀頁面所呈現的概念性程序。NTLMv2精確的回應計算方式會在2.2節處理。用圖1讀「誰把驗證交給誰」，用圖2讀「怎麼計算」，就不會把兩者混在一起。¹

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的非互動式驗證（網域帳戶的情況）

把圖1拆成步驟來看，就是下列7個步驟。NTLMv2本身的回應計算方式，會在接下來的2.2節重新解讀。

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

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

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

產生回應金鑰，再從挑戰值等材料計算HMAC

• 回應金鑰為 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. 若是本機帳戶，兩方就能完成

若是本機帳戶，圖1的右側（網域控制站）就會消失。

資源伺服器在帳戶為網域帳戶時，會向該網域的網域控制站上的驗證服務查詢，但若是本機帳戶，則會參照本機的帳戶資料庫。¹⁰

也就是說，若是工作群組電腦，或是以檔案伺服器的本機帳戶連線到共用資料夾，網域控制站就不會登場，而是變成伺服器查看自己的SAM並自行判定的兩方往返。

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

2.4. 從這個設計衍生出的三個結果

從目前為止的往返，可以取出三項日後會連到故障與攻擊的性質。

第2列的查詢之所以必要，是因為資源伺服器每次需要新的存取權杖時都要確認一次。網域帳戶會向網域控制站的驗證服務確認，本機帳戶則確認本機的帳戶資料庫。¹⁰

此外，由於挑戰值每次都會改變，同一個回應無法原樣重複使用。但是，把當下收到的挑戰值與回應在與另一台伺服器之間中繼，光靠這一點是防不住的。這項差異會在第7章檢視。

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

NTLM會把驗證交給持有雜湊值的一方

網域使用者的密碼雜湊值位於網域控制站端的帳戶資料庫。資源伺服器並不知道該使用者的雜湊值，因此無法自行驗證收到的回應。

於是，把使用者名稱、挑戰值、回應交給網域控制站請它判定，這就是傳遞驗證。以網域帳戶進行的NTLM驗證之所以需要向網域控制站查詢，就是出於這樣的分工。¹⁰¹

若是本機帳戶，確認雜湊值的對象就是伺服器自己的SAM。「NTLM會問網域控制站」這個說法，僅限於網域帳戶的情況。

Kerberos用票證取代了查詢

Kerberos以可更新的工作階段票證，取代了這種傳遞驗證。Microsoft說明，在NTLM中應用程式伺服器每次驗證都必須連線到網域控制站，而在Kerberos中則不再需要這樣的查詢。⁴

不過，若需要驗證PAC（特殊權限屬性憑證）則屬例外。這並不代表「只要用Kerberos，伺服器與網域控制站之間就完全沒有通訊」。

也就是說，遷移到Kerberos除了帶來「能確認對方」這項安全性上的改善之外，還有減少每次驗證都要依賴網域控制站這項維運上的意義。下一章就來看票證是如何扮演這個角色的。

4. Kerberos在做什麼

相對於NTLM每次驗證都要請人驗證回應，Kerberos採取的是先完成身分確認並取得票證，之後用該票證進行驗證的方式。圖3呈現從最初的身分確認到連線至服務的一連串流程。

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

看圖之前，先分清楚名稱與票證

圖3分成完成身分確認並取得TGT → 指定SPN並取得服務票證 → 向服務出示這三個階段。重點是不要把TGT與服務票證讀成同一種東西。

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若能用該長期金鑰解密，且時間戳記合理，就判定為「本人」。³

收到的東西：TGT與工作階段金鑰

KDC會回傳兩樣角色不同的東西。兩者都是「用戶端收到的東西」，但用戶端能不能讀到內容則不一樣。³

持有TGT與能讀到TGT的內容是兩回事。這項區別，銜接到下一步「附上TGT與驗證子提出要求」的程序。

時間一旦偏差，Kerberos本身就會失敗

這裡要掌握的是，時間戳記是驗證的一部分。Kerberos之所以對時間同步要求嚴格，原因就在於此，預設容許的時間差為5分鐘。⁷ 一旦超出這個範圍，預先驗證就無法通過，Kerberos驗證本身就會以錯誤失敗（Windows的時間同步整理於「Windows的時間同步（w32time）指南」）。這種「Kerberos失敗」與「回退到NTLM」是兩回事。區別方式會在6.5節處理。

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

取得TGT之後，接著就要求發給連線目的地服務的票證。到了這一步，「要連到哪個服務」這個名稱（SPN）才成為核心。³

用戶端會把連線目的地的SPN、TGT、驗證子送給KDC。KDC會找出SPN所對應的服務帳戶，再用該帳戶的長期金鑰加密服務票證並回傳。³

把這段流程倒過來讀，就能看見第6章要處理的問題。

• 解析不出SPN，就發不出票證。 服務帳戶若沒有登錄SPN，KDC就無法判斷該用誰的金鑰。以IP位址連線，在預設情況下也是不會嘗試Kerberos的條件（6.1節）。
• 票證是針對目的地產生的。 由於它是以該服務的長期金鑰加密，持有其他長期金鑰的服務便無法解密。無法換個目的地重複使用，原因就在這裡。

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

最後是與KDC無關，與連線目的地服務之間的往返。這裡同樣要把服務端的確認與用戶端的確認分開來讀。

服務端：打開發給自己的票證

用戶端會出示服務票證與驗證子。服務用自己的長期金鑰解密票證，取出工作階段金鑰與授權資訊。能用自己的金鑰解密，就等於確認了這張票證是發給自己的。³

用戶端：在要求相互驗證時確認對方

若用戶端要求了相互驗證，服務會把收到的時間戳記用工作階段金鑰加密後回傳。用戶端驗證這個回應，確認對方是真正的服務。³

不只是服務確認用戶端，用戶端也能確認服務。 這就是NTLM所沒有的相互驗證。

5. 決定性的差異

以下從維運與設計上會產生影響的觀點，比較第2〜4章的機制。是否要向網域控制站查詢，會因為是網域帳戶還是本機帳戶而不同，而Kerberos也有PAC驗證這個例外。 請連同條件一起閱讀。

使用委派的設計，還要再選擇方式

委派指的是，例如讓前端的Web應用程式代表使用者連線到後端的SQL Server的機制。在伺服器內偽裝使用者，與代表使用者一路前進到另一個服務，要分開思考。⁴

而Kerberos的委派又分為無限制委派、限制委派（constrained delegation），以及以資源為基礎的限制委派（RBCD）。除了決定「要用Kerberos」之外，要採用哪一種委派方式也是設計上的議題。

本文不深入各方式的設定。請把這三個名稱，當成日後調查需要委派的架構時的下一組搜尋關鍵字。

名稱與網域的條件，銜接到下一步的釐清

這張表最後兩列，正好就是「回退到NTLM的原因」。因為Kerberos的強處（綁定目的地、驗證對方）是建立在名稱能被正確解析之上的。

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

本章要調查的是「業務照常運作，但驗證變成了NTLM」的原因。請依連線目的地的名稱、SPN的登錄、帳戶、通往KDC的路徑這個順序確認。若驗證本身就出現錯誤，請先到6.5節確認是否需要採取不同的釐清方式。

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

也就是說，就算用了Negotiate，只要湊不齊讓Kerberos成立的條件，被選中的就會是NTLM。應用程式支援Kerberos，與那條連線實際使用了Kerberos，是兩回事。

以下的圖與表，是在NTLM可用的組態下具代表性的分支。這並不表示在NTLM本身受到限制時驗證一定會成功。請先調查切換的原因，至於對驗證方式的限制，則連同第8章、第9章一併確認。

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位址連線

預設行為：以IP位址就不會嘗試Kerberos

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

而且官方也列出了造成這種狀況的原因：因為設定錯誤或供應商的文件，而使用IP位址而非DNS名稱的應用程式。⁵ 實務上也很常看到「因為名稱解析不穩定」而在過去改寫成IP的設定，就這樣一直留到現在。

例外：設定TryIPSPN，並登錄實際會被要求的SPN

以IP位址不嘗試Kerberos，是預設行為，並不是絕對的限制。 在Windows 10版本1507與Windows Server 2016以後，已經有讓SPN的主機名稱可以使用IP位址的機制。¹¹

需要的是下面兩項，缺一不可。

1. 在用戶端把登錄值 TryIPSPN 設為1。
2. 以 Setspn -s <服務類別>/<IP位址> <帳戶> 的形式，手動登錄使用IP位址的SPN。

要登錄的SPN，必須與用戶端實際會要求的服務類別一致。就算原本的連線目的地是同一個IP位址，所需的名稱也會因服務而異。

就算只登錄了 host/，只要與實際被要求的SPN不一致，Kerberos就無法成立。Microsoft把這項功能定位為減少停用NTLM對相容性衝擊的手段。¹¹

先改成FQDN，例外留作最後手段

話雖如此，這並不是第一選擇。Microsoft自己就指出，IP位址是暫時性的，可能因租約到期與更新而引發衝突或驗證失敗，因此通常不應取代主機名稱使用，而且以IP位址為基礎的SPN登錄屬於手動作業，應只在無法切換為DNS主機名稱時才使用。¹¹ 稽核中發現直接輸入IP位址的地方，請先考慮改成FQDN。TryIPSPN 是對那些怎麼樣都做不到的對象所保留的最後手段。

6.2. 未登錄SPN

接著要看的是，實際存取所用的名稱，是否已登錄為SPN。Microsoft把SPN未正確設定的應用程式，列為明明支援Kerberos卻仍使用NTLM的類型之一。⁵

在圖3的TGS交換中，KDC會從SPN查出服務帳戶，並以其長期金鑰加密票證。沒有SPN，就無法鎖定「那個服務的金鑰」。

以DNS別名（CNAME）或自訂主機名稱連線時也一樣，只要該名稱的SPN未登錄，就會發生同樣的事。能靠名稱找到伺服器，與能用該名稱取得Kerberos票證，是兩回事。

要確認的是應用程式連線目的地所寫的名稱，以及針對該名稱會被要求的服務類別SPN。應用程式即使運作正常，也可能只有正在使用的那個名稱沒有登記在冊。

6.3. 本來就在Active Directory之外

找出現在必須使用NTLM的路徑

工作群組組態的電腦，或以本機帳戶存取共用資料夾，都不在Kerberos的場域內。Microsoft也指出，組態為工作群組成員的系統之Windows驗證，以及網域控制站以外的本機登入驗證，會使用、也必須使用NTLM。¹⁰

分清楚本機KDC能填補與不能填補的範圍

這正是無法「單純禁止」NTLM的原因。第2階段預計提供的本機KDC，正是為了填補這個缺口的功能。⁶

不過，請認知到能填補的僅限於彼此都支援的Windows之間。若對象是舊版Windows，或NAS、複合機這類其他廠商的裝置，即使本機KDC問世，本機帳戶驗證也不會自動變成Kerberos。這項分類在實務篇的第5章、第6章有說明。

6.4. 連不到KDC

跨據點或透過VPN無法連線到網域控制站，或是Kerberos所需的通訊被防火牆擋下時，也會成為切換到NTLM的原因。⁶ 因為在無法從KDC取得所需票證的場合，就沒辦法做好使用Kerberos的準備。

這裡請把「能不能連到網域控制站」，連同「是誰發出的通訊」一起分開來看。

「用戶端連不到KDC」與「用NTLM就不需要網域控制站」不是同一回事。 如第3章所見，網域帳戶的NTLM需要從伺服器端向網域控制站查詢。¹⁰ 即使選中了NTLM，只要連這條驗證路徑也斷了，驗證一樣無法完成。

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

無法啟動Kerberos，與被選用之後才失敗

最後來釐清一組很容易混淆但其實不同的狀況。前面的6.1〜6.4，全都是「沒能啟動Kerberos」的案例。因為啟動不了，Negotiate才選擇NTLM。

另一方面，Kerberos被選用之後才失敗的問題，要另外調查。代表性的例子就是4.1節也提過的時間偏差。

只要解析得出SPN、也連得到KDC，Negotiate就會先選擇Kerberos。但若時間差超出容許範圍（預設5分鐘），預先驗證就無法通過，會以Kerberos的錯誤形式失敗。⁷

「因為無法使用Kerberos所以選NTLM」與「選了Kerberos但失敗，所以改用NTLM重試」並不相同。Negotiate不一定會做到後者，應用程式明確以其他方式重試的情況，則要另外考量。

先分清楚症狀，再選擇要看的記錄與指令

實務上的意義很單純。時間偏差造成的故障，去追事件8001是找不到的。症狀也不一樣。

請先分清楚「是回退到NTLM，還是Kerberos壞掉了」，再開始調查。這裡所說的「能運作但走NTLM」這種症狀，講的是NTLM可用的組態。對NTLM的限制與封鎖，請與第8章、第9章分開確認。

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

中繼攻擊與Pass-the-Hash雖然都被當成NTLM的問題來談，但兩者利用的東西不一樣。

先在7.1節看中繼能得逞的條件，再在7.2節看雜湊值遭竊時的問題。

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的連線都能無條件被中繼。

這裡要確認的不只是「是否支援」防禦功能，還包括是否實際要求、強制啟用。在盤點NTLM的同時，確認是否設定為要求SMB簽章是有價值的。

把遷移到Kerberos與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在SMB的NTLM封鎖功能所要對抗的攻擊中，除了暴力破解與破解密碼之外，也列出了Pass-the-Hash。¹³

Kerberos也存在長期金鑰。不過，日常驗證中往來的是有期限的票證與工作階段金鑰。³ 兩者必須連同「被竊取的是什麼，有效範圍就不同」這一點一起比較。

8. NTLMv1、NTLMv2與「移除」

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

這裡要區分的是非建議使用與移除。非建議使用代表不再是積極開發的對象，移除則代表在該版本中無法使用。

下表把2024年6月的非建議使用公告，與其後的NTLMv1移除並排呈現。請不要把第1列的「仍可運作」讀成在第2列的對象OS上也能使用NTLMv1。 NTLMv1適用的是其後的移除。⁹

最優先找出只能使用NTLMv1的對象

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

限制原則對v1與v2都有效

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

9. 接下來會如何發展

遷移的方向，若依改變應用程式的呼叫 → 減少需要NTLM的場合 → 改變網路驗證的預設值這個順序來理解，就會清楚許多。

以下IAKerb與本機KDC的提供時程與預設停用，都是依所引用的Microsoft藍圖，當成計畫來說明。不應把它們當成已經提供的功能，或所有裝置都能自動使用的功能。⁶

第一項：在應用程式端使用Negotiate

應把NTLM的呼叫替換為Negotiate的呼叫，這是非建議使用公告本身就含有的指示。⁹ 官方也明確寫道，應用程式不應直接存取NTLM安全性套件。¹

第二項：減少會用到NTLM的場合本身

第2階段（2026年下半年）預計提供的IAKerb與本機KDC就屬於這一項。⁶ 這是要從通訊協定端，去填補6.3節看到的「因為是本機帳戶所以無法使用Kerberos」「因為連不到網域控制站所以無法使用Kerberos」這兩個缺口的嘗試。

不過能填補的範圍有限。IAKerb解決的是對網域控制站的連線可達性，而不是對方支不支援。本機KDC也只有在彼此都支援的Windows之間才有效。

若對象是其他廠商的NAS或複合機，就算等到第2階段情況也不會改變，因此必須自行從汰換裝置、加入網域、改用其他通訊協定、例外管理之中做出選擇。

第三項：改變網路NTLM驗證的預設值

第3階段的計畫，是在下一個主要版本中把網路NTLM驗證預設停用。⁶ 不過官方也表明了可以用原則再次啟用這個前提。

現在該做的：把可望由新功能解決的相依性與必須自行修正的相依性分開

這項計畫的順序是「先消除使用NTLM的理由，再改變預設值」。自家的相依性也照下面的方式分開，就不會把該等待的與該先修正的混在一起。

重要的是，不要把與舊版Windows或其他廠商裝置之間的驗證一律歸入「等第2階段」。它們不會自動變成Kerberos，放著不管就會在預設停用的階段以故障的形式浮上檯面。

具體的盤點與分類步驟，整理於實務篇。

10. 總結

最後依判斷的順序整理一次。

機制：是以雜湊值產生的回應，還是給目的地的票證

NTLM是以密碼的雜湊值為基礎，產生對挑戰值的回應。負責驗證的，網域帳戶是網域控制站，本機帳戶則是伺服器自己的SAM。¹¹⁰

Kerberos使用的是以目的地服務的長期金鑰加密的票證。³ 只要掌握相互驗證、每次驗證對網域控制站的查詢、委派這三項差異，就能看見分別使用這兩種方式的前提。⁴

釐清：是以NTLM在運作，還是驗證本身停住了

如果是切換到了NTLM，就確認直接輸入IP位址、SPN未登錄、位於Active Directory之外、對KDC的連線可達性這四個條件。⁵⁶¹¹

另一方面，像時間偏差這種在Kerberos被選用之後才出現驗證錯誤的問題則屬另一類。不要只追NTLM/Operational的事件8001，也要查Kerberos端的事件與時間同步。⁷ 不要用「能運作就是Kerberos」「停住了就是回退到NTLM」來判斷，這是調查的出發點。

因應：確認防禦，再前進到Negotiate與名稱的整備

中繼NTLM往返的中繼攻擊，與使用竊得雜湊值的Pass-the-Hash，成立的理由與所需的材料都不同。⁸¹¹³ 一面確認連線目的地的防禦條件，一面減少對NTLM本身的相依。

NTLMv1已在Windows 11 24H2 / Windows Server 2025中移除，包含NTLMv2在內的所有版本都屬於非建議使用。⁹ 在應用程式中要使用Negotiate、把連線目的地統一為FQDN、登錄SPN。¹⁵ 在此之上，請把可望由新功能解決的相依性，與必須自行修正的相依性分開，推進遷移。

相關文章

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

相關諮詢領域

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

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

參考連結

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

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

最大的差異在於「能不能確認對方的身分」。Microsoft明確指出，在NTLM中，用戶端無法驗證伺服器的身分，某個伺服器也無法驗證另一個伺服器的身分。NTLM是為「可以假設伺服器是真品」的環境所設計的，而Kerberos並不做這樣的假設。第二個差異是伺服器是否需要向網域控制站查詢。在NTLM中，若以網域帳戶進行驗證，應用程式伺服器每次驗證用戶端時都會連線到網域控制站（若是伺服器的本機帳戶，伺服器會查閱自己的帳戶資料庫並自行判定，因此不會用到網域控制站）。在Kerberos中，可更新的工作階段票證取代了這種傳遞驗證，因此除非需要驗證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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。