孝志6月末にウクライナを中心とし海外で被害を拡大させた「Petya」「GoldenEye」「NotPetya」などと呼ばれるMBR破壊型ワームランサムウェアですが、攻撃発覚後しばらく経過してもこうしてランサムウェアの名前が未だに統一されないのは、複数のランサムウェアやマルウェアに類似する特徴やコードがあるものの、それらが微妙に異なっており、同種と言いきれないような状態にある点がその要因の一つと考えられます。弊社マルウェア解析チームでは、継続した調査を実施した結果、このMBR破壊型ワームランサムウェアにさまざまな工夫や独自性があることを確認しており、作成者像としては、近年のマルウェアやランサムウェアの有効な機能をうまく取り入れ効果的に組み合わせられる高度な技術を持った者(または組織)であると想定しています。※本記事においては、2017年6月に出現したMBR破壊型ワームランサムウェアを「NotPetya」として以下統一して記載します。■攻撃者の癖をどこから捉えるか■プログラムにおいてある特定の処理を実現させる場合、結果は同じであっても複数の異なる手段が存在することが多々あります。プログラムの作成者が異なれば(完全なコピーをしていない限り)人の数だけ実現手段が多かれ少なかれ異なってきます。マルウェアの場合も、実現手段に着目することで、マルウェア作者の癖や特徴を知る重要な手がかりになるケースがあります。コードをコピーすることや流用するケースも十分にあるため、個々の特徴が全て作者自身によるものであるとは言い切れない点も念頭に置いておく必要がありますが、そうした場合であっても、マルウェアの類似性を図る一つの指標にはなるでしょう。今回は上記のような観点で、現在問題になっている「NotPetya」を中心に類似する複数の他ランサムウェアを横並びで分析、比較した結果をレポートします。前述の通り、MBRの書き換えを行う処理にも例外なく複数の手段があり、弊社マルウェア解析チームでは以下の4種類のランサムウェアにおいて、MBR書き換え処理の流れに関する比較を実施しました。(2016年12月に出現)4NotPetya(2017年6月に出現)ケース1:オリジナルPetya(出現時期:2016年3月)オリジナルPetyaはMBRの書き込みの際、おおまかに、以下の流れを取ります。オリジナルPetyaのMBR操作時におけるAPI呼び出しの流れ(読み込み部分)つまり、オリジナルPetyaではDeviceIoControl関数を利用してMBRの位置を割り出し、SetFilePointerExで先頭に移動し、上書きするという流れになっています。ここではオリジナルPetyaのMBR指定手法を「DeviceIoControl+SetFilePointerEx手法」とします。ケース2:Satana(出現時期:2016年6月)SatanaはMBRの書き込みの際、おおまかに、以下の流れを取ります。SatanaのMBR操作時におけるAPI呼び出しの流れSatanaの特徴は、論理ドライブ名から物理ドライブ番号および物理ドライブ名を取得せず、“¥¥.¥PHYSICALDRIVE0”という決め打ちの文字列でシステムドライブを指定している点です。これは手間を省く際等に行いがちな処理ですが、正確にシステムドライブを指定する場合、物理ドライブ番号を算出すべきであり、実装の差異としての特徴が見られます。MBRの位置を選択する方法として、ディスクの先頭位置とこちらも決め打ちで場所を指定しています。基本的にディスクの先頭位置はMBRになりますが、DeviceIoControlを利用してMBRであるかどうかを確認する処理を挟むオリジナルのPetyaからすると大きく異なり、このあたりも実装の差異としての特徴が出やすい部分といえるでしょう。ここではSatanaのMBR指定手法を「SetFilePointer手法」とします。ケース3:GoldenEye(出現時期:2016年12月)GoldenEyeはMBRの書き込みの際、おおまかに、以下の流れを取ります。GoldenEyeのMBR操作時におけるAPI呼び出しの流れ(読み込み部分)つまり、GoldenEyeでは、物理ドライブ名はPetyaと同じく物理ドライブ番号の取得を経て生成する流れを取っており、MBRの操作時にも、Petyaと同じくDeviceIoControl関数を利用してMBRの位置を割り出した上で、SetFilePointerExで先頭に移動して読み込み、書き込み時にMBRの位置を指定する際は、SetFilePointerおよびSetFilePointerExによる先頭位置の指定を採用しています。以上の事から、GoldenEyeのMBR指定手法については、Petyaと同じく「DeviceIoControl+SetFilePointerEx手法」となります。ケース4:NotPetya(2017年6月に出現)NotPetyaはMBRの書き込みの際、おおまかに、以下の流れを取ります。「NotPetya」のMBR操作時におけるAPI呼び出しの流れつまり、「NotPetya」は細かい部分を省くと、物理ドライブの番号の取得を経て物理ドライブ名を生成し、DeviceIoControl関数を利用してMBRの位置を取得、SetFilePointerExで先頭に移動し、書き込むという流れになっています。これは、まさにPetyaやGoldenEyeと同じ手法であり、「DeviceIoControl+SetFilePointerEx手法」となります。別の観点から見てみましょう。■再起動・シャットダウン処理の比較MBR書き換え型ランサムウェアは、往々にしてMBRを暗号化した後、PCを再起動させようとします。この再起動させる手段に着目してみても、それぞれ興味深い差異があることがわかりました。以下は、今回調査した4種のランサムウェアがPCの再起動またはシャットダウンを促す際の手法を調査した結果です。失敗した場合、次の関数が呼ばれるように多重のエラーハンドリングがされている上記の関数を呼ぶ前にプロセスが途中で強制終了されてもタスクでPCが再起動するよう考慮しているつまり、PCの再起動またはシャットダウンを促す際の手法を比較すると、「Petya」と「GoldenEye」が同じであり、「NotPetya」のみが他と比較して注意深く作成されていることがわかります。マルウェアの主な挙動をバージョンアップさせても、こうした末端のシンプルな処理はそのまま前のバージョンのコードを残すことが十分考えられるため、細部でありながら特徴が現れやすい部分の類似性、または、独自性は注目すべき点といえるでしょう。これまでの分析を表にすると以下となります。■書き換えられたディスクの状態における比較分析MBR書き換え型ランサムウェアにおいて、実際に書き込まれたMBRを含むハードディスクの状態を比較することでも、それぞれの差異や類似性が見えてきます。PetyaとNotPetyaを比較してみます。以下はそれぞれのランサムウェアにより書き換えられたハードディスクの先頭領域をディスクエディタで表示したものです。同じ部分が白色、異なる部分が黄色でマーキングされています。オリジナルのPetyaとNotPetyaが書き換えたディスク先頭領域の比較こうしてみると、第0セクタ(先頭の512バイト、0x00~0x1ffまで)、すなわちMBRの内容については一部異なるものの、全体的に同じデータが書き込まれています。第1セクタの使い方は大きく異なり、NotPetyaではブートプログラムとみられるデータが書き込まれていますが、Petyaでは元々のデータをXORで暗号化しています。GoldenEyeとNotPetyaはどうでしょうか。GoldenEyeとNotPetyaが書き換えたディスク先頭領域の比較GoldenEyeでは、Petyaの時と異なり第1セクタにNotPetyaと全く同じデータが書き込まれています。これを見るだけでもブート領域に書き込むデータの取扱いについて、NotPetyaとGoldenEyeには非常に高い関係性があることがわかります。NotPetyaでは起動画面にGoldenEyeの特徴的なドクロのアスキーアートは表示されずテキストのみであり、以下の通り、GoldenEyeにおいてドクロのアスキーアートがあった領域(第15セクタ辺り)はNotPetyaでは存在しません。GoldenEyeにあったドクロのアスキーアートの領域の比較つまり、GoldenEyeにあったドクロのアスキーアートの領域はNotPetyaにおいては上図の通り0で埋められています。以上から、GoldenEyeとNotPetyaにおけるブート領域への書き込みデータの類似性が確認できました。同様にPetyaとGoldenEyeについても確認してみましょう。以下はPetyaとGoldenEye、それぞれのランサムウェアにより書き換えられたハードディスクの先頭領域をテキスト表示したものです。実際に画面に表示される時は色違いではあるものの、表示される画面(ドクロやテキスト)が、並べてみてもほぼ同じであり、PetyaとGoldenEyeの間の類似性が高いことは明らかです。NotPetyaの順で関連性があるといえそうです。前回のブログで言及したSatanaにおいては、NotPetyaとブートレコードの書き換え方が大きく異なっていることを確認しています。SatanaとNotPetyaに関係性は見出せませんでした。■考察/まとめ以上の各比較結果と、弊社の前回ブログ(「話題のMBR破壊型ワームランサムウェアの内部構造を紐解く」)で分析したランサムウェアの暗号化時のファイル処理等に関する特徴等もあわせて表にまとめると以下となります。※以下の表では、同一または類似する項目を同じ色で表しています。各MBR破壊型ランサムウェアの分析比較結果(類似点が同色)こうして見ると、処理の細かい部分を比較してみても、「Petya」と「GoldenEye」の類似度は高く、一般にPetyaの改良版といわれている「GoldenEye」との関連性が強く裏付けられる結果になっています。一方で、SatanaとNotPetyaにおいてある程度類似する点は確認できたものの、細かい処理を見ると「Petya」と「GoldenEye」ほど類似性があるとはいえず、どちらかというと、NotPetyaにおける独自性が浮き彫りになってきました。これまでの分析結果を踏まえると、NotPetyaは、様々なマルウェアやランサムウェアの機能を効果的に組み合わせて作成されたオリジナルのランサムウェアの可能性があります。ファイル暗号化の際のファイル操作の仕組みは、「Satana」が使った、効率が良くふるまい検知されにくい可能性の高いファイルマッピングの手法を採用し、MBRの書換えの際の操作は「Petya」や「GoldenEye」が使ったより正確なMBRの選定テクニックを採用しています。それ以外の動作は他のマルウェアの弱点を補強するかのように独自性のある機能を付け加えているように見えます。以下は、NotPetyaが他の一般的なランサムウェアやマルウェアと比較して、独自性があり比較的高度な作成者像が想定できる特徴の一覧です。上記リストに記載した「独自ハッシュ化した文字列によるプロセス比較」という点についてですが、NotPetyaはウイルス対策製品のプロセスが存在するかどうかで挙動を変更する動きがあります。多くのマルウェアにおいてはウイルス対策製品のプロセス確認時、起動中のプロセス一覧を取得した上で一つずつ単純に文字列比較を行ってプロセス名を検索していく挙動が一般的です。NotPetyaは、単純な文字列比較ではなく、ハッシュ化した値を比較することで間接的にプロセスチェックを行う挙動があります(詳細はAppendixを参照)。これにはセキュリティ製品による検出を避ける、解析を困難にするといった目的があると考えられます。いった点を鑑みると、「NotPetya」は、処理が失敗するとエラーで強制終了していた「Petya」や「GoldenEye」とは明らかに異なるといっても過言ではないでしょう。他のマルウェアやランサムウェアの良い点を盗み、自分なりに改良し、効果的に組み合わせているかのような、比較的高度な攻撃者像も見えてきます。ここまで分析したとおり、表面上は同じ動作・挙動に見えても、細部を慎重に比較していくと、実は大きく異なっていたり、一方で類似性が見つかったりと、表面的には見えていなかった情報が得られることがあります。これらの観点は、類似する脅威を正確に把握する上で、重要かつ必要なポイントといえるでしょう。前述のとおり、NotPetyaは動作中のプロセスを列挙し、列挙したプロセスのハッシュ値が特定のウイルス対策製品のプロセス名のハッシュ値と合致するかを確認します。「特定のウイルス対策製品のプロセス名」については、コード内に文字列の状態では保持しておらず、代わりにハッシュ化した値を保持しており、列挙した各プロセス名のハッシュを計算し、ハッシュ同士が合致するかどうかで比較します。結果として、「avp.exe」(カスペルスキー社のプロセス名)、「ccSvcHst.exe」「NS.exe」(シマンテック社のプロセス名)と比較し、その結果で挙動を変えます。以下は、NotPetyaが列挙したプロセス名のハッシュ値と保持しているウイルス対策製品のプロセス名のハッシュ値を比較する箇所のコードです。これらのハッシュ算出方法を「avp.exe」を例に以下に示します。簡単にまとめると、ハッシュの初期値を0x12345678として、これに列挙したプロセス名の文字1文字ずつとXORをとりその結果から1を減算する、という処理を3回繰り返します。繰り返しの度にXORの開始位置をずらしながら行う動作となります。ハッシュ値から「avp.exe」がプロセスとして存在することが確認できた場合には、MBRを含むディスクの先頭領域を無意味な値に書き換えます。これによりブートローダおよびOSが正しく起動しなくなります。「ccSvcHst.exe」「NS.exe」のいずれかが存在する場合にはネットワーク関連の動作をスキップします。「avp.exe」が存在しない場合は、無意味な値ではなく脅迫文を表示するコードに書き換えます。入れ替えた「Avp.Exe」や「avP.exE」のような場合でもハッシュ値が衝突(コリジョン)するため、必ずしも例示したプロセス名と完全一致しない場合でも、条件を満たすケースがあることを確認しています。