.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
0x00はじめに
FOX-ITでは、企業組織で発生する一般的なセキュリティリスクを顧客に理解させることができます。攻撃者がNT LANマネージャー認証プロトコル（以下、NTLM認証と呼ばれる）を活用できる場合、このプロトコルは通常Microsoft Active Directoryで有効にされているという資格的再利用のリスクがあります。 NTLM認定の不安は15年以上前から存在しています。このプロトコルは、被害者の資格を予想とは異なるサービスに転送することにより、被害者の資格を乱用する「リレー」として知られるプロセスを通じて、被害者のセッションをハイジャックすることにより乱用することができます。多くの場合、NTLM認証は、デフォルトの認証方法でより安全なKerberosに置き換えられていても、デフォルトで依然としてサポートおよび有効になっています。
この記事では、有名なSMBRELAYXツールのFOX IT拡張機能であるNTLMRELAYXを使用して、LDAP、IMAP、およびMSSQLに資格情報をリレーする方法を示します。そのような攻撃から守るために：
可能であれば、NTLMをエンタープライズ組織内で完全に無効にし、Kerberosに切り替えます。
NTLMを無効にすることができない場合は、資格の再利用のリスクを減らすために、この記事で説明した設定とガイドラインを参照してください。
0x01 ntlmリレーの簡単な説明
NTLM認証は、チャレンジ応答プロトコルです。課題- 応答プロトコルは、共通の共有秘密（この場合はユーザーパスワード）を使用してクライアントを認証します。サーバーは質問を送信し、クライアントは質問の回答に応答します。チャレンジがサーバーによって計算された課題と一致する場合、認証は受け入れられます。 NTLM認証は複雑なプロトコルであり、ここでは簡単な説明です。非常に詳細な説明は、http://davenport.sourceforge.net/ntlm.htmlにあります。
1.NTLM認証プロセス
NTLM認証プロトコルには3つのステップがあります。
ネゴシエート認証：NTLM認証の最初のステップは、プロトコルネゴシエーションであり、クライアントがサポートする機能です。この段階では、クライアントが受け入れたNTLMバージョンを含む、クライアントがサーバーに認証要求を送信します。
サーバーの課題：サーバーは、受け入れるNTLMバージョンと使用したい機能を示す独自のメッセージに応答します。このメッセージには、認証に重要な「チャレンジ」値も含まれています。
認証応答：クライアントは、チャレンジに基づいて応答を返し、属するドメインのユーザー名とパスワードを含みます。
3つのメッセージと対話した後、サーバーは認証が成功しているか、認証が失敗したことを示すメッセージに返信します。クライアントとサーバーの間のセッションは、使用されるプロトコルに従って認証されました。このプロセスは、次の図に示されています。
2。 NTLMの乱用
攻撃者として、クライアントをハイジャックして攻撃者に接続できる場合、このプロセスは乱用される場合があります。これを行う方法については、次のセクションで説明します。攻撃者が認証された接続されたクライアントを持っていると、チャレンジ応答サイクルが完了するまで、クライアントとサーバーの間のサーバーに3つのメッセージを簡単に転送できます。
接続が認証されている場合、攻撃者は単にクライアントにエラーメッセージを送信するか、切断することができます。攻撃者は、セッションを使用して、リレー認証ユーザーからサーバーと対話できます。
3。Cross-Protocol（Cross）Relay
NTLM認証は他のプロトコルにカプセル化されていますが、メッセージは上部プロトコルに関係なく同じです。これにより、他のプロトコルでNTLMメッセージを使用できます。たとえば、HTTPで認証するクライアントは、「承認」ヘッダーにNTLM認証メッセージを送信します。攻撃者は、これらのメッセージをHTTPヘッダーから引き出し、SMBなどの他のプロトコルで使用できます。
NTLMは、SMB、HTTP（S）、LDAP、IMAP、SMTP、POP3、MSSQLなどのさまざまなプロトコルでサポートされています。
4。リレートラフィックを取得
まだ説明されていないもう1つのことは、実際のサーバーではなく、クライアントを攻撃者に接続する方法です。信頼できるトラフィックを取得するには、いくつかの方法があります。
安全でない方法でIPを解決するホストへのトラフィック
自己発見プロトコルの乱用によって引き起こされるトラフィック
中間の攻撃を通じて獲得されたトラフィック
4。安全でない名前解像度プロトコル
Unsafeプロトコルを使用して名前の解像度トラフィックを使用するFox-ITで発生することがよくあります。通常、ワークステーションまたはサーバーは、ネットワークに存在しなくなったホストまたはDNSを使用してホスト名を解決できないホストとして構成されます。これが発生すると、Windowsワークステーションは、NBNSやLLMNRなどの名前解像度プロトコルに戻ります。これは、ブロードキャストトラフィックに依存して同じネットワーク内のホストを要求して、ホスト名をIPアドレスに解決します。同じネットワークセグメントのすべてのホストは、このトラフィックを表示できるため（ファイアウォールの構成に応じて）、ホストはリクエストに返信できます。これにより、攻撃者が要求された名前のアドレスを偽造する機会が与えられます。プロセスを以下に示します。
5。自動発見（WPAD）プロトコル
おそらく、過去数年間でハッカーで最も悪名高い機能は、Windows Proxy Auto Detection（WPAD）機能です。この機能は基本的に、DNSを介してWPADという名前のホスト名を検索します。失敗した場合、上記のLLMNRおよびNBNを攻撃してから、見つけることができる最初のホストに接続できます。この機能の悪用は、認証を求められた場合、ワークステーションが自動的にNTLM認証を使用して認証を試みるため、容易になります。 Microsoftは2016年6月にこの分野でいくつかの問題にパッチを当てましたが、Fox-Itはまだネットワークでこれに遭遇します。
6。真ん中の攻撃の男
攻撃者が被害者のトラフィックを引き継ぐことは、特にARPスプーフィングなどのテクノロジーを使用する場合、企業ネットワークで非常に破壊的であることがよくあります。ただし、エンタープライズデバイスがパブリックWiFiネットワークなどの信頼されていないネットワークに接続すると、攻撃者は被害者を攻撃し、TLSによって保護されていないトラフィックを傍受し、被害者のワークステーションで信頼できる場所にリダイレクトできます。次に、自動イントラネット検出が有効になっている場合（これはデフォルト設定です）、被害者は自動的に認証されます。
7。NTLMRELAYXを使用して、NTLMをどこでもリレー
NTLM認証を悪用できるツールがいくつかあります。そのうちの1つは、Core SecurityのImpacketライブラリの一部であるSMBRELAYXです。 ntlmrelayxは、Fox-ITが開発したSMBRELAYXツールの拡張および部分的な書き換えです。さまざまなプロトコルに適したリレー機能があります。このツールは複数のターゲットを受け入れ、各ターゲット間でループして、認証されるシステムを見つけます。このツールにはSMBおよびHTTPサーバーがあり、そこからNTLM認証をSMB、HTTP（S）、IMAP、LDAP、およびMSSQLにリレーできます。
8。SMBへのリレー
SMBへのリレーは、すでにSMBRELAYXの一部である古典的な攻撃です。この攻撃に慣れていない場合、SMBに中継することで、リレーしたユーザーがデバイスに管理権限を持っている場合、攻撃者はSMB Signature Disabledのホストでファイルを実行できます。 ADMIN以外のユーザーの場合、NTLMRELAYXはSMBCLINERIENTシェルを起動するオプションを追加し、ファイルのダウンロードやアップロードなど、攻撃者がシェアと対話できるようにします。この攻撃は、たとえばNetCatに接続できるローカルTCPシェルを生成するインタラクティブフラグ（-I）を使用して実行できます。
9。LDAPへのリレー
LDAPへのリレーは、NTLMRELAYXの新機能です。 LDAPは、ディレクトリを直接クエリするために使用されるため、興味深いプロトコルです。これには、攻撃者にとって興味深い多くの情報が含まれています。さらに興味深いのは、デフォルトでは、コンピューターアカウントを含むドメイン内のすべてのアカウントがこの情報のほとんどを読むことができることです。これは、NTLMRELAYXが別のFOX IT開発ツールLDAPDOMAINDUMPと統合する場所です。このツールは、ユーザー、グループメンバーシップ、ドメインコンピューター、ドメインポリシーなど、ドメインからできるだけ多くの情報を収集しようとします。
情報の収集に加えて、LDAPを介してディレクトリに書き込むこともできます。 ntlmrelayxがドメイン管理者の特権を持つユーザーに遭遇した場合、攻撃者のドメインの完全な制御をすぐに持つ新しいドメイン管理者アカウントを作成します。
10。IMAPへのリレー
現在の交換バージョンではデフォルトでは有効になっていませんが、多くの企業組織はExchangeサーバー上のIMAPを介してNTLM認証を実行します。これにより、IMAPへのリレーが可能になり、攻撃者が被害者のメールに直接アクセスできます。 IMAPに中継すると、NTLMRELAYXには、電子メールでキーワードを検索するか、ユーザーの指定された受信トレイに最新の電子メールをすべてダウンロードするオプションがあります。
：
11。 MSSQL
へのリレーMSSQLへのリレーは現在理論的証明としてのみ存在しますが、データベースの犠牲者に実行されるコマンドラインでクエリを指定できます。
0x02緩和策
では、エンタープライズ組織はこれらの攻撃に抵抗するために何ができるでしょうか？上記のすべてがNLTM認証プロトコルを乱用しているため、唯一の完全な解決策はNTLMを完全に無効にしてKerberosに切り替えることです。ただし、多くのエンタープライズ組織には、Kerberos認証をサポートしていないレガシー製品またはオペレーティングシステムがあるため、NTLMを無効にすると、ビジネスに大きな影響があります。緩和として、さまざまな設定を有効にして、中間の攻撃のリスクを最小限に抑えることができます。
SMBの署名を有効にする：SMB署名は、すべてのトラフィックを署名することを要求することにより、SMBへの中継をブロックします。署名はメッセージを認証するためにユーザーのパスワードを必要とするため、接続を中継する攻撃者は、攻撃者が被害者のパスワードを持っていないため、サーバーによって受け入れられた通信を送信できません。
LDAPの署名を有効にする：SMB署名と同様に、LDAPの署名はLDAPへの署名のない接続を防ぎます。 TLSからLDAPへの接続が署名されていると見なされるため、この設定はTLSからLDAPへのリレー攻撃を防止しないことに注意する必要があります。
認証拡張保護を有効にする：認証のための拡張保護は、サーバーに接続するために使用されるTLSチャネルがクライアントが認証されたときに使用されるチャネルと同じであることを保証することにより、特定のリレー攻撃を防ぐのに役立ちます。この設定は、主にIISに適用されます。
SPNターゲット名の有効化：SPNターゲット名の確認は、クライアントが認証されていると思われるターゲット名を確認することにより、中間の攻撃をSMBへの攻撃を防ぐことができる別の軽減です。名前がサーバーと一致しない場合、認証は拒否されます。
内部Webサイトがhttpsを使用していることを確認してください：不安定なHTTPプロトコルを介して内部Webサイトにアクセスする場合、ユーザーは接続の信頼性を確認できません。すべての内部WebサイトにHTTPSメソッドのみに合格するように強制することにより、中間攻撃の効果が低下します。
一般的に強化して、中央の人間による攻撃を防ぐ
これらの特定のサーバー側の設定に加えて、次の一般的な硬化はNTLMリレーを防ぐことができます。
自動イントラネット検出の無効化：ドメインでNTLM認証が必要な場合は、ブラウザ（主にインターネットエクスプローラー）が信頼できるWebサイトのみを自動的に認証することを確認してください。グループポリシーを通じて、自動イントラネット検出を無効にすることができ、自動認証を適用する内部Webサイトのホワイトリストに従って自動認証のみを実行できます。上記のように、ここでのみHTTPS Webサイトを使用することを強くお勧めします。
Windowsエージェントの自動検出：WPADのセキュリティ問題は主にMicrosoft MS16-077セキュリティアップデートによって解決されますが、グループポリシーを通じてWPADを無効にすることをお勧めします。
LLMNR/NBNSを無効にする：これらの安全でない名前解像度プロトコルは、通常、よく構成されたネットワークでは必要ありません。それらを無効にすると、攻撃者が名前の解像度のスプーフィングを実行する可能性が減り、攻撃者が被害者をだまして攻撃者サーバーに接続するのが難しくなります。
0x03 get ntlmrelayx
NTLMRELAYXはImpacketリポジトリに提出されており、Impacketサンプルディレクトリにあります。
0x04その他のリソース
NTLMを理解しようとする私たちの研究のほとんどは、次のリソースの助けを借りて行われました。
http://davenport.sourceforge.net/ntlm.html（明確な説明ですが、Microsoftのオープンソースの前の逆プロトコルに基づいていくつかの部分が時代遅れです）
http://ubiqx.org/cifs/smb.html#smb.8.5（上記と同様）
https://msdn.microsoft.com/en-us/library/cc236621.aspx（公式契約文書、非常に技術的）
https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx(lmcompatibilityLevel Description）