JP6219550B1 - プログラム、情報処理装置、及び情報処理方法 - Google Patents

プログラム、情報処理装置、及び情報処理方法 Download PDF

Info

Publication number
JP6219550B1
JP6219550B1 JP2017099584A JP2017099584A JP6219550B1 JP 6219550 B1 JP6219550 B1 JP 6219550B1 JP 2017099584 A JP2017099584 A JP 2017099584A JP 2017099584 A JP2017099584 A JP 2017099584A JP 6219550 B1 JP6219550 B1 JP 6219550B1
Authority
JP
Japan
Prior art keywords
file
condition
program
function
ransomware
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017099584A
Other languages
English (en)
Other versions
JP2018195155A (ja
Inventor
孝志 吉川
孝志 吉川
圭 菅原
圭 菅原
優 関原
優 関原
Original Assignee
三井物産セキュアディレクション株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三井物産セキュアディレクション株式会社 filed Critical 三井物産セキュアディレクション株式会社
Priority to JP2017099584A priority Critical patent/JP6219550B1/ja
Priority claimed from US15/645,270 external-priority patent/US10264002B2/en
Application granted granted Critical
Publication of JP6219550B1 publication Critical patent/JP6219550B1/ja
Publication of JP2018195155A publication Critical patent/JP2018195155A/ja
Application status is Active legal-status Critical

Links

Images

Abstract

【課題】マルウェアによる攻撃を有効に阻止することができるプログラム、情報処理装置、及び情報処理方法を提供する。
【解決手段】所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する。
【選択図】図71

Description

本発明は、プログラム、情報処理装置、及び情報処理方法に関する。

近年、ランサムウェアと呼ばれる種類のマルウェアが世界的に流行している。

ランサムウェアは、他の一般的なマルウェアと同じくインターネットやメール経由で端末に感染する。

ランサムウェアは一度感染すると、端末上の一部のファイルまたは全体を暗号化(ロック)し、ファイルの使用または端末の使用を不可能にした上で、身代金(ランサム:ransom)を支払うよう要求する。暗号化されたファイルを復元することの見返りに金銭を要求する脅迫型のマルウェアである。

ランサムウェアの場合、感染すると直ちにファイルの暗号化が開始される。このため、そのランサムウェアがセキュリティ製品にとって未知の検体である場合、パターンファイルによる検知等の通常の検知では間に合わず、ファイルの暗号化を阻止することは困難である。仮にランサムウェアの感染に早期に気付き、直ちに端末の電源を切る等の処置をとったとしても、ランサムウェアによりいくらかのファイルが暗号化されることは免れず、被害を完全に阻止することは非常に困難である。

ランサムウェアを検出するための方法として、ランサムウェアがユーザーによる操作や入力状態に関係なく、突然ウィンドウを表示する等の特徴的動作をすることを利用して、キーボード、マウス等の入力インターフェースの操作状態と、ディスプレイデバイスの変更状態とを監視してランサムウェアを検出する方法が知られている(特許文献1参照)

米国特許出願公開第2014/0181971号明細書

従来の方法ではランサムウェアのようなマルウェアによるファイルの暗号化等の攻撃を有効に阻止することが困難であった。

本発明の目的は、マルウェアによる攻撃を有効に阻止することができるプログラム、情報処理装置、及び情報処理方法を提供することにある。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスから呼び出されるファイル書込関数がデータを書き込むファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル書込関数が、前記ファイルパスのファイルのヘッダを書き換えるという第2の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

上述したプログラムにおいて、前記判断部は、前記第1の条件及び前記第2の条件に加えて、前記ファイルパスのファイルがヘッダを有しないテキストファイルであるという第3の条件とを満足する場合には、前記所定のプロセスをランサムウェアとして処理するか否かの処理の選択肢をユーザーに提示するようにしてもよい。

上述したプログラムにおいて、前記判断部は、前記第1の条件及び前記第2の条件に加えて、前記所定のプロセスから、前記ファイル書込関数の呼び出しの前に、前記ファイルパスに含まれるパスと同一のパスにおける他のファイルを検索するファイル検索関数が呼びだされているという第4の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断するようにしてもよい。

上述したプログラムにおいて、前記判断部は、前記第1の条件及び前記第2の条件に加えて、前記所定のプロセスから、前記ファイル書込関数の呼び出しの後に、前記ファイルパスに含まれるパスと同一のパスを移動元のパスとし、前記ファイルパスに含まれるパスと同一のパスを移動元のパスとするファイル移動関数が呼びだされているという第5の条件を満足する場合に、前記所定のプロセスをランサムウェアと判断するようにしてもよい。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスから呼び出されるファイル削除関数が削除するファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記所定のプロセスから呼び出される前記ファイル削除関数が削除する前記ファイルパスと同一のファイルパスを移動先とする第1のファイル移動関数が既に呼び出されているという第2の条件と、前記所定のプロセスから呼び出される第2のファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第3の条件と、前記第1のファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル削除関数が削除する前記ファイルパスのファイルのヘッダとが相違しているという第4の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスから呼び出されるファイル移動関数の移動先のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第2の条件と、前記ファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル移動関数の移動先のファイルパスのファイルのヘッダとが相違しているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスから呼び出されるファイル書込関数がデータを書き込むファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル書込関数が、前記ファイルパスのファイルのヘッダを書き換えるという第2の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する手順を実行させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスから呼び出されるファイル削除関数が削除するファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記所定のプロセスから呼び出される前記ファイル削除関数が削除する前記ファイルパスと同一のファイルパスを移動先とする第1のファイル移動関数が既に呼び出されているという第2の条件と、前記所定のプロセスから呼び出される第2のファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第3の条件と、前記第1のファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル削除関数が削除する前記ファイルパスのファイルのヘッダとが相違しているという第4の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する手順を実行させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスから呼び出されるファイル移動関数の移動先のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第2の条件と、前記ファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル移動関数の移動先のファイルパスのファイルのヘッダとが相違しているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する手順を実行させることを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスから呼び出されるファイル書込関数がデータを書き込むファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル書込関数が、前記ファイルパスのファイルのヘッダを書き換えるという第2の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスから呼び出されるファイル削除関数が削除するファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記所定のプロセスから呼び出される前記ファイル削除関数が削除する前記ファイルパスと同一のファイルパスを移動先とする第1のファイル移動関数が既に呼び出されているという第2の条件と、前記所定のプロセスから呼び出される第2のファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第3の条件と、前記第1のファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル削除関数が削除する前記ファイルパスのファイルのヘッダとが相違しているという第4の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスから呼び出されるファイル移動関数の移動先のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第2の条件と、前記ファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル移動関数の移動先のファイルパスのファイルのヘッダとが相違しているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスから呼び出されるファイル書込関数がデータを書き込むファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル書込関数が、前記ファイルパスのファイルのヘッダを書き換えるという第2の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスから呼び出されるファイル削除関数が削除するファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記所定のプロセスから呼び出される前記ファイル削除関数が削除する前記ファイルパスと同一のファイルパスを移動先とする第1のファイル移動関数が既に呼び出されているという第2の条件と、前記所定のプロセスから呼び出される第2のファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第3の条件と、前記第1のファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル削除関数が削除する前記ファイルパスのファイルのヘッダとが相違しているという第4の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスから呼び出されるファイル移動関数の移動先のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、前記ファイル移動関数の移動元のファイルパスと同一のファイルパスに対して、前記所定のプロセスからファイル書込関数が既に呼び出されているという第2の条件と、前記ファイル移動関数の移動元のファイルパスのファイルのヘッダと、前記ファイル移動関数の移動先のファイルパスのファイルのヘッダとが相違しているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

上述したプログラムにおいて、前記第3の条件は、マッピング時の前記実ファイルのヘッダ情報とアンマッピング時の前記実ファイル又は前記仮想ファイルのヘッダ情報とが相違することであるようにしてもよい。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

上述したプログラムにおいて、前記判断部は、前記所定のプロセスにより、前記仮想ファイルを作成する命令、又は、前記仮想ファイルを前記メモリにマッピングする命令が呼び出されると、前記第1の条件を満足すると判断するようにしてもよい。

上述したプログラムにおいて、前記判断部は、前記所定のプロセスにより、前記仮想ファイルを前記メモリからアンマッピングする命令、前記仮想ファイルの一部を前記ディスクに書き込む命令、又は、前記仮想ファイルのハンドルを閉じる命令が呼び出されると、前記第2の条件を満足すると判断するようにしてもよい。

上述したプログラムにおいて、前記判断部は、前記所定のプロセスにより、前記仮想ファイルを作成する命令、又は、前記仮想ファイルを前記メモリにマッピングする命令が連続して呼び出されると、前記第4の条件を満足すると判断するようにしてもよい。

上述したプログラムにおいて、前記コンピューターを、更に、前記所定のプロセスにより前記実ファイルが前記仮想ファイルとして前記メモリ上にマッピングされる時に前記実ファイルをバックアップしたバックアップファイルを生成し、前記判断部が前記所定のプロセスをランサムウェアと判断した場合には、前記バックアップファイルを前記ディスク上の前記実ファイルに書き戻すバックアップ部として機能させるようにしてもよい。

本発明の一態様によるプログラムは、コンピューターを、所定のプロセスによりディスク上の実ファイルへの書き込み命令が発せられたという第7の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第8の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部として機能させることを特徴とする。

上述したプログラムにおいて、前記判断部は、前記書き込み命令により前記実ファイルのファイル構造が不適切な状態に変更されているという第9の条件を更に満足する場合に、前記所定のプロセスをランサムウェアと判断するようにしてもよい。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手段を実行させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手段を実行させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手段を実行させることを特徴とする。

本発明の一態様によるプログラムは、コンピューターに、所定のプロセスによりディスク上の実ファイルへの書き込み命令が発せられたという第7の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第8の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手段を実行させることを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理装置は、所定のプロセスによりディスク上の実ファイルへの書き込み命令が発せられたという第7の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第8の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部を有することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

本発明の一態様による情報処理方法は、所定のプロセスによりディスク上の実ファイルへの書き込み命令が発せられたという第7の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第8の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断することを特徴とする。

以上の通り、本発明によれば、所定のプロセスから呼び出されるファイル書込関数がデータを書き込むファイルパスと同一のファイルパスに対して、所定のプロセスからファイル読出関数が既に呼び出されているという第1の条件と、ファイル書込関数が、ファイルパスのファイルのヘッダを書き換えるという第2の条件とを満足する場合に、所定のプロセスをランサムウェアと判断するようにしたので、マルウェアによる攻撃を有効に阻止することができる。

また、本発明によれば、所定のプロセスによりディスク上の実ファイルが実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、所定のプロセスにより仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の実ファイル又は仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、所定のプロセスをランサムウェアと判断するようにしたので、マルウェアによる攻撃を有効に阻止することができる。

一般的な情報処理装置を示すブロック図である。 コンピュータープログラムの動作をコンピューターのハードウェアとの関連で示す説明図(その1)である。 コンピュータープログラムの動作をコンピューターのハードウェアとの関連で示す説明図(その2)である。 本発明の原理(その1)に関し、ランサムウェアCryptoLockerによるファイル暗号化の説明図(その1)である。 本発明の原理(その1)に関し、ランサムウェアCryptoLockerによるファイル暗号化の説明図(その2)である。 本発明の原理(その1)に関し、ランサムウェアCryptoLockerによるファイル暗号化の説明図(その3)である。 本発明の原理(その1)に関し、ランサムウェアCryptoLockerによるファイル暗号化の説明図(その4)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その1)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その2)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その3)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その4)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その5)である。 本発明の原理(その1)に関し、ランサムウェアCryptoWallによるファイル暗号化の説明図(その6)である。 本発明の原理(その1)に関し、ランサムウェアCERBERによるファイル暗号化の説明図である。 本発明の原理(その1)に関し、ランサムウェアTeslaCryptによるファイル暗号化の説明図(その1)である。 本発明の原理(その1)に関し、ランサムウェアTeslaCryptによるファイル暗号化の説明図(その2)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その1)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その2)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その3)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その4)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その5)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その6)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その7)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その8)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その9)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その10)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その11)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その12)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その13)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その14)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その15)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その16)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その17)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その18)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その19)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その20)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その21)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その22)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その23)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その24)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その25)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その26)である。 本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その27)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その1)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その2)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その3)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その4)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その5)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その6)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その7)である。 本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その8)である。 本発明の原理(その2)に関し、一般的なファイル操作とファイルマッピングによるファイル操作の相違について説明する図である。 本発明の原理(その2)に関し、ランサムウェアSporaによるファイル暗号化時のファイル操作の流れを示す図である。 本発明の原理(その2)に関し、ランサムウェアSporaによるファイル操作とハードウェアとの関係を示す図である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その1)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その2)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その3)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その4)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その5)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その6)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その7)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その8)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その9)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その10)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その11)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その12)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その13)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その14)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その15)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その16)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その17)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その18)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その19)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その20)である。 本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その21)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その1)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その2)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その3)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その4)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その5)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その6)である。 本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法を説明する説明図(その7)である。

[情報処理装置]
本発明が適用される一般的な情報処理装置及びその動作について図1乃至図3を用いて説明する。

図1は一般的な情報処理装置を示すブロック図である。

標準的なスタンドアロン環境における情報処理装置10は、コンピューター(PC)20と、外部周辺装置30とから構成されている。

コンピューター(PC)20は、命令を実行するCPU21と、データおよびプログラムを格納するハードディスク22と、データやプログラムをCPU21が読み込むためのメモリ23と、ユーザーの操作を受け付けるマウスやキーボードのような入出力装置24と、操作内容や処理結果等を表示するディスプレイ25等から構成されている。

外部周辺装置30は、処理結果等を印刷するためのプリンター31や、USBメモリ等の外部記憶装置32等から構成されている。

次に、図2及び図3を用いて、コンピュータープログラム、すなわち、コンピューターに行わせる処理の手順を決められた形式(プログラム言語)に従って書き表したものを実行させる場合の一連の動作について、コンピューター20におけるCPU21、ハードディスク22、メモリ23等のハードウェアとの関連で説明する。

コンピューター20が起動する前は、オペレーションソフトウェア(OS)のプログラムやデータを含むOSデータと、コンピューター20で実行させるプログラムと、文書、図面等のユーザーデータ等がファイルとしてハードディスク22に格納されている(図2(a))。メモリ23にはプログラムやデータ等は展開されていない。

コンピューター20が起動して、CPU21が、ハードディスク22に格納されたOSデータをメモリ23にロードする命令を実行すると、OSデータがメモリ23上にプロセスとして展開される(図2(b))。

次に、CPU21がメモリ23上のOSデータのプロセスを実行して、ハードディスク22に格納されたプログラムにアクセスして、そのプログラムを読み込む(図2(c))。ハードディスク22に格納されたプログラムはメモリ23にロードされ、メモリ23上にプロセスとして展開される(図3(a))。

次に、CPU21がメモリ23上のプログラムのプロセスを実行して、ハードディスク22に格納されたユーザーデータにアクセスして、ハードディスク22へのデータの読み書きを行う(図3(b))。

このように、オペレーションソフトウエアやプログラムにより、CPU21、ハードディスク22、メモリ23との間での動作が行われる。

なお、本明細書において「プロセス」とは「メモリ23上に展開されたプログラム」のことであり、「プログラム」とは「ハードディスク等に格納されたプログラム(ファイル)」のことである。理解しやすさのため「プロセス」である「メモリ23上に展開されたプログラム」のことを単に「プログラム」と記載することもある。

また、本明細書において、Windows API関数の文字列末尾に付与されている"W"や"Ex"は、付与されていないものと同じ意味合いとする。例えば、"FindFirstFileW"は"FindFirstFile"と同義であり、"MoveFileEx"は"MoveFile"と同義である。

[発明の原理(その1)]
本発明の原理(その1)について図4乃至図16を用いて説明する。

(ランサムウェアの分析)
本願発明者等は、まず、国内外で被害が報告されている主なランサムウェア複数種について、ファイルの暗号化を行う際のファイル操作に関わる挙動について解析した。具体的には、4種類のランサムウェア、CryptoLocker、CryptWall、CERBER、TeslaCryptのファイル操作の挙動について解析した。
(a)ランサムウェアCryptoLockerの分析
APIモニター(API Monitor)という解析ツールを用いてランサムウェアCryptoLockerの動作を分析した。APIモニターは、アプリケーションから呼ばれるWindows API(Application Programming Interface)コールの引数、戻り値を、アプリケーションを変更することなくモニターすることができるプログラムである。Windowsは登録商標である。

図4にランサムウェアCryptoLockerのファイル暗号化時に呼び出されたAPIのログ(log)を示す。ランサムウェアCryptoLockerにより、フォルダ"C:\Python27\Lib\compiler"内のファイルが順次暗号化される場合のログである。

1行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

2行目のCreateFileWは、引数"C:\Python27\Lib\compiler\consts.py"のファイルを開くというWindows API関数である。

3−4行目のReadFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\consts.py"を読み出すというWindows API関数である。

5−7行目のWriteFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\consts.py"にデータを書き込むというWindows API関数である。

1−7行目のログは次のことを示している。

1行目のFindNextFileにより次のファイルを検索し、2行目のCreateFileWにより引数"C:\Python27\Lib\compiler\consts.py"のファイルを開き、3−4行目のReadFileと5−7行目のWriteFileにより、ファイル"C:\Python27\Lib\compiler\consts.py"の暗号化が実行される。

8行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

9行目のCreateFileWは、引数"C:\Python27\Lib\compiler\future.py"のファイルを開くというWindows API関数である。

10−11行目のReadFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\future.py"を読み出すというWindows API関数である。

12−15行目のWriteFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\future.py"にデータを書き込むというWindows API関数である。

8−15行目のログは次のことを示している。

8行目のFindNextFileにより次のファイルを検索し、9行目のCreateFileWにより引数"C:\Python27\Lib\compiler\future.py"のファイルを開き、10−11行目のReadFileと12−15行目のWriteFileにより、ファイル"C:\Python27\Lib\compiler\future.py"の暗号化が実行される。

16行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

17行目のCreateFileWは、引数"C:\Python27\Lib\compiler\misc.py"のファイルを開くというWindows API関数である。

18−19行目のReadFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\misic.py"を読み出すというWindows API関数である。

20−22行目のWriteFileは、CreateFileWで開いたファイル"C:\Python27\Lib\compiler\misic.py"にデータを書き込むというWindows API関数である。

16−22行目のログは次のことを示している。

16行目のFindNextFileにより次のファイルを検索し、17行目のCreateFileWにより引数"C:\Python27\Lib\compiler\misic.py"のファイルを開き、18−19行目のReadFileと20−22行目のWriteFileにより、ファイル"C:\Python27\Lib\compiler\misic.py"の暗号化が実行される。

以下同様にして、フォルダ"C:\Python27\Lib\compiler\"内のファイルが順次暗号化される。

このログから、ランサムウェアCryptoLockerは、次のようにしてファイルを暗号化していることがわかる。
(1)FindFirstFile、FindNextFileによりファイルを検索する。FindFirstFile、 FindNextFileは、セットで使用される検索用のWindows API関数である。
(2)CreateFileにより暗号化対象のファイルを開く。
(3)開いたファイルに対し、ReadFile、WriteFileでファイルを書き換えて暗号化する。すなわち、ReadFileにより、暗号化対象ファイルのファイル内容を読み込み、読み込んだ暗号化対象ファイル内容をマルウェアが暗号化し、暗号化された後のデータをWriteFileにより元の暗号化対象ファイルに書き込む。

図5にランサムウェアCryptoLockerのファイル暗号化時に呼び出されたAPIのログを示す。ランサムウェアCryptoLockerにより、フォルダ"C:\User\Public\Videos"下にあるファイル"Wildlife.wmv"が検索され暗号化される場合のログである。

3行目のFindFirstFileは、引数"C:\Users\Public\Videos\*.*"の最初のファイルを検索するというWindows API関数である。

4−9行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

10行目のFindFirstFileは、引数"C:\Users\Public\Videos\Sample Videos\*.*"の最初のファイルを検索するというWindows API関数である。

11−13行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

14行目のCreateFileWは、引数"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"のファイルを開くというWindows API関数である。

15−16行目のReadFileは、CreateFileWで開いたファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"を読み出すというWindows API関数である。

17−19行目のWriteFileは、CreateFileWで開いたファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"にデータを書き込むというWindows API関数である。

20行目のFindNextFileは、次のファイルを検索するというWindows API関数である。

3−9行目のログは次のことを示している。

3行目のFindFirstFileと4−9行目のFindNextFileにより、フォルダ"C:\Users\Public\Videos\*.*"内のファイルを検索したが、ファイルが見つからない。

10−14行目のログは次のことを示している。

