OilRig攻撃者を介して開発およびテストへの取り組みを垣間見ることができる

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

概要

攻撃活動全体を通じて、攻撃者は、完全に入れ替える必要なく、検出されないまま複数の攻撃を遂行できるように、自分たちのツールを継続して開発しています。攻撃のライフサイクルから言えば、ツールの開発は、配信フェーズに先立つ武器化/ステージング フェーズで行われます。配信フェーズでは攻撃者が直接標的に影響を及ぼすため、通常は、配信フェーズが攻撃者の活動を目にする最初の機会となります。Unit 42が2016年5月から追跡している活動であるOilRig攻撃活動に関わる攻撃者から、開発活動を目にする稀な機会がもたらされました。最近、アンチウイルスの検出を回避しようとして、これらの攻撃者が ClaySlide配信文書に変更を加えていることを観察できました。

OilRig攻撃者によって遂行された2回の個別のテストへの取り組みが特定されました。1回は2016年の6月、もう1回は同じく2016年の11月です。これらの各テスト活動に関連付けられたサンプル セットは、かなり小さいですが、各ファイルに加えられた変更から、攻撃者が検出を回避しようとしてどの変更を加えたのかを理解することができます。このテスト活動は、OilRig攻撃活動を担っている脅威グループが、ツールの開発にテスト コンポーネントを組み込んでいる組織化されたプロフェッショナルな運営モデルであることも示唆しています。

テスト活動、分析および手法

私たちは、OilRig攻撃者の攻撃ライフサイクルの開発フェーズで作成されたと見られる2セットのClaySlideサンプルを収集しました。脅威の攻撃者は、これらのファイルをそれぞれ、一般向けのアンチウイルス テストWebサイトにアップロードし、どのベンダーがそのファイルを検出するかを調べました。その後、攻撃者は、検出を回避する方法を見極めるために、ファイルに微妙な変更を加え、新たに作成したファイルを同じ一般向けのアンチウイルス テストWebサイトにアップロードしました。図1のフローチャートは、脅威攻撃者がテスト活動時に従ったプロセスを説明しています。

幸運なことに、脅威攻撃者は配信文書のメタデータを変更していないため、攻撃者が各Word文書を最後に変更したのがいつかを判別することができます。これらの手付かずのタイムスタンプによって、攻撃者によって作成されたとおりにファイルを順序付けするために使用できるタイムラインを作成できます。私たちの分析手法では、各ファイルをタイムライン内の次のファイルと繰り返し比較して、結果として2番目のファイルを作成することになった、最初のファイルに加えられた変更を判別します。

観察された最初のテスト活動は、2016年6月13日に作成された最初のサンプルで始まり、テスト目的で作成された17個のファイルが続きます。攻撃者はこれらを2016年6月15日に2時間で作成しました。表1は、バージョン、最終変更日時、ハッシュ、ファイル名、新たに作成されたファイルのアンチウイルス検出率を含め、2016年6月のテスト活動に関連する観察されたサンプルを示しています。最初の"ttt.xls"ファイルと増分されるファイル名のファイルは、同じおとりコンテンツを含んでいます。そのため、命名方法の違いに関係なく、このサンプルを最初にこのグループに含めています。また、ファイル名"ttt.xls"には"to the top"の略語が含まれています。これはインターネット フォーラムでよく使用されており、テスト活動を開始している攻撃者を示しています。

表1 2016年6月のテスト活動に関連するサンプル

ClaySlide配信文書の2回目のテスト活動は、2016年11月14日の攻撃者による基本サンプルの作成によって開始されました。続いて、翌日の30分間に6個の後続のテストファイルが作成されました。表2は、2016年11月に発生したClaySlideテスト活動に関連する情報を示しています。ここでも、この活動の開始時にはファイル名に明らかな違いがありましたが、最初の2個のサンプルをこのグループに含めたのは、最初の2個のファイルが当初おとりコンテンツを共有していただけでなく、より重要なことに、ファイル名"weak.xls"の初期テスト サンプルと同じマクロ コードとペイロード スクリプトを共有していたためです。

表2 2016年11月のテスト活動に関連するサンプル

これら2回の個別のテスト活動でClaySlide配信文書に加えられた変更を分析することで、テスト中に攻撃者が使用した手法について洞察を得ることができます。2回のテスト セッションで実行された活動を再検討する前に、述べることのできる概括的な見解は次のとおりです。

