Webアプリ用、バックアップ用、スキャン用。気づけばドメインに何十個ものサービスアカウントが存在していて、誰も管理していない。そのうちの1つが攻撃の起点になります。
Active Directoryへの攻撃手法の中でも、特に現場で意識しておきたいのがKerberoastingとDCSyncです。どちらもADの正規の仕組みを悪用するため検知が難しく、侵害が成功すると被害が甚大になります。
本記事では仕組みから防御策まで、演習経験がない方でも理解できるよう丁寧に解説します。
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とは
DCになりすます仕組み
DCSyncは、DCのレプリケーション機能を悪用して、ドメイン内のすべてのパスワードハッシュを盗み出す攻撃手法です。
DCレプリケーション（DC Replication）
複数のDCが存在する環境で、ADのデータを同期するための仕組み。あるDCで変更があると、他のDCに自動的に複製される。DCSyncはこのレプリケーションの仕組みを悪用する。
本来このレプリケーション機能はDCどうしがデータを同期するために使われます。DCSyncではこの仕組みを利用し、DCではない端末から「DCのふりをして」パスワードハッシュを要求します。
攻撃に必要な権限は以下のいずれかです。
| 権限・パーミッション | 既定の保持者 |
|---|---|
| Replicating Directory Changes | Enterprise Admins・Domain Admins・DC上のAdministrators |
| Replicating Directory Changes All | 同上 |
| GenericAll / AllExtendedRights | ドメインルートオブジェクトに対して付与されたアカウント |
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への対策は、以下の4点を組み合わせて実施します。
- DCSync権限の棚卸しをする：「誰がDCSync権限を持っているか」を定期的に確認する。デフォルトではEnterprise Admins・Domain Admins・DC上のAdministratorsが対象だが、過去の設定変更で意図せず追加されているケースがある。年に1回は棚卸しを実施する
- DCSync権限を持つアカウントの数を最小化する：DCSync権限を持つアカウントは攻撃者にとって最重要ターゲット。デフォルトグループへの所属人数を絞り、不要なアカウントへの直接付与は行わない
- Tierモデルを適用してログオン制限をかける：DCSync権限を持つアカウント（Tier 0資産）が、一般業務端末（Tier 2）からログオンできる状態は危険。Tierモデルを適用してログオン経路を制限する
- SPNを持つアカウントにDCSync権限を付与しない：KerberoastingでSPNアカウントのパスワードが割れ、そのアカウントがDCSync権限まで持っていると、一気にドメイン全体が危険にさらされる。この組み合わせは必ず避ける
Tierモデル（Tier Model）
ADリソースを重要度に応じてTier 0（DC・高権限アカウント）・Tier 1（サーバー）・Tier 2（一般端末）に分類し、上位Tierのアカウントが下位Tier環境にログオンできないようにするアクセス制御モデル。
2つの攻撃がつながる侵害シナリオ
KerberoastingとDCSyncは独立した攻撃に見えて、実際の侵害では連鎖します。
① 一般ユーザーアカウントで社内ネットワークに侵入
↓
② Kerberoastingでサービスアカウントのパスワードをクラック
↓
③ サービスアカウントで横展開・偵察
↓
④ 高権限アカウント（Domain Admins等）を発見・奪取
↓
⑤ DCSync実行——全ドメインハッシュ奪取
↓
⑥ KRBTGTハッシュからGolden Ticket生成
KerberoastingはADへの「入口を広げる」フェーズで使われます。一般ユーザー権限でサービスアカウントのパスワードを入手し、動ける範囲を広げる。
DCSyncは「仕上げ」フェーズで使われます。十分な権限を得た後、ドメイン全体の情報を一気に奪い取る。
この連鎖を断ち切るには、Kerberoastingを防いでサービスアカウントの奪取を阻止することが最初の砦になります。サービスアカウントが最小権限しか持っていなければ、仮にKerberoastingが成功しても攻撃者の動ける範囲を制限できます。
この攻撃チェーンは、AD演習Vol.1〜3で構築した環境の上で再現しています。まだ環境がない方は、まずはVol.1から。
すでにVol.1〜3の環境をお持ちの方は、記事末尾の Vol.4へ
なお、Vol.1〜5をまとめて学びたい方はセットプランも用意しています
現場でよくある設定ミス
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回実施している
まとめ
ドメイン内のサービスアカウントを棚卸ししてください。SPNが設定されているアカウント、Domain Adminsに入っているアカウント、パスワードが設定から変わっていないアカウント。
これらを確認するだけで、Kerberoastingのリスクが一目でわかります。
KerberoastingとDCSyncは単独の技術として理解するより、「攻撃者がドメインを制圧するルート」として理解する方が現場の感覚に近いです。2つの攻撃の連鎖を意識することで、どこを守れば被害を最小化できるかが見えてきます。
ここまで読んで「実際に手を動かしてみたい」と思った方へ。AD環境の構築からTierモデルによる防御、そして今回解説した攻撃の実行まで、段階を踏んで体験できる演習シリーズを公開しています。
この記事の内容は、AD演習編 Vol.1〜5で実際に手を動かして体験できます。「構築する」から「検知する」まで、一本のストーリーで学べるシリーズが完結しました。
AD演習編 Vol.1〜5
完全セット
構築 → 設計 → 攻撃 → 検知
VirtualBox上にAD環境をゼロから構築し、Tierモデルの実装・Kerberoasting/DCSyncの攻撃体験・PowerShell/Hayabusaによる検知分析までを一貫して学習。スクリーンショット付き手順書・環境設定リファレンス（Excel）付き。
単体で気になる巻から始めたい方は演習コンテンツ一覧もご覧ください。
あわせてご覧ください
- AD演習編 Vol.4「攻撃手法を体験する（Kerberoasting・DCSync）」
- AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
- ADのユーザーとグループ管理｜最小権限を実現する設計パターン
コメント