6月末にウクライナを中心とし海外で被害を拡大させた「Petya」「GoldenEye」「NotPetya」などと呼ばれるMBR破壊型ワームランサムウェアですが、攻撃発覚後しばらく経過してもこうしてランサムウェアの名前が未だに統一されないのは、複数のランサムウェアやマルウェアに類似する特徴やコードがあるものの、それらが微妙に異なっており、同種と言いきれないような状態にある点がその要因の一つと考えられます。

 弊社マルウェア解析チームでは、継続した調査を実施した結果、このMBR破壊型ワームランサムウェアにさまざまな工夫や独自性があることを確認しており、作成者像としては、近年のマルウェアやランサムウェアの有効な機能をうまく取り入れ効果的に組み合わせられる高度な技術を持った者（または組織)であると想定しています。

 ※本記事においては、2017年6月に出現したMBR破壊型ワームランサムウェアを「NotPetya」として以下統一して記載します。

■攻撃者の癖をどこから捉えるか■

 プログラムにおいてある特定の処理を実現させる場合、結果は同じであっても複数の異なる手段が存在することが多々あります。またプログラムの作成者が異なれば（完全なコピーをしていない限り）人の数だけ実現手段が多かれ少なかれ異なってきます。

 マルウェアの場合も、実現手段に着目することで、マルウェア作者の癖や特徴を知る重要な手がかりになるケースがあります。もちろん、コードをコピーすることや流用するケースも十分にあるため、個々の特徴が全て作者自身によるものであるとは言い切れない点も念頭に置いておく必要がありますが、そうした場合であっても、マルウェアの類似性を図る一つの指標にはなるでしょう。

 今回は上記のような観点で、現在問題になっている「NotPetya」を中心に類似する複数の他ランサムウェアを横並びで分析、比較した結果をレポートします。

■MBRの書き換え処理における比較分析

 前述の通り、MBRの書き換えを行う処理にも例外なく複数の手段があり、弊社マルウェア解析チームでは以下の４種類のランサムウェアにおいて、MBR書き換え処理の流れに関する比較を実施しました。

1. ①オリジナルPetya (2016年3月に出現)
2. ②Satana (2016年6月に出現)
3. ③GoldenEye (2016年12月に出現)
4. ④NotPetya（2017年６月に出現）

ケース①：オリジナルPetya（出現時期：2016年3月）

 オリジナルPetyaはMBRの書き込みの際、おおまかに、以下の流れを取ります。

• システムドライブの論理ボリューム名を取得
  
  • （CreateFileで”¥¥.¥C:”のハンドルを取得）
• 論理ボリューム名から物理ドライブの番号を取得
  
  • （DeviceIoControl にIOCTL_VOLUME_GET_VOLUME_DISK_EXTENTSを渡す）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ | SYNCHRONIZE、FILE_SHARE_READ|FILE_SHARE_WRITE)
• ディスクの先頭のパーティション情報を取得しMBR（PARTITION_STYLE_MBRまたはPARTITION_STYLE_GPT）であるかどうかを確認
  
  • （DeviceIoControl に IOCTL_DISK_GET_PARTITION_INFO_EXを渡して取得）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ、FILE_SHARE_READ)
• SetFilePointerExでディスクの先頭位置（つまりMBR）に移動
• ReadFileによりディスクを読み込み
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • （GENERIC_READ|GENERIC_WRITE、FILE_SHARE_READ|FILE_SHARE_WRITE）
• WriteFileでディスクへ書き込み

つまり、オリジナルPetyaではDeviceIoControl関数を利用してMBRの位置を割り出し、SetFilePointerExで先頭に移動し、上書きするという流れになっています。

ここではオリジナルPetyaのMBR指定手法を「DeviceIoControl＋SetFilePointerEx手法」とします。

ケース②：Satana（出現時期：2016年6月）

 SatanaはMBRの書き込みの際、おおまかに、以下の流れを取ります。

• “¥¥.¥PHYSICALDRIVE0”という固定文字列を利用して以下の引数で物理ドライブを開く
  
  • (FILE_GENERIC_WRITE|FILE_READ_ATTRIBUTES|FILE_READ_DATA/FILE_LIST_DIRECTORY | FILE_READ_EA)
• １セクタあたりのサイズを取得
  
  • （DeviceIoControl にIOCTL_DISK_GET_DRIVE_GEOMETRYを渡す）
