サイバー攻撃に関するインシデントのフォレンジック調査をする場合、重宝するのはやはりログです。

これは、どのOS、アプリケーションでも重宝します。

フォレンジック調査は、「データとして残っている」痕跡が無ければ調査できません。

ログはいつ、どのような動きをしていたかをOSやアプリケーションが痕跡を残してくれるため、調査の軸になります。

ただし、ログの改ざん、破壊がされてしまうケースもあり、その対策は必要です。

さて、今回は、「そもそもログが足りているか？」というお話です。

例えばWebサービスからSQLインジェクションで情報を盗まれた可能性がある場合、ケースによってはSQLのクエリを調べたいわけですが、「SQLのクエリなんて記録してねーよ！」って言われたら、データベースからどんなデータが抽出されたか分からないわけで、特定は困難ということになります。

（大抵パケットなんて取ってないし、暗号化されてたりするし。WebサーバのGetリクエストのログでワンチャンくらい。）

Windowsで「イベントログを残す」ことについて着目したとき、以下を考慮する必要があります。

イベントログのサイズ
イベントログのリサイクルとアーカイブ
残すイベントログの内容

これらを考慮しておかないと、調査しようとしても記録が残っていなくてできない、ということが生じます。

また、より正確な調査に結び付くこともあります。

今回は、Windowsのイベントログに関して調べたり確認した結果のメモです（本人が毎回忘れるので）。

ちなみに、今回はWindowsクライアントマシンをターゲットとしています（サーバは手元にないので・・・）。

イベントログの参照

Windowsでは、「イベントログ」というものがあり、「OSの挙動」に関し、様々なログを残しています。

これは、「イベントビューア」という画面で確認できます。

イベントログの確認方法は以下の通り。

Windows10の場合：

スタート → Windows管理 → イベントビューア

コントロールパネル → システムとセキュリティ → 管理ツール → イベントビューア

どちらかの方法で開くことで、ビューア画面が開きます。

左のペインでログを選択すると、中央上段にリスト、下段に詳細が表示されます。

左のペインを開けば分かりますが、かなりの情報が残されています。

イベントログのサイズ

イベントログは、無制限に記録されるのではなく、サイズの上限がそれぞれ設定されています。

サイズの上限に到達した場合の動作は次に記載します。

イベントログのサイズが重要な理由は、デフォルトの設定では、古いイベントを消して上書きする設定になっているログが多いためです。

このため、調査時にイベントログを参照しても、ログのサイズ上限以前のログが上書きされていて、確認できないケースがあります。

（なお、Volume Shadow Copyの領域に残されているケースはあります。これはまた別の話で。）

イベントログのサイズは、イベントビューアで参照、変更することができます。

操作は、確認したいログを選択して右クリックしてポップアップウィンドウを表示し、「プロパティ」を選択します。

表示されたプロパティには、現在のログのサイズ、最大のログサイズが表示されています。

このログサイズはそれぞれ異なり、セキュリティログはデフォルトで20MBとなっています。

ログの上限サイズとログサイズが一致していることから分かる通り、このログは既に上書きされており、最も古いレコードは2020年9月でした。

つまり、2020年8月以前のデータは残されておらず、このログを2020年8月以前も含めて精査したいならば、これでは記録サイズが不足している、ということになります。

ログのサイズは変更することができます（要管理者権限）。

イベントビューアを使用する場合、「最大ログサイズ」を変更することで変更可能です。

変更した場合、「適用」または「OK」ボタンを押してください。

なお、ログサイズの最小は1048576バイト (1024 KB) 、ログファイルは常に 64 KB の倍数となります。

しかし、いちいち画面を開いて設定を変更するのは面倒！ではありますね。

このため、ログサイズの変更は、コマンドプロンプトやPowershellでも行うことができます。

コマンド：

wevtutil set-log (ログ名称) /maxsize:（サイズ）

例）セキュリティログを30MBにする場合

wevtutil set-log Security/maxsize:31457280

Powershell：

Limit-EventLog -LogName (ログ名称) -MaximumSize (サイズ)

例)

Limit-EventLog -LogName Security -MaximumSize 30720KB

ログ名称は、以下のコマンドで確認できます。

（ログ名称は、日本語ではコマンドが上手くいかないんだなぁコレが。）

コマンド：

wevtutil el

Powershell：

Get-EventLog -List

または

Gwt-WinEvent -ListLog *

イベントログのリサイクルとアーカイブ

デフォルト設定では、ログサイズを大きくしても、ログサイズいっぱいになれば上書きされてしまいます。

ログがいっぱいになった場合、アーカイブして残す設定にすることも可能です。

ログは、イベントログと同じフォルダに、年月日時分秒を付けた名前で出力されます。

なお、アーカイブしたログは、何もしなければどんどん溜まっていくことには注意が必要です。

操作は、確認したいログを選択して右クリックしてポップアップウィンドウを表示し、「プロパティ」を選択します。

