Dionaeaによる初めての生態観察
はじめに
T-Potを植え始めてからかれこれ2週間以上が経過し、サーバーも安定稼働もしてきたので、各ハニーポットの観察方法について調査していこうと思う。最初のターゲットとしては、ハニーポットの中でも人気が高いDionaeaについての観察方法をまとめてみる。Dionaeaを最初のターゲットにした理由としては、収集したマルウェアの保存場所や種類の特定に関する情報は色々と公開されているのだが、攻撃に関するログの見方や、攻撃の再現方法に関しての情報が全然なく、少し苦労したので。（検索方法が悪かったのと、ドキュメントちゃんと読め説はある）
Dionaeaとは
複数のサービスをネットワーク上に公開することにより、攻撃者からマルウェアのコピーを手に入れるための、マルウェア収集用のハニーポットという解釈。もちろん、攻撃に関するログも収集しているため、どのような方法でマルウェアに感染させられたのかを知ることができる。ちなみに、Dionaeaはハエトリグサという意味らしい。
Introduction — dionaea 0.8.0 documentation
稼働サービス
知らないサービスもあるが、こんな感じのものが動いている。
観察に利用するデータ
実際に調査してみた中で、このファイルやディレクトリ大事そうだなーと思うものを載せているため、他に大事そうなものがあったとしても調査の中で見なかったものに関しては登場してきません。
攻撃通信の生データ
サーバーへの要求(in)と応答(out)のラベルがついた攻撃通信のバイトデータで、攻撃を再現する場合に利用する。ファイル単独で見ても旨味は少ないので、関連するファイルをまとめて扱う必要がある。
/data/dionaea/bistreams
収集したマルウェア
ゲットだぜ！したマルウェア達の部屋。ファイル名はハッシュ値になっているため、VirusTotal で種類を調べることが可能。
/data/dionaea/binaries
インシデントログ
何によってインシデントと判定されるのかまでは調べきれていないが、インシデントに関する情報が入っている。bistreamsと違い、時系列かつ読みやすい形式で格納されている模様。
/data/dionaea/log/dionaea.sqlite
観察に必要なツールと使い方に関して
T-Potを運用しているサーバーか、いつも使っている端末にセットアップする。今回の環境では、観察に必要なデータをMacに持ってきてからツールを利用した。
# git clone https://github.com/DinoTools/dionaea.git cd /dionaea/modules/python/util
攻撃の再現方法
bistreamsに格納されているファイルとutilに含まれているretry.pyを使って、攻撃を再現をすることができる。事前にWiresharkなどでパケットをキャプチャしていれば、pcapファイルとしての保存も可能。
| オプション | 用途 |
|---|---|
| -t | bistreamsファイルのコピー先ファイル名 |
| -H | Socket通信での接続先IPアドレス(Dionaea稼働サーバーを指定) |
| -p | Socket通信での接続先Port番号(bistreamsファイルと同じPortを指定) |
| -r | 応答パケットを接続先から受信するかのフラグ（outの部分が必要かどうか） |
| -s | 要求パケットを接続先に送信するかのフラグ（inの部分が必要かどうか） |
| -f | 再現するbistreamsファイル |
完全に再現させるには-r -sは必須で、対象ホストはハニーポットが稼働しているサーバーにする。
python retry.py -t retrystream -H xx.xx.xx.xx -p 21 -r -s -f ftpd-21-::ffff:yy.yy.yy.yy-54hS7r
使用可能なオプションについてはpython retry.py --helpで確認するといい（コード量が少ないので、詳細を知りたい場合はコードを見るのもあり）
インシデントログの確認
dionaea.sqliteファイルとutilに含まれているreadlogsqltree.pyを使って、インシデントログの確認を行うことができる。
python readlogsqltree.py /data/dionaea/log/dionaea.sqlite
使用可能なオプションについてはpython readlogsqltree.py --helpで確認するといい。
観察シナリオ
自分なりの観察シナリオをまとめてみる。
インシデントが溜まる
binariesとかにマルウェアが溜まってきたーや、kibanaで見たら結構攻撃きてるなーなど、なんとなくログ溜まってきてそうだなと思うタイミングを調査のトリガーにしてみる。
# cd /data/dionaea/binaries # ls | wc -l 221
対象のホストを絞り込む
自分はbistreamsのディレクトリをサラーっと眺めて、気になるプロトコルや、通信量が多そうなファイル（マルウェアのダウンロードに成功してる）に目星をつけて、ホストを絞り込む。
# cd /data/dionaea/bistreams # ls -altrh | grep mssqld -rw------- 1 tpot tpot 1.8K Nov 7 09:13 mssqld-1433-::ffff:58.244.204.125-ozutsX -rw------- 1 tpot tpot 113K Nov 7 09:14 mssqld-1433-::ffff:58.244.204.125-lXNimU
インシデントログを確認する
いきなりbistreamsのファイルを使って再現するのもあれかなーと思うので、一旦dionaea.sqliteのログから全体像を確認する。
- 時系列と通信回数の確認
- わかりやすい形式でログが残っていれば概要を把握する
時系列と通信回数の確認では、一まとまりの攻撃に絞り込むのとbistreamsを再現したときに、どこの通信がインシデントログの一通信に当たるかを紐づけるために確認しています。（数が合わない場合があるのでここは追って調査予定。インシデントとして記録される条件が影響している？）
# python readlogsqltree.py -r ::ffff:58.244.204.125 /data/dionaea/log/dionaea.sqlite using database located at /data/dionaea/log/dionaea.sqlite 2018-11-07 09:12:08 connection 21147 mssqld tcp accept ::ffff:xx.xx.xx.xx:1433 <- ::ffff:58.244.204.125:35037 (21147 None) login - user:'sa' password:'' mssql fingerprint - hostname:'AHKJ-WEBSERVICE' cltintname:'Microl office' appname:'ODBC' mssql command - status:complete cmd:'exec sp_server_info 1 exec sp_server_info 2 exec sp_server_info 500 select 501,NULL,1 where 'a'='A' select 504,c.name,c.description,c.definition from master.dbo.syscharsets c,master.dbo.syscharsets c1,master.dbo.sysconfigures f where f.config=123 and f.value=c1.id and c1.csid=c.id set textsize 2147483647 set arithabort on' 2018-11-07 09:12:09 connection 21148 mssqld tcp accept ::ffff:xx.xx.xx.xx:1433 <- ::ffff:58.244.204.125:1537 (21148 None) login - user:'' password:'' mssql fingerprint - hostname:'AHKJ-WEBSERVICE' cltintname:'Microl office' appname:'ODBC' mssql command - status:complete cmd:'exec sp_server_info 1 exec sp_server_info 2 exec sp_server_info 500 select 501,NULL,1 where 'a'='A' select 504,c.name,c.description,c.definition from master.dbo.syscharsets c,master.dbo.syscharsets c1,master.dbo.sysconfigures f where f.config=123 and f.value=c1.id and c1.csid=c.id set textsize 2147483647 set arithabort on' mssql command - status:complete cmd:'SELECT @@VERSION ' mssql command - status:complete cmd:'use master ' 以下省略
攻撃を再現させて生データ確認
インシデントのタイムスタンプから２回コネクションが貼られてるなーというのを確認して、時間に若干ズレはあるけどbistreamsの一個めのファイルが2018-11-07 09:12:08のやり取りで、二個目のファイルが2018-11-07 09:12:09だろうなーと推測。
こちらも再生してみる。
$ python retry.py -t retrystream -H xx.xx.xx.xx -p 1433 -r -s -f mssqld-1433-::ffff:58.244.204.125-ozutsX doing mssqld-1433-::ffff:58.244.204.125-ozutsX $ python retry.py -t retrystream -H xx.xx.xx.xx -p 1433 -r -s -f mssqld-1433-::ffff:58.244.204.125-lXNimU doing mssqld-1433-::ffff:58.244.204.125-lXNimU
Wiresharkで見てみると（通信の一部）。
まとめ
と、観察するときにみるべきファイルや、観察の流れについては自分なりに整理できたと思うので、今後これをベースに攻撃方法の理解と、落としていったマルウェアの解析（動的、静的）を行っていけるといいな。（時間が足りれば・・・）
