BadSuccessor：dMSA を悪用して Active Directory の権限を昇格
エグゼクティブサマリー
Akamai の研究者 Yuval Gordon は、攻撃者が Active Directory（AD）の任意のユーザーを侵害できるようにしてしまう Windows Server 2025 の権限昇格の脆弱性を発見しました。
この攻撃は、Windows Server 2025 で導入された委任された管理サービスアカウント（dMSA）を悪用して実行されます。これは、デフォルトの設定で動作し、実装が簡単な機能です。
この問題は、AD に依存しているほとんどの組織に影響する可能性があります。調査した環境の 91% で、この攻撃を実行するために必要な権限を持つドメイン管理者グループ外のユーザーが見つかりました。
Microsoft は、この問題を今後修正する予定であるとしていますが、現在はパッチを入手できません。そのため、組織はこの攻撃につながる露出を軽減するために他の予防的な対策を講じる必要があります。Microsoft は調査結果を確認し、この情報の公開を承認しました。
このブログ記事では、攻撃の詳細および検知と緩和戦略について説明します。
目次
はじめに
Windows Server 2025 では、Microsoft は委任された管理サービスアカウント（dMSA）を導入しました。dMSA は、グループ管理サービスアカウント（gMSA）の機能を拡張する Active Directory（AD）の新しいタイプのサービスアカウントです。dMSA の主な特徴の 1 つは、管理対象外の既存のサービスアカウントを dMSA にシームレスに変換することで、それらのアカウントを移行できることです。
AD の dMSA の内部構造を調べていたところ、偶然、あるものを発見しました。一見しただけでは、移行メカニズムはクリーンで入念に設計されたソリューションのように見えました。しかし、その内部構造に気になる点があったのです。
さらに深く掘り下げたところ、驚くべきエスカレーションパスが見つかりました。dMSA を悪用することで、攻撃者はドメイン内の任意のプリンシパルを乗っ取ることができてしまいます。攻撃者がこの攻撃を実行するために必要とするのは、ドメイン内の任意の組織単位（OU）に対する良性な権限だけです。これは、しばしば見落とされがちな権限です。
そして、最も重要な点は、この攻撃はデフォルトの状態で実行できてしまうことです。ドメインでは dMSA を使用する必要はありません。Windows Server 2025 ドメインコントローラー（DC）が少なくとも 1 つ存在するドメインであれば、攻撃される可能性があるのです。
このブログ投稿では、この脆弱性をどのように発見したか、攻撃の手口、および攻撃を検知または阻止するために何ができるかについて説明します。
dMSA とは？
攻撃の前に、dMSA が実際に何であるのか、どのように機能するのかを理解することが重要です。
dMSA は通常、既存のレガシー・サービス・アカウントを置き換えるために作成されます。シームレスな移行を可能にするため、dMSA は移行プロセスを実行することでレガシーアカウントの権限を「継承」できます。この移行フローでは、dMSA を、置き換えられたアカウント（つまり、置き換えようとしている元のアカウント）に密接に結合します。このフローと、その過程で付与される権限が、より興味深いポイントとなります。
dMSA 移行フロー
dMSA の移行プロセスは、新しい Start-ADServiceAccountMigration cmdlet を呼び出すことでトリガーできます。内部では、migrateADServiceAccount という名前の新しい LDAP rootDSE 操作を呼び出します。この操作には、次の引数が使用されます。
dMSA の識別名（DN）
置き換えられたアカウントの DN
StartMigration に対応する定数
dMSA の移行ステータスは、msDS-DelegatedMSAState 属性によって決まります。これは dMSA の現在の状態を決定する新しい属性です。現在、msDS-DelegatedMSAState 属性に関する公式な文書がないため、次の表は独自のふるまい分析と実験に基づいています。
値 |
意味 |
0 |
不明（無効になっている可能性があるが未確認） |
1 |
移行中 |
2 |
移行完了 |
3 |
スタンドアロン dMSA（移行なし） |
msDS-DelegatedMSAState 移行値と関連する意味
この属性に加えて、移行プロセスではいくつかの重要な属性が使用されます。
dMSA オブジェクトの場合：
msDS-GroupMSAMembership：この dMSA の使用を許可されているプリンシパルのリストを含みます
msDS-ManagedAccountPrecededByLink：置き換えられたアカウントの DN
置き換えられたアカウントオブジェクトの場合：
msDS-SupersededManagedAccountLink：「後続」dMSA の DN
msDS-SupersededServiceAccountState：msDS-DelegatedMSAState と同じ意味をもち、元のアカウントの移行状態を指定します
移行をトリガーすると、操作によって次の変更が行われます。
msDS-DelegatedMSAState を 1（移行中）に設定します
dMSA の ntSecurityDescriptor を更新して、置き換えられたアカウントを付与します。
読み取り権限
msDS-GroupMSAMembership 属性への書き込みアクセス
dMSA の msDS-ManagedAccountPrecededByLink を、置き換えられたアカウントを参照するように設定します
置き換えられたアカウントの msDS-SupersededManagedAccountLink を、dMSA を参照するように設定します
置き換えられたアカウントの msDS-SupersededServiceAccountState を 1 に設定します
この時点で、dMSA は「移行中」状態になります。まだ完全には機能していませんが、現在はどのシステムが古いサービスアカウントを使用しているかを認識しています。
Complete-ADServiceAccountMigration コマンドを実行すると、以下のような処理が行われます。
dMSA は、SPN、委任設定、その他の機密属性などの主要な設定を、置き換えられたアカウントから継承します
置き換えられたアカウントは無効になります
msDS-DelegatedMSAState と msDS-SupersededServiceAccountState はどちらも 2（移行完了）に設定されます
移行は完了し、置き換えられたアカウントに依存していたサービスは dMSA を使用して認証するようになりました。
dMSA 認証
これで、dMSA の作成と移行プロセスが理解できましたね。ここでは、認証の仕組み、dMSA をサポートするために導入された変更、およびこれらの変更がシームレスな移行プロセスを実現する方法に注目します。
理解しやすくするために、SQL_SRV$ サーバーでサービスを実行するために使用される svc_sql legacy サービスアカウントについて確認します。ドメイン内のリソースにアクセスする必要がある場合、svc_sql アカウントを使用して通常の認証を行います（図 1）。
Fig. 1: Legacy service account authentication flow
移行中の認証
サービスアカウントを DMSA$ という新しい dMSA に移行し、移行をトリガーします。移行期間中に、SQL_SRV$ 上のサービスが svc_sql として認証されると、認証フローはわずかに変更されます。
クライアントは svc_sql として認証するために AS-REQ を送信します
キー配布センター（KDC）は、次の追加フィールドを含む AS-REP を返します。KERB-SUPERSEDED-BY-USER（このフィールドには、新しい dMSA DMSA$ の名前と領域が含まれます）
ホストが dMSA（Windows Server 2025 または Windows 11 24H2）をサポートし、dMSA 認証が有効になっている場合、次のようになります。
DMSA$ の名前を抽出します
DMSA$ で LDAP クエリーを実行して、次の属性を取得します。
msDS-GroupMSAMembership
distinguishedName
objectClass
サービスは SQL_SRV$ で svc_sql として実行されているため、認証自体は svc_sql から LDAP 変更リクエストをトリガーします。これにより、DMSA$ のパスワードの取得が許可されているプリンシパルのリストに SQL_SRV$ が追加されます（図 2）。
これは、移行プロセス中に、svc_sql が dMSA 上の msDS-GroupMSAMembership 属性への書き込みアクセス権が付与されたために可能です。これは、ホストマシンがアカウントの認証情報にアクセスできるようにするための変更です。
Fig. 2: Kerberos authentication flow during dMSA migration
このシームレスなアクセス許可を付与することで、以前に svc_sql を使用したすべてのマシンが DMSA$ の msDS-GroupMSAMembership 属性に一覧表示され、dMSA として認証できるようになります。
移行完了後の認証
移行が完了すると（Complete-ADServiceAccountMigration 経由で）、ふるまいが再度変更されます。
クライアントが AS-REQ を送信して svc_sql として認証しようとすると、AS-REP は受信されなくなります
代わりに、DC は KRB-ERROR を返し、svc_sql が無効であることを示します
KRB-ERROR には KERB-SUPERSEDED-BY-USER フィールドが含まれています。これにより、クライアントは svc_sql が移行されたことを認識し、DMSA$ を使用して自動的に認証を再試行できます（図 3）。
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$（および以前 svc_sql に依存していたその他のマシン）は現在、DMSA$ を使用するように透過的に切り替えられます。
UnexPACted（予期しない）ふるまい
dMSA Kerberos 認証の興味深い側面として、その特権属性証明（PAC）があります。
認証時に、Kerberos は PAC をチケットに埋め込みます。これは、サービスがクライアントのアクセスレベルを決定するために使用する構造です。標準のチケット認可チケット（TGT）では、PAC にはユーザーと、そのユーザーが所属するすべてのグループの SID が含まれます。
しかし、dMSA でログインする際、予期しない事象が確認されました。
PAC には、dMSA SID だけでなく、置き換えられたサービスアカウントの SID と、その関連するすべてのグループの SID も含まれていました。
dMSA 移行プロセスを悪用した権限の昇格
移行後、KDC は元の（置き換えられた）アカウントのすべての権限を dMSA に付与します。
デザインの観点から考えると、これは理にかなっています。目標は、新しいアカウントが、同じ SPN、同じ委任、同じグループメンバーシップなど、置き換えるアカウントと完全に同じ動作をするシームレスな移行体験を提供することです。
しかし、セキュリティ研究者の視点から見ると、このようなふるまいはすぐに目に付きます。あるシステムにおいて、手動による再設定を必要とせずに、アカウント間で自動的に権限をコピーすることが判明し、私たちはさらに調査を進めました。 コピー元のアカウントはどのようにして決定するのか？それによる影響は？悪用される可能性は？
これらの疑問は、私たちを重要な発見へと導きました。PAC 継承のこの興味深い動作は、単一の属性 msDS-ManagedAccountPrecededByLink によって制御されているようです。
KDC はこの属性に基づいて、dMSA が「置き換える」対象を決定します。dMSA が認証する際、PAC はこのリンクのみに基づいて構築されます。
攻撃者になったつもりで考えてみましょう
攻撃者の観点から見た場合、これはどのように見えるでしょうか。この機能を利用した攻撃の可能性を検討し、攻撃者がどの程度まで到達できるかを実際に検証してみましょう。
当社の最初のアイデア：dMSA を使用して、アカウント乗っ取りのプリミティブを作成します。ユーザーアカウントに対する権限を持っていると仮定した場合、その権限を何らかの方法で新しい dMSA に「移行」して、不正に侵害することは可能でしょうか？隙の無い計画のようです。私たちがすべきことは次のとおりです。
dMSA を作成します
migrateADServiceAccount rootDSE 操作を使用して、ターゲットユーザーと dMSA 間の移行を開始し、完了させます
dMSA として認証 - ターゲットユーザーのすべての権限を取得します
唯一の問題は、実行できないことです。
dMSA と置き換えられたアカウントの両方を完全に制御していても、migrateADServiceAccount 操作は、当社が知る限りドメイン管理者に制限されているため、移行を実行できません。図 4 に、失敗した試行例を示します。
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
2 つ目のアイデアは、複雑で、創造的で、高度な技術をもつ何かが必要であることは明らかです。文書化されていないふるまいを調べる必要があります。KDC の一部をリバースエンジニアすることもできます。または、2 つの属性を設定することもできます。
移行を直接実行することはできませんが、dMSA オブジェクトに次の属性を直接設定するだけで、非常に簡単に「シミュレート」できます。
ターゲットアカウントの DN を msDS-ManagedAccountPrecededByLink に書き込みます
msDS-DelegatedMSAState を値 2 に設定します（移行完了）
この時点から、dMSA として認証するたびに、KDC は msDS-ManagedAccountPrecededByLink 属性にリンクされたアカウントの SID を使用して PAC を構築し、事実上、置き換えられたアカウントのすべての権限を付与します。
BadSuccessor の解説
この「シミュレートされた移行」の技術における興味深い事実の 1 つは、置き換えられたアカウントに対する権限が不要であることです。唯一の要件は、dMSA の属性に対する書き込み権限です。どの dMSA でもよいのです。
ユーザーによって先行されたものとして dMSA をマークすると、KDC は自動的に正当な移行が行われたと見なし、元のユーザーが持っていたすべての権限を、あたかもその正当な後継者であるかのように、dMSA に自動的に付与します。
しかし、特権が与えられたアカウントでは、さすがに実行できないですよね。おそらく...
また、ドメイン管理者を含むこの「BadSuccessor」という手口は、全てのユーザーに対して機能します（図 5）。dMSA オブジェクトを制御するすべてのユーザーがドメイン全体を制御できます。それだけで十分です。実際の移行はありません。検証はありません。監視もありません。
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
dMSA の悪用：低い権限からドメインを支配するまで
この時点で、「私の環境では dMSA を使用していないし、私に影響はないだろう」と思われるかもしれません。もう一度考えてみてください。
ある悪用シナリオでは、攻撃者は既存の dMSA を制御し、このアクセスを使用して BadSuccessor 攻撃を実行します。しかし、実際には別のシナリオがあります。攻撃者が頻繁に実行する可能性のあるシナリオです。このシナリオでは、攻撃者は新しい dMSA を作成します。
ユーザーが AD でオブジェクトを作成すると、そのすべての属性に対する完全な権限が付与されます。そのため、攻撃者が新しい dMSA を作成すると、ドメイン全体が侵害される可能性があります。
通常、New-ADServiceAccount cmdlet を使用して dMSA を作成すると、管理サービスアカウントコンテナに格納されます。このコンテナへのアクセス権をユーザーに付与することは可能ですが、デフォルトでは、組み込みの特権 Active Directory グループのみがこのコンテナに対するアクセス権を持ちます。そのため、このコンテナに書き込むことができる可能性はほとんどありません。
ただし、管理サービスアカウントコンテナに制限されることはありません。通常の OU でも作成できます。任意の OU で、「msDS-DelegatedManagedServiceAccount の作成」または「すべての子オブジェクトの作成」のいずれかの権限を持つすべてのユーザーが dMSA を作成できます。
dMSA の作成
OU 内でのオブジェクトの作成をユーザーに許可することは、非常に一般的な構成です。この機能は良性とみなされるため、この権限を持つユーザーが適切に監視および強化される可能性は低くなります。
dMSA を作成するためには、まず権限を持つ OU を特定します。幸いにも、当社の例示環境では「temp」という OU が作成されており、権限のないユーザーにすべての子オブジェクトを作成する「弱い」権限を与えています（図 6）。
Fig. 6: Example of required privileges on an OU
その後、これらの権限を使用して、New-ADServiceAccount cmdlet を使用して dMSA を作成できます。図 7 に示すように、権限のないユーザーはデフォルトの MSA コンテナに dMSA を作成できませんが、パス引数を使用してアクセス可能な OU に dMSA を作成できます。
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
私たちは今、新しく作成された、機能しない dMSA のご機嫌な所有者になりました。作成者の所有者として、この攻撃に使用する両方の属性への書き込みアクセス権を含め、オブジェクトに対する権限を自分自身に付与することができます。これは、次の方法で変更できます。
msDS-ManagedAccountPrecededByLink：これを任意のユーザーまたはコンピューターの DN に設定します — ドメインコントローラー、ドメイン管理者のメンバー、保護されたユーザー、そして（皮肉にも）「アカウントは機密であり、委任できません」とマークされたアカウントを含みます
msDS-DelegatedMSAState：これを 2 に設定して、完了した移行をシミュレートします（図 8）
Fig. 8: Modifying attributes to mimic successful migration
前述したように、この攻撃は AD 内のすべてのアカウントで機能するようです。私たちは、アカウントが置き換えられたターゲットとして使用されることを防止する設定を見つけることができませんでした。
dMSA 用の TGT を取得する
dMSA で認証する方法の 1 つは、サービスを作成し、dMSA アカウントで実行されるように設定することです。これを実現することは可能ですが、便利なことではありません。幸いにも、Joe Dibley 氏による素晴らしいプルリクエストのおかげで、Rubeus は dMSA 認証をサポートするようになりました（図 9）。これにより、dMSA の TGT をリクエストするために使用できます。
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA →ドメイン管理
この例では、組み込みの管理者アカウントを対象にしています。Wireshark を使用して、dMSA 用に受信したチケットの PAC を検査しました（図 10）。これには次の内容が含まれます。
dMSA の RID（1137）
置き換えられたアカウントの RID（500 — 管理者）
置き換えられたアカウントのすべてのグループメンバーシップ（512 — ドメイン管理者、519 — エンタープライズ管理者）
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
これは、ドメインコントローラーが私たちを正当な後継者として扱うために必要なすべての情報です。最後に、このことを覚えておいてください。グループメンバーシップの変更はなく、ドメイン管理者グループが関与することもなく、実際の特権アカウントへの不審な LDAP 書き込みも発生しません。
2 つの属性の変更だけで、新しいオブジェクトが後継者として登録されます。KDC は、前リンクの正当性を検証しません。リンクが存在する場合、権限が付与されます。グループメンバーシップは変更せず、既存のアカウントの昇格は行わず、従来の特権昇格アラートを発動させることは一切ありませんでした。
デモ：エンドツーエンドの攻撃フロー
この動画では、攻撃の実際のデモをご覧いただけます。
Active Directory で dMSA を悪用して権限を昇格するデモ
この話にはまだ続きがある — 認証情報を侵害するための dMSA の悪用
どのユーザーでも TGT を取得できるのは便利なことですが、私たちはより多くのものを求めています。認証情報も必要な場合はどうすればよいですか？幸いにも、このシナリオでも dMSA が私たちを助けてくれます。
dMSA に対して TGT をリクエストすると、KERB-DMSA-KEY-PACKAGE と呼ばれる新しい構造体が含まれます。この構造体には、current-keys と previous-keys の 2 つのフィールドがあります。MSDN によると、これらは dMSA の現在のパスワードと以前のパスワードに関連するキーを含むはずです。たしかにその通りですが、それがすべてではありません。
私たちが驚いたのは、新しく作成された dMSA の TGT をリクエストしても、previous-keys フィールドは空ではなかったことです。作成したばかりなので、「以前のパスワード」は使用しないでください。この事実を無視していましたが、何か見覚えがあることに気づきました。
図 11 に示すように、構造体の 2 番目の要素は、タイプ 23（RC4-HMAC）の単一のキーを保持しています。この暗号化方式はソルト化されていないため、同一のパスワードは、ユーザー間でも同じキーを生成します。
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
では、この特定のキーは？ラボ環境で同じパスワードを長年再利用してきたことが、ついに報われました。 すぐに認識しました。これは Aa123456 に対応するキーで、デモでターゲットアカウントに使用したパスワードです。
考えてみてください：別のアカウントのキーは、何らかの理由で dMSA の previous-keys 構造で終了しました。
大規模なキーの漏えい
では、ここで何が起きているのでしょうか？また、それはなぜでしょうか？
msDS-ManagedAccountPrecededByLink は、権限付与のために dMSA を置き換えられたアカウントにリンクするだけでなく、dMSA がそのキーを継承できるようにします。これは、この攻撃によりドメイン内の任意の（またはすべての）ユーザーとコンピューターのキーを取得することもできることを意味します。このキーを使用して、アカウントで認証できます。
実装全体を分析したわけではありませんが、エンドユーザーの利便性を考慮し、アカウントの移行時にシームレスな継続性を確保するために、この動作が存在するという見解があります。
たとえば、レガシー・サービス・アカウントを使用して実行されているサービスがあるとします。ドメイン全体のアカウントは、このサービスへのチケットを要求します。このチケットは、レガシー・サービス・アカウントのキーを使用して暗号化されます。ここでは、レガシーアカウントを dMSA に置き換え、移行が完了し、サービスアカウントが dMSA に置き換えられると仮定します。ただし、dMSA は古いアカウントのキーにアクセスできません。
結果：クライアントが既存のチケットを使用して認証を試みた場合、サーバーは新しい dMSA キーを使用して復号化することができません。このため、発行されたすべてのチケットは期限切れでなくても使用できなくなります。
このようなサービスの中断を避けるために、KDC は新しい dMSA のキーパッケージ構造に、以前のアカウントのキーを含み、dMSA の以前の認証情報として処理し、「古い」チケットを復号化することができます。
これを理解すると、もう 1 つの奇妙なことが意味を成し始めます。current-keys フィールドには、整数（暗号化の種類を表す）とオクテット文字列（対応するキー）からなる 3 つの要素があります。このページを参照して暗号化タイプの値の理解にお役立てください。私たちのケースでは、リストには RC4-HMAC、AES256、および AES128 のキーが含まれます。ただし、previous-keys フィールドは少し異なります。このフィールドには、RC4-HMAC に対応するキーが 1 つだけ含まれています（図 12）。previous-keys リストには 1 つのキータイプ、特に RC4-HMAC しか含まれていないのはなぜなのか。
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
その答えは元の（置き換えられた）アカウントでサポートされている暗号化タイプにあります。サービスチケットは、ターゲットサービスがサポートする暗号化タイプを使用してのみ暗号化されます。Harmj0y’s excellent blog post で説明されているように、このふるまいは msDS-SupportedEncryptionTypes 属性によって制御されています。この属性が未定義の場合（ユーザーアカウントのデフォルトケース）、システムは RC4-HMAC のみに設定されます。したがって、 previous-keys リストには RC4-HMAC のみのキーが含まれています。
つまり、KDC は、移行前に発行されたサービスチケットを復号化するために必要な元のアカウントのキーだけを dMSA に提供します。これらは、元のプリンシパルでサポートされている暗号化タイプに基づいて決定されます。このタイプは、msDS-SupportedEncryptionTypes 属性を確認することで検証できます。
Microsoft の対応
2025 年 4 月 1 日、私たちは MSRC を通じてこの情報を Microsoft に報告しました。Microsoft はレポートと概念実証を検討した後、この問題を認め、有効性を確認しました。しかし、これは中程度の影響度の脆弱性として評価され、現在は即時サービスのしきい値を満たしていないと述べています。
Microsoft によると、この脆弱性の悪用に成功するためには、dMSA オブジェクトに対する特定の権限が攻撃者にすでに与えられている必要があります。これは、特権が昇格されたことを示しています。新しい dMSA を作成するシナリオに対応するために、Microsoft は KB5008383 を参照しました。ここでは、CreateChild 権限に関連するリスクについて説明しています。
Microsoft の対応には感謝していますが、影響度の評価については敬意を払って反対しています。
この脆弱性により、OU に対する CreateChild 権限を持つ任意のユーザーがドメイン内の任意のユーザーを侵害し、DCSync 攻撃を実行するために使用されるディレクトリ変更のレプリケート権限と同等の権限を取得できるようにする、これまで知られていなかった影響度の大きい不正使用パスが導入されています。
さらに、現在の業界慣行やツールが CreateChild アクセス（特に dMSA に対する CreateChild アクセス）に重大な懸念事項としてのフラグを立てる兆候は確認されていません。このことは、問題の隠密性と重大度を両方強調するものと考えています。
検知と緩和
検知
この攻撃ベクトルの悪用の可能性を検知するためには、組織は次の領域に重点を置く必要があります。
dMSA の作成監査：新しい msDS-DelegatedManagedServiceAccount オブジェクト（イベント ID 5137、図 13）の作成をログに記録するように SACL を設定します。サービスアカウントの作成に通常責任を負わないアカウントには、特にご注意ください。
Fig. 13: Event example of dMSA creation
属性変更の監視：msDS-ManagedAccountPrecededByLink 属性（イベント ID 5136、図 14）に対する変更のために SACL を設定します。この属性への変更は、不正使用の試みまたは成功を示す強い兆候です。
Fig. 14: Event example of dMSA link creation
dMSA 認証の追跡：dMSA に対して TGT が生成され、かつ、KERB-DMSA-KEY-PACKAGE 構造が含まれる場合、ドメインコントローラーはイベント ID 2946（ディレクトリ・サービス・ログ）を記録します。
グループ・マネージドサービス・アカウント・オブジェクト・フィールド（これは dMSA であり、gMSA ではありません）には、認証されている dMSA の DN が表示され、Caller SID フィールドには S-1-5-7 と表示されます （図 15）。通常とは異なる dMSA を含む 2946 のイベントが頻繁に発生しているか、予期しないものであるかを調査する必要があります。
Fig. 15: Event example of dMSA authentication
権限の確認：OU およびコンテナには細心の注意を払ってください。過度に権限を委任すると、このような悪用の可能性を高めることにつながります。
緩和策
Microsoft が正式なパッチをリリースするまで、防御の取り組みでは、可能な限り dMSA の作成と権限の強化の機能を制限することに重点を置く必要があります。
防御側は、ドメイン全体で dMSA を作成する権限を持つすべてのプリンシパル（ユーザー、グループ、コンピューター）を識別し、その権限を信頼できる管理者だけに制限する必要があります。
これを支援するために、次のことを実行する PowerShell スクリプトを公開しました。
dMSA を作成できるすべてのデフォルト以外のプリンシパルを列挙する
各プリンシパルがこの権限を持つ OU を一覧表示する
Microsoft は、Microsoft のエンジニアリングチームがパッチの開発に取り組んでいることを当社に知らせてくれました。技術詳細が入手可能になり次第、このブログ記事の緩和ガイダンスを更新します。
結論
この調査では、限られた範囲の権限（多くの場合、リスクが低いと想定される）でも、Active Directory 環境では広範囲に及ぶ影響を受ける可能性があることを強調しています。攻撃者はあらゆる手段を使います。最近の技術の進歩が私たちに教えてくれたように、無害に見える機能も、悪用されると深刻な結果をもたらす可能性があります。dMSA はサービスアカウント管理のための最新のソリューションとして導入されましたが、その導入により、新たな複雑さが生まれ、新たな悪用の機会をもたらしました。
組織は、dMSA を作成する機能や既存の dMSA を制御する機能を、他の機密操作と同じレベルの調査で扱う必要があります。これらのオブジェクトを管理する権限は厳密に制限されている必要があり、変更は定期的に監視および監査される必要があります。
この調査では、Windows Server 2025 の一般的なリスク、特に dMSA に伴うリスクを明らかにしました。防御担当者が誤設定の権限に潜む影響を明確に理解し、緩和する手助けとなれば幸いです。