コンテンツに移動
脅威インテリジェンス

Net-NTLMv1 に終止符を: プロトコル廃止を加速させるレインボー テーブルの公開

2026年2月3日
Mandiant

Mandiant Services

Stop attacks, reduce risk, and advance your security.

Contact Mandiant

※この投稿は米国時間 2026 年 1 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

執筆者: Nic Losby


はじめに

Mandiant は、Net-NTLMv1 という旧式プロトコルからの移行の緊急性を周知するため、Net-NTLMv1 レインボー テーブルの包括的なデータセットを一般公開することにしました。Net-NTLMv1 は、1999 年の暗号解読研究ですでに脆弱性が指摘され、20 年以上も前から非推奨とされていますが、Mandiant のコンサルタントは稼働中の環境で今でも使われているのを目の当たりにしています。このレガシー プロトコルは、組織を容易な認証情報窃取の危険にさらしていますが、運用の慣習や、「目に見える差し迫ったリスク」が示されてこなかったために、依然として広く残ってしまっているのが現状です。

今回 Mandiant がテーブルを公開するのは、セキュリティ担当者が Net-NTLMv1 の脆弱性を実証しやすくするためです。このプロトコルを悪用するツール自体は以前から存在していましたが、多くの場合、機密データをサードパーティのサービスにアップロードする必要があったり、鍵を総当たり攻撃するために高価なハードウェアが必要だったりしました。今回公開されたデータセットを使えば、防御者や研究者は、600 米ドル未満のコンシューマ ハードウェアでも 12 時間以内に鍵を復元できるようになります。これは、Mandiant の現場知見と Google Cloud のリソースを組み合わせることで、特定の攻撃手法そのものを成り立たなくしていくという相乗効果を狙った取り組みの一例でもあります。

この投稿では、レインボー テーブルの生成方法、コミュニティ向けのデータセットへのアクセス方法、そして Net-NTLMv1 を無効化し、認証強制攻撃を防ぐための重要な対策手順を解説します。

背景

Net-NTLMv1 は、少なくとも 2012 年には安全でないことが広く知られるようになっています。DEFCON 20 での発表をきっかけに注目が集まりましたが、実際には、このプロトコルの暗号解析は 1999 年まで遡ります。さらに 2016 年 8 月 30 日には、Hashcat が既知の平文を使用したデータ暗号化標準(DES)鍵のクラックに対応し、このプロトコルを攻撃するための手法がより身近なものになりました。一方、レインボー テーブル自体も古い技術で、2003 年に Philippe Oechslin が最初の論文を発表しています。この論文では、1980 年に Martin Hellman が提案した「時間とメモリのトレードオフ」という考え方の初期の反復(イテレーション)を引用しています。

技術的に言うと、攻撃者が Extended Session Security(ESS)なしの Net-NTLMv1 ハッシュを取得でき、かつ既知の平文 1122334455667788 がわかっている場合、既知平文攻撃(KPA)と呼ばれる暗号攻撃を適用できます。この攻撃では、使用されている鍵素材を確実に復元できます。復元される鍵素材は、認証を行った Active Directory(AD)オブジェクト(ユーザーまたはコンピュータ)のパスワード ハッシュそのものです。そのため、攻撃結果はすぐにそのオブジェクトの侵害に利用でき、結果として権限昇格につながるケースが多く見られます。

実際の攻撃では、認証強制がよく使われます。たとえば、ドメイン コントローラ(DC)のような非常に高い権限を持つオブジェクトから認証を引き出す手法です。DC のマシン アカウントのパスワード ハッシュを復元できれば、DCSync 権限を取得でき、AD 内の他のあらゆるアカウントを侵害する足がかりになります。

データセットの公開

未ソートのデータセットは、gsutil -m cp gs://net-ntlmv1-tables/tables . を使用してダウンロードできます。また、Google Cloud Research Dataset ポータルから入手することも可能です。

テーブルの SHA-512 ハッシュを検証するには、まずチェックサム gsutil -m cp gs://net-ntlmv1-tables/tables.sha512 . をダウンロードします。その後、sha512sum -c tables.sha512 で整合性を確認します。なお、パスワード クラックのコミュニティでは、すでにこのデータセットをもとにした派生成果物が作られており、すぐに使える形式のテーブルを独自にホスティングしている例もあります。

テーブルの利用方法

