KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説

「サービスアカウントのパスワード、前任者が設定したまま変えていない」——現場でこういう話を聞くと、背筋が凍ります。

Webアプリ用、バックアップ用、スキャン用。気づけばドメインに何十個ものサービスアカウントが存在していて、誰も管理していない。そのうちの1つが攻撃の起点になります。

Active Directoryへの攻撃手法の中でも、特に現場で意識しておきたいのがKerberoastingとDCSyncです。どちらもADの正規の仕組みを悪用するため検知が難しく、侵害が成功すると被害が甚大になります。

本記事では仕組みから防御策まで、演習経験がない方でも理解できるよう丁寧に解説します。

Kerberoastingとは

Kerberoastingとは——SPNを狙ったパスワードクラック攻撃

Kerberoastingは、サービスアカウントに設定されたSPNを悪用してパスワードを盗み出す攻撃手法です。

SPN（Service Principal Name：サービスプリンシパル名） Active Directoryにおいて「このサービスはこのアカウントで動いている」ことをKerberosに伝える識別子。ファイルサーバーやWebアプリなど、Kerberos認証を使うサービスには必ずSPNが必要。

TGSチケット（Ticket Granting Service Ticket） Kerberosがサービスへのアクセスを許可するために発行するチケット。ドメインコントローラー（DC）がサービスアカウントのパスワードハッシュで暗号化して発行する。

SPNが設定されたアカウントに対しては、ドメイン内の誰でもTGSチケットを要求できます。これはKerberos認証の正規の仕様です。問題は、このTGSチケットがサービスアカウントのパスワードハッシュで暗号化されていることです。

攻撃者はこのチケットをオフラインで持ち出し、パスワードクラックツールで辞書攻撃をかけます。パスワードが弱ければ、平文パスワードが手に入ります。

Kerberoasting攻撃の流れ

攻撃は次の3ステップで完結します。

① SPNを持つアカウントを列挙する LDAPクエリでドメイン内のSPN一覧を取得します。一般ユーザー権限で実行でき、特別な準備は不要です。

② TGSチケットを要求・取得する 対象アカウントのTGSチケットをDCに要求します。正規のKerberos動作なので、ログには通常のチケット要求として記録されます。

③ オフラインでパスワードをクラックする 取得したTGSチケット（ハッシュ）をhashcatなどのツールで辞書攻撃します。ネットワーク接続は不要で、手元のマシンで完結します。

なぜ一般ユーザー権限だけで実行できるのか

Kerberoastingが特に厄介な理由は、ドメインの一般ユーザーであれば誰でも実行できる点です。

TGSチケットの要求は「サービスにアクセスするための正規の手順」であり、日常的に発生しています。Kerberoastingはその仕組みをそのまま悪用するため、デフォルト設定のAD環境では検知が非常に困難です。

またデフォルトではRC4暗号が使われるため、GPUを使った辞書攻撃に対して脆弱です。

RC4（Rivest Cipher 4） Kerberosが歴史的に使ってきた暗号アルゴリズム。処理速度は速いが、現代のGPUによる総当たり攻撃に対して脆弱とされる。攻撃者はあえてRC4形式のチケットを要求することでクラックを高速化する。

Kerberoastingへの防御策

① サービスアカウントをgMSAに移行する（根本解決）

gMSA（group Managed Service Account：グループ管理サービスアカウント） ADが自動でパスワードを管理する特殊なサービスアカウント。120文字のランダムパスワードが30日ごとに自動ローテーションされる。人間が知ることのできないパスワードのため、クラックは事実上不可能。

gMSAへの移行が最も確実な対策です。ただし非Windowsシステムや一部のアプリケーションではgMSAに対応していない場合があります。その場合は次の対策を組み合わせて実施します。

② パスワードを30文字以上に設定する

gMSA化が難しい場合は、サービスアカウントのパスワードをランダムな30文字以上に設定します。辞書攻撃での解読が現実的でなくなります。

③ AES暗号を強制する