• ファイル名のパターンが明らかである。テスト ファイルのファイル名には同じ単語または増分する番号が使用されているか、または一連のテスト ファイルはまったく同じファイル名を共有しています。
• 非常に構造化されたアプローチ。ベースラインのテスト サンプルを使用し、その後、少しずつ反復的に変更を加えています。
• 攻撃者はベースライン テスト サンプルに戻りテストを続行することもある。
• 変更は個別に数分で加えられ、以下が含まれる。
  • ペイロードの削除または位置の変更
  • おとりコンテンツおよびシート名の変更
  • 関数名および変数名の変更
  • コード行全体の削除
  • 連結または代替エンコード(base64または16進数)を介した文字列の難読化
  • コード内の関数の順序の並べ替え
• 多くの場合、テスト ファイルは次の理由でもはや機能していない。
  • 必要なコンポーネントの削除
  • 無意味な値での変数の置き換え
  • デコードできないエンコードされた文字列の使用
• テスト活動はかなり低いアンチウイルス検出率で停止した。
• 攻撃者はどの検出シグネチャがトリガーされているか判別しようとしたため、テスト全体を通じてサンプルを検出したベンダー数は増減している。

2016年6月のテスト活動

2016年6月に、OilRig活動に関わる攻撃者は、ClaySlideマクロ コードのどの部分をアンチウイルス ベンダーが検出目的で使用しているかを判別しようとして、一連のテスト活動を開始しました。これらの活動の結果、17個の異なるバージョンのClaySlide配信文書が作成され、その多くはファイル内に変更が加えられたため、もはや適切に動作しません。2016年6月のテスト活動の徹底的な分析を付録Aに掲載しています。

6月のテストでは、攻撃者は、悪意のあるマクロを重点的にテストするために、Excel配信文書から悪意のあるペイロードを削除することから始めました。攻撃者はテストの間、反復的に多数の変更を加えましたが、ペイロードをシステムに保存する役割と、ペイロードを実行するためにスケジュールされたタスクを作成する役割を担っていたコード ブロックを完全に削除することから、これらの変更を開始しました。このコードの削除によって検出率が0となり、アンチウイルス検出ルールがこれらのコード行に基づいてこれらのファイルを検出していたことを攻撃者は理解しました。攻撃者は、それ以降の労力の大半をこのコード部分の変更に費やしました。

その時点で、攻撃者はアンチウイルス検出の原因となっているコード部分を把握したため、検出された正確なコード行を判別しようとして、マクロにコード部分を追加し直し、変更を加えました。このプロセスには、ペイロードとスケジュールされたタスクを作成するために使用されるコマンドの変更が含まれていました。これらの2つのコマンドに加えられた変更には、それらの完全な削除と、キーボード乱打およびbase64や16進数表記を含むさまざまな異なるエンコードの同等の文字列などの機能しない文字列による置換が含まれます。また、攻撃者は、特に、WScript.Shellオブジェクトを直接使用するか、またはオブジェクトを変数に格納することで、これらのコマンドの実行方法も変更しました。さらに、攻撃者は、"poawearshell"や"scshtassks"などのミススペルのコマンドおよび"fireeye.vbs"の代わりに"firaeeye.vbs"などのペイロードのファイル名のバリエーションも意図的に使用しています。

上記のとおりコマンドに変更を加えた後、攻撃者はマクロ内の関数名の変更に焦点を移しましたが、結果として、検出率は変わりませんでした。40分の休憩の後、攻撃者は、以前に作成したテスト ファイルを変更するのではなく、ベース マクロに戻したようです。再度、ペイロードを保存し実行する役割のベース マクロを変更しましたが、今度は、生成したファイルを保存するためにペイロード用に作成するフォルダ名を変更しています。また、攻撃者がベース マクロに戻した後に生じたこれらの活動の間に生成された2つのファイルには、おとりコンテンツ用にキーボードを乱打した文字列が含まれ、以前のテスト ファイルとは大幅に異なっています。テスト活動全体を通じて、アンチウイルス検出率は6という高い割合に達しましたが、最終的に攻撃者がテスト活動を停止した時点では、サンプルを検出していたベンダーはいませんでした。攻撃者はこの結果に満足したようです。ただし、攻撃者が特定のベンダーを回避しようとしていたことを示す確証は得られていません。

2016年11月のテスト活動

