AD攻撃手法と要塞化｜Pass-the-Hash・Kerberoasting・GoldenTicket・DCSyncを理解して守る

「ADの設定は一通りできてます」——では、Pass-the-Hashで横展開されたとき、どこで止めますか？

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つの攻撃手法

4つの中で影響範囲が最も大きいのがGoldenTicketとDCSyncです。どちらもドメイン全体の掌握につながるため、特に優先度の高い対策が必要です。

参考：Active Directoryをセキュリティで保護するためのベスト プラクティス | Microsoft Learn

Pass-the-Hash——パスワードを知らなくても侵入できる

攻撃の仕組み——ハッシュ値がなぜ危険なのか

NTLMハッシュ（NTLM Hash） Windowsがパスワードを保存・認証に使用するハッシュ値。NTLMプロトコルの認証ではパスワードの平文ではなくこのハッシュ値を使うため、ハッシュ値さえ入手すれば平文を知らなくても認証を突破できる。

WindowsのNTLM認証は「パスワードのハッシュ値」を使って認証します。平文パスワードは使いません。これは盗聴対策として設計された仕組みですが、逆に「ハッシュ値を盗めばパスワードを知らなくても認証できる」という弱点を生んでいます。

攻撃の流れはシンプルです。

1. 攻撃者がマルウェア等で一般PCを侵害する
2. LSASS（認証情報を管理するWindowsプロセス）からNTLMハッシュを抽出する
3. 抽出したハッシュを使って他のサーバへ認証を試みる
4. 同じ資格情報が有効なサーバへ次々と侵入する（横展開）

LSASS（Local Security Authority Subsystem Service） Windowsの認証を管理するプロセス。ログオン中のユーザーの資格情報をメモリ上にキャッシュしており、攻撃ツール（Mimikatzなど）による抽出の標的になりやすい。

現場で起きること——どう広がるか

現場での典型的なシナリオは「一般PCの侵害から始まりDCに到達する」流れです。特にDomain Adminsアカウントで一般PCにログインしたことがある環境では、そのPCにハッシュが残っているため、そのPCを起点にドメイン全体が危険にさらされます。

特権アカウントを一般PCで使うリスクについては「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」で解説しています。

対策——資格情報キャッシュを減らす設計

Credential Guard（資格情報ガード） Windows仮想化ベースのセキュリティ機能。LSASSを隔離された環境で動作させることで、資格情報の抽出ツールによるハッシュ盗取を防ぐ。

参考：Credential Guard の概要 | Microsoft Learn

Kerberoasting——サービスアカウントを狙うオフライン攻撃

攻撃の仕組み——チケットを持ち帰ってクラックする

SPN（Service Principal Name：サービスプリンシパル名） ADにおいてサービスを一意に識別する識別子。Kerberosはこの識別子を使ってサービス向けのチケット（TGS）を発行する。SPNが設定されたアカウントはKerberoastingの標的になりうる。

Kerberosでは、ユーザーがサービスにアクセスするときに「サービスチケット（TGS）」を取得します。このTGSはサービスアカウントのNTLMハッシュで暗号化されています。

Kerberoastingの手順はシンプルです。

1. ドメインユーザー（一般権限で十分）がSPNを持つサービスアカウント向けのTGSを正規に要求する
2. 取得したTGSをネットワーク上には送らず、ローカルに持ち帰る
3. オフラインでパスワードクラックツールを使いTGSを解読する
4. サービスアカウントのパスワードを復元し、そのアカウントで侵入する

TGS（Ticket Granting Service：サービス許可チケット） Kerberosで特定のサービスへのアクセスに使用するチケット。サービスアカウントのハッシュで暗号化されており、オフラインクラックの対象になる。

この攻撃の特徴はネットワーク上に不審な通信が発生しないことです。チケットの取得は正規の操作なので、ログを見ても気づきにくい。

現場で起きること——弱いパスワードのサービスアカウントが標的になる

サービスアカウントは「人が使わない」ため、パスワードを設定したまま何年も変更されないケースが多くあります。弱いパスワードのサービスアカウントは数分〜数時間でクラックされます。サービスアカウントの設計については「サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド」で詳しく解説しています。

対策——SPNとパスワード管理の強化

gMSA（group Managed Service Account：グループ管理サービスアカウント） ADが自動でパスワードを生成・ローテーションするサービスアカウント。複数サーバで共有できるため、Kerberoasting対策として推奨される。

参考：グループ管理サービスアカウントの概要 | Microsoft Learn

GoldenTicket——DCを制した攻撃者が作る「偽造パスポート」

攻撃の仕組み——KRBTGTハッシュの悪用