GPOでKerberos暗号化をAESに強制することで、RC4よりクラックコストが大幅に上がります。ただしAESに変更してもパスワードが弱ければ辞書攻撃は成立します。AES強制は必ずパスワード長の確保とセットで実施してください。

④ サービスアカウントの権限を最小化する

仮にKerberoastingが成功してパスワードが割れても、そのアカウントの権限が最小限であれば被害を限定できます。サービスアカウントをDomain Adminsなどの高権限グループに所属させることは絶対に避けてください。

DCSyncとは

DCSyncとは——DCになりすまして全ハッシュを奪う攻撃

DCSyncは、DCのレプリケーション機能を悪用して、ドメイン内のすべてのパスワードハッシュを盗み出す攻撃手法です。

DCレプリケーション（DC Replication） 複数のDCが存在する環境で、ADのデータを同期するための仕組み。あるDCで変更があると、他のDCに自動的に複製される。DCSyncはこのレプリケーションの仕組みを悪用する。

本来このレプリケーション機能はDCどうしがデータを同期するために使われます。DCSyncではこの仕組みを利用し、DCではない端末から「DCのふりをして」パスワードハッシュを要求します。

攻撃に必要な権限は以下のいずれかです。

DCSync攻撃の流れ

① DCSync権限を持つアカウントを奪取する Kerberoasting・パスワードスプレー・フィッシングなど、別の攻撃手法で高権限アカウントを入手します。

② レプリケーション要求を送信する 攻撃ツールがDCに「レプリケーションデータをください」と要求します。正規のDCからのリクエストと見分けがつかないため、ADは応答します。

③ 全ハッシュを取得する ドメイン内のすべてのユーザー・コンピューターのNTLMハッシュが手に入ります。ドメインの「鍵束ごと盗む」状態です。

KRBTGTハッシュ奪取とその先

DCSyncで特に危険なのがKRBTGTアカウントのハッシュ奪取です。

KRBTGT（Key Distribution Center Service Account） Kerberos認証の根幹を担う特殊アカウント。DCが発行するTGT（Ticket Granting Ticket）の暗号化に使われる。「ドメインの信頼の根」とも言われる。

KRBTGTのハッシュを手に入れると、攻撃者はGolden Ticketを偽造できます。Golden Ticketとは任意の権限・有効期限を持つ偽造TGTのことで、存在しないユーザーや管理者権限を自由に作り出せます。有効期限を10年に設定することも可能で、一度発行されると検知と無効化が極めて困難です。

DCSyncの成功は「ドメインの完全侵害」を意味します。回復には全ユーザー・コンピューターのパスワードリセットとKRBTGTパスワードの2回変更が必要で、多くの組織にとって甚大なコストがかかります。

DCSyncへの防御策

① DCSync権限の棚卸しをする

「誰がDCSync権限を持っているか」を定期的に確認します。デフォルトではEnterprise Admins・Domain Admins・DC上のAdministratorsが対象ですが、過去の設定変更で意図せず追加されているケースがあります。年に1回は棚卸しを実施してください。

② DCSync権限を持つアカウントの数を最小化する

DCSync権限を持つアカウントは攻撃者にとって最重要ターゲットです。デフォルトグループへの所属人数を絞り、不要なアカウントへの直接付与は行いません。

③ Tierモデルを適用してログオン制限をかける

Tierモデル（Tier Model） ADリソースを重要度に応じてTier 0（DC・高権限アカウント）・Tier 1（サーバー）・Tier 2（一般端末）に分類し、上位Tierのアカウントが下位Tier環境にログオンできないようにするアクセス制御モデル。

DCSync権限を持つアカウント（Tier 0資産）が、一般業務端末（Tier 2）からログオンできる状態は危険です。攻撃者は業務端末を足がかりに高権限アカウントへ横展開するため、Tierモデルを適用してログオン経路を制限します。

④ SPNを持つアカウントにDCSync権限を付与しない

KerberoastingでSPNアカウントのパスワードが割れ、そのアカウントがDCSync権限まで持っていると、一気にドメイン全体が危険にさらされます。SPNアカウントとDCSync権限の組み合わせは必ず避けてください。