10行目のFindFirstFileにより、フォルダ"C:\Users\Public\Videos\*.*"より下層のフォルダ"C:\Users\Public\Videos\Sample Videos\*.*"に移行し、11−13行目のFindNextFileにより、フォルダ"C:\Users\Public\Videos\Sample Videos\*.*"内を検索し、ファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"を見つけたので、14行目のCreateFileWにより開く。

15−20行目のログは次のことを示している。

CreateFileWにより開いたファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"を、15−16行目のReadFileと17−19行目のWriteFileにより、暗号化する。

そして、20行目のFindNextFileにより、フォルダ"C:\Users\Public\Videos\Sample Videos\*.*"内の次のファイルを検索する。

図5のように、あるフォルダ下にあるファイルが検索され暗号化される場合も、図4と同様に、FindFirstFile、FindNextFile、CreateFile、ReadFile、WriteFileにより、ファイルを検索し、検索されたファイルを書き換えて暗号化する。

図6は、ランサムウェアCryptoLockerによりアクセスされる前と後のファイル"Wildlife.wmv"の状態を示す。図6(a)が、ランサムウェアCryptoLockerによりアクセスされる前の状態であり、図6(b)が、ランサムウェアCryptoLockerによりアクセスされた後の状態である。

図6に示すように、ランサムウェアCryptoLockerによりアクセスされた後には、暗号化されたファイル"Wildlife.wmv"のヘッダが書き換えられている。

図7は、ランサムウェアCryptoLockerにより暗号化される前と後のファイル"Wildlife.wmv"のヘッダを示す。図7(a)が、ランサムウェアCryptoLockerにより暗号化される前のヘッダであり、図7(b)が、ランサムウェアCryptoLockerにより暗号化された後のヘッダである。

図7に示すように、ファイル"Wildlife.wmv"の先頭から末尾までの全てのバイトの部分が書き換えられている。少なくとも、バイナリファイルであれば、ファイルの種類や、サイズ、ファイルの種類に応じた各種情報の情報を表す「ヘッダ」と呼ばれる部分(通常、先頭から数バイトから数十バイト)が書き換えられている。

以上のことから、ランサムウェアCryptoLockerの暗号化時のファイル操作に関する挙動は、次の通りであることがわかった。
(1)ファイル検索のWindows API関数であるFindFirstFile、FindNextFileが呼び出される。
(2)ファイルを開くWindows API関数であるCreateFileが呼び出される。
(3)CreateFileの対象ファイルに、ファイルを読み出すWindows API関数であるReadFileと、ファイルにデータを書き込むWindows API関数であるWriteFileが呼び出される。
(4)CreateFileの対象ファイルのヘッダが、ランサムウェアCryptoLockerのアクセス前後で相違している。
(b)ランサムウェアCryptoWallの分析
プログラムのデバッグを支援するプログラムであるデバッガ(Debugger)を用いてランサムウェアCryptoWallの動作を分析した。

ランサムウェアCryptoWallは、まずファイルを検索するWindows API関数であるFindFirstFileWにより、ルートドライブから端末内のファイルを検索する。

図8は、ランサムウェアCryptoWallがファイル検索を開始する際の様子を示すデバッガの画面のキャプチャである。

最初の図8(a)のキャプチャは、FindFirstFileWに、ドライブのルートである"C:\*"が引数として渡されていることを示している。

次の図8(b)のキャプチャは、FindFirstFileWに、ドライブのルート"C:\*"より下層のフォルダである"C:\Users\*"が引数として渡されていることを示している。

その次の図8(c)のキャプチャは、FindFirstFileWに、フォルダ"C:\Users\*"より下層のフォルダである"C:\Users\Public\*"が引数として渡されていることを示している。

更にその次の図8(d)のキャプチャは、FindFirstFileWに、フォルダ"C:\Users\Public\*"より下層のフォルダである"C:\Users\Public\Videos\*"が引数として渡されていることを示している。

Windows API関数であるFindFirstFileWによる、ルートドライブから端末内の更なるファイル検索の結果、最初に"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"が検索され、ランサムウェアCryptoWallにより暗号化される。

図9は、ランサムウェアCryptoWallがファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"を暗号化する際の様子を示すデバッガの画面のキャプチャである。

最初の図9(a)のキャプチャは、Windows API関数であるCreateFileWにより、ファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"が開かれていることを示している。

次の図9(b)のキャプチャは、Windows API関数であるReadFileと、Windows API関数であるWriteFileが交互に呼び出され、ファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"が所定のサイズ分ずつ書き換えられて暗号化されていることを示している。

その次の図9(c)のキャプチャは、Windows API関数であるMoveFileが呼び出され、元のファイル"C:\Users\Public\Videos\Sample Videos\Wildlife.wmv"のファイル名を暗号化後の別のファイル名に変更されていることを示している。

図10は、ランサムウェアCryptoWallによりアクセスされる前と後のファイル"Wildlife.wmv"の状態を示す。図10(a)が、ランサムウェアCryptoWallによりアクセスされる前の状態であり、図10(b)が、ランサムウェアCryptoWallによりアクセスされた後の状態である。

図10に示すように、ランサムウェアCryptoWallによりアクセスされた後には、フォルダ"C:\Users\Public\Videos\Sample Videos\*.*"内に元のファイル名"野生動物.wmv(Wildlif.wmv)"とは別のファイル名に変更され、ファイルのヘッダが書き換えられている。

図11は、ランサムウェアCryptoWallにより暗号化される前と後のファイル"Wildlife.wmv"のヘッダを示す。図11(a)が、ランサムウェアCryptoLockerにより暗号化される前のヘッダであり、図11(b)が、ランサムウェアCryptoLockerにより暗号化された後のヘッダである。暗号化されたファイルはファイル名が変更されている。

図11に示すように、ファイル"Wildlife.wmv"の先頭から末尾までの全てのバイトの部分が書き換えられている。少なくとも、バイナリファイルであれば、ファイルの種類や、サイズ、ファイルの種類に応じた各種情報の情報を表す「ヘッダ」と呼ばれる部分(通常、先頭から数バイトから数十バイト)が書き換えられている。

次に、別のファイルを暗号化する際の様子について説明する。

図12及び図13は、ランサムウェアCryptoWallがファイル"C:\Users\Public\Pictures\Sample Pictures\Tulips.jpg"を暗号化する際の様子を示すデバッガの画面のキャプチャである。

最初の図12(a)のキャプチャは、Windows API関数であるCreateFileにより、ファイル"C:\Users\Public\Pictures\Sample Pictures\Tulips.jpg"が開かれていることを示している。

次の図12(b)のキャプチャは、Windows API関数であるReadFileと、Windows API関数であるWriteFileが繰り返し呼び出されることを示している。

その次の図13のキャプチャは、ファイル"C:\Users\Public\Pictures\Sample Pictures\Tulips.jpg"が暗号化により破損され、サムネイルで表示できなくなっていることを示している。更に、Windows API関数であるMoveFileEXが呼び出され、元のファイル"C:\Users\Public\Pictures\Sample Pictures\Tulips.jpg"が暗号化後の別のファイル名"C:\Users\Public\Pictures\Sample Pictures\p3EiSzLkWhfU5pgrD5SX9PdYPyP5ICa5iXzySi34oaY=.E08A29776586FC717E27.breaking_bad"に変更されていることを示している。

以上のことから、ランサムウェアCryptoWallの暗号化時のファイル操作に関する挙動は、次の通りであることがわかった。
(1)ファイル検索のWindows API関数であるFindFirstFile、FindNextFileが呼び出される。
(2)ファイルを開くWindows API関数であるCreateFileが呼び出される。
(3)CreateFileの対象ファイルに、ファイルを読み出すWindows API関数であるReadFileと、ファイルにデータを書き込むWindows API関数であるWriteFileが呼び出される。
(4)CreateFileの対象ファイルのヘッダが、ランサムウェアCryptoWallのアクセス前後で相違している。
(5)ファイルを移動するWindows API関数であるMoveFileExが呼び出され、移動元の移動先が同じでファイル名が変更される。
(c)ランサムウェアCERBERの分析
プログラムのデバッグを支援するプログラムであるデバッガ(Debugger)を用いてランサムウェアCERBERの動作を分析した。

ランサムウェアCERBERは、まずファイルを検索するWindows API関数であるFindFirstFile、FindNextFileにより、端末内のファイルを検索し、特定の拡張子を持つファイルを暗号化対象ファイルとして、そのリストをあらかじめ作成する。

次に、リスト化した暗号化対象ファイルを、Windows API関数であるCreateFileWにより順に開いたのち、Windows API関数であるReadFileによりファイルを一度読み出し、その後、Windows API関数であるWriteFileによりファイルにデータを書き込むことにより暗号化を行う。更に、WriteFileによるデータの書き込みにより暗号化が終了すると、Windows API関数であるMoveFileWにより、同一フォルダにファイルを移動、すなわちファイル名の変更が行われる。

図14は、ランサムウェアCERBERがファイルを暗号化する際の様子を示すデバッガの画面のキャプチャである。

最初の図14(a)のキャプチャは、Windows API関数であるCreateFileWにより、ファイル"C:\Python27\Lib\unittest\test\test_assertions.py"が開かれていることを示している。

次の図14(b)のキャプチャは、Windows API関数であるReadFileにより、CreatFileWで開いたファイルを読み込むことを示している。

更に次の図14(c)のキャプチャは、Windows API関数であるWriteFileにより、CreatFileWが開いたファイルにデータを書き込むことを示している。

更に次の図14(d)のキャプチャは、Windows API関数であるMoveFileWが呼び出され、CreatFileWが開いたファイルのファイル名を変更されたことを示している。

以上のことから、ランサムウェアCERBERの暗号化時のファイル操作に関する挙動は、次の通りであることがわかった。
(1)ファイル検索のWindows API関数であるCreateFileが呼び出される。
(2)CreateFileの対象ファイルに、ファイルを読み出すWindows API関数であるReadFileと、ファイルにデータを書き込むWindows API関数であるWriteFileが呼び出される。
(3)CreateFileの対象ファイルのヘッダが、ランサムウェアCERBERのアクセス前後で相違している。
(4)ファイルを移動するWindows API関数であるMoveFileExが呼び出され、移動元の移動先が同じでファイル名が変更される。
(d)ランサムウェアTeslaCryptの分析
プログラムのデバッグを支援するプログラムであるデバッガ(Debugger)を用いてランサムウェアTeslaCryptの動作を分析した。

ランサムウェアTeslaCryptは、まずファイルを検索するWindows API関数であるFindFirstFile、FindNextFileにより、Cドライブ直下から端末内のファイルを検索する。暗号化対象ファイルである特定の拡張子を持つファイルが存在した場合、Windows API関数であるCreateFileWにより開いたのち、Windows API関数であるReadFileを複数回実行してメモリ上にファイルを読み出し、そのメモリ上のファイルを暗号化し、その後、Windows API関数であるWriteFileを複数回実行して、暗号化対象ファイルを上書きする。

図15は、ランサムウェアTeslaCryptがファイルを暗号化する際の様子を示すデバッガの画面のキャプチャである。

最初の図15(a)のキャプチャは、Windows API関数であるFindFirstFile、FindNextFileにより、Cドライブ直下から端末内のファイルを検索していくことを示している。

次の図15(b)のキャプチャは、Windows API関数であるCreateFileWにより、ファイル"C:\Users\test\Desktop\おとり.png"が開かれていることを示している。

更に次の図15(c)のキャプチャは、Windows API関数であるReadFileにより、CreatFileWが開いたファイルを複数回にわけて読み出すことを示している。

更に次の図15(d)のキャプチャは、Windows API関数であるWriteFileにより、CreatFileWが開いたファイルにデータを複数回にわけて書き込むことを示している。

図16は、ランサムウェアTeslaCryptにより暗号化される前と後のファイル"C:\Users\test\Desktop\おとり.png"のヘッダを示す。図16(a)が、ランサムウェアTeslaCryptoにより暗号化される前のヘッダであり、図16(b)が、ランサムウェアTeslaCryptoにより暗号化された後のヘッダである。

図16に示すように、ファイル"おとり.png"の先頭から末尾までの全てのバイトの部分が書き換えられている。少なくとも、バイナリファイルであれば、ファイルの種類や、サイズ、ファイルの種類に応じた各種情報の情報を表す「ヘッダ」と呼ばれる部分(通常、先頭から数バイトから数十バイト)が書き換えられている。

以上のことから、ランサムウェアTeslaCryptの暗号化時のファイル操作に関する挙動は、次の通りであることがわかった。
(1)ファイル検索のWindows API関数であるFindFirstFile、FindNextFileが呼び出される。
(2)ファイル検索のWindows API関数であるCreateFileが呼び出される。
(3)CreateFileの対象ファイルに、ファイルを読み出すWindows API関数であるReadFileと、ファイルにデータを書き込むWindows API関数であるWriteFileが呼び出される。
(4)CreateFileの対象ファイルのヘッダが、ランサムウェアTeslaCryptのアクセス前後で相違している。

(本発明の原理)
本願発明者等は、これら4種類のランサムウェアの分析結果から、ファイルを暗号化する際のファイル操作の挙動に、次のような共通する挙動があることに気がついた。
(1)ファイルを開くWindows API関数であるCreateFileが呼び出される。
(2)CreateFileの対象ファイルに、Windows API関数であるReadFile、WriteFileが1回以上呼び出される。
(3)CreateFileの対象ファイルのヘッダが変化している。

一般のアプリケーションで、このような挙動をするものは想定しにくく、ランサムウェア特有の挙動である。

そこで、本願発明者等は、このような挙動を検出することにより、ファイルを暗号化しようとする未知のランサムウェアを確実に検出し、未知のランサムウェアによる攻撃を有効に阻止することができると考え、本発明を着想するに至った。

[第1実施形態]
本発明の第1実施形態によるプログラム、情報処理装置及び情報処理方法について図17乃至図43を用いて説明する。

(本実施形態の概要)
本実施形態の概要について図17及び図18を用いて説明する。

本実施形態では、ハードディスク22に保存されたユーザーデータへアクセスするという挙動を有するプログラムの全ての挙動が検出対象である。

CPU21がメモリ23上のOSデータのプロセスを実行して、ハードディスク22に格納されたプログラムにアクセスして、そのプログラムを読み込み(図2(c))、ハードディスク22に格納されたプログラムがメモリ23にロードされ、メモリ23上にプロセスとして展開される(図3(a))前に、メモリ23に本発明プログラムのプロセスを常駐させておく(図17(a))。

本発明プログラムは、ランサムウェアが導入される危険性のある状態となる前であればいつ実行してメモリ23上にプロセスとして常駐させてもよい。

例えば、スタートアッププログラムとして、コンピューターの起動時に起動させておく。Windows OSには、PCの起動と共に実行されるプログラムとして「スタートアッププログラム」が登録できる仕組みがある。本実施形態では、その仕組みを利用し本発明プログラムをスタートアッププログラムとして登録しておく。これにより、本発明プログラムがPCの起動直後からメモリ23上に配置している状態にする。

また、PCの起動時にプログラムを起動する方法としては、レジストリやサービスの仕組みを使用する方法もあるが、いずれの方法を用いてもよい。

これにより、PCの起動直後から常にコンピューターをランサムウェアから保護することができる。

本発明プログラムは、図17(a)に示すように、ハードディスク22に格納されたプログラムがメモリ23にロードするという動作と、CPU21がプログラムを実行するという動作との間に割り込む。CPU21によるプログラムに基づく動作をフックすることにより、プログラムが実行される直前で、そのプログラムの挙動を本発明プログラムの監視下に置く。

これにより、これ以降、監視対象プログラムの全ての挙動は、本発明プログラムが実行直前に把握することができる。必要に応じて、監視対象プログラムの処理に機能を加えたり、変更したりすることができる。

本発明プログラムにより、監視対象プログラムの挙動が、ランサムウェア特有の挙動であると判断された場合には、図17(b)に示すように、本発明プログラムは、監視対象プログラムがハードディスク22内のファイルにアクセスを行おうとする直前に、そのアクセスをブロックする。このようにして、未知のランサムウェアによる攻撃をブロックしてファイルの暗号化を阻止する。

本発明プログラムは3つの機能を有する。本発明プログラムの3つの機能について図18を用いて説明する。

第1の機能は、現在動作中のプログラムや、後ほど起動するプログラムである監視対象プログラムが使用するWindows APIをフックする機能である。図18に示すように、本発明プログラムから、現在起動中のプロセス、すなわち、notepad.exe、WINWORD.exe、calc.exe、Ramsomware.exe、cmd.exe、…のプロセスが使用するWindows APIをフックする。

第2の機能は、フックしたWindows APIにより、監視対象プログラムの挙動を本発明プログラムに通知、問い合わせをして、その結果に基づいて監視対象プログラムがランサムウェアであるか判断する機能である。

第3の機能は、フックしたWindows APIからの通知の受領、記録、問い合わせに応答する機能である。

第1の機能と第3の機能は、常駐している本発明プログラムの機能であり、第2の機能は、監視対象プログラム内に組み込まれる本発明プログラムの機能である。

(フック対象のWindows API関数)
本発明プログラムは、監視対象プロセスにおいて、ランサムウェアの分析結果から得られた共通の挙動であるWindows API関数をフックすることにより、ランサムウェアの検知および防御を実現する。

ランサムウェアの共通の挙動であるWindows API関数とは、本発明の原理で指摘したように、CreateFile(ファイル作成関数(ファイルハンドル取得関数))、(ファイル生成関数)、ReadFile(ファイル読出関数)、WriteFile(ファイル書込関数)である。

本実施形態では、共通のWindows API関数である、ファイルを開きファイルハンドルを取得するためのCreateFile(ファイル生成関数)はフック対象とせず、ReadFile(ファイル読出関数)、WriteFile(ファイル書込関数)のみをフック対象としている。それは次のような理由からである。

まず、共通のWindows API関数である、ReadFile(ファイル読出関数)、WriteFile(ファイル書込関数)を実行するためには、ファイルのハンドルを取得することは事前に必須の処理であるので、ReadFile(ファイル読出関数)、WriteFile(ファイル書込関数)をフック対象とするだけで、ファイルのハンドルを取得することを検出できる。

また、ファイルのハンドルを取得するためには、CreateFile(ファイル生成関数)以外のWindows API関数、例えば、OpenFile(ファイルオープン関数)でも実現可能であるので、CreateFile(ファイル生成関数)はファイルのハンドルを取得するために必須のWindows API関数とは言えない。

(HookReadFile)
HookReadFileは、ReadFile(ファイル読出関数)をフックするWindows API関数である。

HookReadFileは、通常のReadFileの動作に加えて、本発明プログラムに対して、次の情報(a)〜(c)を通知する機能を付加したWindows API関数である。

通知手段としては、プロセス間通信等、プロセスの動作に大きな遅延を発生させない程度の高速な手法が望ましい。ソケット通信やファイルによる受け渡し等でも、高速に実現できる環境であれば、いかなる方法でもよい。
(a)通知元API名。フックするWindows API関数の名前であるReadFileである。
(b)自身のプロセスID。フックするReadFileを呼び出す監視対象プロセスのプロセスIDである。
(c)ReadFileの対象ファイルパス。通知元APIであるReadFileのパラメータに指定されたファイルハンドルを示すファイルパスである。

ここで「ファイルパス」とは、その「ファイル」を保存している「フォルダ」に辿り着くまでに階層を重ねたフォルダの「経路(path)」を含めたものである。例えば、ハードディスクの「Cドライブ」上のフォルダ「Users」内のフォルダ「user」内のフォルダ「Desktop」内にあるファイル「note.doc」の「ファイルパス」は次の通りである。

C:\Users\user\desktop\note.doc
また、ファイルパス(C:\Users\user\desktop\note.doc)からファイル名(note.doc)を除いたファイルパス(C:\Users\user\desktop\)のことを「フォルダパス」と言う。

HookReadFile(ReadFileのフック関数)から通知を受けた本発明プログラムは、通知された内容、すなわち、API名、プロセスID、ファイルパスを、順次、通知記録データとしてメモリ23に保存する。この通知記録データは、後述するHookWriteFile(WriteFileのフック関数)において使用される。

なお、オペレーティングシステムではプロセスIDを再利用する機能があるので、長時間継続していると、異なるプロセスに対して偶発的に同じプロセスIDが割り当てられる可能性がある。このような偶発的なプロセスIDの一致によるランサムウェアの誤検知を防止するため、通知記録データを定期的にクリアすることが望ましい。

通知記録データの定期的クリアの間隔は任意であるが、長くともオペレーティングシステムの終了時または再起動時にはクリアすることが望ましい。クリア間隔をユーザーが設定できるようにしてもよい。

図19に上述したHookReadFileによる動作のイメージを示す。図19左部に監視対象プログラムのプロセスを示し、図19右部に本発明プログラムのプロセスを示す。

図19左側の監視対象プログラムのプロセスには、本発明プログラムのフック機能であるHookReadFileが組み込まれている。組み込まれたHookReadFileは、通常のReadFileの動作に加えて、(a)通知元API名、(b)自身のプロセスID、(c)ReadFile対象ファイルパスを、図19右側の本発明プロセスに通知する。