KRBTGTアカウント ドメイン内のKerberos認証に使用される特殊なサービスアカウント。このアカウントのハッシュ値はKerberosチケット（TGT）の署名に使われるため、流出するとドメイン内の任意のチケットを偽造できる。

Kerberosの認証チケット（TGT）は、KRBTGTアカウントのハッシュ値で署名されています。攻撃者がこのハッシュ値を入手すると、有効期限・権限・ユーザー名を自由に設定した**偽造TGT（GoldenTicket）**を作成できます。

GoldenTicketを持つ攻撃者は、存在しないユーザーとして、あるいは任意の管理者として、ドメイン内のどのリソースにもアクセスできます。

現場で起きること——発覚しにくい長期潜伏

GoldenTicketの最大の危険性は発覚しにくさです。正規のKerberosチケットと見分けがつかないため、ログを見ても「正常な認証」として記録されます。KRBTGTのパスワードを変更しない限り、作成されたGoldenTicketは理論上何年でも有効です。

実際のインシデントでは、侵害が発覚した後に「数か月前からGoldenTicketで侵入されていた」ことが判明するケースがあります。

対策——KRBTGTパスワードの定期リセット

KRBTGTパスワードは2回連続でリセットする必要があります（古いハッシュを完全に無効化するため）。リセット手順はMicrosoftが提供するスクリプトを使用することを推奨します。

参考：KRBTGT アカウントのパスワードをリセットする | Microsoft Learn

DCSync——DCになりすましてハッシュを根こそぎ奪う

攻撃の仕組み——レプリケーション権限の悪用

DCレプリケーション（Directory Replication） 複数のDC間でADデータベースを同期する仕組み。この権限を持つアカウントはDCに接触せずにアカウント情報（ハッシュ値を含む）を取得できる。

ADには複数のDCが存在する環境のため、DCどうしがお互いにデータを同期（レプリケーション）する仕組みがあります。DCSyncはこの仕組みを悪用します。

1. 攻撃者がレプリケーション権限（Replicating Directory Changes All）を持つアカウントを入手する
2. DCに対して「別のDCとしてデータを同期したい」というリクエストを送る
3. DCは正規のレプリケーションと判断し、要求されたアカウントのハッシュを返す
4. ドメイン内の全アカウント（KRBTGTを含む）のハッシュを取得する

この攻撃はDCへの直接ログインが不要です。レプリケーション権限を持つアカウントがあれば、ネットワーク経由でリモートから実行できます。

現場で起きること——静かに全アカウントのハッシュが流出する

DCSyncが成功すると、攻撃者はドメイン内の全アカウントのNTLMハッシュとKRBTGTハッシュを入手します。これ以降、Pass-the-HashもGoldenTicketも自由に使えます。

問題は「気づきにくい」ことです。レプリケーション要求は通常業務でも発生するため、監視設定がないと見逃します。イベントログでの検知方法については「ADイベントログ監査」で解説した4662（ディレクトリサービスのアクセス）が手がかりになります。

対策——レプリケーション権限の棚卸しと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でサービスアカウントのパスワードを自動管理する——これらはすべて「盗める資格情報を減らす」設計です。

Tierモデル・PAWの実務設計については「AD特権アカウントの設計」を参照してください。

② 侵害が広がる前に検知する GoldenTicketは「侵害後に長期潜伏される」攻撃です。DCへのアクセスをログで監視し、KRBTGTパスワードを定期リセットすることで、潜伏期間を最小化できます。ログ監視の設計については「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の正規の仕組みを悪用している」という点です。これらは脆弱性ではなく仕様である以上、パッチを当てて終わりにはなりません。仕組みを理解した上で、露出面を減らし・検知できる状態を作り・被害範囲を限定するという設計の積み重ねが唯一の答えです。

今日確認すべきことは1つです。ドメイン内でSPNが設定されているサービスアカウントを確認し、パスワードが適切に管理されているかを見てください。

# SPNが設定されているサービスアカウントの一覧表示
Get-ADUser -Filter {ServicePrincipalName -ne "$null"}　

弱いパスワードのサービスアカウントは今すぐKerberoastingの標的になりえます。

次のステップは、オンプレADとEntra IDを連携させたハイブリッド構成の設計です。「Entra IDとオンプレAD連携」で、クラウド時代のADセキュリティ設計を解説します。

あわせてご覧ください

• Active Directoryとは？Windows認証基盤の仕組みと設計の基本
• AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
• ADイベントログ監査｜正常・異常の見分け方と攻撃の兆候を追う実務ガイド
• サービスアカウントの権限設計｜最小権限を守るためのパターンと実務ガイド
• 最小権限の原則とは？実務での考え方と設計例
• MFAとは？多要素認証の仕組みと実務での導入・運用ガイド