Data Talks: Following a Trail of Confusion: PowerShell in Malicious Office Documents by Dr. Josh Stroschein, VDA Labs 2018年10月2日 より
サイバー脅威が発展を続ける中、Microsoft Office文書ファイル（文書）は悪意のある行為者に着実に悪用され続けています。これらの文書を用いた攻撃は、マクロ機能に組み込まれた機能以外には何も使われていないことも多いため、マルウェアとして検知することが難しいため、特に企業ネットワーク内部への足がかりにするために継続的に悪用されています。このようなメリットがある手法を攻撃側が実践しない理由がありましょうか。
マクロは、PowerShellスクリプトの実行からメモリ内でのシェルコードのステージングと実行まで、広範に強力な機能を提供しています。これらはすべて、Office Suiteに実装されたネイティブな機能で実現されています。つまり、大半の悪意のあるドキュメントでは、ゼロデイが使用される訳ではないため、攻撃を阻止するためのパッチが提供される余地がないことを意味します。WebベースのOfficeアプリケーションの時代であっても、Officeドキュメントを互いに電子メールで送信するのは一般的なことです。検出の観点では、この特徴は、通常の、正当な文書の中から悪意のある文書を識別することを困難にしています。被害者にとって魅力的なソーシャルエンジニアリングを併用し、難読化のレベルを変えて検出を効果的に遅らせることで、攻撃側の成功率を高めているのです。
この種の攻撃で私たちが観測した進化の1つは、PowerShellなどのOSの組み込み機能を利用することです。このアプローチは、攻撃者は(マルウェアとして検知される事を回避して)侵入先でとどまり続ける手口を利用するだけでなく、この攻撃のメモリに常駐する性質ゆえに不要な産物をディスクに書き込まないようにすることが可能です。この戦術を高度な難読化手法と組み合わせると、攻撃者が従来の高度な検出ベースの対策を回避できる可能性が高まります。
今回は、このような手法を採用した悪質なOfficeドキュメントについて解説します。この分析では、まず初期段階での評価のための静的分析手法をとり、次に動的解析手法に目を向けることでコード解読をスピードアップします。この記事の終わりまでには、Office文書がこの攻撃手法でどのように使用されるのかを、より理解いただくことができます。
マクロを探す
私たちの分析は文書の中のマクロを調べることから始まります。マクロは被害者のシステム上でコードを実行する唯一の方法ではありませんが、今回分析する、この特定の文書の場合は攻撃の開始のために使用されています。Didier Stevens氏が開発したユーティリティのOLEDUMPは、Office文書からマクロを調べて抽出するには非常に有用なツールです。このツールを使うには、単に対象のOffice文書のファイル名とパスをOLEDUMPに入力します。これで文書の構造に関する情報が提供されます。ここで探すのは、マクロストリームの存在です。これはインデックスの隣に小文字、または大文字の ‘m’で表示されます。
このドキュメントには、ストリーム8とストリーム14の、2つのマクロストリームが存在します。デフォルトでは、ストリームはドキュメント内で圧縮され、展開するために「-v」引数が指定されます。 “ -s”引数で検査したいストリームを指定する事が可能で、これら二つの引数を合わせて標準出力にストリームの内容を出力することも可能です。これでマクロの内容を調べられますが、これをファイルにリダイレクト出力して、テキストエディタを分析に使用するとさらに便利です。
マクロコードの分析
マクロは、その実行を開始するのに”Auto”関数群を使用します。 この特定のドキュメントの場合ではAutoopen関数が定義されており、ドキュメントが開かれてコンテンツが有効になった時点で呼び出されます。
この分析対象文書全体を通してコードの難読化が一貫しており、Autoopen関数も例外ではありません。この関数では、ステートメントwNjqSjの廻りに2つの変数宣言が定義されています。このステートメントは実際には関数呼び出しですが、他のステートメントは単に分析を複雑にするための、ひっかけのコードです。このタイプの難読化を検出する1つの方法は、それらの変数が実際に使用されているかどうかを確認することです。この事例では、ランダムな値が割り当てられていますが、二度と使用されることはありません。この方法はドキュメント全体で使用されるため、分析の早い段階でこの難読化方法を特定することは有益です。
関数wNjqSjをたどると、不要なステートメントを追加する、同じ手法が再度使用されています。これらを除外することで、この関数の3番目のステートメントである、唯一の関数呼び出しに集中することができます。
この関数呼び出しで際立っているのは、キーワードShellです。 このメソッドは、Windows OSのコマンドプロンプトでコマンドを実行するためにマクロで使用されます。 引数は、一連の関数呼び出しと変数を結合したものです。これは、作成者が実行を意図するスクリプトを難読化するための一般的な手法でもあります。これら2つの関数がストリーム8で定義されている唯一の関数なので、これらの関数呼び出しを確認するにはストリーム14を調べる必要があります。
このストリームで定義されている関数も、不要なステートメントを関数に追加するのと同じ手法を使用しています。
不要なステートメントを識別して除去し続けることもできますが、埋め込みスクリプトの文字列難読化に対処し続ける必要があります。 この難読化に効率よく対応するために、動的分析に目を向けていきます。
Bromium Secure Platformによる動的解析への切り替え
この難読化を手作業で辿る代わりに、動的分析をすることで、これらのマクロで作成されたプロセスを把握することができます。これは、マクロコード内に隠された実質的なスクリプトの動作を示し、分析時間のかなりの部分を節約します。 これを行うために、 Bromium Secure Platformを用いてマルウェアをハードウェア的に隔離して、マクロの動作を直接観察してみました。Bromium Secure Platformは、こうしたサンプル(検体)を隔離しての実行を可能にするためマイクロVMアーキテクチャを利用します。しかも実際のエンドポイントシステム上であり、サンドボックス環境ではありません。これにより、Office文書のプロセスの動作を、貴重な脅威インテリジェンスや証跡物など併せて容易に捉えることができます。
最初の段階の結果は下図のコマンドです。これは別の段階の難読化をしています。
すぐにはわかりにくいですが、このコマンドはPowerShellスクリプトを実行するために使用されており、後続するプロセスの動作の中で見られます。
PowerShellを追跡する
PowerShellでは、「 – e」フラグは、コマンドがbase64エンコードであることを環境に通知します。base64デコードユーティリティを使用すると、次の段階が明らかになります。
このスクリプトが何をしているのかを判断する前に、難読化を解除すべき段階がもう1つあります。関数呼び出しとオブジェクトを分析することで、DeflateStreamクラスの新しいオブジェクトが作成されます。 このオブジェクト渡される引数は別のbase64エンコード文字列であることが、FromBase64Stringの呼び出しから判断できます。復号化された文字列は圧縮データなので、これも解凍する必要がありますが、これは多様な方法で実行できます。今回の場合では、Windowsに組み込まれているISEを使ってオブジェクトを出力するようにスクリプトを変更しただけです。
難読化された道は、ようやく終わりました。 このスクリプトは、悪意のあるリモートサーバーから複数のファイルをダウンロードし、そのファイルをユーザーのTEMPフォルダに書き込み、その後で各バイナリーを実行します。攻撃者は、有効なマクロをもつこのOffice文書で、エンドポイントを足がかりにして、攻撃者が意図したファイルをダウンロードさせて実行させることができました。多くの場合、後続する攻撃用プログラムは、C&Cサーバーから定期的に命令を取得するローダーであり、攻撃者は「着地」した環境にあわせて攻撃をカスタマイズできます。この時点で被害者の立場では、潜在的に深刻な問題を既に抱えており、攻撃者に対して既に幾つかのステップ分、後手になっています。Bromiumの隔離は検出に頼らず悪意のあるホストPCへのアクセスを防止するため、今回の事例のように難読化などで検出をすり抜けるようなケースでも、 Bromium Secure Platformが実現する仮想化ベースのセキュリティだけが、絶えず進化する攻撃手法を効果的に対処します。
今回の話題は次の機会に、この攻撃の後続段階である、ダウンロードしたバイナリファイルについて詳しくご説明します。