検知したRecordの全フィールドをCSVに出力する

[hitenkoku]

No description provided.

[hitenkoku]

オプションを付けた際に、検知したレコードの中身(JSON形式)を特定のファイルに出力する

[hach1yon]

countルールの仕様確認が必要

[hitenkoku]

csvにあたらしくカラムを作ってそこに検知したレコードの情報をすべて追加する。
countのルールは対象外とする

xmlデータがこんな感じの時に

<EventData>
   <huga>xxxx</huga>
   <hoge atr="aaaa">
   <UserData>D</UserData>
</EventData>

こういうデータを出す
huga: xxx | hoge.atr: aaaa | UserData: D

[YamatoSecurity]

XMLを確認しました。少し工夫する必要がありそうです。
もしかして他のパターンもあるかもしれないが、主なログを調べた限り、以下のパターンがありました：

パターン１ ( = "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は不要)

パターン２ (= "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=
という風に出力したら良いと思います。

パターン３ (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　のように削除する必要があるはずです。

[hach1yon]

やはり、かなり仕様変更が入りそうですね。
CSVに出力するというそもそもの仕様が良くない気がしてきたので、もうちょっとreasonableな仕様を考えたいと思います。

[itiB]

• 検討事項
  • detailsがないルールは全部出力?
  • 詳細にみたいときには結局EVTXエクスプローラーでみるし詳細にださなくてもいいのでは

→ YamatoSecurity のイメージを書いてもらう

[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"

という風に考えていますが、いかがでしょうか？

[hach1yon]

@YamatoSecurity

details出力に無いフィールドだけ追加するというのは、Sigmaルールで必要なフィールドだけ出力するのと同じ位実装が大変そうな気がするので、とりあえず下記のどちらかにしたいです。

• detailsの設定されてないルールだけ、CSVのdetailsカラムにSystem以外の全フィールドを出力する。
• CSVに新しいカラムを追加し、detailsの有無に関わらず全てのルールについて、追加したカラムにSystem以外の全フィールドを出力する。

[YamatoSecurity]

了解です。では、「CSVに新しいカラムを追加し、detailsの有無に関わらず全てのルールについて、追加したカラムにSystem以外の全フィールドを出力する。」の方をお願いしたいです。

[hach1yon]

@YamatoSecurity
出力例を添付しておきます。evtxはhttps://github.com/sans-blue-team/DeepBlueCLI/blob/master/evtx/eventlog-dac.evtx を使っています。
hayabusa.csv

見難いというか、殆どの値はセルに表示できないです。
EXCELで見るとしたら、赤く囲った部分で見る感じになりそうです。WQHDでぎりぎり’なので、フルHDだともっときついかもしれないです。

、

[hach1yon]

各手法のメリットとデメリットを比較しました。

CSVのカラムに出力する

メリット

• 1ファイルで済むので他のファイルを開かなくて良い。
• フィールドの値をフィルタ条件に使える。
• EXCEL内の検索もできる
• セル上で値を確認することはできないが、赤く囲った部分で値を確認することは一応可能。

デメリット

• セル上で値を確認することができない。特にディスプレイサイズの小さいノートパソコンではかなり厳しい。
• 赤く囲った部分で値を確認できるが、見やすいとは言えない。
• 列の幅がすごく広くなって、他のカラムの値も確認しづらくなる。
• python等のスクリプトで処理する場合、JSON形式の方が処理しやすい。また、元のレコードを完全に復元できる情報をもっているわけではないので、スクリプトで一部できないことが発生しそう。

外部ファイルに1レコードに対して1ファイルずつ出力する。

メリット

• JSON形式でもXML形式でもVisual Studio Code等で開けば、色も付けてくれるので、確認しやすい。
• python等のスクリプトで処理する場合、元のレコードを完全に復元できる情報を出力できるので、一通りのことはできそう
• 他のカラムの列幅を圧迫しない。

デメリット

• 1ファイルずつ開かなければいけないのが、面倒。
• EXCEL上でフィルタすることができない。

外部ファイルに複数レコードまとめて出力する。

• 1ファイルずつ開かなければいけないデメリットは解消される。
• その分、ファイル内で対応するセルを検索する必要がある。(検索用のIDを新たに用意する必要がある。)
• フィールドの値をEXCELのフィルタ条件に使うことはできないまま。

[hitenkoku]

会議メモ:

オプションについて

元々はoption指定時のみ出力する仕様でしたが、今の実装では常時出力するようにしています。
サンプル(https://github.com/Yamato-Security/Hayabusa-sample-evtx)とか、2GBの大きなログで試してみましたが、パフォーマンス等に与える影響は殆どありませんでした。
使わない時は見なければいいだけなので、オプション無しで常時出力するようにしようと思いますが、いいですか?

出力されるファイルサイズが3倍近くなっている。hayabusa-sample-evtxの5-6MB位、全データを出したら15MB位

データを集約させるときに余分なデータを送付することを避けたいのでオプションでオンオフをつけれるようにしたい。

[hitenkoku]

以下のような出力が出ていて、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

[hach1yon]

オプションどうするかについてはissueで話しますか。

バグについては調べます。

[hach1yon]

@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

[hitenkoku]

コメントありがとうございます。私の確認が不十分で申し訳ないです。@YamatoSecurity から指摘された内容をそのまま転記しておりました。私としてはこのままで問題ないと思います。

前回の打ち合わせでどの形で出力するかは@YamatoSecurity が確認中です

@YamatoSecurity ご回答の程よろしくお願いいたします

[YamatoSecurity]

私の方で調査してみました。
param1,param2,param3はEvtxのRecordに全て存在していて、出力されるのが正しい挙動だと思いますが、問題ないですよね?

はい、問題ありません。
ミーティングの時にこの4625イベントがたまたま画面に出てきたので、取り急ぎ情報共有しました。原因はSigmaルールにChannelが書かれていないので、Securityの4625ではなくて、Applicationの4625の誤検知で、フィールド名が全然違います。
お騒がせしてすみません。

[hach1yon]

CSV値見えない問題については、セル内改行するとある程度見やすくなるかも。デメリットもありますが...。これは他のカラムにも当てはまることです。

[hach1yon]

後はRecordInformationを一番最後のカラムにして、RecordInformationの一フィールドで一つのセルを使うようにするとか。RecordInformationだけカラム数が行毎に可変になりますが、それを許容するために一番最後のカラムにする感じ

[hach1yon]

なんか、こういうのがあると、EXCELとかTimelineExplorerとか汎用の表計算ソフトに任せる限界を感じますね。EXCELでやる限りどうやっても見にくいです。

下記のISSUEでもそうですが、EXCELで使うことだけを考えればこういうことをやってもいいですが、pythonとかスクリプトで操作する人からするとこれは余計な処理なので、hayabusa専用のUIを作るのが良いような気がしてきました。

#477

[YamatoSecurity]

お返事が遅くなってすみません。比較とフィードバックありがとうございます。

1. オプションについて
   全フィールドの出力はあくまでルール作成と徹底的な調査のためのデバッグ情報のようなものなので、デフォルトでは出力したくないです。(※現在sigmaのdetailsに対応していないので、暫定的にそのためにもなりますが、今回の目的ではありません）
   デフォルトで出力すると、結果のファイルサイズが無駄に大きくなって、Threat Huntingで多くの端末から情報を送信する時に困るのと、それを見てしまう人が居るのでfast forensicsじゃなくなります。(全情報を最初から確認したいのであれば、その解析に特化したツール(Evtxecmd)が既にあるので、それを使ったら良いとなってしまいます）
   ので、オプションを追加して頂けますか？ (仕様に書いてあるように標準出力時でも全情報のカラムを追加したいです。(ルール作成で毎回ファイルに保存して、catで確認して、ファイル削除するのは意外と手間なので）

2. 今回はルール作成等で別のファイルを確認する手間が無いようにしているので、CSVカラムを追加するしかないと思います。
   小さいモニターしか持っていない人は仕方なく横にスクロールして貰うしかないと思います。フォレンジック調査している人であれば、ワイドやウルトラワイドのモニターか縦に長いモニターを使っている人が多いと思います。現在はdetailsも横に固定の文字列で定義してしまっているけど、いつかは各フィールドを配列にして、モニターを縦にしている人のためにフィールドを改行で区切れるようにしたいと思っています。(もしくは、X個のフィールドごとに改行を入れるとか、文字数を超えると改行を入れるとか）
   WindowsのEvent ViewerでイベントをCSVに出力したら改行がかなり入るけど、問題なくExcel等にインポートできるので、改行コードに注意すれば、いけると思います。（多分）

3. 専用の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モデルもありかも知れません。

[hach1yon]

1について
理由はあまり納得できるものが無いように思えますが、とりあえずオプションにしておきます。この機能自体がそもそも微妙なので、オプションにしておいた方がよさそうです。
fastforensicにならない....は見なければ良いだけですし、必要になった時に再実行する手間もありますしね。

[hach1yon]

2について
EXCELはカラム幅の制限があるので、ワイドやウルトラワイドのモニターを使っても、殆どの値は見れないです。縦に長いモニターを使っているなら、余計に見えないですね。今回はルール作成等で別のファイルを確認する手間が無いようにしているので、CSVカラムを追加するしかないと思います。というのもそんなことないのですが、もう作ってしまったので、このままにしたいと思います。

https://support.microsoft.com/ja-jp/office/excel-%E3%81%AE%E4%BB%95%E6%A7%98%E3%81%A8%E5%88%B6%E9%99%90-1672b34d-7043-467e-8e27-269d656771c3

以下の部分は自分がちょっと前に書いたこと同じだと思いますが、出来ないことはないです。ただ、このように表示すると更に見にくくなる人もいるので、とりあえず今回は実装しません。ただでさえオプションが多いのに、更に多くなってしまいそうという理由もあります。

いつかは各フィールドを配列にして、モニターを縦にしている人のためにフィールドを改行で区切れるようにしたいと思っています。

[hach1yon]

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の表現力や記述しやすさ等を元に決めればよいと思います。

[kazuminn]

本来はhayabusaにいれるべき機能ではないので、ちゃんと分けておきたいという気持ちもあります。

そうなんですよね。分けたい。
レコードの中身を全部出力するなら、subcommandにするのもありかな？と思うのですが、Dさんは「複雑化するのはあまり好まない」と言います。

ピボットキーワード処理が2gbのvetch で2分ほどかかっていますが、UIの方に処理を持っていくにしても、表示するのに、時間かかっちゃうと、イライラするかなと思います。

うーん、という気持ちです(ふわふわしてる)

[YamatoSecurity]

是非良いUIが作れそうであれば、作りましょう。
すぐ作れないと思うので、それまでにあとできるのは、実行時に重複しているフィールドを出力しない実装が難しいのであれば、タイムラインを使った後に重複しているフィールドを削除するオプションかツールを作ったら、データがかなり減って、一台のモニターに収まるかもしれません。

[hach1yon]

重複しているフィールドを消しても殆ど意味なかったので、実装しません。この機能は現状の仕様だと使い難いので、作り直すことになります。そのような機能に時間かけても意味ないので、今回はこのままリリースします。

[hach1yon]

本来はhayabusaにいれるべき機能ではないので、ちゃんと分けておきたいという気持ちもあります。

そうなんですよね。分けたい。 レコードの中身を全部出力するなら、subcommandにするのもありかな？と思うのですが、Dさんは「複雑化するのはあまり好まない」と言います。

ピボットキーワード処理が2gbのvetch で2分ほどかかっていますが、UIの方に処理を持っていくにしても、表示するのに、時間かかっちゃうと、イライラするかなと思います。

うーん、という気持ちです(ふわふわしてる)

@kazuminn
自分的にはサブコマンドでも良いような気はします。サブコマンドがrustのclapで簡単に実現できるなら、良いかなという感じです。後、既存のソースと混ざらいないようにモジュールを分けておけば、そこまで複雑度は上がらないような気もします。

2gbの処理に時間がかかるのはしょうがなくて、それはUIから実行してもterminalから実行しても時間がかかるのは変わらないので、後はUI上で待ち時間中に他の作業ができたりとか、時間がかかる処理であることをUI上で分かるようにするとか、そういう感じだと思います。

[hitenkoku]

@hach1yon

現状のusageを文字列に指定するやり方ではできませんが、メソッドチェーンの形でサブコマンド設定をすることはできます。Clapの今のバージョンでも可能なので投入すること自体は問題ないと思います。

複雑化するのはあまり好まないという話は処理の面としては @hach1yon のコメントの通りで、モジュールを分ければそれは問題ないと思っています。

@kazuminn

複雑になるのは好まないという話を出したのは #393 #412 での話であり、そちらの方では--outputのオプションが -pオプションの有無によって出力されるファイルが異なるという話があり、--outputのオプションの説明が複雑になるので避けたいという意図です。

今回のサブコマンドは指定したらoutput内での特定レコードが追加されるということでオプションに対して一意ではあるので、必須な機能であるかの話は置いといてコマンドの面では複雑にはならないかと思っていました。

[hach1yon]

まぁ、これは今すぐでもないので、次回のミーティングで時間があれば話しましょうか。

[hitenkoku]

打ち合わせの結果、v1.2の締切に合わせられそうならばv1.2に戻すとして、暫定的にマイルストーンをv1.2からv1.3に一応変更しておきました。