Net-NTLMv1 のハッシュを取得した後は、従来型のものから近年改良されたものまで、各種レインボー テーブル検索ソフトウェアを使って解析できます。代表的な例としては、rainbowcrack(rcrack)、CPU 向けに最適化された RainbowCrack-NG、画像処理装置(GPU)上で動作する rainbowcrackalackフォーク版などがあります。事前に Net-NTLMv1 ハッシュを DES の各コンポーネントに分解する前処理が必要です。この処理には ntlmv1-multi を使用します。具体的な実行手順については、Net-NTLMv1 ハッシュの取得で説明します。

Net-NTLMv1 ハッシュの取得

多くの攻撃者は、Responder--lm フラグと --disable-ess フラグ付きで実行し、認証を 1122334455667788 という固定値に設定することで、接続を Net-NTLMv1 のみに限定させようとします。その後、攻撃者は接続を待機するか、PetitPotamDFSCoerce といったツールを使用して認証を強制し、DC や目的達成に有用な低権限ホストから接続を発生させます。取得したレスポンスをクラックすることで、ユーザー アカウントやコンピュータ マシン アカウントのパスワード ハッシュを回収できます。攻撃者のワークフローの例を、下の 図 1、図 2、図 3 に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig1.max-800x800.png

図 1: DC に対する DFSCoerce

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig2.max-600x600.png

図 2: DC のマシン アカウントに対して取得された Net-NTLMv1 ハッシュ

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig3.max-800x800.png

図 3: Net-NTLMv1 ハッシュを DES の各要素に分解

図 4 は、Net-NTLMv1 ハッシュを DES の暗号テキストに変換するプロセスを示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig4.max-2100x2100.png

図 4: Net-NTLMv1 ハッシュから DES 暗号テキストへの変換

その後、攻撃者は分割して得られた暗号テキストを使い、既知の平文 1122334455667788 を前提として、使用された鍵をクラックします。具体的には、図 5 に示す手順でテーブルを読み込み、図 6 と図 7 に示すような結果が得られるという流れです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig5.max-1100x1100.png

図 5: クラックのために DES コンポーネントを読み込み

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig6.max-500x500.png

図 6: 1 つ目のハッシュのクラック結果

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig7.max-1400x1400.png

図 7: 2 つ目のハッシュのクラック結果と実行統計

この段階まで進むと、攻撃者は残っている最後の鍵を、再度 ntlmv1-multi を使って計算するか、あるいは twobytes を使って検索することで求めることができます。これにより、DC のアカウントに対応する完全な NT ハッシュを再構成できます。その際の最後の鍵の算出例が 図 8 です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig8.max-600x600.png

図 8: 残りの鍵の計算

算出した結果は、Hashcat の NT ハッシュ シュッキング モードである -m 27000 を使用して検証できます。その様子を示したのが 図 9 です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig9.max-800x800.png

図 9: ハッシュ シュッキングによる鍵の検証

攻撃者はその後、取得したハッシュを使用して、乗っ取ったマシンアカウントとして認証を行い、DC に対して DCSync 攻撃を実行できます。この攻撃フローでは、Impacket ツールスイートに含まれる secretsdump.py が使用されます。実際の流れは 図 10 に示されています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/net-ntlmv1-fig10.max-1100x1100.png

図 10: DCSync 攻撃の実行

対策

組織は、Net-NTLMv1 の使用を直ちに無効化する必要があります。

ローカル コンピュータ ポリシー

[Local Security Settings] > [Local Policies] > [Security Options] > [Network security: LAN Manager authentication level] > [Send NTLMv2 response only]

グループ ポリシー

[Computer Configuration] > [Policies] > [Windows Settings] > [Security Settings] > [Local Policies] > [Security Options] > [Network Security: LAN Manager authentication level] > [Send NTLMv2 response only]

これらの設定はコンピュータごとのローカル構成であるため、攻撃者はローカル管理者権限を利用して構成をわざと脆弱な状態に変更し、攻撃が終わった後に元の状態に戻すことが可能です。このようなエッジケースを捕捉するだけでなく、Net-NTLMv1 がいつどこで使用されているかをモニタリングし、警告を発することも必要です。

イベントログをフィルタして、イベント ID 4624: 「An Account was successfully logged on.」を確認します。その中の [Detailed Authentication Information] > [Authentication Package] > [Package Name (NTLM only)] を参照し、この属性の値が「LM」または「NTLMv1」の場合、LAN Manager または Net-NTLMv1 が使用されたことを意味します。

関連ドキュメント

本プロジェクトは、以下に挙げるブログ投稿、ソーシャル メディア、コード リポジトリで公開されている研究に着想を得て、参考にしています。

謝辞

このブログ投稿の作成にあたり、協力いただいたすべての人に感謝します。特に、Chris King と Max Gruenberg には心から感謝しています。

- Mandiant

投稿先