テクニカル ウォークスルー: 最近のSofacy攻撃で使われているOffice Test持続手法

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

概要

以前のブログでお伝えしたように、私たちはユーザーがMicrosoft Officeアプリケーションを開くたびにSofacyグループが新しい持続型メカニズム("Office Test"と私たちは呼んでいます)を使ってトロイの木馬をロードしているのを確認しました。レポート後に、この持続手法についてどのような動作が行われ、影響を受けるMicrosoft Officeはどのバージョンなのか具体的に知りたいというお問い合わせがいくつかありました。今回のブログはこの持続手法に関する技術面での分析として、セキュリティの専門家やネットワーク防衛担当者の皆様が危険を見抜くのにお役に立てるでしょう。それは別の脅威グループがこの技法を利用し始める恐れがあると考えられるからです。

私たちはOfficeDllSideloadingという名称の悪意のある動作タグをAutoFocusに追加してPalo Alto Networksのお客様がこの持続手法の使用を追跡できるようにしました。

Office Testのこれまでの経緯

最近の標的型攻撃でSofacyに利用された配信文書を分析しているなかで、私たちは文書が次のレジストリ キーを作成していることに気付きました。

HKEY_CURRENT_USER\Software\Microsoft\Office test\Special\Perf

私たちが分析したところでは、このレジストリ キーに対してDLLのパスが追加されると、Microsoft Officeアプリケーションが開かれるたびにそのDLLがロードされます。このレジストリ キーが持続性のために使われるのをそれまで見たことがなかったため、私たちはこのレジストリ キーがどのようにして悪意のあるペイロードの実行を結果としてもたらすのか調査しました。クリーンなシステムにMicrosoft Officeがインストールされていることを確認し、図1に示すとおりこのレジストリ キーが存在しないことを確かめました。

図1 Microsoft OfficeのインストールでデフォルトではWindowsレジストリに"Office Test"キーが存在しない
図1 Microsoft OfficeのインストールでデフォルトではWindowsレジストリに"Office Test"キーが存在しない

私たちがWildFireデータを確認したところ、ほんの一握りのサンプルしかこのレジストリ キーを持続性のために使っていないことが分かりました。それらのサンプルはいずれもSofacyのCarberp亜種をロードするのに使われました。当時私たちはSofacyグループが持続性の技法を新たに見つけたものと思っていましたが、驚いたことにHexacornが2014年4月のブログ記事でこのレジストリ キーのことを明らかにしていました。このことからSofacyグループがこの持続性の技法を独自に発見したのではなく、脅威の攻撃者がよく行うように既存の技法を自分たちの極秘資料帳に取り入れた可能性のあることが伺えます。

DLLをロードする過程

このレジストリ キーがどのようにして悪意のあるDLLを実行するのか見極めるため、私たちはユーザーがMicrosoft Wordアプリケーションを開いたときに発生する活動を分析しました。Wordを分析することにした理由は、Sofacy攻撃に関する研究からWordがトロイの木馬の悪意のあるDLLをロードすることが分かっていたからです。しかし、別のMicrosoft Officeアプリケーションもこの持続手法の影響を受けやすいことが分かっていますので、そちらについては次のセクションで詳しく説明します。

下の図2はスタートアップ過程の間に発生した、このレジストリ キーに関連のあるAPI関数呼び出しを示しています。これらのAPI呼び出しからWord (WINWORD.EXE)が"wwlib.dll"をロードしている様子を示していることが分かります。ここで、"wwlib.dll"はWordが実行時にロードする正規のライブラリです。この"wwlib.dll"ライブラリは問題のレジストリ キーを開き、そのデフォルト値を問い合わせ(図2のNULL)、その次にLoadLibraryWを使って、このキーに保存されている悪意のあるDLL("btecache.dll")をロードします。

図2 悪意のあるDLLをロードするWord が呼び出したAPI関数
図2 悪意のあるDLLをロードするWord が呼び出したAPI関数