図19右側の本発明プログラムのプロセスは、HookReadFileからの通知への対応を行う。図19左側のHookReadFileからの通知を受け取り、通知記録データとして順次記録する。

図19では、HookReadFileは、(a)通知元API名、(b)自身のプロセスID、(c)ReadFile対象ファイルパスとして、(a)[ReadFile]と(b)pid:3421と(c)filename:c:\Users\user\Desktop\note.docの組;(a)[ReadFile]と(b)pid:1568と(c)filename:c:\Users\user\Documents\schedule.xlsの組;(a)[ReadFile]と(b)pid:1568と(c)filename:c:\Users\user\Documents\schedule.xlsの組;・・・・を順次通知し、本発明プログラムは順次通知されたものを通知記録データとして記録している。

(HookWriteFile)
HookWriteFileは、WriteFile(ファイル書込関数)をフックするWindows API関数である。

HookWriteFileは、通常のWriteFileの動作に加えて、次の機能を付加したWindows API関数である。

WriteFileに指定されたパラメータ及びパラメータから取得できる情報が、後述する「ランサムウェアによるファイル暗号化操作であることの判断基準」に合致した場合、ランサムウェアによるファイル暗号化操作であると判断し、WriteFileによるデータ書き込みを行わずにプロセスを終了させる機能。

上記の「ランサムウェアによるファイル暗号化操作であることの判断基準」とは、次の条件(A)〜(C)を満足することである。

条件(A):WriteFileの書き込み対象に指定されたファイルハンドルのファイルポインタの現在位置を取得し、その現在位置が先頭またはヘッダ範囲内であること。ファイルポインタの現在位置はSetFilePointer関数を使用する等で取得可能である。

条件(B):WriteFileの呼び出しにより書き換え前後でデータが変化すること。

条件(C):本発明プログラムに問い合わせた結果、WriteFileが呼び出し時に指定されたファイルに対して、既に自身のプロセスから ReadFileが呼び出されていること。

条件(A)と条件(B)により、ファイルの先頭またはヘッダ範囲内情報が変化しているかを判断する。

条件(C)を含めたのは次の理由である。

一般的なファイルの暗号化手順では、プログラムの実装方法として、ReadFileで読み取った内容を暗号化した後、WriteFileで別のファイルに直接書き込む手法がとられる。しかし、今回分析したランサムウェアにおいては、そのような手法をとらず、あえて ReadFileで読み込んだファイルをWriteFileで書き換え、その後にリネームするといった動作を行っていた。これは、フォレンジック技術によるファイルの復元を防止するためと考えられる。ReadFileで読み込んだファイルをあえてWriteFileで上書きすることで、ディスク上のデータを上書きするため、フォレンジック技術を用いた方法でも、ファイルの復元ができなくなる可能性が高い。ランサムウェアの作者はあえてその状況を狙っているものと考えられる。本発明プログラムでは、この挙動を検知条件のひとつとしているため、このようなランサムウェアの特性に非常に効果的である。

この付加した機能により、HookWriteFile(WriteFileのフック関数)内で、呼び出し元プロセスがランサムウェアかどうかを判断し、ランサムウェアである場合、ファイル暗号化の防止、ランサムウェア検知の通知、ランサムウェアのプロセスの強制終了を行うことができる。

条件(A)のイメージを図20に示す。

図20(a)(b)左部はメモリ23上の監視対象プログラムのプロセスを示し、図20(a)(b)右部はハードディスク22上の書き込み対象ファイルを示す。

メモリ23上の監視対象プロセスに組み込まれたHookWriteFileから、ハードディスク22上の書き込み対象ファイルへの書き込み開始位置が指定される。

図20(a)の場合、ハードディスク22上の上側の書き込み対象ファイルに対する書き込み開始位置"0x00000020"はファイルの先頭ではなく、下側の書き込み対象ファイルに対する書き込み開始位置"0x00000000"はファイルの先頭である。書き込み開始位置がファイルの先頭である下側の書き込み対象ファイルへの書き込みが条件(A)を満足し、ランサムウェアによる書き込みの可能性があると判断する。

図20(b)の場合、ハードディスク22上の上側の書き込み対象ファイルに対する書き込み開始位置"0x00000024"はファイルのヘッダの範囲内でなく、下側の書き込み対象ファイルに対する書き込み開始位置"0x00000004"はファイルの先頭ではないがヘッダの範囲内である。書き込み開始位置がファイルのヘッダの範囲内である下側の書き込み対象ファイルへの書き込みが条件(A)を満足し、ランサムウェアによる書き込みの可能性があると判断する。

なお、ヘッダの範囲内であるかを判断するためには、ファイルの各拡張子に対するヘッダのサイズが予め分かっている必要がある。各拡張子に対応するヘッダのサイズは予めHookWriteFile(WriteFileのフック関数)内に保持しておく。例えば、拡張子が"pdf"であるPDFファイルでは先頭から5バイトがヘッダである。

条件(B)のイメージを図21に示す。

図21左部はメモリ23上の監視対象プログラムのプロセスを示し、図21右部はハードディスク22上の書き込み対象ファイルを示す。

メモリ23上の監視対象プロセスに組み込まれたHookWriteFileが書き込もうとする書き込み予定データと、ハードディスク22上の書き込み対象ファイルの書き込み前の状態のデータとを比較する。

図21の場合、HookWriteFileが書き込もうとする書き込み予定データ"00 AA 00 BB 00 CC 00 DD 00 EE 00 FF 00 00 08 00"と、ハードディスク22上の書き込み対象ファイルの書き込み前の状態のデータ"50 4B 03 04 14 00 06 00 08 00 00 00 21 00 A3 EF"とは相違するので、条件(B)を満足し、ランサムウェアによる書き込みの可能性があると判断する。

条件(C)のイメージを図22に示す。

図22(a)左部にメモリ23上の監視対象プログラムのプロセスを示し、図22(a)右部にメモリ23上の本発明プログラムのプロセスを示す。

図22(a)左部の監視対象プロセスに組み込まれたHookWriteFileは、自身(監視対象プロセス)のプロセスIDと、WriteFileの対象ファイルパスに基づいて、図22(a)右部の本発明プログラムのプロセスに対して、ReadFileの通知記録データ中に、同一プロセスID、同一対象ファイルパスのReadFileの記録があるか否かを問い合わせる。図22(a)右部の本発明プログラムは、同一プロセスID、同一対象ファイルパスのReadFileの記録があるか否かをHookWriteFileに応答する。

図22(a)の場合、監視対象プロセスに組み込まれたHookWriteFileからプロセスID"pid:1568"とファイルパス"C:\Users\user\Documents\schedule.xls"に基づいて、ReadFileの通知記録データに対して問い合わせる。

図22(b)にReadFileの通知記録データを示す。

ReadFileの通知記録データの第4〜6行、第7〜9行、第13〜15行に、HookWriteFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"と同一である、プロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"のReadFileの記録があるので、条件(C)を満足し、ランサムウェアによる書き込みの可能性があると判断する。

その結果、図22(a)右側の本発明プログラムは、同一プロセスID、同一対象ファイルパスのReadFileの記録があった旨をHookWriteFileに応答する。

(除外リスト)
本発明プログラムを、システム上において動作する全てのプロセスから呼び出される全てのReadFile、WriteFileをフックし、そのプロセスがランサムウェアである否かを判断することは、システムに新たな負荷を加えることになる。

そこで、本実施形態では、明らかにランサムウェアではないプログラムを予め登録した「除外リスト」を作成しておき、除外リストに登録されたプログラムに対しては、本発明プログラムを実行しないようにする。

図23に除外リストの具体例を示す。

除外リストには正規のプログラムを登録する。例えば、システムにインストールされている「プログラム名」「プログラムファイル」「ファイルのフルパス」「ファイルサイズ」「ハッシュ値」「デジタル著名」等を必要に応じて登録する。

図23では、正規のプログラムとして、「インターネットエクスプローラー」「MSワード」「MSエクセル」を登録している。

除外リストは、システムへのプログラムをインストールするたびに更新し、ハードディスク22上に格納しておく。本発明プログラムの起動時に除外リストの内容を読み込むようにする。

本発明プログラムの動作後、読み込んだ除外リストの情報はメモリ23上にマッピングされる。突然のマシントラブルでメモリ情報が揮発しても内容を失わないよう、ハードディスク22上のファイルに対して常に更新しておくことがよい。

また、除外リストのファイルは、マルウェアやランサムウェアによる編集を避けるため、暗号化しておくことが望ましい。

(ユーザーによる除外リストへの追加)
「ランサムウェアによるファイル暗号化操作であることの判断基準」の条件(A)は、HookWriteFileからの書き込み対象ファイルへの書き込み開始位置が先頭又はヘッダ範囲内であることである。この条件(A)は、監視対象プログラムがファイルのヘッダを書き換えるものであるかを判断するための条件である。監視対象プログラムがファイルのヘッダを書き換える場合には、監視対象プログラムがランサムウェアの可能性があると判断する。監視対象プログラムがファイルのヘッダ以外の部分を書き換える場合には、通常の書き換え処理でありランサムウェアの可能性がないと判断する。

一般的に、コンピューターが扱うファイルは「テキストファイル(テキスト形式)」と「バイナリファイル(バイナリ形式)」の2種類に分類される。

バイナリファイル、例えば、拡張子が"doc"、"ppt"、"exe"、"pdf"、"jpg"、"bmp"等のファイルは、通常、ファイル種別に応じたヘッダ情報を有している。バイナリファイルの内容を編集して変更し上書き保存した場合でも、通常、ヘッダ情報となるファイルの先頭部分は変更されず、データ部分が変更される。バイナリファイルのヘッダが書き換えられると、そのファイルは適切に開けなくなり、通常のアプリケーションではそのようなことは行われない。したがって、ファイルのヘッダを書き換えるプログラムはランサムウェアの可能性がある。

ファイルの先頭部分のヘッダを書き換えるような処理を行うアプリケーションも存在するが、その場合には、ヘッダの書き換えに応じて、ファイルの拡張子も変更されてファイル種別が変更される。拡張子を含むファイル名が変わらないままで、ヘッダを書き換えることは通常のアプリケーションでは行われない。したがって、ファイル名が変わらないままで、ファイルのヘッダを書き換えるプログラムはランサムウェアの可能性がある。

一方、テキストファイル、例えば、拡張子が"txt"、"csv"等のファイルは、通常、ファイル種別に応じたヘッダ情報を有していない。テキストファイルの場合、ファイルの先頭部分もデータ部分である。したがって、テキストファイルが先頭部分から書き換えられていても、それがランサムウェアによる暗号化か、通常のアプリケーションにより書き換えかを判断することは困難である。

本発明プログラムでは、ファイルの拡張子に基づいて、テキスト形式のファイルであると判断された場合は、その対応をユーザーの判断にゆだねるようにする。

図24は、テキスト形式のファイルの書き換えを検出した場合の警告画面である。

警告画面では「以下のプロセスがテキストファイルの改変挙動を行っています。どう処理しますか。」と尋ね、「プロセス名:AAATextEditor.exe」、「該当挙動:ファイル内容の改変」、「対象ファイル:C:\Users\test\Desktop\議事録.txt」、「書き込み内容:"[議事録]\n 出席者:佐藤・・・"」を示す。

更に「※現在の操作に心当たりのないプロセスおよびファイルである場合、ランサムウェアによるファイルの暗号化処理の可能性があります。」と警告し、その対応処理の選択ボタン「プロセスを終了」、「この警告を放置」、「プロセスを除外に追加」を示す。

ユーザーが「プロセスを終了」を選択した場合には、プロセス"AAATextEditor.exe"を直ちに終了させる。ユーザーが、そのプロセスをランサムウェアであると判断した場合である。

ユーザーが「この警告を放置」を選択した場合には、プロセス"AAATextEditor.exe"を終了させることなく、そのまま処理を続行する。ユーザーが、そのプロセスをランサムウェアであるか否か判断できない又は判断を保留する場合である。

ユーザーが「プロセスを除外に追加」を選択した場合には、プロセス"AAATextEditor.exe"を、図25に示すように、「除外リスト」に追加し、同じプロセスに対する警告を再度行わないようにする。ユーザーが、そのプロセスはランサムウェアでないと判断した場合である。

なお、監視対象プログラムからの除外リスト(ホワイトリスト)の参照および追加は、直接ハードディスク22上のファイルへアクセスするよう実装してもよいし、一度常駐プログラムを経由してアクセスするように実装してもよい。

(対処行動)
本発明プログラムが、監視対象プログラムをランサムウェアであると判断した場合の対処行動について説明する。

監視対象のプログラムをランサムウェアであると判断した場合には、WriteFileによるファイルへの書き込みは行わず、監視対象プログラムによるプロセスを強制終了する。

プロセスの強制終了は、WriteFileをフックしているHookWriteFile関数内で行う。一般的には、ExitProcess関数や、Exit関数等を用いることで実現できるが、プロセスを終了可能な命令であればいかなるものを使用してもよい。

プロセスの強制終了により、ランサムウェアによるファイルの暗号化を防ぐことができる。プロセスの強制終了では、当該ファイルは暗号化されないため、事前のファイルのバックアップ等も不要である。

なお、直ちにプロセスを終了させることにより不都合が生じる可能性のある環境においては、例えば、ユーザーに強制終了予定であることを事前に通知し、強制終了するか否かの判断を仰ぐようにしてもよい。また、後述する「付加機能による検出精度のコントロール」の機能を用いて対応するようにしてもよい。

(HookReadFileとHookWriteFile)
図26に、本発明プログラムによるHookReadFileによる動作とHookWriteFileによる動作のイメージをまとめて示す。

図26左部に監視対象プログラムのプロセスを示し、図26右部に本発明プログラムのプロセスを示す。

図26左側の監視対象プログラムのプロセスには、本発明プログラムのフック機能であるHookReadFileとHookWriteFileが組み込まれている。

組み込まれたHookReadFileは、通常のReadFileの動作に加えて、(a)通知元API名、(b)自身のプロセスID、(c)ReadFile対象ファイルパスを、図26右側の本発明プロセスに通知する。

図26右側の本発明プログラムのプロセスは、図26左側のHookReadFileからの通知を受け取り、通知記録データとして順次記録する。

組み込まれたHookWriteFileは、自身(監視対象プロセス)のプロセスIDと、WriteFileの対象ファイルパスに基づいて、図26右部の本発明プログラムのプロセスに対して、ReadFileの通知記録データ中に、同一プロセスID、同一対象ファイルパスのReadFileの記録があるか否かを問い合わせる。図26右側の本発明プログラムは、同一プロセスID、同一対象ファイルパスのReadFileの記録があるか否かをHookWriteFileに応答する。

組み込まれたHookWriteFileは、更に、書き換え対象ファイルがテキストファイルの場合にユーザーに通知し、その対処方法の選択肢をユーザーに示す。

ユーザーにより監視対象プロセスの除外リストへの追加が選択された場合には、除外リストに当該プロセスを追加する。

ユーザーにより監視対象プロセスの終了が選択された場合には、監視対象プロセスを強制終了する。

(Windows APIのフック方法)
本発明プログラムが、Windows APIをフックする具体的な方法について、図27乃至図34を用いて説明する。

すべてのWindowsプログラムは、起動するとそれぞれのプロセス空間(メモリ空間)と呼ばれる仮想メモリ上に配置される仕組みとなっている。

それぞれのプロセス空間には、マルウェアのプロセス空間の状態を拡大して表示した図27に示すように、Import Address Table(IAT)という項目があり、IAT にはプログラムが使用する関数(API)の一覧とそれに応じたメモリアドレス(番地)が記録されている。これはプログラムが動作する際に、どういった関数がどこのメモリに読み込まれているかを把握するための一般的な仕組みである。

この前提のもとフック制御を行う方法について記述する。

まず、図28に示すように、監視対象プログラムのプロセス空間に、フック用の WriteFile関数(HookWriteFile関数)を埋め込む。自分以外の他のプロセスにコードを注入する、すなわち、コードをインジェクションするには、そのプロセスのメモリ空間において、VirtualAllocEx関数というWindows APIを利用し、まだ使用されていない領域に一定サイズのメモリ領域を確保する。図28右部の網掛け部分がそのメモリ領域である。

次に、図29に示すように、WriteProcessMemoryというWindows APIを利用し、確保したメモリ領域に実行させたいコード、ここではHookWriteFile関数本体、および、その HookWriteFile関数を監視対象プログラムのプロセス空間内のIATへ組み込むための関数Aを書き込む。この動作を図29の太線矢印で示す。なお、確保したメモリ領域の具体的なアドレスはVirtualAllocExの戻り値を確認することで取得することができる。

次に、図30に示すように、書き込んだコード(関数A)を実行させるために CreateRemoteThreadというWindows APIを呼び出すことにより、その任意のコードをマルウェアのプロセス空間上で実行することができる。この動作を図30の太線矢印で示す。

ここで、監視対象プログラムのプロセス空間のみに注目すると、図31に示すようになる。

次に、図32に示すように、CreateRemoteThreadにより、関数Aが実行されると、関数 Aは、監視対象プログラムのプロセス空間のIATにおける、正規のWriteFile関数のアドレス(図32ではアドレス"0x46700000"番地)を、HookWriteFile関数のアドレス(図32ではアドレス"0x49000000"番地)へ書き換える。これでフックの事前処理が完了する。

なお、どの関数がどのアドレスに展開されているか、すなわち、IATにあるその関数に対応するアドレス、を知るには、GetProcAddressというWindows APIの引数に関数名を渡すことで、指定した関数がプロセス空間のどのアドレスに対応づけられているのか、具体的なアドレスを知ることができる。

次に、図33及び図34に示すように、監視対象プログラムが、例えば"0x3C0"というファイルハンドルの指すファイル内容を書き換えようとしたと仮定する。その場合、WriteFile関数が呼び出されると、監視対象プログラムは自身のプロセス空間内のIATを参照した結果、正規の WriteFile関数ではなく、HookWriteFile関数に"0x3C0"というパラメータを渡すことになる。

HookWriteFile関数の内部では、任意の処理を行うことが可能である。具体的には、本来WriteFileを使用して書き込むデータの内容を事前にチェックする、変更する等である。本発明プログラムにおけるHookWriteFile関数の内容は、前述のとおりである。

(付加機能による検出精度のコントロール)
本発明プログラムが監視対象プログラムをランサムウェアであると判断した場合には、ランサムウェアによるファイルの暗号化を防ぐため、監視対象プログラムによるプロセスを強制終了する。

しかしながら、環境によっては、直ちにプロセスを強制終了させることにより不都合が生じる場合がある。そこで、本発明プログラムに付加機能を設けて、ランサムウェアの検出精度をコントロールするようにする。

(HookFindNextFileによるコントロール)
HookFindNextFileは、FindNextFile(ファイル検索関数)をフックするWindows API関数である。

ReadFile(ファイル読出関数)をフックするHookReadFile、WriteFile(ファイル書込関数)をフックするHookWriteFileに加えて、HookFindNextFileによりFindNextFile(ファイル検索関数)をフックするようにして、ランサムウェアの検出精度を向上させる。

FindFirstFileとFindNextFileは、ファイルの検索や列挙に使用するWindows API関数であり、通常、セットで使用される。

図35に、FindFirstFileとFindNextFileによる動作を示す。

まず、場所を指定してFindFirstFileを呼び出すと、その場所の最初のファイルの情報がシステムから応答され、最初のファイルの情報(AAA.txt)が取得できる。

次に、FindNextFileを呼び出すと、FindFirstFileにより取得したファイルハンドルから、その場所の次のファイルの情報(BBB.pdf)が取得できる。

以降、FindNextFileを呼び出すことにより、その場所の更に次のファイルの情報(CCC.txt、DDD.exe、…)を順次取得できる。

したがって、HookReadFile、HookWriteFileによる上述したランサムウェアの検知時に、FindFirstFileやFindNextFileが常に呼び出されている場合には、ランサムウェアが連続してファイルの暗号化を行っていると判断することができる。

図36に示すように、まず、FindFirstFileを呼び出し、ある場所の最初のファイルの情報を取得する。続いて、ReadFileとWriteFileを呼び出し、そのファイルの暗号化処理を行う。次に、FindNextFileを呼び出し、その場所の次のファイルの情報を取得する。続いて、ReadFileとWriteFileを呼び出し、そのファイルの暗号化処理を行う。次に、同様に、FindNextFileを呼び出し、その場所の次のファイルの情報を取得する。続いて、ReadFileとWriteFileを呼び出し、そのファイルの暗号化処理を行う。以降、同様な処理を繰り返して、その場所のファイルを連続して暗号化する。

このようなファイルの連続した暗号化処理を検出するためには、FindNextFileのみをフックして監視すればよい。FindFirstFileは必ずしもフックして監視しなくともよい。

