Loading article…
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 つのパスワード値の 1 つまたは両方を使用します。これらの値は両方ともサーバー (またはドメイン コントローラー) に保存され、ソルトがないためパスワードと同等です。つまり、サーバーからハッシュ値を取得すれば、実際のパスワードを知らなくても認証できます。この 2 つは、LM ハッシュ( DESベースの関数を適用したパスワードの最初の 14 文字を言語の従来の 8 ビット PC 文字セットに変換したもの) と 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 つのパスワード ハッシュの 1 つ) を含む操作を実行します。クライアントは、計算の 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のセッションセキュリティを組み合わせたものです。
簡単に言うと、8 バイトのクライアント チャレンジが 8 バイトのサーバー チャレンジに追加され、MD5 ハッシュ化される点を除いて、NTLMv1 アルゴリズムが適用されます。ハッシュ結果の最小 8 バイトの半分が、NTLMv1 プロトコルで使用されるチャレンジです。クライアント チャレンジは、応答メッセージの 24 バイトのスロットの 1 つで返され、24 バイトの計算された応答は、他のスロットで返されます。
これは NTLMv1 の強化版であり、既存のドメイン コントローラ インフラストラクチャを使用する機能を維持しながら、不正なサーバーによる辞書攻撃を回避します。固定Xに対して、サーバーは場所Yが値Kを持ち、 Y=DES_K(X)となるテーブルを計算します。クライアントがチャレンジの選択に参加しなくても、サーバーはX を送信し、テーブルで応答Y を検索してKを取得できます。この攻撃は、レインボー テーブルを使用することで実現できます。[18]
ただし、既存の NTLMv1 インフラストラクチャでは、チャレンジ/レスポンス ペアはサーバーによって検証されず、検証のためにドメイン コントローラーに送信されます。NTLM2 セッションを使用すると、サーバーがチャレンジの代わりにサーバーとクライアントのチャレンジのハッシュを使用する場合、このインフラストラクチャは引き続き機能します。
NTLMv1 クライアント<-サーバー: SC クライアント→サーバー: H(P,SC) サーバー->ドメイン制御: H(P,SC)、SC サーバー<-DomCntl: はいまたはいいえ NTLM2 セッション クライアント<-サーバー: SC クライアント->サーバー: H(P,H'(SC,CC)), CC サーバー->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) サーバー<-DomCntl: はいまたはいいえ
NTLM の可用性と使用
2010年以降、マイクロソフトはアプリケーションでのNTLMの使用を推奨しなくなった。[19]
実装者は、NTLM が AES や SHA-256 などの最新の暗号化方式をサポートしていないことに注意する必要があります。整合性には巡回冗長検査(CRC) またはMD5 を使用し、暗号化にはRC4 を使用します。
パスワードからキーを派生する方法は、RFC1320 および FIPS46-2 で指定されています。したがって、アプリケーションでは一般に NTLM を使用しないことが推奨されます。
これらの推奨事項にもかかわらず、NTLM は依然としてシステムに広く導入されています。[引用が必要]主な理由は、古いシステムとの互換性を維持するためです。ただし、状況によっては回避できます。[方法は? ]
Microsoft は、相互運用性 (特に RC4-HMAC 暗号化タイプ) を向上させるために、Kerberos プロトコルの実装に NTLM ハッシュを追加しました。独立した研究者によると、この設計決定により、NTLM ハッシュがわかっている場合、ドメイン コントローラーは攻撃者に Kerberos チケットを発行するように仕向けられる可能性があります。 [20] Microsoft は、Windows 2000 およびそれ以降の Active Directory ドメインの優先認証プロトコルとしてKerberos を 採用しました。 [16] Kerberos は通常、サーバーがWindows Server ドメインに属している場合に使用されます。Microsoft は、開発者が 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 の役割を果たします。たとえば、ネットワーク ログオン時にそのアカウントが使用される場合、管理者などのローカル アカウントを持つ Windows コンピューターが DC の役割を果たします。
Windows NT 4.0 Service Pack 4 より前では、SSP は NTLMv1 をネゴシエートし、他のマシンが LM をサポートしていない場合は LM にフォールバックしていました。
Windows NT 4.0 Service Pack 4 以降、クライアントとサーバーの両方がサポートしている場合は、SSP は NTLMv2 セッションをネゴシエートします。[24] Windows XP までは、米国以外のコンピューターでは 40 ビットまたは 56 ビットの暗号化が使用されていました。これは、当時米国が暗号化技術の輸出に厳しい制限を設けていたためです。Windows XP SP3 以降では、更新プログラムをインストールすることで 128 ビットの暗号化を追加できるようになり、Windows 7 では 128 ビットの暗号化がデフォルトになります。
Windows Vista 以降では、受信認証では LM は無効になっています。Windows Server 2003 までの Windows NT ベースのオペレーティング システムでは、LAN Manager (LM) ハッシュと Windows NT ハッシュの 2 つのパスワード ハッシュが保存されます。Windows Vista以降では、両方を保存する機能がありますが、1 つはデフォルトで無効になっています。つまり、Windows Vista を実行しているコンピューターがサーバーとして機能する場合、LM 認証は機能しなくなります。以前のバージョンの Windows (Windows NT 4.0 Service Pack 4 まで遡る) では、このように動作するように構成できましたが、デフォルトではありませんでした。[25]
弱点と脆弱性
NTLM は依然としてパスザハッシュ攻撃に対して脆弱であり、これはMicrosoft セキュリティ更新プログラム MS08-068 で対処されたリフレクション攻撃の変種です。たとえば、Metasploit は多くの場合、あるマシンから資格情報を取得し、別のマシンを制御するために使用できます。[3] [26] Squirtle ツールキットを使用すると、Web サイトのクロスサイトスクリプティング攻撃を利用して、NTLM 経由で近くの資産を攻撃できます。[27]
2010 年 2 月、Amplia Security は Windows の NTLM 認証メカニズムの実装にいくつかの欠陥を発見しました。この欠陥によりプロトコルのセキュリティが破られ、攻撃者がファイルへの読み取り/書き込みアクセスやリモート コード実行が可能になりました。提示された攻撃の 1 つには、プロトコルによって生成される疑似乱数とチャレンジ/レスポンスを予測する機能が含まれていました。これらの欠陥は、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]が実証したように、DESキーをhashcatモード14000でクラッキングすることで、既知の平文攻撃を使用してNTLMハッシュを導出できます。
パスザハッシュ攻撃やパスワードクラッキングで使用されるパスワードと同等のハッシュは、まず「盗まれる」必要があることに注意してください (ハッシュにアクセスするのに十分な権限を持つシステムを侵害するなど)。また、これらのハッシュは、従来の NTLM 認証中にネットワーク経由で送信される NTLMSSP_AUTH「ハッシュ」と同じではありません。
Linuxとの互換性
LinuxのNTLM実装にはCntlm [37]やwinbind（Sambaの一部）[38]が含まれ、LinuxアプリケーションがNTLMプロキシを使用できるようになります。
FreeBSDは、安全でないNTハッシュ形式でCrypt（C）を介してパスワードを保存することもサポートしています。 [39]
参照
参考文献
- ^ ab 「はじめに」、NT LAN Manager (NTLM) 認証プロトコル仕様、Microsoft 、 2010 年 8 月 15 日取得
- ^ 「セッション セキュリティの詳細」、NT LAN Manager (NTLM) 認証プロトコル仕様、Microsoft 、 2010 年 8 月 15 日取得
- ^ ab Takahashi, T (2009-12-17)、「NTLM リフレクションの考察」、FrequencyX ブログ、IBM Internet System Security (ISS)、2009-12-31 にオリジナルからアーカイブ、2010-08-14 に取得
- ^ ab 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 版)、Microsoft 、 2010 年 8 月 15 日取得
- ^ 「Connectionless」、NT LAN Manager (NTLM) 認証プロトコル仕様(3.1.5.2 版)、Microsoft 、 2010 年 8 月 15 日取得
- ^ 「NEGOTIATE_MESSAGE」、NT LAN Manager (NTLM) 認証プロトコル仕様(2.2.1.1 版)、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 版)、Microsoft 、 2010 年 8 月 15 日取得
- ^ ab 「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 日に取得
- ^ ab 「セキュリティ構成」、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-08-08). 棺を釘で閉じろ、NTLM は死んだ。Defcon 16。
- ^ Hernan Ochoa および Agustin Azubel (2010-07-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-02-13). 「手動で調整された hashcat 6.0.0 ベータ版と 2080Ti (標準クロック) が、単一のコンピューティング デバイスで NTLM クラッキング速度の 100GH/s を突破」@hashcat 。2019 年 2 月 26 日閲覧。
- ^ 現代のレインボーテーブルの使用例
- ^ 「倫理的なハッカー、ダスティン・ヘイウッド、別名EvilMog：「私の使命は企業をより安全にすることです」」The Globe and Mail。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 認証フレームワーク
- objectif-securite (ophcrack 用のレインボー テーブル)
- Px for Windows - NTLMプロキシを介して自動的に認証するHTTPプロキシサーバー
- NTLMv1 マルチツール - NTLMv1 チャレンジレスポンスを hashcat で解読できる形式にフォーマットするツール