図2の“wwlib.dll”によって見られる最後のアクティビティには、次のように、HKEY_LOCAL_MACHINEハイブ内の同じレジストリ キーへのハンドルを開こうとする試みが含まれています。

HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf

このキーは、Microsoft Officeのデフォルトのインストールでは存在しないため、キーを開こうとする試みは失敗します。さらに、持続性を目的とする場合、このレジストリ キーの使用は適していません。攻撃者がHKLMハイブ内でレジストリ キーを変更するために高い権限が必要となるからです。代わりに、攻撃者はHKCUハイブ内に“Office Test”レジストリ キーを作成しました。このキーであれば、現在のアカウント権限のみで、悪意のあるDLLへのパスでキーを変更できます。

Sofacy攻撃では、攻撃者は“btecache.dll”という名前のローダー型トロイの木馬(図2)を“Office Test”レジストリ キーに追加しました。ローダー型トロイの木馬は、図3に示すように、“C:\ProgramData\svchost.dll”から2番目のDLLを見つけてWordにロードし、終了します。“svchost.dll”には、Sofacyトロイの木馬のCarberp亜種の関数コードが含まれ、それらはユーザーがアプリケーションを閉じるまでWord内で実行し続けます。

図3 Microsoft Word内で実行されているペイロード“svchost.dll”
図3 Microsoft Word内で実行されているペイロード“svchost.dll”

Office Testキーの目的

起動プロセスのアクティビティに基づいて、レジストリ キーから悪意のあるDLLをロードしている正規の“wwlib.dll”を見つけました。私たちは、Microsoft Officeのインストール時にレジストリに追加されなかったキーから“wwlib.dll”がDLLをロードした理由を探りました。“wwlib.dll”の静的な分析から、図4に示すように、DLLがレジストリ キーからライブラリをロードし、その後、ロードしたライブラリから“_GetPerfhostHookVersion@0”という名前のAPI関数の解決と呼び出しを試行していることが明らかになりました。

図4 レジストリからDLLをロードし、_GetPerfhostHookVersion@0の解決と呼び出しを試行するwwlib.dll内のコード
図4 レジストリからDLLをロードし、_GetPerfhostHookVersion@0の解決と呼び出しを試行するwwlib.dll内のコード

“wwlib.dll”は、LoadLibraryW関数を使用してレジストリ キーからDLLをロードするときに、エクスポートされた関数のDllEntryPointをDLL内で実行します。Sofacyの“btecache.dll”の場合、DllEntryPoint関数が“svchost.dll”と呼ばれる2番目のDLLを見つけ、その関数コードをロードして実行します。“btecache.dll”には、“_GetPerfhostHookVersion@0”という名前のエクスポートされた関数は含まれていませんが、これは重要ではありません。図4のコードがAPI関数の解決に失敗するが、APIを呼び出すことなく実行し続けるのと同様だからです。

“_GetPerfhostHookVersion@0”以外にも、“wwlib.dll”ライブラリは、レジストリからロードされたDLLから、特に名前に次を含む、いくつかの追加のエクスポートされた関数の解決を試みます。

_InitPerf
_PerfCodeMarker
_UnInitPerf

Word (および他のMicrosoft Officeアプリケーション)は、アプリケーションの開発またはテスト段階で、パフォーマンス評価やその他のデバッグ タスクを実行するために、このレジストリ キーを使用してDLLをロードしているようです。このことから、“Software\Microsoft\Office test\Special\Perf”レジストリ キーがMicrosoft Officeのインストール時に作成されない理由がわかりました。

また、ライブラリがHKEY_LOCAL_MACHINEハイブ内の次のレジストリ キーからDLLのロードを試行することも発見しました。キー名“RuntimePerfMeasurement”は、“wwlib.dll”がパフォーマンス テストやデバッグを目的に、これらのレジストリ キーを使用していることをさらに示唆しています。

HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf\RuntimePerfMeasurement

脆弱なアプリケーションとバージョン

