■はじめに

LockerGogaは比較的新しいランサムウェアですが、世界では限定的ないくつかの大企業に対する標的型攻撃で使用され、一回限りの攻撃のために毎回カスタマイズされていると考えられており、攻撃の数に合わせて複数の亜種が確認されています。

LockerGogaが大きく注目を集めることになったのは、2019年初頭のフランスの事件が始まりですが、その事件に関与しているとされる検体はルーマニアからVirusTotalにアップロードされていました。それと関連するLockerGogaの興味深い話として、ランサムウェアの名前の「Goga」がルーマニア人における姓として使われているケースがあることや、この検体の最初のアップロード国も加味すると、「LockerGoga」というランサムウェア自体がルーマニアに由来するものであるとみる見解も一部あるようです。

LockerGogaに関する解析記事はすでに国外のベンダーからいくらか出ているものの、ある一つの事件に関する解説において様々な亜種の動作を一つにまとめて記載しているものがいくらかあり、また情報が断片的なものも少なくなく一つの検体としての全体像が少し見えづらいという印象を筆者は受けました。そのため本記事では、直近のLockerGoga関連事件として記憶に新しい今年3月のノルウェーでの攻撃で使用されたといわれている検体にフォーカスを当て、感染の始まりから終了までその挙動の全体像を解説します。また、本記事に限り以降では、該当ハッシュ値の検体を指し「LockerGoga」と記載することとします（※本記事で解説する検体のハッシュ値は本記事の末尾に記載）。

■LockerGogaの全体概要

まず初めに、LockerGogaと関連プロセスにおける全体連携と役割を一つの図に表します。

LockerGogaは下の図に示す通り、自身を複数起動させ、命令を「送る側」（マスター）と「受ける側」（スレーブ）に役割をそれぞれ分担（以降、マスター／スレーブ方式と呼ぶ）することでファイルの暗号化を行い、また、並行して複数の正規プログラムを利用し感染端末の復旧を妨げる各種不正操作を行います。

以降ではLockerGogaの感染の流れと個々の仕組みの詳細について一つずつ順を追って解説していきます。

■LockerGogaの感染の流れと詳細

LockerGogaの本体はEXEファイルであり、以下の図のように、アイコンにユーザーアカウント制御（UAC）の対象プログラムであることを示す盾マークが表示されていることからも分かる通り、管理者権限での実行を前提として作成されています。

そのため、ユーザーがLockerGogaの本体（EXEファイル）を手動で実行した場合はUACのダイアログに承諾させるか、攻撃者が遠隔から配布する場合はLockerGogaをPsExec等のツールや権限昇格に関わる脆弱性の利用など何らかの手口を利用して管理者権限で実行させる必要があります。

なお、多くの一般的なランサムウェアで見られるアイコン偽装がされていない点からも、何らかの正規ファイルに偽装してユーザーに手動でダブルクリックさせるような意図はあまり感じられず、どちらかといえば、PsExec等のツールやシステムサービスによる配布、脆弱性の利用等、なんらかの手段でユーザーの操作を介さずに管理者権限で実行させる感染手法を前提にして開発されているように見受けられます。

LockerGogaのEXEファイルには以下の通り「ALISA LTD」の有効なデジタル署名が付与されています（以下の画像はオフライン環境での様子であり現在は失効しています）。

■感染の始まり

LockerGogaのEXEファイルが管理者権限により実行されると、まず%temp%の一時領域にCMDのmoveコマンドを利用して自身のEXEファイルを移動させます（以下参照）。

なお、補足情報となりますが、このCMDによるEXEファイル移動の操作の際、該当EXEのプロセスが起動中であっても同一ボリューム上であればファイルの移動操作はMFTレコード情報の更新には影響を及ぼさないため、プロセスを起動したままプロセスの実体ファイルを移動させることができます（なお、「別ボリュームへの移動」やファイルの「削除」は不可能）。

