次の方法で共有

ゴールデン gMSA 攻撃から回復する方法

  • [アーティクル]

この記事では、ドメイン コントローラー データベース露出インシデントの影響を受けるグループ管理サービス アカウント (gMSA) の資格情報を修復する方法について説明します。

現象

ゴールデン gMSA 攻撃の詳細については、次の Semperis の記事を参照してください。

ゴールデンGMSA攻撃の紹介

上記の記事の説明は正確です。 問題を解決するためのアプローチは、Microsoft キー配布サービス (kdssvc.dll、KDS とも呼ばれます) ルート キー オブジェクトと、侵害された KDS ルート キー オブジェクトを使用するすべての gMSA を置き換えます。

詳細

gMSA に対する攻撃が成功すると、攻撃者は KDS ルート キー オブジェクトのすべての重要な属性と、gMSA オブジェクトの Sid 属性と msds-ManagedPasswordID 属性を取得します。

msds-ManagedPasswordID属性は、ドメインの書き込み可能なコピーにのみ存在します。 そのため、ドメイン コントローラーのデータベースが公開されている場合、ドメイン コントローラーがホストするドメインのみがゴールデン gMSA 攻撃に対して開かれています。 ただし、攻撃者がフォレスト内の別のドメインのドメイン コントローラーに対して認証できる場合、攻撃者は msds-ManagedPasswordIDのコンテンツを取得するための十分なアクセス許可を持っている可能性があります。 攻撃者はこの情報を使用して、追加のドメイン内の gMSA に対する攻撃を作成する可能性があります。

1 つのドメインが公開された後にフォレストの追加ドメインを保護するには、攻撃者が情報を使用する前に、公開されているドメイン内のすべての gMSA を置き換える必要があります。 通常、公開された内容の詳細はわかりません。 そのため、フォレストのすべてのドメインに解決を適用することをお勧めします。

事前対策として、監査を使用して KDS ルート キー オブジェクトの露出を追跡できます。 読み取りが成功したシステム アクセス制御リスト (SACL) は、マスター ルート キー コンテナーに配置できます。これにより、msKds-ProvRootKey クラスのmsKds-RootKeyData属性に対する正常な読み取りの監査が可能になります。 このアクションにより、ゴールデン gMSA 攻撃に関するオブジェクトの露出状況が決定されます。

Note

監査は、KDS ルート キー データに対するオンライン攻撃の検出にのみ役立ちます。

ManagedPasswordIntervalInDaysの値は gMSA の作成後に読み取り専用になるため、ManagedPasswordIntervalInDays パラメーターを 15 日に設定するか、gMSA の作成時に適切な値を選択することを検討できます。

侵害が発生した場合、この設定によって次のローリング時間が短縮される可能性があります。

Scenario 1を使用すると、復元されたバックアップの日付からデータベース公開の終了までの間、または少なくともこれらの gMSA がロールするまでのリスク ウィンドウ期間の間に再作成される gMSA の理論上の数が減ります。

シナリオ例を次に示します。

  1. データベースの公開後、"Day D" で復旧を実行します。

  2. 復元されたバックアップは D-15 からのバックアップです。

    Note

    D-15 は、"D 日" の 15 日前の日を意味します。

  3. gMSA ManagedPasswordIntervalInDays 値は 15 です。

  4. gMSA が存在し、D-1 がロールされています。

  5. D-10 から新しい gMSA が作成されました。

  6. 侵害は D-5 で発生し、一部の gMSA はこの日付に作成されています。

結果は次のようになります。

  1. D と D-5 の間で作成された gMSA は関係ありません*。

  2. D-15 (バックアップ復元) と D-5 (侵害) の間に作成された gMSA * を再作成する必要があります。または、D+5 から D+10 まで待機できる場合は、リスク ウィンドウを想定する必要があります。 例えば次が挙げられます。

    • D+5 では、D-10 で作成された gMSA を再作成する必要があります。
    • D+10 では、D-5 で作成された gMSA を再作成する必要があります。

    *侵害またはバックアップの正確な時刻によって異なります。

タイムラインの例を次に示します。

gMSA タイムラインの例の図。

デバッグでは、システム、セキュリティ、ディレクトリ サービス、Security-Netlogon イベント ログのイベント ID を確認できます。

侵害の詳細については、「 Microsoft と Azure のセキュリティ リソースを使用して、全身的な ID 侵害からの復旧に役立つを参照してください。

解決方法

この問題を解決するには、状況に応じて、次のいずれかの方法を使用します。 このアプローチでは、新しい KDS ルート キー オブジェクトを作成し、ドメインのすべてのドメイン コントローラーで Microsoft Key Distribution Service を再起動します。

シナリオ 1: どのような情報が公開され、いつ公開されたかに関する信頼性の高い情報がある