2つの攻撃がつながる——実際の侵害シナリオ

KerberoastingとDCSyncは独立した攻撃に見えて、実際の侵害では連鎖します。

KerberoastingはADへの**「入口を広げる」フェーズ**で使われます。一般ユーザー権限でサービスアカウントのパスワードを入手し、動ける範囲を広げる。

DCSyncは**「仕上げ」フェーズ**で使われます。十分な権限を得た後、ドメイン全体の情報を一気に奪い取る。

この連鎖を断ち切るには、Kerberoastingを防いでサービスアカウントの奪取を阻止することが最初の砦になります。サービスアカウントが最小権限しか持っていなければ、仮にKerberoastingが成功しても攻撃者の動ける範囲を制限できます。

現場でよくある設定ミス

① SPNをサービスアカウントに安易に付与している

「Kerberos認証を通すためにとりあえずSPNを設定する」という運用で、用途不明のSPNが増え続けている現場があります。SPNを持つアカウントはすべてKerberoastingの標的です。定期的にSPN一覧を確認し、不要なものは削除してください。

② サービスアカウントがDomain Adminsに入っている

「管理が楽だから」という理由でサービスアカウントをDomain Adminsに追加する運用は非常に危険です。Kerberoastingでそのアカウントのパスワードが割れた瞬間、ドメイン全体が危険にさらされます。

③ RC4暗号のまま放置している

デフォルト設定ではKerberosはRC4暗号を使います。AES強制に変更することでクラックコストは上がりますが、パスワードが弱ければAESモードでも辞書攻撃は成立します。AES強制は必ずパスワード長の確保とセットで実施してください。

④ DCSync権限の棚卸しをしていない

「誰がDCSync権限を持っているか把握していない」という組織は多いです。過去の設定変更で意図せず追加されているケースもあります。年1回の棚卸しを習慣にしてください。

現場でできることチェックリスト

Kerberoasting対策

• ドメイン内のSPN一覧を把握しており、不要なSPNは削除している
• SPNを持つサービスアカウントをgMSAに移行している（困難な場合はパスワード30文字以上）
• サービスアカウントはDomain Adminsなど高権限グループに所属していない
• AES暗号が強制されており、パスワードも十分な長さが確保されている

DCSync対策

• DCSync権限を持つアカウントの一覧を把握している
• DCSync権限を持つアカウントはTier 0として管理され、業務端末からログオンできない
• SPNを持つサービスアカウントにDCSync権限が付与されていない
• DCSync権限の棚卸しを年1回実施している

まとめ

今日確認すべきことは1つです。ドメイン内のサービスアカウントを棚卸ししてください。

SPNが設定されているアカウント、Domain Adminsに入っているアカウント、パスワードが設定から変わっていないアカウント——これらを確認するだけで、Kerberoastingのリスクが一目でわかります。

KerberoastingとDCSyncは単独の技術として理解するより、「攻撃者がドメインを制圧するルート」として理解する方が現場の感覚に近いです。2つの攻撃の連鎖を意識することで、どこを守れば被害を最小化できるかが見えてきます。

防御設定を実際に手を動かして体験したい方は、[AD演習編 Vol.6「防御設定を実装する」]（公開予定）でKerberoasting・DCSync両方の防御設定をBefore/After形式で体験できます。

ここまで読んで「実際に手を動かしてみたい」と思った方へ。AD環境の構築からTierモデルによる防御、そして今回解説した攻撃の実行まで、段階を踏んで体験できる演習シリーズを公開しています。

あわせてご覧ください

• AD演習編 Vol.4「攻撃手法を体験する（Kerberoasting・DCSync）」
• 特権アカウントとTierモデルで考えるADセキュリティ
• Active Directoryのグループ設計と最小権限の原則

参考文献

• 参考：Detecting and Mitigating Active Directory Compromises（ASD・ACSC）
• 参考：Kerberos 認証の概要（Microsoft Learn）
• 参考：グループの管理されたサービス アカウントの概要（Microsoft Learn）