🛡️ Impacket findDelegation スクリプト徹底解説: Active Directory の委任設定を調査する

Active Directory (AD) 環境のセキュリティ評価やペネトレーションテストにおいて、不適切な権限設定を発見することは非常に重要です。特に、「委任 (Delegation)」の設定は、攻撃者によって権限昇格やラテラルムーブメント（横展開）の足がかりとして悪用される可能性があります。

このブログ記事では、Impacket スイートに含まれる強力なツールの一つ、impacket-findDelegation (または単に `findDelegation.py`) に焦点を当て、その使い方と Active Directory 環境における委任設定の検出方法について詳しく解説します。このツールを使いこなすことで、AD 環境に潜むセキュリティリスクを効果的に特定し、対策を講じることが可能になります。🔍

まずは、委任とは何か、そしてなぜそれが重要なのかを見ていきましょう。

Active Directory における委任とは、あるアカウント（ユーザーまたはコンピュータ）が、別のサービスに対して、認証されたユーザーの代わりに（成り代わって）アクセスすることを許可する仕組みです。これにより、多層的なアプリケーション構造（例: フロントエンドの Web サーバーがバックエンドのデータベースサーバーにユーザーとしてアクセスする）を実現できます。しかし、この便利な機能は、設定を誤ると深刻なセキュリティリスクとなり得ます。

主に以下の3種類の委任が存在します:

1. 制約なし委任 (Unconstrained Delegation)

   これは最も古く、最も危険な形態の委任です。この設定が有効になっているアカウント（通常はコンピュータアカウントやサービスアカウント）は、自身に認証してきた任意のユーザーに成り代わり、ドメイン内のあらゆる Kerberos サービスにアクセスできてしまいます。攻撃者が制約なし委任が設定されたアカウントを侵害した場合、そのサーバーに認証しに来たドメイン管理者などの高い権限を持つユーザーの TGT (Ticket Granting Ticket) をメモリから窃取し、ドメイン全体を掌握する可能性があります。😱

