テスト､兵器化、配信までのOilRigの作戦実行スピードを分析

This post is also available in: English (英語)

概要

攻撃者の作戦がどのようなスピードで展開されていくかを攻撃ライフサイクルの初期段階で考察するにはかなりの困難がともないます。偵察・兵器化のような攻撃の初期段階では､標的に直接働きかける配信段階と比べると、リサーチャーが分析に使えるデータがまだあまりないからです。

しかしながら､BONDUPDATERを配信した中東の政府機関に対する2018年8月の攻撃を継続調査するなかで、Unit 42リサーチャーは、OilRigによるテスト段階の活動を観測することができました。またこのテスト段階の活動が､続く攻撃で使用された兵器化済み配信文書の作成につながったことを確信するにいたりました。

OilRigがテスト活動を開発プロセスに組み込んでいることは明らかで､私たちは以前にも配信文書およびTwoFace webシェルでテスト活動を実行した様子を観測しています。彼らはそこで､配信文書をすこしだけ修正し、インターネットに広く公開されているアンチウイルス スキャニング ツールに送信してみて､それがマルウェアと判断されるかどうかを確認することで、検出回避方法を編み出すというプロセスをテスト活動に組み入れていました。オンラインのアンチウイルススキャナーには､無料で迅速にアンチウイルスをテストできるという利点がある一方､攻撃者がアンチウイルス エンジンによるマルウェア検出について学習するためのツールにもなっており､結果的に攻撃者に「品質保証サービス」を提供しているかたちになっています。

OilRigの作戦実行スピードを判断するために、テスト時に作成されたファイルの作成時間、配信文書の作成時間、攻撃でスピアフィッシング メールが送信された時間を比較しました。

OilRigのテスト活動は標的型攻撃のわずか6日前に開始され、2018年8月20日、21日、26日の3回にわたってテストが行われたことがわかりました。テスト実行者は、最終版のテスト ファイル作成後8時間以内に配信文書を作成しており、その20分後にスピアフィッシング メールを介してその配信文書が配信されています。

OilRigのテスト活動

新しいBondupdaterバージョンを使用した、脅威攻撃者グループOilRigによる最近の攻撃を調査していくなかで、Unit 42リサーチャーは、OilRigが使用した別のMicrosoft Office文書がないか探していました。そこから､同時期に他の攻撃で使用された別のマルウェアが見つけるかもしれないと考えたからです｡私たちは機能面にフォーカスすることにし､最近の調査で見つかったオリジナルのOilRig Microsoft文書を最初の足がかりとして調査範囲を広げていきました。

Unit 42リサーチャーは、いくつかの公開アンチウイルス テスト サイトに送信された11の異なるサンプルを見つけました(表1参照)。これらのサンプルは、OilRigが開発とテストの活動中に作成したもののようで、中東政府に対する最近のOilRig攻撃で使用された配信文書、 N56.15.doc (7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00) と多くの類似点がありました(これについても表1を参照してください)。このテストで私たちは､XLS-withyourface.xlsおよびXLS-withyourface – test.xlsといった文書のファイル名に前述の標的型攻撃で観測されたC2が含まれていることを確認しました。メタデータ、マクロ コード、C2ドメインを含むファイル名の類似点から、これらのファイルは、8月26日に発生した標的型攻撃で使用する前にOilRigが実際にコードのテストで使用したものと考えられます。これらすべてのテスト ファイルはMicrosoft Excel文書であるにもかかわらず、標的型攻撃で使用された実際のファイルはMicrosoft Word文書であったことは、興味深い点です。

表1 テスト活動中に生成されたファイルおよび関連した標的型攻撃で配信された文書

表1のMicrosoft Excelスプレッドシート内のメタデータから、OilRig開発者は、関連した標的型攻撃の6日前である8月20日にこれらのテスト文書の作成を開始したことがわかります。OilRigが実行したテスト活動はすべて8月26日の攻撃以前に発生しています。テスト活動と攻撃活動で「最終変更日」を相互参照すると、図1に示すとおり､活動の時系列を容易に描くことができます。