• SetFilePointerとReadFile＆WriteFileで第３セクタ、第６セクタを書き込み処理
• SetFilePointerでディスクの先頭位置（つまりMBR）に移動
• WriteFileでディスクへ書き込み

 Satanaの特徴は、論理ドライブ名から物理ドライブ番号および物理ドライブ名を取得せず、“¥¥.¥PHYSICALDRIVE0”という決め打ちの文字列でシステムドライブを指定している点です。これは手間を省く際等に行いがちな処理ですが、正確にシステムドライブを指定する場合、物理ドライブ番号を算出すべきであり、実装の差異としての特徴が見られます。

 また、MBRの位置を選択する方法として、ディスクの先頭位置とこちらも決め打ちで場所を指定しています。基本的にディスクの先頭位置はMBRになりますが、DeviceIoControlを利用してMBRであるかどうかを確認する処理を挟むオリジナルのPetyaからすると大きく異なり、このあたりも実装の差異としての特徴が出やすい部分といえるでしょう。

ここではSatanaのMBR指定手法を「SetFilePointer手法」とします。

ケース③：GoldenEye（出現時期：2016年12月）

 GoldenEyeはMBRの書き込みの際、おおまかに、以下の流れを取ります。

• システムドライブの論理ボリューム名を取得
  
  • （CreateFileで”¥¥.¥C:”のハンドルを取得）
• 論理ボリューム名から物理ドライブの番号を取得
  
  • （DeviceIoControl にIOCTL_VOLUME_GET_VOLUME_DISK_EXTENTSを渡す）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ | SYNCHRONIZE、FILE_SHARE_READ|FILE_SHARE_WRITE)
• ディスクの先頭のパーティション情報を取得しMBR（PARTITION_STYLE_MBRまたはPARTITION_STYLE_GPT）であるかどうかを確認
  
  • （DeviceIoControl に IOCTL_DISK_GET_PARTITION_INFO_EXを渡して取得）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ 、FILE_SHARE_READ)
• SetFilePointerExでディスクの先頭位置（つまりMBR）に移動
• ReadFileによりディスクを読み込み
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ | GENERIC_WRITE、FILE_SHARE_READ|FILE_SHARE_WRITE)
• SetFilePointerでディスクの先頭位置（つまりMBR）に移動
• WriteFileでディスクへ書き込み

つまり、GoldenEyeでは、物理ドライブ名はPetyaと同じく物理ドライブ番号の取得を経て生成する流れを取っており、MBRの操作時にも、Petyaと同じくDeviceIoControl関数を利用してMBRの位置を割り出した上で、SetFilePointerExで先頭に移動して読み込み、書き込み時にMBRの位置を指定する際は、SetFilePointerおよびSetFilePointerExによる先頭位置の指定を採用しています。

以上の事から、GoldenEyeのMBR指定手法については、Petyaと同じく「DeviceIoControl＋SetFilePointerEx手法」となります。

ケース④：NotPetya（2017年6月に出現）

 NotPetyaはMBRの書き込みの際、おおまかに、以下の流れを取ります。

• システムドライブの論理ボリューム名を取得
  
  • （CreateFileで”¥¥.¥C:”のハンドルを取得）
• 論理ボリューム名から物理ドライブの番号を取得
  
  • （DeviceIoControl にIOCTL_VOLUME_GET_VOLUME_DISK_EXTENTSを渡す）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ | SYNCHRONIZE、FILE_SHARE_READ|FILE_SHARE_WRITE)
• ディスクの先頭のパーティション情報を取得しMBR（PARTITION_STYLE_MBRまたはPARTITION_STYLE_GPT）であるかどうかを確認
  
  • （DeviceIoControl に IOCTL_DISK_GET_PARTITION_INFO_EXを渡して取得）
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • （GENERIC_READ、FILE_SHARE_READ）
• SetFilePointerExでディスクの先頭位置（つまりMBR）に移動
• ReadFileによりディスクを読み込み
• 物理ドライブ（“¥¥.¥PhysicalDrive0”）を以下の引数で開く
  
  • (GENERIC_READ|GENERIC_WRITE、FILE_SHARE_READ|FILE_SHARE_WRITE)
• SetFilePointerExでディスクの先頭位置（つまりMBR）に移動
• WriteFileでディスクへ書き込み

つまり、「NotPetya」は細かい部分を省くと、物理ドライブの番号の取得を経て物理ドライブ名を生成し、DeviceIoControl関数を利用してMBRの位置を取得、SetFilePointerExで先頭に移動し、書き込むという流れになっています。これは、まさにPetyaやGoldenEyeと同じ手法であり、「DeviceIoControl+SetFilePointerEx手法」となります。

では、もう少し別の観点から見てみましょう。

■再起動・シャットダウン処理の比較

 MBR書き換え型ランサムウェアは、往々にしてMBRを暗号化した後、PCを再起動させようとします。