2. 制約付き委任 (Constrained Delegation – KCD)

   制約なし委任のリスクを軽減するために導入されました。この設定では、委任を許可するアカウントが、指定された特定のサービスに対してのみユーザーに成り代わることを許可します。これにより、成り代わりの範囲を限定できます。

   KCD にはさらに2つのバリエーションがあります:

   • Kerberos Only: ユーザーが Kerberos を使用して最初のサービスに認証した場合にのみ、後続のサービスへの委任が可能です。
   • Protocol Transition (プロトコル移行): ユーザーが Kerberos 以外の認証方法（例: NTLM、フォームベース認証）で最初のサービスに認証した場合でも、最初のサービスが Kerberos を使用して後続の指定されたサービスへユーザーとして委任できます。これは柔軟性が高い反面、悪用されると攻撃者が任意のユーザー（管理者含む）に成り代わって特定のサービスを不正利用できる可能性があります。

   制約付き委任の設定は、委任を行う側（例: フロントエンドサーバー）のアカウントオブジェクト (`msDS-AllowedToDelegateTo` 属性）に格納されます。

3. リソースベース制約付き委任 (Resource-Based Constrained Delegation – RBCD)

   Windows Server 2012 で導入された比較的新しい委任の形態です。従来の KCD とは異なり、委任の許可設定は、委任される側（例: バックエンドのデータベースサーバー）のリソース自身が保持します。具体的には、リソース（コンピュータアカウントなど）の `msDS-AllowedToActOnBehalfOfOtherIdentity` 属性に、どのプリンシパル（ユーザーまたはコンピュータ）が自分自身に対して他のユーザーに成り代わることを許可するかを指定します。

   RBCD の利点は、リソースの管理者が委任の制御権を持つ点です。これにより、ドメイン管理者の介入なしに委任設定が可能になります。しかし、攻撃者がコンピュータアカウントを作成する権限（デフォルトでドメインユーザーに許可されていることが多い）や、既存のコンピュータアカウントを侵害した場合、そのアカウントを信頼させて RBCD を悪用し、特定のサーバー（ドメインコントローラーなど）へのアクセス権を得る攻撃経路が存在します。🛡️

🚨 なぜ委任設定の発見が重要なのか？
これらの委任設定、特に「制約なし委任」や「プロトコル移行を伴う制約付き委任」、「不適切に設定された RBCD」は、攻撃者にとって格好の標的となります。侵害されたアカウントが悪用され、ドメイン管理者権限の奪取や機密データへのアクセスにつながる可能性があるため、これらの設定を定期的に監査し、最小権限の原則に従って適切に管理することが極めて重要です。

ただし、注意点として、「Account is sensitive and cannot be delegated」属性が有効になっているユーザーや、「Protected Users」グループのメンバーは、これらの委任メカニズムによる成り済ましの対象から除外されます。

Impacket は、ネットワークプロトコルを扱うための Python クラスのコレクションです。特に、SMB や MSRPC といった Windows 環境でよく使われるプロトコルに焦点を当てており、低レベルでのパケット操作やプロトコル実装へのアクセスを提供します。

Impacket は単なるライブラリではなく、その機能を活用した多くの便利なスクリプト（ツール）群を含んでいます。これらは主に examples ディレクトリに格納されており、ペネトレーションテストやセキュリティ評価、システム管理タスクなど、様々な場面で役立ちます。

主なスクリプトの例:

• psexec.py: リモートでコマンドを実行 (PsExec の代替)
• secretsdump.py: SAM/LSA シークレット、NTLM ハッシュ、Kerberos キーなどをダンプ
• smbclient.py: SMB/CIFS 共有へのアクセス
• GetUserSPNs.py: Kerberoasting 攻撃のための SPN を持つユーザーを検索
• GetNPUsers.py: AS-REP Roasting 攻撃のための事前認証不要ユーザーを検索
• ntlmrelayx.py: NTLM リレー攻撃を実行
• そして、今回解説する findDelegation.py: AD 内の委任設定を列挙

これらのツールは連携して使用されることも多く、Active Directory 環境のセキュリティ状態を深く理解するための強力な武器となります。🔧

impacket-findDelegation を使用するには、まず Impacket スイート全体をインストールする必要があります。Python と pip (Python のパッケージインストーラ) がシステムにインストールされていることが前提です。

最も一般的なインストール方法は pip を使うことです:

pip install impacket
# または pip3 install impacket
    

あるいは、GitHub リポジトリから直接クローンしてインストールすることも可能です:

git clone https://github.com/fortra/impacket.git
cd impacket/
pip install .
# または python setup.py install
    

Kali Linux などのペネトレーションテスト用ディストリビューションには、Impacket がプリインストールされているか、パッケージマネージャー (apt) を通じて簡単にインストールできる場合があります。

sudo apt update
sudo apt install python3-impacket impacket-scripts
    

インストール後、impacket-findDelegation または findDelegation.py コマンドが利用可能になります。（パスが通っていない場合は、Impacket をインストールしたディレクトリ内の examples ディレクトリに移動して python findDelegation.py のように実行する必要があります。）

実行には、ターゲットの Active Directory ドメインに関する情報を照会できる有効なドメイン認証情報（ユーザー名とパスワード、またはハッシュ、Kerberos チケットなど）が必要です。

impacket-findDelegation の基本的なコマンド構文は以下の通りです:

impacket-findDelegation [-h] [-target-domain TARGET_DOMAIN] [-ts] [-debug]
                         [-hashes LMHASH:NTHASH] [-no-pass] [-k] [-aesKey hex key]
                         [-dc-ip ip address] [-dc-host hostname]
                         target
    

必須パラメータ:

• target: ターゲットドメインと認証情報を指定します。形式は <ドメイン>/<ユーザー名>[:<パスワード>] です。パスワードを省略すると、プロンプトで尋ねられます。

重要なオプション:

• -dc-ip <IPアドレス>: 接続先のドメインコントローラー (DC) の IP アドレスを指定します。指定しない場合、target で指定されたドメイン名 (FQDN) から解決しようとします。
• -dc-host <ホスト名>: 接続先の DC のホスト名を指定します。

基本的な実行例:

ユーザー名 svc_user とパスワード Password123 を使用して、corp.local ドメインの DC (192.168.1.100) に対して委任設定を検索します。

impacket-findDelegation -dc-ip 192.168.1.100 corp.local/svc_user:Password123
    

パスワードをインタラクティブに入力する場合:

impacket-findDelegation -dc-ip 192.168.1.100 corp.local/svc_user
Password:
    

この基本コマンドを実行すると、LDAP クエリを通じてドメイン内のユーザーアカウントとコンピュータアカウントを検索し、委任に関連する属性 (`userAccountControl`, `msDS-AllowedToDelegateTo`, `msDS-AllowedToActOnBehalfOfOtherIdentity`) をチェックして、設定されている委任の種類と対象を表示します。

impacket-findDelegation は、検索対象や認証方法を細かく制御するための様々なオプションを提供しています。

検索対象フィルタリングオプション:

認証オプション:

接続・その他オプション:

これらのオプションを組み合わせることで、特定のタイプの委任設定を持つアカウントを効率的に探し出すことができます。

組み合わせ例:

制約なし委任が設定されているコンピュータアカウントのみを Kerberos チケットを使って検索:

export KRB5CCNAME=/tmp/user.ccache
impacket-findDelegation -k -no-pass -dc-ip 192.168.1.100 -unconstrained corp.local/someuser
    

NTLM ハッシュを使用して、RBCD が設定されているアカウントを検索:

impacket-findDelegation -hashes :NTHASH_HERE -dc-ip 192.168.1.100 -rbcd corp.local/someuser
    

impacket-findDelegation を実行すると、検出された委任設定が表形式で表示されます。各列の意味を理解することが重要です。

Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies

AccountName      AccountType          DelegationType                  DelegationRightsTo                         SPN Exists
-----------      -----------          --------------------------      ------------------------------------------- -----------
WEBSRV01$        Computer             Unconstrained                   N/A                                        True
APPSRV02$        Computer             Constrained (Kerberos Only)     cifs/FILESRV01.corp.local                  True
DBSERV03$        Computer             Constrained (Protocol Trans.)   http/WEBSRV01.corp.local                   True
BACKUPSVC        User                 Unconstrained                   N/A                                        False
DC01$            Computer             Resource Based Constrained      Allowing: CORP\TESTPC$                     True
FILESRV01$       Computer             Resource Based Constrained      Allowing: CORP\APPSRV02$                   True
(*) Found 6 accounts with delegation rights.
    

列の説明:

• AccountName: 委任設定がされているアカウントの SAM アカウント名（ユーザーまたはコンピュータ）。コンピュータアカウントは通常 `$` で終わります。
• AccountType: アカウントの種類 (`User` または `Computer`)。
• DelegationType: 検出された委任の種類:
  • Unconstrained: 制約なし委任。
  • Constrained (Kerberos Only): 制約付き委任（Kerberos のみ）。
  • Constrained (Protocol Trans.): 制約付き委任（プロトコル移行あり）。
  • Resource Based Constrained: リソースベース制約付き委任。
• DelegationRightsTo:
  • 制約付き委任の場合: 委任が許可されているサービスプリンシパル名 (SPN) のリスト。
  • リソースベース制約付き委任の場合: このアカウントへの委任を許可されているプリンシパル（`Allowing: DOMAIN\AccountName` の形式）。
  • 制約なし委任の場合: N/A。
• SPN Exists: そのアカウントにサービスプリンシパル名 (SPN) が設定されているかどうか (`True` または `False`)。Kerberos 委任が正しく機能するためには、通常 SPN が必要です。特にサービスアカウントとして使用されるユーザーアカウントで SPN がない場合（例の BACKUPSVC）、意図した通りに機能していない可能性があります。

リスクの評価:

• Unconstrained: 最も危険度が高いです。侵害されると、そのサーバーに認証する高権限ユーザー（ドメイン管理者など）になりすまされる可能性があります。特にドメインコントローラーでこの設定が有効になっている場合は極めて危険です。ユーザーアカウントに設定されている場合も同様に危険です。
• Constrained (Protocol Trans.): 危険度が高いです。攻撃者がこのアカウントを侵害し、プロトコル移行を悪用できれば、任意のユーザー（管理者含む）として、指定されたサービスにアクセスできる可能性があります。委任先サービスが機密性の高いもの（例: ドメインコントローラーの CIFS や LDAP）の場合、リスクはさらに増大します。
• Constrained (Kerberos Only): プロトコル移行ありよりは安全ですが、それでも侵害された場合、Kerberos で認証してきたユーザーとして指定サービスにアクセスされる可能性があります。委任先サービスによってはリスクとなります。
• Resource Based Constrained: 設定自体は比較的新しく安全なメカニズムですが、設定ミスや悪用シナリオ（例: 攻撃者が作成したコンピュータアカウントに DC への委任権限を与える）により、権限昇格に繋がる可能性があります。誰が誰への委任を許可しているかを注意深く確認する必要があります。

出力結果を確認し、特に危険度の高い委任設定が見つかった場合は、その設定が本当に必要か、設定されているアカウントのセキュリティは十分かなどを詳細に調査する必要があります。🧐

impacket-findDelegation は、様々なセキュリティ関連の活動において非常に役立ちます。

ペネトレーションテスト / レッドチーム演習

攻撃者の視点から Active Directory 環境の弱点を探す際、委任設定は最も注目すべきポイントの一つです。

1. 初期アクセス後の権限昇格: 低権限ユーザーアカウントを侵害した後、impacket-findDelegation を実行して、侵害したユーザーが読み取れる範囲で委任設定を探します。もし制約なし委任を持つサーバーが見つかれば、そのサーバーへのアクセス権を取得し、ドメイン管理者がログインしてくるのを待つか、強制認証（例: Printer Bug, PetitPotam）を利用して管理者の TGT を窃取し、ドメイン管理者権限を得ることを試みます。
2. ラテラルムーブメント: 制約付き委任（特にプロトコル移行あり）を持つアカウントを侵害した場合、委任先のサービス (DelegationRightsTo) を確認します。もしそのサービスが他のサーバー（ファイルサーバー、データベースサーバーなど）で動作しており、侵害したアカウントがそのサーバー上の管理者や機密データにアクセスできるユーザーに成り代われるなら、それを足掛かりに横展開（ラテラルムーブメント）を行います。Impacket の getST.py を使って成り代わり用のサービスチケットを取得し、psexec.py や smbclient.py などで利用します。
3. RBCD 攻撃パスの探索: ドメインユーザーがデフォルトでコンピュータアカウントを作成できる（ms-DS-MachineAccountQuota が 0 より大きい）環境では、RBCD を悪用した権限昇格が可能です。攻撃者はまず、自身の制御下にあるコンピュータアカウントを作成（または既存の侵害済みコンピュータアカウントを使用）し、次に書き込み権限を持つ別のコンピュータアカウント（理想的にはドメインコントローラー）の `msDS-AllowedToActOnBehalfOfOtherIdentity` 属性を編集して、自身のアカウントに委任権限を与えます。その後、getST.py でドメイン管理者などの高権限ユーザーとしてターゲットコンピュータへのサービスチケットを取得し、アクセスします。impacket-findDelegation -rbcd は、既存の RBCD 設定を発見するのに役立ちます。

セキュリティ監査 / フォレンジック調査

防御側の視点からも、このツールは価値があります。

• 定期的な設定監査: 定期的に impacket-findDelegation を（十分な権限を持つアカウントで）実行し、意図しない、または過剰な委任設定が存在しないかを確認します。特に、制約なし委任は原則として避けるべきであり、見つかった場合は正当な理由があるか、他の方法で代替できないかを検討します。
• インシデント対応: セキュリティインシデント発生時、攻撃者がどのように権限昇格や横展開を行ったかを調査する一環として、関連するアカウントの委任設定を確認します。不審な RBCD 設定などが攻撃の痕跡である可能性があります。
• 構成ミスの発見: 設定ミスにより不要な委任が有効になっているケースを発見し、修正することで攻撃対象領域 (Attack Surface) を削減します。

これらのシナリオで impacket-findDelegation を活用することで、Active Directory 環境のセキュリティ体制を強化し、潜在的な脅威を未然に防ぐ、あるいは迅速に対応することが可能になります。🛡️

impacket-findDelegation は強力なツールですが、使用にあたっては以下の点に注意し、ベストプラクティスに従うことが重要です。

• 必要な権限:

  このツールは、Active Directory に対して LDAP クエリを実行し、ユーザーオブジェクトやコンピュータオブジェクトの属性（`userAccountControl`, `msDS-AllowedToDelegateTo`, `msDS-AllowedToActOnBehalfOfOtherIdentity` など）を読み取る必要があります。そのため、実行には少なくともドメイン内の認証済みユーザー（Authenticated Users）権限が必要です。ドメイン全体の包括的な情報を得るためには、より高い権限（例: Domain Admins または委任された読み取り権限を持つアカウント）が必要になる場合があります。

• 環境への影響:

  通常、impacket-findDelegation の実行自体は読み取り操作が中心であり、Active Directory 環境に直接的な変更を加えるものではありません。しかし、多数のオブジェクトを照会するため、大規模な環境ではドメインコントローラーに一時的な負荷がかかる可能性があります。実行する時間帯や頻度には配慮が必要です。

• 誤検知の可能性:

  ツールは属性値に基づいて委任設定を報告しますが、その設定が実際に悪用可能か、あるいは意図された正当な設定であるかまでは判断しません。検出された結果については、必ずその背景や文脈を確認し、リスクを評価する必要があります。

• 検出後の対策:

  危険な委任設定（特に制約なし委任）が発見された場合、以下の対策を検討します。

  • 設定の無効化または変更: 可能であれば、制約なし委任を無効にするか、より安全な制約付き委任（Kerberos Only または RBCD）に変更します。
  • 最小権限の原則の適用: 委任が必要な場合でも、委任先サービスを必要最小限に限定します。プロトコル移行が必要ない場合は無効にします。
  • アカウント保護の強化: 委任が設定されているアカウント（特にコンピュータアカウントやサービスアカウント）のパスワード強度を高め、定期的な変更を実施し、アクセス権限を最小限にします。
  • 「Protected Users」グループの活用: ドメイン管理者などの特権アカウントを「Protected Users」グループに追加することで、委任による成り済ましを含む多くの攻撃から保護できます。
  • 高価値アカウントの委任禁止: 特権アカウントに対して「Account is sensitive and cannot be delegated」フラグを設定します。
• 定期的な監査:

  Active Directory の設定は時間とともに変化する可能性があるため、impacket-findDelegation などのツールを用いた委任設定の監査を定期的に実施し、セキュリティ体制を維持することが重要です。

• 他のツールとの連携:

  BloodHound などの Active Directory 可視化・分析ツールと組み合わせることで、委任設定がどのように権限昇格パスに繋がるかをより具体的に把握できます。

これらの点を考慮し、責任を持ってツールを使用することで、Active Directory のセキュリティ強化に大きく貢献できます。✅

impacket-findDelegation は、Active Directory 環境における潜在的なセキュリティリスクである「委任設定」を効率的に発見するための非常に強力なツールです。制約なし委任、制約付き委任、リソースベース制約付き委任といった様々なタイプの委任を検出し、その詳細情報を表示することができます。

このツールを活用することで、ペネトレーションテスターやレッドチームは攻撃経路を発見し、セキュリティ管理者は設定ミスや過剰な権限を発見して修正することが可能になります。特に、制約なし委任やプロトコル移行を伴う制約付き委任は、攻撃者によって悪用されやすく、ドメイン全体の侵害につながる可能性もあるため、重点的にチェックすべき項目です。

しかし、ツールの出力結果を鵜呑みにせず、検出された委任設定が持つ実際の意味やリスクを評価し、最小権限の原則に基づいた適切な対策を講じることが不可欠です。定期的な監査と適切な設定管理を通じて、Active Directory 環境をより安全に保つ努力を継続しましょう。 💪

このブログ記事が、impacket-findDelegation の理解と活用の一助となれば幸いです。😊