ただしプロセスが起動している状態のまま実体ファイルを移動させるため、該当プロセスが保有するイメージファイル名（プロセスの実体となるEXEファイルのフルパス）の情報は元のままとなり、以下の図のように、PorocessHackerなどのプロセス調査ツールで確認した場合、LockerGogaのプロセスの実体ファイルがあるはずのフォルダ場所をエクスプローラーで確認しても該当EXEファイルは存在しておらず、PorocessHackerなどのプロセス調査ツールを使用して、親フォルダの場所や本体の実行ファイルの場所をプロセスから取得することができなくなります（ファイルが存在しないというエラーが表示される）。

この点については、（後述しますが）初めに起動した上記のプロセスをこの後すぐに終了していることからも、LockerGogaが意図的に行っているというよりは偶発的なものであると推測していますが、一般的な概念として実行中のプロセスの実体ファイルは移動されないという前提で捉えがちなため、もしこれが意図的に悪意を持って多用された場合、プロセスと実体を紐づけることが難しくなり、調査ツールやセキュリティソフトの一部では追跡が困難となりうるテクニックと言えます。

LockerGogaは、先ほどのコマンドにより、%temp%に移動させた自身の実体ファイルを、起動中の自身のプロセスからさらに実行します（下記図参照）。

なおLockerGogaは、実行時に自身に付与された実行引数によって、「マスター」と「スレーブ」に切り変えて動作するマスター／スレーブ方式を採用しています。

%temp%に移動した実体ファイルは実行されると、再度自身に「-m」の引数をつけて実行することで、「マスター」（命令を送る側）として起動させます（その後、実行元から起動した最初のプロセスは自身を終了します）。

ここまでの動きを一つの図にしたものが以下となります。

■管理アカウントのパスワードの強制変更

マスターとして起動したLockerGoga は、次にOS標準ツールの「net.exe」を利用して、標準ユーザーを除く全ての管理者アカウントのユーザーのパスワードを強制的に「HuHuHUHoHo283283@dJD」という共通の文字列に設定します（以下参照）。

以下は例として、感染端末上に「スティーブ」というユーザー名で作成していた管理者アカウントのパスワードがLockerGogaにより強制的に変更されようとした際のコマンドラインの様子です。

このパスワードについては、動的に生成したものではなく、以下のようにLockerGogaの本体にハードコーディングされ埋め込まれています。

つまり、このパスワードの強制変更の挙動による結果として次のような状況となります。

以下は、LockerGogaの感染前と後のアカウント一覧を比較した様子ですが、感染前はパスワードを設定していなかった管理者アカウントにおいて、感染後にパスワードが設定されている様子がわかります。

注目すべきなのは、管理者アカウント以外の標準ユーザーには変更を加えていない点です。

このように、パスワードの強制設定の対象を管理者アカウントのみに限定している事実は、一連の暗号化処理の後、脅迫文を記載したテキストファイルの閲覧とランサムウェアによる感染被害をユーザーに認識させるために、あえて標準ユーザーアカウントでログインできる余地を残したという意図とも捉えることができます。

■マスター・スレーブ方式による暗号化処理の分担

マスターとなったLockerGogaはその後、さらに自身を複数の子プロセスとして起動させますが、その際に「-s」の引数をつけることで「スレーブ」（命令を受ける側）として動作させます。つまり以下のようなプロセスツリー構造となります。

マスターとスレーブはそれぞれ以下の役割で動作します。

マスターはファイルの暗号化以外の不正操作を担当し、スレーブはファイルの暗号化の分担作業を担当します。

マスターは全てのドライブを列挙した上で、順にドライブ内のフォルダを階層的に検索していき、暗号化対象となるファイルのリストを作成します。その後、子プロセスとして起動させたスレーブに暗号化対象のファイルパスを都度渡すことで、暗号化処理自体をスレーブプロセスに担当させます。つまり、ファイルの暗号化という一つの処理で捉えると、暗号化する対象ファイルをスキャンする処理と、暗号化を行う処理をプロセスレベルで分担している事になります。

その際、スレーブを複数起動させ並列で処理させますが、一つのスレーブが担当する暗号化ファイルの数は一プロセスあたり10数個程度となります。一つのスレーブは10数個程度の担当範囲となるファイルの暗号化が終わり次第終了し、その後新たなスレーブがマスターによって生成されます。

以上までに説明した動作を一つの図に表したものが以下となります。

