現在、ウクライナを中心に「GoldenEye」「Petya」「PEtrwrap」と呼ばれている新たなMBR破壊型かつワーム型ランサムウェアの脅威が拡大しています。

この記事では弊社マルウェア解析チームが現時点までに調査した調査内容を掲載します。

はじめに脅威の全体像を簡潔に記載した上で、後半ではより細かい分析結果を中心に解説していきます。

■今回の攻撃のおおまかな仕組みとマルウェアの挙動について

感染の方法については、サードパーティ製のアプリケーション「MeDoc」経由や、メールに添付されたファイル経由で感染する等、色々な情報が流れていますが、今のところ弊社では確証のある情報は確認できていません。

今回の攻撃の中核となるマルウェア本体のファイル形式はDLLとなります。

マルウェア本体となるDLLファイル（DLLマルウェア①とする）は名前のないエクスポート関数が用意されており、外部からエクスポート関数を関数名ではなく序数で呼び出されることを前提とした作りとなっています。

つまり、このマルウェアが動作するには、正規プロセスであるRundll32.exe等のDLLを呼び出すホストプロセスの存在が必須となります。

なお、名前がないエクスポート関数を持つという点については一般的なマルウェアとしてはあまり見かけない作りであり、解析を困難にさせる目的があると推測されます。

加えて、このDLLには有効でないMicrosoftのデジタル署名が付加されています。この点についてもデジタル署名が付与されているだけ（有効かどうかを確認しない）で安全とみなす製品、人の目を逃れるためと考えられます。

また、詳細は後述しますが、DLLファイルのリソースセクションには、複数の不正ツールが組み込まれており、感染活動の際に取り出して利用します。

名前がない該当のエクスポート関数（序数１）内の処理、つまり、このマルウェアが実行されると行われる主要な処理は、以下の流れで実施されます。

【マルウェアの不正活動の流れ】

• シャットダウン等の特別な処理を行うための複数の特権を自身に付与
• winsockの初期化
• 実行のコマンドライン引数のチェック
• ローカルキルスイッチのチェック（特定のファイルが存在すると自身を終了します）
• MBRの書き換え
• シャットダウンを行うタスクスケジュールの作成
• パスワードダンプツールの作成（32ビットおよび６４ビット用のツールがそれぞれリソースセクションに保有）
• パスワードダンプツールを子プロセスとして実行、名前付きパイプによるプロセス間通信にてパスワードを奪取
• ネットワーク情報の取得（NetBIOSから列挙）
• ネットワーク活動（横展開）の処理を開始
• 一般ファイルの暗号化を開始
• イベントログの削除
• 関数の実行により強制的なBSODを引き起こし、端末を再起動させる
  
  • まずNtRaiseHardError関数の呼び出し
  • それができない場合は、InitiateSystemshutdownExによるシャットダウンを試行
  • それが失敗した場合は、ExitWindowsExによるシャットダウンを試行
• 上記の処理が全て終わると自身のプロセスの終了

また、以下に挙げる特徴的な動作や横展開の挙動（ワーム活動）の機能があります。

【特徴的な挙動】

• 一時ファイルとして生成するパスワードダンプツールを利用した認証情報の奪取
• 格納されている資格情報を奪取 (CRedEnumerate関数の利用)
• ローカルキルスイッチのチェック（ファイルの存在有無の確認）
• PsExec及びWmicによる自身の横展開（ワーム活動）
• SMBv1の脆弱性攻撃による自身の横展開（ワーム活動）

■横展開の挙動（ワーム活動）について

SMBv1の脆弱性による横展開については、EternalBlueまたはEternalRomance（いずれもMS17-010の更新プログラム適用で修正される）で脆弱性を突き、DoublePulsarを設置、DoublePulsarを介してlsass.exeにインメモリでDLLインジェクションを行います。

