Duplicate Sec 4688 events outputted with ./target/release/hayabusa -M -d ../hayabusa-sample-evtx

[hitenkoku]

    > `./target/release/hayabusa -M -d ../hayabusa-sample-evtx`で一番多いイベントはSec 4688で合っていますが、下の方をよく見たら、`Sec 4688: Unknown`2件も出ています。なぜ不明な`Sec 4688`が出ているのか分かりますか？

これを別issueにしますか？ @hitenkoku

Originally posted by @YamatoSecurity in #728 (comment)

[YamatoSecurity]

@hitenkoku 今思い出しましたが、チャンネル名がSecurityだったり、小文字のsecurityだったりする場合があるので、それで別のチャンネルとして集計されているかもしれません。集計する前にチャンネル名を全部小文字にしたらどうですか？

[hitenkoku]

基本は小文字で実施をしています。問題がないか念のため確認します

[hitenkoku]

確認が完了しました。ご指摘いただいた事項はMetrics実装の際に対応済みです

データ自体になにも存在しない可能性があり得るためもう少し解析します

[hitenkoku]

Metricsですべてのレコード情報を出したところEventID 4688 の物自体が9712件となっていました。
そのすべてが"Security"チャンネルとなっていました。(なので一番上の正しく表示されているものしか存在しなかった)

集計の際に何かしら情報が残ってしまっている可能性があるためもう少し調査します

[hitenkoku]

確認が取れました。eventIDの情報を取得した際にダブルクォートも含んだ形で情報を管理していたことが原因でした。修正を行いpull-requestを出しておきます

[hitenkoku]

@YamatoSecurity 対応が完了しました。イベントIDのキー名に一部ダブルクォートが入ってしまったことによる集計の誤りであることが確認できました。 #733 で修正したのでご確認ください。

[YamatoSecurity]

@hitenkoku 対応ありがとうございました！
ということで、普段のスキャン時でもイベントIDがダブルクォートに囲まれているせいで、IDが一致しなくて検知漏れが出ている可能性はありそうですか？もしあり得るのであれば、別のissueでイベントIDをチェックする前に全部ダブルクォートをtrimした方が良さそうですが、どう思いますか？

[hitenkoku]

@YamatoSecurity 可能性は否定できないです。ただ、今回問題となっている処理の関数に関連した処理は検知側のロジックでは利用していないため、確実に修正が必要とは判断できないです。
確認するとすれば今回の4688のダブルクォートが入っているレコードを特定させて、そのファイルに対して実行をするなどの検証が必要となります。

確認は必要だとは思いますので、一応調査用のissueを作っておきます。もし不要となればissueをcloseする方針にしようともいます