見出し画像

ADの多層防御メモ

吉田 晋　情報処理安全確保支援士（登録025036号）

はじめに：
本記事に書かれている内容は一つのサンプルとしてご参考ください。詳細はそれぞれの企業のシステム構成や各バージョンや運用ポリシーによって異なる可能性があります。

【１】攻撃者のAD攻略ステップ

ステップ1: 情報収集とスキャン

AD環境の構造や脆弱性を把握するための探索活動を行う。
・例: AD内の情報収集
・この段階で既知の脆弱性が見つかれば、直接攻撃へ移行。

ステップ2: 初期アクセスと認証情報の収集

低権限のアカウントや認証情報を取得。
・例: Credential Theft
・ユーザーアカウントを使って、横展開や権限昇格を模索。

ステップ3: 横展開と権限昇格

取得した認証情報を使い、特権アカウントを目指す。
・例: Privilege Escalation
・横展開ツールやPass-the-Hash/Pass-the-Ticketの手法が使われる。

ステップ4: AD内の支配

ドメイン管理者の特権を取得し、ネットワーク全体の支配を試みる。
・例: Golden TicketやDCSync攻撃
・ステップ5: ゴール達成
攻撃者の目的を実行。
・例: 機密情報の窃取やシステムの破壊

【２】ローカル管理者権限の保護

1.Credential Guardの有効化（LSASSの保護）:

Credential Guardを有効化して、LSASSプロセスからのパスワードやKerberosチケットの窃取を防止。

グループポリシーで有効化

  1. [グループポリシーエディター]を開く。

  2. [コンピューターの構成] > [管理用テンプレート] > [システム] > [Device Guard] を選択。

  3. [仮想化ベースのセキュリティ] をダブルクリックして有効化。

  4. [Credential Guard構成] で以下を選択:
    [Credential Guardを有効にする]

2.UACの強化:

ユーザーアカウント制御（UAC）の厳格な設定を適用。
下記項目をグループポリシーで設定。

管理者承認モードでの管理者アカウントの動作
→プロンプトを表示する

昇格プロンプト時にセキュリティで保護されたデスクトップを切り替える
→有効

標準ユーザーの昇格要求をプロンプトする
→プロンプトを表示する

ローカル管理者の昇格プロンプト
→プロンプトを表示する

ユーザーアカウント制御: 管理者承認モードを有効にする
→有効

【３】無効化すべきプロトコル

特に優先すべき項目（最優先）

  1. SMBv1: ランサムウェア攻撃の主要な経路で、すべての環境で無効化すべき。
    （SMBv1はランサムウェア（例: WannaCry）の主な攻撃ベクターであり、AD未導入環境でも同様のリスクがあります。ファイル共有やNAS、バックアップデバイスなどでSMBv1が使用されている場合、攻撃者が侵入して横展開を試みる際に利用される可能性が高いです。）

  2. LLMNR、NetBIOS: LAN内部での認証情報窃取を防ぐため、優先度が高い。
    （LAN内部での名前解決を狙った攻撃（認証情報の窃取、リレー攻撃）に悪用されます。AD未導入環境でも、LANを利用する限りこれらのリスクは変わりません。Responderのようなツールを使えば攻撃が簡単に実行できるため、優先的に無効化すべきです。）

  3. Telnet: 平文通信を排除し、SSHへの移行が必要。
    （Telnetの問題（平文通信）は、ADの有無に関係なくネットワーク全体で深刻なリスクをもたらします。
    」 SSHへの移行が容易な場合が多いため、優先度は常に高いです。）

  4. WEP: 無線LANの暗号化をWPA2またはWPA3に更新。
    （WEPの脆弱性は無線LAN環境に直結します。ADの有無にかかわらず、全ての環境で排除が必要です。）

  5. NTLM: AD環境でのNTLMの使用は深刻な危険性があり、攻撃者に悪用されるリスクが高いために無効化すべき。
    （Pass-the-Hash攻撃、NTLMリレー攻撃、NTLMハッシュの盗難、セッションハイジャック、NTLMのフォールバック問題、暗号化の弱さ、認証の盗聴）

