Windowsネットワークでは、NT (New Technology) LAN Manager ( NTLM ) は、ユーザーに認証、整合性、機密性を提供することを目的としたMicrosoftセキュリティ プロトコルのスイートです。 [ 1 ] [ 2 ] [ 3 ] NTLM は、以前の Microsoft 製品である Microsoft LAN Manager (LANMAN)の認証プロトコルの後継です。NTLM プロトコル スイートは、LAN Manager認証プロトコル、NTLMv1、NTLMv2、および NTLM2 セッション プロトコルを 1 つのパッケージに組み合わせたセキュリティ サポート プロバイダーに実装されています。これらのプロトコルがシステムで使用されるか、または使用できるかどうかは、グループ ポリシー設定によって管理され、Windows のバージョンによってデフォルト設定が異なります。
NTLMパスワードは、現代のハードウェアで簡単にブルートフォース攻撃に遭う可能性があるため、弱いと考えられています。 [ 4 ]
プロトコル
NTLMはチャレンジレスポンス認証プロトコルであり、コネクション指向環境(コネクションレス型も同様)でクライアントを認証するために3つのメッセージを使用し、整合性が必要な場合は4つ目の追加メッセージを使用します。[ 5 ] [ 6 ] [ 7 ] [ 8 ]
- まず、クライアントはサーバーへのネットワークパスを確立し、その機能を通知するNEGOTIATE_MESSAGEを送信します。[ 9 ]
- 次に、サーバーはクライアントのIDを確立するために使用されるCHALLENGE_MESSAGEで応答します。[ 10 ]
- 最後に、クライアントはAUTHENTICATE_MESSAGEでチャレンジに応答します。[ 11 ]
NTLMプロトコルは、2つのハッシュ化されたパスワード値の一方または両方を使用します。これらのハッシュ値は両方ともサーバー(またはドメインコントローラー)に保存され、ソルト化されていないためパスワードと同等です。つまり、サーバーからハッシュ値を取得すれば、実際のパスワードを知らなくても認証できます。この2つのハッシュ値は、LMハッシュ(DESベースの関数を適用し、その言語の従来の8ビットPC文字セットに変換されたパスワードの最初の14文字)とNTハッシュ(リトルエンディアンUTF-16 UnicodeパスワードのMD4)です。どちらのハッシュ値もそれぞれ16バイト(128ビット)です。[ 12 ]
NTLMプロトコルは、NTLMのバージョンに応じて2つの一方向関数のいずれかを使用します。NT LanManとNTLMバージョン1はDESベースのLanMan一方向関数(LMOWF)を使用し、NTLMv2はNT MD4ベースの一方向関数(NTOWF)を使用します。[ 12 ] [ 13 ]
NTLMv1
サーバーは、8バイトの乱数(チャレンジ)を送信することでクライアントを認証します。クライアントは、チャレンジと、クライアントとサーバー間で共有される秘密鍵(具体的には、前述の2つのパスワードハッシュのいずれか)を用いた処理を実行します。クライアントは、計算結果である24バイトを返します。実際、NTLMv1では通常、両方のハッシュを用いて計算が行われ、24バイトの結果が両方とも送信されます。サーバーは、クライアントが正しい結果を計算したことを確認し、そこから秘密鍵を所有していること、ひいてはクライアントの信頼性を推測します。
どちらのハッシュも16バイトの値を生成します。5バイトのゼロが付加されて21バイトになります。この21バイトは3つの7バイト(56ビット)の値に分割されます。これらの56ビットの値はそれぞれ、 64ビットのチャレンジをDES暗号化するための鍵として使用されます。チャレンジの3つの暗号化は再結合され、24バイトのレスポンスが生成されます。レスポンスにはLMハッシュとNTハッシュの両方が返されますが、これは設定可能です。
C = 8バイトのサーバーチャレンジ、ランダム K1 | K2 | K3 = NTLMハッシュ | 5バイト-0 応答 = DES(K1,C) | DES(K2,C) | DES(K3,C)
NTLMv2
NTLMv2は、 Windows NT 4.0 SP4 [ 14 ]で導入され(Windows 2000ではネイティブサポートされています)、チャレンジレスポンス認証プロトコルです。NTLMv1の暗号的に強化された代替プロトコルとして設計されており、多くのスプーフィング攻撃に対するプロトコルの堅牢化と、サーバーによるクライアントへの認証機能の追加により、NTLMのセキュリティを強化しています。[ 1 ] [ 15 ] [ 16 ]
NTLMv2 は、8 バイトのサーバー チャレンジに対して 2 つの応答を送信します。各応答には、サーバー チャレンジの16 バイトHMAC - MD5ハッシュ、完全にまたは部分的にランダムに生成されたクライアント チャレンジ、ユーザーのパスワードとその他の識別情報からなる HMAC-MD5 ハッシュが含まれます。2 つの応答は、クライアント チャレンジの形式が異なります。短い方の応答では、このチャレンジに 8 バイトのランダム値が使用されます。応答を検証するには、サーバーは応答の一部としてクライアント チャレンジを受信する必要があります。この短い応答では、16 バイトの応答に 8 バイトのクライアント チャレンジが付加されて 24 バイトのパッケージが作成されます。これは、以前の NTLMv1 プロトコルの 24 バイトの応答形式と一致しています。一部の非公式ドキュメント (DCE/RPC Over SMB、Leighton など) では、この応答は LMv2 と呼ばれています。
NTLMv2によって送信される2番目のレスポンスは、可変長のクライアントチャレンジを使用します。このチャレンジには、(1) NT時刻形式の現在時刻、(2) 8バイトのランダム値(下のボックスのCC2)、(3) ドメイン名、(4) いくつかの標準形式の情報が含まれます。レスポンスにはこのクライアントチャレンジのコピーが含まれる必要があるため、可変長となります。非公式ドキュメントでは、このレスポンスはNTv2と呼ばれます。
LMv2とNTv2はどちらも、クライアントとサーバーのチャレンジを、ユーザーのパスワードやその他の識別情報のNTハッシュでハッシュ化します。正確な計算式は、SAMまたはADに保存されているNTハッシュから開始し、 HMAC - MD5を使用してユーザー名とドメイン名をハッシュ化していきます。下のボックスで、Xはフォーマットフィールドの固定コンテンツを表します。
SC = 8バイトのサーバーチャレンジ、ランダム CC = 8バイトのクライアントチャレンジ、ランダム CC* = (X, 時間, CC2, ドメイン名) v2-ハッシュ = HMAC-MD5(NT-ハッシュ、ユーザー名、ドメイン名) LMv2 = HMAC-MD5(v2-ハッシュ、SC、CC) NTv2 = HMAC-MD5(v2-ハッシュ、SC、CC*) 応答 = LMv2 | CC | NTv2 | CC*
NTLM2セッション
NTLM2セッションプロトコルはMS-CHAPv2に似ています。[ 17 ] NTLMv1の認証とNTLMv2のセッションセキュリティを組み合わせたものです。
簡単に説明すると、NTLMv1アルゴリズムが適用されますが、8バイトのサーバーチャレンジに8バイトのクライアントチャレンジが付加され、MD5ハッシュ化されます。ハッシュ結果の下位8バイトが、NTLMv1プロトコルで使用されるチャレンジです。クライアントチャレンジはレスポンスメッセージの24バイトスロットの1つで返され、24バイトの計算されたレスポンスはもう1つのスロットで返されます。
これはNTLMv1の強化版であり、既存のドメインコントローラ基盤を利用しつつ、不正なサーバによる辞書攻撃を回避します。Xを固定値とすると、サーバはYの位置がKの値を持つテーブルを計算します。このテーブルはY=DES_K(X)となります。クライアントがチャレンジの選択に参加しなくても、サーバはXを送信し、テーブルからレスポンスYを参照してKを取得できます。この攻撃はレインボーテーブルを用いることで実現可能です。[ 18 ]
しかし、既存のNTLMv1インフラストラクチャでは、チャレンジ/レスポンスのペアはサーバーによって検証されず、ドメインコントローラーに送信されて検証されます。NTLM2セッションを使用すると、サーバーがチャレンジの代わりにサーバーとクライアントのチャレンジのハッシュを使用することで、このインフラストラクチャは引き続き機能します。
NTLMv1 クライアント<-サーバー: SC クライアント→サーバー: H(P,SC) サーバー->DomCntl: H(P,SC), SC Server<-DomCntl: はいまたはいいえ NTLM2セッション クライアント<-サーバー: SC クライアント→サーバー: H(P,H'(SC,CC)), CC サーバー->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) Server<-DomCntl: はいまたはいいえ
NTLMの可用性と使用
2010年以降、マイクロソフトはアプリケーションでのNTLMを推奨しなくなりました。[ 19 ]
実装者は、NTLM が AES や SHA-256 といった最新の暗号化方式をサポートしていないことに注意する必要があります。整合性の保証には巡回冗長検査(CRC) またはMD5を使用し、暗号化にはRC4 を使用します。
パスワードからキーを導出する方法は、RFC1320およびFIPS46-2で規定されています。したがって、アプリケーションでは一般的にNTLMを使用しないことが推奨されます。
これらの推奨事項にもかかわらず、NTLMは依然として多くのシステムに導入されています。主な理由は、古いシステムとの互換性を維持するためです。ただし、状況によっては回避できる場合もあります。
マイクロソフトは、相互運用性(特にRC4-HMAC暗号化タイプ)を向上させるため、Kerberosプロトコルの実装にNTLMハッシュを追加しました。ある独立系研究者によると、この設計決定により、NTLMハッシュが既知の場合、ドメインコントローラは攻撃者にKerberosチケットを発行するように仕向けられる可能性があるとのことです。 [ 20 ] マイクロソフトは、Windows 2000以降のActive Directoryドメインの優先認証プロトコルとしてKerberosを採用しました。 [ 16 ] Kerberosは通常、サーバーがWindows Serverドメインに属している場合に使用されます。マイクロソフトは、開発者がKerberosやNTLMセキュリティサポートプロバイダー(SSP)を直接使用しないことを推奨しています。[ 21 ]
アプリケーションはNTLMセキュリティパッケージに直接アクセスするのではなく、Negotiateセキュリティパッケージを使用する必要があります。Negotiateを使用すると、認証に関与するシステムでサポートされている場合、アプリケーションはより高度なセキュリティプロトコルを利用できます。現在、NegotiateセキュリティパッケージはKerberosとNTLMのいずれかを選択します。認証に関与するシステムのいずれかでKerberosが使用できない場合を除いて、NegotiateはKerberosを選択します。
NTLMセキュリティサポートプロバイダーの使用
NTLM SSP は次の状況で使用されます。
- クライアントは、ドメインに属していないサーバー、または Active Directory ドメインが存在しないサーバーに対して認証しています (一般に「ワークグループ」または「ピアツーピア」と呼ばれます)
- サーバーでは「パスワード保護共有」機能が有効になっている必要がありますが、この機能はデフォルトでは有効になっておらず、一部のバージョンの Windows ではホームグループと相互に排他的です。
- サーバーとクライアントの両方が同じホームグループに属している場合、 NTLMの代わりにKerberosに似たプロトコルである公開キー暗号化ベースのユーザー間認証が使用されます。 [ 22 ]ホームグループは、おそらく小規模ネットワークでリソースを共有する最も簡単な方法であり、パスワードで保護された共有を使用できるようにいくつかの追加ユーザーを構成する場合と比較しても、最小限の設定で済みます。そのため、小規模ネットワークやホームネットワークでは、パスワードで保護された共有よりもはるかに多く使用されている可能性があります。
- サーバーがNASデバイスやネットワークプリンターなどのSMBをサポートするデバイスである場合、NTLM SSPが唯一サポートされている認証方式となる場合があります。SMBの一部の実装、またはSambaなどの古いディストリビューションでは、WindowsがSMBサーバーとの送信認証にNTLMv1、あるいはLMをネゴシエートすることがあります。その結果、デバイスが新しいデバイスであっても、古くて安全でないソフトウェアが搭載されていても、デバイスは動作してしまいます。
- サーバーがドメインのメンバーであっても、Kerberos を使用できない場合。
- クライアントはIP アドレスを使用してサーバーに認証しています(逆名前解決は利用できません)
- クライアントは、推移的なフォレスト間信頼ではなく、従来の NTLM 信頼を持つ別の Active Directory フォレストに属するサーバーに認証しています。
- ファイアウォールがKerberosに必要なポート(通常はTCP 88)を制限する場合
プロトコルバージョンの使用
アプリケーション開発者またはネゴシエートSSPによって認証にNTLM SSPを使用することが決定された後、グループポリシーはNTLM SSPが実装する各プロトコルの使用権限を指定します。認証レベルは5つあります。[ 23 ]
- LM および NTLM 応答を送信: クライアントは LM および NTLM 認証を使用し、NTLMv2 セッション セキュリティは使用しません。DC は LM、NTLM、および NTLMv2 認証を受け入れます。
- LM と NTLM を送信 - ネゴシエートされた場合は NTLMv2 セッション セキュリティを使用する: クライアントは LM および NTLM 認証を使用し、サーバーがサポートしている場合は NTLMv2 セッション セキュリティを使用します。DC は LM、NTLM、および NTLMv2 認証を受け入れます。
- NTLM 応答のみ送信: クライアントは NTLM 認証のみを使用し、サーバーがサポートしている場合は NTLMv2 セッション セキュリティを使用します。DC は LM、NTLM、および NTLMv2 認証を受け入れます。
- NTLMv2 応答のみ送信: クライアントは NTLMv2 認証のみを使用し、サーバーがサポートしている場合は NTLMv2 セッション セキュリティを使用します。DC は LM、NTLM、および NTLMv2 認証を受け入れます。
- NTLMv2 応答のみを送信\LM を拒否: クライアントは NTLMv2 認証のみを使用し、サーバーがサポートしている場合は NTLMv2 セッション セキュリティを使用します。DC は LM を拒否します (NTLM と NTLMv2 認証のみを受け入れます)。
- NTLMv2 応答のみを送信\LM と NTLM を拒否: クライアントは NTLMv2 認証のみを使用し、サーバーがサポートしている場合は NTLMv2 セッション セキュリティを使用します。DC は LM と NTLM を拒否します (NTLMv2 認証のみを受け入れます)。
DCはドメインコントローラを意味しますが、この用語の使用は混乱を招きます。サーバーとして機能し、ユーザーを認証するコンピュータは、この文脈ではDCの役割を果たします。例えば、ネットワークログオン時にAdministratorなどのローカルアカウントが使用されるWindowsコンピュータなどがこれに該当します。
Windows NT 4.0 Service Pack 4 より前では、SSP は NTLMv1 をネゴシエートし、他のマシンが NTLMv1 をサポートしていない場合は LM にフォールバックしていました。
Windows NT 4.0 Service Pack 4以降、SSPはクライアントとサーバーの両方がNTLMv2セッションをサポートしている場合、常にNTLMv2セッションをネゴシエートするようになりました。[ 24 ] Windows XPまでは、米国以外のコンピュータでは40ビットまたは56ビットの暗号化が使用されていました。これは、当時米国が暗号化技術の輸出に厳しい制限を設けていたためです。Windows XP SP3以降では、更新プログラムをインストールすることで128ビット暗号化を追加できるようになり、Windows 7では128ビット暗号化がデフォルトになりました。
Windows Vista以降では、受信認証においてLMは無効になっています。Windows NTベースのオペレーティングシステム(Windows Server 2003を含む)は、LAN Manager(LM)ハッシュとWindows NTハッシュの2つのパスワードハッシュを保存します。Windows Vista以降では、両方を保存する機能がありますが、片方はデフォルトで無効になっています。つまり、Windows Vistaを実行しているコンピュータがサーバーとして機能する場合、LM認証は機能しなくなります。以前のバージョンのWindows(Windows NT 4.0 Service Pack 4まで)では、このように動作するように設定できましたが、デフォルトではありませんでした。[ 25 ]
弱点と脆弱性
NTLMは依然としてパス・ザ・ハッシュ攻撃に対して脆弱です。これは、Microsoftセキュリティ更新プログラムMS08-068で修正されたリフレクション攻撃の亜種です。例えば、Metasploitは多くの場合、あるマシンから認証情報を取得し、それを使って別のマシンを制御するために利用されます。[ 3 ] [ 26 ] Squirtleツールキットは、ウェブサイトのクロスサイトスクリプティング攻撃を、NTLM経由で近隣の資産への攻撃に利用するために利用される可能性があります。[ 27 ]
2010年2月、Amplia SecurityはWindowsのNTLM認証メカニズムの実装に複数の脆弱性を発見しました。これらの脆弱性によりプロトコルのセキュリティが破られ、攻撃者がファイルへの読み取り/書き込みアクセスやリモートコード実行を行えるようになりました。提示された攻撃手法の一つには、プロトコルによって生成される疑似乱数やチャレンジ/レスポンスを予測する能力が含まれていました。これらの脆弱性は17年間にわたりWindowsの全バージョンに存在していました。これらの問題を説明するセキュリティアドバイザリには、完全に動作する概念実証エクスプロイトが含まれていました。これらの脆弱性はすべてMS10-012で修正されました。[ 28 ] [ 29 ]
2012年には、8文字のNTLMパスワードハッシュの組み合わせをすべて6時間以内に解読できることが実証されました。 [ 30 ]
2019年には、より近代的なハードウェアを使用することで、この時間は約2.5時間に短縮されました。[ 4 ] [ 31 ]また、 8文字と9文字のNTLMパスワードにはレインボーテーブルが利用可能です。これより短いパスワードは、ブルートフォース攻撃によって復元可能です。[ 32 ]
2019年、EvilMog [ 33 ] [ 34 ]は、NTLMv1チャレンジレスポンスをHashcat互換のクラッキング形式でフォーマットするためのntlmv1-multitool [ 35 ] というツールを公開しました。Hashcatと十分なGPUパワーがあれば、HashcatフォーラムのAtom [ 36 ]が実演したように、Hashcatモード14000でDES鍵をクラッキングすることで、既知平文攻撃を用いてNTLMハッシュを導出できます。
Pass-the-Hash攻撃やパスワードクラッキングで使用されるパスワード相当のハッシュは、まず「盗む」必要があることに注意してください(例えば、ハッシュにアクセスするための権限を持つシステムに侵入するなど)。また、これらのハッシュは、従来のNTLM認証でネットワーク経由で送信されるNTLMSSP_AUTH「ハッシュ」とは異なります。
Linuxとの互換性
LinuxのNTLM実装にはCntlm [ 37 ]とwinbind ( Sambaの一部)[ 38 ]が含まれ、LinuxアプリケーションがNTLMプロキシを使用できるようになります。
FreeBSDは、安全でないNTハッシュ形式でCrypt(C)を介してパスワードを保存することもサポートしています。 [ 39 ]
参照
参考文献
- ^ a b「はじめに」、NT LAN Manager (NTLM) 認証プロトコル仕様、Microsoft 、 2010年8月15日取得
- ^ 「セッションセキュリティの詳細」、NT LAN Manager(NTLM)認証プロトコル仕様、Microsoft 、 2010年8月15日取得
- ^ a b Takahashi, T (2009-12-17)、「NTLMリフレクションの考察」、FrequencyX Blog、IBM Internet System Security (ISS)、2009年12月31日時点のオリジナルよりアーカイブ、 2010年8月14日取得
- ^ a b Claburn, Thomas (2019年2月14日). 「8文字のWindows NTLMパスワードを使う?やめよう。どれも2.5時間以内に解読される可能性がある」 www.theregister.co.uk . 2020年11月26日閲覧。
- ^ 「Microsoft NTLM」、MSDN、Microsoft 、 2010年8月15日閲覧。
- ^ 「メッセージ構文 | セクション 2.2」、NT LAN Manager (NTLM) 認証プロトコル仕様、Microsoft 、 2010年8月15日取得
- ^ 「コネクション指向」、NT LAN Manager (NTLM) 認証プロトコル仕様(3.1.5.1 ed.)、Microsoft 、 2010年8月15日取得
- ^ 「コネクションレス」、NT LAN Manager (NTLM) 認証プロトコル仕様(3.1.5.2 版)、Microsoft 、 2010年8月15日取得
- ^ "NEGOTIATE_MESSAGE"、NT LAN Manager (NTLM) 認証プロトコル仕様(2.2.1.1 ed.)、Microsoft 、 2010年8月15日取得
- ^ "CHALLENGE_MESSAGE"、NT LAN Manager (NTLM) 認証プロトコル仕様(2.2.1.2 版)、Microsoft 、 2010年8月15日取得
- ^ "AUTHENTICATE_MESSAGE"、NT LAN Manager (NTLM) 認証プロトコル仕様(2.2.1.3 ed.)、Microsoft 、 2010年8月15日取得
- ^ a b「NTLM v1 認証」、NT LAN Manager (NTLM) 認証プロトコル仕様(3.3.1 版)、Microsoft 、 2010年8月15日取得
- ^ 「NTLM v2 認証」、NT LAN Manager (NTLM) 認証プロトコル仕様(3.3.1 版)、Microsoft 、 2010 年 8 月 15 日取得
- ^ Windows NT 4.0 Service Pack 4 の新機能は何ですか?
- ^ NTLM 2 認証を有効にする方法、サポート、Microsoft、2007 年 1 月 25 日、 2010 年 8 月 14 日取得
- ^ a b「セキュリティ構成」、Microsoft Windows 2000 セキュリティ強化ガイド、TechNet、Microsoft、2009年3月24日、 2010年8月14日取得
- ^グラス、エリック、「NTLM」、ダベンポート、ソースフォージ
- ^ Varughese, Sam (2006年2月). 「Rainbow Cracking and Password Security」 . Palisade. 2010年6月1日時点のオリジナルよりアーカイブ。 2010年8月14日閲覧。
- ^ 「実装者のためのセキュリティに関する考慮事項」、NT LAN Manager(NTLM)認証プロトコル仕様、Microsoft 、 2010年8月16日取得
- ^ 「Active Directoryの脆弱性公開:脆弱な暗号化により、攻撃者はログインせずに被害者のパスワードを変更できる - Aorato」 。 2014年10月6日時点のオリジナルよりアーカイブ。 2014年10月5日閲覧。
- ^ 「Microsoft NTLM」 . TechNetライブラリ. Microsoft . 2015年11月2日閲覧。
- ^ 「公開鍵暗号化ベースのユーザー間認証の概要」 TechNetライブラリMicrosoft 2015年11月2日閲覧。
- ^ 「LAN Manager 認証レベル」 . MSDN ライブラリ. Microsoft . 2015年11月2日閲覧。
- ^ 「Windows 認証」 . TechNet ライブラリ. Microsoft. 2011年6月29日. 2015年11月2日閲覧。
- ^ Jesper Johansson. 「史上最も誤解されているWindowsのセキュリティ設定」 . TechNet Magazine . Microsoft . 2015年11月2日閲覧。
- ^ HD Moore. 「MS08-068: Metasploit と SMB リレー」 .
- ^ Kurt Grutzmacher (2008年8月8日). 「棺を釘で閉じろ、NTLMは死んだ」 . Defcon 16.
- ^ Hernan Ochoa、Agustin Azubel (2010年7月28日). Windows SMB NTLM Weak Nonce脆弱性の理解(PDF) . Blackhat USA 2010.
- ^ Hernan Ochoa、Agustin Azubel. 「Windows SMB NTLM Weak Nonce 脆弱性セキュリティアドバイザリ」 .
- ^ Goodin, Dan (2012年12月10日). 「25個のGPUクラスターが6時間以内にあらゆる標準Windowsパスワードを解読」 Ars Technica . 2020年11月23日閲覧。
- ^ hashcat (2019年2月13日). 「手動調整されたhashcat 6.0.0ベータ版と2080Ti(標準クロック)が、単一のコンピューティングデバイスでNTLMクラッキング速度の100GH/sを突破」 . @hashcat . 2019年2月26日閲覧。
- ^現代のレインボーテーブルの使用例
- ^ 「倫理的なハッカー、ダスティン・ヘイウッド(別名EvilMog):「私の使命は企業をより安全にすることです」「 .グローブ・アンド・メール. 2019年12月9日. 2023年10月12日閲覧。
- ^ 「ダスティン・ヘイウッド:神経多様性を持つ知性を善のために利用する『邪悪な』ハッカー」IBMニュースルーム。2023年10月12日閲覧。
- ^ Heywood, Dustin (2023-10-11)、2020年11月10日更新、 2023年10月12日閲覧
- ^ 「DES KPAモードを活用する方法」 . hashcat.net . 2023年10月12日閲覧。
- ^ 「Cntlm: C での高速 NTLM 認証プロキシ」。
- ^ 「NTLM 認証 - MoodleDocs」。
- ^ 「FreeBSDの新しいパスワード暗号化方法としてのNT MD4パスワードハッシュ」 Mail-archive.com 2018年12月2日閲覧。
外部リンク
- レインボーテーブルを使ったオンラインNTLMハッシュクラック
- NT LAN Manager (NTLM) 認証プロトコル仕様
- Cntlm – NTLM、NTLMSR、NTLMv2 認証プロキシおよびアクセラレータNTLM 非対応アプリケーション用のパーソナル HTTP(S) および SOCKS5 プロキシ (Windows/Linux/UNIX)
- NTLM 認証プロトコルとセキュリティ サポート プロバイダーNTLM プロトコルの詳細な分析。
- プロトコルとその名前が変更されたことを説明するMSDNの記事
- NTLM認証に関するMSDNページ
- Libntlm – 無料の実装。
- ユーザーが MS プロキシ サーバー経由で認証できるようにするNTLM 認証プロキシ サーバーソフトウェア。
- NTLM認証のインストール- Linux上のSambaとMidgardのNTLM設定手順
- NTLMバージョン2(NTLMv2)とそれを制御するLMCompatibilityLevel設定
- Jespa – Java Active Directory 統合、サーバー側 NETLOGON 検証機能を備えた完全な NTLM セキュリティ サービス プロバイダー(商用ですが、25 ユーザーまで無料)
- EasySSO - JIRA 用の NTML 認証システムJespaライブラリを利用してAtlassian製品用のIWAを提供するNTLM 認証システム。
- ntlmv2-auth NTLMv2 API および Java 用サーブレット フィルタ
- ntlmメッセージ生成ツール
- WAFFLE – Java/C# Windows 認証フレームワーク2010年10月20日アーカイブWayback Machine
- objectif-securite (ophcrack 用のレインボー テーブル)
- Px for Windows - NTLMプロキシを介して自動的に認証するHTTPプロキシサーバー
- NTLMv1 マルチツール- NTLMv1 チャレンジレスポンスを hashcat で解読できる形式にフォーマットするツール