マルウェア対策スキャン インターフェイス (AMSI) でマルウェアを防ぐ方法

Windows マルウェア対策スキャン インターフェイス (AMSI) の概要については、「マルウェア対策スキャン インターフェイス (AMSI)」を参照してください。

アプリケーション開発者は、マルウェア対策に積極的に参加できます。 具体的には、スクリプト ベースの動的なマルウェアや従来とは異なるサイバー攻撃からお客様を保護する手助けができます。

たとえば、アプリケーションがスクリプト実行可能であるとします。つまり、アプリケーションが任意のスクリプトを受け入れ、スクリプト エンジンを介してそれを実行します。 スクリプトをスクリプト エンジンに提供する準備ができた時点で、アプリケーションは Windows AMSI API を呼び出してコンテンツのスキャンを要求できます。 そうすることで、スクリプトに悪意があるかどうかを確実に判断してから、続行を決断してスクリプトを実行できます。

これは、スクリプトが実行時に生成される場合でも当てはまります。 スクリプトは (悪意の有無にかかわらず)、難読化を解除するいくつかのパスを通る可能性があります。 ただし、最終的には、難読化解除したプレーン コードをスクリプト エンジンに提供する必要があります。 AMSI API を呼び出すのはこの時点です。

AMSI アーキテクチャの図を次に示します。このアーキテクチャでは、自身のアプリケーションは "その他のアプリケーション" ボックスの 1 つで表されます。

AMSI アーキテクチャ

Windows AMSI インターフェイスはオープンです。 つまり、どのアプリケーションでも呼び出すことができます。送信されたコンテンツは、登録されている任意のマルウェア対策エンジンで処理できます。

また、この説明をスクリプト エンジンに限定する必要もありません。 たとえば、該当のアプリケーションが通信アプリであれば、インスタント メッセージのウイルスをスキャンしてからお客様に表示します。 あるいは、該当のソフトウェアがゲームであれば、プラグインをゲームにインストールする前に検証します。 AMSI を使用する多くの機会とシナリオがあります。

AMSI の動作

AMSI の動作を見てみましょう。 この例では、Windows Defender が AMSI API を呼び出しているアプリケーションです。 ただし、同じ API をユーザー独自のアプリケーション内から呼び出すことができます。

次に示すスクリプトのサンプルは、XOR エンコード手法を使用して意図を隠しています (意図が無害かどうかは関係ありません)。 この例では、このスクリプトがインターネットからダウンロードされたと見なすことができます。

Base64 でエンコードされたサンプル スクリプト

より興味深くするため、このスクリプトをコマンド ラインに手動で入力します。したがって、監視する実際のファイルはありません。 これは、"ファイルレス脅威" と呼ばれるものを反映しています。 ディスク上のファイルをスキャンするほど簡単ではありません。 この脅威は、マシンのメモリ内にのみ存在するバックドアである可能性があります。

次に、Windows PowerShell でスクリプトを実行した結果を示します。 Windows Defender が、標準の AMSI テスト サンプル シグネチャを使用するだけで、この複雑なシナリオで AMSI テスト サンプルを検出できることがわかります。

AMSI テスト サンプルを検出する Windows Defender

AMSI と JavaScript/VBA との統合

次のワークフロー図では、もう 1 つの例のエンド ツー エンド フローについて説明します。ここでは、AMSI と Microsoft Office 内でのマクロ実行との統合を示しています。

AMSI と JavaScript/VBA との統合

  • ユーザーが、(悪意のある) マクロを含むドキュメントを受け取ります。このマクロは、難読化やパスワードで保護されたファイルなどの手法を使用して、静的なウイルス対策ソフトウェア スキャンを回避します。
  • その後、ユーザーが (悪意のある) マクロを含むドキュメントを開きます。 ドキュメントが保護ビューで開かれても、ユーザーは [編集を有効にする] をクリックして保護ビューを終了します。
  • ユーザーが [マクロの有効化] をクリックして、マクロの実行を許可します。
  • マクロが実行される際に、VBA ランタイムは循環バッファーを使用して、Win32、COM、VBA API の呼び出しに関連するデータとパラメーターをログに記録します [1]。
  • 高リスクと見なされる特定の Win32 または COM API ("トリガー" とも呼ばれる) が観察されると [2]、マクロの実行が停止され、循環バッファーの内容が AMSI に渡されます。
  • 登録された AMSI マルウェア対策サービス プロバイダーは、マクロの動作に悪意があるかどうかを示す判定で応答します。
  • 動作に悪意がない場合、マクロの実行が続行されます。
  • それ以外の場合、つまり動作に悪意がある場合、Microsoft Office はアラートに応答してセッションを閉じ [3]、AV がファイルを検疫できます。

これは何を意味するのでしょうか。

Windows ユーザーにとっては、Windows 10 の組み込みスクリプト ホスト上で難読化と回避の手法を使用する悪意のあるソフトウェアが、これまでよりもはるかに深いレベルで自動的に検出され、保護のレベルが向上します。