早急に検討すべき項目

  1. SSL/TLS 1.0/1.1: 外部通信の暗号化方式をTLS 1.2以上に更新。
    （外部向けのウェブサービス、メールサーバー、VPNなどで利用されている場合、セキュリティを大きく損なう可能性があるため、AD未導入でも優先度は高いです。）

  2. FTP: SFTPやFTPSなど、より安全な転送プロトコルへの移行。
    （平文通信で認証情報やデータが盗まれるリスクがあるため、AD未導入環境でも代替プロトコル（SFTP/FTPS）への移行が推奨されます）

  3. SNMPv1/2c: ネットワーク監視でSNMPv3を利用。
    （SNMPの平文通信による情報漏洩やデバイスの制御リスクは、ADの有無に関係ありません。
    」 ネットワーク機器の管理にSNMPが使われている場合、SNMPv3への移行が必要です。）

  4. PPTP: VPNのセキュリティ向上を検討。
    （PPTPはVPNプロトコルとしてセキュリティが非常に弱いため、AD環境の有無を問わず代替プロトコルへの移行が望まれます。）

【４】ADの主な監視対象のログとイベントID

アカウント操作


ID:4728
特権グループ（例: Domain Admins）にユーザーが追加されるのは通常運用では稀。攻撃者が権限昇格を試みている可能性。
ID:4729
特権グループからユーザーを削除する操作は攻撃の隠蔽を目的とした不正操作の可能性がある。
ID:4756
セキュリティグループ（例: Backup OperatorsやAdministrators）に不審なユーザーが追加されるのは注意。

ディレクトリサービスの変更

ID:5136
ディレクトリサービスオブジェクト（例: GPOや特権アカウント）の変更は、攻撃者による不正な設定変更やバックドア作成の兆候。

認証プロトコルの使用

ID:4769
Kerberosサービスチケットが特定のアカウントで大量に発行されるのはKerberoasting攻撃の可能性。
ID:4776
NTLM認証試行が通常使わない端末や不審な場所から行われるのはPass-the-Hash攻撃の兆候。

サービスのインストール

ID:7045
新しいサービスのインストールは通常業務では稀であり、攻撃者がバックドアを設置する際に発生する可能性がある。

ログポリシーの変更

ID:1102
イベントログが消去されるのは、攻撃者が証拠を隠すために行う可能性が高い。

【５】ADイベントの通知設定例

1.準備

PowerShellスクリプトの作成:
・イベントログを監視してメール通知を送信するスクリプトを作成します。
SMTPサーバの確認:
・送信に使用するSMTPサーバのアドレス、ポート、認証情報（ユーザー名とパスワード）を用意します。
タスクスケジューラの設定:
・指定のイベントID発生時にスクリプトが実行されるように設定します。

2.PowerShellスクリプト

以下のスクリプトを作成して、C:\Scripts\MonitorEvents.ps1に保存します。

# --- 設定 ---
# 監視するイベントID
$EventIDs = @(4728, 4729, 4756, 5136, 4769, 4776, 7045, 1102)

# イベントログの種類
$LogName = "Security"

# メール送信の設定
$FromEmail = "alert@example.com" # 送信元メールアドレス
$ToEmail = "admin@example.com" # 管理者メールアドレス
$SMTPServer = "smtp.example.com" # SMTPサーバアドレス
$SMTPPort = 587 # SMTPポート
$SMTPUsername = "smtp_user" # SMTPユーザー名
$SMTPPassword = "smtp_password" # SMTPパスワード

# --- ログ監視 ---
# 直近の関連イベントを取得
$Events = Get-WinEvent -LogName $LogName -FilterHashtable @{Id=$EventIDs} | Select-Object -First 10

# イベントがあればメール通知
if ($Events) {
$Body = "以下の重要なイベントが検出されました:`n"
foreach ($Event in $Events) {
$Body += "EventID: $($Event.Id)`n"
$Body += "TimeCreated: $($Event.TimeCreated)`n"
$Body += "Message: $($Event.Message)`n`n"
}

# メール送信
Send-MailMessage -From $FromEmail -To $ToEmail -Subject "ADセキュリティ警告: イベントID検出" -Body $Body -SmtpServer $SMTPServer -Port $SMTPPort -Credential (New-Object System.Management.Automation.PSCredential($SMTPUsername, (ConvertTo-SecureString $SMTPPassword -AsPlainText -Force))) -UseSsl
}

3.タスクスケジューラの設定