図1 テストおよび攻撃の活動の時系列

また､図2の図表は、8月20日と8月22日にアンチウイルス エンジンが繰り返しXLS-withyourface.xlsをマルウェアとして検出した様子を示しています。続く7分間で、テスト実行者は、さらに2つのサンプルを作成し、それらの検出は、それぞれ16件から6件に減っています。最終的に検出件数は8月21に最小となりますが、これが標的型攻撃の5日前です。図1の時系列から､8月21日と8月26日の間でテスト活動に谷が見られます。テスト実行者はこの間活動を停止していたのです。しかし、8月26日の攻撃直前に活動は再開され、Excel文書が変更されています。最後の繰り返しテストは、標的型攻撃で使用されたWord配信文書の作成時間から8時間前以内に行われています。

図2 テストの各繰り返しので実行された挿入および削除と比較した検出率

図2の図表で、テスト実行者によるテストの各繰り返しでのスプレッドシートの変更に伴って、検出率が上がったり、下がったりしているのがわかります。これらの検出率の変化によって、テスト実行者は、ファイルの変更度合いによって検出されるかどうかを判断することができます。このテスト活動を分析するに当たり、弊社は各繰り返しで実行された変更の数を比較しました。特に、GitHubファイル差分に基づく、挿入行数および削除行数と検出件数を比較して、変更量が検出率に明らかに影響を与えるかどうかを判断しました。図2では、わずかしか変更されていない繰り返し1および2では、検出件数が多く減り、変更が多い繰り返し3および4では、検出件数が少ししか減らない、あるいは大きく増加するという結果になっています。

ハイレベルで考察すると、変更の数量は必ずしもテスト実行者にとって重要ではなく、検出率を下げるには変更の質が重要で、テスト実行者は検出を回避する方法について情報を得ることができます。質の変更例は、繰り返し2における「wscript」を使用してドロップされたVBScriptを実行するコード行の削除で、これによって、検出率は16件から6件に減っています。最終的に、テスト実行者は、これらのテスト繰り返しから得た知見により、より検出されにくく、攻撃が成功しやすい配信文書を作成します。各繰り返しにおける変更について詳しくは、付録の分析を参照してください。

OilRigは何を学んだのか

OilRigの開発過程で、攻撃者が、開発技法を学び、適応させているのは明らかです。攻撃者は、変更を行い、再送信して、ファイルの特定のコンテンツがアンチウイルス検出されるかどうかを判断するためだけを目的として、テスト サービスにファイルを送信していることを弊社は観測しています。OilRig攻撃者は、このプロセスで学んだ知識を使用して、検出を回避する配信文書を開発し、攻撃の成功率を高めています。

各文書の差分比較を行うことで、Unit 42リサーチャーは、コードの各繰り返しを考察することができます。その際、OilRigがどのようにテストを実行したかだけでなく、攻撃者が配信文書の検出率を下げるために何を学んだかという観点で考察しています。OilRigが何を学んだかをすべて挙げることはできませんが、以下のように学んだと予想されることをいくつか推定することは可能です。

• ドロップされたVBScriptを実行する組み込みShell関数の汎用呼び出しを行うかどうかでマクロが検出されることがある
• Shell関数を使用した非表示ウィンドウ(vbHideフラグ)でのコマンド実行は、可視ウィンドウ(vbNormalFocusフラグ)を使用した場合よりも多く検出される
• マクロがシステムに書き込むVBScript内に文字列「powershell」を組み込むと検出される
• Shell関数を使用して実行されるコマンドで「powershell」文字列および「wscript」文字列に対して文字列難読化を使用すると、検出率が下がる

われわれは何を学んだのか

OilRigが検出をうまく回避する方法を学んだのと同様に、弊社も研究者としてそれぞれの繰り返しに着目することで学べることがありました。学びの機会を得ることは、脅威攻撃者の手法と能力の理解に役立つだけでなく、保護メカニズムのプロアクティブな構築にもつながります。

