ADは正しく設計・運用すれば強固な認証基盤になります。
しかし攻撃者の視点から見ると、ADは「一度侵入できれば全体を掌握できる」構造を持っています。設計の甘さや運用の抜け穴が、そのままドメイン全体の陥落につながります。
守れる設計をするためには、攻撃の仕組みを知ることが不可欠です。この記事では、AD環境で実際に使われる4つの攻撃手法
Pass-the-Hash
Kerberoasting
GoldenTicket
DCSync
それぞれの仕組み、現場での影響、具体的な対策を解説します。
ADの認証の仕組みについては「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」を先にご覧ください。攻撃の兆候をログで追う方法については「ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド」と合わせて読むと防御設計の全体像が掴めます。
なぜADは攻撃者に狙われるのか
ADはドメイン内のすべてのユーザー・コンピューター・権限を一元管理しています。裏を返すと、ADを掌握した攻撃者はドメイン全体を自由に操れます。全ユーザーのパスワードリセット・任意のPCへのログイン・ファイルサーバの全データ奪取——これらがすべて可能になります。
攻撃者がAD環境を狙う理由はもう一つあります。ADの認証プロトコル（KerberosとNTLM）の仕組み自体に、設計上悪用可能な特性があることです。これは脆弱性ではなく仕様です。仕様である以上、完全に無効化することはできません。仕組みを理解した上で、悪用されにくい設計で補うことが現実的な対策になります。
KerberosとNTLMの役割については「Active Directoryとは？」の「ADの認証はどう動くのか」セクションで解説しています。
この記事で扱う4つの攻撃手法
| 攻撃手法 | 悪用する仕組み | 主な標的 | 影響範囲 |
|---|---|---|---|
| Pass-the-Hash | NTLMハッシュ | 一般ユーザー・管理者アカウント | ハッシュが有効な全リソース |
| Kerberoasting | Kerberosサービスチケット | サービスアカウント | SPNが設定されたサービス全体 |
| GoldenTicket | KRBTGTアカウントのハッシュ | ドメイン全体 | ドメイン内の全リソース |
| DCSync | DCレプリケーション権限 | ドメイン全体 | 全アカウントの資格情報 |
4つの中で影響範囲が最も大きいのがGoldenTicketとDCSyncです。どちらもドメイン全体の掌握につながるため、特に優先度の高い対策が必要です。
参考：Active Directoryをセキュリティで保護するためのベスト プラクティス | Microsoft Learn
Pass-the-Hashとは
ハッシュ値が危険な理由
NTLMハッシュ（NTLM Hash）
Windowsがパスワードを保存・認証に使用するハッシュ値。NTLMプロトコルの認証ではパスワードの平文ではなくこのハッシュ値を使うため、ハッシュ値さえ入手すれば平文を知らなくても認証を突破できる。
WindowsのNTLM認証は「パスワードのハッシュ値」を使って認証します。平文パスワードは使いません。これは盗聴対策として設計された仕組みですが、逆に「ハッシュ値を盗めばパスワードを知らなくても認証できる」という弱点を生んでいます。
攻撃の流れはシンプルです。
- 攻撃者がマルウェア等で一般PCを侵害する
- LSASS（認証情報を管理するWindowsプロセス）からNTLMハッシュを抽出する
- 抽出したハッシュを使って他のサーバへ認証を試みる
- 同じ資格情報が有効なサーバへ次々と侵入する（横展開）
LSASS（Local Security Authority Subsystem Service）
Windowsの認証を管理するプロセス。ログオン中のユーザーの資格情報をメモリ上にキャッシュしており、攻撃ツール（Mimikatzなど）による抽出の標的になりやすい。
現場でどう広がるか
現場での典型的なシナリオは「一般PCの侵害から始まりDCに到達する」流れです。特にDomain Adminsアカウントで一般PCにログインしたことがある環境では、そのPCにハッシュが残っているため、そのPCを起点にドメイン全体が危険にさらされます。
特権アカウントを一般PCで使うリスクについては「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」で解説しています。
資格情報キャッシュを減らす対策
| 対策 | 内容 |
|---|---|
| Credential Guard の有効化 | Windows 10/Server 2016以降で利用可能。仮想化ベースのセキュリティでLSASSを保護しハッシュ抽出を防ぐ |
| PAWの導入 | 特権アカウントを専用端末に閉じ込め、一般PC上にハッシュが残らない構成にする |
| Tierモデルの徹底 | Tier 0アカウントを一般PC（Tier 2）で使用しない。ログオン先制限をGPOで強制する |
| NTLMの制限 | グループポリシーでNTLM認証を制限・監視する（完全無効化は互換性の確認が必要） |
Credential Guard（資格情報ガード）
Windows仮想化ベースのセキュリティ機能。LSASSを隔離された環境で動作させることで、資格情報の抽出ツールによるハッシュ盗取を防ぐ。
参考：Credential Guard の概要 | Microsoft Learn
Kerberoastingとは
チケットを持ち帰ってクラックする仕組み
SPN（Service Principal Name：サービスプリンシパル名）
ADにおいてサービスを一意に識別する識別子。Kerberosはこの識別子を使ってサービス向けのチケット（TGS）を発行する。SPNが設定されたアカウントはKerberoastingの標的になりうる。
Kerberosでは、ユーザーがサービスにアクセスするときに「サービスチケット（TGS）」を取得します。このTGSはサービスアカウントのNTLMハッシュで暗号化されています。
Kerberoastingの手順はシンプルです。
- ドメインユーザー（一般権限で十分）がSPNを持つサービスアカウント向けのTGSを正規に要求する
- 取得したTGSをネットワーク上には送らず、ローカルに持ち帰る
- オフラインでパスワードクラックツールを使いTGSを解読する
- サービスアカウントのパスワードを復元し、そのアカウントで侵入する
TGS（Ticket Granting Service：サービス許可チケット）
Kerberosで特定のサービスへのアクセスに使用するチケット。サービスアカウントのハッシュで暗号化されており、オフラインクラックの対象になる。
この攻撃の特徴はネットワーク上に不審な通信が発生しないことです。チケットの取得は正規の操作なので、ログを見ても気づきにくい。
なぜサービスアカウントが狙われるのか
サービスアカウントは「人が使わない」ため、パスワードを設定したまま何年も変更されないケースが多くあります。弱いパスワードのサービスアカウントは数分〜数時間でクラックされます。サービスアカウントの設計については「サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド」で詳しく解説しています。
SPNとパスワード管理を強化する
| 対策 | 内容 |
|---|---|
| Managed Service Account（MSA）/ gMSAの使用 | パスワードをADが自動管理・ローテーションするサービスアカウント。クラックされる前にパスワードが変わり続ける |
| 不要なSPNの削除 | 使われていないSPNを持つアカウントを棚卸しして削除する |
| サービスアカウントのパスワード強化 | 手動管理の場合は25文字以上のランダム文字列を使用する |
| 特権の最小化 | SPNを持つアカウントに余分な権限を付与しない |
gMSA（group Managed Service Account：グループ管理サービスアカウント）
ADが自動でパスワードを生成・ローテーションするサービスアカウント。複数サーバで共有できるため、Kerberoasting対策として推奨される。
参考：グループ管理サービスアカウントの概要 | Microsoft Learn
GoldenTicketとは
KRBTGTハッシュから偽造チケットを作る
KRBTGTアカウント
ドメイン内のKerberos認証に使用される特殊なサービスアカウント。このアカウントのハッシュ値はKerberosチケット（TGT）の署名に使われるため、流出するとドメイン内の任意のチケットを偽造できる。
Kerberosの認証チケット（TGT）は、KRBTGTアカウントのハッシュ値で署名されています。攻撃者がこのハッシュ値を入手すると、有効期限・権限・ユーザー名を自由に設定した偽造TGT（GoldenTicket）を作成できます。
GoldenTicketを持つ攻撃者は、存在しないユーザーとして、あるいは任意の管理者として、ドメイン内のどのリソースにもアクセスできます。
発覚しにくい理由
GoldenTicketの最大の危険性は発覚しにくさです。正規のKerberosチケットと見分けがつかないため、ログを見ても「正常な認証」として記録されます。KRBTGTのパスワードを変更しない限り、作成されたGoldenTicketは理論上何年でも有効です。
実際のインシデントでは、侵害が発覚した後に「数か月前からGoldenTicketで侵入されていた」ことが判明するケースがあります。
KRBTGTパスワードを定期的にリセットする
| 対策 | 内容 |
|---|---|
| KRBTGTパスワードの定期リセット | 既存のGoldenTicketを無効化する唯一の手段。年1回以上・インシデント後は即座に実施 |
| Tier 0の厳格な保護 | KRBTGTハッシュはDCへの侵入がなければ入手できない。DCへのアクセスをTierモデルで制限する |
| DCSync検知の設定 | KRBTGTハッシュの抽出に使われるDCSyncをイベントログで検知する（次セクションで解説） |
KRBTGTパスワードは2回連続でリセットする必要があります（古いハッシュを完全に無効化するため）。リセット手順はMicrosoftが提供するスクリプトを使用することを推奨します。
参考：KRBTGT アカウントのパスワードをリセットする | Microsoft Learn
DCSyncとは
DCになりすましてハッシュを要求する仕組み
DCレプリケーション（Directory Replication）
複数のDC間でADデータベースを同期する仕組み。この権限を持つアカウントはDCに接触せずにアカウント情報（ハッシュ値を含む）を取得できる。
ADには複数のDCが存在する環境のため、DCどうしがお互いにデータを同期（レプリケーション）する仕組みがあります。DCSyncはこの仕組みを悪用します。
- 攻撃者がレプリケーション権限（
Replicating Directory Changes All）を持つアカウントを入手する - DCに対して「別のDCとしてデータを同期したい」というリクエストを送る
- DCは正規のレプリケーションと判断し、要求されたアカウントのハッシュを返す
- ドメイン内の全アカウント（KRBTGTを含む）のハッシュを取得する
この攻撃はDCへの直接ログインが不要です。レプリケーション権限を持つアカウントがあれば、ネットワーク経由でリモートから実行できます。
静かに全アカウントが流出する
DCSyncが成功すると、攻撃者はドメイン内の全アカウントのNTLMハッシュとKRBTGTハッシュを入手します。これ以降、Pass-the-HashもGoldenTicketも自由に使えます。
問題は「気づきにくい」ことです。レプリケーション要求は通常業務でも発生するため、監視設定がないと見逃します。イベントログでの検知方法については「ADイベントログ監査」で解説した4662（ディレクトリサービスのアクセス）が手がかりになります。
レプリケーション権限を管理する
| 対策 | 内容 |
|---|---|
| レプリケーション権限の棚卸し | Replicating Directory Changes All を持つアカウントをDC以外から削除する |
| イベントID 4662の監視 | DCSyncの実行時にレプリケーション操作として記録される。DCアカウント以外からの4662を即アラート化する |
| 特権アカウントの保護 | Domain Adminsをはじめとする高権限アカウントを厳格に管理し、DCSyncに必要な権限が攻撃者に渡らないようにする |
# レプリケーション権限を持つアカウントの確認（参考コマンド）
Get-ADObject -Filter * -Properties nTSecurityDescriptor |
Where-Object { $_.nTSecurityDescriptor.Access |
Where-Object { $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" } }参考：DCSync 攻撃の疑い（ディレクトリ サービスのレプリケーション）| Microsoft Defender for Identity
4つの攻撃に共通する防御設計の考え方
4つの攻撃手法を整理すると、防御設計に共通する3つの原則が見えてきます。
- 資格情報の露出面を減らす：Pass-the-HashもKerberoastingも、「資格情報が盗める状態」があることで成立する。Tierモデルで特権アカウントの使用場所を絞り、PAWで端末を隔離し、gMSAでサービスアカウントのパスワードを自動管理する——これらはすべて「盗める資格情報を減らす」設計
- 侵害が広がる前に検知する：GoldenTicketは「侵害後に長期潜伏される」攻撃。DCへのアクセスをログで監視し、KRBTGTパスワードを定期リセットすることで、潜伏期間を最小化できる
- 侵害の影響範囲を限定する：完全な防御はない。侵害されたとき「どこまで被害が広がるか」を設計で制御することが重要。最小権限の原則に基づいてアカウントの権限を絞り、侵害の連鎖を止める設計を意識する
Tierモデル・PAWの実務設計については「AD特権アカウントの設計」、ログ監視の設計については「ADイベントログ監査」、最小権限の設計については「最小権限の原則とは？」で、それぞれ詳しく解説しています。
要塞化チェックリスト
Pass-the-Hash対策
- [ ] Credential Guardを有効化している（Windows 10 / Server 2016以降）
- [ ] PAWを導入し、特権アカウントを専用端末に閉じ込めている
- [ ] GPOでTier 0アカウントのログオン先を制限している
- [ ] NTLMの使用状況をイベントログで監視している
Kerberoasting対策
- [ ] SPNを持つサービスアカウントを棚卸ししている
- [ ] 可能な限りgMSA / MSAに移行している
- [ ] 手動管理のサービスアカウントは25文字以上のランダムパスワードを使用している
- [ ] 不要なSPNを削除している
GoldenTicket対策
- [ ] KRBTGTパスワードを年1回以上リセットしている
- [ ] インシデント発生後にKRBTGTパスワードを2回連続でリセットする手順を定めている
- [ ] DCへのアクセスをTierモデルで制限している
DCSync対策
- [ ]
Replicating Directory Changes All権限をDC以外のアカウントから削除している - [ ] イベントID 4662（DCアカウント以外からの実行）をアラート対象にしている
- [ ] Domain Adminsのメンバーを最小人数に絞っている
攻撃を知ることが守れる設計への第一歩
4つの攻撃手法に共通しているのは、「ADの正規の仕組みを悪用している」という点です。これらは脆弱性ではなく仕様である以上、パッチを当てて終わりにはなりません。仕組みを理解した上で、露出面を減らし・検知できる状態を作り・被害範囲を限定するという設計の積み重ねが唯一の答えです。
ドメイン内でSPNが設定されているサービスアカウントを確認し、パスワードが適切に管理されているかを見てください。
# SPNが設定されているサービスアカウントの一覧表示
Get-ADUser -Filter {ServicePrincipalName -ne "$null"}
弱いパスワードのサービスアカウントは今すぐKerberoastingの標的になりえます。
次のステップは、オンプレADとEntra IDを連携させたハイブリッド構成の設計です。「Entra IDとオンプレAD連携」で、クラウド時代のADセキュリティ設計を解説します。
ここまで読んで「実際に手を動かしてみたい」と思った方へ。AD環境の構築から、OU・GPO・グループ設計、Tierモデルによる防御、そして今回扱った攻撃手法までを段階を踏んで体験できる演習シリーズを公開しています。
この記事の内容は、AD演習編 Vol.1〜5で実際に手を動かして体験できます。「構築する」から「検知する」まで、一本のストーリーで学べるシリーズが完結しました。
AD演習編 Vol.1〜5
完全セット
構築 → 設計 → 攻撃 → 検知
VirtualBox上にAD環境をゼロから構築し、Tierモデルの実装・Kerberoasting/DCSyncの攻撃体験・PowerShell/Hayabusaによる検知分析までを一貫して学習。スクリーンショット付き手順書・環境設定リファレンス（Excel）付き。
単体で気になる巻から始めたい方は演習コンテンツ一覧もご覧ください。
あわせてご覧ください
コメント