FindNextFileをフックするHookFindNextFileは、呼び出されると通常のFindNextFileの動作に加えて、本発明プログラムに対して次の情報(a)〜(c)を通知する。

通知手段としては、プロセス間通信等、プロセスの動作に大きな遅延を発生させない程度の高速な手法が望ましい。ソケット通信やファイルによる受け渡し等でも、高速に実現できる環境であれば、いかなる方法でもよい。
(a)通知元API名。フックするWindows API関数の名前であるFindNextFileである。
(b)自身のプロセスID。フックするFindNextFileを呼び出す監視対象プロセスのプロセスIDである。
(c)通知元APIであるFindNextFileのパラメータで指定されたデータバッファから取得できるファイル名。データバッファには次のファイルの情報が格納されている。

したがって、HookReadFile、HookWriteFileによりランサムウェアが検知されたことを条件として、その暗号化処理の前に、FindNextFileが呼び出され、かつ、取得された次のファイル名がReadFileおよびWriteFileの対象ファイルと合致するかどうかを確認することにより、暗号化処理が複数のファイルに対して連続して行われていることを判断することができる。

上記を判断するためには、例えば、HookReadFile、HookWriteFile、HookNextFileが、それぞれ、本発明プログラムに対して通知する(a)通知元API名、(b)プロセスID、(c)ファイルパスを、通知記録データに記録しておき、その通知記録データに基づいて判断する。

図37に通知記録データの具体例を示す。

図37の通知記録データには、第4〜6行に、FindNextFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"の記録があり、第7〜9行、第13〜15行に、ReadFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"の記録があり、第10〜12行、第16〜18行に、WriteFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"の記録がある。

FindNextFileのプロセスIDとファイルパスは、ReadFileとWriteFileのプロセスIDとファイルパスと同一である。WriteFileにより、ファイル"schedule.xls"のヘッダが変更されたことが検出された場合には、暗号化処理が複数のファイルに対して連続して行われていると判断する。

図37の通知記録データには、更に、第22〜36行に、同じフォルダ
"C:\Users\user\Documents\"内のファイル"description.doc"に対して同様な処理を行っていることが記録されている。WriteFileにより、ファイル"description.doc"のヘッダが変更されたことが検出された場合には、暗号化処理が同一フォルダ内の複数のファイルに対して連続して行われていると判断する。

暗号化処理が複数のファイルに対して連続して行われているかの判断を有効にするか設定することにより、ランサムウェアによる暗号化処理に対する検知挙動の精度をコントロールすることができる。

図38は、複数ファイルに対する暗号化処理の検知を有効にするかの設定画面である。図38の設定画面の表現方法は一例であり、他の表現方法でもよい設定画面では、チェックボタンの後に「複数のファイルに対する暗号化処理を検知条件の入れる」を表示すると共に、「チェックを入れない場合は単一ファイルに対する暗号化処理も検知対象に含まれます」との注意書きを表示する。ユーザーがチェックボタンをチェックすることに検知条件を変更することができる。

例えば、単一のファイルに対する暗号化処理を行う可能性のあるユーザー環境では、この検知条件がないと、正当な暗号化処理をランサムウェアによる処理と誤検知することとなる。このような誤検知、誤検知による過検知を発生させないようにすることができる。

(HookMoveFileによるコントロール)
HookMoveFileは、MoveFile(MoveFileA、MoveFileW、MoveFileExA、MoveFileExW)(ファイル移動関数)をフックするWindows API関数である。

ReadFile(ファイル読出関数)をフックするHookReadFile、WriteFile(ファイル書込関数)をフックするHookWriteFileに加えて、HookMoveFileによりMoveFile(ファイル移動関数)をフックするようにして、ランサムウェアの検出精度を向上させる。

MoveFileは、ファイルの移動及びファイル名の変更を行うためのWindows API関数である。図39に示すように、MoveFileの第一引数は移動元のファイルパス(ファイル名)であり、第二引数は移動先のファイルパス(ファイル名)である。

MoveFileの第一引数と第二引数のファイル名を除くファイルパスが異なる場合は、「ファイルの移動」の処理になる。MoveFileの第一引数と第二引数のファイル名を除くファイルパスが同じ場合は、実質的に「ファイル名の変更」の処理となる。

ランサムウェアには、暗号化対象のファイル名を暗号化後に変更するものがある。これは、暗号化ファイルの元ファイル名を判断不能にするためであり、ファイルの中身だけではなくファイル名も同時に暗号化処理を行う。

そのようなランサムウェアは、図40に示すように、ファイルの暗号化処理が行われた直後にMoveFileを呼び出すことで、ファイル名の暗号化も併せて行う。その流れを検知することで、ランサムウェアによるファイル名の暗号化挙動を本発明プログラムが把握することを可能にする。

図40に示すように、FindNextFileを呼び出し、その場所の次のファイルの情報を取得する。続いて、CreateFile、ReadFile、WriteFileを呼び出し、そのファイルの暗号化処理を行う。続いて、MoveFileを呼び出し、そのファイルのファイル名を暗号化している。図40では、MoveFileにより、暗号化されたファイル"ABS.pdf"のファイル名が"g1d4fr.vvv"に変更されている。

このようなファイル名の暗号化処理を検出するために、MoveFileをフックして監視する。MoveFileをフックするHookMoveFileは、呼び出されると通常のMoveFileの動作に加えて、本発明プログラムに対して次の情報(a)〜(c)を通知する。

通知手段としては、プロセス間通信等、プロセスの動作に大きな遅延を発生させない程度の高速な手法が望ましい。ソケット通信やファイルによる受け渡し等でも、高速に実現できる環境であれば、いかなる方法でもよい。
(a)通知元API名。フックするWindows API関数の名前であるMoveFileである。
(b)自身のプロセスID。フックするMoveFileを呼び出す監視対象プロセスのプロセスIDである。
(c)通知元APIであるMoveFileの第一引数と第二引数で指定されたファイルパス。

したがって、HookReadFile、HookWriteFileによりランサムウェアが検知されたことを条件として、その暗号化処理の後に、MoveFileが呼び出され、かつ、MoveFileの第一引数と第二引数のパス(ファイルパスからファイル名を除いたファイルパス)が同一であるかどうかを確認することにより、ファイル名に対する暗号化処理が行われていることを判断することができる。

上記を判断するためには、例えば、HookReadFile、HookWriteFileが、それぞれ、本発明プログラムに対して通知する(a)通知元API名、(b)プロセスID、(c)ファイルパス、MoveFileが、本発明プログラムに対して通知する(a)通知元API名、(b)プロセスID、(c)第一引数のファイルパス、(d)第二引数のファイルパスを、通知記録データに記録しておき、その通知記録データに基づいて判断する。

図41に通知記録データの具体例を示す。

図41の通知記録データには、第4〜6行、第10〜12行に、ReadFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"の記録があり、第7〜9行、第13〜15行に、WriteFileのプロセスID"pid:1568"、ファイルパス"C:\Users\user\Documents\schedule.xls"の記録があり、第16〜19行に、MoveFileのプロセスID"pid:1568"、第一引数ファイルパス"C:\Users\user\Documents\schedule.xls"、第二引数ファイルパス"C:\Users\user\Documents\g1d4fr6ps.vvv"の記録がある。

MoveFileのプロセスIDは、ReadFileとWriteFileのプロセスIDと同一であり、MoveFileの第一引数のファイルパスは、ReadFileとWriteFileのファイルパスと同一であり、MoveFileの第1引数のパスと第2引数のパスは同一である。WriteFileによりファイル"schedule.xls"のヘッダが変更されたことが検出された場合には、"schedule.xls"が暗号化処理され、かつ、"schedule.xls"のファイル名も"g1d4fr6ps.vvv"に暗号化処理されていると判断する。

図41の通知記録データには、更に、第22〜37行に、同じフォルダ
"C:\Users\user\Documents\"内のファイル"description.doc"に対して同様な処理を行っていることが記録されている。WriteFileによりファイル"description.doc"のヘッダが変更されたことが検出された場合には、"description.doc"が暗号化処理され、かつ、"description.doc"のファイル名も"p6dfg7p4.vvv"暗号化処理されていると判断する。

ファイルに対する暗号化処理を検知した上で、ファイル名の変更が行われていることを検知した場合、本発明プログラムは、その情報をユーザーに示して、ランサムウェアによる暗号化処理に対する検知挙動の精度をコントロールすることができる。

図42は、ファイル名の変化を検知した場合に警告するか否かの設定画面である。図42の設定画面の表現方法は一例であり、他の表現方法でもよい
設定画面では、チェックボタンの後に「「ファイル名の変化」を検知条件に入れる」を表示すると共に、「チェックを入れない場合はファイル名が変化しない暗号化処理も検知対象に含まれます」「チェックを入れた場合はファイル名の変化に関する情報が検知時に表示され、対処を選択可能となります」との注意書きを表示する。ユーザーがチェックボタンをチェックすることで警告するか否かを設定することができる。

図43は、ファイル内容が改変され、かつ、ファイル名が改変された場合の警告画面である。慎重なユーザーはこの情報を元にどう対処するかを選択できユーザビリティが向上するとともに、誤検知、誤検知による過検知のコントロールも可能となる。

警告画面では「以下のプロセスがテキストファイルの改変挙動を行っています。どう処理しますか。」と尋ね、「プロセス:AAAA.exe」、「該当挙動:ファイル内容の改変、ファイル名の改変、「d1g2r.vvv」に変更しようとしています」、「対象ファイル:C:\Users\test\Document\BBB.pdf」を示す。

更に、その対応処理の選択ボタン「プロセスを終了」、「この警告を放置」、「プロセスを除外に追加」を示す。

ユーザーが「プロセスを終了」を選択した場合には、プロセス"AAAA.exe"を直ちに終了させる。ユーザーが、そのプロセスをランサムウェアであると判断した場合である。

ユーザーが「この警告を放置」を選択した場合には、プロセス"AAAA.exe"を終了させることなく、そのまま処理を続行する。ユーザーが、そのプロセスをランサムウェアであるか否か判断できない又は判断を保留する場合である。

ユーザーが「プロセスを除外に追加」を選択した場合には、プロセス"AAAA.exe"を、前述した「除外リスト」に追加し、同じプロセスに対する警告を再度行わないようにする。ユーザーが、そのプロセスはランサムウェアでないと判断した場合である。

[第2実施形態]
本発明の第2実施形態によるプログラム、情報処理装置及び情報処理方法について図44乃至図51を用いて説明する。

本発明の第1実施形態は、主なランサムウェアの挙動を分析して共通部分を洗い出し、そこから確実に不正であると判断できる挙動を検知・防御するものである。しかしながら、分析したランサムウェアによる手法でなくても、ファイルの暗号化処理の防御は可能である。

そこで、本願発明者等は、分析したランサムウェア以外の想定しうる挙動を検出することにより、未知のランサムウェアを確実に検出し、ランサムウェアによる攻撃を有効に阻止することができると考え、本実施形態を着想するに至った。

本願発明者等が想定した暗号化手法について説明する。図44に本願発明者等が想定した暗号化手法を示す。

あるファイルAを暗号化対象とした場合、本発明の第1実施形態では、暗号化されたファイルは元のファイルに直接上書き処理している。しかしながら、直接上書き処理しなくても、暗号化されたファイルを元のファイルが存在したフォルダに存在する状態にすることができる。

図44の暗号化方法について、ステップの番号順に説明する。
(ステップ1):ReadFileにより、ファイルAを読み込みメモリ23上で暗号化する。
(ステップ2):メモリ23上のファイルAの暗号化されたデータを、WriteFileにより、任意の場所にファイルBとして作成する。
(ステップ3−A):暗号化されたファイルBを、MoveFileにより、ファイル名をファイルCに変更する。
(ステップ3−B):暗号化されたファイルBを、MoveFileにより、ファイル名をファイルAに変更し、ファイルAが存在したフォルダに移動することでファイルAを上書きする。
(ステップ4):MoveFileにより、ファイルCをファイルAが存在したフォルダに移動する。
(ステップ5):DeleteFileにより、ファイルAを削除する。

ステップ5の後は、ファイルAが存在したフォルダに、暗号化されたファイルAのファイル名がファイルCに変更された「状態1」となる。

ステップ3−Bの後は、ファイルAが存在したフォルダに、暗号化されたファイルAが存在する「状態2」となる。

図45に暗号化方法の複数のケースを示す。

暗号化方法のケース1は、ステップ1、ステップ2、ステップ3−A、ステップ4、ステップ5の順番に進行し、状態1となるケースである。

暗号化方法のケース1は、ステップ1、ステップ2、ステップ3−Bの順番に進行し、状態2となるケースである。

本実施形態では、例えば、ケース1、ケース2を検知することにより、分析したランサムウェア以外の想定しうる挙動を検出するようにする。

なお、「状態1」「状態2」となるための挙動はケース1、ケース2に限らないが、そのような別のケースについても、後述する検知方法と同様の方法により検知することが可能である。

本実施形態においても、第1実施形態におけるHookReadFile、HookWriteFileによる暗号化処理を検知する。本実施形態では、それに加えて、MoveFile(MoveFileA、MoveFileW、MoveFileExA、MoveFileExW)(ファイル移動関数)をフックするHookMoveFileや、DeleteFile(ファイル削除関数)をフックするHookDeleteFileを用いる。

そして、HookReadFile、HookWriteFile、HookDeleteFileが、それぞれ、本発明プログラムに対して(a)通知元API名、(b)プロセスID、(c)ファイルパスを通知し、HookMoveFileが、本発明プログラムに対して(a)通知元API名、(b)プロセスID、(c)第一引数のファイルパス、(d)第二引数のファイルパスを通知する。本発明プログラムに通知された、これらデータは、適宜、所定のリストに記録する。

(ケース1の検知)
図48に、ケース1の検知の事前処理を示す。

本発明プログラムに対して、HookReadFileから通知される、(a)通知元API名、(b)プロセスID、(c)ファイルパスを、リストAとして記録する。

本発明プログラムに対して、HookWriteFileから通知される、(a)通知元API名、(b)プロセスID、(c)ファイルパスを、リストBとして記録する。

本発明プログラムに対して、HookMoveFileから通知される、(a)通知元API名、(b)プロセスID、(c)第一引数のファイルパス、(d)第二引数のファイルパスを、リストCとして記録する。

ケース1の検知条件を次に示す。

条件1:あるプロセスにより、DeleteFileが呼び出され、引数のファイルパス(削除対象のファイル)がリストAに含まれている。すなわち、HookDeleteFileから通知されるプロセスIDが、HookReadFileから通知されるプロセスIDと同一であり、かつ、HookDeleteFileから通知されるファイルパスがリストAに含まれている。

条件1の具体例を図47に示す。図47に示すように、あるプロセスにより、DeleteFileが呼び出され、引数のファイルパス"C:\DDD\CC.doc"がリストAに含まれている。

この条件1は、あるプロセスが過去にReadFileで読み込んだことがあるファイルをDeleteFileにより削除しようとしていることを意味する。

条件2:DeleteFileの引数(削除対象ファイルの)のフォルダパスが、リストCの第二引数のフォルダパスと等しい。すなわち、HookDeleteFileから通知されるプロセスIDが、HookMoveFileから通知されるプロセスIDと同一であり、かつ、HookDeleteFileから通知されるファイルパスからファイル名を除いたパスが、リストCの第二引数からファイル名を除いたパスと同一である。

条件2の具体例を図48に示す。図48に示すように、DeleteFileの引数のフォルダパス"C:\DDD\"が、リストCの第二引数のフォルダパス"C:\DDD\"と等しい。

この条件2は、あるプロセスが削除しようとしているファイルの場所が、過去にそのプロセスが何らかのファイルを移動先として指定した記録があるということを意味する。

条件3:MoveFileの第一引数のファイルが、リストBに含まれている。すなわち、HookWriteFileから通知されるプロセスIDが、HookMoveFileから通知されるプロセスIDと同一であり、かつ、HookWriteFileから通知されるファイルパスが、HookMoveFileから通知される第一引数のファイルパスと同一である。

条件3の具体例を図49に示す。図49に示すように、MoveFileの第一引数のファイル"C:\XXX\VV.doc"が、リストBに含まれている。

この条件3は、あるプロセスが過去にWriteFileで書き込んだファイルを、MoveFileで移動させようとしていることを意味する。

条件4:上記の条件2を満足したMoveFileの第一引数のファイルのヘッダが、第1の条件を満足したDeleteFileの引数のファイルのヘッダと異なる。

条件4の具体例を図50に示す。図50に示すように、MoveFileの第一引数のファイル"C:\DDD\CC.doc"のヘッダが、第1の条件を満足したDeleteFileの引数のファイル"C:\XXX\VV.doc"のヘッダと異なる。

この条件4は、第1実施形態におけるファイルのヘッダの相違の判断条件と同じである。

(ケース2の検知)
図51に、ケース2の検知の事前処理を示す。

本発明プログラムに対して、HookReadFileから通知される、(a)通知元API名、(b)プロセスID、(c)ファイルパスを、リストAとして記録する。

本発明プログラムに対して、HookWriteFileから通知される、(a)通知元API名、(b)プロセスID、(c)ファイルパスを、リストBとして記録する。

ケース2の検知条件を次に示す。

条件1:あるプロセスにより、MoveFileが呼び出され、第二引数のファイルパスがリストAに含まれている。すなわち、HookMoveFileから通知されるプロセスIDが、HookReadFileから通知されるプロセスIDと同一であり、かつ、HookMoveFileから通知される第二引数のファイルパスがリストAに含まれている。

この条件1は、このプロセスが過去にReadFileで読み込んだ事があるファイルを何らかのファイルで上書きしようとしていることを意味する。

条件2:その際、MoveFileの第一引数のファイルパスが、リストBに含まれている。すなわち、HookMoveFileから通知されるプロセスIDが、HookWriteFileから通知されるプロセスIDと同一であり、かつ、HookMoveFileから通知される第一引数のファイルパスがリストBに含まれている。

この条件2は、このプロセスが過去にWriteFileで書き込んだことがあるファイルを、移動させようとしていることを意味する。

条件3:MoveFileの第一引数のファイルのヘッダが、第二引数のファイルのヘッダと異なる。

この条件3は、第1実施形態におけるファイルのヘッダの相違の判断条件と同じである。

[発明の原理(その2)]
本発明の原理(その2)について図52乃至図54を用いて説明する。

(ランサムウェアの分析)
本願発明者等は、国内外で被害が報告されている他のランサムウェアについて更に解析を行った。

発明の原理(その1)に記載したように、通常のランサムウェアがファイルを暗号化する際には、ReadFileおよびWriteFileというWindows APIをファイルの読み書き時に利用する。そこで、発明の原理(その1)に基づく本発明の第1実施形態や本発明の第2実施形態では、ファイルの読み書きの関数、すなわち、ReadFileやWriteFileを用いてファイルが操作された際に、ファイルのヘッダが書き換えられているか否かに着目してランサムウェアを検知している。

しかしながら、ランサムウェアの中には、ファイルを暗号化する際に、ファイルマッピングという仕組みを利用してファイル操作を行うタイプのランサムウェアが存在する。このようなランサムウェアでは、ファイルの読み書き関数であるReadFile及びWriteFileを使用しない。このため、発明の原理(その1)に基づく本発明の第1実施形態や本発明の第2実施形態では、このようなランサムウェアを検知することが困難である。
(a)一般的なファイル操作とファイルマッピングによるファイル操作の相違
図52を用いて、一般的なファイル操作とファイルマッピングによるファイル操作の相違について説明する。

図52に示すように、実ファイルはハードディスク22に記憶されている。一般的なファイル操作におけるファイルの読み書きの処理では、その都度、メモリ23にバッファ(図示せず)を用意してファイルを読み込み、編集したデータをファイルに書き戻す、といった一連の処理を行う。

ファイルマッピングとは、オペレーティングシステム(Windows OS)がファイルをメモリデータのように扱うことを可能にする技術である。

ファイルマッピングによるファイル操作では、図52に示すように、ハードディスク22に記憶されている実ファイルの全体を、メモリ23に、仮想ファイル(ファイルマッピングオブジェクト)として展開する。ファイルマッピングによるファイル操作において、ファイルの内容を書き換える際には、その都度、メモリ23に展開された仮想ファイルに対して内容の書き換えが行われる。ファイルの内容の変更結果は一連の処理の最後の段階でハードディスク22の実ファイルへ反映させる。

図52に示すように、プロセスからハードディスク22に記憶された実ファイルにアクセスすることが可能であり、また、プロセスからメモリ23に展開された仮想ファイルにアクセスすることが可能である。

ファイル操作を行う場合、ハードディスク22に記憶された実ファイルを書き換えるよりも、メモリ23に展開された仮想ファイルを書き換える方が圧倒的に高速である。

