Active Directoryログ — 何を集め、何を見て、何をアラートにするか
Active Directoryのログ収集で集めるべきEvent IDと検知ルールを、Microsoft公式ドキュメントに沿って実務向けに解説します。
タイの組織で稼働しているDomain Controllerの多くは、Windowsをインストールしたときの監査設定のままです。そこから一度も見直されていない、というケースが珍しくありません。困るのは実際に何かが起きたときです。役員のアカウントが深夜3時に使われていた、申請のないユーザーがDomain Adminsに入っていた——調べようとしても遡れません。必要なイベントが、そもそも記録される設定になっていなかったからです。
なぜActive Directoryのログが重要なのか
2024年9月、5か国6機関のサイバーセキュリティ機関——オーストラリアのASD ACSCを中心に、米国のCISAとNSA、カナダのCanadian Centre for Cyber Security、英国のNCSC、ニュージーランドのNCSC——が共同文書 Detecting and Mitigating Active Directory Compromises を公表しました。ADに対する攻撃手法を17件まとめたものです。文書の立場ははっきりしています。攻撃者は権限昇格と、機密性の高いユーザーオブジェクトの奪取を狙って、日常的にADを標的にしている、というものです。
構造を考えれば当然でもあります。ADはドメイン内すべての端末のアカウント、権限、ポリシーを一箇所で保持しています。Domain Adminを1つ取られた時点で、全端末を取られたのと同じ状態になります。同じ文書でも、攻撃者の目標はドメインを掌握できる水準まで権限を上げることだと説明されています。Domain Adminを握った状態は、全端末に同時に何かを配布できる状態でもあります。
もう一つは法令面です。タイのコンピュータ犯罪法（B.E. 2550〔2007年〕、2560年改正）第26条は、サービス提供者に対し、コンピュータトラフィックデータを90日以上保存することを求めています。ADのログオン／ログオフのログが保存対象に含まれるかどうかは、2021年告示の付属書Bでサービス提供者の種類ごとに定められています（要件の詳細はコンピュータ犯罪法のログ保存ガイドにまとめてあります）。ただし90日はあくまで法令上の下限で、調査に必要な期間として決められた数字ではありません。
収集すべきEvent ID
下の表はWindowsの監査カテゴリ単位で並べてあります。後述の「ADログをSIEMへ送る方法」に出てくる auditpol の一行と、そのままグループが対応するためです。該当するカテゴリを有効にしていなければ、そのグループのイベントは一件も発生しません。
「意味」の列は、Microsoftのドキュメントで実際に使われている名称をそのまま載せています。独自の訳語を当てていないので、そのまま検索すれば一次情報にたどり着けます。
Logon/Logoff グループ — 誰が、どの端末に、いつ入ったか
| Event ID | 意味 | 重要度 | 併せて見るもの |
|---|
| 4624 | An account was successfully logged on | 高 | Logon Type — 2 = 対話ログオン（Interactive）、3 = ネットワークログオン（Network）、10 = リモート対話ログオン（RemoteInteractive／RDP） |
| 4625 | An account failed to log on | 最高 | Status / Sub Status code |
| 4634 | An account was logged off（セッション終了） | 中 | 4647（利用者自身のログオフ操作）と対。両方出るのが普通 |
| 4648 | A logon was attempted using explicit credentials | 中 | アラートを組む前にベースラインが必要 |
| 4672 | Special privileges assigned to new logon | 高（条件付き） | Subject\Security ID |
表だけでは伝わらない点が3つあり、これらがルールの誤検知の原因になります。
4624にIPが必ず入っているとは限りません。 IPアドレス／ポートとワークステーション名（Workstation Name）のフィールドが埋まるかどうかは、認証のコンテキストと使用プロトコル次第だとMicrosoftが明記しています。Kerberosを使うネットワークログオンではワークステーション名が入らないことが多く、NTLMログオンではTCP/IPの情報が落ちます。「同一IPからの回数を数える」タイプのルールを書くなら、先に知っておくべき前提です。
4634に「失敗」版はありません。 「ログオフ成功」と説明している記事を見かけますが、正確ではありません。このイベントが示すのは、ログオンセッションが終了してもう存在しない、それだけです。
4672は想像よりずっと大量に出ます。 新しいセッションに13種類の機微な権限（sensitive privilege — SeDebugPrivilege、SeTcbPrivilege、SeBackupPrivilegeなど）のいずれかが付与されたログオン時に発生します。SYSTEMアカウントがログオンするたびに発生するため大量に記録される、とMicrosoft自身が書いています。推奨されている運用は、Subject\Security ID がLOCAL SYSTEM、NETWORK SERVICE、LOCAL SERVICEのいずれでもない場合に限ってアラートを上げる方法です。フィルタなしで設定すると、1週間でチームがこのルールを止めます。
Account Management グループ — アカウントと権限グループを誰が変えたか
| Event ID | 意味 | 重要度 |
|---|
| 4720 | A user account was created | 高 |
| 4722 | A user account was enabled（computerオブジェクトも対象） | 高 |
| 4723 | An attempt was made to change an account's password（利用者本人による変更） | 中 |
| 4724 | An attempt was made to reset an account's password（管理者による他人のリセット） | 高 |
| 4725 | A user account was disabled | 高 |
| 4726 | A user account was deleted | 最高 |
| 4740 | A user account was locked out | 高 — Caller Computer Nameフィールドを見る |
| 4728 | A member was added to a security-enabled global group（Domain Adminsなど） | 最高 |
| 4732 | A member was added to a security-enabled local group（DC上ではdomain-local。Builtin\Administrators、Account Operatorsなど） | 最高 |
| 4756 | A member was added to a security-enabled universal group（Enterprise Admins、Schema Adminsなど） | 最高 |
この表で最も間違いが多いのが4728／4732／4756です。4728を「セキュリティグループへのメンバー追加」とだけ書いてある解説をよく見かけますが、これでは曖昧すぎて運用に使えません。3つともセキュリティグループである点は同じで、分かれているのはグループのスコープです。順にglobal、domain-local、universalに対応します（Audit Security Group Managementのページに記載）。
結果として、4728だけを監視しているとDomain Adminsに追加された人は見えますが、Enterprise AdminsとSchema Admins（universal → 4756）が見えません。DC上の Builtin\Administrators（domain-local → 4732）も見えません。どちらも同じく最上位権限への経路です。
もう一点、4740は名前からするとサブカテゴリ「Audit Account Lockout」に属していそうですが、実際はAudit User Account Managementの中にあります。逆にAccount Lockoutというサブカテゴリに入っているのは4625です。サブカテゴリ単位で監査を有効にする場合は、この入れ替わりに注意してください。
Account Logon グループ — 主にDomain Controller上で発生
| Event ID | 意味 | 重要度 |
|---|
| 4776 | The computer attempted to validate the credentials for an account（NTLM） | 高 — Error Codeを見る |
| 4771 | Kerberos pre-authentication failed | 最高 — Failure Codeを見る |
| 4769 | A Kerberos service ticket was requested | 中 — 元々の発生量が非常に多い |
4769と4771はDomain Controllerでしか発生しません。4776だけは少し違って、記録されるのはその資格情報を保持している側です。ドメインアカウントならDCですが、ローカルアカウントならその端末自身になります。メンバーサーバー上のローカルアカウントを狙った攻撃を見たい場合は、DC以外からも4776を集める必要があります。
AD関連の記事で最も抜け落ちやすいのがこのグループです。そして実運用のドメインでブルートフォースを検知するなら、いちばん必要になるのもここです。
4625はDCで発生するとは限りません。 4625はログオンが試行された端末側で記録される、とMicrosoftは説明しています。したがってドメインアカウントがKerberosで失敗した場合、DCに出るのは4771です。NTLM側なら、Error Codeが0x0以外の4776になります。ブルートフォースのルールを4625だけで組んでDCに向けているなら、監視すべきイベントを取り違えています。
実際に使えるコードを見ておきます。以下はNTLM側——4776のError Code、および端末側で記録される4625のSub Status——のコードです。0xC0000064 はそのユーザー名が存在しない（アカウント名を総当たりで探している）、0xC000006A はユーザー名は正しくパスワードが違う（ブルートフォースまたはパスワードスプレー）、0xC0000234 はアカウントがロック中です。Kerberos側の4771は体系が別で、RFC 4120のFailure Codeを使います。事前認証の失敗が 0x18（KDC_ERR_PREAUTH_FAILED。多くはパスワード誤りですが、それだけではありません）、該当ユーザーが存在しないケースが 0x6（KDC_ERR_C_PRINCIPAL_UNKNOWN）です。
4776には知っておくべき制約がもう2つあります。 ドメインアカウントがDCに直接ログオンした場合には発生しません。また、記録されるのは送信元のワークステーション名（Source Workstation）だけで、IPも宛先も入りません。
設定すべきアラート5種
以下のルールは特定のSIEM製品に依存しない書き方にしてあります。イベントの相関ができる製品ならどれでも組めます（SIEMとログ管理の違いに自信がなければ、先にSIEMとは何かを読んでおくと理解が早くなります）。
先にルール本体より大事な話を一つ。以下のしきい値はすべて出発点の数字です。標準値ではありません。 最低2週間は監視モードで動かしてベースラインを取ってから、夜間に担当者を呼び出すアラートに昇格させてください。バッチ処理が多い組織とそうでない組織では、妥当な数字が桁違いに変わります。
1. 単一アカウントへのブルートフォース
Rule (Kerberos): 同一target accountに対する 4771 Failure Code = 0x18 が 5分間に10回超
Rule (NTLM): 同一target accountに対する 4776 Error Code = 0xC000006A が 5分間に10回超
Correlate: 4771 は Client Address（IPv4/IPv6。::1 はDCローカル）で集計する
4776 は IP を持たないので Source Workstation（送信元コンピューター名）で代替する
どちらも取れない場合は target account + code で集計する
Microsoftは4771のドキュメント上で、Failure Code 0x18が短時間に繰り返し発生する場合はブルートフォースの兆候であり、特に重要度の高いアカウントで注意すべきだと述べています。
2. 新しい管理者アカウントの出現
Rule: 4720（ユーザー作成）に続いて 1時間以内に 4728 または 4732 または 4756
追加先グループが高権限グループのウォッチリストに含まれること
ウォッチリストの最低ライン: Domain Admins, Enterprise Admins, Schema Admins,
Builtin\Administrators, Account Operators, Backup Operators
3つすべてを条件に入れる理由は、前述のグループスコープにあります。4720 + 4728しか見ないルールは、フォレストレベルの権限に至る3つの経路のうち2つを取りこぼします。
3. 業務時間外のログオン
Rule: 22:00〜06:00 の 4624
必ず先にフィルタする:
- Logon Type 2（対話ログオン）と 10（リモート対話ログオン／RDP）だけを対象にする
- マシンアカウント（名前が $ で終わるもの）を除外する
- SYSTEM、NETWORK SERVICE、LOCAL SERVICE を除外する
このフィルタ3つを入れないと、バックアップジョブ、スケジュールタスク、サービスに対して毎晩アラートが飛び、誰も読まなくなります。忘れられがちな点がもう一つあって、この時間帯はDCのシステム時刻とタイムゾーンで評価されます。海外拠点や時差のあるチームを抱えている組織は、設定前に検討が必要です。
4. パスワードスプレー
Rule: 4771（0x18）または 4776（0xC000006A）が、重複しないtarget account
15件以上に対して 30〜60分の時間枠で発生
別ルール（アカウント名の列挙）:
NTLM は 4776 Error Code = 0xC0000064
Kerberos は 4771 Failure Code = 0x6（KDC_ERR_C_PRINCIPAL_UNKNOWN）
ネット上でよく見かける1分の時間枠は狭すぎます。パスワードスプレーはロックアウトポリシーに引っかからないよう意図的にゆっくり実行され、攻撃側は1アカウントにつき1回だけ試して待ちます。数えるべきなのは重複しないアカウント数です。総試行回数を見ても、この攻撃の特徴は浮かび上がりません。
5. Kerberoasting
Rule: 4769 のうち、以下3条件をすべて満たすもの
1) Ticket Encryption Type が 0x11 でも 0x12 でもない（＝AESではない）。0x17 は RC4-HMAC
2) Service Name が SPNを持つ user account（$ で終わる computer account ではない）
3) 単一アカウントが短時間に重複しない複数の Service Name を要求している
AD記事でいちばん間違って書かれているのがこのルールです。よく見る書き方は「4769の発生量が異常に多い」ですが、これは使えません。4769はKDCがサービスチケットの要求を受け取るたびに発生し、Microsoftのドキュメントもこのサブカテゴリのイベント量を「KDCサーバー上ではVery High」と分類しています。発生量ベースのルールは、全員が一斉にログオンする月曜の朝に鳴り、パッチ適用後の再起動でもう一度鳴ります。
正直に言うと、条件1は優先順位付けの材料にとどまります。これだけで断定はできません。攻撃者はAESを要求することもできますし、RC4を有効にしたままの環境には条件に合致する正常なRC4トラフィックも存在します。このルールを実用に耐えるものにしているのは条件2と3のほうです。
最近変わった点も一つ。Windows Server 2016以降で2025年1月14日以降のSecurity Cumulative Updateを適用している環境では、4769にClientAdvertizedEncryptionTypes、ServiceSupportedEncryptionTypes、SessionKeyEncryptionTypeといったフィールドが追加されます。ここまで来ると、はるかに鋭い条件が書けます——クライアントはAES対応を提示したのに、発行されたチケットはRC4だった。暗号化タイプを単体で見るより、実際の指標にずっと近い形です。
最後に、4769のログを実際に眺めるとFailure Code 0x20が大量に見つかります。これはサービスチケットの期限切れを意味していて、Microsoft自身が情報提供目的のメッセージでセキュリティ上の意味はほとんどないと明記しています。入口の段階で落として構いません。
ADログをSIEMへ送る方法
ステップ1: Domain Controllerで監査ポリシーを有効にする
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Management" /success:enable /failure:enable
auditpol /set /category:"Account Logon" /success:enable /failure:enable
この3行で、上の3つの表に出てくるEvent IDはすべてカバーされます。取りこぼしはありません。Kerberoastingのルールが使う4769も含まれていて、3行目（サブカテゴリ Audit Kerberos Service Ticket Operations）から入ってきます。コマンドの書式とカテゴリ名は、Microsoftのドキュメントに記載されているとおりです。
実機に打ち込む前に押さえておきたい点が4つあります。
/category: は投網のように大雑把な道具です。 Logon/Logoffをカテゴリごと有効にすると、Audit IPsec Main Mode、Quick Mode、Extended Mode、Network Policy Server、Group Membershipまで一緒に有効になり、必要なイベントの数をはるかに超えます。ピンポイントで絞るなら /subcategory: を使いますが、上の表が参照しているサブカテゴリを漏れなく有効にする必要があります。Logon/Logoffのグループだけでも、Logon、Logoff、Special Logon、Account Lockoutの4つが要ります。"Logon" だけを有効にすると、4634と4672、そしてロックアウト側の4625が消えます。この作業に余分にかかるのは数分ですが、負荷の高いDCでは、チームが面倒を見られる量のログと、膨れ上がるライセンス費用との分かれ目になります。
Account Managementへの /failure:enable は、グループ関連のイベントに関してはほとんど意味がありません。 Audit Security Group Managementのページで、このサブカテゴリにはFailureイベントが存在しないためfailure auditingの有効化は推奨しない、とMicrosoftが明記しています。
いちばん高くつくのは3行目です。 Microsoftが示しているイベント量の評価は、Audit Security Group Management = Low、Audit Logon = クライアントでLow・DCやネットワークサーバーでMedium、そしてAudit Kerberos Service Ticket Operations = KDCサーバー上でVery High です。ストレージとEPSの見積もりは、最初からここを織り込んでおいてください。
auditpolが書き込むのはローカルポリシーです。 組織がGroup Policy（Advanced Audit Policy Configuration）で管理している場合、次のGPO更新で打ち込んだ設定は上書きされます。検証機以外ではGPO経由で設定してください。監査がひとりでに消えた理由を後から探す羽目にならずに済みます。
ステップ2: Windowsからイベントを取り出す方法を選ぶ
Windowsは自力でsyslogを送りません。現実的な選択肢は2つです。
端末にエージェント／フォワーダーを入れる — よく使われるのはNXLog、winlogbeat、あるいはSIEM製品自身のエージェントです。Windows Event Logを読み、syslogとしてcollectorへ直接送ります。
WEC／WEFを使う — Windows Event CollectorとWindows Event ForwardingはWindows標準の仕組みで、各端末のイベントを1台のWindows collectorに集約できます。全台にエージェントを入れずに済むのが利点です。注意点として、WEFで届くのはWindows collectorまでです。syslogを受けるSIEMへ渡すには、そのcollector上にもう一段フォワーダーが必要になります。
ステップ3: 保存期間は法令の下限より長めに取る
90日は通信記録の通常の最低保存期間です(担当官の個別命令で延長される場合があり、告示にはほかの要件もあります)。ただし調査の側から見ると、侵入の最初の一歩は最初に気づいた事象よりさらに前にあるのが普通です。そして、保存していないものは遡れません。だから認証ログだけは法令の下限より長く——たとえば365日——取っておく、という判断になります。
zcrLogの保持期間は1日から最長10年まで設定でき、必要な期間に合わせて構成します。ただし公開されているSaaSプランと仮想アプライアンスプランは、いずれも90日保管が既定です。365日規模で持つ場合はストレージ込みの構成になるので、料金ページの各プランと必要な容量を突き合わせて確認してください。
zcrLogとActive Directory — 実際にできること
ここで挙げるSystem LogsとLog Ingestionの画面については、zcrLogの製品ページで詳しく解説しています。
Domain Controllerを含むWindowsのイベントはSystem Logsに入り、フィールドに分解された状態で届きます。 Log ViewerのSystem LogsタブにはSource Type列があるので、Windowsのイベントとsyslogで届くファイアウォールのログが同じ画面に混ざっていても切り分けられます。Windowsの行なら、Event ID・送信元ホスト・ユーザー・プロトコルがそれぞれ別の列に収まります。Domain Controllerのホスト名は行の値として出るだけでなく、Source Deviceのフィルタ候補としてもそのまま選べます。
AD運用に直接効く列は、Event、User、Source Hostname、Protocol、Severity、Severity Score、Risk Score、Risk Level、Actionあたりです。フィルタはUsername、Event ID、Source Device、Source IP/Hostname、Protocol、Severityで絞り込めるので、「このアカウントがその時間帯に何をしていたか」を追う作業には足ります。ステータス行には名前解決済みのhostname数とマッピング済みデバイス数が表示され、時刻はAsia/Bangkokで表示されます。時間範囲は5分から24時間、加えてカスタム指定が選べ、auto-refreshとLiveモードもあります。
クラウド側のID基盤（Entra ID）は独立したタブです。 Log Viewer内にMicrosoft Entra IDの専用タブがあり、Audit LogsとSign-in Logsに分かれています。Sync Nowボタンがあり、Category、Status、Actor Email、Target Typeでフィルタできます。Log Ingestion → Custom Integrationsには、Microsoft Entra IDとSentinelOneが用意されています（この側の設定手順はMicrosoft Entra IDのログ収集にまとめてあります）。また、zcrLogはOffice 365 Management API経由で、Microsoft 365（Exchange、SharePoint、Teams）の監査ログも収集します。AWS CloudTrail、Google Cloud監査ログ、CrowdStrike Falconのログも収集できます。
はっきり書いておくべき制約もあります。 オンプレミスのADについては、Entra IDにあるようなワンクリックのインテグレーションカードはまだありません。Windowsイベントの取り込みは、ステップ2で書いたsyslogまたはエージェントによるフォワーディングの作業になります。Source Configurationでsyslogを受けるとき、FortinetとPalo Altoについては送信元の種別が自動で判別されます。Windowsはログストリーム内のSource Typeとして現れていて、インテグレーションカードとしては存在していません。複数のSIEMを比較検討中なら、同じ質問を各社にぶつけてみてください。オンプレミスのADとEntra IDの両方をまとめて「AD対応」と呼んでいるベンダーは少なくありません。
zcrLogの料金とプランを見る →
お問い合わせ
現在の監査ポリシーと保存期間で足りているかどうか、一度見てほしいという相談も歓迎です。
参考資料