公開が特定の日付より前に発生し、この日付が最も古い gMSA パスワードよりも前であることがわかっている場合は、次の手順に示すように、gMSA を再作成せずに問題を解決できます。

この方法では、攻撃者に知られていない新しい KDS ルート キー オブジェクトを作成します。 gMSA がパスワードをロールすると、新しい KDS ルート キー オブジェクトの使用に移行します。 古い KDS ルート キーを使用して最近パスワードをロールした gMSA を修正するには、復元の直後にパスワードの更新を強制する権限のある復元が必要です。

Note

  • Active Directory ドメイン サービス (AD DS) データベースの公開が終了した後に作成された gMSA を手動で修復する必要はありません。 攻撃者はこれらのアカウントの詳細を認識せず、これらのアカウントのパスワードは新しい KDS ルート キー オブジェクトに基づいて再生成されます。
  • 手順が完了するまで gMSA オブジェクトを "メンテナンス モード" と見なし、システム、セキュリティ、ディレクトリ サービス、および Security-Netlogon イベント ログのアカウントで報告される可能性のあるエラーを無視する必要があります。
  • このガイドでは、gMSA が Managed Service Accounts コンテナーの子オブジェクトであることを前提としています。 アカウントをカスタム親コンテナーに移動した場合は、これらのコンテナー内の gMSA の Managed Service Accounts コンテナーに関連する手順を実行する必要があります。
  • 権限のある復元では、gMSA 資格情報の取得が許可されているアカウント (PrincipalsAllowedToRetrieveManagedPassword) を含め、すべての属性がバックアップ時の状態にロールバックされます。

修復する gMSA を保持しているドメインで、次の手順に従います。

  1. ドメイン コントローラーをオフラインにして、ネットワークから分離します。

  2. AD DS データベースの公開前に作成されたバックアップからドメイン コントローラーを復元します。

    gMSA のパスワード間隔がバックアップの有効期間より長い場合は、前のキー マテリアルがまだ機能するウィンドウを許容することを決定できます。 その時間待てず、一致する古いバックアップに不足している gMSA が多すぎる場合は、プランを Scenario 2 に切り替える必要があります。

  3. ドメインの 管理されたサービス アカウント コンテナーに対して権限のある復元操作を実行します。 復元操作に、このドメイン コントローラーに関連付けられている可能性があるすべてのコンテナーの子オブジェクトが含まれていることを確認します。 この手順では、最後のパスワード更新の状態がロールバックされます。 サービスが次にパスワードを取得すると、新しい KDS ルート キー オブジェクトに基づいてパスワードが新しいパスワードに更新されます。

  4. 復元されたドメイン コントローラーで Microsoft キー配布サービスを停止して無効にします。

  5. 別のドメイン コントローラーで、「 キー配布サービス KDS ルート キーを作成する 新しい KDS ルート キー オブジェクトを作成する」の手順に従います。

    Note

    運用環境では、新しい KDS ルート キーを使用できるようにするには、10 時間待つ必要があります。 EffectiveTime属性を調べて、新しい KDS ルート キーが使用可能になるタイミングを確認します。

  6. すべてのドメイン コントローラーで Microsoft キー配布サービスを再起動します。

  7. 新しい gMSA を作成します。 新しい gMSA が新しい KDS ルート キー オブジェクトを使用して、 msds-ManagedPasswordID 属性の値を作成することを確認します。

    Note

    この手順は省略可能ですが、新しい KDS ルート キーが現在使用中であり、Microsoft キー配布サービスで使用されていることを検証できます。

  8. 作成した最初の gMSA の msds-ManagedPasswordID 値を確認します。 この属性の値は、一致する KDS ルート キー オブジェクトの GUID を含むバイナリ データです。

    たとえば、KDS ルート キー オブジェクトに次の CNがあるとします。

    KDS ルート キー オブジェクトの CN 属性の値を示すスクリーンショット。

    このオブジェクトを使用して作成された gMSA には、次のような msds-ManagedPasswordID 値があります。

    gMSA オブジェクトの msDS-ManagedPasswordId 属性の値のスクリーンショット。KDS ルート キー CN 属性の部分がどのように含まれているかを示しています。

    この値では、GUID データはオフセット 24 から始まります。 GUID の各部分は、異なる順序で行われます。 この画像では、赤、緑、青のセクションで、並べ替え済みの部分が識別されます。 オレンジ色のセクションは、元の GUID と同じシーケンスの部分を識別します。

    作成した最初の gMSA で新しい KDS ルート キーが使用されている場合、後続のすべての gMSA でも新しいキーが使用されます。

  9. すべてのドメイン コントローラーで Microsoft キー配布サービスを無効にして停止します。

  10. 再接続し、復元されたドメイン コントローラーをオンラインに戻します。 レプリケーションが機能していることを確認します。

    これで、権限のある復元とその他のすべての変更 (復元された gMSA を含む) がレプリケートされます。

  11. すべてのドメイン コントローラーで Microsoft キー配布サービスを再度有効にして起動します。 復元された gMSA のシークレットがロールされ、要求に応じて新しい KDS ルート キー オブジェクトに基づいて新しいパスワードが作成されます。

    Note

    gMSA が復元されても使用されておらず、 PrincipalsAllowedToRetrieveManagedPassword パラメーターが設定されている場合は、復元された gMSA で、パスワードの取得を許可されているプリンシパルを使用して、 Test-ADServiceAccount コマンドレットを実行できます。 パスワードの変更が必要な場合、このコマンドレットは gMSA を新しい KDS ルート キーにロールします。

  12. すべての gMSA がロールされていることを確認します。

    Note

    PrincipalsAllowedToRetrieveManagedPassword パラメーターが設定されていない gMSA はロールしません。

  13. 古い KDS ルート キー オブジェクトを削除し、レプリケーションを確認します。

  14. すべてのドメイン コントローラーで Microsoft キー配布サービスを再起動します。