したがって、ファイルマッピングによるファイル操作では、一般的なファイル操作のように、内容を変更する都度、実ファイルに対する読み込み処理と書き込み処理を行う必要がない。したがって、ファイルマッピングによるファイル操作の方が高速にファイルの内容の書き換えが可能である。
(b)ランサムウェアSporaの分析
(ファイル操作について)
本願発明者等が調査した結果、ランサムウェアの中で2017年初頭に出現した「Spora」がファイルマッピングによるファイル操作を行っていることがわかった。

本願発明者等がランサムウェアSporaを解析した結果、ファイル暗号化時のファイル操作の流れがわかった。図53に、ランサムウェアSporaによるファイル暗号化時のファイル操作の流れを示す。
(ステップ1):CreateFileにより、暗号化対象の実ファイルを開く。
(ステップ2):CreateFileMappingにより、仮想ファイル(ファイルマッピングオブジェクト)を作成する。
(ステップ3):MapViewOfFileにより、プロセスのメモリアドレス空間にマッピングを行う。
(ステップ4):ファイルマッピングオブジェクトをメモリ上で暗号化する。
(ステップ5):UnmapViewOfFileにより、ファイルマッピングオブジェクトをアンマップする。
(ステップ6):CloseHandleにより、ファイルハンドルをクローズする。

また、メモリ23上の仮想ファイルであるファイルマッピングオブジェクトに対する変更が、ハードディスク22上の実ファイルに反映されるタイミングについて解析した。その結果、次のタイミング(1)〜(5)で、ハードディスク22上の実ファイルに暗号化が反映されることがわかった。
(1)UnmapViewOfFileが呼び出されたタイミング。
(2)UnmapViewOfFileExが呼び出されたタイミング。
(3)FlushViewOfFileが呼び出されたタイミング。
(4)CloseHandleが呼び出されたタイミング。
(5)上記(1)〜(4)以外で、ファイルマッピングオブジェクトのハンドルが閉じられたタイミング。

一般的な正しい処理手順では(1)UnmapViewOfFile、又は(2)UnmapViewOfFileExにより、ファイルマッピングオブジェクトをアンマップした後に、ファイルオブジェクトを(4)CloseHandleで閉じるという流れとなる。なお(3)FlushViewOfFileにより、マップドファイル内にある指定された範囲のデータをディスクに書き込むこともある。

ただし、上記(1)〜(4)の関数が呼び出されなくても、プロセスを終了する等の何らかのトリガーにより、ファイルマッピングオブジェクトのハンドルを閉じることでも、ハードディスク22上の実ファイルに暗号化が反映される。

図54に、ランサムウェアSporaによるファイル操作とハードウェアとの関係を示す。

まず、プロセスが、CreateFileにより、ハードウェア22上にある暗号化対象の実ファイルを開く(ステップ1)。

次に、図54(a)に示すように、プロセスが、CreateFileMappingにより、実ファイルの仮想ファイル(ファイルマッピングオブジェクト)を作成し(ステップ2)、プロセスが、MapViewOfFileにより、メモリ23上のプロセスのメモリアドレス空間に仮想ファイルをマッピングする(ステップ3)。

図54(a)に示すように、一般的なファイル操作では、ハードディスク22上の実ファイルへのアクセスは、ファイルの読み書き関数であるReadFile及びWriteFileを用いる。しかしながら、ランサムウェアSporaによるファイルの暗号化操作では、ReadFile及びWriteFileを使用しない。

次に、プロセスが、ファイルマッピングオブジェクトをメモリ23上で暗号化する(ステップ4)。

次に、図54(b)に示すように、プロセスが、UnmapViewOfFileにより、ファイルマッピングオブジェクトをアンマップし(ステップ5)、プロセスが、CloseHandleにより、ファイルハンドルをクローズする(ステップ6)。それにより、メモリ23上の暗号化された仮想ファイル(ファイルマッピングオブジェクト)への変更が、ハードディスク22上の実ファイルに反映される。

メモリ23上の仮想ファイル(ファイルマッピングオブジェクト)への変更が、ハードディスク22上の実ファイルに反映されるタイミングとしては、上記のUnmapViewOfFileが呼び出されたタイミング、CloseHandleが呼び出されたタイミングの他に、UnmapViewOfFileExが呼び出されたタイミングや、FlushViewOfFileが呼び出されたタイミングや、上記以外で、ファイルマッピングオブジェクトのハンドルが閉じられたタイミングがある。

本願明細書において「マッピング時」とは、仮想ファイル(ファイルマッピングオブジェクト)がプロセスのメモリアドレス空間にマッピングされた時のことである。例えば、CreateFileにより暗号化対象の実ファイルを開き、CreateFileMappingにより仮想ファイル(ファイルマッピングオブジェクト)を作成し、MapViewOfFileによりプロセスのメモリアドレス空間にマッピングを行った時である。

本願明細書において「アンマッピング時」とは、メモリ23上の仮想ファイルであるファイルマッピングオブジェクトに対する変更が、ハードディスク22上の実ファイルに反映された時である。例えば、次のタイミング(1)〜(5)のタイミングである。
(1)UnmapViewOfFileが呼び出されたタイミング。
(2)UnmapViewOfFileExが呼び出されたタイミング。
(3)FlushViewOfFileが呼び出されたタイミング。
(4)CloseHandleが呼び出されたタイミング。
(5)上記(1)〜(4)以外で、ファイルマッピングオブジェクトのハンドルが閉じられたタイミング。

上記(1)〜(4)の関数が呼び出されなくても、プロセスを終了する等の何らかのトリガーにより、ファイルマッピングオブジェクトのハンドルを閉じることでも、ハードディスク22上の実ファイルに暗号化が反映される。
(ファイル内容の変更について)
ランサムウェアによるファイルの変更と通常のアプリケーションによるファイルの変更との差異は、ヘッダ情報を有するタイプのファイルで顕著に表れる。通常のアプリケーションがファイルを書き換える場合、ファイルのヘッダ情報はそのまま変更せず、ファイルの中間部分のデータが書き換わることが圧倒的に多い。これに対し、ランサムウェアがファイルを暗号化する場合、ファイルのヘッダ情報が書き換わる。

したがって、ファイルの先頭部分を比較することで、ランサムウェアによる暗号化である可能性が高い操作と、そうではない通常のアプリケーションによる操作とを判別することが可能となる。

より広範囲にランサムウェアを検知し、かつ誤検知を防ぐためには、ファイルの先頭部分だけの変化を監視するのではなく、「ファイル構造の不適切な状態への変更」を監視することが本質的な要請である。

それは、ランサムウェア作成者の目的が、ユーザーからランサム(身代金)を獲得することにあるからである。ユーザーがファイルを開こうとしたときに、そのファイルを開くことができないと、ユーザーはランサムウェアによる感染を認識し、ランサムウェア作成者にランサム(身代金)を支払おうとする。ファイルの内容が大幅に書き換えられた場合も同様である。

ユーザーにランサム(身代金)を支払おうとする動機付けをもたらす「ファイル構造の不適切な状態への変更」には、例えば、次のような態様がある。
(i)ヘッダ情報の変更
ヘッダ情報が変更されるとアプリケーションにより開くことができなくなる。例えば、拡張子「.pdf」のファイルにおいて、ファイルがPDFフォーマットでなくなると、PDFフォーマットに対応したアプリケーションでファイルを開くことができなくなる。

ヘッダ情報を持つファイルの多くは、ファイルのヘッダ情報はファイルの先頭部分にある。しかし、ファイルの種類によっては、ファイルのヘッダ情報がファイルの先頭部分にないものもある。ファイルの先頭部分の監視だけでは、様々な種類のファイルのヘッダ情報の変更を監視できない。

ヘッダ情報の位置はファイルの種類ごとに定められている。ファイルの種類に応じて定められたヘッダ情報の位置の部分を監視することにより、ヘッダ情報の変更を監視する。

ファイルの種類に対するヘッダ情報の位置は公開情報により知ることができる。公開情報としては、ファイルのマジックナンバーと呼ばれるヘッダ内の固定値が公開されているものや、各フォーマットに対するRFCの定義が公開されているものがある。
・Magic number (programming)
https://en.wikipedia.org/wiki/Magic_number_(programming)
・Windows Image Media Types
https://tools.ietf.org/html/rfc7903#section-1.2
例えば、拡張子が「GIF」のファイルのマジックヘッダ(ファイルの先頭データ)は「47 49 46 38 39 61」か「47 49 46 38 37 61」となるので、これらのデータが、これら以外に書き換えられる場合には暗号化操作と判断することができる。

公開情報に存在しない拡張子のファイルのヘッダ情報については、ファイルの先頭から固定のサイズをヘッダ情報とみなして監視する。また、この監視方法を他の監視方法と併用してもよい。
(ii)フッタ情報の変更
一般的なファイルには「ヘッダ+ボディ」という形式が多いが「ヘッダ+ボディ+フッタ」というファイル形式のファイルもある。そのようなファイルにおいて、フッタ情報が変更されると、アプリケーションにより開くことができなくなる場合がある。
(iii)ボディ情報の変更
ファイルの種類によってはボディの構造に一定のルールが定められている場合がある。

例えば、ボディ内は4つのデータ部分に分かれていて、各データ部分の最後には0x00(ヌル文字)が複数バイト連続するというルールが定められたファイルがある。このようなファイルの場合、各データ部分の最後が暗号化されて0x00(ヌル文字)でなくなった場合、アプリケーションで開くことができなくなる。

また、ボディ内に存在するデータ部分の数や、各データ部分のサイズ、各データ部分の開始位置等のルールがヘッダ上で定義されているファイルがある。このようなファイルの場合、このルールから逸脱する変更がボディに加えられると、アプリケーションで開くことができなくなる。

また、ボディがとる値(バイナリ値)の範囲が定められているファイルがある。このようなファイルの場合、ボディの値が定められた範囲から逸脱する変更がボディに加えられると、アプリケーションで開くことができなくなる。
(ランサムウェアSporaの検知条件)
本願発明者等は、上記のランサムウェアSporaの分析に基づき、ランサムウェアSporaを有効に検知することができる、次のような検知条件を着想するに至った。
(a)条件A:ファイル構造の不適切な状態への変更がある。

この条件Aは、ファイルのファイル構造が不適切な状態に書き換わることである。

ファイル構造の不適切な状態への変更には、例えば、ヘッダ情報の変更、フッタ情報の変更、ボディ情報の変更がある。
(i)ヘッダ情報の変更
この場合の条件Aは、同じファイルのヘッダ情報が書き換わることである。

ファイルマッピングを利用したランサムウェアでは、ハードディスク22上の実ファイルがメモリ23上に仮想ファイルとして展開される。したがって、条件Aは次の条件A1、条件A2のいずれかとなる。

条件A1:ファイル操作前の実ファイルのヘッダ情報と、ファイル操作後の所定タイミングにおける実ファイルのヘッダ情報を比較して、書き換わっている。

条件A2:ファイル操作前の実ファイルのヘッダ情報と、ファイル操作後の所定タイミングにおける仮想ファイルのヘッダ情報を比較して、書き換わっている。

ファイル操作後の所定タイミングとは、メモリ23上の仮想ファイルであるファイルマッピングオブジェクトに対する変更が、ハードディスク22上の実ファイルに反映されるタイミングである。具体的には上述した(1)〜(5)のタイミングである。

なお、ファイルマッピングオブジェクトのハンドルが閉じられた(5)のタイミングの場合には、そのタイミングを捕まえることが困難な場合がある。

実際には、ヘッダ情報を持つファイルの多くは、ファイルのヘッダ情報はファイルの先頭部分にある。

ヘッダ情報がファイルの先頭部分にある場合、条件Aは、先頭部分のデータが書き換わることである。この場合、条件Aは次の条件A1、条件A2のいずれかとなる。

条件A1:ファイル操作前の実ファイルの先頭部分のデータと、ファイル操作後の所定タイミングにおける実ファイルの先頭部分のデータを比較して、書き換わっている。

条件A2:ファイル操作前の実ファイルの先頭部分のデータと、ファイル操作後の所定タイミングにおける仮想ファイルの先頭部分のデータを比較して、書き換わっている。
(ii)フッタ情報の変更
この場合の条件Aは、同じファイルのフッタ情報が書き換わることである。

条件Aは次の条件A1、条件A2のいずれかとなる。

条件A1:ファイル操作前の実ファイルのフッタ情報と、ファイル操作後の所定タイミングにおける実ファイルのフッタ情報を比較して、書き換わっている。

条件A2:ファイル操作前の実ファイルのフッタ情報と、ファイル操作後の所定タイミングにおける仮想ファイルのフッタ情報を比較して、書き換わっている。
(iii)ボディ情報の変更
この場合の条件Aは、同じファイルのボディのデータが書き換わることである。

条件Aは次の条件A1、条件A2のいずれかとなる。

条件A1:ファイル操作前の実ファイルのボディのデータと、ファイル操作後の所定タイミングにおける実ファイルのボディのデータを比較して、書き換わっている。

条件A2:ファイル操作前の実ファイルのボディのデータと、ファイル操作後の所定タイミングにおける仮想ファイルのボディのデータを比較して、書き換わっている。
(b)条件B:ファイルマッピングオブジェクトの連続的な操作がある。

ファイルマッピングを利用した場合、1ファイルに対して、必ず、CreateFileMappingというAPIと、MapViewOfFileというAPIを一度読み出す必要がある。したがって、連続的なファイルマッピングが発生した場合には、CreateFileMappingというAPIと、MapViewOfFileというAPIが2回以上読み出される。

したがって、条件Bは、具体的には、CreateFileMappingというAPIと、MapViewOfFileというAPIとが複数回読み出されることである。

条件Bを設けたのには次のような意義がある。理想的には条件Aによりひとつ目のファイルの暗号化を検知できることが望ましいが、それが困難な場合でも、条件Bの検知によりファイルの暗号化操作を確実に検知することができる。

[第3実施形態]
本発明の第3実施形態によるプログラム、情報処理装置及び情報処理方法について図55乃至図75を用いて説明する。

(本実施形態の概要)
本実施形態の概要について図55及び図56を用いて説明する。

本実施形態では、ハードディスク22に保存されたユーザーデータへアクセスするという挙動を有するプログラムの全ての挙動が検出対象である。

CPU21がメモリ23上のOSデータのプロセスを実行して、ハードディスク22に格納されたプログラムにアクセスして、そのプログラムを読み込み(図2(c))、ハードディスク22に格納されたプログラムがメモリ23にロードされ、メモリ23上にプロセスとして展開される(図3(a))前に、メモリ23に本発明プログラムのプロセスを常駐させておく(図55(a))。

本発明プログラムは、ランサムウェアが導入される危険性のある状態となる前であればいつ実行してメモリ23上にプロセスとして常駐させてもよい。

例えば、スタートアッププログラムとして、コンピューターの起動時に起動させておく。オペレーティングシステム(Windows OS)には、PCの起動と共に実行されるプログラムとして「スタートアッププログラム」が登録できる仕組みがある。本実施形態では、その仕組みを利用し本発明プログラムをスタートアッププログラムとして登録しておく。これにより、本発明プログラムがPCの起動直後からメモリ23上に配置している状態にする。

また、PCの起動時にプログラムを起動する方法としては、レジストリやサービスの仕組みを使用する方法もあるが、いずれの方法を用いてもよい。

これにより、PCの起動直後から常にコンピューターをランサムウェアから保護することができる。

本発明プログラムは、図55(a)に示すように、ハードディスク22に格納されたプログラムがメモリ23にロードするという動作と、CPU21がプログラムを実行するという動作との間に割り込む。CPU21によるプログラムに基づく動作をフックすることにより、プログラムが実行される直前で、そのプログラムの挙動を本発明プログラムの監視下に置く。

これにより、これ以降、監視対象プログラムの全ての挙動は、本発明プログラムが実行直前に把握することができる。必要に応じて、監視対象プログラムの処理に機能を加えたり、変更したりすることができる。

本発明プログラムにより、コンピューターを、監視対象プログラムがランサムウェアと判断する判断部として機能させる。

本発明プログラムにより、コンピューターに、監視対象プログラムがランサムウェアと判断する判断手順を実行させる。

判断部又は判断手順により、監視対象プログラムの挙動が、ランサムウェア特有の挙動であると判断された場合には、図55(b)に示すように、本発明プログラムは、監視対象プログラムがハードディスク22内のファイルにアクセスを行おうとする直前に、そのアクセスをブロックする。このようにして、未知のランサムウェアによる攻撃をブロックしてファイルの暗号化を阻止する。

(本発明プログラムの3つの機能)
本発明プログラムは3つの機能を有する。本発明プログラムの3つの機能について図56を用いて説明する。

第1の機能は、現在動作中のプログラムや、後ほど起動するプログラムである監視対象プロセスが使用するWindows APIをフックする機能である。図56に示すように、本発明プログラムから、現在起動中のプロセス、すなわち、notepad.exe、WINWORD.exe、calc.exe、Ramsomware.exe、cmd.exe、…のプロセスが使用するWindows APIをフックする。

第2の機能は、フックしたWindows APIにより、監視対象プロセスの挙動を記録する機能である。

第3の機能は、第2の機能により記録した挙動によりランサムウェアであるかどうかを判断する機能である。

第1の機能は、常駐している本発明プログラムの機能であり、第2の機能と第3の機能は、監視対象プロセス内に組み込まれる本発明プログラムの機能である。

なお、常駐している本発明プログラムに第1の機能と第3の機能を持たせ、監視対象プロセス内に組み込まれる本発明プログラムに第2の機能を持たせるようにしてもよい。その場合には、監視対象プロセス内に組み込まれる本発明プログラムが第2の機能により記録した挙動を常駐している本発明プログラムに通知し、常駐している本発明プログラムが第3の機能によりランサムウェアであるどうかを判断する。

(第1の機能:監視対象プロセスが使用するAPIをフックする機能)
本発明プログラムは、監視対象プロセスにおいて、ランサムウェアの分析結果から得られた挙動であるAPI及びこれと同等の機能を持つAPIをフックする。本実施形態におけるフック対象APIは次の通りである。

CreateFileMapping
MapViewOfFile/MapViewOfFileEx
UnmapViewOfFile/UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
APIをフックする具体的な方法は後述する。

監視対象プロセスは、現在動作中のプログラム及び以降起動するプログラムである。後述する除外リストに挙げられているプログラムは監視対象プロセスから除外される。また、除外リストになくても、デジタル署名が付与されている等によりファイルの出自が明らかであるプログラムや、安全性が確認されているプログラムを監視対象プロセスから除外することができる。

(第2の機能:フックしたAPIにより監視対象プロセスの挙動を記録する機能)
本発明プログラムは、第1の機能によりフックしたAPIにより監視対象プロセスの挙動を記録する。

監視対象プロセスの挙動を記録するために、第1の機能で列挙したAPIのうち、CreateFileMapping、MapViewOfFile/MapViewOfFileExのAPIのフック関数を使用する。

(HookCreateFileMapping関数)
HookCreateFileMapping関数は、CreateFileMappingなるAPIをフックする関数である。

CreateFileMappingは、ファイルマッピングを使用してファイルの読み書きを行う際に、指定されたファイルに対する、名前付きまたは名前なしのファイルマッピングオブジェクトを作成または開くAPIである。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc430039.aspx
には、CreateFileMappingの説明が記載されている。その抜粋を図57に示す。

CreateFileMappingのフック関数であるHookCreateFileMapping関数には、フックにより捕捉した情報及び通常のCreateFileMappingの呼び出しにより取得した情報を記録する機能を持たせる。

HookCreateFileMapping関数で記録する情報を次に示す。なお、CreateFileMappingにより指定されたファイルのことを、暗号化を説明する便宜上「暗号化対象ファイル」と称することとする。
(a)暗号化対象ファイルのハンドル
CreateFileMappingAPIが呼び出される際に指定されたファイルハンドル(hFile)。
(b)暗号化対象ファイルパス
ファイルハンドルをもとに取得したファイルパス。ファイルハンドル(hFile)からファイルパスを求めることができる。
(c)ファイルマッピングオブジェクトのハンドル
CreateFileMappingを呼び出すことによって得られる戻り値。

フック関数(HookCreateFileMapping関数)内でフック前のオリジナルのCreateFileMappingを呼び出すことで取得できる。
(d)暗号化対象ファイルの暗号化前のヘッダデータ
ファイルハンドルをもとに取得したヘッダデータ。ファイルハンドル(hFile)に対してReadFile等のAPIを使用してファイルのヘッダデータを読み込むことにより取得できる。図58に示すように、ファイルハンドル(hFile)に基づいて、例えばReadFileのAPIを使用して、暗号化対象ファイルの暗号化前のヘッダデータをハードディスク22から読み込む。

このようにHookCreateFileMapping関数により記録される情報は、メモリ23上に、例えば、図59に示すようなリスト形式で記録される。以降、このリストを「メモリマップドリスト」と呼ぶ。

図59は、暗号化対象ファイルのハンドルが「0xABC」であり、暗号化対象ファイルパスが「C:\test.pdf」であり、ファイルマッピングオブジェクトのハンドルが「0xABCD」であり、暗号化対象ファイルの暗号化前のヘッダデータが「25 50 44 46 2D」であることを示している。