設置されるDoublePulsarはWannaCry攻撃キャンペーン時のEternalBlueの時のものと命令コードが変わっているため、既存のfuzzbunchから命令を送っても利用することはできませんが、カーネル空間でフックされる関数（SrvTransactionNotImplemented関数）やフック関数の内容は基本的に同じであることを確認しています。

また正規プロセスである「lsass.exe」にインジェクションされる dll （DLLマルウェア②とする）はエクスポート関数を持たずDLLMainから主なコードが開始されます。

dll （DLLマルウェア②）はロードされると自身のリソース領域からdll（DLLマルウェア①）を復号して Windows フォルダ配下に作成し、以下のコマンドで実行します。

この際、Windowsフォルダ配下に作成されるDLL（DLLマルウェア①）のファイル名は、攻撃元で使用されていたDLLの名前と同一となります。つまり、攻撃元でDLLファイル名「XXXX.yyy」（DLLマルウェア①）が実行されると、最終的に、リモート先で感染した端末に作成されるDLL（DLLマルウェア①）のファイル名は「C:¥Windows¥XXXX.yyy」となり、これが「rundll32.exe C:¥Windows¥XXXX.yyy,#1 <数字>」というコマンドラインで実行されます。

※なお、現時点で一般に拡散しているファイルでは上記「XXXX.yyy」に該当するファイル名前は「perfc.dat」となります。

また、SMBv1の脆弱性による横展開（ワーム活動）だけでなく、PsExec及びWmicを利用した横展開も行います。

なお、今回のMBR破壊型ワームランサムウェアにおけるこれら一連のワーム活動では、ローカルネットワークのみが拡散先のターゲットなっており、先日のWannaCry攻撃キャンペーンで利用されたマルウェアのようにグローバルネットワークに攻撃を行う挙動は確認されていません。

PsExecの利用については、DuplicateTokenExを使用しユーザーのトークンを複製、WNetAddConnection2W関数によりadmin$の共有フォルダを検索、PsExecと自身を送り込んだうえでPsExecを利用して自身をリモート実行します。

PsExecは、リソースセクションの３つ目の項目から、復号して生成します。

その際、Windowsフォルダの配下に「dllhost.dat」という固定のファイル名で生成します。

また、以下はPsExecを実行する際の実行引数を生成するコードです。

また、Wmicによる横展開については、以下のコマンドを利用してリモートからユーザー名とパスワードを使用して接続しRundll32を呼び出すことでDLLをロードさせます。

さらにこのマルウェアは、mimikatzのようなパスワードダンプツールをリソースセクションから一時フォルダ内に作成し、名前付きパイプによるプロセス間通信を確立、lsass.exeからパスワードを奪取する挙動があります。その際、OSのビット数を調べ、それぞれのビット数に合致したツールを作成します。なお、これらのファイルは一時ファイルであり、使用が終わると削除するため、感染環境にはファイルとして残存しません。以下は、そのコードです。

■ローカルキルスイッチについて

今回の検体は、WannaCryのようにキルスイッチを持つことも判明しました。

ただし、WannaCryのキルスイッチはURLへの接続でしたが、今回のMBR破壊型ワームランサムウェアにおけるキルスイッチはローカルにあるファイルの存在有無となります。具体的には、Windows配下に自身のDLLファイル名から拡張子を削った文字列と同一のファイルがすでに存在する場合はExitProcessにより処理を終了します。つまり、マルウェアのDLLファイル名が「xxxx.yyy」(拡張子がyyy)だった場合、「C:¥Windows¥xxxx」（拡張子がない）というファイルが存在すれば処理を行わずマルウェアはプロセス終了します。

※なお、現時点で一般に拡散しているファイルでは上記「xxxx」に該当するファイル名前は「perfc」となります。

以下は、キルスイッチとなるファイルの確認を行うコードです。

ただし、感染時に上記のファイルが存在しない場合は、逆に該当ファイルを作成した上で処理を継続します。

