グループ管理サービスアカウントの概要
従来の慣行として、通常のユーザーアカウントをサービスアカウントとして使用すると、パスワード管理の負担がユーザーにのしかかります。その結果、アカウントのパスワードが何年もの間同じ状態のままになりやすくなり、ブルートフォース攻撃や不正使用に対して非常に脆弱になります。グループ管理サービスアカウント（gMSAs）は、自動化タスク、サービス、アプリケーションをより安全に実行するための方法を提供します。
gMSA は Windows Server 2016 で導入され、Windows Server 2012 以降で活用できます。gMSA のパスワードは Windows によって完全に管理されます。パスワードはランダムに生成され、自動的にローテーションされます。さらに、サービス アカウント自体が、パスワード情報を問い合わせるサーバーに「インストール」されるため、どのユーザーもパスワードを知っている必要はありません。 Active Directory を実行時に参照します。その結果、gMSA は、サービス アカウントとして使用されるユーザー アカウントよりも、誤用や侵害（コンプロマイズ）に対してはるかに影響を受けにくくなっています。
グループ管理サービスアカウントのセキュリティ
gMSA は Active Directory の特定のオブジェクト タイプです。msDS-GroupManagedServiceAccount となります。これらのオブジェクトには、パスワードとそのローテーションに関連する特別な属性が付いています。 LAPS と同様に、gMSA の属性が、それらにアクセスする必要がある Active Directory のオブジェクトのみに対してロックされていることを確認してください。
gMSA の属性と権限
gMSA には次の属性があります：
- msDS-ManagedPassword— gMSA のパスワードを含む BLOB
- msDS-ManagedPasswordID— 現在の gMSA パスワードを生成するために使用されるキー ID
- msDS-ManagedPasswordPreviousID— 以前の gMSA パスワードを生成するために使用されるキー ID
- msDS-GroupMSAMembership— gMSA のパスワードを照会する権限を持つオブジェクトの一覧
- msDS-ManagedPasswordInterval— パスワードをローテーション（変更）する間隔（日数）
パスワード情報は msDS-ManagedPassword 属性に保存されているため、環境内で誰がパスワードを照会できるのかは必ず把握しておきたいところです。この情報は msDS-GroupMSAMembership 属性で設定されます。
ただし、これはその属性だけでは少し複雑です。Active Directory の権限が関係してくるためです。何らかの理由で、ユーザーまたはオブジェクトが msDS-GroupMSAMembership アカウント経由でパスワードを照会するための権限を持つように設定されていたとしても、gMSA の msDS-ManagedPassword 属性に対する「Read」権限がそれでも必要になります。
つまり、gMSA のパスワードを保護する方法には 2 つの手段があります。
- 必要なオブジェクトだけがパスワードを照会するための権限を持つようにし、それらが msDS-GroupMSAMembership に存在することを確認してください。
- アクセスが必要な管理ユーザーと、gMSA がインストールされているコンピューター アカウントだけが、その属性を読み取るための権限を持つようにしてください。また、gMSA およびその属性を変更できるのは管理者だけにし、誰も msDS-GroupMSAMembership 属性に自分を追加できないようにしてください。
理想的には、攻撃者が上記のいずれかのシナリオを悪用する選択肢を持てないように、gMSA を2つの経路の両方でしっかりとロックダウンします。以下では、gMSA 上の権限や設定が適切に管理されていない場合に、アカウントが侵害され、 権限昇格 または横方向への移動につながる仕組みを説明します。
gMSA のパスワードの悪用
gMSA を悪用すること は、概念的には比較的シンプルです。まず、Mimikatz のようなツールを使ってパスワードを取得するか、Active Directory の設定が不適切であるために直接クエリを実行して取得します。gMSA はサービスアカウントなので、通常は比較的権限が高いです。そのため、その後は多くの場合、横方向への移動や権限昇格が可能になります。
厳選した関連コンテンツ：
例のシナリオを順を追って見ていきましょう。
1. まずは、フィッシングのような手法を使って通常の Windows ユーザー アカウント「notadmin」を侵害します。このアカウントは Active Directory 内では最小限の権限しか持っていませんが、侵入した先のマシンではローカル管理者です。
2. 次に、gMSA が存在するかどうかを調べます。Windows PowerShell cmdlet にアクセスできるなら、これは非常に簡単です。単純なスクリプトを実行すると、Active Directory 内のすべての管理対象サービス アカウントが取得できます：
Get-ADServiceAccount -Filter *
3. スクリプトを少しだけ変更することで、gMSA のパスワードを照会できるのが誰かを特定できます：
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
ご覧のとおり、これらのサービス アカウントのパスワードを照会できるのは Kevin Joyce アカウントだけです：
4. これらのサービス アカウントがいずれかの特権グループのメンバーであるかどうかを確認することで、狙いたいターゲットの範囲を絞り込めます。そこから、オブジェクトの1つに設定されている権限をさらに掘り下げることができます：
Get-ADServiceAccount -Filter * -Properties memberof
ここでの結果を見ると、gMSA サービス アカウントが Domain Admins のメンバーであることが分かります。したがって、こちらを悪用の対象として試します。
5. Microsoft LAPS に関する投稿で提供されているスクリプトを修正することで、特定の gMSA 属性に対して、完全制御（Full Control）、すべてのプロパティを書き込む（Write All Properties）、またはプロパティを書き込む（Write Property）の権限を含む、マネージド サービス アカウントに対する権限を持つすべてのオブジェクトの一覧を取得できました。出力結果は以下のとおりで、スクリプトへのリンクは末尾にあります。
6. ご覧のとおり、notadmin アカウントには gMSA アカウントに対する完全制御（Full Control）権限があります。これにより msDS-GroupMSAMembership 属性を変更できるようになり、マネージド サービス アカウントのパスワードを取得できるようになります：
Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
7. パスワードを実際に照会できるようになったので、これで何ができるのかを見てみましょう：
Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
$pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
8. 属性に保存されている値は、パスワードそのものではなく、パスワードのデータを含む BLOB です。そのため、DSInternals のようなツールを使ってパスワードをデコードする必要があります：
$pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
これで SecureCurrentPassword と CurrentPassword を取得できます。CurrentPassword は役に立たないように見えますが、これはすべての文字が UTF-16 だからです。SecureCurrentPassword は NTLM ハッシュに変換でき、パス・ザ・ハッシュ攻撃（pass the hash） に使って、mimikatz で権限を昇格できます。
9. パス・ザ・ハッシュ（pass the hash） を行うには、mimikatz を実行してこのコマンドを使うだけです:
sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
10. いま、Domain Admins のメンバーであった gMSA サービス アカウントとしてシェルが実行できているので、Active Directory を侵害するために好きなことが何でもできます。その中でも最も早い方法の1つですが、おそらくは最も目立つ（ノイジーな）やり方の1つは、DCSync 攻撃を実行して、krbtgt アカウントのハッシュを盗むことです:
lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
gMSA の保護と監視
gMSA の悪用を防止し、検出するために使える戦略があります。
権限
最も明白で、ある意味でおそらく最も重要な防御策は、グループ管理サービスアカウント（group managed service accounts）に適切な権限が設定されていることを確認することです。これらのオブジェクトに対して誰が書き込みアクセスを持っているかを理解することは、それらを保護するうえで重要です。理屈の上では、パスワードを照会できる相手を制御する属性に自分を追加できる人は、すでにそのアカウントを乗っ取り、その特権を悪用するためのアクセス権を持っていることになります。
次に行うべきことは、これらのアカウントのパスワードを照会できる能力を持つのが誰なのか、そしてそのようなアクセスを必要とするのが誰なのかを正確に把握することです。実際には、gMSA のパスワードを取得できるべき唯一のアカウントは、その gMSA がインストールされているコンピューターアカウントだけです。
イベント ログ
ネイティブのイベント ログで探せるイベントがあり、それによって、gMSA アカウントのパスワードを誰が照会しているのかを特定するのに役立ちます。ドメインに対して「Audit directory service access」ポリシーを有効化し、監視したい gMSA に SACL を設定すると、人が msDS-ManagedPassword 属性を照会したときにイベント ログを生成できます：
この設定を有効にして新しい SACL を作成すると、イベント ID 4662 のイベント ログが生成されます。見た目は次のとおりです:
ご覧のとおり、ログには ‘notadmin’ アカウントが gMSA アカウント上のプロパティを読み取ったことが記録されています。読み取られたプロパティは Active Directory のスキーマに保存されている GUID ですが、ADSI Edit を使うと、ハイライトされている GUID が msDS-ManagedPasssword 属性に解決されることがわかります。
何らかのイベント ログ転送、または SIEM ソリューションを利用している場合、これらのログは、誰がこれらの属性にアクセスしているのかを特定するうえで非常に貴重です。
Netwrix StealthDEFEND
もう一つの選択肢は Netwrix StealthDEFEND のようなツールです。 Netwrix StealthDEFEND はネイティブのイベント ログに依存せず、gMSA パスワードへのアクセスや高リスクの権限付与をすぐに検出できます。たとえば、上に示したシナリオでは、 ‘notadmin’ アカウントがパスワードを照会したときに、次の脅威が生成されます:
さらに、Netwrix StealthDEFEND を使用すると、gMSA の悪用が検出されたときに実行するプレイブックを簡単に作成できます。プレイブックには、犯人のユーザー アカウントに MFA リクエストへ応答させること、アカウントを無効化すること、または ServiceNow インシデントを作成するといった複数のステップを含めることができます。
付録
gMSA 権限コード：
<#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'
##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target
<#Get objects that have specific permissions on the target(s):
Full Control(GenericAll)
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access |
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access |
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
生の内容を表示gMSA_Permissions_Collection.ps1 によりホストされています GitHub
よくある質問
gMSA とは？
管理サービス アカウント（Managed Service Accounts：MSA）と同様に、グループ管理サービス アカウント（Group Managed Service Accounts：gMSA）は、サービスやアクセス管理を保護するために使用される管理対象のドメイン アカウントです。gMSA の機能により、ドメイン コントローラー（DC）による自動パスワード管理、サービス プリンシパル名（Service Principal Name：SPN）の管理の簡素化、さらに管理を他の管理者に委任できるため、 Active Directory のセキュリティ が向上し、特権アクセスを持つアカウントを最小限に抑えます。
MSA と gMSA の違いは何ですか？
MSA と異なり、gMSA は複数のコンピューターに関連付けることができます。
グループ管理サービス アカウントを見つけるには？
ドメイン コントローラー上の gMSA の一覧を取得するには、Server Manager > Tools > Active Directory Users and Computers > Managed Service Accounts を開きます。
gMSA は Domain Admin になれますか？
はい。gMSA アカウントは Domain Admins のメンバーにできますが、この運用は情報セキュリティ上危険になり得ます。
gMSA を作成するにはどうすればよいですか？
グループ管理サービス アカウントは、New-ADServiceAccount コマンドレットで作成します。
共有する
もっと詳しく
著者について
Kevin Joyce
プロダクトマネジメント担当ディレクター
Netwrix のプロダクトマネジメント担当ディレクター。Kevin はサイバーセキュリティに情熱を持ち、特に攻撃者が組織の環境を悪用するために用いる戦術や手法を理解することに注力しています。Active Directory と Windows のセキュリティに焦点を当てたプロダクトマネジメントでの 8 年の経験を通じて、その情熱を活かし、組織がアイデンティティ、インフラ、データを保護できるようなソリューションの構築を支援しています。