タスクスケジューラを起動:
・「スタートメニュー」 > 「タスクスケジューラ」を検索して起動。

新しいタスクを作成:
・「タスクの作成」をクリック。
・名前: 「ADセキュリティ監視」などわかりやすい名前を指定。
・セキュリティオプション: 「最高の特権で実行する」を有効化。

トリガーの設定:
・「トリガー」タブを選択 > 「新規」をクリック。
・トリガーの種類: 「イベントで作成」を選択。
・ログ: Security
・ソース: Microsoft-Windows-Security-Auditing
・イベントID: 4728, 4729, 4756, 5136, 4769, 4776, 7045, 1102

アクションの設定:
・「アクション」タブを選択 > 「新規」をクリック。
・アクションの種類: 「プログラムの開始」を選択。
・プログラム/スクリプト: powershell.exe
・引数の追加:

-ExecutionPolicy Bypass -File "C:\Scripts\MonitorEvents.ps1"

条件と設定の確認:
・「条件」タブで「ログオンしているかどうかにかかわらず実行」を選択。
・「設定」タブで「タスクが失敗した場合に再試行」を設定（推奨: 再試行間隔1分、再試行回数3回）。

タスクを保存:
・「OK」をクリックしてタスクを保存。

4.動作確認

手動でイベントを発生させてテスト:
・イベントログの確認:

Write-EventLog -LogName Security -Source "Microsoft-Windows-Security-Auditing" -EventId 7045 -EntryType Information -Message "テストイベント"

メール通知の確認:
・管理者メールボックスに通知が届くことを確認します。

5.注意事項

SMTPサーバの設定:
社内メールサーバや外部SMTPサービス（例: Gmail）を使用する場合、認証やセキュリティ設定（MFAなど）に注意。

PowerShellの権限:
タスクスケジューラで実行されるスクリプトには、必要な権限があることを確認。

スクリプトの保護:
スクリプトは読み取り専用に設定し、アクセス権を制限します。

ログのレビュー:
スクリプトが適切に実行されているか、タスクスケジューラの履歴やイベントログで定期的に確認。

【５】ADの必要ポート（●は必要最小限ポート）

以下のポート以外は閉じることを検討推奨。

●53 TCP/UDP DNS ドメイン名解決
●88 TCP/UDP Kerberos 認証
●389 TCP/UDP LDAP ディレクトリサービスアクセス
●445 TCP SMB ファイル共有、プリンタ共有
636 TCP LDAPS 暗号化されたLDAP
3268 TCP LDAP GC グローバルカタログサービス
3269 TCP LDAP GC SSL 暗号化されたグローバルカタログサービス
●135 TCP/UDP RPC リモートプロシージャコール
137 UDP NetBIOS-ns NetBIOS名前解決
138 UDP NetBIOS-dgm NetBIOSデータグラム
139 TCP NetBIOS-ssn NetBIOSセッション

積極的に閉じることが推奨されるポート

・HTTP/FTPサーバ機能
・ファイル共有FTP、Telnet、NFS
・不要なリモートアクセスTelnet、（RDP管理端末のみ）
・プリントサービス（Print Spooler）

【６】脆弱プロトコルの無効化ステップ

システム部が特に難色を示しそうな項目は、以下の3つです

NTLM：
Kerberos移行の工数や既存アプリケーションの互換性が問題になる）

SMBv1：
古いNASやバックアップ機器などへの依存が多い

SNMPv1/2c：
ネットワーク監視の一斉変更が必要になる

1.NTLMからKerberosへの移行

1.1 使用状況の特定
ツール:
Active Directory監査機能やSIEM（例: Splunk、Microsoft Sentinel）でNTLMを使用しているシステムやクライアントを特定。
イベントログ（ID 4624、4648）でNTLM認証が行われている箇所を確認。
ポイント:
どのシステムやアプリケーションがNTLMに依存しているかリスト化。
Kerberosが使えないケース（クロスフォレスト、信頼関係の設定不備）を把握。
1.2 段階的な移行
移行ステップ:
1. まず、内部システム（例: ファイル共有、プリンタ）でKerberosに切り替える。
2. 次に、業務アプリケーションやデータベースでKerberosのテストを実施。
3. Kerberosが動作しないケースを特定し、解決策を検討。
1.3 フォールバックの管理
NTLMを即座に無効化せず、段階的に制限する:
グループポリシーを設定して「NTLMの使用を監査モードに変更し、依存箇所を監視。
最終的に「拒否に変更。
1.4 Kerberosインフラの強化
DNSの正確な設定:
KerberosはDNSに依存するため、名前解決が適切に機能するよう整備。
SPN（Service Principal Name）の設定:
各サービスのSPNを登録し、Kerberos認証が成功するよう調整。