この持続型メカニズムに対して脆弱なWordバージョンを確認するために、以下のWordバージョンの“wwlib.dll”をチェックしました。2003、2007、2010、2013、2015および2016。Office 2007、2010、2013、2015および2016の“wwlib.dll”が、このブログで取り上げている“Office Test”レジストリキーからDLLをロードすることを確認できました。Office 2003はこのレジストリキーからDLLをロードせず、“wwlib.dll”ファイルを持っていませんでした。

他のMicrosoft Officeアプリケーションもテストし、どのアプリケーションが“Office Test”レジストリキーからDLLをロードするのかを確認しました。テストしたアプリケーションは、Word、Powerpoint、Excel、Outlook、OneNote、Publisherなどです。興味深いことに、Officeスイートの一部のアプリケーションでは、(Wordがwwlib.dllを使用するように)レジストリ持続型メカニズムを使用して別のDLLを呼び出して悪意のあるペイロードをロードする必要はありません。代わりに、アプリケーションから直接悪意のあるペイロードをロードします。図5は、実行可能ファイルから直接ペイロードをロードするアプリケーションと別個のDLLファイルを使用するアプリケーションをグラフィック表示しています。

図5 Office Testのワークフロー
図5 Office Testのワークフロー

簡単な防御方法

調査中、レジストリキー“HKEY_LOCAL_MACHINE\Software\Microsoft\Office test”を手動で作成し、このキーに対する現在のユーザーのアカウントの書き込み権限を削除することによって、“Office Test”持続型テクニックを簡単に打ち破ることができることがわかりました。Microsoft Officeは操作にこのレジストリキーを必要とせず、インストール時にこのレジストリキーを作成すらしないため、このキーを読み取り専用で追加してもMicrosoft Officeアプリケーションの操作に影響しません。“Office Test”持続型メカニズムを打ち破る手順を以下に説明します。また、この手順は、グループポリシーを使用して簡単にスクリプト化したり、システムにプッシュしたりできます。

免責条項: レジストリを変更すると、重大な問題が発生し、オペレーティングシステムを再インストールする必要が生じる場合があります。弊社は、レジストリを間違った方法で使用して生じた問題が解決できることを保証しません。ここで提供する情報は自分の責任で使用してください。

まず、“reg”コマンドで“HKCU\Software\Microsoft\Office test”を作成します。コマンドプロンプトを開き(cmd.exe)、以下を入力します。

reg add “HKCU\Software\Microsoft\Office test”

図6 “reg”コマンドを使用して“Office test”レジストリキーを作成
図6 “reg”コマンドを使用して“Office test”レジストリキーを作成

“regedit”アプリケーションを使用して、新しく作成したレジストリキーに移動します。このキーを右クリックすると、図7に示すように、このキーに関連付けられた権限にアクセスできます。

図7 キーを右クリックして権限にアクセス
図7 キーを右クリックして権限にアクセス

現在のユーザーは、図8に示すように、このレジストリキーに対する“Full Control”(フルコントロール)権限を持っています。この権限があると、攻撃者は“Special\Perf”サブキーにトロイの木馬へのパスを書き込むことができます。図8の“Read”(読み取り)コントロールがあると、Microsoft Officeはこのキーおよびそのサブキーの内容を読み取ることができます。これが、攻撃者がこのテクニックを利用して悪意のあるDLLをOfficeアプリケーションにロードする方法です。この持続型メカニズムを打ち破るために、“Advanced”(詳細設定)ボタンをクリックしてこのキーへの現在のユーザーの書き込み権限を削除できます。

図8 “Office test”レジストリキーに対する現在のユーザーのデフォルトの権限
図8 “Office test”レジストリキーに対する現在のユーザーのデフォルトの権限

現在のユーザーには、このレジストリ キーに対する[フル コントロール]アクセス許可が付与されています。これは、その親オブジェクトからアクセス許可を継承しており、結局はHKEY_CURRENT_USERハイブからそのアクセス許可を継承しているためです。このレジストリ キーに対するユーザーの書き込みアクセス許可を削除するには、まず、図9に示すボックスをオフにして、継承されたアクセス許可を削除する必要があります。