上記の説明の通り、一つのスレーブが担当する暗号化ファイルは限られた少数のファイルのみとなるため、以下の図のように、LockerGogaが暗号化処理を行う最中は常に2〜3個のスレーブがマスタープロセスの配下で入れ替わり立ち替わり（起動しては終了を繰り返し）、暗号化処理が進んでいく事になります。

なぜ、LockerGogaが上記のような暗号化手段を採用したかについて、複数プロセスを利用して暗号化を行うことで暗号化速度の効率を求めた結果だろうという見解も見られますが、もちろんその側面は一つに挙げられるとは思うものの一つのスレーブプロセスが少数のファイルのみを担当して入れ替わり立ち替わりする理由には繋がりにくいようにも感じます。この手段の背景には、一般的な対策製品やサンドボックスにおけるランサムウェアの検知手法の一つに、連続したファイルの読み書き処理の監視というものがあり、LockerGogaの開発者は一つのプロセスが担当する暗号化ファイルの数を出来るだけ抑えることで、対策製品等の暗号化検知から逃れようとした可能性が背景の一つにあるのではないかと筆者は推測しています。また、一つのプロセスが数多くのファイルの暗号化を担当する事により、次々と生まれては消える複数のプロセスで暗号化処理を常時分散させた方が、プロセスの強制終了など何らかの要因で暗号化が失敗し処理が継続できなくなった時のリスクを分散しているという見方もできます。ただしこれらの見方についても、あくまで推測の範疇を出ません。

■マスターとスレーブの命令の受け渡しテクニック

どのファイルを暗号化すべきかというマスターからスレーブへの暗号化に関する「命令」の受け渡しは、共有メモリを介したプロセス間通信（BoostC++ライブラリのIPC）が使用されます。そのため、マスターはスレーブを子プロセスとして実行する際、実行引数内で「-i」という文字列に続き共有メモリ名（“SM-tgytutrc”、SMはShared Memoryの略と推測）を引き渡すことで、プロセス間通信として読み書きすべき「共有メモリの場所」を指示します。以下の図はマスターがスレーブを子プロセスとして起動する際の実行引数（コマンドライン）となります。

また、スレーブがマスターからの暗号化命令を受け取ろうとしている際の、デバッガでのスレーブの解析状況を以下に示します。（正確には、スレーブがマスターから指定された共有メモリ名“SM-tgytutrc”をOpenFileMappingに渡すことでマスターが作成した既存のファイルマッピングオブジェクトを開き、MapViewOfFileExを使用してメモリにビューを生成、ビューのアドレスを取得した直後の状態）

メモリーの該当アドレス領域にマスターがスレーブに渡した文字列が確認できます。これは（後述しますが）Base64でエンコードされた暗号化対象のファイルのフルパスとなっています。

プロセス調査ツールである「ProcessHacker」や「ProcessExplorer」などでも、スレーブプロセスのプロパティから確認することで、マッピングされたメモリの状態を簡単に確認することができます。

以下は実際に、ProcessHackerを使用して、スレーブの該当アドレス帯のメモリを閲覧している様子ですが、Base64でエンコードされた文字列が確認でき、さらに、そのBase64でエンコードされた該当文字列をWindows標準搭載の「certutil.exe」でデコードしてみた結果、ある一つのファイルパスが現れました。これが、LockerGogaのマスターからスレーブへ暗号化を指示したファイルのフルパスとなります（つまり、このスレーブプロセスにこれから暗号化されるファイルとなります）。

上記のマスターとスレーブの共有メモリを利用した暗号化対象ファイルパスの受け渡しについて、わかりやすく概念図にしたものが以下となります。

以上までが、スレーブとして起動したLockerGogaがマスターから暗号化の命令を受け取るまでの流れとなります。続いてランサムウェアとしての主たる挙動となる暗号化の動作に入ります。

■暗号化処理におけるファイル操作

LockerGogaは自身のプロセスに以下の複数の特権を付与することで、様々な不正活動に必要な権限を得ます。これらの特権により、アクセス制御されているようなファイルもACLをバイパスして暗号化できるようになります。また、SeRestorePrivilege特権によりシステムファイルでさえも書き換えることが可能となります。