OilRigについては以下のことがわかりました。

• 文書に変更を加えた後、速やかにファイルをアップロードしてテストしており､ファイル作成からテストまでの時間は平均33秒
• テスト実行者が何度も繰り返しながら変更を加えることで、マクロが本来意図されていたようには機能しなくなっていたことから、テストの取り組み中はマクロの機能の維持は気にしていないものと思われる
• ドロップしたVBScriptの実行のために関数を変更するだろう｡具体的にはShellオブジェクトから組み込みのShell関数への変更を行うと思われる
• サンドボックス回避のためにスリープ機能を追加するだろう。具体的にはWait関数を使用すると思われる
• 文字列の各文字を16進形式に置き換えて連結するなど文字列の難読化技法を好んで使用している

この分析から、OilRig攻撃者が悪意のあるWord文書(弊社ブログで説明)のベースとして、悪意のあるExcel文書からのマクロを使用したことがわかりました。以下の類似点により、このマクロが配信文書の作成に使用されたことを強く確信しています。

• 個々の文字の16進数値を連結した文字列で表現する同じ文字列難読化技法が使用されています。この技法は、テスト用Excel文書と、OilRigの最近の攻撃で使用されたWord文書(弊社ブログで説明)の両方に存在しています。
• 埋め込みのVBScript内の「powershell」文字列および「cmd.exe」文字列を文字列難読化技法を使用して難読化しています。これは、一連のテスト活動の「繰り返し4」でテストされていました。
• 組み込みのShell関数で実行されるコマンドを文字列難読化技法を使用して難読化しています。これは、一連のテスト活動の「繰り返し8」でテストされていました。

OilRig攻撃者は、テスト活動で使用したマクロに変更を加えて、兵器化した配信文書を作成していると思われます。こういった変更としては、「HGHG」という関数を追加して、難読化したBONDUPDATER PowerShellスクリプトをファイルに保存する行為があります。また、OilRigは、VBScriptの保存に使用する変数を、テスト用Excel文書で確認された「DDDD」の代わりに、兵器化したWord文書では「A」という変数に変更していました。最後に、OilRig攻撃者は、マクロから関数「AA」を削除しました。この関数は、Excelに固有でWord文書には不要のおとりコンテンツが含まれると思われる非表示のスプレッドシートを表示させるものです。

結論

攻撃者や攻撃グループは、検出回避のため､マルウェアの開発・変更をサポートしてくれるファイルやURLのインターネットに公開されているスキャン サービスを日常的に使用しています。弊社ブログでも説明したとおり､私たちはこれまで蓄積してきたOilRigのテスト・開発に関する豊富な知見をさらに深められるよう､今後もOilRigの開発技術の変更を継続的に監視していきます。知見を深めることでOilRigの高い攻撃能力にさらにスポットライトをあて、攻撃者たちのより完全な姿を浮かび上がらせることができるからです。

攻撃グループの開発方法を詳細に調査することは、研究者にとって攻撃者のツール、戦略、および手順の理解を深める絶好の機会となります。アクティブな攻撃キャンペーンで最終的に使用されるマルウェアと開発中のマルウェアを比較することで、マルウェアの各繰り返しで加えられた修正と変更を理解できるようになります。さらに、マルウェア自体の特定の機能変更を確認できた場合は、新しい機能と前の機能を相関させることもできます。今回､テスト中に作成されたファイルと実際の攻撃で配信されたファイルのタイムスタンプを比較することで、OilRigの作戦実行速度の洞察を得ることもできました。OilRigが攻撃の6日前にテスト活動を開始し、文書を作成する8時間前にテストを終了し、文書を作成した20分後にスピアフィッシング メールで攻撃者がその文書を配信したと断定することもできました。

OilRigは引き続き活発な動きを見せていますが、パロアルトネットワークスのお客様は、この脅威グループから以下の方法で保護されています。

