Zerologonはなぜ認証を突破できたのか？ ── Netlogonでゼロが正解になった理由
· 更新日: · 小村 豪 · Windows, 情報セキュリティ, Active Directory, 暗号, CVE
更新履歴(初版のみ・2026年09月14日公開)
- 初版公開
Zerologonは、コンピューターのパスワードを知らない相手が、Netlogonの認証を通過できた脆弱性です。その理由は、AESの鍵を解読できたからではありません。ゼロで埋めた認証データが、サーバーの計算した正解と一致する場合があったからです。1
1. 概要
Zerologon（CVE-2020-1472）は、WindowsのNetlogonを悪用し、コンピューターアカウントになりすませる問題でした。ドメインコントローラーの身元まで偽装されると、認証情報の窃取を通じてドメイン全体を掌握されるおそれがありました。2
| 項目 | 内容 |
|---|---|
| CVE | CVE-2020-1472 |
| 通称 | Zerologon |
| 公表年・初回対策 | 2020年。初回のセキュリティ更新は2020年8月11日。3 |
| 対象機能 | Netlogon Remote Protocol（MS-NRPC）によるコンピューター認証 |
| 問題の性質 | 認証の不備によるなりすましと権限昇格 |
| 主な影響 | ドメインの認証情報の窃取、ドメイン全体の掌握。認証突破後にも追加の段階が必要。 |
| 悪用実績 | あり。Microsoftが2020年に実際の悪用を報告。2 |
中心となる欠陥は、認証用の8バイトを作る暗号処理にあります。特定の条件では、1バイト目の結果が後続7バイトでも繰り返され、鍵を知らなくても答えを作れてしまいました。3章で、その計算を順に追います。1
2. 対象
対象となったのは、影響を受けるWindows Serverをドメインコントローラー（DC）として使う、未修正の環境です。当時の主な対象にはWindows Server 2008 R2 SP1、2012、2012 R2、2016、2019などがあります。これは代表例であり、Server Coreを含む製品・更新の適用範囲はMicrosoftの案内で確認する必要があります。4
攻撃者には、対象DCのNetlogonへ通信できることが必要でした。一方、この認証突破のために、事前のドメインユーザーの資格情報や管理者権限を持っている必要はありませんでした。ここで扱うのはDCのコンピューター認証であり、一般のPCのサインイン画面でパスワードにゼロを入力する話ではありません。5
以下の「詳細」は、2020年当時の未修正動作を説明しています。修正後の入力検査やセキュアRPCの強制は、5章「対策」で分けて扱います。
3. 詳細
Netlogonの認証
会社のドメインに、ファイルサーバーFS01と、認証基盤を担うドメインコントローラーDC01があるとします。
FS01が「私はFS01です」と送ってきても、名前だけなら別の機械も名乗れます。そこでNetlogonでは、コンピューターアカウントのパスワードから得た秘密を使い、相手が本物かを確かめます。人のアカウントとは別に、機械にもアカウントと秘密があるわけです。6
両者はまず、今回の通信に使うチャレンジという値を交換します。FS01側の値とDC01側の値、それに共有する秘密から、双方が同じセッション鍵Kを計算します。Kをネットワークへそのまま送るのではありません。7
flowchart TB
accTitle: Netlogonでは両者が同じ鍵を別々に計算する
accDescr: コンピューターのパスワード由来の秘密と、双方のチャレンジから、クライアントとDCが同じセッション鍵を導出します。
A["FS01の秘密と両チャレンジ"] --> B["FS01がKを計算"]
C["DCが持つ同じ秘密と値"] --> D["DC01もKを計算"]
B -.->|"結果は同じ鍵"| D
図1: 通信で交換する値だけではKを計算できず、パスワード由来の秘密も必要です。7
FS01はKを使い、自分が送ったチャレンジから8バイトの認証用の値を作ってDC01へ渡します。DC01も同じ計算をし、届いた値と比較します。以下では、この8バイトを「確認値」と呼びます。仕様上の名前はclient Netlogon credentialです。6
DC01のチャレンジも無駄ではありません。Kを作る材料に入っています。ただし、確認値を作る暗号処理へ直接入れるのは、クライアント側のチャレンジです。
flowchart TB
accTitle: DCは相手の確認値を自分でも計算して比べる
accDescr: クライアントのチャレンジとセッション鍵から、双方が同じ確認値を計算し、DCが受け取った値との一致を確認します。
A["クライアントのチャレンジ"] --> B["Kで確認値を計算"]
B --> C["DC側の正解"]
D["相手から届いた確認値"] --> E{"一致するか"}
C --> E
図2: この確認が成り立つには、Kを知らない相手が正解を簡単に作れないことが必要です。6
Zerologonは、ここを崩しました。「一致したのだから秘密を知っているはず」という判断が、成立しなくなったのです。
AES-CFB8の状態更新
当時の問題のある経路では、確認値を作るためにAES-CFB8を使っていました。AESの内部の計算まで追う必要はありません。まずは「鍵Kと16バイトの入力を受け取り、16バイトを返す。同じ鍵と入力なら、同じ結果になる」と考えてください。8
CFB8は、そのAESを使ってデータを1バイトずつ暗号化する方法です。計算用に16バイトの状態を持ち、その初期値をIV（初期化ベクトル）と呼びます。9
1バイト分の処理は、次の流れです。
flowchart TB
accTitle: CFB8で暗号文の1バイトを作る流れ
accDescr: 16バイトの状態を鍵KでAESにかけ、出力の先頭1バイトと平文の1バイトをXORし、できた暗号文を状態の末尾へ戻します。
R["16バイトの状態"] --> A["AESで計算（鍵K）"]
A --> S["出力の先頭1バイト"]
S --> X["平文1バイトとXOR"]
X --> C["暗号文の1バイト"]
C --> U["状態を1バイトずらして追加"]
U --> R
図3: 次の状態に戻すのは、平文ではなく、今作った暗号文の1バイトです。9
XORはビットごとの排他的論理和です。ここではある値とゼロをXORすると、その値のままという性質だけ使います。たとえば0x53 XOR 0x00は0x53です。
最後の「ずらして追加」が重要です。古い状態の先頭1バイトを捨て、残り15バイトの後ろへ、今作った暗号文を付けます。通常はこれで状態が変わり、次のAESにも違う入力が入ります。9
ところがNetlogonのこの処理では、IVを16バイトすべてゼロに固定していました。現在公開されている仕様の§3.1.4.4.1にも、SET IV = 0と明記されています。8
ゼロ状態の繰り返し
ここで、クライアントが送るチャレンジも8バイトすべてゼロだった場合を考えます。確認値を作る処理から見ると、平文もゼロが8個です。
まずゼロのIVをAESへ入れます。鍵Kは秘密のままで、値は分かりません。その鍵では、AESの出力の先頭1バイトが、たまたまゼロだったとしましょう。出力16バイト全部がゼロである必要はありません。
すると、1バイト目の暗号文は0 XOR 0 = 0です。
次に状態を更新します。ゼロが16個あったところから、先頭のゼロを一つ捨て、末尾に今できたゼロを一つ追加する。……やはり、ゼロが16個です。
2バイト目に入っても、AESへ渡す状態と鍵が、1バイト目と全く同じなのです。 AESの先頭の出力もゼロになり、平文もゼロなので、暗号文はまたゼロ。これが8バイト目まで続きます。
flowchart TB
accTitle: ゼロを戻すと内部状態が変わらない
accDescr: AES出力の先頭がゼロになる鍵では、ゼロの平文からゼロの暗号文ができ、状態もゼロのままなので同じ計算が繰り返されます。
A["状態：ゼロ16個"] --> B["AESの先頭がゼロ"]
B --> C["平文ゼロとXOR → ゼロ"]
C --> D["ゼロを捨て、ゼロを追加"]
D --> A
図4: 最初の条件が成立すると、後続のバイトでも新しい偶然を待つ必要がありません。1
これは図だけの仮定ではなく、AESの計算でも確かめられます。以下は文献の実測値の転載ではなく、本記事のオフライン計算例です。公開の固定鍵3b902ea5bf4d9855826a3291bc752e76を使いました。ゼロ16バイトに対するAES出力は0050788b…で、先頭だけがゼロです。この鍵とゼロのIVで、ゼロ8バイトをCFB8暗号化すると、結果もゼロ8バイトになりました。
計算結果のJSONには各段階の状態を載せています。固定鍵の例はallZeroFixedPoint.traceで、1バイト目から8バイト目までのstateBefore・aesOutput・stateAfterを照合できます。暗号処理の照合に用いたNISTの値はnistF37に分けています。Windowsへの通信や、脆弱性の再現攻撃は行っていません。1011
約256分の1になる理由
1バイトには256通りの値があります。鍵をランダムに選んだとき、AES出力の先頭1バイトがゼロになる確率を約1/256と見れば、直前に説明したゼロ状態に入る確率も約1/256です。これはSecura原報告の暗号上の欠陥を説明する節と、認証突破の段階で述べられている条件です。1
ここを(1/256)の8乗と数えてはいけません。2バイト目以降は、新しい入力を試しているのではなく、同じ鍵・同じ状態に戻って同じ結果を出しているからです。
認証では、クライアントがゼロのチャレンジとゼロの確認値を提示したとき、DC側の正解までゼロになる鍵に当たれば、比較が一致します。攻撃者はKを計算していないのに、正解を提出できてしまいます。
一方、同じKなら、計算を繰り返しても結果は変わりません。認証をやり直す際にDCが新しいチャレンジを返すことで、パスワードは同じでも、そこから導くKが変わる点が、この脆弱性を現実的な問題にしました。71
flowchart TB
accTitle: 鍵が変わるとゼロの確認値が一致するかも変わる
accDescr: 同じパスワードでもDCのチャレンジが変わるとセッション鍵が変わり、ゼロ入力に対する確認値も変わります。
A["DCのチャレンジが変わる"] --> B["セッション鍵Kが変わる"]
B --> C{"AES出力の先頭は？"}
C -->|"ゼロ"| D["ゼロ8個が正解になる"]
C -->|"ゼロ以外"| E["その提示値では一致しない"]
図5: 秘密を総当たりで探すのではなく、秘密を知らなくても正解がゼロになる条件が問題でした。71
なお、256分の1は「256回で必ず成功」という意味ではありません。本記事で、各試行が独立・成功確率が毎回1/256というモデルから計算すると、256回以内に1回以上成功する確率は1 - (255/256)^256、約63.3％です。256はこのモデルの待ち回数の平均であって、成功を保証する上限ではありません。計算記録のrepeatedTrialModelに、仮定・回数・結果を残しています。10
4. 影響
ドメイン全体への波及
認証の欠陥によって破られたのは、コンピューターの身元確認です。認証成功の返事を受け取っただけで、攻撃者のPCが突然ドメイン管理者になるわけではありません。
被害を大きくしたのは、DC01自身もコンピューターアカウントを持つことと、その身元で利用できる機能でした。
さらに、認証を通過しても攻撃者はセッション鍵を知りません。本来、続くRPC通信の署名や暗号化が必須なら、その鍵で通信を保護する段階で困ります。しかし脆弱だった構成では、この保護を省略できました。認証後の要求にも確認値を使う仕組みがあり、同じ暗号上の欠陥が影響しました。1213
Securaの報告書では、そこからDCのAD側に保存されたコンピューターアカウントのパスワードを書き換え、DCの身元を利用してディレクトリの複製機能へ進む例が示されています。認証情報を含むデータの取得が、ドメイン全体の掌握につながりました。複製は別のDRSというプロトコルの役割であり、Netlogonへの一回の要求で全パスワードが返るわけではありません。14
flowchart TB
accTitle: 身元の偽装が認証基盤全体への被害につながる
accDescr: 公表された攻撃例では、Netlogonの認証突破と追加の欠陥を通じてDCのアカウントが侵害され、複製権限が認証情報への影響を広げました。
A["コンピューターの身元を偽装"] --> B["追加の欠陥でDCのアカウントを侵害"]
B --> C["DCの身元で複製機能を悪用"]
C --> D["ドメインの認証情報へ被害"]
図6: 認証の突破だけでなく、その先で得られる権限と機能が被害の範囲を決めます。14
この書き換えは、DCのローカルに残る秘密まで同時に揃えるものではありません。両者の不一致によって認証やサービスを壊すおそれもあるため、動作中のDCで気軽に再現してよい検証ではありません。14
実際の悪用
Microsoftは2020年に実際の悪用を報告しています。入口となる別の脆弱性でネットワーク内に足場を得た後、Zerologonへ進んだ事例もあります。事前のドメイン資格情報が不要なことと、DCへ通信できる場所が必要なことは、両立します。215
5. 対策
修正内容
「IVをランダムに変えれば終わり」と思うかもしれません。しかしWindowsの対策を、そのような暗号方式の変更として読むのは正確ではありません。現在の仕様でもAES版の確認値計算はゼロIVです。一方で、現行の§3.1.4.1の手順7には、チャレンジの先頭5バイトを調べて条件に合わない入力を拒否する検査が明記され、すべてゼロのチャレンジも拒否されます。これは修正後の仕様であり、2020年の未修正サーバーの動作とは区別して読む必要があります。816
運用上の変更では、認証後の通信にセキュアRPCを要求する範囲も広げられました。3
flowchart TB
accTitle: 認証の入力と認証後の通信を別々に保護する
accDescr: 修正後の認証は弱いチャレンジを拒否し、セキュアRPCの強制は認証後の通信を鍵に基づいて保護します。
A["認証時のチャレンジ"] --> B["弱い入力を拒否する検査"]
C["認証後のRPC通信"] --> D["署名・暗号化の強制"]
図7: 確認値の比較だけを信用せず、その入力と、続く通信にも制約を設けます。163
更新の経緯
導入は二段階でした。2020年8月11日の更新は、単にログを出すだけの更新ではありません。 Windowsのコンピューターアカウント、信頼アカウント、DCのアカウントなどにセキュアRPCを強制する対策を含みます。2021年2月9日以降の更新では、非Windowsのコンピューターアカウントにも強制を広げました。明示的に脆弱な接続を許可する例外ポリシーは、別に考慮が必要です。3
運用上の確認
古い構成を点検するなら、読み取り専用DC（RODC）も含む全DCへの更新の適用状況と、その例外ポリシーを確認するのが先です。当時のFullSecureChannelProtectionレジストリ値は2021年2月以降の強制段階では使われないため、古い記事の設定値だけを対策として転記しないでください。17
Netlogonのイベント5827〜5831も、拒否・当時の許可・ポリシーによる例外などで意味が違います。一つの番号だけを見て侵害を断定したり、記録がないことだけで安全と判断したりせず、更新と設定を確認したうえで通信元や周辺の記録を調べます。18
6. 教訓
Zerologonでは、AESは同じ鍵と入力に同じ結果を返していました。壊れたのは、その結果を「相手が秘密を知っている証拠」として使う仕組みです。
暗号アルゴリズムの強さだけでは、認証全体の安全性は決まりません。 Netlogonでは、相手が選べるゼロの入力と、ゼロに固定した初期状態が組み合わさりました。状態更新まで追うと、一度成立した条件が8バイト目まで残ることが分かります。確認値の長さだけから、当てる難しさを判断することはできません。
また、認証の後にも鍵による通信保護が必要です。Zerologonでは、その保護を省略できる条件や、DCのアカウントが持つ権限が被害を広げました。入力の検証、認証後の通信、アカウントの権限を、別々の項目として確認する必要があった事例です。
図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全6件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle
関連記事
参考リンク
本文と図の脚注から、根拠となる節・手順・ページへ辿れます。確認日は2026年9月15日です。PDFは紙面に印刷されたページ番号と、表紙から数えたPDF表示ページを併記しました。ページ指定が効かないビューアーでは、節番号で探してください。
資料の時点と入手方法。 MS-NRPCのリンク先は確認時点の現行仕様であり、2020年の未修正動作をそのまま記した文書ではありません。各注の更新日はページに表示された日付です。Secura原報告は公式PDFが確認環境でHTTP 403だったため、著者・題名・2020年9月の表記がある第三者転載テキストで該当節を照合しました。原PDFのページ番号や、転載内容が原PDFと完全に一致することは未確認です。文献の記述、本文の説明用の導出、当サイトの計算記録は区別して示します。
-
Secura原報告、暗号上の欠陥の節と認証突破の段階（転載テキストの該当箇所）。検索語は
Core vulnerability、Exploit step 1。固定されたゼロIV、先頭1バイトがゼロになる約1/256の条件、同じ状態が後続へ繰り返される説明と、セッション鍵が変わることを参照しています。図4の1バイトずつの追跡は、その説明とNIST §6.3の計算則を本文で展開したものです。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 -
Microsoft Security Response Center、2020年10月29日のNetlogon悪用報告、冒頭第1段落（記事）。検索語は
continued activity。実際の攻撃活動、DCの身元の偽装、ドメイン資格情報の窃取と掌握への可能性を述べています。本文の「悪用実績あり」はこの当時の報告を指し、現在の発生件数を示すものではありません。 ↩ ↩2 ↩3 -
Microsoftサポート KB4557222の更新時期を説明する節（文書）。
Initial Deployment PhaseとEnforcement Phaseの小見出し、特に2020-08-11側の最初の三つの項目と2021-02-09側の本文を参照しています。前者はWindows・信頼・DCの各アカウントへの強制、後者は非Windowsも含む強制範囲と例外の説明です。 ↩ ↩2 ↩3 ↩4 -
Microsoftサポート KB4557222の適用対象欄とFAQ 6〜8（文書）。FAQ 6は影響を受ける役割がDCであること、7・8はWindows Server 2008 SP2と2008 R2 SP1を区別する説明です。本文は当時の代表的な対象の整理で、2026年現在の製品サポート状況や全SKUの一覧ではありません。 ↩
-
Tom Tervoort / Secura、2020年9月の原報告。参照箇所：冒頭のSummary（第三者転載テキストの該当箇所）。対象DCと通信できる一方、ドメイン資格情報は不要という前提と、コンピューターへのなりすましを述べた段落を参照しています。原報告の題名は Zerologon: Unauthenticated domain controller compromise by subverting Netlogon cryptography。転載へのリンクの検索位置が合わなければ、この節名をページ内検索してください。 ↩
-
Microsoft Open Specifications、MS-NRPC §3.1.4.1 Session-Key Negotiation、手順1〜6（該当節、ページ表示の更新日2025-07-08）。手順1・2がチャレンジ交換、4がクライアント自身のチャレンジからの確認値計算、6がDCでの再計算と比較です。節末では一致を共有する秘密の所持の証拠として扱う設計を説明しています。本文のFS01/DC01は説明用の名称です。 ↩ ↩2 ↩3
-
Microsoft Open Specifications、MS-NRPC §3.1.4.3.1 AES Session-Key（該当節、ページ表示の更新日2025-08-12）。参照箇所は
ComputeSessionKeyの引数と、その直後の擬似コードです。共有する秘密、クライアントとサーバーの両チャレンジが入力であり、HMACの結果から128ビットの鍵を得ることを確認できます。 ↩ ↩2 ↩3 ↩4 -
Microsoft Open Specifications、MS-NRPC §3.1.4.4.1 AES Credential（該当節、ページ表示の更新日2025-07-08）。冒頭のAES-128・8ビットCFBの指定と、擬似コードの
SET IV = 0を参照しています。ゼロIVの直接の根拠であり、この節だけで認証前後の検査や修正の全体を説明しているわけではありません。 ↩ ↩2 ↩3 -
NIST SP 800-38A（2001年版）、§6.3、紙面pp.11–12／PDF表示18–19ページ（計算式のページ・図3のページ）。暗号化側の状態更新式と出力式、図3の暗号文を戻す矢印が根拠です。本文の「16バイトを1バイトずらす」は、規格中のブロック長
b=128、区切り長s=8を代入した説明です。IVを予測不能とするCFBの条件はAppendix C、紙面p.20／PDF表示27ページ（該当ページ）で確認できます。 ↩ ↩2 ↩3 -
本記事のオフライン計算（結果JSON）。固定鍵と入力は
allZeroFixedPoint.key・iv・plaintext、各バイトの状態は同じ項目のtrace、NISTとの照合値はnistF37にあります。約63.3％はrepeatedTrialModelの確率1/256・回数256を用い、1 - (1 - 1/256)^256 = 0.6328402451…と計算した値です。文献からの引用値でも、Windows上での攻撃成功率の実測でもありません。 ↩ ↩2 -
NIST SP 800-38A（2001年版）、§F.3.7 CFB8-AES128.Encrypt、紙面pp.39–40／PDF表示46–47ページ（開始ページ）。照合に使ったのは冒頭のKey・IVと、Segment #1〜#16の平文・暗号文です。計算記録の
nistF37に同じ入力と暗号文を記載しています。後の公開固定鍵によるゼロ状態の例は、このNISTの値とは別です。 ↩ -
Secura原報告、認証後の通信と確認値を扱う段階（第三者転載テキスト）。検索語は
Exploit step 2とExploit step 3。前者でRPCの署名・暗号化を省略できた条件、後者で認証後の要求に使う確認値を説明しています。認証突破だけで、鍵を使う通信保護まで実行できるようになるわけではないことの根拠です。 ↩ -
Microsoft Open Specifications、MS-NRPC §3.3.4.2.1 Generating a Client Netlogon Signature Token、手順7・8（該当節、ページ表示の更新日2024-07-25）。手順7の鍵を使う署名計算と、8のセッション鍵に基づく暗号化を参照しています。これは通信保護の計算の根拠であり、2020年当時に保護を省略できた条件の根拠は前のSecura原報告です。 ↩
-
Secura原報告、DCのパスワード変更とドメインへの波及を扱う段階（第三者転載テキスト）。検索語は
Exploit step 4とExploit step 5。AD側だけのコンピューターアカウントの変更、ローカル側の秘密との不一致、続く複製機能による認証情報への影響を説明した部分です。本文と図6は、この報告例の段階を要約しています。 ↩ ↩2 ↩3 -
Microsoft Security、2020年11月30日のDefender for Identity記事、初期の攻撃を振り返る節のFigure 3直後（該当箇所）。
CVE-2019-0604を含む段落から続く二つの段落を参照しています。SharePointへの侵入で得た足場から、ZerologonによるDCへの攻撃へ進んだ事例です。 ↩ -
Microsoft Open Specifications、MS-NRPC §3.1.4.1の手順7（該当箇所、ページ表示の更新日2025-07-08）。検索語は
first 5 bytes。先頭5バイト内に単独で現れる値がない場合に拒否する規定で、全部ゼロもこの条件に入ります。本文は現行仕様のこの記述を示しており、このページの更新日を2020年のパッチ公開日として扱ってはいません。 ↩ ↩2 -
Microsoftサポート KB4557222の展開手順1、例外ポリシーの節、レジストリ設定の節（文書）。
RODCとFullSecureChannelProtectionをページ内検索すると、全DCへの更新と、2021年2月以降はレジストリ値によらず強制する記述へ辿れます。例外ポリシーの節には、脆弱な接続を許可したアカウントを残す危険が説明されています。 ↩ -
Microsoftサポート KB4557222のイベントログの節、各イベント表（文書）。
5827で検索し、5828〜5831までの表も確認します。5827・5828は拒否、5829は初期段階で許可された接続、5830・5831はポリシーで許可された接続です。この表が示すのは接続の処理結果で、侵害の確定判定ではありません。 ↩
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
PrintNightmareはなぜSYSTEM権限を奪えたのか？ ── 印刷スプーラーとドライバー導入の境界
PrintNightmare（CVE-2021-34527）は、印刷スプーラーのドライバー導入機能からSYSTEM権限のコード実行に至る脆弱性でした。通常の印刷との違い、DLLが実行される過程、Point and Printとの関係、2021年の対策を解説します。
Windowsサービスのアカウント選定 ── LocalSystem・仮想アカウント・gMSAの使い分け
WindowsサービスをLocalSystemで動かし続けていませんか。LocalService・NetworkService・仮想アカウント・ドメインユーザー・gMSAの権限とネットワーク上の身元を判断表で比較し、最小権限で運用する選び方を解説します。
グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け
「GPOで配布」の意味が分からないままAD環境を触っていませんか。グループポリシーの仕組みとLSDOUの適用順序、gpupdate・gpresultでの反映確認、Intuneとの使い分け、客先GPOがアプリの動作を変える落とし穴まで実務目線で解説します。
Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる
全PC共通のローカル管理者パスワードは、1台の侵害が全台に波及するPass-the-Hash攻撃の温床です。OS標準機能になったWindows LAPSによる自動ローテーションと、AD/Entra IDへの保存設定、運用の落とし穴を解説します。
SMB署名とLDAPチャネルバインディング ── NTLM対策の「残り半分」を実務で締める
NTLMを止めるまでの間、リレー攻撃の被害を抑える防御がSMB署名とLDAP署名・チャネルバインディングです。OSごとの既定値、監査イベントの読み方、強制へ進める手順、業務アプリと機器の直し方までを実務目線で整理します。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
よくある質問
この記事のテーマについて、相談時によくある質問をまとめています。
- Zerologonは、パスワードに0を入力するとログインできる脆弱性ですか？
- いいえ。人がWindowsのサインイン画面へ入力するパスワードの話ではありません。Netlogonでコンピューターの身元を確認するときに、ゼロの並んだ認証用データが正しい計算結果と一致し得た脆弱性です。
- AES自体が解読されたのですか？
- AESの鍵を求めた攻撃ではありません。AES-CFB8の初期状態をゼロに固定し、選べる入力もゼロにすると、特定の鍵では内部状態が変わらず、出力がずっとゼロになる性質を利用しています。
- なぜ成功確率が256分の1になるのですか？
- ランダムな鍵に対して、ゼロの16バイトをAESへ入れた出力の先頭1バイトがゼロになる確率を約256分の1と見ます。この条件が成立すると、後続も同じ状態と鍵で計算するため、8バイトを独立に当てる必要がなくなります。256回で必ず成功するという意味ではありません。
- 攻撃にはドメインユーザーの資格情報が必要でしたか？
- この脆弱性による認証突破そのものには、事前のドメイン資格情報は不要でした。ただし、未修正のドメインコントローラーのNetlogonへ通信できる必要があります。インターネット上の任意のPCを無条件に攻撃できるという話ではありません。
- 2020年8月と2021年2月の更新は何が違いますか？
- 2020年8月の更新は、Windowsのコンピューターアカウントや信頼アカウントなどにセキュアRPCを強制する初期対策を含みました。2021年2月以降は非Windowsのコンピューターアカウントにも強制を広げる段階です。例外ポリシーは別に確認が必要で、古いレジストリ設定を現在の対策としてそのまま使うものではありません。