SeDebugPrivilege・・・システムプロセスを含む任意のプロセスへのフルアクセスを得ることが可能となる

SeBackupPrivilege・・・ACLで制限されたファイルやフォルダもバイパスされ読み込みが可能となる

SeRestorePrivilege・・・ACLで制限されたファイルやフォルダもバイパスされ書き込みが可能となる

SeLockMemoryPrivilege・・・メモリ内のページロックを行うために必要な権限

SeCreateGlobalPrivilege・・・共有メモリの作成時に必要な権限

ランサムウェアがファイルを暗号する際の「ファイルの読み書き」（※ 暗号化するために一旦ファイルを「読み込み」、読み込んだデータを暗号化し、暗号化したデータを「書き込む」という、基本的に全てのランサムウェアに共通するファイル操作のセット）の処理においてLockerGogaは、以下のようにntdll.dllからGetProcAddressでネイティブAPIのアドレスを明確に取得し利用しており、あえてKernel32.dllが提供するような、より一般的なWriteFile/ReadFileなどの標準的なAPIを避けているように見受けられます。このあたりは一般的なばらまき型のランサムウェアではあまり意識されておらず、多くは見られない点の一つとなります。

なお、LockerGogaに関する一部の記事では「他のランサムウェアと異なりゴミ箱(Recycle.Bin)のファイルまで暗号化する」といったような記述が見受けられますが、筆者の経験上、ゴミ箱の中を含めて暗号化するランサムウェアは決して少なくありません。またLockerGogaにおいても実際には、ゴミ箱をピンポイントで狙っているような処理はなく、単純にドライブとフォルダを上から順に暗号化を実施するため、メインドライブの最初に列挙される$Recycle.Bin内も対象になるためであり、意図的に狙っているものではないと考えられます。

実際に以下の図で分かる通り、メディアが挿入されていないドライブ（以下の図ではAドライブとDドライブ）なども無作為にアクセスしようとして内部的に処理が失敗している様子がわかります。こうした状況から、暗号化時におけるファイル操作のロジックは比較的単純といえます。

LockerGogaは暗号化する際、GetWindowsDirectoryによりWindowsフォルダのパスを取得し暗号化の対象から除外します。つまり、Windowsフォルダ以外の「全て」のファイルが暗号化の対象となります。

ただしLockerGogaのコード内部には、以下に挙げるいくからの特定拡張子のリストとそれを扱う処理が明確に含まれています。

この点についてもLockerGogaに関する一部の公開情報では、上記に挙げた特定の拡張子を持つファイルのみを暗号化対象とするといった記載や、一部の拡張子のファイル暗号化を避ける、特定のオプションをつけることで全てファイルが暗号化対象になる、といった記述も見られますが、少なくとも本検体においては、実行引数を一切付けずにLockerGogaを実行するだけで、以下の図のように、最終的に上記に挙げた拡張子によらず画像ファイルなどを含む全てのファイルを無作為に暗号化していることがわかります。

ただし、上に挙げた特定の拡張子とそれ以外のファイルにおいて、暗号化の処理の過程に全く違いがないというわけではなく、まず初めに上記の特定の拡張子を持つファイルを先に暗号化したのち、それらの暗号化が終わり次第その他の拡張子を暗号化する、という２段階に分けて処理を行っており、結果的に全てのファイルを暗号化していました。

２段階で暗号化を進めていることが理解しやすいよう、C:¥aaaaa¥というフォルダ内に様々な拡張子を３０個配置して検証した様子を以下の図に示します。なお、ファイルサイズによる処理の差異が出ないよう全て同一ファイル（同一ファイルサイズ）のファイルを３０個用意し、ファイル名と拡張子のみを変更して検証しています。

結果として、上で示したように静的解析で明らかになった特定の拡張子を持つファイルを優先的に暗号化していることがわかります。

さらに、ProcessMonitorを使用すれば、一つのスレーブプロセスの中で、特定の拡張子を持つファイルを優先的に暗号化している様子が以下の図のようにわかりやすく確認できます。