具体的にはHookCreateFileMapping関数の第一引数に指定された暗号化対象ファイルハンドルからファイルパスを割り出し、そのファイルをハードディスク22上の別の場所に保管する機能である。保管場所はどこでもよい。

ランサムウェアによる暗号化が検知された場合に、このバックアップから暗号化される前のファイルをコピーし復元する。

バックアップはあくまでも一時ファイルであり、暗号化が発生しない場合はディスクを無駄に圧迫することになるので、適宜この一時ファイルを削除する。

保管する際は、拡張子を含むファイル名やファイルの内容を暗号化することが望ましい。また、特定のプログラム以外からの書き込みができないようなフォルダに保管する等の対策をとることが望ましい。バックアップファイルが攻撃者によって置き換えられたり削除されたりすることを防ぐためである。

図60に、ファイルマッピング時のファイルバックアップから、暗号化検知後のファイル復元の流れの具体例を示す。

CreateFileMapping関数が呼び出される(ステップ1)と、HookCreateFileMapping関数の第一引数に指定された暗号化対象ファイルハンドル(0x1A)からファイルパス(C:\users\test\Desktop\test.doc)を取得する(ステップ2)。取得したファイルパス(C:\users\test\Desktop\test.doc)から割り出したファイル(test.doc)を別の場所に暗号化を施したファイル(91B4083010E141872685)として保管する(ステップ3)。

その後、ランサムウェアによる暗号化ファイル(C:\users\test\Desktop\test.doc.encrypted)を検知する(ステップ4)と、バックアップしたファイル(91B4083010E141872685)の暗号化を解いて、ファイル(C:\users\test\Desktop\test.doc)を復元する(ステップ5)。

なお、バックアップしたファイルは、ディスクを圧迫しないよう定期的に削除する必要がある。削除する頻度は任意であるが、一定の期間を過ぎたものを削除する、バックアップファイルが一定の個数を超えたら古いものから削除する、残りのディスク容量が一定量を下回った場合に古いものから削除する等、ディスク資源が枯渇しないような処理とする必要がある。

(HookCreateFile関数)
HookCreateFile関数は、CreateFileなるAPIをフックする関数である。

図60では、CreateFileMappingをフックするHookCreateFileMapping関数によりバックアップファイルを作成した。しかしながら、ファイルが排他モードで開かれている場合にはバックアップが作成できない。

このため、バックアップ機能は、CreateFileMapping関数より前に呼び出されるCreateFileをフックするHookCreateFile関数により、排他モードで開かれる前にバックアップしておくことが望ましい。

CreateFileは、ファイル等のオブジェクトにアクセスするためにオブジェクトを作成するか、利用できるハンドルを返すかする関数である。この関数を呼び出すことで、指定したファイルに読み書きするためのハンドルを取得できる。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc429198.aspx
には、CreateFileの説明が記載されている。その抜粋を図61に示す。

CreateFileのフック関数であるHookCreateFile関数に、次の機能を持たせる。

呼び出し時のパラメータに指定されたファイル名が存在する場合は、そのファイルをバックアップする機能、すなわち別の場所にコピーする機能である。

バックアップファイルのファイル名は、どのプロセスによって暗号化されたものかを判別するために、例えば、プロセスIDやプロセス名等を埋め込んでおくのが望ましい。

CreateFileは暗号化操作に関わらず頻繁に呼び出される関数であるので、全てをバックアップ対象とするとディスク領域を圧迫するおそれがある。このため、書き込み権限を指定してハンドルを取得しようとする場合、排他モードを指定してハンドルを取得しようとする場合等の条件を満たした場合等のみバックアップ対象とするようにしてもよい。

バックアップはあくまでも一時ファイルであり、暗号化が発生しない場合はディスクを無駄に圧迫しないよう削除すべきである。

例えば、オペレーティングシステム(Windows OS)でも一時領域として使用されるユーザー毎の一時フォルダである %temp%(例:C:\Users\test\AppData\Local\Temp)等に保管するようにしてもよい。

なお、バックアップしたファイルは、ディスクを圧迫しないよう定期的に削除する必要がある。削除する頻度は任意であるが、一定の期間を過ぎたものを削除する、バックアップファイルが一定の個数を超えたら古いものから削除する、残りのディスク容量が一定量を下回った場合に古いものから削除する等、ディスク資源が枯渇しないような処理とする必要がある。

(HookMapViewOfFile関数/HookMapViewOfFileEx関数)
HookMapViewOfFile関数は、MapViewOfFileなるAPIをフックする関数である。HookMapViewOfFileEx関数は、MapViewOfFileExなるAPIをフックする関数である。

MapViewOfFileおよびMapViewOfFileExは、CreateFileMappingにより作成されたマッピングオブジェクトを指定して、ファイルのビューをプロセスのアドレス空間にマップする関数である。この関数を呼び出すことで、読み込んだファイルのデータが対応付けられたアドレスを取得できる。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc430198.aspx
には、MapViewOfFileの説明が記載されている。その抜粋を図62(a)に示す。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc430178.aspx
には、MapViewOfFileExの説明が記載されている。その抜粋を図62(b)に示す。

MapViewOfFile、MapViewOfFileExのフック関数であるHookMapViewOfFile関数、HookMapViewOfFileEx関数には、次の機能を持たせる。

呼び出し時のパラメータに指定されたファイルマッピングオブジェクトハンドル(hFileMappingObject)がメモリマップドリスト内に存在するかを確認し、存在する場合はその行にマップの開始アドレスを追記する機能である。

マップの開始アドレスは、MapViewOfFile/MapViewOfFileExを呼び出すことによって得られる戻り値の「マップされたビューの開始アドレス」である。「マップされたビューの開始アドレス」は、HookMapViewOfFile関数/HookMapViewOfFileEx関数内でフック前のオリジナルのMapViewOfFile/MapViewOfFileExを呼び出すことにより取得できる。

図63に示す具体例では、呼び出し時のパラメータに指定されたファイルマッピングオブジェクトハンドル「0xABCD」がメモリマップドリスト内に存在したので、その行にマップ開始アドレス「0x201000」が追記されている。

(メモリマップドリスト)
上述したように、HookCreateFileMapping関数、HookMapViewOfFile関数/HookMapViewOfFileEx関数により、図64に示すメモリマップドリストが生成される。

メモリマップドリストの「暗号化対象ファイルのハンドル」「暗号化対象ファイルパス」「ファイルマッピングオブジェクトのハンドル」「暗号化前のヘッダデータ」は、HookCreateFileMapping関数により挿入され、「マップ開始アドレス」はHookMapViewOfFile関数/HookMapViewOfFileEx関数により挿入される。

HookCreateFileMapping関数が呼び出されるたびに、新たな「暗号化対象ファイルのハンドル」「暗号化対象ファイルパス」「ファイルマッピングオブジェクトのハンドル」「暗号化前のヘッダデータ」がメモリマップドリストに追加される。なお、既にリストに記録されているものは追加しなくてもよい。そして、HookMapViewOfFile関数/HookMapViewOfFileEx関数が呼び出されるたびに、新たな「マップ開始アドレス」が追加される。

図64は、後述する「(第3の機能(その2):明示的にマップのクローズ・反映処理が行われない場合)」に記録されるメモリマップドリストの例である。

具体的には「C:\document\」フォルダ内のファイルが順に暗号化される流れにおいて、2つ目のファイル「2.pdf」がマッピングされたため、ファイル「1.pdf」の暗号化前のヘッダデータと暗号化後(現在)のヘッダデータを比較する状況を示している。

ファイル「1.pdf」のヘッダデータが異なっている場合、当該マッピング処理は暗号化を目的としたものであると判断し、検知する。

図64に示すメモリマップドリストの情報は、ひとつの監視対象プロセスが終了するとクリアされる。

本発明プログラムを常駐プログラムとして動作させる場合には、ひとつの監視対象プロセスが終了してもメモリマップドリストの情報はクリアされない。そのため、オペレーティングシステムのハンドル値の再利用により、異なるハンドルであるのに、偶発的にハンドル値が一致すると誤って検知するおそれがある。そのような誤検知を防止するため、メモリマップドリストを定期的にクリアすることが望ましい。ユーザーがクリアする間隔を設定できるようにしてもよい。また、オペレーティングシステムの終了時または再起動時にはクリアすることが望ましい。

ランサムウェアによる暗号化では、ファイルを1つずつ処理する流れをとることが多いため、マッピングによる暗号化においても「マップ」「暗号化」「アンマップ」を交互に繰り返すことが基本的な流れになる。この基本的な流れに対する対応であればメモリマップドリストが大きい必要はない。

しかしながら、多数のファイルを一気にマップし、その後、多数のファイルに暗号化を施し、その後、多数のファイルを一気にアンマップする、という処理を行う場合には、メモリマップドリストに、多数のファイル分の領域を設ける必要がある。

(第3の機能:記録を使用してランサムウェアであるかどうかを判断する機能)
本発明プログラム第3の機能は、第2の機能により記録した挙動により監視対象プロセスがランサムウェアであるかどうかを判断する。監視対象プロセスが、明示的にマップのクローズ・反映処理を行う場合と、明示的にマップのクローズ・反映処理が行わない場合とがあり、それぞれの場合を想定した処理を行う。

(第3の機能(その1):明示的にマップのクローズ・反映処理が行われる場合)
監視対象プロセスの挙動を記録するために、第1の機能で列挙したフック対象APIのうち、次のAPIのフック関数を使用する。

UnmapViewOfFile/UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
UnmapViewOfFile関数、UnmapViewOfFileEx関数は、マッピングされたメモリ(以下この状態のメモリを「マップドメモリ」と呼ぶ)を解除(アンマップ)する関数である。アンマップすることにより、マップドメモリ上のデータがファイルへ反映されるため、実質的に実ファイルへの書き込みが行われる動作である。監視対象プロセスがランサムウェアであれば実ファイルが暗号化される。

FlushViewOfFile関数は、マップされた状態(マップドメモリ)を解除(アンマップ)しないが、この関数を呼び出すことによりマップドメモリ上のデータを実ファイルに反映する関数である。

CloseHandle関数は、より広範に使用されるAPIである。ファイルマッピングでは、マップされた仮想ファイルの実ファイルへの書き込みが終わった後、マップされた仮想ファイルを閉じる際に呼び出される。したがって、通常のプログラムであれば、CloseHandleを呼び出す前に、UnmapViewOfFile関数やUnmapViewOfFileEx関数により、仮想ファイルがアンマップされる。しかしながら、UnmapViewOfFile関数やUnmapViewOfFileEx関数を呼び出すことなくCloseHandleを呼び出した場合には、マップドメモリのデータが実ファイルへ反映される。したがって、CloseHandle関数も、UnmapViewOfFile関数、UnmapViewOfFileEx関数、FlushViewOfFile関数と同様、実ファイルへの書き込みタイミグとして監視すべきAPIである。

(HookUnmapViewOfFile関数/HookUnmapViewOfFileEx関数)
HookUnmapViewOfFile関数は、UnmapViewOfFileなるAPIをフックする関数である。HookUnmapViewOfFileEx関数は、UnmapViewOfFileExなるAPIをフックする関数である。

UnmapViewOfFileおよびUnmapViewOfFileExは、マップされた状態(マップドメモリ)を解除(アンマップ)する関数である。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc430200.aspx
には、UnmapViewOfFileの説明が記載されている。その抜粋を図65(a)に示す。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/windows/desktop/mt670639(v=vs.85).aspx
には、UnmapViewOfFileExの説明が記載されている。その抜粋を図65(b)に示す。

UnmapViewOfFile、UnmapViewOfFileExのフック関数であるHookUnmapViewOfFile関数、HookUnmapViewOfFileEx関数には、通常のUnmapViewOfFile/UnmapViewOfFileExの動作に加え以下の機能を追加する。
(a)呼び出し時のパラメータに指定されたマップドメモリ(lpBaseAddress)がメモリマップドリスト内に存在するかを確認し、存在する場合はその行の「暗号化前のヘッダデータ」を取得する機能。
(b)呼び出し時のパラメータに指定されたマップドメモリ(lpBaseAddress)がメモリマップドリスト内に存在するかを確認し、存在する場合はlpBaseAddressの位置にマップされた「暗号化後のヘッダデータ」(マップドメモリ上の先頭データ)を取得する機能。

UnmapViewOfFileが呼び出されるということは、既にMapViewOfFileが呼ばれていて、かつ、マップドメモリの使用を終え、ファイルにマップドメモリの内容を反映させる等の理由によりマップを解除したい段階と考えられる。このため、この時点のマップドメモリの先頭データはファイル暗号化後のヘッダデータとみなせる。
(c)上記の「暗号化前のヘッダデータ」と「暗号化後のヘッダデータ」とを比較し、それらに差異がある場合、ランサムウェアによるファイル暗号化操作であると判断し、プロセスを終了させる機能。

これらの機能による具体例を図66に示す。図66に示す例では、暗号化対象ファイルのハンドル「0xABC」の「暗号化前のヘッダデータ」は「25 50 44 46 2D」であり、HookUnMapViewOfFileFile/HookUnMapViewOfFile のパラメータの「開始アドレス(lpBaseAddress)」に「0x201000」が指定されている。メモリ23上のアドレス「0x201000」のデータ「50 4B 03 04 14」が「暗号化後のヘッダデータ」である。図66に示す例では、暗号化前のヘッダデータ「25 50 44 46 2D」と、暗号化後のヘッダデータ「50 4B 03 04 14」が相違するので、ランサムウェアによるファイル暗号化操作であると判断し、監視対象プロセスを終了させる。

(HookFlushViewOfFile関数)
HookFlushViewOfFile関数は、FlushViewOfFileなるAPIをフックする関数である。

FlushViewOfFileは、マップドファイルのビュー内にある、指定された範囲のデータをディスクに書き込む関数である。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc430048.aspx
には、FlushViewOfFileの説明が記載されている。その抜粋を図67に示す。

FlushViewOfFileはUnmapViewOfFile/UnmapViewOfFileExと同様、呼び出しパラメータにマップの開始アドレス(lpBaseAddress)があるため、HookUnmapViewOfFile/HookUnmapViewOfFileExと同様に暗号化を検知することが可能である。

FlushViewOfFileのフック関数であるHookFlushViewOfFile関数には、通常のFlushViewOfFileの動作に加え以下の機能を追加する。
(a)呼び出し時のパラメータに指定されたマップドメモリ(lpBaseAddress)がメモリマップドリスト内に存在するかを確認し、存在する場合はその行の「暗号化前のヘッダデータ」を取得する機能。
(b)呼び出し時のパラメータに指定されたマップドメモリ(lpBaseAddress)がメモリマップドリスト内に存在するかを確認し、存在する場合はlpBaseAddressの位置にマップされた「暗号化後のヘッダデータ」(マップドメモリ上の先頭データ)を取得する機能。
(c)上記の「暗号化前のヘッダデータ」と「暗号化後のヘッダデータ」とを比較し、それらに差異がある場合、ランサムウェアによるファイル暗号化操作であると判断し、プロセスを終了させる機能。

(HookCloseHandle関数)
HookCloseHandle関数は、CloseHandleなるAPIをフックする関数である。

CloseHandleは、ファイルが閉じられる際に呼び出されるAPIである。

Microsoft社のリファレンス
https://msdn.microsoft.com/ja-jp/library/cc429605.aspx
には、CloseHandleの説明が記載されている。その抜粋を図68に示す。

ファイルマッピングを使用する場合、一般的にはCloseHandleを呼び出す前にアンマップする。そのため一般的にアンマップはHookUnmapViewOfFile/HookUnmapViewOfFileExで検知できる。しかしながら、意図的にアンマップするHookUnmapViewOfFile/HookUnmapViewOfFileExを用いずに、直ちにファイルをクローズする方法も考えられ、この場合にもマップドメモリの内容が実ファイルに反映される可能性があることから、CloseHandleをトリガーとして検知することが望ましい。

CloseHandleのフック関数であるHookCloseHandle関数には、通常のCloseHandleの動作に加え次の機能を追加する。

HookCloseHandle関数においても、実施すべきことの基本的な考え方は、HookUnmapViewOfFile/HookUnmapViewOfFileEx関数の場合と同じである。メモリマップドリストを利用して以前のファイルの状態(暗号化前のヘッダデータ)と、HookCloseHandleが呼び出されたタイミングでの暗号化後のヘッダデータを取得して、これらヘッダデータを比較する。

HookUnmapViewOfFile/HookUnmapViewOfFileEx関数の場合と異なる点は、ヘッダデータを取得するまでのメモリマップドリストの辿り方である。その辿り方を図69及び図70に示す。

CloseHandle関数のパラメータには「マップの開始アドレス」は存在せず、ファイルハンドルのみとなる。そのため、前のファイルの状態(暗号化前のヘッダデータ)を取得するには、図69に示すように、メモリマップドリスト内の「暗号化対象ファイルのハンドル」を検索し、パラメータに指定されたファイルハンドルhObjectの値と合致する行の「暗号化前のヘッダデータ」列の値を取得する。

ただし「ファイルハンドル」の値は、オペレーティングシステム(Windows OS)により再利用される可能性がある。このため、ハンドルの一致による誤検知にならないために、「ファイルハンドル(hObject)」から「ファイルパス」を求め、「ファイルハンドル」の一致に加え、求めた「ファイルパス」と「暗号化対象ファイルパス」列の値が一致することも条件としてもよい。

暗号化後のヘッダデータ取得については、図70に示すように、ファイルハンドル(hObject)からReadFile関数等を使用し、ハードディスク22上の実ファイルから先頭データ(ヘッダデータ)を読み取る方法や、フック前のオリジナルのCloseHandleを呼び出し、クローズされたファイルを再度オープンし、ハードディスク22上の実ファイルから先頭データ(ヘッダデータ)を読み取る方法が考えられる。

処理のオーバーヘッドを考えると、ファイルハンドルを使用して先頭データを取得するほうが、よりよいパフォーマンスとなると思われる。

(第3の機能のまとめ)
明示的にマップのクローズ・反映処理が行われる場合の動作について、図71を用いて時系列に沿って説明する。

まず、ステップ1では、HookCreateFileMappingにより、メモリマップドリストに新しい行が追加される。新しい行には、暗号化対象ファイルのハンドル、暗号化対象ファイルパス、ファイルマッピングオブジェクトのハンドル、暗号化対象ファイルの暗号化前のヘッダデータが記入される。

図71では、暗号化対象ファイルのハンドルが「0xABC」であり、暗号化対象ファイルパスが「C:\test.pdf」であり、ファイルマッピングオブジェクトのハンドルが「0xABCD」であり、暗号化対象ファイルの暗号化前のヘッダデータが「25 50 44 46 2D」である。

次に、ステップ2では、HookMapViewOfFile/HookMapViewOfFileExにより、メモリマップドリストに、マップの開始アドレスが記入される。

図71では、呼び出し時のパラメータに指定されたファイルマッピングオブジェクトハンドル「0xABCD」がメモリマップドリスト内に存在したので、その行にマップ開始アドレス「0x201000」が追記される。

次に、ステップ3では、監視対象プロセスがランサムウェアであるとマップドメモリのデータが暗号化される。

次に、ステップ4では、HookUnmapViewOfFile/HookUnmapViewOfFileEx、又は、HookFlushViewOfFileにより、まず、UnmapViewOfFile/UnmapViewOfFileEx、又は、HookFlushViewOfFileの呼び出し時のパラメータに指定されたアドレスとマッチするものを「マップの開始アドレス」列から検索する(ステップ4−1)。次に、マッチする行があれば、その行のヘッダデータ(暗号化前)と、マップドメモリから取得した現在のヘッダデータ(暗号化後)とを比較して、差異があれば暗号化されたと判断する。そのようにして、監視対象プロセスがランサムウェアであるか否かを判断する(ステップ4−2)。

図71では、呼び出し時のパラメータ「0xABCD」から、メモリマップドリストの暗号化前のヘッダデータ「25 50 44 46 2D」を取得し、呼び出し時のパラメータ「0xABCD」により指定されたアドレス「0x201000」から現在のヘッダデータ(暗号化後)「50 4B 03 04 14」を取得する。これらを比較すると差異があるので、監視対象プロセスはランサムウェアであると判断する。

(ランサムウェアの検知処理(その1))
ランサムウェアの検知処理(その1)の詳細について、図72のフローチャートを用いて説明する。

HookUnmapViewOfFile/HookUnmapViewOfFileEx、又は、HookFlushViewOfFileを用いた場合のランサムウェアの検知処理である。

まず、UnmapViewOfFile/UnmapViewOfFileEx、又は、HookFlushViewOfFileの呼び出し時のパラメータ「lpBaseAddress」に指定されたアドレスがメモリマップドリストに存在するか否かを判断する(ステップS11)。

そのアドレスがメモリマップドリストに存在しなければ、直ちにランサムウェアの検知処理を終了する。