シナリオ 2: KDS ルート キー オブジェクトの公開の詳細が不明で、パスワードがロールするのを待つことはありません

どのような情報が公開されたか、いつ公開されたかがわからない場合は、Active Directory フォレストの完全な公開の一部である可能性があります。 これにより、攻撃者がすべてのパスワードに対してオフライン攻撃を実行する可能性があります。 この場合は、フォレストの回復を実行するか、すべてのアカウント パスワードをリセットすることを検討してください。 gMSA をクリーンな状態に回復することは、このアクティビティの一部です。

次のプロセスでは、新しい KDS ルート キー オブジェクトを作成する必要があります。 次に、このオブジェクトを使用して、公開されている KDS ルート キー オブジェクトを使用するフォレストのドメイン内のすべての gMSA を置き換えます。

Note

次の手順は、「グループ管理サービス アカウントの概要の手順に似ています。 ただし、いくつかの重要な変更があります。

次のステップを実行します。

  1. 既存のすべての gMSA を無効にし、削除するアカウントとしてマークします。 これを行うには、アカウントごとに、 userAccountControl 属性を 4098 に設定します (この値は WORKSTATION_TRUST_ACCOUNT フラグと ACCOUNTDISABLE (disabled) フラグを組み合わせた値です)。

    次のような PowerShell スクリプトを使用して、アカウントを設定できます。

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. 1 つのドメイン コントローラーを使用し、次の手順に従います。

    1. 新しい KDS ルート キー オブジェクトを作成するには、「 KDS ルート キー キー配布サービスを作成する」の手順に従います。

    2. Microsoft キー配布サービスを再起動します。 再起動後、サービスは新しいオブジェクトを取得します。

    3. 削除対象としてマークされた各 gMSA に関連付けられている DNS ホスト名とサービス プリンシパル名 (SPN) をバックアップします。

    4. 既存の gMSA を編集して、SPN と DNS ホスト名を削除します。

    5. 既存の gMSA を置き換える新しい gMSA を作成します。 また、削除した DNS ホスト名と SPN を使用して構成する必要もあります。

      Note

      また、直接削除された gMSA SID は解決できないため、すべてのアクセス許可エントリを確認する必要があります。 アクセス制御エントリ (ACE) を置き換える場合は、グループを使用して gMSA アクセス許可エントリを管理することを検討してください。

  3. 新しい gMSA を調べて、新しい KDS ルート キー オブジェクトが使用されていることを確認します。 これを行うには、次の手順を実行します。

    1. KDS ルート キー オブジェクトの CN (GUID) 値に注意してください。

    2. 作成した最初の gMSA の msds-ManagedPasswordID 値を確認します。 この属性の値は、一致する KDS ルート キー オブジェクトの GUID を含むバイナリ データです。

      たとえば、KDS ルート キー オブジェクトに次の CNがあるとします。

      KDS ルート キー オブジェクトの CN 属性の値のスクリーンショット。

      このオブジェクトを使用して作成された gMSA には、イメージに似た msds-ManagedPasswordID 値があります。

      gMSA オブジェクトの msDS-ManagedPasswordId 属性の値のスクリーンショット。KDS ルート キー CN 属性の部分がどのように含まれているかを示しています。

      この値では、GUID データはオフセット 24 から始まります。 GUID の各部分は、異なる順序で行われます。 この画像では、赤、緑、青のセクションで、並べ替え済みの部分が識別されます。 オレンジ色のセクションは、元の GUID と同じシーケンスの部分を識別します。

      作成した最初の gMSA で新しい KDS ルート キーが使用されている場合、後続のすべての gMSA でも新しいキーが使用されます。

  4. 新しい gMSA を使用するように適切なサービスを更新します。

  5. 次のコマンドレットを使用して、古い KDS ルート キー オブジェクトを使用した古い gMSA を削除します。

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. 古い KDS ルート キー オブジェクトを削除し、レプリケーションを確認します。

  7. すべてのドメイン コントローラーで Microsoft キー配布サービスを再起動します。