この再起動させる手段に着目してみても、それぞれ興味深い差異があることがわかりました。

 以下は、今回調査した４種のランサムウェアがPCの再起動またはシャットダウンを促す際の手法を調査した結果です。

つまり、PCの再起動またはシャットダウンを促す際の手法を比較すると、「Petya」と「GoldenEye」が同じであり、「NotPetya」のみが他と比較して注意深く作成されていることがわかります。

たとえマルウェアの主な挙動をバージョンアップさせても、こうした末端のシンプルな処理はそのまま前のバージョンのコードを残すことが十分考えられるため、細部でありながら特徴が現れやすい部分の類似性、または、独自性は注目すべき点といえるでしょう。

これまでの分析を表にすると以下となります。

■書き換えられたディスクの状態における比較分析

 MBR書き換え型ランサムウェアにおいて、実際に書き込まれたMBRを含むハードディスクの状態を比較することでも、それぞれの差異や類似性が見えてきます。

まずはPetyaとNotPetyaを比較してみます。

以下はそれぞれのランサムウェアにより書き換えられたハードディスクの先頭領域をディスクエディタで表示したものです。同じ部分が白色、異なる部分が黄色でマーキングされています。

こうしてみると、第0セクタ（先頭の512バイト、0x00～0x1ffまで）、すなわちMBRの内容については一部異なるものの、全体的に同じデータが書き込まれています。ただし、第1セクタの使い方は大きく異なり、NotPetyaではブートプログラムとみられるデータが書き込まれていますが、Petyaでは元々のデータをXORで暗号化しています。

では、GoldenEyeとNotPetyaはどうでしょうか。

 GoldenEyeでは、Petyaの時と異なり第1セクタにNotPetyaと全く同じデータが書き込まれています。これを見るだけでもブート領域に書き込むデータの取扱いについて、NotPetyaとGoldenEyeには非常に高い関係性があることがわかります。

 ただし、NotPetyaでは起動画面にGoldenEyeの特徴的なドクロのアスキーアートは表示されずテキストのみであり、以下の通り、GoldenEyeにおいてドクロのアスキーアートがあった領域（第15セクタ辺り）はNotPetyaでは存在しません。

つまり、GoldenEyeにあったドクロのアスキーアートの領域はNotPetyaにおいては上図の通り0で埋められています。

 以上から、GoldenEyeとNotPetyaにおけるブート領域への書き込みデータの類似性が確認できました。

 同様にPetyaとGoldenEyeについても確認してみましょう。

以下はPetyaとGoldenEye、それぞれのランサムウェアにより書き換えられたハードディスクの先頭領域をテキスト表示したものです。

実際に画面に表示される時は色違いではあるものの、表示される画面（ドクロやテキスト）が、並べてみてもほぼ同じであり、PetyaとGoldenEyeの間の類似性が高いことは明らかです。

以上の結果をまとめると、ブート領域においては、GoldenEyeとNotPetyaが強く類似、そしてGoldenEyeとPetyaが強く類似しており、ブート領域に書き込まれるデータに限っては、 Petya -> GoldenEye -> NotPetyaの順で関連性があるといえそうです。

 なお、前回のブログで言及したSatanaにおいては、NotPetyaとブートレコードの書き換え方が大きく異なっていることを確認しています。

つまり、ブート領域に書込まれるデータに関しては、 SatanaとNotPetyaに関係性は見出せませんでした。

■考察／まとめ

 以上の各比較結果と、弊社の前回ブログ（「話題のMBR破壊型ワームランサムウェアの内部構造を紐解く」）で分析したランサムウェアの暗号化時のファイル処理等に関する特徴等もあわせて表にまとめると以下となります。

※以下の表では、同一または類似する項目を同じ色で表しています。

こうして見ると、処理の細かい部分を比較してみても、「Petya」と「GoldenEye」の類似度は高く、一般にPetyaの改良版といわれている「GoldenEye」との関連性が強く裏付けられる結果になっています。

一方で、SatanaとNotPetyaにおいてある程度類似する点は確認できたものの、細かい処理を見ると「Petya」と「GoldenEye」ほど類似性があるとはいえず、どちらかというと、NotPetyaにおける独自性が浮き彫りになってきました。

 これまでの分析結果を踏まえると、NotPetyaは、様々なマルウェアやランサムウェアの機能を効果的に組み合わせて作成されたオリジナルのランサムウェアの可能性があります。

例えば、ファイル暗号化の際のファイル操作の仕組みは、「Satana」が使った、効率が良くふるまい検知されにくい可能性の高いファイルマッピングの手法を採用し、MBRの書換えの際の操作は「Petya」や「GoldenEye」が使ったより正確なMBRの選定テクニックを採用しています。さらに、それ以外の動作は他のマルウェアの弱点を補強するかのように独自性のある機能を付け加えているように見えます。

