マルウェア対策スキャン インターフェイス (AMSI) を使用してマルウェアから保護する方法

  • [アーティクル]

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

アプリケーション開発者は、マルウェア防御に積極的に参加できます。 具体的には、動的なスクリプトベースのマルウェアや、従来とは異なるサイバー攻撃から顧客を保護するのに役立てることができます。

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

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

独自のアプリケーションが「その他のアプリケーション」ボックスの 1 つで表される AMSI アーキテクチャの図を次に示します。

the AMSI architecture

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

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

AMSI が機能している

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

XOR エンコード手法を使用して意図を非表示にするスクリプトのサンプルを次に示します (その意図が無害かどうか)。 この図では、このスクリプトがインターネットからダウンロードされたと考えることができます。

sample script encoded in Base64

さらに興味深いものにするには、監視する実際のファイルがなくて済むように、コマンド ラインでこのスクリプトを手動で入力します。 これは、「ファイルレス脅威」と呼ばれるものをミラー化しています。 ディスク上のファイルをスキャンするのとは違い、簡単ではありません。 脅威は、コンピューターのメモリ内にのみ存在するバックドアである可能性があります。

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

Windows Defender detecting the AMSI test sample

AMSI と JavaScript/VBA の統合

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

AMSI integration with JavaScript/VBA

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

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

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

アプリケーション開発者は、悪意のある可能性のあるコンテンツの追加のスキャンと分析のベネフィットを受ける (および顧客を保護する) 場合は、アプリケーションで Windows AMSI インターフェイスを呼び出すようにすることを検討してください。

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

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

Windows AMSI が防御に役立つように設計されたファイルレス脅威の種類について、より多くの背景情報にご興味があるかもしれません。 このセクションでは、マルウェア エコシステムで再生される従来のいたちごっこのゲームを見ていきます。

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

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

an example of a malicious PowerShell script

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

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

an example of a dynamic script

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

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

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

そのため、このシグネチャによってキャッチされた後、マルウェアの作成者は、次の例のように、Base64 でスクリプト コンテンツをエンコードするなど、より複雑なものに移行します。

an example of script content in Base64

機略に優れていることから、ほとんどのマルウェア対策エンジンでは、Base64 デコード エミュレーションも実装されています。 そのため、Base64 デコード エミュレーションも実装しているため、一時的には進んでいるのです。

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

an example of an algorithmic obfuscation script

この時点では、ウイルス対策エンジンがエミュレートまたは検出するものを一般的に超えているので、このスクリプトが実行していることを必ずしも検出するとは限りません。 ただし、難読化とエンコードの手法に対するシグネチャの記述を開始できます。 実際、スクリプトベースのマルウェアのシグネチャの大部分を占めるのは、この点です。

ただ、難読化機能が平凡で、多くの適切に動作するスクリプトのように見える場合はどうでしょうか。 それに対するシグネチャは、許容できない数の誤検知を生成します。 単独では検出できないくらいのサンプル ステージャースクリプトは以下です。

a sample stager script that's too benign to detect on its own

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

the equivalent in Visual Basic script

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

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