シナリオ 3: ドメイン管理者の辞任、その時点で情報が盗まれなかった、パスワードがロールするのを待つことができます

ドメイン管理者または同等の権限を持つ高い特権を持つメンバーが辞任した場合、その時点で KDS ルート キーの公開の証明はなく、パスワードのローリングの時間枠を確保できます。 gMSA を再作成する必要はありません。

予防措置として、KDS ルート キーをロールして、悪用後の攻撃を防ぐ必要があります。 たとえば、元ドメイン管理者が不正であることが判明し、一部のバックアップを保持しています。

新しい KDS ルート キー オブジェクトが作成され、gMSA が自然にロールします。

Note

ドメイン管理者に関連する侵害については、公開されている内容に従って Scenario 1 または Scenario 2 を参照し、「Microsoft と Azure のセキュリティ リソースを使用して全身的な ID 侵害から回復する」の オンプレミスの修復 アクティビティに従ってください。

ロールする gMSA を保持しているドメインで、次の手順に従います。

  1. ドメイン コントローラーで、「 キー配布サービス KDS ルート キーを作成する 新しい KDS ルート キー オブジェクトを作成する」の手順に従います。

    Note

    運用環境では、新しい KDS ルート キーを使用できるようにするには、10 時間待つ必要があります。 EffectiveTime属性を調べて、新しい KDS ルート キーが使用可能になるタイミングを確認します。

  2. すべてのドメイン コントローラーで Microsoft キー配布サービスを再起動します。

  3. 新しい gMSA を作成します。 新しい gMSA が新しい KDS ルート キー オブジェクトを使用して、 msds-ManagedPasswordID 属性の値を作成することを確認します。

    Note

    この手順は省略可能ですが、新しい KDS ルート キーが現在使用中であり、Microsoft キー配布サービスで使用されていることを検証できます。

  4. 作成した最初の gMSA の msds-ManagedPasswordID 値を確認します。 この属性の値は、一致する KDS ルート キー オブジェクトの GUID を含むバイナリ データです。

    たとえば、KDS ルート キー オブジェクトに次の CNがあるとします。

    KDS ルート キー オブジェクトの CN 属性の値のスクリーンショット。

    このオブジェクトを使用して作成された gMSA には、次の図のような msds-ManagedPasswordID 値があります。

    gMSA オブジェクトの msDS-ManagedPasswordId 属性の値のスクリーンショット。KDS ルート キー CN 属性の部分がどのように含まれているかを示しています。

    この値では、GUID データはオフセット 24 から始まります。 GUID の各部分は、異なる順序で行われます。 この画像では、赤、緑、青のセクションで、並べ替え済みの部分が識別されます。 オレンジ色のセクションは、元の GUID と同じシーケンスの部分を識別します。

    作成した最初の gMSA で新しい KDS ルート キーが使用されている場合、後続のすべての gMSA でも新しいキーが使用されます。

  5. 次のパスワード ロールに応じて、gMSA のシークレットが自然にロールされ、要求に応じて新しい KDS ルート キー オブジェクトに基づいて新しいパスワードが作成されます。

    Note

    使用された gMSA がロールされていても、同じロール間隔の未使用の gMSA がない場合、 PrincipalsAllowedToRetrieveManagedPassword パラメーターが設定されている場合は、 Test-ADServiceAccount コマンドレットを実行できます。 gMSA パスワードの取得が許可されているプリンシパルを使用し、この手順では gMSA を新しい KDS ルート キーに移動します。

  6. すべての gMSA がロールされていることを確認します。

    Note

    PrincipalsAllowedToRetrieveManagedPassword パラメーターのない gMSA はロールしません。

  7. すべての gMSA が新しい KDS ルート キー オブジェクトにロールされたら、古い KDS ルート キー オブジェクトを削除し、レプリケーションを確認します。

  8. すべてのドメイン コントローラーで Microsoft キー配布サービスを再起動します。

関連情報

グループの管理されたサービス アカウントの概要

サードパーティのお問い合わせ窓口に関する免責事項

サードパーティのお問い合わせ窓口に関する情報は、ユーザーの便宜のために提供されているものであり、 この連絡先情報は、予告なしに変更される可能性があります。 マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。