以下は、NotPetyaが他の一般的なランサムウェアやマルウェアと比較して、独自性があり比較的高度な作成者像が想定できる特徴の一覧です。

• エクスポート関数名のないエクスポート関数の仕様
• 多重スレッドとDisableThreadLibaryCallsを利用した処理負荷の軽減
• 独自ハッシュ化した文字列によるプロセス比較
• 改変されたDoublePulsarの利用
• PSExec＆Wmic&EternalBlue&EternalRomanceという複数のワーム経路
• 多重のエラーハンドリングや保険機構
• FileMappingを利用した高速な暗号化時のファイル操作
• 名前付きパイプによる通信を利用した独自のパスワードダンプツールとの連携

 上記リストに記載した「独自ハッシュ化した文字列によるプロセス比較」という点についてですが、NotPetyaはウイルス対策製品のプロセスが存在するかどうかで挙動を変更する動きがあります。

 多くのマルウェアにおいてはウイルス対策製品のプロセス確認時、起動中のプロセス一覧を取得した上で一つずつ単純に文字列比較を行ってプロセス名を検索していく挙動が一般的です。しかし、NotPetyaは、単純な文字列比較ではなく、ハッシュ化した値を比較することで間接的にプロセスチェックを行う挙動があります（詳細はAppendixを参照）。これにはセキュリティ製品による検出を避ける、解析を困難にするといった目的があると考えられます。

 こういった点を鑑みると、「NotPetya」は、処理が失敗するとエラーで強制終了していた「Petya」や「GoldenEye」とは明らかに異なるといっても過言ではないでしょう。他のマルウェアやランサムウェアの良い点を盗み、自分なりに改良し、効果的に組み合わせているかのような、比較的高度な攻撃者像も見えてきます。

 またここまで分析したとおり、表面上は同じ動作・挙動に見えても、細部を慎重に比較していくと、実は大きく異なっていたり、一方で類似性が見つかったりと、表面的には見えていなかった情報が得られることがあります。これらの観点は、類似する脅威を正確に把握する上で、重要かつ必要なポイントといえるでしょう。

■Appendix：「NotPetya」によるプロセス名のハッシュ値計算アルゴリズムの詳細

 前述のとおり、NotPetyaは動作中のプロセスを列挙し、列挙したプロセスのハッシュ値が特定のウイルス対策製品のプロセス名のハッシュ値と合致するかを確認します。「特定のウイルス対策製品のプロセス名」については、コード内に文字列の状態では保持しておらず、代わりにハッシュ化した値を保持しており、列挙した各プロセス名のハッシュを計算し、ハッシュ同士が合致するかどうかで比較します。結果として、「avp.exe」（カスペルスキー社のプロセス名）、「ccSvcHst.exe」「NS.exe」（シマンテック社のプロセス名）と比較し、その結果で挙動を変えます。

 以下は、NotPetyaが列挙したプロセス名のハッシュ値と保持しているウイルス対策製品のプロセス名のハッシュ値を比較する箇所のコードです。

「avp.exe」のハッシュ値は0x2E214B44、「ccSvcHst.exe」のハッシュ値は0x6403527E、「NS.exe」のハッシュ値は0x651B3005 となっています。これらのハッシュ算出方法を「avp.exe」を例に以下に示します。

簡単にまとめると、ハッシュの初期値を0x12345678として、これに列挙したプロセス名の文字１文字ずつとXORをとりその結果から1を減算する、という処理を３回繰り返します。また繰り返しの度にXORの開始位置をずらしながら行う動作となります。

 ハッシュ値から「avp.exe」がプロセスとして存在することが確認できた場合には、MBRを含むディスクの先頭領域を無意味な値に書き換えます。これによりブートローダおよびOSが正しく起動しなくなります。また「ccSvcHst.exe」「NS.exe」のいずれかが存在する場合にはネットワーク関連の動作をスキップします。「avp.exe」が存在しない場合は、無意味な値ではなく脅迫文を表示するコードに書き換えます。

 なお、上記のハッシュ計算方法では、列挙した「avp.exe」「ccSvcHst.exe」「NS.exe」に限らず、一部大文字小文字を入れ替えた「Avp.Exe」や「avP.exE」のような場合でもハッシュ値が衝突（コリジョン）するため、必ずしも例示したプロセス名と完全一致しない場合でも、条件を満たすケースがあることを確認しています。

吉川 孝志 の他のブログ記事を読む

関連ブログ記事

• 話題のMBR破壊型ワームランサムウェアの内部構造を紐解く