2.SMBv1の無効化と移行

2.1 使用システムの特定
ツール:
ネットワークスキャンツール（例: Nmap）やWindowsイベントログでSMBv1を使用しているシステムを特定。
SMBクライアントとサーバーのログでSMBプロトコルのバージョンを確認。
ポイント:
古いNAS、バックアップシステム、プリンタがSMBv1に依存している場合が多い。
2.2 段階的な無効化
移行ステップ:
1. サーバー側のSMBv1を無効化:
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
2. クライアント側での依存性を検証。
3. 完全に移行できたら、クライアント側でもSMBv1を無効化。
2.3 代替プロトコルへの移行
移行先:
SMBv2/3:
最新のWindowsバージョンや対応NASではSMBv3が推奨。
別プロトコル:
非SMBベースのファイル転送（SFTPやHTTPSなど）も検討。
2.4 古いデバイスの更新計画
SMBv2/3をサポートしないNASやプリンタは、計画的に新しいデバイスに置き換える。
一時的な対応として、古いNASを隔離ネットワークで運用する。

3.SNMPv1/2cからSNMPv3への移行

3.1 使用状況の把握
ツール:
ネットワーク管理ツール（例: SolarWinds、Nagios）でSNMPv1/v2cを使用しているデバイスを特定。
ポイント:
ネットワーク機器（ルータ、スイッチ、アクセスポイント）が対象。
一部のIoTデバイスもSNMPに依存。
3.2 移行準備
デバイス対応の確認:
SNMPv3をサポートしているか確認し、設定手順を入手。
古いデバイスでSNMPv3に対応していない場合、更新計画を立てる。
監視システムの対応:
監視ツールがSNMPv3に対応していることを確認。
SNMPv3の設定を反映。
3.3 設定変更の段階的実施
移行ステップ:
1. SNMPv3を有効化し、既存のSNMPv1/2cと並行稼働。
2. SNMPv3に対応する監視設定を移行。
3. 問題が解決したらSNMPv1/2cを無効化。
3.4 運用変更
SNMPv3の強化設定:
暗号化と認証を必須に設定（例: AES-128とSHA）。
共通コミュニティ名（public/private）を排除。

共通のベストプラクティス

  1. 現状の可視化
    監査やログを活用して、現在どこで古いプロトコルが使用されているか特定。
    ネットワークマップや依存リストを作成。

  2. 段階的な移行
    一斉移行はリスクが高いため、影響範囲を限定したテスト移行から始める。
    問題が発生した場合にすぐに元の状態に戻せるよう、ロールバック計画を用意。

  3. 利用者や関係者への説明
    利用者（業務部門）に対して変更理由を説明し、納得を得る。
    「移行に失敗すると影響が大きいという懸念を払拭するため、事前テスト結果や移行計画を共有。

  4. テスト環境での検証
    移行前にテスト環境を用意し、依存するシステムやアプリケーションが正常に動作することを確認。
    移行ツールや設定変更が予期しない影響を与えないかを事前に検証。

  5. ログと監視の強化
    移行後の動作をモニタリングして、不具合やパフォーマンス問題がないか監視。
    問題が発生した場合、即座に対応できる体制を整備。

まとめ：移行の優先順位

  1. NTLM: Kerberosへの段階的な移行が必要。

  2. SMBv1: SMBv2/3対応デバイスへの移行、レガシーシステムの更新計画。

  3. SNMPv1/2c: SNMPv3への移行とネットワーク監視ツールの設定変更。
    成功のためのポイント
    現状の依存箇所を正確に把握し、段階的かつ安全な移行を計画する。
    テスト環境での検証を十分に行い、移行による業務影響を最小化する。
    関係者に事前に移行計画を共有し、リスクとメリットを明確化して合意を得る。
    これらを実行することで、移行の負担を軽減し、セキュリティを向上させることが可能です。


いいなと思ったら応援しよう！