こうした挙動の背景として考えられるのは、他の亜種で特定の拡張子のみを対象とできるように機能自体を分離させていたものの、本検体においては全ファイルを暗号化するように両方の分岐処理を順に遷移するように呼び出す形で作成したという可能性があるかもしれません。

また他の考え方として、上で挙げた特定の拡張子は企業における主な重要なファイル（資産）である可能性の高い拡張子でもあるため、それらを優先的に暗号化することで、途中で暗号化が失敗しても出来るだけダメージを早めに加えておきたいという意図があるという見方もできなくはありません。

■暗号化されたファイルの構造

LockerGogaのスレーブはファイルを暗号化する際、ファイル全体を全て読み込んで暗号化するのではなく、以下の図のように、0x10000（65,536）バイトごとに区切って個々に暗号化を行なっています。これについては、read/writeのIOが多く発生するデメリットはあるものの、ファイルサイズが大きいファイルなどで一気に全体を読み込むよりもメモリの利用効率が良いなどのメリットを考慮した可能性があります。

また、一つのファイルの暗号化が全て終わると、暗号化したファイルの末尾に「GOGA」という文字列から始まる144バイトの構造体（以降、GOGA構造体と呼ぶ）を最後に追記します。

次に示すのは、LockerGogaが暗号化しようとしたあるファイルにおいて、ファイル本体部分の暗号化処理が完了した直後と、GOGA構造体が追記された後のバイナリを比較した様子となりますが、ファイル末尾に「GOGA」の文字列から始まる１４４バイトのデータが追記されていることがわかります。

LockerGogaはファイルを暗号化する際、Crypto++(Cryptopp) と呼ばれるC++クラスライブラリを利用し、１２８bitの AES暗号アルゴリズムによりファイルを暗号化します。その際、ファイルごとにランダムなAESキーとIVを使用しますが、LockerGogaは該当ファイルの暗号化に使用したそれらの暗号関連情報（AESのIVとKEY）をGOGA構造体の中に埋め込みます。ただし、埋め込まれるKEYはRSA暗号の公開鍵により暗号化されています。

以下はLockerGogaのGOGA構造体を生成する処理およびそれを追記するコードを抜粋したものとなります。

つまり、GOGA構造体は以下のような構造を持ちます。先頭の“GOGA”の文字列に続く４バイトにLockerGogaのバージョン番号が記載され、どのバージョンのLockerGogaで暗号化されたファイルなのかが判別可能になっており、以下の例では「1510」というバージョンのLockerGogaで暗号化されていることがわかります。その後ろに、暗号化されたファイルのファイルサイズやRSA公開鍵で暗号化されたAES暗号のKEYとIVなどが続きます。

■LockerGogaの脅迫文

LockerGogaは、ファイルの暗号化と併せて、以下に示すような脅迫文を含むテキストファイルをPublicのデスクトップに作成します。このテキストファイルの中には、一般のランサムウェアに見られるような仮想通貨の送金アドレスやURLは含まれておらず、ファイルを暗号化したという脅迫文とともに、匿名性の高いメールサービスであるProtonMail等の連絡先メールアドレスが記載されているのみとなっています。

なお、冒頭２行目に「the security system of your company」とあることからも、明らかに初めから企業を狙った標的型ランサムウェアであることが伺い知れます。

■暗号化後の後処理（各セッションのログオフ、ネットワーク無効化、データ抹消）

全ての対象ファイルの暗号化が終わると、LockerGoga（マスター）は、OS標準ツールの「logoff.exe」を利用して、自身が動作しているユーザーセッション以外の全てのセッションのログオフを試みます。これは、リモートからの復旧を困難とさせるためにリモート接続しているユーザー（のセッション）を締め出す意図などが考えられます。

その後、LockerGogaは、Windows標準ツールである「cipher.exe」を利用して、全てのドライブの空き領域を消去します。これには、フォレンジックによるファイルの復元を困難にさせる目的があると考えられます。

続いて、LockerGogaはOS標準ツールである「netsh.exe」を利用して、端末に存在する全てのネットワークインターフェイスを無効にします。これには、ネットワークからのシステム復旧などを妨害する目的があると考えられます。

