本サイトは、快適にご利用いただくためにクッキー(Cookie)を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
ここ連日ランサムウェア「WannaCry」が世間を騒がせています。
弊社では3月時点で「WannaCry 1.0」の検体を入手しており、ランサムウェアとしての「WannaCry」は以前からDropbox等で一般のランサムウェアと同様に拡散されていたことを把握しています。
本記事では、今回の一連の攻撃で利用された「WannaCry 2.0」を構成する複数のファイルおよびその関係性、そして「WannaCry 1.0」との比較分析により見えた「WannaCry 2.0」の特徴について解説します。
■WannaCryに感染するまでの複数検体の関連について
まず初めに、今回の感染で利用される一連のファイルの関連図を以下に示します。
世間で公開されている今回の攻撃の分析において、個別のファイルの視点で捉えているケースはあまり多くないと思われますが、実際にはこれだけ多くのファイルが関連しあって今回の攻撃に利用されています。
図1 今回の攻撃で使用された複数のファイルの関連図
まず、SMBの脆弱性を利用して拡散する検体(以降、ドロッパー①とします)のリソースセクションには、別のEXEファイルが完全な形で埋め込まれています。
ドロッパー①は実行されると、自身のリソースセクションから「tasksche.exe」(以降、ドロッパー②とします)をドロップし、サービスとして登録します。
さらに、ドロッパー②のリソースセクションにはパスワード圧縮されたZIPファイルが埋め込まれています。なお、弊社の解析により、解凍パスワードは「WNcry@2ol7」であることが判明しています。
図2 ドロッパー②のリソースセクションの操作に関わるコード部分
図3 ドロッパー②のリソースセクションのZIPファイルを一般的なZIP解凍ソフトで閲覧した様子
ドロッパー②はカレントディレクトリにZIP内のファイルを解凍し作成します。
なお、ZIPファイルの各ファイルの役割については図1に詳細を記していますので、ここからは、いくつか特徴的なところをピックアップして解説します。
ZIPファイル内のフォルダ「msg」には、ランサムウェアのGUIで表示させる各言語の脅迫文書がリッチテキスト形式のファイルでまとめられています。
図4 ドロッパー②のリソースセクションのZIPファイル内の「msg」フォルダの内部
ZIP内にある「b.wnry」は、画像ファイルであり感染後に変更する壁紙の画像です。
図5 ドロッパー②のリソースセクション内ZIPファイル内の「b.wnry」ファイル
その後、ドロッパー②は以下のレジストリを作成します。
そのため、以下のレジストリの有無でも感染の有無を確認することができます。
図6 感染時に作成されるレジストリキー
また、以下のコマンドにより、全てのユーザーにNTFSアクセス権のフルコントロールを与えます。
図7 アクセス権の変更を行うコマンドを実行する際のコード
また、ドロッパー②は、以下のWin32APIのような特徴的なMutex名をシステムに登録します。
これは多重感染防止の目的と推測されます。
図8 ドロッパー②が作成するMutex値
■「WannaCry 1.0」と「WannaCry 2.0」の比較について
以下は、今年の3月前後に確認された「WannaCry 1.0」(左)と、今回攻撃で使用された「WannaCry 2.0」を比較した様子です。
図9 「WannaCry 1.0」(左)と、今回攻撃で使用された「WannaCry 2.0」を比較した様子
WannaCry 2.0ではGUIの右上に言語設定プルダウンメニューが追加されていることがわかります。
さらに興味深いことに、ランサムウェアの特徴である暗号化に関わる挙動が「WannaCry 2.0」のGUIのバイナリから無くなっています。
具体的には、ドロッパー②に暗号化挙動が移り、2つのバイナリが組み合わさることで従来の「ランサムウェア」として成立するように変更されています。
図10 2つのバイナリで「ランサムウェア」が成立する構造
なお、以下はドロッパー①からランサムウェアが実行されるまでの実際のファイル連携をあらわした図ですが、実際はドロッパー②から直接「@wannaDecryptor@.exe」(リソースZIP内に「u.wnry」として保存されていたファイル)が実行されるのではなく、キッカー(実行役)が間に入っていることがわかりました(ドロッパー②がシステム権限で動作している場合)。
図11 キッカーを挟んで実行される「@wannaDecryptor@.exe」
なぜ「@WannaDecryptor@.exe」を直接実行せず、なぜキッカーを間に挟んでいるのでしょうか。
その理由の一つに、Vista以降で導入された「セッション0の分離」という仕組みが関係しています。
Vista以降では、サービスやシステムのプロセスはセッション0というセッションで管理され、ユーザーが起動するアプリケーションはセッション1以上のセッションで管理されるようになりました。また、この変更により、セッション0のプロセスはユーザーインターフェイスを表示させることができないという制限が設けられました。
つまり、システム権限として起動したドロッパー②から直接子プロセスとして「@WannaDecryptor@.exe」を実行してしまうと同一権限で起動してしまい、GUIが表示できなくなってしまいます。
そのため、権限をユーザー権限まで降格させる機能を持たせた「taskse.exe」というキッカーを間に挟む必要があったと推測されます。
図12 権限降格させGUIを表示させる仕組み
■今後、注意すべきポイント
今回、ランサムウェアである「WannaCry」そのものにSMBの脆弱性を利用したワーム機能があるという情報が多く流れていますが、より厳密には今回ご紹介した通り、ランサムウェアの(暗号化に関する)機能とワーム(拡散)機能は明確にバイナリとして機能分離しており、ドロッパー①については、汎用的な作りになっている可能性も考えられなくはありません。
つまり、ドロッパー①のリソースセクションのEXEを別のマルウェアに変えるだけで、「WannaCry」とは異なるランサムウェアやマルウェアを配布することができるといえます。
図13 機能分離されたドロッパー①に注意が必要
さらに、ドロッパー①は、ユーザー権限では動作せず、管理者権限で実行される前提になっていることを解析の結果確認しています。つまり、攻撃の始まりの拡散時は、ドロッパー①を管理者権限で実行させる不正なスクリプトやマルウェア等のキッカーが存在したか、SMBの脆弱性を利用して初めから管理者権限に昇格していた等の可能性が考えられます。そうしたことからも、スクリプト添付等のメールで配布される等、従来通りの攻撃方法についても変わらずに注意が必要です。
なお、ドロッパー②については、ユーザー権限、管理者権限、システム権限で動作させられることがそれぞれ想定されており、ユーザー権限で動作した場合は、その権限で暗号化できる範囲のファイルを暗号化した上、UACを表示させボリュームシャドーコピーの削除を試み、管理者権限で動作した場合は、「taskse.exe」のキッカーを挟まずに直接「@WannaDecryptor@.exe」を呼び出し、システム権限で動作した場合は、上記で言及した通り、「taskse.exe」を利用して権限降格を行い「@WannaDecryptor@.exe」を呼び出します。このことから、ドロッパー②は、様々な拡散方法で展開されることを想定して作成されている背景が想定できます。このように、権限動作に着目することでも、ドロッパー①とドロッパー②がそれぞれ異なる展開方法を前提に個別に作成されたともいえるかもしれません。
以上となりますが、「WannaCry対策=パッチ適用」と特別に1:1で捉えるのではなく、WannaCry1.0がDropboxなど他の侵入経路を利用していたように、メール経由等も含め、他のランサムウェアと変わらない対策が引き続き必要です。
また、他のランサムウェアやマルウェアが今回のSMBの脆弱性を利用するケースも念頭に置き、多方面の備えが重要となります。
関連ブログ記事
おすすめ記事