図9 このボックスをオフにすることによって、継承されたアクセス許可を削除
図9 このボックスをオフにすることによって、継承されたアクセス許可を削除

図9のボックスをオフにすると、図10のダイアログ ボックスが表示されます。このダイアログ ボックスには、このキーからすべてのアクセス許可を削除するための[削除]オプションと、ユーザーに対して特別なアクセス許可を追加するための[追加]オプションが用意されています。

図10 レジストリ キーの継承されたアクセス許可を削除した後に表示されるダイアログ ボックス
図10 レジストリ キーの継承されたアクセス許可を削除した後に表示されるダイアログ ボックス

ここで、[追加]をクリックして現在のユーザーを選択してから、[編集]ボタンをクリックして、このユーザーに対して特別なアクセス許可を設定します。次のダイアログでは、図11に示すように、まず[すべてクリア]ボタンをクリックして、既存のすべてのアクセス許可を削除してから、[読み取り制御]のみをオンにします。

図11 このキーに読み取り専用アクセス許可を割り当てる
図11 このキーに読み取り専用アクセス許可を割り当てる

[読み取り制御]アクセス許可を設定すると、Microsoft Office製品は引き続きこのレジストリ キーから読み取りを行うことはできますが、悪意のある文書がこのキーに書き込みを行うことはできなくなります。私たちは、以前のブログで取り上げた、Sofacyが用いた配信文書に対して、この簡単なレジストリ変更をテストしました。その結果、ユーザーがMicrosoft Officeアプリケーションを開いたときに、配信文書は以前と同様に当社の分析システムを悪用できましたが、ペイロードを実行することはできず、感染は害のないものとなりました。

AutorunsによるOffice Testの検出

Unit 42はMicrosoftと連絡を取り、Office Testの持続性メカニズムと、脅威グループが標的型攻撃の際にそのメカニズムを利用していることを知らせました。これを受けてMicrosoftは、2016年7月4日に新しいバージョンのAutorunsをリリースしました。具体的には、Office Testレジストリ キーのチェック機能を備えたv13.52です。私たちは、Autoruns v13.52をダウンロードして、この持続性手法を用いるSofacyツールによって侵害を受けたシステムで、GUIバージョン(Autoruns.exe)とCLIバージョン(autorunsc.exe)の両方をテストしました。以下の図12および図13は、これら2つのAutorunsツールが、持続性を確立するためにこのレジストリ キーが使用されていることを検出したことを示しています。

図12 GUIバージョンのAutorunsによるOffice Testの持続性メカニズムの検出
図12 GUIバージョンのAutorunsによるOffice Testの持続性メカニズムの検出
図13 AutorunによるOffice Test持続性メカニズムの検出
図13 AutorunによるOffice Test持続性メカニズムの検出

結論

"Office Test"の持続性メカニズムは、ユーザーがOfficeアプリケーションを開くたびに、攻撃者がトロイの木馬を実行できるようにします。この持続性メカニズムは、Microsoft Officeアプリケーションの開発およびテスト時に使われたと思われるレジストリ キーを利用して、悪意のあるDLLをロードします。持続性のためにこの特定の戦術を使用するのは非常に巧妙な手口で、悪意のあるペイロードをロードして実行するためにユーザーの介在が必要なため、サンドボックスでの自動分析が困難になります。認知度が低いことに加え、ユーザーの介在によってサンドボックス回避を実現するという方法を組み合わせることで、この持続性手法は、今後の攻撃で用いられるであろう、潜在的に魅力的な持続手法になっています。Unit 42では、何らの脅威が持続性獲得の目的ですでにこのキーを使用している可能性があるため、このレジストリキーが作成されたシステムがないかどうか監視することを推奨します。MicrosoftがAutorunsツールに"Office Test"レジストリ キーを追加したのは、検出のためでもあります。さらに、このブログで説明したように、"Office test"レジストリ キーを読み取り専用モードで作成することによって、この持続性を無効化することも推奨します。