またこの動作に関して、ファイルの暗号化前ではなく、ファイルの暗号化処理が一通り完了した後に全てのネットワークを無効にしていることから、この挙動順序が意図的だとすれば、ネットワーク上の共有フォルダやマウントドライブなども含めた被害拡大を想定した挙動であると考えることもできます。

その後、自身の本体である実行ファイルを3秒後に削除するバッチファイルを作成して実行します。つまり、LockerGogaは自動起動エントリーなどを作成せず、一度動作するとその一回切りで自己消去する、使い捨て型のランサムウェアであることがわかります。

そしてLockerGogaは、最後に自身が動作しているユーザーアカウントのセッションを「logoff.exe」によりログオフさせてから、自身のプロセスを終了します。

■WS2_32の静的リンクの謎

以上がLockerGogaの動作であり、自動起動エントリーの登録やネットワーク接続、横展開などのワーム機能などの挙動は見られません。

なおLockerGogaは、ネットワーク通信（WinSock2／ソケット通信）に関するWin32APIを提供するWS2_32.dllを静的リンクしています。しかし、ソケットの初期化と終了に関連するWin３２APIであるWSAStartupおよびWSACleanupをインポートして使用しているだけであり、特にそれ以上の関連コードは確認されず、関連したネットワーク動作も見られませんでした。これについては、将来的な亜種においてネットワーク機能を実装しようとしているのか、または過去のコードの名残なのか、など色々と憶測はできるものの、正確なところは判断できません。

■ブートローダーの暗号化とアカウントの締め出し

LockerGogaの本体（EXEファイル）は、LockerGogaのプロセスが終了したのち、前述のバッチファイルにより3秒後（timeout 3のコマンド）にCMDにより削除されます。

この一連の操作ののち、端末は自動的にログオフされ、以下のような画面の状態となります。

この後、標準ユーザーのアカウントであればLockerGogaにパスワードが変更されていないため、この状態からのログインが可能ですが、管理者アカウントの場合はLockerGogaにより強制的にパスワードが変更されているため、普段のパスワードを入力しても以下の図のようにログインできなくなります。

なお、（今回のようにマルウェア解析を行わない限りLockerGogaが変更したパスワードはわからないため、通常においてはできることではありませんが）LockerGogaに強制的に設定された「HuHuHUHoHo283283@dJD」というパスワードを使えば管理者権限のアカウントにログインすることも可能であり、その際の様子が以下となります（以下はWindows10での検証時の様子）。

つまりログインさえできればWindowsとしてはかろうじて動作する状態を保っていることがわかります。

なお、LockerGogaは前述のファイル暗号化の処理の過程で、他のファイルと並行し、「ブートローダー」というシステムファイルに対しても暗号を行います。ブートローダーとは端末を起動した際に初めに読み込まれ、OSを起動させるために必要なシステムファイルです。

ただし、ブートローダーにピンポイントで狙いを定めて暗号化している訳ではなく、通常のファイル暗号化の処理の流れの中でそのままブートローダーのファイルである「bootmgr」を暗号化しています。

以下は、LockerGogaが一連のファイル暗号化処理を進めている際のCドライブ直下の様子ですが、上から順に流れる暗号化処理の過程でWindowsのブートローダーである「bootmgr」もそのまま暗号化されていることがわかります。

コード上においても暗号化処理において「bootmgr」を明確に狙うような処理は確認しておらず、上の図を見てわかる通り、全ファイルを対象にして暗号化しているがためにその途中にあるbootmgrも暗号化されてしまっているだけとも捉えられ、そこに明確な意図があると言い切ることはできないように感じます。また、ここにはLockerGogaの開発者がSeRestorePrivilege特権を付与した事による弊害となってしまっているようにも思えます。

どちらにしても、この挙動のため、感染後にユーザーが一度でも端末を再起動してしまうと、２度とこの端末ではOSを起動できなくなってしまいます。これは端末起動時にシステムが最初に利用するブートローダーが読み込めなくなってしまうためです。

以下は感染後に再起動した際の様子ですが、端末の起動直後に「BOOTMGR is Missing」と表示され、OSの起動へ進めなくなってしまうことがわかります。