ダイアログの「イベントログが最大値に達したとき」で、「イベントを上書きしないでログをアーカイブする」を選択します。

「適用」または「OK」ボタンを押してください。

この設定もコマンドラインで可能です。

コマンド：

wevtutil set-log Security /retention:true /autobackup:true

（autobackupをオンにするとき、retentionもTrueにしておかなければならない点に注意。）

Powershell（調査中）：

$logdetails = Get-LogProperties 'Security'

$logdetails.Retention = $True

$logdetails.AutoBackup = $True

Set-LogProperties -LogDetails $logdetails

・・・Microsoftのマニュアル通りであればコレでいけるはずなんですが、私の環境ではなぜかエラーになってしまいます。

これは調査中ですが、一応メモしておきます。

残すイベントログの内容

今回の記事の発端である、残すイベントログの内容です。

Windowsのログは色々あるものの、デフォルトでは監査ログの内容が一部しかなかったり、Disableになっていてログを取っていないものがあります。

インシデント調査の際に欲しい情報でもデフォルトではログされていないことがあるので、有事の際に調査できるよう、ログ出力を確認し、必要な情報を増やしましょう。

監査ログは、グループポリシーエディタで編集できます。

ローカルマシンの場合、ローカルグループポリシーエディタ（gpedit.msc）が利用できます。

※注：gpedit.mscは、Windows10 homeにはありません。Pro以上となります。

私の環境では、

コンピュータの構成→Windowsの設定→セキュリティの設定→監査ポリシーの詳細な構成→システム監査ポリシー

を選択することで右のペインに監査ポリシーを表示することができました。

さらにカテゴリを選ぶことで、サブカテゴリが表示されます。

このサブカテゴリのプロパティで監査イベントを構成することで、ログの出力が追加されます。

ログが無効の場合、イベントビューアで有効化することができます。

イベントビューアでログを右クリックし、ポップアップメニューの「ログの有効化」をクリックするか、ログのプロパティで「ログを有効化する」にチェックをいれて「OK」または「適用」をクリックします。

これらはコマンドでも実行できます。

監査ポリシーは、コマンドプロンプト、Powershell双方でauditpolが利用できます。

監査ポリシーの状況は以下のコマンドで確認できます。

コマンド：

auditpol /get /category:*

このコマンドで確認できた、2020年11月1日現在のWindows10 Proのデフォルトの監査ポリシーは以下のとおり。

システム監査ポリシー
カテゴリ/サブカテゴリ設定
システム
セキュリティシステムの拡張　　　　　　監査なし
システムの整合性　　　　　　　　　　　　成功および失敗
IPsec ドライバー　　　　　　　　　　　　　監査なし
その他のシステムイベント　　　　　　　成功および失敗
セキュリティ状態の変更　　　　　　　　　成功
ログオン/ログオフ
ログオン　　　　　　　　　　　　　　　　　　成功および失敗
ログオフ　　　　　　　　　　　　　　　　　　成功
アカウント　ロックアウト　　　　　　　　成功
IPsec メインモード　　　　　　　　　　　監査なし
IPsec クイックモード　　　　　　　　　　監査なし
IPsec 拡張モード　　　　　　　　　　　　監査なし
特殊なログオン　　　　　　　　　　　　　成功
その他のログオン/ログオフイベント　　　監査なし
ネットワークポリシーサーバー　　　成功および失敗
ユーザー要求/デバイスの信頼性情報　　監査なし
グループ　メンバーシップ　　　　　　　　監査なし
オブジェクトアクセス
ファイルシステム　　　　　　　　　　　　　監査なし
レジストリ　　　　　　　　　　　　　　　　　　監査なし
カーネル　オブジェクト　　　　　　　　　　監査なし
SAM　　　　　　　　　　　　　　　　　　　　　監査なし
証明書サービス　　　　　　　　　　　　　　監査なし
生成されたアプリケーション　　　　　　　監査なし
ハンドル操作　　　　　　　　　　　　　　　　監査なし
ファイルの共有監査なし
フィルタリングプラットフォームパケットのドロップ　　監査なし
フィルタリングプラットフォームの接続　　　　　　　　　監査なし
その他のオブジェクトアクセスイベント　　　　　　　　　監査なし
詳細なファイル共有　　　　　　　　　　　監査なし
リムーバブル記憶域　　　　　　　　　　　監査なし
集約型ポリシーステージング　　　　　監査なし
特権の使用
重要でない特権の使用監査なし
その他の特権の使用イベント監査なし
重要な特権の使用監査なし
詳細追跡
プロセス作成監査なし
プロセス終了監査なし
DPAPI アクティビティ監査なし
RPC イベント監査なし
プラグアンドプレイイベント監査なし
トークン権限調整済みイベント監査なし
ポリシーの変更
ポリシーの変更の監査成功
ポリシーの変更の認証成功
ポリシーの変更の承認監査なし
MPSSVC ルールレベルポリシーの変更監査なし
フィルタリングプラットフォームのポリシーの変更監査なし
その他のポリシー変更イベント監査なし
アカウント管理
コンピューターアカウント管理監査なし
セキュリティグループ管理成功
配布グループの管理監査なし
アプリケーショングループの管理監査なし
その他のアカウント管理イベント監査なし
ユーザーアカウント管理成功
DS アクセス
ディレクトリサービスアクセス監査なし
ディレクトリサービスの変更監査なし
ディレクトリサービスのレプリケーション監査なし
詳細なディレクトリサービスレプリケーション監査なし
アカウントログオン
Kerberos サービスチケット操作監査なし
その他のアカウントログオンイベント監査なし
Kerberos 認証サービス　　　　　　　　　　監査なし
資格情報の確認監査なし