2016年11月15日、OilRig活動に関わる攻撃者は、ClaySlide配信文書のテストを開始しました。6月のテスト活動は配信文書からペイロードを削除することから始まりましたが、11月のテストで生成されたファイルはすべてHelminthペイロードを保持し、そのすべてが"updateorg[.]com"のC2ドメインを使用する同じペイロードでした。2016年11月のテスト活動の徹底的な分析を付録Bに掲載しています。

11月のテストでは、攻撃者は最初におとりコンテンツを含むExcelワークシートの変更に重点を置いたようです。ワークシートに加えられた変更は、おとり内のセルへのランダムな文字列の追加と、ワークシート自体の名前の変更です。最終的に、攻撃者はおとりコンテンツを、ルーティング設定を含むおとりから脆弱なパスワードのリストへと、まったく異なるテーマに完全に変更しました。

おとりコンテンツを含むExcelワークシートの変更に加え、攻撃者は、最初にユーザーに表示されるワークシートにも変更を加えました。少し振り返って、最初のOilRigブログの付録で説明したとおり、ClaySlide配信文書は最初に"Incompatible"という名前のワークシートとともに開かれます。このワークシートは、"コンテンツを有効化"して文書の内容を表示するようにユーザーに指示するコンテンツを表示し、実際に、悪意のあるマクロを実行して、システムを侵害します。マクロが実行されると、"Incompatible"ワークシートは非表示となり、おとり文書を含むワークシートが表示されます。攻撃者は、"Incompatible"ワークシートを変更し、ランダムな文字列を含めました。検出ルールが検出目的でこのシートのハッシュを使用しているかどうかを判別しようとしたようです。

"Incompatible"ワークシートにこれらの変更を加える一方で、攻撃者は悪意のあるマクロにも変更を加えています。攻撃者は悪意のあるマクロの関数名を変更することから開始し、"Doom_Init"と"Doom_ShowHideSheets"を"Doon_Init"に、"Doon_SHSheet"を"Ini"と"SHSheet"に変更しました。ある時点で、攻撃者は、マクロ内の関数の順序が検出の原因かどうかを調べるために、それらの順序を変更しました。また、Helminthペイロードを実行するために使用されるVBスクリプトを格納するための変数名も"BackupVbs"から"Backup_Vbs"に変更しました。

これらのテスト活動で加えられたもう1つの変更として、スケジュールされたタスクを作成するために必要なコマンドがいくつかの文字列に分割され、それらは連結されて元に戻されました。この手法は興味深く、最終的なコマンドは引き続き機能します。コマンドがもはや機能しない段階までコマンドが変更された6月のテストで見られた変更とは大きく異なっています。

悪意のあるマクロに加えられた最後の変更は、ペイロードを取得するマクロの位置です。すべてのClaySlide配信文書で、マクロは"Incompatible"ワークシート内の特定のセルからHelminthトロイの木馬に関連するスクリプトを取得します。攻撃者は、スクリプトを含むセルを変更することで、検出ルールがこれらの特定の位置にあるスクリプトを検索しているかどうかを調べています。脅威攻撃者がテスト活動を停止するまでに、攻撃者はClaySlide配信文書の検出率を2まで低下させました。これは満足する結果だったようです。6月のテスト活動と同様に、攻撃者が11月のテストで特定のアンチウイルス ベンダーを回避しようとしたことを示す確証は得られていません。

結論

OilRig攻撃活動に関わる脅威攻撃者によって、攻撃に使用する前の配信文書のテストと変更に関する彼らの戦略の一部が明らかになりました。これらの変更の目的は、セキュリティ製品による検出を回避し、ClaySlide配信文書の使用を広げることです。これらのテスト活動を分析することで、OilRig攻撃者に対する有用な洞察が得られました。特に、この脅威グループは運営の点から見てかなり成熟しており、可能なかぎり配信文書を使用しようとしていることは事実です。

以前のブログで説明したとおり、この脅威グループがClaySlide配信文書に変更を加えていることはすでにわかっていました。今では、脅威攻撃者がファイル名やペイロードの操作などの配信文書の一部に任意で変更を加えているのではなく、最終的にこれらの変更をもたらす組織化されたプロセスがあることもわかりました。この認識は、OilRig脅威グループが、効果を持続させるために微妙に変更を加えながら、長期間にわたり配信文書を使い続けていくことを示唆しています。

付録A

この付録には、2016年6月にOilRig攻撃者によって遂行されたテスト活動の各バージョンの綿密な分析が含まれています。各バージョンで加えられた変更を確認できるように、スクリーンショットとファイル間の相違(提示可能な場合)を示しています。