つまり、LockerGogaは結果的に、一度でもユーザーがシステムを再起動（またはシャットダウン）すると復旧や対処が困難となるような暗号化処理を行っており、一部においてLockerGogaがワイパー（破壊を目的としたマルウェア）である可能性が高いとされている見解の理由の一つはここにあります。

しかし、本記事で示した通りLockerGogaはパスワードの強制設定及び強制変更を管理者アカウントに限定していることから、標準ユーザーアカウントでログインする余地を少なからず残しています。「NotPetya」など過去に確認されているワイパーは端末を強制的に再起動させるものが多い一方、LockerGogaは全ての処理が終わった後、ユーザーをログオフさせるだけにとどめており、あえて端末を感染後に再起動させたり、シャットダウンさせたりしていません。

そのため、LockerGogaの感染後でも、標準ユーザーのアカウントでは（またはパスワードを入力さえすれば管理者アカウントにおいても）ログインすることは可能であり、ログインさえできれば、デスクトップなどに作成された脅迫文（テキストファイル）を閲覧することも可能であることがわかります。また、LockerGogaが作成した脅迫文章の文中にはシステムを再起動したりシャッドダウンしたりしないように注意書きが記載されています。

一般のランサムウェアのように、脅迫文章内にTorなどのURLが記載されておらず送金させるための手順が明記されていない点も、「ランサムウェア」としての不審点として報じられているケースも見受けられますが、これは一方で、ネットワークを利用した復旧を困難とさせるためネットワークインターフェイスを全て無効にしてしまった弊害であると捉えることもできます。ここでもし攻撃者との連絡方法すら明記してなければ確かに不審に感じますが、LockerGogaは脅迫文中の末尾に連絡先のメールアドレスを複数記載しています。

■LockerGoga解析におけるまとめと考察

一見、「ファイルの暗号化」と同時に、相反する「ブートローダーの破壊（暗号化）」を行う動作があるとだけ聞くと、ランサムウェアに偽ったワイパーであるかように受け止めてしまいがちですが、こうして動作を改めて一つ一つ確認しながらみてみると、システムにログインできる余地を残し、脅迫文面および攻撃者への連絡手段を閲覧できようにしている点から、依然LockerGogaがワイパーであると言い切れる状況ではないようにも思えます。

とはいえ、LockerGogaが感染後に脅迫文を一度も見せずユーザーをいきなりログオフさせてしまっている事実は、ユーザーがその後端末をそのまま再起動してしまうリスクを高める動きにもなってしまっており、本当に金銭搾取が目的であれば、bootmgrを暗号化対象から除外するか、または除外しないにしても、ログオフの直前に脅迫文章を見せ明確に「再起動してはいけない」点をはっきりと提示する必要があるのではないかとも考えられるため、巧妙にランサムウェアである可能性を残した「ワイパー」である可能性はもちろん十分に残っています。

その観点でいえば、脅迫文中にも矛盾するように感じる記述が見られます。脅迫文の中段に「我々の復号ツールを使えば同じネットワークの異なるコンピューターから全ての暗号化されたファイルを復号することができる」という記載があります。しかし、解析で明らかになったように、LockerGogaは感染端末にあるあらゆるネットワークインターフェイスを無効化するため、ネットワーク上の外部からそうしたツールのみで復元することは物理的に不可能であるようにも思えます。

もう一つ考えられるのは、攻撃者は対象組織や攻撃の目的に合わせてLockerGogaを「ランサムウェア」としても「ワイパー」としても利用できるよう自由にチューニングできるようにしている可能性であり、一見相反する挙動が垣間見えたり、どちらでも取れるような動きが混在していたりするのは、様々な挙動オプションが混ざってしまっているという背景があるのではないかと捉えることもできます。

どちらにしても、あらゆる「ランサムウェア」は攻撃者がその後一切コミュニュケーションに応じなければそれだけで被害者にとっては「ワイパー」となりうる側面を常に含んでおり、企業やユーザーにとって莫大な被害をもたらす大きな脅威として共通することに違いはありません。

最後に、以上までに解説したLockerGogaの感染における、起動から終了までの一連の流れを一つの図にまとめ以下に掲載します。

■本記事で使用したLockerGogaの検体：

SHA-256：c97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15