Closed hitenkoku closed 2 years ago
countルールの仕様確認が必要
csvにあたらしくカラムを作ってそこに検知したレコードの情報をすべて追加する。 countのルールは対象外とする
xmlデータがこんな感じの時に
<EventData>
<huga>xxxx</huga>
<hoge atr="aaaa">
<UserData>D</UserData>
</EventData>
こういうデータを出す huga: xxx | hoge.atr: aaaa | UserData: D
XMLを確認しました。少し工夫する必要がありそうです。 もしかして他のパターンもあるかもしれないが、主なログを調べた限り、以下のパターンがありました:
パターン1 ( = "hogehoge"
が指定されている場合: )
<EventData>
<Data Name="param1">application-specific</Data>
<Data Name="param2">Local</Data>
<Data Name="param3">Launch</Data>
</EventData>
を
param1: application-specific | param2: Local | param3: Launch
にしたいです。(Data Nameは不要)
パターン2 (= "hogehoge"
が無い場合):
<EventData>
<Data>Available</Data>
<Data>None</Data>
<Data>NewEngineState=Available PreviousEngineState=None SequenceNumber=13 HostName=ConsoleHost HostVersion=5.1.17134.1 HostId=56051a4b-f4cf-4094-8f7d-f73132c83887 HostApplication=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe EngineVersion=5.1.17134.1 RunspaceId=8c910902-af24-4595-9c97-dc3380be4931 PipelineId= CommandName= CommandType= ScriptName= CommandPath= CommandLine=</Data>
</EventData>
を
Data: Available | Data: None | Data: NewEngineState=Available PreviousEngineState=None SequenceNumber=13 HostName=ConsoleHost HostVersion=5.1.17134.1 HostId=56051a4b-f4cf-4094-8f7d-f73132c83887 HostApplication=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe EngineVersion=5.1.17134.1 RunspaceId=8c910902-af24-4595-9c97-dc3380be4931 PipelineId= CommandName= CommandType= ScriptName= CommandPath= CommandLine=
という風に出力したら良いと思います。
パターン3 (EventDataではなく、UserData): 多くのログはEventDataに詳細な情報が書かれていますが、WMI-Activity、Setup等のログはEventDataではなく、UserDataになっています。 例:
<UserData>
<Operation_StartedOperational xmlns="http://manifests.microsoft.com/win/2006/windows/WMI">
<ProviderName>Win32_WIN32_TERMINALSERVICE_Prov</ProviderName>
<Code>0x0</Code>
<HostProcess>wmiprvse.exe</HostProcess>
<ProcessID>3448</ProcessID>
<ProviderPath>%SystemRoot%\system32\tscfgwmi.dll</ProviderPath>
</Operation_StartedOperational>
</UserData>
毎回邪魔なxmlnsのURLがあるので、消したいです。
例: ProviderName: Win32_WIN32_TERMINALSERVICE_Prov | Code: 0x0 | 等々
ロジックとしてはEventDataもしくはUserDataのもっともネストされているフィールドを出力すると良さそうです。
少し稀なパターンでUserDataの中にEventDataがある場合もあります (SMBServer/Operational):
<UserData>
<EventData xmlns="Smb2Namespace">
<NameLength>16</NameLength>
<Name>SEC504STUDENT</Name>
<DomainNameLength>6</DomainNameLength>
<DomainName>SEC504</DomainName>
<TransportNameLength>58</TransportNameLength>
<TransportName>\Device\NetBT_Tcpip_{65E8D264-9990-4A71-8230-39635FC91F19}</TransportName>
<TransportFlags>0x1</TransportFlags>
</EventData>
</UserData>
この場合でももっともネストされているフィールドを出力したら
NameLength: 16 | Name: SEC504STUDENT | DomainNameLength: 6 | 等々
が出力されます。
注意点:AccessMask等のフィールドにタブや改行のコントロールコードが入っている場合もあるので、https://github.com/Yamato-Security/hayabusa/pull/396 のように削除する必要があるはずです。
やはり、かなり仕様変更が入りそうですね。 CSVに出力するというそもそもの仕様が良くない気がしてきたので、もうちょっとreasonableな仕様を考えたいと思います。
→ YamatoSecurity のイメージを書いてもらう
将来的にSigmaルールもHayabusaルールのように必要なフィールドだけ(また、分かりやすいフィールド名など)でdetailsを出力したいのですが、実装するのは時間がかかるので、取り敢えず全情報を出すことでSigmaアラートも確認できるようにしたいです。このissueは間接的にsigmaアラートの中身を確認できるようにしていますが、アナリストが詳細に調査したい場合や、ルール作成する時にいちいちEvent Viewerでevtxの中身を調べなくても良いようにするのが目的です。
イメージ:
-F --full-data 'Print all field information.'
という新しいオプションを付けると、ファイル出力時だけではなく、標準出力でも全フィールドの情報がdetailsカラムで出力されます。(※デフォルトのオプションではないので、遅くなったり、沢山のメモリが必要になったりしても、そんなに気にしなくても良いと思います。)
パターン 1: detailsが無い場合(Sigmaルール): 全フィールド(Key: Value)を出力する。(evtxの前半のSystem情報を省く)
パターン 2: detailsがある場合(Hayabusaルール): details出力に無いフィールドだけ追加する。 例(Sysmon EID 20を探すルール):
details: '%Operation% | Type: %Type% | Name: %Name% | Dst: %Destination% | User: %User%'
detection:
selection:
Channel: Microsoft-Windows-Sysmon/Operational
EventID: 20
condition: selection
XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" />
<EventID>20</EventID>
<Version>3</Version>
<Level>4</Level>
<Task>20</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2019-07-19T14:57:02.895491400Z" />
<EventRecordID>4059</EventRecordID>
<Correlation />
<Execution ProcessID="2796" ThreadID="4356" />
<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
<Computer>MSEDGEWIN10</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="RuleName" />
<Data Name="EventType">WmiConsumerEvent</Data>
<Data Name="UtcTime">2019-07-19 14:57:02.884</Data>
<Data Name="Operation">Deleted</Data>
<Data Name="User">MSEDGEWIN10\IEUser</Data>
<Data Name="Name">"AtomicRedTeam-WMIPersistence-Example"</Data>
<Data Name="Type">Command Line</Data>
<Data Name="Destination">"C:\\Windows\\System32\\notepad.exe"</Data>
</EventData>
</Event>
Hayabusaのデフォルト出力:
"Deleted | Type: Command Line | Name: ""AtomicRedTeam-WMIPersistence-Example"" | Dst: ""C:\\Windows\\System32\\notepad.exe"" | User: MSEDGEWIN10\IEUser"
-Fを指定した場合:
"Deleted | Type: Command Line | Name: ""AtomicRedTeam-WMIPersistence-Example"" | Dst: ""C:\\Windows\\System32\\notepad.exe"" | User: MSEDGEWIN10\IEUser | RuleName: | EventType: WmiConsumerEvent | UtcTime: 2019-07-19 14:57:02.884"
という風に考えていますが、いかがでしょうか?
@YamatoSecurity
details出力に無いフィールドだけ追加するというのは、Sigmaルールで必要なフィールドだけ出力するのと同じ位実装が大変そうな気がするので、とりあえず下記のどちらかにしたいです。
了解です。では、「CSVに新しいカラムを追加し、detailsの有無に関わらず全てのルールについて、追加したカラムにSystem以外の全フィールドを出力する。」の方をお願いしたいです。
@YamatoSecurity 出力例を添付しておきます。evtxはhttps://github.com/sans-blue-team/DeepBlueCLI/blob/master/evtx/eventlog-dac.evtx を使っています。 hayabusa.csv
見難いというか、殆どの値はセルに表示できないです。 EXCELで見るとしたら、赤く囲った部分で見る感じになりそうです。WQHDでぎりぎり’なので、フルHDだともっときついかもしれないです。 、
各手法のメリットとデメリットを比較しました。
会議メモ:
オプションについて
元々はoption指定時のみ出力する仕様でしたが、今の実装では常時出力するようにしています。 サンプル(https://github.com/Yamato-Security/Hayabusa-sample-evtx)とか、2GBの大きなログで試してみましたが、パフォーマンス等に与える影響は殆どありませんでした。 使わない時は見なければいいだけなので、オプション無しで常時出力するようにしようと思いますが、いいですか?
出力されるファイルサイズが3倍近くなっている。hayabusa-sample-evtxの5-6MB位、全データを出したら15MB位
データを集約させるときに余分なデータを送付することを避けたいのでオプションでオンオフをつけれるようにしたい。
以下のような出力が出ていて、param1やparam2はないはずだが出力されているという状態になっているとのこと。
2016-09-18 07:56:46.000 +09:00 IE10Win7 4625 medium initial_access : persistence : t1078 : t1190 : t1133 Failed Logon From Public IP param1: 86400 | param2: SuppressDuplicateDuration | param3: Software\Microsoft\EventSystem\EventLog rules/sigma/builtin/security/win_susp_failed_logon_source.yml ../../hayabusa-sample-evtx/DeepBlueCLI/many-events-application.evtx
オプションどうするかについてはissueで話しますか。
バグについては調べます。
@hitenkoku @YamatoSecurity
私の方で調査してみました。 param1,param2,param3はEvtxのRecordに全て存在していて、出力されるのが正しい挙動だと思いますが、問題ないですよね?
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Events>
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-EventSystem' Guid='{899daace-4868-4295-afcd-9eb8fb497561}' EventSourceName='EventSystem' />
<EventID Qualifiers='16384'>4625</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime='2016-09-17T22:56:46.0000000Z' />
<EventRecordID>2096</EventRecordID>
<Correlation />
<Execution ProcessID='0' ThreadID='0' />
<Channel>Application</Channel>
<Computer>IE10Win7</Computer>
<Security />
</System>
<EventData>
<Data Name='param1'>86400</Data>
<Data Name='param2'>SuppressDuplicateDuration</Data>
<Data Name='param3'>Software\Microsoft\EventSystem\EventLog</Data>
</EventData>
</Event>
</Events>
以下のような出力が出ていて、param1やparam2はないはずだが出力されているという状態になっているとのこと。
2016-09-18 07:56:46.000 +09:00 IE10Win7 4625 medium initial_access : persistence : t1078 : t1190 : t1133 Failed Logon From Public IP param1: 86400 | param2: SuppressDuplicateDuration | param3: Software\Microsoft\EventSystem\EventLog rules/sigma/builtin/security/win_susp_failed_logon_source.yml ../../hayabusa-sample-evtx/DeepBlueCLI/many-events-application.evtx
コメントありがとうございます。私の確認が不十分で申し訳ないです。@YamatoSecurity から指摘された内容をそのまま転記しておりました。私としてはこのままで問題ないと思います。
前回の打ち合わせでどの形で出力するかは@YamatoSecurity が確認中です
@YamatoSecurity ご回答の程よろしくお願いいたします
私の方で調査してみました。 param1,param2,param3はEvtxのRecordに全て存在していて、出力されるのが正しい挙動だと思いますが、問題ないですよね?
はい、問題ありません。 ミーティングの時にこの4625イベントがたまたま画面に出てきたので、取り急ぎ情報共有しました。原因はSigmaルールにChannelが書かれていないので、Securityの4625ではなくて、Applicationの4625の誤検知で、フィールド名が全然違います。 お騒がせしてすみません。
CSV値見えない問題については、セル内改行するとある程度見やすくなるかも。デメリットもありますが...。これは他のカラムにも当てはまることです。
後はRecordInformationを一番最後のカラムにして、RecordInformationの一フィールドで一つのセルを使うようにするとか。RecordInformationだけカラム数が行毎に可変になりますが、それを許容するために一番最後のカラムにする感じ
なんか、こういうのがあると、EXCELとかTimelineExplorerとか汎用の表計算ソフトに任せる限界を感じますね。EXCELでやる限りどうやっても見にくいです。
下記のISSUEでもそうですが、EXCELで使うことだけを考えればこういうことをやってもいいですが、pythonとかスクリプトで操作する人からするとこれは余計な処理なので、hayabusa専用のUIを作るのが良いような気がしてきました。
お返事が遅くなってすみません。比較とフィードバックありがとうございます。
オプションについて 全フィールドの出力はあくまでルール作成と徹底的な調査のためのデバッグ情報のようなものなので、デフォルトでは出力したくないです。(※現在sigmaのdetailsに対応していないので、暫定的にそのためにもなりますが、今回の目的ではありません) デフォルトで出力すると、結果のファイルサイズが無駄に大きくなって、Threat Huntingで多くの端末から情報を送信する時に困るのと、それを見てしまう人が居るのでfast forensicsじゃなくなります。(全情報を最初から確認したいのであれば、その解析に特化したツール(Evtxecmd)が既にあるので、それを使ったら良いとなってしまいます) ので、オプションを追加して頂けますか? (仕様に書いてあるように標準出力時でも全情報のカラムを追加したいです。(ルール作成で毎回ファイルに保存して、catで確認して、ファイル削除するのは意外と手間なので)
今回はルール作成等で別のファイルを確認する手間が無いようにしているので、CSVカラムを追加するしかないと思います。 小さいモニターしか持っていない人は仕方なく横にスクロールして貰うしかないと思います。フォレンジック調査している人であれば、ワイドやウルトラワイドのモニターか縦に長いモニターを使っている人が多いと思います。現在はdetailsも横に固定の文字列で定義してしまっているけど、いつかは各フィールドを配列にして、モニターを縦にしている人のためにフィールドを改行で区切れるようにしたいと思っています。(もしくは、X個のフィールドごとに改行を入れるとか、文字数を超えると改行を入れるとか) WindowsのEvent ViewerでイベントをCSVに出力したら改行がかなり入るけど、問題なくExcel等にインポートできるので、改行コードに注意すれば、いけると思います。(多分)
専用のUIについて 情報がそもそも多いと、どのUIでも限界があると思いますが、どのようなUIを想像していますか? 何か良いものが作れそうのであれば、ぜひ作ってみたいのですが、hayabusaのバックエンド処理(今回のツール)とfrontendのUIを別にしたいです。なので、hayabusa-guiはGoやpython等のもっと書きやすい言語の方が良いと思います。(rustのように全OSに対応している言語、dependency不要だと一番嬉しいですが) RITAというOSSのネットワークThreat Huntingツールがありますが、商用でGo+HTML5で作ったWeb Frontend UIも販売しています:https://www.youtube.com/watch?v=zYMBZKGm9PE ここまで良いUIを作ろうと思ったら、開発が大変のはずなので、副業ができるのであれば、このようなfreemiumモデルもありかも知れません。
1について 理由はあまり納得できるものが無いように思えますが、とりあえずオプションにしておきます。この機能自体がそもそも微妙なので、オプションにしておいた方がよさそうです。 fastforensicにならない....は見なければ良いだけですし、必要になった時に再実行する手間もありますしね。
2について
EXCELはカラム幅の制限があるので、ワイドやウルトラワイドのモニターを使っても、殆どの値は見れないです。縦に長いモニターを使っているなら、余計に見えないですね。今回はルール作成等で別のファイルを確認する手間が無いようにしているので、CSVカラムを追加するしかないと思います。
というのもそんなことないのですが、もう作ってしまったので、このままにしたいと思います。
以下の部分は自分がちょっと前に書いたこと同じだと思いますが、出来ないことはないです。ただ、このように表示すると更に見にくくなる人もいるので、とりあえず今回は実装しません。ただでさえオプションが多いのに、更に多くなってしまいそうという理由もあります。
いつかは各フィールドを配列にして、モニターを縦にしている人のためにフィールドを改行で区切れるようにしたいと思っています。
3について 目的はhayabusaに必要な機能に絞った高速に動作するViewerが欲しいということです。EXCELは大量データだと遅くなりますし、TimelineExplorerも動作が不安定だったりするので。あと、今回みたいに複数行に表示するデータはEXCELでもTimelineExplorerでも厳しいです。
UIの外観としてはWindowsのEventViewerのようにテーブルで一覧表示しつつ、詳細は別のタブで表示する感じのものを想定しています。今回の全フィールド出力のように表示内容が多い機能は別タブで表示した方が見やすいです。 それにフィルタとかcountとかpivote keyword listとか必要な分析機能を追加できるようなものを考えています。検知と関係ないpivote keyword listの機能をhayabusaに入れようとしてますが、本来はhayabusaにいれるべき機能ではないので、ちゃんと分けておきたいという気持ちもあります。
pythonでもgoでも全OS/nodependency対応したものが作れないということはないです。dependencyについては、UIフレームワークが何に依存しているかに因る部分もあるので、各言語のUIフレームワークを調査して、動作速度やUIの表現力や記述しやすさ等を元に決めればよいと思います。
本来はhayabusaにいれるべき機能ではないので、ちゃんと分けておきたいという気持ちもあります。
そうなんですよね。分けたい。 レコードの中身を全部出力するなら、subcommandにするのもありかな?と思うのですが、Dさんは「複雑化するのはあまり好まない」と言います。
ピボットキーワード処理が2gbのvetch で2分ほどかかっていますが、UIの方に処理を持っていくにしても、表示するのに、時間かかっちゃうと、イライラするかなと思います。
うーん、という気持ちです(ふわふわしてる)
是非良いUIが作れそうであれば、作りましょう。 すぐ作れないと思うので、それまでにあとできるのは、実行時に重複しているフィールドを出力しない実装が難しいのであれば、タイムラインを使った後に重複しているフィールドを削除するオプションかツールを作ったら、データがかなり減って、一台のモニターに収まるかもしれません。
重複しているフィールドを消しても殆ど意味なかったので、実装しません。この機能は現状の仕様だと使い難いので、作り直すことになります。そのような機能に時間かけても意味ないので、今回はこのままリリースします。
本来はhayabusaにいれるべき機能ではないので、ちゃんと分けておきたいという気持ちもあります。
そうなんですよね。分けたい。 レコードの中身を全部出力するなら、subcommandにするのもありかな?と思うのですが、Dさんは「複雑化するのはあまり好まない」と言います。
ピボットキーワード処理が2gbのvetch で2分ほどかかっていますが、UIの方に処理を持っていくにしても、表示するのに、時間かかっちゃうと、イライラするかなと思います。
うーん、という気持ちです(ふわふわしてる)
@kazuminn 自分的にはサブコマンドでも良いような気はします。サブコマンドがrustのclapで簡単に実現できるなら、良いかなという感じです。後、既存のソースと混ざらいないようにモジュールを分けておけば、そこまで複雑度は上がらないような気もします。
2gbの処理に時間がかかるのはしょうがなくて、それはUIから実行してもterminalから実行しても時間がかかるのは変わらないので、後はUI上で待ち時間中に他の作業ができたりとか、時間がかかる処理であることをUI上で分かるようにするとか、そういう感じだと思います。
@hach1yon
現状のusageを文字列に指定するやり方ではできませんが、メソッドチェーンの形でサブコマンド設定をすることはできます。Clapの今のバージョンでも可能なので投入すること自体は問題ないと思います。
複雑化するのはあまり好まないという話は処理の面としては @hach1yon のコメントの通りで、モジュールを分ければそれは問題ないと思っています。
@kazuminn
複雑になるのは好まないという話を出したのは #393 #412 での話であり、そちらの方では--outputのオプションが -pオプションの有無によって出力されるファイルが異なるという話があり、--outputのオプションの説明が複雑になるので避けたいという意図です。
今回のサブコマンドは指定したらoutput内での特定レコードが追加されるということでオプションに対して一意ではあるので、必須な機能であるかの話は置いといてコマンドの面では複雑にはならないかと思っていました。
まぁ、これは今すぐでもないので、次回のミーティングで時間があれば話しましょうか。
打ち合わせの結果、v1.2の締切に合わせられそうならばv1.2に戻すとして、暫定的にマイルストーンをv1.2からv1.3に一応変更しておきました。
オプションを付けた際に、検知したレコードの中身(JSON形式)を特定のファイルに出力する