JPCERT/CCによるエンドポイントログ分析トレーニング用のコンテンツをKibanaでながめてみる

#はじめに

JPCERT/CCから提供されている[分析トレーニング用のエンドポイントログ](https://blogs.jpcert.or.jp/ja/2020/07/log_analysis_training.html)をElasticの[Kibana](https://www.elastic.co/jp/kibana)を使ってながめてみます。

* [ログ分析トレーニング用コンテンツの公開](https://blogs.jpcert.or.jp/ja/2020/07/log_analysis_training.html) (2020/07/28, JPCERT/CC)
 * [Log Analysis Training](https://jpcertcc.github.io/log-analysis-training/)
 * [JPCERTCC/log-analysis-training](https://github.com/JPCERTCC/log-analysis-training) (github)
 * [ハンズオン解説資料](https://github.com/JPCERTCC/log-analysis-training/tree/master/Material)

まず[Hands-on1](https://github.com/JPCERTCC/log-analysis-training/tree/master/Hands-on/Handson1)および[Hands-on3](https://github.com/JPCERTCC/log-analysis-training/tree/master/Hands-on/Handson3)で提供されているSecurityログとSysmonログ(CSV形式)を[Elastic Common Schema (ECS)](https://www.elastic.co/jp/blog/introducing-the-elastic-common-schema)へマッピングしてElasticsearchへ投入します。ここでは[Winlogbeat](https://www.elastic.co/jp/beats/winlogbeat)のテンプレートをベースに作成したものを利用します。

Elasticsearch用に追加したコンテンツや簡単なスクリプトなどはForkさせていただいた[こちら](https://github.com/rhpenguin/log-analysis-training)へ置いておきました。

#利用するソフトウェア
- OS: Ubuntu 18.04
- Elasticsearch (7.6.1) 
- Kibana (7.6.1)

#トレーニングコンテンツ（CSV形式）をJsonへ変換
公開されているSecurityログとSysmonログ(CSV形式)をElastic Common Schema (ECS)へマッピングしてJson形式へ変換します。変換用の簡単な[スクリプト](https://github.com/rhpenguin/log-analysis-training/blob/master/Hands-on/Handson1/elastic/csv2json.py)を書きましたのでそれを使います。

```shell:Hands-on1
$ git clone https://github.com/rhpenguin/log-analysis-training.git
$ cd log-analysis-training/Hands-on/Handson1/elastic
$ python3 csv2json.py > handson1.json
```

```shell:Hands-on3
$ cd log-analysis-training/Hands-on/Handson3/elastic
$ python3 csv2json.py > handson3.json
```

※[handson1.json](https://github.com/rhpenguin/log-analysis-training/blob/master/Hands-on/Handson1/elastic/handson1.json)および[handson3.json](https://github.com/rhpenguin/log-analysis-training/blob/master/Hands-on/Handson3/elastic/handson3.json)はElasticsearchの[Bulk API形式](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)で出力しています。

#Elasticsearchにテンプレートを設定
Winlogbeat 7.8.1のものをベースに[テンプレート](https://github.com/rhpenguin/log-analysis-training/blob/master/Hands-on/Handson1/elastic/handson1_template.json)を作成しましたので設定します。

```shell
$ cd log-analysis-training/Hands-on/Handson1/elastic
$ curl -XPUT 'localhost:9200/_template/jpcertcc-log-analysis-training' -H 'Content-Type: application/json' --data-binary @handson1_template.json
```

※このhandson1_template.jsonのテンプレート定義は共通のためHands-on3用に設定する必要はありません。

最近の[ECSテンプレート定義](https://github.com/elastic/ecs/blob/master/schemas/process.yml)では（例えば大文字小文字を区別せずに検索したいなど）必要そうな文字列フィールドは最初からkeyword型とtext型のマルチフィールド定義になっているんですね～

（例）process.command_lineフィールド

```json
"process": {
  "properties": {
...
    "command_line": {
      "ignore_above": 1024,
      "type": "keyword",
      "fields": {
        "text": {
          "norms": false,
          "type": "text"
        }
      }
    },
...
```

※ process.command_line.textでmatchできる

#Elasticsearchへログデータ(Json形式)を投入

Bulk APIでログデータをElasticseachへ投入します。

```shell:Hands-on1
$ cd log-analysis-training/Hands-on/Handson1/elastic
$ curl -XPOST -H 'Content-Type: application/json' 'localhost:9200/_bulk' --data-binary @handson1.json
```

```shell:Hands-on3
$ cd log-analysis-training/Hands-on/Handson3/elastic
$ curl -XPOST -H 'Content-Type: application/json' 'localhost:9200/_bulk' --data-binary @handson3.json
```

インデクスは以下のようにハンズオン毎に作成しています（テンプレートは共通）。

|ハンズオン名|Elasticsearchインデクス名|
|---|---|
|Hands-on1|jpcertcc-log-analysis-training-handson1|
|Hands-on3|jpcertcc-log-analysis-training-handson3|

![jpcert_log_analysis1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/fe939911-d90f-a727-1b39-8a2bd4e9e5fa.png)

※画像クリックで別タブで拡大表示

#Kibanaのインデクスパターンを作成
「jpcertcc-log-analysis-training-*」というパターンで作成しておきます。
![jpcert_log_analysis0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/dcdb2279-5348-ec24-ebe7-ed01e693b98b.png)

#お題の「win.exe」のログを検索してみる
[ハンズオン解説資料](https://github.com/JPCERTCC/log-analysis-training/tree/master/Material)のハンズオン１のお題にある「win.exe」を対象にしてログソースをまたがって検索してみる（ECS）。

* プロセス自体：process.name: "win.exe" or
* 子プロセス：process.parent.name: "win.exe" or
* 孫プロセス：(process.parent.name: "cmd.exe" and process.parent.pid:2688)

![jpcert_log_analysis2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/6c208309-e68d-7545-f607-c85e42930dc5.png)

通信を実行・・・子プロセスであるcmd.exeがmz.exe（コマンド引数がそもそもアヤシすぎかつEXEファイル配置場所が「C:\Intel\Logs\mz.exe」とアヤシイ・・・）という（孫）プロセスを起動しているのでSysmonログに記録されているこのEXEファイルのハッシュ値をVirusTotalで検索してみると・・・[Mimikatz](https://www.virustotal.com/gui/file/5f921bf97123c4601e30a40d8e66cf78d335c3c8ddb710d764e4786a25deb595/detection)っぽいですね。
![jpcert_log_analysis17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/98aa487d-c49f-2a34-bddb-af30f7c2acec.png)

#どんなプロセスが起動されているかをながめてみる

![jpcert_log_analysis3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/15e8bd39-8449-bcba-0f8e-5ef7a5dd1b05.png)

[ハンズオン解説資料](https://github.com/JPCERTCC/log-analysis-training/tree/master/Material)や「[インシデント調査のための攻撃ツール等の実行痕跡調査に関する報告書](https://www.jpcert.or.jp/research/ir_research.html) [JPCERT/CC]」にあるアヤシそう（？）なプロセス名（グラフの横軸）がいくつか実行されていますね。縦軸はログ数（プロセス起動回数）です。

![jpcert_log_analysis4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/c804401f-5644-1587-bf75-dad6e3678f75.png)

同じグラフをプロセス起動数の少ない順（昇順）でひっくり返してみました。レアプロセスを見てみるのもありですね。

#cmd.exeやPowerShell.exeから起動されているプロセスを検索してみる

* process.parent.name: "cmd.exe" or
* process.parent.name: "powershell.exe"

![jpcert_log_analysis5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/d0abd95f-4df1-874f-2ae6-daf5445da7ae.png)

アヤシさ満載・・・

他にも例えばcscript.exeやwscript.exe、mshta.exe、rundll32.exe/mshtml.dll、LNKやVBAなどの条件で不審なふるまいをながめてみても良いかもですね。

#タスクスケジューラから起動されているプロセスを検索してみる

* process.parent.name: "taskeng.exe"

![jpcert_log_analysis6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/324b54c1-e022-6e5a-0f94-3fb3ae489bdd.png)

#WMI経由で実行されているプロセスを検索してみる

* process.parent.name: "wmiprvse.exe"

[WmiPrvSE.exe](https://qiita.com/rhpenguin/items/52baf3be61d630d96c5a)の子プロセスを検索してみます。
![jpcert_log_analysis7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/8a4ebc8d-e19c-0a8d-2f8a-f2010b846ea3.png)

見つかりませんでした。

#プロキシ経由以外の通信状況をながめてみる

「[Find Evil - Know Normal](https://digital-forensics.sans.org/community/posters)！！！」
アヤシい社内ホスト間（PC間）通信やプロキシを経由しない通信（数）・・・
※端末のIPアドレス一覧が[ハンズオン解説資料](https://github.com/JPCERTCC/log-analysis-training/tree/master/Material)に含まれています。

###接続(connect)側 (IP)
![jpcert_log_analysis8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/04aa12f1-bd93-10a1-6c98-22a295cbcd67.png)

###接続(connect)側 (Port)
![jpcert_log_analysis10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/f7958d4c-67c0-3808-af3a-4ca0fe1e3172.png)

###受信(listen)側 (IP)
![jpcert_log_analysis9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/9ce43a52-7147-8e7d-75f8-ba9f903fd3fc.png)

###受信(listen)側 (Port)
![jpcert_log_analysis11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/00f1f775-7856-acfd-5b27-49874a3096f0.png)

#子プロセスの起動状況を検索してみる
普通は子プロセスを起動しないようなプロセス名があるか・・・
![jpcert_log_analysis12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/556ef687-0276-ef2f-426a-2bdff0bcef53.png)

#プロセス起動（コマンドライン引数）に通信っぽい指定がないか検索してみる

###（例）httpの文字列を含むものを検索

* process.command_line.text: "http"（textマッチ）
![jpcert_log_analysis13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/7e382c16-31a3-0343-6d20-da6894336dbf.png)

cmd.exeやpowershell.exeのアヤシさ満載・・・

###（例）netコマンドの文字列を含むものを検索
![jpcert_log_analysis18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/9620980f-7a04-61c2-a588-a54dbff20b0c.png)

最近はPC間でアクセスという運用はレア（？）でしょうかね・・・

他にもRDP通信とかIPアドレスやURLやWindows UNCパターンを含むとかの条件で検索してみてもいいかもですね。

#プロセス起動（コマンドライン引数）にレジストリアクセスっぽい指定がないか検索してみる

（例）レジストリのルート名を含むものを検索

![jpcert_log_analysis14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/54875158-2c78-858e-020b-7164e1643ecb.png)

Tempとかアヤシさ満載・・・

#普通は通信しなさそうなプロセス名がないかながめてみる

![jpcert_log_analysis15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/0a5dcba0-de60-ed3f-6965-18a8347050ba.png)

#普通はファイル共有通信しなさそうな宛先ホスト名（例：PC間通信など）がないかながめてみる
![jpcert_log_analysis16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/362125/7ce62280-6888-57af-74db-da9ab1d9a35d.png)

#まとめ
「なんか通常(Normal)と違う・・・」という気づきにKibanaを使う例をいくつか書いてみました。

実際のログ解析のやり方については[ハンズオン解説資料](https://github.com/JPCERTCC/log-analysis-training/tree/master/Material)に非常に詳細に書かれておりかなり実践的でおすすめです！