つまりこの動作から、このローカルキルスイッチは多重感染および多重暗号化を防ぐ目的であることが推測されます。ミューテックスを利用せずにファイルの有無で多重感染を防ぐ点は少数派なマルウェアの部類に入ると言えます。

■ファイルの暗号化について

なお、今回のマルウェアは、MBRの書き換えに加え、一般的なランサムウェアと同じくファイルの暗号化を行いますが、その際はファイルの拡張子は追加せず、元ファイルを暗号化データで上書きすることで暗号化処理を行います。そのため、暗号化ファイルを別ファイルに作成し、元ファイルを削除するようなタイプのランサムウェアと比較すると、ディスクからのデータ復旧が難しい部類に入ると考えられます。

以下は、ドライブを列挙し、暗号化対象にする固定ドライブを選定しているコードです。

また、MBRを書き換えたことによる被害に気付かせるかのように、タスク登録によるシャットダウンを行う動作があります。

以下は、シャットダウンタスクを生成する際のコードです。

これにより、再起動後は以下のような脅迫文が表示され、OSが起動できなくなります。

また、これまでに挙げたシャットダウン等の特別なOS処理を行うために、プログラム開始時に自身に特権を付与する挙動があります（下記参照）。

■マルウェアの作りからみた分析

今回の検体が、2016年に確認されたランサムウェア「Petya」（またはその亜種）であるとの情報もありますが、弊社では2016年当時にPetyaを解析しており、その結果と比較すると以下の点など複数が「Petya」の当時の特色と異なると分析しています。

まず、2016年の「Petya」では、LoadLIbaryとGetProcAddressを利用した動的な関数呼び出しを多用することで難読化された状態にあり、バイナリ全体がそのままでは静的解析しづらい構造になっていました。しかし、今回のMBR破壊型ワームランサムウェアは、インポートしたDLLの関数を静的に利用しており、全体構造も難読化されておらず当時の「Petya」とは対象的に静的解析で十分把握しやすい構造となっています。つまり解析の観点だけから述べると解析しやすい構造に後退していることになります。

また、2016年の初期の「Petya」はMBRの書き換え動作のみを持っており、ファイルの暗号化挙動はありませんでした。また、管理者権限がない場合は自身を管理者権限で起動するようにUACで許可を求めますが、それを拒否される等により管理者権限で起動できない場合は、クラッシュし処理を停止する動作が確認されていました。

その後「Petya」は、管理者権限ではない場合にファイルの暗号化部分を担当する「Mischa」と呼ばれるランサムウェアと連携し動作する仕組みに進化しました。

さらに2016年12月には、MBRの書き換えとファイル暗号化の両方を一つの実行ファイルで行えるようになり、それ以前のPetya（Mischa）で表示させていた赤、緑のドクロでなく、黄色のドクロを画面に表示させる「GoldenEye」と呼ばれるランサムウェアに進化しました。そのため、今回のランサムウェアが「Petya」の一方で「GoldenEye」と呼ばれている背景も理解できます。

しかし、暗号化処理時の細かいファイル操作の挙動に注目すると、「Mischa」および、その後の2016年12月に現れた「GoldenEye」とも異なる挙動となることが弊社の解析により明らかになりました。

弊社マルウェア解析チームではこれまで数多くのランサムウェアを解析してきましたが、これまでに出現したほぼ全てのランサムウェアはファイル暗号化の際のファイル操作の挙動として以下の流れをとります。

• CreateFileでファイルをオープン
• ReadFileで暗号化対象のファイル内容を読み込み
• 読み込んだ内容を暗号化
• WriteFileで暗号化したデータをファイルへ書き込み
• CloseHandleでハンドルを閉じる

上記の処理、つまりReadFile&WriteFileを利用したファイル操作の流れは「Mischa」も、2016年12月に現れた「GoldenEye」も採用しており、例外ではありませんでした。

しかし、今回のMBR破壊型ワームランサムウェアでは、暗号化時のファイル操作に以下の処理の流れを取ります。