アプリケーション開発者であれば、潜在的に悪意のあるコンテンツを特別にスキャンして分析することでメリットを得る (同時にお客様を保護する) には、アプリケーションで Windows AMSI インターフェイスを呼び出すことを検討してください。

ウイルス対策ソフトウェア ベンダーであれば、AMSI インターフェイスのサポートの実装を検討できます。 そうした場合、アプリケーション (Windows 10 の組み込みスクリプト ホストを含む) で潜在的に悪意があると見なされるデータに関して、さらに詳しい分析情報がエンジンに与えられます。

ファイルレス脅威に関するその他の背景情報

Windows AMSI が防御に役立つファイルレス脅威の種類に関して、さらに多くの背景情報が必要ではないでしょうか。 このセクションでは、マルウェア エコシステムでプレイされる従来のネコとネズミのゲームについて説明します。

例として PowerShell を使用します。 ただし、説明するのと同じ手法とプロセスを、VBScript、Perl、Python、Ruby など、任意の動的言語で利用できます。

悪意のある PowerShell スクリプトの例を次に示します。

悪意のある PowerShell スクリプトの例

このスクリプトは画面にメッセージを書き込むだけのものですが、マルウェアは通常はさらに悪質です。 ただし、これを検出するためのシグネチャを簡単に記述できます。 たとえば、シグネチャによって、ユーザーが開くすべてのファイルで文字列 "Write-Host 'pwnd!'" を検索することができます。 素晴らしいです。最初のマルウェアが検出されました。

しかし、最初のシグネチャによって検出されると、マルウェアの作成者は対応します。 この例のような動的スクリプトを作成することで対応します。

動的スクリプトの例

このシナリオでは、マルウェア作成者は、実行する PowerShell スクリプトを表す文字列を作成します。 ただし、以前のシグネチャを遮断するために、単純な文字列連結手法を使用します。 広告が多い Web ページのソースを表示してみると、広告ブロック ソフトウェアを回避するためにこの手法の多くのインスタンスが使用されていることがわかります。

最後に、マルウェア作成者は、この連結文字列を Invoke-Expression コマンドレット (PowerShell のメカニズム) に渡して、実行時に構成すなわち作成されるスクリプトを評価します。

これに対して、マルウェア対策ソフトウェアは基本的な言語エミュレーションを開始します。 たとえば、2 つの文字列の連結が確認された場合は、それらの 2 つの文字列の連結をエミュレートし、その結果に対してシグネチャを実行します。 残念ながら、これは非常に脆弱なアプローチです。言語の性質として文字列を表したり連結したりする多くの方法があるためです。

このシグネチャによって捕捉された後、マルウェア作成者はさらに複雑な方法に移行します。たとえば、次の例のように、Base64 でスクリプト コンテンツをエンコードします。

Base64 のスクリプト コンテンツの例

ほとんどのマルウェア対策エンジンは、リソースが豊富であり、Base64 デコード エミュレーションも実装しています。 Base64 デコード エミュレーションが実装されているため一時的には有利です。

これに対して、マルウェア作成者はアルゴリズムの難読化に移行します。たとえば、実行するスクリプト内の単純な XOR エンコード メカニズムです。

アルゴリズム難読化スクリプトの例

通常、この時点では、ウイルス対策エンジンによって何かをエミュレートしたり検出したりする段階を過ぎており、このスクリプトで何が実行されるかを検出する必要は必ずしもありません。 ただし、難読化とエンコードの手法に対するシグネチャの記述を開始することはできます。 実際、シグネチャの大半がスクリプト ベースのマルウェアに対応している理由はこれです。

しかし、オブファスケーターが非常に単純で、適切に動作する多くのスクリプトのように見える場合はどうでしょうか。 それに対してシグネチャを使用すると、許容できない数の誤検知が生成されます。 無害すぎて自動的に検出できないサンプルの "ステージャ" スクリプトを次に示します。

無害すぎて自動的に検出できないサンプルの ステージャ スクリプト

この例では、Web ページをダウンロードし、そこからいくつかのコンテンツを呼び出しています。 同等の Visual Basic スクリプトを次に示します。

同等の Visual Basic スクリプト

これらの両方の例で状況を悪化させるのは、ウイルス対策エンジンが、ユーザーによって開かれるファイルを検査することです。 悪意のあるコンテンツがメモリ内にしか存在しない場合、攻撃は検出されない可能性があります。

このセクションでは、従来のシグネチャを使用した検出の限界について説明しました。 しかし、悪意のあるスクリプトは難読化を解除するいくつかのパスを通る可能性があり、最終的に、難読化解除されたプレーン コードをスクリプト エンジンに提供する必要があります。 そして、その時点で (前述の最初のセクションで説明したように)、Windows 10 の組み込みスクリプト ホストが AMSI API を呼び出して、この保護されていないコンテンツのスキャンを要求します。 また、アプリケーションでも同じように行うことができます。