ログ分析に基づくマルウェア解析の過程
ログ収集システムを用いたマルウェア解析を実際に体験して学んだことをメモしておこうと思います。
解析環境はWindowsです。
セキュリティオペレーションの流れ
まず、マルウェア解析を含むセキュリティオペレーションの一連の流れを示します。
| 順序 | 概要 |
|---|---|
| 1 | アラートシステム（Cybereason,SIEM等）が異常検知 |
| 2 | 異常と検知されたプロセス/ファイルの解析（Cybereason,SIEM等の示すログ情報と異常根拠を元に解析。必要に応じて感染ノードを回収して実ファイルの調査とユーザへの聴取。） |
| 3 | 分析後に対象がマルウェアか過検知かの判定 |
| 4 | マルウェアの場合、被害状況・現状の確認 |
| 5 | 対応（マルウェア削除、システムのスキャン、再発防止の仕組み構築、注意勧告、上長や関係部署への通達） |
ここでは、上記の内の2～3に該当するマルウェア解析について述べて行きたいと思います。また、コードの解析はアラートシステムに任せ、ログ情報を元にした解析に焦点を当てます。
マルウェア解析
今回はアラートシステムにCybereasonを用いた場合の解析について述べます。
注視するべき要点
ネットワークフォレンジックの観点から注視すべき要点は以下のものです。
| 単語 | 概要 |
|---|---|
| 場所 | IPアドレスと、それが存在する地域についての情報。攻撃の温床となるアドレスは偏っているので、怪しさの指標になる。C&CサーバやbotnetのIPアドレスはスキャンサービスのVirustotal等で調べられる。 |
| 時刻 | 攻撃・異常の発生時刻など。どのタイミングでどのような振る舞いをしているかは分析に重要。 |
| 期間 | 疑わしいプロセスが振る舞う期間。潜伏期間や攻撃期間などはマルウェアの動向を考察する上で参考になる。 |
| 方向性 | 通信が内向きか外向きかという方向性。外部通信であればC&C通信である可能性があり、内向きであれば横への展開（感染拡大）である可能性があるという推測ができる。 |
| ポート | トランスポート層でのポート番号。どのようなサービスにアクセスしようとしたか等を知る事が出来る。例えばポートスキャン実行時には複数の宛先ポートが検出される。 |
| データ量 | 通信量とも。不自然に大きなデータがやり取りされていれば、情報窃取やマルウェア注入などのインシデントを想起できる。 |
| 頻度 | 振る舞いの頻度。通信頻度が正規ユーザが行う頻度とかけはなれていた場合、悪意のあるプロセスがバックグラウンドでC&C通信を行っている可能性などが考えられる。 また、不審な振る舞いの頻度が高ければマルウェアであるとの判断につながる。 |
| 評価 | Reputation。マルウェアのハッシュ値、IPアドレス、ドメイン名、URLなどに対する評価。様々なマルウェアスキャン製品・サービスによって裏付けられた評価であり、分析対象がマルウェアか否かを判断する指標となる。 これを行うサービスとしてはVirustotal、IBM X-Forceなどがある。 |
| 履歴 | ログ情報。 プロセスが如何なる振る舞いをしているか、ある端末で起きている事象が他の端末でも起きていないか等の調査に役立てる。 |
| プロセス | プロセスの正当性の確認。異常なプロセスが親や子にいないか。プロセスの実行源となったファイルに署名はついているかなどを確認する。 |
| 状態 |
疑わしいプロセスが現段階でどのような状態にあるか。既にマルウェアとしての活動を停止しているのか、現在もまだ動作しているのかなど。 |
怪しいプロセスの具体的な情報例
上記に記された要点に沿って、実際のマルウェアで観測されがちな特徴を記述します。
ファイルのハッシュが既知のマルウェアと一致
ファイル名は自由に決めることができるため、マルウェア配布者は、マルウェアに無害そうな名前をつけることがあります。しかし、そのファイルの内容までを悪意のないものに偽装するのは難しいことです。そこで、マルウェア解析者は、ファイルの内容を識別するためにハッシュを用います（※本筋から逸れるのでハッシュや衝突に関する説明は省略します）。既知のマルウェアのハッシュと、検知した疑わしいファイルのハッシュが一致すれば、ファイル名が異なっても中身が同じでマルウェアの可能性が高いと判断できます。ハッシュとしてはSHA1やMD5がよく用いられるようです。
既知のマルウェアとハッシュが一致するものがあるか検索する際にはVirustotalなどを利用します。
ファイルパスが怪しい
例えば実行ファイルがユーザローカル領域のtempフォルダ配下から実行されている場合などは、ユーザの意図に関わらずマルウェアから実行されている場合があります。
例）Emdiviなど
また、おおよそ正規の実行ファイルはProgramFilesに置かれます。マルウェアの場合、すぐに発見されないようにフォルダの深い階層に設置するような場合があります。
アイコンや名前・拡張子がおかしい
拡張子が.pdf.exeのように2重になされている場合、2重拡張子といい、ユーザに実行ファイルではない偽装を行う意図が考えられます。2重拡張子には、.exeを表示領域から見切れさせるために、.pdf____________.exeと冗長な命名をするようなものもあります。また、実行ファイルにも関わらずドキュメントファイルのアイコンなどを装う場合もマルウェアの可能性があります。
実行ファイルが実行ファイルを作成している
ドロッパー（Dropper）と呼ばれるマルウェア等にありがちな挙動です。ドロッパーは、それ自体にC&C通信などの諜報機能を持ちませんが、実行されると、悪意のある挙動を行うマルウェア（ダウンローダー等）を作成して子プロセスとして実行します。
目立った諜報活動を行う子プロセスのマルウェアが削除されても、そのマルウェアを作成・実行するドロッパーが生きていればまたマルウェアが作成されるので、ドロッパーも特定して削除する必要があります。
ヒューリスティック分析（振る舞い検知）を行っているCybereason等では、実行ファイルを作成するような動作もマルウェアとして検知してくれるようです。また、仮にマルウェアが検知された場合、解析過程でその親プロセスを辿ることができればドロッパーに行きつくことがあるのでプロセスの親子関係も大事な要素です。
信頼できそうな製作者や製品名だが電子署名がない
ファイルにはその製作者や製品名を記述できますが、その他にも作成元を証明するための電子署名をつけることができます。
マルウェアの作成者は、この製作者や製品名を、偽装したアイコンやファイル名、ダウンロード時の状態に合わせてもっともらしいものに設定します。例えば、Flash Playerの脆弱性につけこんでダウンロードさせたマルウェアの場合、製作者をadobe systems incorporated、製品名をadobe flash player utilityなどとすることがあり、この情報だけだと一見安全そうに見えます。ただし、電子署名までは偽装できないので、この電子署名が無いという情報だけで一転してとても信頼性のないファイルとなります。
現状の把握
サイバー攻撃、特に標的型攻撃を、その手順ごとに段階化した考えをサイバー・キル・チェーンといいます。以下の表にその概要を示します。
| 名称 | 概要 |
|---|---|
| 偵察 | あらゆる偵察行動を指します。企業のサイトや公開情報から、攻撃対象の情報を得る。また、攻撃の踏み台に出来そうな脆弱性のあるノードを探すなど。脆弱性の調査にはポートスキャンなどが行われる。 |
| 武器化 | 脆弱性のあるサイトに悪意のあるコードを埋め込んだり、攻撃ツール（rootkit,dropper）やマルウェアを作成する。 |
| 配送 | なりすましメールなどにマルウェアを添付して攻撃対象に送り込んだり、悪意のあるコードを埋め込んだサイトに攻撃対象を誘導して、ドライブバイダウンロード（ユーザに気づかれないようにDL）させる。 |
| エクスプロイト/攻撃 | メールの添付ファイルを開かせたり、ダウンロードさせた実行ファイルを実行させる。 |
| インストール | エクスプロイトの結果としてマルウェアが設置される。 |
| 遠隔操作 | C&Cサーバに接続させることにより、感染端末を遠隔操作する。 |
| 侵入拡大 | 通称、横への展開とも呼ばれ、ネットワーク内で脆弱性を探して侵入先を拡大する。 |
| 目的実行 | 目的の情報を窃取する。 |
現状を把握する場合、このサイバー・キル・チェーンがどの段階かを把握すると良いかもしれません。また、攻撃対策時には、このサイバー・キル・チェーンをどこで切れるかを考慮します。
過検知について
正規の正常なソフトウェアが誤ってマルウェアと検知されてしまうことを過検知といいます。とりあえず疑わしきは罰するという路線では業務がままならず、必要である正常なソフトウェアは削除しないようにしなくてはならないため、過検知かどうかを正しく判断する技術が重要になってきます。
対応
対応は技術的対応と業務的対応に分けられると思います。
技術的対応としては例えば
・C&Cサーバのアドレスをブラックリストに登録して通信させないようにする
・マルウェアやその生成源を特定して削除する
・感染の疑われるノードのスキャン
・感染の疑われる端末の押収と実端末上での捜査
などが挙げられます。
業務的な対応としては例えば
・感染先ネットワークの管理者や上長、セキュリティチームへの報告
・インシデント関係者への聴取と警告
などが挙げられます。
リンク
ここには参考になる書籍やサイトのURLについてメモしておきます。順次更新予定です。
参考書籍
- ジョセフ・D. スローン,Joseph D. Sloan 著『ネットワークトラブルシューティングツール』O'Reilly
- あきみち,空閑 洋平 著『インターネットのカタチ-もろさが織り成す粘り強い世界-』オーム社
公開BGP情報を基にしたネットワーク可視化プロジェクトの紹介など
参考サイト
- 確認君＋ Webページへアクセスすることで相手側へ知られてしまう情報を確認できるサイトです。
tracerouteの仕様について
tracerouteは、指定したホストまでの経路（経由したノード）を表示するツールです。自社ネットワークで障害が起こった時に“どのノードまではパケットが正常に届いているのか”等を調べる時に使います。もしも使用者が攻撃者であれば“攻撃パケットが標的リンクを通るかどうか”等を調べるために使うこともできるでしょう。また、あるノードまでは応答が早く、あるノードを境に応答が遅くなる場合、このノード間がボトルネックリンクではないかという推測もできます。
このtracerouteですが、IPヘッダのTTL値を利用していることはよく知られています。しかしＩＰ層以上の仕様/実装がWindowsとUnix系OS（Linux）では違います。この点について、大学の実験実習で学んだのでメモとして書き留めておこうと思います。
各OSでの仕様を知ることは、Firewallでtracerouteを通したい場合等に役に立ちます。また、AS等では当該パケットを観測することでtracerouteが行われたことを認知し、攻撃者による攻撃前の調査パケット（予兆）を得るといったことも可能になるかと思われます。
各OS共通の仕様
IPヘッダまでの仕様は各OSで共通です。IPヘッダにはTTLフィールドといものがあります。TTL値は経由できるホップ数を表しており、IPパケットは経由したノードごとにTTL値を1減らされ、0になるとそのノードにおいて破棄されます。tracerouteでは、調査パケットのIPヘッダのTTL値が1の場合,2の場合,3の場合...と試していき、最終的に対象ホストに到達するまでこれを繰り返すというものです。
つまり、tracerouteコマンドを打つと、まずはIPヘッダのTTLフィールド（パケットが経由できるノード数を表すフィールド）を1としたパケットが送りだされます。経由できるノード数は1なので、最初の中継器でパケットが受け取られてTTL値が1減らされ0になるので、パケットは最初の中継器で破棄されます。次のパケットはTTL値が2なので、2つ目の中継器で破棄されます。次のパケットはTTL値が3なので、3つ目の中継器で破棄され...という風に対象ホストに至るまでのそれぞれのノードで破棄されるパケットがでてくるのです。
traceroute実行ノードは、これらの破棄されたノードからの応答を受け取ることで、対象ホストまでの全ルートを得ます。
Windwosでの仕様
Windowsではtracerouteはtracertコマンドとして実装されています。Windowsでのtracerouteは簡単に言うとpingです。すなわち、IPの上層はICMPとなっています。traceroute実行ノードによる調査パケットは全てICMP type8 code0（echo request）として送られます。ただし、それぞれの中継ノードではTTL値が0になってパケットは破棄されるので、中継ノードからtraceroute実行ノードに対してICMP type11 code0(time exceeded)が返されます。唯一宛先ホストのみが、echo requestに対する応答として、ICMP type0 code0(echo reply)を返します。
traceroute実行ノードはecho replyが返ってきたら宛先ホストまでのtraceが完了したと解釈することができます。ちなみにそれぞれの応答（time exceededおよびecho reply）内には送信者の情報が記載されているので、traceroute実行ノードは中継ノードの情報を得られます。
※補足
ちなみに、tracerouteでは実行ノードとそれぞれの中継器間の情報（ＲＴＴ等）しかわかりませんが、現行のWindowsでは中継器間の情報もわかるpathpingなるものがあったりするそうで…
Unix系OS（Linux）での仕様
Linux等では、IPパケットの中身はICMPではなくUDPになっています（ただし指定すればICMPでも可能）。UDPヘッダの宛先ポート番号を、絶対に使われていないであろうポート番号に設定して送ります。TTL値が0になる中継ノードからは、実行ノードに対して、Windowsのtracertと同じようにICMP type11 code0（time exceeded）が返されます。しかし、宛先ホストには待ちうけていないポート宛ての要求が来たのでパケットを破棄し、実行ノードに対してICMP type3 code3(port unreachable)を返します。
実行ノードはport unreachableを得れば宛先ノードまでのtraceが完了したと判断します。以下はtraceroute後の宛先からのport unreachableをwiresharkで実際にキャプチャした際の画像です。
※補足
ちなみに、実際に使われるであろう宛先ポートを指定すると、運用されているサービスから応答が来てしまう可能性があるので、使われていないポートを指定します。また、メジャーなサービスの宛先ポート番号はウェルノウンポートとなるので、多くの実装では33434からインクリメントしてパケットを送信しますので、Firewallでもしtracerouteを通す場合これを意識するといいと思います。また念のため1度に2つ（資料によっては3つ）調査パケットを送るようです。（つまり1つのTTLに対して異なる宛先ポート番号を指定した2つ又は3つのパケットを送ります。）
結論
IP層より上層で使うプロトコルと、それに伴った宛先ホストまで到達したかどうかの判断方法が異なります。
今後のtraceroute関連の記事について
tracerouteの高速化については前から興味がありましたので、tracerouteのコードなんかを見ながら記事がかければなーと思います。あとtracerouteを応用した研究等（既存のものでいうと某大学様のASパス推測など）についても言及できればと思います。
Linux(CentOS)のディレクトリ構造
サーバをいじりはじめて最初に感じたのが、各ディレクトリの意味をちゃんと理解できていないなーということでした。
サーバを管理する上では吐かれたログを見たり、システムの設定をいじったりしないといけないので、ディレクトリ構造については知っておくべきだと思い、現行のディレクトリ構造の標準などについて調べてみました。
※間違いがあったら指摘して戴けると嬉しいです。
目次
FHS（Filesystem Hierarchy Standard）について
FHSはLinuxディストリビューションの多くが従っているファイルシステム階層に関する標準だそうです。自分が利用しているCentOSもこれに則っているようです。
2017年1月現在での現行標準はv3.0のようです。
※ファイルシステムとは、記憶装置に格納されたデータ（ファイル）を、ユーザが操作できるようにするためにOSが提供している機能です。複数の関連するファイル（及びディレクトリ）を束ねるのがディレクトリになります。
Windows系OSではデバイスごとにツリー構造を持ちますが、UNIX系OSでは、すべてのデバイス上のファイルをひとつの階層構造（木構造）のいずれかのディレクトリ内に配置する仮想ファイルシステムになっており、この木構造の根にあたるのがルートディレクトリになります。
ディレクトリ構造
Linuxのファイルシステム最上位はルートディレクトリ（"/"）です。※ルートディレクトリは厳密には/直前の空白らしいのですが/と表すのが慣例となっています。
その直下のディレクトリは下記のようになっています。
| 名前 | 格納される内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| /bin |
最低限必要な基本コマンドの実行ファイル（binaries）が格納されている。 例えば、chmod、sh、ls、cp、pwd、chown、psなど。 ※/usr/binと違いシングルユーザモードで使う最低限のもの置いている点。/binにないものを/usr/binに置いている。 |
||||||||||||||||||||
| /boot | 起動（ブート）に必要なファイル。カーネルの他にもinitrd等が含まれる。 | ||||||||||||||||||||
| /dev | 接続されたデバイスを制御する際に用いるデバイス・ファイル（スペシャル・ファイル）が置かれる。データ入出力を1文字（バイト）単位で行うマウス・キーボードのようなものをキャラクタデバイス、ある一定の大きさ（ブロック）単位で行うHDD・メモリ・FDのようなものをブロックデバイスと呼ぶ。 デバイスファイルに対し、open()などのシステムコールを用いると、カーネルドライバがファイルではなくデバイスへアクセスする仕組みになっている。 主なデバイスファイル名とその詳細については以下のようになる。
|
||||||||||||||||||||
| /etc |
固有の設定ファイルが置かれる。設定ファイルの拡張子と定義されているわけでないものの、confとつくものが割とある。例えばWebサーバの設定はhttpd.conf(httpd/conf)などとして置かれる。 |
||||||||||||||||||||
| /home | ユーザのホームディレクトリ。 | ||||||||||||||||||||
| /lib | /bin配下や/sbin配下にある実行ファイルに必要なライブラリ。 | ||||||||||||||||||||
| /media | リムーバブルなデバイスのマウントポイント。 | ||||||||||||||||||||
| /mnt | ファイルシステムの一時的なマウントポイントで、通常は空である。 | ||||||||||||||||||||
| /opt | アプリケーションのパッケージのインストール用。 | ||||||||||||||||||||
| /proc |
procfs(process filesystem)というプロセスの情報をファイルシステムに見せかけたものをマウントするディレクトリ。ここではプロセスや場合によってはカーネルの情報が置かれる。 |
||||||||||||||||||||
| /root | rootユーザのホームディレクトリ。 | ||||||||||||||||||||
| /sbin | システム管理関係のコマンド実行ファイルが置かれる。 | ||||||||||||||||||||
| /tmp | 一時的に利用するファイル置き場。システムを再起動したときには消去されている。 | ||||||||||||||||||||
| /usr | マルチユーザで共有可能なリソース、アプリケーションが置かれるディレクトリ。
|
||||||||||||||||||||
| /var | 内容が変化する可変データが置かれるディレクトリ。ログファイルやアプリケーションキャッシュなど。 |
この他にもディストリビューションやOSごとに固有のディレクトリだったり、インストールしたサブシステムによって追加されるディレクトリがあるようです。自分のCentOSではselinuxという強制アクセス制御のためのディレクトリ等もありました。
補足
■initrdとはなんぞや
聞いたことがあってもよくわかっていなかったものの一つです。Wikipediaさん曰く次の通りらしいです。
初期RAMディスク（initial ramdisk）はLinuxカーネルのブート時に一時的なルートファイルシステムをメモリに読み込むための方式。
カーネルのbootにはファイルシステムを参照しないといけないが、ファイルシステム構築にはカーネルが必要という矛盾があり、これを打開するため、カーネルブート時には一時的なファイルシステムをメモリ上に展開するということでしょうか…？
うーん確信が持てない…ということでさらに調べていくとめちゃくちゃわかりやすく解説されていらっしゃるサイト様がありましたので、リンクを張っておきます。
つまりポイントは以下
- 現状のLinuxでは、カーネルはモジュール化により各種ドライバを内包していない。なぜなら、ドライバをすべてカーネルに内包させると容量が肥大化するため。現在は必要に応じてモジュールをカーネルに組み込む形を取っている。
- つまりブート時にカーネル単体をメモリ上に展開しても、ドライバがないのでHDDを認識できない問題が起こる。
- initrdはブートする際に必要なHDDドライバなどのモジュールを、カーネルと一緒にメモリに展開するために記述されるファイル
モノリシックカーネルとドライバのモジュール化についても勉強になりましたので、ブートの仕組みやこれらについても後で改めて別記事にまとめようと思います。
自宅サーバのスペック等
前置き
サーバ構築・運用技術を養うために自宅でWebサーバ等を構築していきたいと思います。幸いマシン自体は5年前に購入したものがあったので、これを利用したいと思います。
古いモデルですが、勉強用途として使う分にはどうなのか、電力消費量はどうなのかなど今後体感したことをちょこちょこ書いて行きたいと思います。その際に、同じく勉強中の読者の方の後学になれば良いなということで簡単にサーバのスペックを記載しておきます。
サーバのスペック
マシンスペック
製品：HP ProLiant MicroServer N54Lモデル（ディスクレスモデル）
|
リソース名 |
詳細 |
|---|---|
|
プロセッサ |
AMD Turion(TM) Ⅱ NEO N54Lプロセッサー（2.2GHz） |
|
キャッシュメモリ |
1MB L2×2 |
|
メモリ |
4GB×1 |
|
HDD |
250GB×4 |
※(R)や(TM)は登録商標について表すものです。
搭載OS
CentOS 6.7
Ubuntuは大学で利用しており、別のディストリビューションも触ってみたかったのでCentOSを選択しました。もしかしたら今後変更することもあるかもしれませんが、とりあえずこれで行こうと思います。
プロフィール
書いてる人
寝ることとおいしいご飯を食べることが好きな、そこらへんの工学系の学生です。
専攻は機械だったこともあれば電気だったこともあります。現在は情報です。
はてなＩＤ（white-hawk）は好きな色と好きな動物を組み合わせただけなんですが、厨二病っぽくなってしまいました。
ブログで書くこと
ちょっぴり社会経験を積んでみて、実践的な技術力が欠けていると感じたので、実践的な取り組みを行ったりして学んだことをメモしていこうと思いブログを開設しました。
実践的な技術だけでなく理論寄りの記事も書くかもしれません。
勉強中の身ですので、もし記述内容に間違いがあった場合指摘して戴けると嬉しいです。
また、たまにおいしいご飯に関する記事も書くかもしれませんがご了承ください。