• CreateFileでファイルをオープン
• CreateFileMappingでファイルマッピングオブジェクトの作成
• MapViewOfFileでファイルマッピングオブジェクトのハンドルを取得
• ファイルの暗号化（CryptEncrypt）
• FlushViewOfFileによる実ファイルへの反映
• UnmapViewOfFileでプロセスのアドレス空間からアンマップ
• CloseHandleでハンドルを閉じる

これはファイルマッピングという技術を使用したWindows特有のファイル操作の一般的な処理の流れであり、ディスクへのI/Oを最小限に抑えることで効率的にファイルの操作を行うことが可能です。具体的には、メモリ上に作成した実ファイルのコピーとなる仮想ファイルをメモリ上で処理し、一連の処理後に実ファイルへ反映させます。ディスクファイルアクセスよりもメモリアクセスの方が高速なため、これにより暗号化処理の高速化が期待できます。

つまり、今回のMBR破壊型ワームランサムウェアは、ファイルマッピング手法を利用した効果的な暗号化処理を行なっていますが、実はランサムウェアでこの手法を取るものはほとんどありません。ファイルマッピングによる処理方法があまり知られていないというのもその背景にあるでしょう。我々が把握している限り、過去のランサムウェアにおいて同手法を採用していたのは「Spora」や「Satana」等の一部のみでした。

この「Satana」と呼ばれるランサムウェアは、今からちょうど一年前の2016年6月末に発見されたランサムウェアであり、MBRの書き換えとファイルの暗号化を行う挙動を持ちます。

つまり、ファイル操作にファイルマッピングを利用する点も併せて考えると、今回のMBR破壊型ワームランサムウェアはどちらかというと「Petya＆Mischa」や「GoldenEye」よりは「Satana」に近いと言えるでしょう。

表で並べると以下のようになります。こうしてみると、PetyaとGoldenEyeにおける関連性、Satanaと今回のランサムウェアにおける関連性が見えてきます。

上の表のとおり、足のつきやすいメールを使用した珍しい連絡方法を採用している点まで類似しています。

ただし、「Satana」のファイル暗号化時のファイルマッピングの処理において、仮想ファイルを実ファイルに反映させる際、FlushViewOfFileを利用せず、UnmapViewOfFileをいきなり呼ぶようになっています。

UnmapViewOfFileでも実ファイルへ処理結果を反映させることは可能ですが、FlushViewOfFileで確実に実ファイルへ反映させてからUnmapViewOfFileでアンマップを行うという流れが暗号化を迅速にファイルに反映させる意味ではより合理的な方法と考えられます。

このFlushViewOfFileを挟むか挟まないかは結果からするとどちらでもよく、ある意味マルウェア作成者の”癖”のようなものであると言えるため、「Satana」と今回のMBR破壊型ワームランサムウェアにこうした違いがある点が意味するところは興味深いと感じます。また、こうした観点から見ていくと、一見挙動が似ていても細部は微妙に異なることがわかります。

さらに、MBRを書き換えた後の処理も2016年当初の「Petya」とは異なります。

2016年当初の「Petya」はMBRを書き換えたのち、NtRaiseHardError関数を呼び出すことで強制的にBSOD(ブルースクリーン)を引き起こしますが、もしNtRaiseHardError関数が失敗すると処理が継続できない挙動となっていました。

しかし今回のMBR破壊型ワームランサムウェアでは、NtRaiseHardError関数を呼び出すところまでは同じですが、その後、NtRaiseHardErrorの呼び出しが失敗した場合はInitiateSystemshutdownExWを利用し、さらにInitiateSystemshutdownExWの処理が失敗するとExitWindowsExを利用するといったように、OSをシャッドダウンさせる挙動を一つ見ても、多重のエラーハンドリングがされていることがわかりました(以下の図参照)。

