サイバー攻撃に関するインシデントのフォレンジック調査をする場合、重宝するのはやはりログです。
これは、どの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のデフォルトの監査ポリシーは以下のとおり。
※表示が乱れるので、後日修正・・・
有効化する場合は、以下のコマンドを実行します。
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
これを単純にまんまバッチ化したので以下に貼っておきます。
（多分、世界で筆者または他の誰かがとっくにやってそうなんですが、よー見つけきらんかったので・・・。作っちまった。）
注意事項はGitのReadmeに書いてありますが、現段階で以下のとおり。
- /category、/subcategoryはGUIDを使うようにしています。ただし、それゆえのWindowsのバージョンの違いによる差がでる可能性は否定できません。監査名は変わらないと思いますが、GUIDまでバージョン間で共通かどうかは、手元に環境がないため確認できていません（所詮は個人のご自宅作業なので）。
- ログサイズの変更までは含んでいません。恐らく、これだけ有効化するとログはすぐに一杯になってリサイクルされてしまうので、記事にあるとおりサイスを増やすなりアーカイブするなりは別途検討。もし組織内で使用するなら、このバッチにログサイズ変更を追加して実行すると良いかと思います。
微妙に雑なのは、所詮個人がご自宅で、プライベートタイムと粗末な環境でやってるので勘弁してくださいｗ
っていうか、これでも下手なコンサルｗよりはお金もらってもいいんじゃね？くらいの内容になってきてる気がするんですけどね・・・？