バージョン1

攻撃者は3バイトを除くすべてをVBSおよびPowerShellスクリプトから削除しましたが、マクロ自体は未変更のままでした。これは、それ以降、配信文書には、システムに感染するために使用される悪意のあるペイロード(Helminthスクリプト)が含まれていないことを示しています。ペイロードを配信文書から削除することで、攻撃者は配信文書自体に基づくアンチウイルス検出の結果を分離できます。また、ペイロードなしのサンプルには、ベース サンプル内のペイロードだった"update-kernal[.]net"のC2サーバなど、セキュリティ リサーチャーが通常サンプルを特定の脅威グループと相関付けるために使用する属性やエンティティも含まれていません。

ペイロードを削除することで、攻撃者は、それ以降のバージョンで、配信文書内のマクロを変更することに集中的に取り組んでいます。

バージョン2

攻撃者は、マクロ内の大半の機能を担っているコードを完全に削除しました。図2に示すとおり、削除されたコードは次の機能を担っています。

1. フォルダの作成
   1. \Libraries\up
   2. \Libraries\dn
   3. \Libraries\tp
2. PowerShellコマンドを実行して、次を作成
   1. PowerShellスクリプト
   2. VBスクリプト
3. コマンドを実行して、VBスクリプトを実行するためのスケジュールされたタスクを作成

バージョン3

攻撃者は、以前のバージョンで削除されたコンテンツを追加しています。ただし、コマンドを実行してVBスクリプトを実行するためのスケジュールされたタスクを作成する役割を担うコード行は省かれました。これは、脅威攻撃者が、ベンダーがマクロ内のこの行に基づいてClaySlideサンプルを検出しているかどうかを確認するためにテストしたことを示しています。

バージョン4

攻撃者は、前回のバージョンのときに除外していたコード行を追加します。このことから、このコードは検出目的で使用されていなかったことが示唆されます。攻撃者はまた、"cmd"変数でPowerShellスクリプトを呼び出すメソッドを変更しました。新たな"WScript.Shell"オブジェクトを作成する代わりに、"wss"変数に格納された"WScript.Shell"スクリプトを使用しています。

バージョン5

攻撃者は、ペイロードをファイルシステムに保存するPowerShellスクリプトを呼び出すためのコマンドが格納された'cmd'変数の内容をbase64でエンコードしました。また、スケジュールされたタスクの作成コマンドについても、base64でエンコードしたものに変更しました。これらの変更はbase64デコード ルーチンを伴わないため、このバージョンで生成されたサンプルはエラーになると考えられます。攻撃者はこれらの変更をサポートするコードを追加することもできたはずですが、デコード ルーチンがないことから、攻撃者はコードを確実に機能させるための手間は省いていることが推察されます。

バージョン6

攻撃者は、前回のバージョンで追加したbase64エンコード文字列が検出されているかどうか確認するために、これらの文字列を削除し、2つのコマンド文字列を空にします。

バージョン7

攻撃者は、'cmd'変数内の"powershell.exe"に対して、またスケジュールされたタスクの作成コマンドに代わるものとして、base64でエンコードした文字列を追加します。

バージョン8

攻撃者は、"powershell.exe"の最初のbase64を、PowerShellコマンドを実行するbase64エンコード文字列に置き換えます。しかし、2番目の"powershell.exe"については、スケジュールされたタスクを作成するクリアテキスト文字列に置き換えます。このbase64でエンコードされたPowerShellコマンドは、これまでのバージョンに見られたものと同様のものです。ただし、攻撃者は、ペイロードを保存するためのファイル名を("fireeye.vbs"から)"firaeeye.vbs"に変更し、("FireeyeVbs"に代わって)"FireeayeVbs"という名前の、コード内にはない変数を参照しています。

バージョン9

攻撃者は、スケジュールされたタスクを作成するクリアテキスト文字列を、この文字列のbase64エンコード バージョンに置き換えます。ただし、このbase64エンコード文字列では、作成するタスクの名前が"GoogleUpdatesTaskMachineUI"から"GoosgleUpdatesTaskMachineUI"に、またスクリプト名が"fireeye.vbs"から"fireeyse.vbs"に変更されています。

バージョン10