そのアドレスがメモリマップドリストに存在すると、その行のヘッダデータ(暗号化前)を取得する(ステップS12)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、呼び出し時のパラメータ「lpBaseAddress」により指定されたアドレスから現在のヘッダデータ(暗号化後)を取得する(ステップS13)。これは、現在のメモリ23の仮想ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS14)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、直ちにランサムウェアの検知処理を終了する。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS15)。

(ランサムウェアの検知処理(その2))
ランサムウェアの検知処理(その2)の詳細について、図73のフローチャートを用いて説明する。

HookCloseHandleを用いた場合のランサムウェアの検知処理である。

まず、HookCloseHandleの呼び出し時のパラメータ「hObject」に指定されたハンドルがメモリマップドリストに存在するか否かを判断する(ステップS21)。

そのハンドルがメモリマップドリストに存在しなければ、直ちにランサムウェアの検知処理を終了する。

そのハンドルがメモリマップドリストに存在すると、そのパラメータ「hObject」からファイルパスを算出する(ステップS22)。

次に、メモリマップドリストから「暗号化対象ファイルパス」を取得する(ステップS23)。

次に、パラメータから算出されたファイルパスと、メモリマップドリストから取得したファイルパスとが同じであるか否か判断する(ステップS24)。

ファイルパスが同じでなければ、直ちにランサムウェアの検知処理を終了する。

ファイルパスが同じであると、該当する行のヘッダデータ(暗号化前)を取得する(ステップS25)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、ファイルパスから現在のヘッダデータ(暗号化後)を取得する(ステップS26)。これは、現在のハードディスク22の実ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS27)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、直ちにランサムウェアの検知処理を終了する。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS28)。

(バックアップ処理)
本発明プログラムによれば、上述したように、監視対象プロセスがひとつ目のファイルの暗号化を実行した時点で、監視対象プロセスをランサムウェアとして検知することが可能である。しかし、ランサムウェアとして検知した時点で、既にマップドメモリの内容は暗号化された状態となっている。このため、監視対象プロセスを強制的に終了させても、ひとつ目のファイルの暗号化は阻止できない。

したがって、監視対象プロセスをランサムウェアとして検知した場合には、HookCreateFileMapping関数でバックアップしたファイルをハードディスク22の実ファイルとして書き戻すようにする。本発明プログラムの常駐プログラムにランサムウェアの検知を通知し、バックアップしたファイルを書き戻す。

バックアップファイルの書き戻しに際しては、(第2の機能:フックしたAPIにより監視対象プロセスの挙動を記録する機能)の(HookCreateFileMapping関数)に示した処理を適用する。

(第3の機能(その2):明示的にマップのクローズ・反映処理が行われない場合)
明示的にUnmapViewOfFile/UnmapViewOfFileEx、FlushViewOfFile、CloseHandleを呼び出さずとも、プログラムの終了時には、オペレーティングシステム(Windows OS)によってマップドメモリの内容がファイルに書き出される。ランサムウェアの開発者がAPIの監視から逃れるために、意図的に上述したクローズ処理を行わない方法をとることも考えられる。このため、このような場合にもランサムウェアを検知できるようにする必要がある。

明示的に上記のAPIが呼び出されない場合には、マップドメモリに対してヘッダデータの差異確認を行うトリガーがなくなる。このため、監視対象プロセスによりファイルが処理された直後に、そのファイルが暗号化されたかを検知することができない。

そこで、本発明プログラムでは、通常、ランサムウェアがファイルを連続して暗号化するという特徴に着目し、ファイル暗号化の連続性を利用して検知するようにした。

本発明プログラムは、MapViewOfFile、MapViewOfFileExのフック関数であるHookMapViewOfFile関数、HookMapViewOfFileEx関数に、更に次の機能を追加する。
(a)メモリマップドリストをすべて走査する機能。
(b)走査して取得した全ての行の「暗号化前のヘッダデータ」をそれぞれ取得する機能
(c1)走査して取得した全ての行の「暗号化対象ファイルパス」から、ハードディスク22上の実ファイルから現在のヘッダデータをそれぞれ取得する機能。
(c2)走査して取得した全ての行の「マップの開始アドレス」からメモリ23上の仮想ファイルの現在のヘッダデータを取得する機能。この場合は、マップの開始アドレスがOSにより再利用されていない、すなわち、マップの開始アドレスがメモリマップドリスト内で重複していない状況でのみ有効である。OSにより再利用されている場合、既に新しい情報で置き換えられている可能性があるためである。
(d)上記の全ての行の「暗号化前のヘッダデータ」と「暗号化後のヘッダデータ」とをそれぞれ比較し、それらに差異がある場合、ランサムウェアによるファイル暗号化操作であると判断し、プロセスを終了させる機能。

HookMapViewOfFile関数、HookMapViewOfFileEx関数に上述した機能を追加しても、ひとつ目のファイルの暗号化を検知することはできない。ひとつ目のファイルに対してHookMapViewOfFile関数、HookMapViewOfFileEx関数を実行したときには、ひとつ目のファイルに対する暗号化がまだ実行されていないからである。ふたつ目以降のファイルの暗号化でHookMapViewOfFile関数、HookMapViewOfFileEx関数を実行したときには、ひとつ目のファイルに対する暗号化は既に実行されているので、ひとつ目のファイルの暗号化を検知することができる。

(ランサムウェアの検知処理)
本発明プログラムによるランサムウェアの検知処理について、図74及び図75を用いて説明する。

図74に示すのは、監視対象プロセスにより連続的にファイルの暗号化が行われた場合の処理である。

ひとつ目のファイルに対してステップ1(HookCreateFileMapping)、ステップ2(HookMapViewOfFile/HookMapViewOfFileEx)、ステップ3(ランサムウェアによりマップドメモリのデータ暗号化)が行われる。

ステップ3まで終了した時点ではメモリマップドリストには、暗号化対象ファイルのハンドルに「0xABC」、暗号化対象ファイルパスに「C:\test.pdf」、ファイルマッピングオブジェクトのハンドルに「0xABCD」、暗号化前のヘッダデータに「25 50 44 46 2D」、マップ開始アドレスに「0x201000」が記録されている。

ひとつ目のファイルに対するステップ3の後、明示的なクローズ処理(UnmapViewOfFile/UnmapViewOfFileEx、FlushViewOfFile、CloseHandle)が行われないまま、オペレーティングシステム(Windows OS)によってマップドメモリの内容がファイルに書き出される。次にふたつ目のファイルに対する処理が行われる。

ふたつ目のファイルに対しても、同様に、ステップ1(HookCreateFileMapping)、ステップ2(HookMapViewOfFile/HookMapViewOfFileEx)、ステップ3(ランサムウェアによりマップドメモリのデータ暗号化)が行われる。

ステップ1まで終了した時点ではメモリマップドリストには、暗号化対象ファイルのハンドルに「0xDEF」、暗号化対象ファイルパスに「C:\doc.txt」、ファイルマッピングオブジェクトのハンドルに「0xEF01」、暗号化前のヘッダデータに「61 62 63 64 65」が記録されている。

ステップ2(HookMapViewOfFile/HookMapViewOfFileEx)の詳細について、図75のフローチャートを用いて説明する。HookMapViewOfFile/HookMapViewOfFileExを用いたランサムウェアの検知処理である。

まず、メモリマップドリストの走査を開始する(ステップS31)。

次に、メモリマップドリストの末尾であるか否か判断する(ステップS32)。メモリマップドリストの末尾であると、走査が終了したとして、直ちにランサムウェアの検知処理を終了する。

メモリマップドリストの末尾でないと、メモリマップドリストの該当行の「暗号化前のヘッダデータ」を取得する(ステップS33)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、メモリマップドリストの該当行の「暗号化対象ファイルパス」を取得する(ステップS34)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、該当行の「暗号化対象ファイルパス」のファイルから現在のヘッダデータ(暗号化後)を取得する(ステップS35)。これは、現在のハードディスク22の実ファイル、又は、現在のメモリ23の仮想ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS36)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、メモリマップドリストの次の行を走査すべくステップS32に戻る。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS37)。

(バックアップ処理)
本発明プログラムによれば、上述したように、監視対象プロセスがふたつ目のファイルの暗号化を実行した時点で、監視対象プロセスをランサムウェアとして検知することが可能である。しかし、ランサムウェアとして検知した時点で、既にひとつ目のファイル及びふたつ目のファイルのマップドメモリの内容は暗号化された状態となっている。このため、監視対象プロセスを強制的に終了させても、ひとつ目のファイル及びふたつ目のファイルの暗号化は阻止できない。

したがって、監視対象プロセスをランサムウェアとして検知した場合には、HookCreateFileMapping関数でバックアップしたファイルをハードディスク22の実ファイルとして書き戻すようにする。本発明プログラムの常駐プログラムにランサムウェアの検知を通知し、バックアップしたファイルを書き戻す。

バックアップファイルの書き戻しに際しては、(第2の機能:フックしたAPIにより監視対象プロセスの挙動を記録する機能)の(HookCreateFileMapping関数)に示した処理を適用する。

(除外リスト)
本発明プログラムを、システム上において動作する全てのプロセスに対して、そのプロセスがランサムウェアである否かを判断することは、システムに新たな負荷を加えることになる。

そこで、本実施形態では、明らかにランサムウェアではないプログラムを予め登録した「除外リスト」を作成しておき、除外リストに登録されたプログラムに対しては、本発明プログラムを実行しないようにする。

除外リストには正規のプログラムを登録する。例えば、システムにインストールされている「プログラム名」「プログラムファイル」「ファイルのフルパス」「ファイルサイズ」「ハッシュ値」「デジタル署名」等を必要に応じて登録する。

除外リストは、システムへのプログラムをインストールするたびに更新し、ハードディスク22上に格納しておく。本発明プログラムの起動時に除外リストの内容を読み込むようにする。

本発明プログラムの動作後、読み込んだ除外リストの情報はメモリ23上にマッピングされる。突然のマシントラブルでメモリ情報が揮発しても内容を失わないよう、ハードディスク22上のファイルに対して常に更新しておくことがよい。

また、除外リストのファイルは、マルウェアやランサムウェアによる編集を避けるため、暗号化しておくことが望ましい。

(プロセスの強制終了)
本発明プログラムが、監視対象プロセスがランサムウェアであると判断した場合、当該プロセスを強制終了する。プロセスの強制終了は、フックしている関数内で行う。一般的には、ExitProcess関数や、Exit関数等を用いることで実現できるが、プロセスを終了可能な命令であればいかなるものを使用してもよい。これにより、ランサムウェアによるファイルの暗号化を防ぐことができる。

なお、直ちにプロセスを終了させることで問題となる可能性のある環境においては、ユーザーに通知し終了の判断を仰ぐといった対応も可能である。

[発明の原理(その3)]
本発明の原理(その3)について説明する。

本願発明者等が確認しているランサムウェアの暗号化処理では、対象ファイルの内容全体が暗号化され、ヘッダ情報、データ部全てが書き換えられている。上述した発明の原理(その1)及び発明の原理(その2)では、ランサムウェアが対象ファイルの内容全体を書き換えることを前提として、対象ファイルの少なくともヘッダ情報が書き換えられたか否かを判断して、ランサムウェアを検知している。

しかしながら、今後、発明の原理(その1)及び発明の原理(その2)に基づくランサムウェア検知を逃れるために、ファイルのヘッダ情報は書き換えずに、データ部のみを暗号化するランサムウェアが出現する可能性が考えられる。

このようなランサムウェアの暗号化処理においては、暗号化後もファイルフォーマットが成立し、ファイルを正規のアプリケーションで開くことができるが、データ内容が確認することができず、ランサムウェアにより暗号化が達成されることとなる。

発明の原理(その1)及び発明の原理(その2)に基づく実施形態では、このようなランサムウェアを検知することが困難である。本発明の原理(その3)は、別の手法により、ファイルのヘッダ情報は書き換えずに、データ部のみを暗号化するランサムウェアを検知しようとするものである。

まず、ファイルのデータ部の内容は正規のアプリケーションによって常に書き換えられるものであるため、データ部が書き換えられたか否かのみによりランサムウェアを検知することはできない。

多くの環境では、特定のファイルを扱うアプリケーションはオペレーションシステム(OS)によって関連付けがなされている。例えば、拡張子が「.doc」「.docx」のファイルを開く際は、自動的に規定のアプリケーションであるMicrosoft社のWordアプリケーションにより開かれる設定となっている。

したがって、拡張子が「.doc」「.docx」に関連付けされていないプログラムが、拡張子「.doc」「.docx」のファイルのデータ部のみを変更するという処理は、当該プログラムがランサムウェアである可能性があると考えることができる。

本発明の原理(その3)は、監視対象プログラムがファイルにアクセスする際に、その監視対象プログラムが当該ファイルの拡張子に関連付けされていないプログラムであって、当該ファイルのデータ部のみを変化させたか否かを判断し、それに基づいてランサムウェアを検知する。

当該ファイルのデータ部のみを変化させたことの検知には、データ部の変化を検知するがヘッダ情報の変化は検知しない場合を含み、データ部の変化を検知し、かつヘッダ情報が変化していないことを検知する場合を含む。

なお、データ部のみの暗号化への対策においては、データ部の「変化」よりも、書き込み対象ファイルの拡張子に関連付けされていないアプリケーションがデータ部に「書き込む可能性がある」ことをランサムウェア検知の優先事項としてもよい。

ユーザーの設定やカスタマイズされた環境によっては、ファイルの拡張子に関連付けられた規定のアプリケーション以外のプログラムにより開いてデータ部を編集することがある。例えば、Microsoft Word以外のプログラムで、拡張子が「.doc」「.docx」のファイルのデータ部を編集することがある。

これに対しては、ユーザーに当該プログラムが「意図したプログラムであるか否か」を問う画面を表示して、ユーザーの回答に応じて、ランサムウェアではないことを示すホワイトプログラムリストに追加する。これにより、それ以降は、繰り返し検知されることがなくなる。

[第4実施形態]
本発明の第4実施形態によるプログラム、情報処理装置及び情報処理方法について図76乃至図82を用いて説明する。

本実施形態では、監視対象プログラムがファイルにアクセスする際に、まず、監視対象プログラムが当該ファイルの拡張子に関連付けされたプログラムであるか否かを判断する。そして、関連付けされたプログラムでないと判断された場合には、監視対象プログラムが当該ファイルのデータ部のみを変化させたか否かを判断する。当該ファイルのデータ部のみを変化させたと判断された場合には、監視対象プログラムをランサムウェアの疑いありと判断する。

(監視対象プログラムがファイルの拡張子に関連付けされているか否かの検出)
本発明プログラムが、監視対象プロセスからのAPIをフックするときには、アクセスするアプリケーション名と、アクセス対象のファイル名(拡張子)を把握している。ファイルの読み書きの際に、アクセス対象ファイルの拡張子を切り出し、その拡張子から関連付けされたアプリケーションのパスを取得し、監視対象プロセスのアプリケーションのパスと比較し、これらパスが同じであれば、関連付けされたアプリケーションと判断する。

拡張子に関連付けられたアプリケーションのリストは、オペレーティングシステム(Windows OS)では、ハードディスク上にレジストリ値として保管されている。したがって、HKEY_CLASSES_ROOT配下にあるレジストリ値を直接読み取ることで、関連付けされたアプリケーションを取得することができる。

また、拡張子に関連付けられた単一のアプリケーションだけでなく、当該ファイルを右クリックした際に表示される「プログラムから選択」に表示されるアプリケーションの候補の一覧を取得することもできる。

ハードディスク上のレジストリ領域から「拡張子に関連付けられたアプリケーション」を取得する流れの具体例を図76に示す。

図76に示すように、レジストリ「HKCR\.docx」からCLSIDと呼ばれる識別子「{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}」を取得し、この識別子「{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}」から、拡張子「.docx」に関連付けられたプログラムのパス「C:\Program Files\Microsoft Office\Office15\WINWORD.EXE」を取得する。

より単純な方法として、オペレーティングシステム(Windows OS)のAssocQueryString APIの引数に「.docx」等の拡張子を指定して呼び出すことで、「C:\Program Files\Microsoft Office\Office15\WINWORD.EXE」のようにアプリケーションの場所を取得できる。

例えば、HookCreateFileMapping関数において、ファイルを暗号化しようとしているアプリケーションが当該ファイルの拡張子に関連付けされたアプリケーションであるかどうかを判断する流れを図77に示す。

関連付けられたアプリケーションを取得するには次のようにする。

まず、HookCreateFileMapping関数からファイルのハンドル「0x6C」を取得する。

次に、ファイルハンドルからGetFinalPathNameByHandle等を使用して、アクセス対象ファイルのファイルパス「C:\users\test\Desktop\test.doc」を取得する。

次に、取得したファイルパス「C:\users\test\Desktop\test.doc」から拡張子「.doc」のみを切り出す。

次に、AssocQueryStringを使用して、切り出された拡張子「.doc」に関連付けられたアプリケーション「C:\Program Files\Microsoft Office\Office15\WINWORD.EXE」を取得する。

一方、監視対象のプロセスに対しては、GetModuleFileName等を使用して、自身のパス
「C:\Program Files\Microsoft Office\Office15\WINWORD.EXE」を取得する。

そして、このようにして取得した拡張子に関連付けられたアプリケーションと、監視対象のプロセス自身のパスとを比較する。一致する場合には、拡張子に関連付けられたアプリケーションによるデータ変更であるから暗号化ではないと判断する。一致しない場合には、拡張子に関連付けられていないアプリケーションによるデータ変更であるから暗号化の可能性があると判断する。

(ファイルのヘッダ部とデータ部)
本発明プログラムでは、書き込み対象の場所がヘッダ部であるか、データ部であるかの判断が必要である。そこで、ファイルのヘッダ部とデータ部の判断方法を説明する。

ヘッダ部の位置やサイズはアプリケーション毎に定義され公開されている。基本的には公開されている各ファイルの形式にしたがう。本発明プログラムでは公開されている各ファイルの形式におけるヘッダ情報のうち、不変となる部分をそのファイル形式のヘッダ情報とする。

例えば、図78(a)は、画像形式であるビットマップファイルの公開されているフォーマットの一部である。ヘッダ部には、ファイルヘッダ、情報ヘッダ、カラーテーブル等の情報が記録されている。データ部には、ピクセルデータ(画像データ)が記録されている。

しかしながら、ヘッダ部のデータは全てが固定値ではない。例えば、図78(a)のヘッダ部において3バイト目(アドレス「00000002」)のデータ「F6 93 25 00」値は、当該ビットマップファイルのファイルサイズを示している。画像ファイルのファイルサイズが変化すれば、この部分のデータも変化する。

