bitbank techblog

ADサーバのイベントログをSumo Logicで分析してみた

これは ビットバンク株式会社 Advent Calendar 2020 の 10 日目の記事です。

はじめに

はじめまして。ビットバンクでセキュリティを担当していますThymです。

ビットバンクでのセキュリティチームでは様々なモニタリングを実施していますが、今回はADサーバのイベントログ監視についてご紹介いたします。

モニタリング環境

ビットバンクでは、ログモニタリングをする環境として、Sumo Logicを導入しています。このサービスは、SaaS型のログ分析ツールです。ビットバンクではこのSumo Logicを利用して様々なログ分析を行なっています。
詳しい導入の経緯等は参考のケーススタディをご覧ください。

参考:https://www.sumologic.jp/case-study/bitbank/

ADサーバのログモニタリングと言っても様々な観点がありますが、今回はADサーバへどのようなログオンがあり、またログオンの失敗がないかを確認しようと思います。
これをSumo Logicを使って確認するための一連の流れについてご紹介します。

ADサーバでのイベントログをSumo Logicで確認するためには、まず、ADサーバ上でイベントログを正しく出力するための設定が必要です。

まずは、イベントログを取得しようとするホストにて、auditpol コマンドを実行し、現在の設定を確認します。

auditpol /get /category:*

下記の箇所を確認し、ログが出力されるように設定を変更します。

  • ログオン/ログオフ
    • 特殊なログオン →成功および失敗
  • オブジェクト アクセス
    • 証明書サービス →成功および失敗
      その他のオブジェクト アクセス イベント →成功および失敗
  • 特権の使用
    • 重要な特権の使用 →成功および失敗
  • アカウント管理
    • セキュリティ グループ管理 →成功および失敗
  • アカウント ログオン
    • Kerberos サービス チケット操作 →成功および失敗
    • 資格情報の確認 →成功および失敗

参考: ログを活用したActive Directoryに対する攻撃の検知と対策,P62Appendix E) イベントログを記録するための監査ポリシーの設定

出力されたイベントログをSumo Logicへ取り込む

ビットバンクではADの設置場所としてAWSを採用しています。
そのため上記の設定で出力されてイベントログをCloudWatchLogsへ連携し、Sumo Logicへ取り込みます。
細かい設定方法は割愛しますが、下記 sourceCategory でイベントログが貯まるように設定しました。

中略/WindowsServer/EventLog/Security

参考:CloudWatchで監視するWindowsイベントログ

Sumo Logicへ取り込んだイベントログをLogReduceする

上記の作業でSumo Logic上にイベントログが取り込まれましたが、これだけでは、検索、分析、確認といった作業ができません。

1-3

↑取り込んだ直後は項目の選択肢もなく、検索や分析、確認が行えない。。

そのため、ログの構造を把握するためにSumo Logicに取り込んだイベントログを LogReduce
します。

_sourceCategory = 中略WindowsServer/EventLog/Security | logreduce

parseする項目を決める

LogReduceをした結果、今回は下記の項目でparseしてみます。

((((_sourceCategory = 中略/WindowsServer/EventLog/Security))))
| parse "<EventID>*</EventID>" as EventID nodrop
| parse "<Data Name='LogonType'>*</Data>" as LogonType nodrop
| parse "<Data Name='TargetUserName'>*</Data>" as TargetUserName nodrop
| parse "<Computer>*</Computer>" as Computer nodrop
parseする項目の解説

ADサーバから出力されるイベントログには様々な情報が記載されています。
今回はログオンの成功およびログオンの失敗に関しての箇所のみ触れます。

EventIDの種類

EventIDにもたくさんの種類がありますが、今回の目的であるログオンの成功およびログオン失敗のイベントIDは下記です。

EventID EventIDの説明
4624 アカウントのログオンが正常に完了しました。
4625 アカウントがログオンに失敗しました。

参考:
4624: アカウントのログオンが正常に完了しました。
4625 (F): アカウントがログオンに失敗しました。

LogonType

LogonTypeにはいくつか種類がありますが、今回は下記のタイプについて、説明します。

LogonType LogonTypeの説明
2 ユーザーがこのコンピューターにログオンしました。
3 ユーザーまたはコンピューターがネットワークからこのコンピューターにログオンした。
10 ユーザーがターミナルサービスまたはリモートデスクトップを使ってリモートでこのコンピューターにログオンしました。

参考:ログオンの種類と説明

TargetUserName

TargetUserNameは、ログオン時のUserName が記録されます。

Computer

Computerは、Computerにログオンしたのかが記録されます。

ログオンの成功およびログオン失敗のイベントログを検索する

EventIDの種類での説明の通り、4624と4625で検索してみます。

((_sourceCategory = 中略/WindowsServer/EventLog/Security))
| parse "<EventID>*</EventID>" as EventID nodrop
| parse "<Data Name='LogonType'>*</Data>" as LogonType nodrop
| parse "<Data Name='TargetUserName'>*</Data>" as TargetUserName nodrop
| parse "<Computer>*</Computer>" as Computer nodrop

| where EventID = "4624" or "4625"

2-2

↑ばっちり、ログオンの成功を見ることができるようになりました!
(ログオンの失敗は、検索した時点ではありませんでした)

おわりに

今回は分析のことはじめとして、ADサーバへのどのようなログオンがあり、またログオンの失敗がないかをSumo Logicで確認するための一連の流れについてご紹介しました。

次回活用編

次回以降、活用編としてログを活用した Active Directory に対する攻撃の検知と対策 1.2 版からSumo queryを作成してみようと思います。お楽しみに!

参考

Author image
About Thym
expand_less