• AutoFocusをご利用のお客様は、Bondupdater_Docsでサンプルを調べることができます。
• WildFireは現在のOilRig Bondupdater_Docsファイルについて、悪意があると判断したファイルすべてを検出します。
• Trapsは、Bondupdater_Docsに現在関連付けられているすべてのファイルをブロックします。

付録

この付録には、攻撃者によるテストの一連の「繰り返し」ごとに実施した分析が含まれています。各繰り返しに対する分析を提示する前に、表1にファイルと検出率に関する追加情報も示してあります。

表1 テストの各繰り返し別の追加データ

繰り返し別の分析部分には、配信文書内のマクロに加えられた変更の説明が含まれています。これらの変更は、各繰り返しで比較した2つのファイル間の差分のスクリーンショットでも確認できます。差分のスクリーンショットで、背景が赤い行はファイルから削除されたもので、背景が緑の行はファイルに追加されたものです。

繰り返し0

このテスト活動に関連付けられている最初の既知のファイルは、攻撃者が作成したオリジナル文書ではないようです。そう考えるのは、このExcelスプレッドシートには、この配信文書の前のバージョンからのアーティファクトが含まれていると思われる__SRP_0というストリームが含まれているからです。__SRP_0ストリームには、アーティファクト、具体的には一連のbase64でエンコードされた文字列が含まれています。これらの文字列は、デコードされると、2018年8月の中東政府に対するOilRigの攻撃に関する弊社ブログで説明した7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00によってドロップされた「AppPool.ps1」というBONDUPDATER PowerShellペイロードのほぼ完全に同じコピーになります。次の図2では、__SRP_0からデコードしたbase64文字列と、弊社ブログで説明した「AppPool.ps1」ファイルとを比較しています。この比較では、改行されていることとスペースがあることの違い以外は完全に同一のコンテンツ(「withyourface[.]com」C2を含め)であることがわかります。

図2 前のBONDUPDATERペイロードとキャッシュ済みストリームから抽出したペイロードとの比較

この特定のサンプルを分析したとき、テスト実行者がPowerShellペイロードを悪意のあるWord文書(弊社ブログで説明)からシステムにドロップする方法を変更したことがわかりました。この悪意のあるExcel文書内のマクロは、AppPool.ps1ファイルを作成するのではなく、AppPool.vbsを作成するだけです。その後マクロはこのファイルを「wscript」を使用して実行します。次にVBScriptによってAppPool.ps1がシステム内に作成されます。これが、前の弊社ブログで説明したWord文書の手法との主な違いです。

また、テスト実行者は、サンプルからBONDUPDATERペイロードを完全に削除したようです。AppPool.vbsスクリプトでは、後にデコードされてAppPool.ps1ファイルに保存されるbase64エンコード化ペイロードの保存に使用される「mysrc」という空の変数が使用されているからです。

前述のとおり、このテスト活動は弊社ブログで説明したWord配信文書を使用した攻撃に先立つものと確信しています。さらに、これは脅威グループが実施した単なる一連のテストではなかったことも確信しています。__SRP_0ストリームに存在するBONDUPDATERツールが、テスト実行者が既にペイロードが含まれる文書をこれより前に作成していて、このテスト活動ではそのペイロードを削除していたことを示唆しているからです。テスト実行者がPowerShellペイロードに対してテスト活動を以前に実施して、配信文書のマクロ部分に現在のテスト活動を限定するためにそのペイロードを削除した可能性があります。

繰り返し1

この繰り返しでは、テスト実行者は1つのシンプルな変更を加えており、文字列「powershell.exe」をAppPool.vbsファイルに記述されないように削除しています。基本的にこの変更によって、VBScriptがAppPool.ps1を正常に実行できなくなるため、インストール プロセスが中断されます。ただし、テスト実行者は検出がこの文字列に起因するかどうかを判断するためにこの変更を加えています。図3の差分のスクリーンショットでは、「powershell.exe」文字列がなくなっていることはすぐにはわかりませんが、行24の「Shell0」を探すと、左の(赤い)テキストには「powershell.exe -exec bypass」と表示されているのに、右の(緑の)テキストでは「-exec bypass」となっていることがわかります。