また、今回のMBR破壊型ワームランサムウェアは非常に多くのスレッドを生成しますが、DLLのDLLEntryPointにはDisableThreadLibaryCallsが設定されており、スレッドが生成されるたびにDLLMainが呼び出されないようにすることで処理に負荷がかからないようにしています。ここから一般的なDLLの開発に慣れている作成者像を見ることができます。

ここまでに記載したマルウェアの構造や実現方法等を見ても、少なくとも従来の「Petya」とは異なるレベルのランサムウェアであり、管理者権限ではない場合クラッシュし処理を終了していた当初の「Petya」の安易な作りを鑑みると、作成者のスキルが大きく異なるように感じます。

（もちろん、「Petya」の作者が大幅に開発手法を変化させた、進歩した等の可能性もあるでしょう。しかしもはやその時点で作者以外が「petya」かどうかを断言する術はないのではないでしょうか）

■まとめ

攻撃の感染方法については、現在のところ様々な報道がされ所説ありますが、マルウェアのワーム挙動を見る限り、グローバルを対象としておらず閉じられたローカルネットワークでの横展開に限定されているため、グローバルネットワークへの感染を手当たり次第に行った先日のWannaCry攻撃キャンペーンと比較すると、ローカルネットワークのみを狙う今回の閉鎖的ワーム型ランサムウェアは、その影響範囲に関して、特に国内においては世間で騒がれているほど、そしてWannaCryを超えるほどの脅威にはないように感じます。ただし、WannaCryの改変された亜種が出現し一般に広く拡散したように、元の攻撃者の意図しない２次配布者が、元の攻撃者の意図しない形で脅威を改変し2次拡散が行われるなど、今後も同様の攻撃が続くことが想定されるため、今回の攻撃に特化した特別な対応が必要ということではなく、他のマルウェアやランサムウェアと同様に継続的な対策が求められるといえるでしょう。

■Appendix：rundll32コマンドに付加される数値とバグ？

前述の通り、実行されるrundll32コマンドには末尾に＜数値＞が付加されます。

具体的には以下のようなコマンドです（末尾の「40」）。

この数値は「lsass.exe」にインジェクションされるDLLファイル（インメモリ）に、攻撃元で実行したDLLファイル名とともに埋め込まれている値です。

この値はタスクに登録される再起動（shutdown）の時刻の計算に使用されます。

具体的には以下の図のような計算の中で使用されます。

しかしながら、上記における「分」の計算はタイミングによって正しくない値になる場合があります。具体的には、59を超える値になる可能性があります。「時」については 24 で剰余をとるものの、「分」については最後の剰余計算をし忘れてしまったのでしょうか。

このような状況となった例が以下です。

この場合、以下のようにタスクが登録されません（59分までであれば登録されます）。以下は手動で試した画面ですが、同じコマンドを実行しようとするとエラーになりタスク登録されないことがわかります。

上記の通り、感染するタイミングによってはタスクが作成されない場合があります。しかしながら、このタスクによるOSの再起動は、本ランサムウェアにとっては保険の機構であり、再起動自体はタスクが実行される前の、感染直後のNtRaiseHardErrorによるBSOD等で実現されるため、タスクが登録されないからといって特に安心できるようなものではありません。

以下は、本記事の執筆にあたり使用した検体のハッシュ値となります。

• Petya（Mischa）のSHA256値：
  E03E2D150B8135CFB330394C35F9BF372801B8A7C52A7A271DB0A4EE46ABBDD7
  
  
• SatanaのSHA256値：
  683A09DA219918258C58A7F61F7DC4161A3A7A377CF82A31B840BAABFB9A4A96
  
  
• GoldenEyeのSHA256値：
  B5EF16922E2C76B09EDD71471DD837E89811C5E658406A8495C1364D0D9DC690
  
  
• 今回のランサムウェアのSHA256値：
  027CC450EF5F8C5F653329641EC1FED91F694E0D229928963B30F6B0D7D3A745
  64B0B58A2C030C77FDB2B537B2FCC4AF432BC55FFB36599A31D418C7C69E94B1

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