攻撃者は、PowerShellを使用したペイロードのインストールとペイロード実行タスクのスケジュールを行うコマンドとして使用するbase64エンコード文字列を変更します。このbase64でエンコードされたPowerShellコマンドでは、バージョン8で変更された"fireeye.vbs"というファイル名と"FireeyeVbs"という変数名が再導入されています。ただし、このbase64エンコード コマンドでは、"powershell"の代わりに"poawearshell"という文字列が使用されています。

スケジュールされたタスクを作成するためのbase64文字列については、バージョン9で変更された"GoogleUpdatesTaskMachineUI"というスケジュールされたタスク名と"fireeye.vbs"というスクリプト ファイル名が再導入されています。ただし、"schtasks"という文字列が検出されているかどうか確認するために、攻撃者は"scshtassks"という文字列を使用しています。

バージョン11

攻撃者は、base64でエンコードした'cmd'変数内の文字列とスケジュールされたタスクを作成するための文字列を変更しました。base64でエンコードしたPowerShellの文字列とcreate taskコマンドの文字列を組み込む代わりに、これらの文字列を次の文字列のbase64エンコード表現に置き換えています。

上の文字列には、この配信文書の分析を提供したFireEyeブログへのリンクが含まれています。以前のサンプルには、次に示す非エンコード文字列がマクロ内のコメントとして含まれていたことに注意してください。

'source code from https://www.fireeye.com/blog/threat-research/2016/05/tareted_attacksaga.html

バージョン12

攻撃者は、base64でエンコードした'cmd'変数内の文字列とスケジュールされたタスクを作成するための文字列を、ランダムに入力した文字に置き換えました。両手でキーボードを乱打することによってこれらの変数に使用する文字列を生成したと考えられます。

バージョン13

攻撃者は、'cmd'内のランダム入力キーと、スケジュールされたタスクを作成するための文字列を、2つ前のバージョンで使用したbase64文字列によって変更しました。ただし、このbase64文字列は左大かっこと右大かっこで囲まれています。

バージョン14

攻撃者は、前回のバージョンでPowerShellコマンドとスケジュールされたタスクの作成コマンドに使用したbase64エンコード文字列を16進数文字列に変更しました。この文字列には、前にバージョン4で見られた、スケジュールされたタスクの作成コマンドを構成する文字の16進数表記が含まれています。今回も、16進数値を正しい文字にデコードするデコード関数はスクリプトに含まれていないため、このスクリプトは機能しません。

バージョン15

攻撃者は、Excelドキュメントが開かれたときに実行される2つの関数名を変更しました。これまでのどのバージョンでも、これらの関数名は"fireeye_Init"と"fireeye_ShowHideSheets"でした。"fireeye_Init"はトロイの木馬をインストールし、"fireeye_ShowHideSheets"はExcelスプレッドシート内でおとりコンテンツを表示します。攻撃者は、これらの関数名がアンチウイルス製品によって検出されているかどうか調べるために、これらの2つの関数名を"fireeye_Init2"と"fireeye_ShowHideSheets3"に変更しました。

バージョン16

このバージョンは非常に興味深いものです。攻撃者は前回のバージョンで作成したドキュメントを変更するのではなく、ベース ドキュメントに戻していると思われるからです。

ファイル名は、増分番号から、ベース ドキュメントと同じファイル名である"ttt.xls"に変更されています。また、前回のバージョンのサンプルと比較したところ、次に示すいくつかの変更が見られました。

ただし、このバージョンで作成されたファイルをベース ファイルと比較すると、変更の数と種類は、これまでのバージョンで加えられた変更の方により近づいているように見えます。私たちが考えているように攻撃者がベース ドキュメントに戻す場合、スクリプト ファイル名、ペイロードによって生成されたファイルを格納するフォルダの名前、およびスクリプトによってPowerShellスクリプトが呼び出される方法に変更が加えられます。攻撃者は、スクリプト ファイル名を"fireeye.vbs"から"fireueye.vbs"に変更し、"up"、"dn"、および"tp"の各フォルダ名をそれぞれ"uup"、"dgn"、および"tup"に変更したうえで、新たな"WScript.Shell"オブジェクトを作成する代わりに、"wss"変数に格納されている"WScript.Shell"スクリプトを使用してコマンドを実行しました。

バージョン17