図3 繰り返し1に関するファイル間の差分のスクリーンショット

繰り返し2

この繰り返しでは、テスト実行者は、wscriptアプリケーションを使用してAppPool.vbsスクリプトを実行する行を削除しました。図4からわかるように、テスト実行者は、コードの行全体を削除し、新しい行に置き換えました。

図4 繰り返し2に関するファイル間の差分のスクリーンショット

繰り返し3

この繰り返しでは、テスト実行者はマクロをかなり大幅に変更しました。まず、テスト実行者は、"C:\ProgramData\WindowsAppPool"フォルダを作成した後、このフォルダにAppPool.vbsファイルを書き込む前に10秒間スリープするコードの行を導入しました。これは図5の行12にあります。図5の下部から図6へ続く箇所は、テスト実行者が、このマクロの前のバージョンで見られたVBScriptの代わりにbase64でエンコードされたBONDUPDATER PowerShellペイロードをDDDD変数に追加したことも示しています。ここに含まれているbase64でエンコードされたBONDUPDATERは、繰り返し0で言及した最初のテストサンプルのキャッシュされた__SRP_0ストリームと完全に同じペイロードです。図7も、テスト実行者が、VBScriptを実行するために理論的に使用する"wscript.shell"オブジェクトを含めるようにShell0変数を設定する行を削除したことを示しています。

図5 スリープコードとその他のオブジェクトの追加を示す繰り返し3に関するファイル間の差分のスクリーンショット

図6 VBScriptの保存に使用する変数の変更を示す繰り返し3に関するファイル間の差分のスクリーンショット

図7 'wscript.shell'オブジェクトの削除を示す繰り返し3に関するファイル間の差分のスクリーンショット

繰り返し4

この繰り返しでは、テスト実行者は、マクロのbase64でエンコードされたPowerShellスクリプトを、前の繰り返しで置き換えたVBScriptに置き換えます。また、テスト実行者は、"Scripting.FileSystemObject"オブジェクトと"Wscript.Shell"オブジェクトをインスタンス化するコードの行を削除しました(図8の行17と18)。

図8 VBScriptをマクロに追加して戻したことを示す繰り返し4に関するファイル間の差分のスクリーンショット

わずかな変更ですが、テスト実行者はVBScriptをマクロに再導入したようです。DDDD変数に格納されたVBScriptの2つの変更は、スクリプト内の2つの文字列の難読化です。具体的には"powershell"(図9の行24)と"cmd.exe"(図9の行25)の文字列です。代わりに、これらの文字列は両方とも、それぞれの文字の16進数値を使用して一度に1文字が組み込まれ、連結されました。たとえば、"powershell"の文字列は次の文字列に置き換えられました。

テスト実行者は、組み込みShell関数を使用し、wscriptアプリケーションを使用して"AppPool.vbs"スクリプトを実行する行(図9の行29)も追加しました。テスト実行者は、Shell関数の呼び出しに、非表示ウィンドウでコマンドを実行する"vbHide"フラグを使用しました。

図9 文字列難読化および組み込みShell関数の使用を示す繰り返し4に関するファイル間の差分のスクリーンショット

繰り返し5

この繰り返しでは、テスト実行者は、前の繰り返しで導入したwscriptを使用して、"AppPool.vbs"スクリプトを実行する組み込みShell関数の呼び出しを削除します。図10は、テスト実行者が、コードの行29を空の行に置き換えることによってこの行を削除したことを示しています。

図10 Shell関数の呼び出しの削除を示す繰り返し5に関するファイル間の差分のスクリーンショット

繰り返し6