本発明では、ファイル種別が変化しない限り変化しない部分を「本発明のヘッダ部」とする。例えば、ビットマップファイルでは、図78(b)に示すように、ヘッダ部の先頭2バイト「42 4D」(文字列「BM」)を「本発明のヘッダ部」とし、その他の部分を[本発明のデータ部」とする。

なお、ファイル種別が変化しない限り変化しない部分は、必ずしも連続している必要はない。不連続な変化していない部分を「本発明のヘッダ部」としてもよい。例えば、図78(b)では、3〜6バイトを除いた「42 4D xx xx xx xx 00 00 00 00」を「本発明のヘッダ部」としてもよい。「xx」は変化しうるバイトを示す。

ファイル形式が公開されていない又はヘッダ部のサイズが公開されていない場合には、ファイルの先頭部分をヘッダ部、それ以外をデータ部としてもよい。この場合、先頭部分のサイズは任意であるが、一般的に数バイトから数十バイト程度を設定する。そして、ランサムウェアを検知しようとした結果、誤検知が多い場合にはサイズを調整できるようにする。

(一般的なファイル操作とファイルマッピングによるファイル操作)
前述したように、ファイル操作として、一般的なファイル操作とファイルマッピングによるファイル操作が可能である。

実ファイルはハードディスクに記憶されている。一般的なファイル操作におけるファイルの読み書きの処理では、その都度、メモリにバッファ(図示せず)を用意してファイルを読み込み、編集したデータをファイルに書き戻す、といった一連の処理を行う。

ファイルマッピングによるファイル操作では、ハードディスク22に記憶されている実ファイルの全体を、メモリに、仮想ファイル(ファイルマッピングオブジェクト)として展開する。ファイルマッピングによるファイル操作において、ファイルの内容を書き換える際には、その都度、メモリに展開された仮想ファイルに対して内容の書き換えが行われる。ファイルの内容の変更結果は一連の処理の最後の段階でハードディスクの実ファイルへ反映させる。

発明の原理(その3)は、一般的なファイル操作にも、ファイルマッピングによるファイル操作にも適用することができる。

(ファイルマッピングによるファイル操作)
発明の原理(その3)を、ファイルマッピングによるファイル操作に適用した場合について説明する。

本発明プログラムは、第2実施形態と同様の3つの機能を有する。

第1の機能は、現在動作中のプログラムや、後ほど起動するプログラムである監視対象プロセスが使用するWindows APIをフックする機能である。

第2の機能は、フックしたWindows APIにより、監視対象プロセスの挙動を記録する機能である。

第3の機能は、第2の機能により記録した挙動によりランサムウェアであるかどうかを判断する機能である。

(Hook関数及びそれに追加する機能)
本実施形態におけるHook関数及びそれに追加する機能を説明する。

本実施形態におけるフック対象APIは、第3実施形態と同様、次の通りである。

CreateFileMapping
MapViewOfFile/MapViewOfFileEx
UnmapViewOfFile/UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
本実施形態では、上記のフック対象APIをフックするHook関数に次のような機能を追加する。
(a)自身のプロセスが既定のプログラムであるかを確認する機能。
(b)HookCreateFileMapping関数の「暗号化対象ファイルの暗号化前のヘッダデータ」をメモリマップドリストに登録する際に、併せて「暗号化対象ファイルの暗号化前のデータ部のハッシュ値」を取得し登録する機能。
(c)HookMapViewOfFile関数、HookMapViewOfFileEx関数、HookUnmapViewOfFile関数、HookUnmapViewOfFileEx関数、FlushViewOfFile関数、CloseHandle関数において、「暗号化後(フック関数呼び出し時点)のデータ部のハッシュ値」を取得する機能。
(d)自身のプロセスが既定のプログラムでない場合、かつ取得した暗号化前後のデータ部のハッシュ値を比較し異なる場合に検知する機能。

(第3の機能のまとめ)
明示的にマップのクローズ・反映処理が行われる場合の動作について、図79を用いて時系列に沿って説明する。

まず、ステップ1では、HookCreateFileMappingにより、メモリマップドリストに新しい行が追加される。新しい行には、暗号化対象ファイルのハンドル、暗号化対象ファイルパス、ファイルマッピングオブジェクトのハンドル、暗号化対象ファイルの暗号化前のヘッダデータ、暗号化前のデータ部のハッシュ値が記入される。

図79では、暗号化対象ファイルのハンドルが「0xABC」であり、暗号化対象ファイルパスが「C:\test.pdf」であり、ファイルマッピングオブジェクトのハンドルが「0xABCD」であり、暗号化対象ファイルの暗号化前のヘッダデータが「25 50 44 46 2D」であり、暗号化前のデータ部のハッシュ値が「4669.....CBD7」である。

次に、ステップ2では、HookMapViewOfFile/HookMapViewOfFileExにより、メモリマップドリストに、マップの開始アドレスが記入される。

図79では、呼び出し時のパラメータに指定されたファイルマッピングオブジェクトハンドル「0xABCD」がメモリマップドリスト内に存在したので、その行にマップ開始アドレス「0x201000」が追記される。

次に、ステップ3では、監視対象プロセスがランサムウェアであるとマップドメモリのデータが暗号化される。

次に、ステップ4では、HookUnmapViewOfFile/HookUnmapViewOfFileEx、又は、HookFlushViewOfFileにより、まず、UnmapViewOfFile/UnmapViewOfFileEx、又は、HookFlushViewOfFileの呼び出し時のパラメータに指定されたアドレスとマッチするものを「マップの開始アドレス」列から検索する(ステップ4−3)。

次に、マッチする行があれば、その行のデータ部(暗号化前)のハッシュ値と、マップドメモリから取得した現在のデータ部(暗号化後)のハッシュ値を計算する。続いて、暗号化前のデータ部のハッシュ値と暗号化後のデータ部のハッシュ値とを比較して、差異があれば暗号化されたと判断する。そのようにして、監視対象プロセスがランサムウェアであるか否かを判断する(ステップ4−2)。

図79では、呼び出し時のパラメータ「0xABCD」から、暗号化前のデータ部のハッシュ値「4669.....CBD7」を取得し、呼び出し時のパラメータ「0xABCD」により指定されたアドレス「0x201000」から現在の暗号化後のデータ部のハッシュ値「B66A1.....40AB」を取得する。これらを比較すると差異があるので、監視対象プロセスはランサムウェアであると判断する。

データ部のハッシュ値が何らかの理由で正しく取得できない場合には、(第3の機能(その2):明示的にマップのクローズ・反映処理が行われない場合)と同様に、2つ目のファイル暗号化処理の初期段階(MapViewOfFile/Exの呼び出しタイミング)で検知を試みる。

(ランサムウェアの検知処理)
ランサムウェアの検知処理の詳細について、図80のフローチャートを用いて説明する。

HookUnmapViewOfFile/HookUnmapViewOfFileEx、又は、HookFlushViewOfFileを用いた場合のランサムウェアの検知処理である。

まず、UnmapViewOfFile/UnmapViewOfFileEx、又は、HookFlushViewOfFileの呼び出し時のパラメータ「lpBaseAddress」に指定されたアドレスがメモリマップドリストに存在するか否かを判断する(ステップS41)。

そのアドレスがメモリマップドリストに存在しなければ、直ちにランサムウェアの検知処理を終了する。

そのアドレスがメモリマップドリストに存在すると、その行のヘッダデータ(暗号化前)を取得する(ステップS42)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、呼び出し時のパラメータ「lpBaseAddress」により指定されたアドレスから現在のヘッダデータ(暗号化後)を取得する(ステップS43)。これは、現在のメモリ23の仮想ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS44)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS45)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、監視対象プログラム自身が対象ファイルの拡張子に関連付けられたアプリケーションである否かを判断する(ステップS46)。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションであれば、直ちにランサムウェアの検知処理を終了する。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションでなければ、該当した行の暗号化前のデータ部のハッシュ値を取得する(ステップS47)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、lpBaseAddress(マップドメモリ)から現在のデータ部を取得し、そのハッシュ値を計算する(ステップS48)。これは、現在のメモリ23の仮想ファイルから取得したデータである。

次に、暗号化前のデータ部のハッシュ値と現在のデータ部のハッシュ値とを比較して、相違するか否かを判断する(ステップS49)。

暗号化前のデータ部のハッシュ値と暗号化後のデータ部のハッシュ値が相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS45)。

暗号化前のデータ部のハッシュ値と暗号化後のデータ部のハッシュ値が相違しなければ、ランサムウェアの検知処理を終了する。

(一般的なファイル操作)
発明の原理(その3)を、一般的なファイル操作に適用した場合について説明する。

一般的なファイル操作におけるファイルの読み書きの処理では、その都度、メモリにバッファ(図示せず)を用意してハードディスク上の実ファイルを読み込み、編集したデータをファイルに書き戻す、といった一連の処理を行う。

一般的なファイル操作の場合には、監視対象プログラムが、対象ファイルの拡張子に関連付けされていないアプリケーションであって、データ部に対しWriteFileが呼び出されるか否かを検知する。

本実施形態では、WriteFileをフックするHookWriteFile関数に以下の処理を追加する。
(a)自身のプロセスが既定のプログラムであるかを確認する機能。
(b)自身のプロセスが既定のプログラムでない場合に検知する機能。

ランサムウェアの検知処理の詳細について、図81のフローチャートを用いて説明する。

HookWriteFile関数を用いた場合のランサムウェアの検知処理である。

まず、書き込み対象ファイルが過去のReadFileの記録に存在するか否かを判断する(ステップS51)。過去のReadFileの記録とは、図22(b)に示すようなReadFileの通知記録データである。ここには、ReadFileのプロセスID、ファイルパスが順次記録されている。

書き込み対象ファイルが過去のReadFileの記録に存在しなければ、直ちにランサムウェアの検知処理を終了する。

書き込み対象ファイルが過去のReadFileの記録に存在すると、書き込み対象位置がヘッダの範囲内であるか否かを判断する(ステップS52)。

書き込み対象位置がヘッダの範囲内であると、その行のヘッダデータ(暗号化前)を取得する(ステップS53)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、書き込みデータの内容から現在のヘッダデータ(暗号化後)を取得する(ステップS54)。これは、現在のメモリ23の仮想ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS55)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS56)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、直ちにランサムウェアの検知処理を終了する。

ステップS52において、書き込み対象位置がヘッダの範囲内でないと判断されると、監視対象プログラム自身が対象ファイルの拡張子に関連付けられたアプリケーションである否かを判断する(ステップS57)。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションであれば、直ちにランサムウェアの検知処理を終了する。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションでなければ、書き込み前のデータ部(書き込み対象箇所のデータ)を取得する(ステップS58)。これは、現在のハードディスク22の実ファイルから取得するデータである。

次に、書き込み対象データを取得する(ステップS59)。これは、現在のメモリ23のバッファから取得するデータである。

次に、書き込み前後のデータの内容が相違するか否かを判断する(ステップS60)。すなわち、ステップS58で取得した書き込み前の書き込み対象箇所のデータと、ステップS59で取得した書き込み対象データとを比較して、相違するか否かを判断する(ステップS60)。

書き込み前後のデータの内容が相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS56)。

書き込み前後のデータの内容が相違しなければ、ランサムウェアの検知処理を終了する。

上記実施形態では、ファイルへの書き込み命令(WriteFile)によるヘッダデータの変更又はデータ部の書き込み前後のデータの変更を検知したが、ヘッダデータの変更やデータ部のデータの変更以外の他のファイル構造の不適切な状態への変更を検知してもよい。

(一般的なファイル操作の変形実施形態)
発明の原理(その3)を、一般的なファイル操作に適用した場合の変形実施形態について説明する。

第4実施形態における上記説明では、監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションでないことを検知し、かつ、WriteFileによる書き込み前後のデータが相違することを検知した場合に、監視対象プロセスをランサムウェア又はその疑いとして検知している。

しかしながら、WriteFileの呼び出し自体が、監視対象プログラムによる書き込みを行う意思を明確に示していると言える。WriteFileによる書き込み前後のデータの相違を検知しなくとも、監視対象プロセスをランサムウェア又はその疑いとして検知してもよい。

このようなランサムウェアの検知処理の詳細について、図82のフローチャートを用いて説明する。

HookWriteFile関数を用いた場合のランサムウェアの検知処理である。

まず、書き込み対象ファイルが過去のReadFileの記録に存在するか否かを判断する(ステップS71)。過去のReadFileの記録とは、図22(b)に示すようなReadFileの通知記録データである。ここには、ReadFileのプロセスID、ファイルパスが順次記録されている。

書き込み対象ファイルが過去のReadFileの記録に存在しなければ、直ちにランサムウェアの検知処理を終了する。

書き込み対象ファイルが過去のReadFileの記録に存在すると、書き込み対象位置がヘッダの範囲内であるか否かを判断する(ステップS72)。

書き込み対象位置がヘッダの範囲内であると、その行のヘッダデータ(暗号化前)を取得する(ステップS73)。これは、前もってハードディスク22の実ファイルから取得したデータである。

次に、書き込みデータの内容から現在のヘッダデータ(暗号化後)を取得する(ステップS74)。これは、現在のメモリ23の仮想ファイルから取得したデータである。

次に、取得した暗号化前のヘッダデータと暗号化後のヘッダデータとを比較して、相違するか否かを判断する(ステップS75)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違すれば、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS76)。

暗号化前のヘッダデータと暗号化後のヘッダデータが相違しなければ、直ちにランサムウェアの検知処理を終了する。

ステップS72において、書き込み対象位置がヘッダの範囲内でないと判断されると、監視対象プログラム自身が対象ファイルの拡張子に関連付けられたアプリケーションである否かを判断する(ステップS77)。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションでなければ、監視対象プロセスをランサムウェア又はその疑いとして検知する(ステップS76)。

監視対象プログラムが対象ファイルの拡張子に関連付けられたアプリケーションであれば、ランサムウェアの検知処理を終了する。

上記変形実施形態では、ファイルへの書き込み命令(WriteFile)によるヘッダデータの変更を検知したが、ヘッドデータの変更を検知しなくともよい。また、ヘッダデータの変更やデータ部のデータの変更以外の他のファイル構造の不適切な状態への変更を検知してもよい。

[変形実施形態]
本発明は上記実施形態に限らず種々の変形が可能である。

例えば、上記実施形態では、マイクロソフトのオペレーティングシステムであるマイクロソフトウィンドウズ(Microsoft Windows)に本発明を適用したが、Android、BSD、iOS、Linux、OS X、Windows Phone、IBM z/OS(全て登録商標)等の他のオペレーティングシステムに本発明を適用してもよい。各オペレーティングシステムに対するランサムウェアによる攻撃を確実かつ有効に阻止することができる。

また、上記実施形態では、実ファイルがハードディスクに記録されている場合に本発明を適用したが、ハードディスク以外のディスク、例えば、ソリッドステートドライブ(SSD)等の半導体素子メモリを用いたストレージや、携帯電話、スマートフォン等に用いられる半導体素子メモリを用いたストレージに、実ファイルが記録されている場合に本発明を適用してもよい。

10…情報処理装置
20…コンピューター(PC)
30…外部周辺装置
21…CPU
22…ハードディスク
23…メモリ
24…入出力装置
25…ディスプレイ
31…プリンター
32…外部記憶装置

Claims (18)

  1. コンピューターを、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    として機能させるためのプログラム。
  2. コンピューターを、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    として機能させるためのプログラム。
  3. 請求項1又は2記載のプログラムにおいて、
    前記第3の条件は、マッピング時の前記実ファイルのヘッダ情報とアンマッピング時の前記実ファイル又は前記仮想ファイルのヘッダ情報とが相違することである
    ことを特徴とするプログラム。
  4. コンピューターを、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    として機能させるためのプログラム。
  5. 請求項1乃至4のいずれか1項に記載のプログラムにおいて、
    前記判断部は、前記所定のプロセスにより、前記仮想ファイルを作成する関数、又は、前記仮想ファイルを前記メモリにマッピングする関数が呼び出されると、前記第1の条件を満足すると判断する
    ことを特徴とするプログラム。
  6. 請求項1記載のプログラムにおいて、
    前記判断部は、前記所定のプロセスにより、前記仮想ファイルを前記メモリからアンマッピングする関数、前記仮想ファイルの一部を前記ディスクに書き込む関数、又は、前記仮想ファイルのハンドルを閉じる関数が呼び出されると、前記第2の条件を満足すると判断する
    ことを特徴とするプログラム。
  7. 請求項2記載のプログラムにおいて、
    前記判断部は、前記所定のプロセスにより、前記仮想ファイルを作成する関数、又は、前記仮想ファイルを前記メモリにマッピングする関数が連続して呼び出されると、前記第4の条件を満足すると判断する
    ことを特徴とするプログラム。
  8. 請求項1乃至7のいずれか1項に記載のプログラムにおいて、
    前記コンピューターを、更に、
    前記所定のプロセスにより前記実ファイルが前記仮想ファイルとして前記メモリ上にマッピングされる時に前記実ファイルをバックアップしたバックアップファイルを生成し、前記判断部が前記所定のプロセスをランサムウェアと判断した場合には、前記バックアップファイルを前記ディスク上の前記実ファイルに書き戻すバックアップ部
    として機能させるためのプログラム。
  9. コンピューターに、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手順
    を実行させるプログラム。
  10. コンピューターに、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手順
    を実行させるプログラム。
  11. コンピューターに、
    所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断手順
    を実行させるプログラム。
  12. 請求項1乃至11のいずれか1項に記載のプログラムを記録したコンピューター読み取り可能な記録媒体。
  13. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    を有することを特徴とする情報処理装置。
  14. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    を有することを特徴とする情報処理装置。
  15. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する判断部
    を有することを特徴とする情報処理装置。
  16. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスにより前記仮想ファイルがアンマッピングされるという第2の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する
    ことを特徴とする情報処理方法。
  17. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記第1の条件が連続して発生するという第4の条件と、アンマッピング時の前記実ファイル又は前記仮想ファイルのファイル構造が不適切な状態に変更されているという第3の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する
    ことを特徴とする情報処理方法。
  18. 所定のプロセスによりディスク上の実ファイルが前記実ファイルに対応する仮想ファイルとしてメモリ上にマッピングされるという第1の条件と、前記所定のプロセスが前記実ファイルのファイル種別に関連付けられていないプログラムであるという第5の条件と、マッピング時の前記実ファイルの情報とアンマッピング時の前記実ファイル又は前記仮想ファイルの情報とが相違するという第6の条件とを満足する場合に、前記所定のプロセスをランサムウェアと判断する
    ことを特徴とする情報処理方法。
JP2017099584A 2017-05-19 2017-05-19 プログラム、情報処理装置、及び情報処理方法 Active JP6219550B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017099584A JP6219550B1 (ja) 2017-05-19 2017-05-19 プログラム、情報処理装置、及び情報処理方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017099584A JP6219550B1 (ja) 2017-05-19 2017-05-19 プログラム、情報処理装置、及び情報処理方法
US15/645,270 US10264002B2 (en) 2016-07-14 2017-07-10 Program, information processing device, and information processing method
US16/144,606 US20190028495A1 (en) 2016-07-14 2018-09-27 Program, information processing device, and information processing method

Publications (2)

Publication Number Publication Date
JP6219550B1 true JP6219550B1 (ja) 2017-10-25
JP2018195155A JP2018195155A (ja) 2018-12-06

Family

ID=60156778

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017099584A Active JP6219550B1 (ja) 2017-05-19 2017-05-19 プログラム、情報処理装置、及び情報処理方法

Country Status (1)

Country Link
JP (1) JP6219550B1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150235025A1 (en) * 2014-02-20 2015-08-20 Mark Mundy Process to prevent malicious changes to electronic files on an electronic storage device
JP5996145B1 (ja) * 2016-07-14 2016-09-21 三井物産セキュアディレクション株式会社 プログラム、情報処理装置、及び情報処理方法
US9514309B1 (en) * 2014-04-30 2016-12-06 Symantec Corporation Systems and methods for protecting files from malicious encryption attempts
US20160378988A1 (en) * 2015-06-26 2016-12-29 Quick Heal Technologies Private Limited Anti-ransomware
JP2017010531A (ja) * 2015-06-19 2017-01-12 エーオー カスペルスキー ラボAO Kaspersky Lab 変更されたデータを復元するシステム及び方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150235025A1 (en) * 2014-02-20 2015-08-20 Mark Mundy Process to prevent malicious changes to electronic files on an electronic storage device
US9514309B1 (en) * 2014-04-30 2016-12-06 Symantec Corporation Systems and methods for protecting files from malicious encryption attempts
JP2017010531A (ja) * 2015-06-19 2017-01-12 エーオー カスペルスキー ラボAO Kaspersky Lab 変更されたデータを復元するシステム及び方法
US20160378988A1 (en) * 2015-06-26 2016-12-29 Quick Heal Technologies Private Limited Anti-ransomware
JP5996145B1 (ja) * 2016-07-14 2016-09-21 三井物産セキュアディレクション株式会社 プログラム、情報処理装置、及び情報処理方法

Also Published As

Publication number Publication date
JP2018195155A (ja) 2018-12-06

Similar Documents

Publication Publication Date Title
US8397297B2 (en) Method and apparatus for removing harmful software
US5854916A (en) State-based cache for antivirus software
US7620992B2 (en) System and method for detecting multi-component malware
US7836504B2 (en) On-access scan of memory for malware
US7765410B2 (en) System and method of aggregating the knowledge base of antivirus software applications
US5572590A (en) Discrimination of malicious changes to digital information using multiple signatures
JP6370747B2 (ja) バーチャルマシーンモニタベースのアンチマルウェアセキュリティのためのシステム及び方法
US5398196A (en) Method and apparatus for detection of computer viruses
US20120017276A1 (en) System and method of identifying and removing malware on a computer system
US8819835B2 (en) Silent-mode signature testing in anti-malware processing
US8365297B1 (en) System and method for detecting malware targeting the boot process of a computer using boot process emulation
CN1285987C (zh) 高效计算机病毒检测系统和方法
US7945787B2 (en) Method and system for detecting malware using a remote server
US7779472B1 (en) Application behavior based malware detection
RU2551820C2 (ru) Способ и устройство для проверки файловой системы на наличие вирусов
CA2304163C (en) Dynamic heuristic method for detecting computer viruses
US7841006B2 (en) Discovery of kernel rootkits by detecting hidden information
JP5586216B2 (ja) コンテキストアウェアによるリアルタイムコンピュータ保護システムおよび方法
US5696822A (en) Polymorphic virus detection module
US10043001B2 (en) Methods and apparatus for control and detection of malicious content using a sandbox environment
US20020178375A1 (en) Method and system for protecting against malicious mobile code
CN103593608B (zh) 用于检测由虚拟机所执行的恶意代码的系统和方法
US7349931B2 (en) System and method for scanning obfuscated files for pestware
US8510828B1 (en) Enforcing the execution exception to prevent packers from evading the scanning of dynamically created code
US20020035696A1 (en) System and method for protecting a networked computer from viruses

Legal Events

Date Code Title Description
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20170810

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170905

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170908

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170926

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170927

R150 Certificate of patent or registration of utility model

Ref document number: 6219550

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150