テスト活動の最後のバージョンでは、攻撃者は1つ前のバージョンで加えた変更の一部を、ベース ドキュメントで使用する値に変更しています。具体的には、ファイル名とフォルダ名です。ただし、攻撃者は、"fireeye.vbs"スクリプトを格納するためにスクリプトでパスとして使用される"%PUBLIC%"環境変数と、ペイロードで使用されるフォルダとを格納するための新たな変数も追加します。このバージョンには、"fireeye.vbs"ファイルに格納されるコマンドの実行を試行する変更済みPowerShellコマンドも含まれますが、スクリプトをそのファイルに書き込むことになるコマンドの部分は含まれていません。また攻撃者は、VBスクリプトを実行するようスケジュールされたタスクを作成するためのコマンドを実行することになる行を削除しています。

付録B

この付録には、2016年11月にOilRig攻撃者によって遂行されたテスト活動の各バージョンの綿密な分析が含まれています。各バージョンで加えられた変更を確認できるように、スクリーンショットとファイル間の相違(提示可能な場合)を示しています。

バージョン1

このテストの最初のバージョンでは、攻撃者はベース サンプルから、おとりコンテンツを変更しています。ざっと見たところ、おとりコンテンツには、Ciscoルーターに静的ルートの設定とその他の設定を行うコマンドが含まれていました。元々、このテスト活動で使用されているベース テスト ファイルでは、図19で示している"Sheet1"という名前のExcelワークシートにこれらの設定が含まれていました。

図20に示したように、テストの最初のバージョンで、攻撃者はおとりコンテンツが含まれるワークシートの名前を"Sheet1"から"hgvc"に変更し、そのワークシートに文字列"jgvchhctf"を追加しました。脅威攻撃者は、ワークシート名またはおとりワークシートのハッシュがアンチウイルス検出の原因となるかどうかを判別しようとしていると思われます。

バージョン2

次に攻撃者は、図21に示したように、おとりコンテンツが含まれるワークシートの名前を"hgcv"から"table"に変更し、おとりコンテンツをCiscoルーティング設定から脆弱なパスワードのリストへと完全に変更しました。ここでは、脅威攻撃者が、次なる攻撃で使用する新しいおとりコンテンツをテストしていると思われます。

バージョン3

前のバージョンにならって、攻撃者はExcelワークシートのコンテンツに変更を加えていますが、このバージョンでは、変更は、おとりワークシートに加えられたのではなく、コンテンツを有効にしてマクロを実行するようユーザーに指示するメッセージが表示される"Incompatible"という名前の最初のワークシートに加えられました。図22に示したように、攻撃者は文字列"yy"をこのワークシートに追加して、アンチウイルス ベンダーがこのワークシートに基づいてClayslide文書を検出するかどうか判別します。

このバージョンで攻撃者はマクロにも変更を加えています。具体的には、関数名を変更し、文字列を分割した後に、連結しています。マクロ内の関数名"Doom_Init"および"Doom_ShowHideSheets"を"Doon_Init"および"Doon_SHSheet"に変更して、これらの関数名が検出の原因となるか判別します。また、攻撃者は、マクロ内のコマンドの"powershell"という語を分割した後に、機能を維持するよう連結しています。

バージョン4

1つ前のバージョンと同様に、脅威攻撃者は、Incompatibleワークシートとマクロ内のコードに変更を加えます。図24に示したように、脅威攻撃者はまず、最初に表示されるIncompatibleワークシート内の2つのセルに文字列"hi"を追加しました。

図25に示したように、このバージョンで攻撃者はマクロにも変更を加えました。攻撃者は、2つの関数名"Doon_Ini"および"Doon_SHSheet"をそれぞれ"Ini"および"SHSheet"に変更しました。また、攻撃者は、スプレッドシートから取得されるVBスクリプトを格納する変数名を"BackupVbs"から"Backup_Vbs"に変更し、この新しい変数名を使用するようPowerShellコマンドも変更しました。最後に、攻撃者はさらに、作成したタスクの名前を分割し、機能を維持するために連結を使用しました。

バージョン5

このバージョンでは、攻撃者はスクリプト内の関数の順序を変更しています。具体的には、"Ini"関数を"SHSheet"関数の前に配置しました。図26は、関数のこの順序変更を示しています。

バージョン6

テストの最後のバージョンで、攻撃者はbase64でエンコードされたVBスクリプトと、base64でエンコードされた2つのPowerShellスクリプトをIncompatibleワークシート内の3つの異なるセルに移動します。また、攻撃者は、これらの新しい場所からbase64でエンコードされた文字列にアクセスするようマクロを変更し、これによって、この文書の機能が維持されます。