この繰り返しでは、テスト実行者は、前の繰り返しで削除した組み込みShell関数の呼び出しを再導入します。ただし、テスト実行者は、wscriptを使用して"AppPool.vbs"スクリプトを実行する文字列を省くことによってこれを実行するコマンドを含めませんでした。図11は、Shell関数の呼び出しにブランクのコマンドパラメータがあることを示しています。検出率が大幅に上昇しました。これは、検出率がコマンド自体に基づくのではなく、組み込みShell関数の汎用呼び出しに起因することを示唆しています。

図11 Shell関数で空のコマンドを使用していることを示す繰り返し6に関するファイル間の差分のスクリーンショット

繰り返し7

この繰り返しでは、図12で示すように、テスト実行者は、wscriptを使用して"AppPool.vbs"スクリプトを実行し、組み込みShell関数を呼び出すコマンドを再導入します。ただし、今回テスト実行者は、"vbHide"フラグの代わりに"vbNormalFocus"フラグを使用します。その結果、コマンドプロンプトウィンドウが表示された状態でコマンドが実行されます。この変更によって、検出率が8減少します。これは、Shell関数内で"vbHide"フラグを使用することを複数のベンダーが悪意があるとみなしていることを示唆しています。

図12 コマンド実行時にウィンドウを表示することを示す繰り返し7に関するファイル間の差分のスクリーンショット

繰り返し8

このテストの繰り返しは、前の繰り返しからかなり時間が経過してから実行されました。新しいファイルは前のファイルの約5日後に生成されました。このファイル作成の大きな時間差は、テストアクティビティが新しいラウンドに入ったことを示唆しています。ただし、この新しく生成されたファイルのファイル名は"sss – Copy.xls"で、前のファイル名は"sss.xls"でした。これら2つのファイル名を比較すると、テスト実行者は、前の繰り返しで生成されたファイルをコピーし、今回の繰り返しテストの基礎として使用したかもしれないということが示唆されます。ファイル名とこれら2つのドキュメントのマクロに対する変更のため、私たちはこのアクティビティを進行中のテストの取り組みの一環として扱っています。

この繰り返しでは、テスト実行者はマクロの複数の箇所をわずかに変更しました。まず、テスト実行者は、マクロを10秒間スリープするコードの行を削除しました。この行は最初に繰り返し3で導入された行です。図13は、コードのこの行の削除を示しています。この行では、10秒間のスリープに"Application.Wait"関数を使用しています。

図13 スリープ機能の削除を示す繰り返し8に関するファイル間の差分のスクリーンショット 

テスト実行者による次の変更は、Shell関数内のコマンド実行内の文字列"wscript"の難読化です。テスト実行者は、文字列を16進数形式のそれぞれの文字に置き換えて連結する、前の繰り返しで使用した文字列難読化手法と同じ手法を使用しています。図14は、"wscript"を表すために使用されている難読化された文字列"Chr(CLng("&H77")) & Chr(CLng("&H73")) & Chr(CLng("&H63")) & Chr(CLng("&H72")) & Chr(CLng("&H69")) & Chr(CLng("&H70")) & Chr(CLng("&H74")) & Chr(CLng("&H20"))"を示しています。

図14は、現在のExcelワークシートを表すActiveSheetオブジェクトを保存するために使用する変数名をテスト実行者が変更したことも示しています。テスト実行者はこの変数名を"sh"から"Sh"(行41)に変更しました。また、テスト実行者は、このオブジェクトを使用するとき、それぞれの前の行(行43、45および47)も変更しました。

図14 コマンドの文字列難読化の使用および変数名の変更を示す繰り返し8に関するファイル間の差分のスクリーンショット

繰り返し9

テストの最後の繰り返しでは、テスト実行者は、難読化された"wscript"文字列を含む"AppPool.vbs"スクリプトの呼び出しに使用するShell関数の呼び出しに使用するコードの行全体を削除します。図15は、テスト実行者が行全体を削除しただけで、別のコードに置き換えなかったことを示しています。これは、マクロがVBScriptファイルを実行せず、システムに保存しないことを示唆しています。

図15 Shellコマンドの削除を示す繰り返し9に関するファイル間の差分のスクリーンショット