※表示が乱れるので、後日修正・・・

有効化する場合は、以下のコマンドを実行します。

auditpol /set /category:(監査名) /success:enable /failure:enable

例）アカウントログオンの成功、失敗ともに有効にする場合

auditpol /set /category:"Account Logon" /success:enable /failure:enable

2020/12/31 追記

どうも、/catecory、/subcategoryの文字列は、使用している言語に依存するようです。

このため、日本語環境では、以下のようにしないと成功しないことがあります。

auditpol /set /category:"アカウントログオン" /success:enable /failure:enable

ただし、これではWindowsの言語設定の影響を受けてしまいます。

日本語以外の設定のWindowsを使用している場合に問題が発生することになります。

特に会社等で使用する場合、日本語以外を利用される方やサーバは英語版を利用していることがあるのではないかと思います。

確認したところ、GUIDを使うことで言語設定の影響を回避することが可能なようです。

auditpol /set /category:"{69979850-797A-11D9-BED3-505054503030}" /success:enable /failure:enable

GUIDの確認は、以下の方法で可能です。

auditpol /list /category /v

auditpol /list /subcategory:(カテゴリレベルの監査名) /v

以下に、自身のWindows 10環境で動作確認したバッチのソースをGithubにアップしたので、リンクを記事の一番最後に貼っておきます。

（個人の環境なので数が無く、他の環境で上手くいくかはまだ確認がとれていません。）

ログ自体の有効化は、以下のコマンドで実行できます。

wevtutil set-log （ログ名） /enabled:true

例）「Microsoft-Windows-ASN1/Operational」ログを有効化

wevtutil set-log "Microsoft-Windows-ASN1/Operational" /enabled:true

Powershellの場合、

$logdetails = Get-LogProperties 'Microsoft-Windows-ASN1/Operational'

$logdetails.Enabled = $True

Set-LogProperties -LogDetails $logdetails

あたりでいけそうな気もするんですが・・・自分の環境ではエラーになるので、調査中ステータスです。

以上、とりあえず調べたWindowsイベントログ情報でした。

まだ勉強中、検証中の部分もあるので、とりあえず集めた情報を羅列した感じです。

検証は、今後時間が取れればやりたいところ。

おススメログ設定、なんてエラそうなものまでは・・・出せるかな？

2020/12/31追記

YEA(Yamato Event Analyzer)プロジェクトで、ザック氏に以下の情報をいただきました。

WINDOWS LOGGING CHEAT SHEET - Win 7 thru Win 2019

https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/5c586681f4e1fced3ce1308b/1549297281905/Windows+Logging+Cheat+Sheet_ver_Feb_2019.pdf

これを単純にまんまバッチ化したので以下に貼っておきます。

（多分、世界で筆者または他の誰かがとっくにやってそうなんですが、よー見つけきらんかったので・・・。作っちまった。）

Sachiel-archangel/WinEventEnableWindows Event log . Contribute to Sachiel-archangel/WinEventEnable development by creating an account on GitHub.

github.com

注意事項はGitのReadmeに書いてありますが、現段階で以下のとおり。

/category、/subcategoryはGUIDを使うようにしています。ただし、それゆえのWindowsのバージョンの違いによる差がでる可能性は否定できません。監査名は変わらないと思いますが、GUIDまでバージョン間で共通かどうかは、手元に環境がないため確認できていません（所詮は個人のご自宅作業なので）。
ログサイズの変更までは含んでいません。恐らく、これだけ有効化するとログはすぐに一杯になってリサイクルされてしまうので、記事にあるとおりサイスを増やすなりアーカイブするなりは別途検討。もし組織内で使用するなら、このバッチにログサイズ変更を追加して実行すると良いかと思います。

微妙に雑なのは、所詮個人がご自宅で、プライベートタイムと粗末な環境でやってるので勘弁してくださいｗ

っていうか、これでも下手なコンサルｗよりはお金もらってもいいんじゃね？くらいの内容になってきてる気がするんですけどね・・・？

Windowsのイベントログ、足りてますか？