A PART OF ANTI-VIRUS 2【1 章 AMSI (Windows Antimalware Scan Interface) について】

もくじ

• AMSI の概要

  • AMSI を利用するアプリケーション

• AMSI による端末の保護

  • スクリプトベースの脅威について
  • AMSI による保護の強化
  • AMSI のその他の利点
  • 悪意ある攻撃者との戦い

• アプリケーションが AMSI スキャンを利用する方法

  • システムに登録されているプロバイダーを確認する

• AMSI によりスクリプトの実行をブロックする

  • 事前準備
  • AMSI で PowerShell スクリプトの実行をブロックする
  • AMSI で VBScript スクリプトの実行をブロックする
• 1 章のまとめ
• 本書のもくじ

AMSI の概要

Windows 10 から導入された AMSI (Windows Antimalware Scan Interface) とは、 一言で表現すると「アプリケーションやサービスをマシン内で稼働するアンチマルウェア製品と統合するための汎用的な標準インターフェース」です。

以下は、簡略化された AMSI のイメージ図です。

AMSI は、このイメージ図のように各アプリケーション側から AMSI を通して システム内で稼働するアンチマルウェア製品にスキャン対象のデータを連携し、そのスキャン結果を受け取ります。

上図のように、アプリケーションは AMSI を使用して自身が処理するデータが悪意のあるものか否かを判断するためにシステムに登録されているアンチマルウェア製品を利用することができます。

また、AMSI はアンチマルウェア製品ベンダーには依存しない標準的なインターフェースを提供しており、 さまざまな製品ベンダーがデータをスキャンするための AMSI プロバイダーをシステムに登録することができます。¹

システムに登録可能な AMSI プロバイダーは、Windows 標準の Microsoft Defender ウイルス対策をはじめとして、 多くのアンチマルウェア製品ベンダーにより提供されています。

AMSI プロバイダーを提供している製品ベンダーの一覧については、whoamsi リポジトリから確認することができますが、残念ながら直近数年間は情報が更新されていないため最新情報の網羅性には留意が必要です。²

AMSI を利用するアプリケーション

AMSI は、Windows において例えば以下のようなコンポーネントに統合されています。

• User Account Control - UAC (EXE、COM、MSI の権限昇格や ActiveX インストール)
• PowerShell (スクリプト、対話インターフェース、または動的なコードの評価)
• Windows Script Host (wscript.exe や cscript.exe)
• JavaScript and VBScript
• Office VBA macros

また、上記以外にも例えば SharePoint Server や Exchange Server などのサービスで AMSI による保護を利用することができます。^{3 4}

各サービスとアプリケーションは、いずれも AMSI を利用して不正なコードの実行や 悪意のある Web リクエストなどをブロックすることでユーザーを保護しています。

AMSI による端末の保護

スクリプトベースの脅威について

従来のアンチマルウェア製品は、マルウェアの実行ファイルがディスク上に作成されることを前提としていました。

しかし、AMSI がリリースされた 2015 年までには、PowerShell などのシステムに導入されているツールを使用したスクリプトベースの攻撃が急速に広まっていました。⁵

このようなスクリプトベースの攻撃は OS 標準のツールを使用します。⁶

さらに、これらの攻撃は多くの場合メモリ内で悪意のあるコードの作成や実行が行われ、ディスク上にファイルを作成しません。⁷

また、もしマルウェアがファイルを介して配布される場合でも、 スクリプトベースのマルウェアの場合は高度な暗号化または難読化手法を用いることで、 従来のシグネチャマッチングによる検知を非常に困難にすることが容易でした。⁸

そのため、上記のような攻撃手法はアンチマルウェア製品の検知を回避して攻撃を成功させる目的で多くの悪意のある攻撃者に用いられることとなり、非常に大きな脅威となっていました。

AMSI による保護の強化

しかし、AMSI のリリースはこのような脅威に対する保護を大幅に強化しました。⁹

例えば、PowerShell を利用したファイルレスマルウェア攻撃が行われる場合でも、 メモリ内に配置されている悪意のある実行コードを AMSI を通してスキャンすることにより、 攻撃を未然に防ぎシステムを保護することができます。

また、仮にスクリプトに難読化の手法が用いられている場合でも、 難読化解除プロセスを経て最終的にスクリプトエンジンに与えられるプレーンな実行コードを AMSI によりスキャンすることができるため、攻撃者が検知を回避することは非常に困難になりました。

AMSI のその他の利点

また、AMSI により強化された保護により対処が可能となるのは、 前項で紹介したスクリプトベースの脅威に留まりません。

AMSI によるスキャン要求は PowerShell などのスクリプトエンジン以外にも、さまざまな種類のアプリケーションに組み込むことができます。

そのため、外部から受け取った Web リクエストや、ユーザーが入力フォームから投稿したテキストなど、 さまざまなコンテンツを AMSI を通してスキャンし、悪意のある要求やテキストの送信などをブロックすることも可能です。

悪意ある攻撃者との戦い

ここまでに紹介してきた通り、AMSI はそのリリース以降さまざまなアプリケーションに統合され、多くの脅威からユーザーとシステムを保護してきました。

しかし、他のあらゆるセキュリティ製品の例に漏れず、AMSI もより巧妙に検知を回避しようとする攻撃者とのいたちごっこを続けています。

例えば、2018 年には AMSI が Office VBA に新たに統合され、 当時から増加していた VBA マクロを使用してアンチマルウェア製品の検知を回避する マルウェアを効果的に検知/ブロックできるようになりました。¹⁰

しかし、AMSI による Office VBA マクロを悪用するマルウェアに対する検知能力は向上したものの、 Office VBA に統合された AMSI を回避するために、1993 年の VBA 導入以前にリリースされた Excel 4.0(XLM) マクロを悪用する手法が増加しました。¹¹

このようなトレンドに対処するため、Microsoft は 2021 年に Excel 4.0(XLM) マクロにも AMSI を統合しました。

※ なお、本書執筆時点では、Excel 4.0(XLM) マクロはユーザーの保護を目的に既定で無効化されています。¹²

以上のように、AMSI は悪意のある攻撃者により次々と生み出される新しい攻撃手法に対抗するために、 さまざまなアプリケーションへの統合を行うことでユーザーとシステムを保護してきました。

もちろん、悪意のある攻撃者が使用する手法は日々進化を続けているため、AMSI による保護は絶対ではありません。

しかし、少なくとも AMSI はスクリプトエンジンや Office マクロを悪用する脅威に対抗するための優れたソリューションの 1 つである点は間違いありません。

そのため、AMSI のような重要なセキュリティ機能をリスクに対する検討が不十分なまま無効化するようなことがないよう、 ユーザーやシステムの管理者はこれらの機能がどのような脅威からシステムを保護しているのかについて、十分に把握しておくことが重要であると考えます。

アプリケーションが AMSI スキャンを利用する方法

では、このような利点を持つ AMSI スキャンを各アプリケーションがどのように使用するのかを見ていきます。

任意のアプリケーションは、以下の図のように AMSI を利用するためのインターフェースとして用意されている API を使用して、 システムに登録されている AMSI プロバイダーにスキャンを要求することができます。

スキャン要求を受け取った AMSI プロバイダーは通常、必要に応じてシステムにインストールされているアンチマルウェアスキャンエンジンを利用し、 そのスキャン要求が行われたコンテンツが悪意のあるものであるか否かを確認し、その結果を返します。

なお、既定では MpOav.dll が AMSI プロバイダーとして登録されており、システム内で稼働する Microsoft Defender ウイルス対策が AMSI API を使用して要求されたデータのスキャンを行います。¹³

システムに登録されている AMSI プロバイダーは、要求されたスキャンに対するスキャン結果に応じて、 通常は以下のいずれかの種類の結果を返します。¹⁴

• AMSI_RESULT_CLEAN
• AMSI_RESULT_NOT_DETECTED
• AMSI_RESULT_BLOCKED_BY_ADMIN_START
• AMSI_RESULT_BLOCKED_BY_ADMIN_END
• AMSI_RESULT_DETECTED

詳細については 2 章以降に記載しますが、例えばアプリケーションが行ったスキャン要求に対して AMSI_RESULT_NOT_DETECTED の結果が返された場合、 スキャン要求を行ったアプリケーション側でスクリプトの実行ブロックなどの操作を行い、端末を保護することができます。

システムに登録されているプロバイダーを確認する

続けて、システムに登録されている AMSI プロバイダーの情報を確認します。

まず、システムに登録されている AMSI プロバイダーの一覧はレジストリキー HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers から確認できます。

既定では、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers 直下に AMSI プロバイダーの ID である {2781761E-28E0-4109-99FE-B9D127C57AFE} が登録されていることを確認できます。

また、この ID は COM サーバーとして登録されている AMSI プロバイダーの CLSID に一致します。

そのため、レジストリキー HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID} から一致する CLSID のレジストリキーを確認すると、 以下のスクリーンショットのように HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{2781761E-28E0-4109-99FE-B9D127C57AFE} のレジストリキーが登録されていることを確認でき、ここから Microsoft Defender のコンポーネントに関する情報を参照できることがわかります。

なお、上記の例ではシステムに既定でインストールされている Microsoft Defender IOfficeAntivirus のみが AMSI プロバイダーとして登録されていますが、 サードパーティのアンチマルウェア製品をインストールしている場合には、サードパーティ製の AMSI プロバイダーが登録されている場合があります。

AMSI によりスクリプトの実行をブロックする

続いて、実際に AMSI により PowerShell や VBScript のスキャンが行われ、検知される動作を確認してみます。¹⁵

また、今回は単にスクリプトの実行がブロックされることを確認するだけでなく、 ETW プロバイダー Microsoft-Antimalware-Scan-Interface から出力されるイベントを確認することで、 実際に AMSI によりスキャンされ、検知されたコンテンツを特定してみることにします。

事前準備

AMSI による検知テストと、検知時の ETW トレースを取得するため、 仮想マシンなどにインストールした Windows 端末で事前に以下の操作を実施します。

1. logman を使用して ETW イベントトレースセッションを開始する。

まずは、管理者権限で起動したコマンドプロンプトで以下のコマンドを実行し、 ETW プロバイダー Microsoft-Antimalware-Scan-Interface から出力されるイベントを取得するための ETW イベントトレースセッションを開始します。

logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -bs 64 -nb 16 256 -o %USERPROFILE%\Downloads\AMSITrace.etl -ets

このコマンドにより、logman ツールを使用して Microsoft-Antimalware-Scan-Interface という ETW プロバイダーが出力する情報をキャプチャできるようになります。¹⁶

キャプチャしたイベント情報は、上記のコマンド実行時のユーザープロファイル直下の Downloads フォルダに AMSITrace.etl ファイルとして保存されます。

ファイルを特定のフォルダに配置したい場合には、-o オプションで指定している出力先のファイルパスを変更できます。

開始した ETW イベントトレースセッションを停止してイベントのキャプチャを停止するには、以下のコマンドを実行します。

logman stop AMSITrace -ets

なお、注釈に記載している “Better know a data source: Antimalware Scan Interface” などの多くのセキュリティベンダーの公開ブログなどでは、 以下のように -bs 64 -nb 16 256 ETW トレースセッションのバッファサイズに関するオプションを含まないコマンド例が紹介されています。¹⁷

logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -o AMSITrace.etl -ets

しかし、 十分なバッファサイズを指定せずに ETW イベントトレースセッションを開始した場合には、 サイズの大きなイベントがドロップされ、保存した ETL ファイルに含まれない場合があるので注意が必要です。¹⁸

指定したバッファサイズより大きな ETW イベントがロストしたかどうかを確認したい場合は、 logman ではなく Windows Performance Toolkit (WPT) に含まれる Xperf を使用します。 ¹⁹

# トレースセッションの開始
xperf.exe -start AMSITrace -on Microsoft-Antimalware-Scan-Interface -BufferSize 64 -MinBuffers 16 -MaxBuffers 256 -f %USERPROFILE%\Downloads\AMSITrace.etl

# トレースセッションの終了
xperf.exe -stop AMSITrace

Xperf を使用すると、ETW イベントのロストが発生した場合は、 xperf: warning: Session "AMSITrace" lost 1 events. のような警告を表示してくれます。

2. Get-AMSIEvent コマンドレットをインポートする

ETW イベントトレースを取得できるようになったら、次は取得したイベントを解析するためのツールをインストールします。

取得した ETW トレースイベントは、標準の Get-WinEvent コマンドレットで解析することができますが、 このコマンドレットを使用する場合、取得した AMSI/Debug イベントの各フィールドを上手く解釈することができません。²⁰

そのため、今回は前述の “Better know a data source: Antimalware Scan Interface” という記事の中で提供されている AMSITools.psm1 を使用することにします。

このツールを使用するため、まずは AMSITools.psm1 のソースコードをフォークされた以下のリポジトリからダウンロードし、マシンの任意のパスに配置します。

https://gist.github.com/kash1064/7e752a71f6ef48ab32e1323d764b8774

続いて、取得した AMSITools.psm1 を以下のコマンドレットでインポートし、 イベント解析のためのヘルパー関数 Get-AMSIEvent を使用できるようにします。

Import-Module C:\Tools\AMSI\AMSITools.psm1

ツールのインポートが完了すると、以下のコマンドで保存した ETL ファイルを解析できます。

Get-AMSIEvent "$($env:USERPROFILE)\Downloads\AMSITrace.etl"

AMSI で PowerShell スクリプトの実行をブロックする

Microsoft-Antimalware-Scan-Interface から出力されるイベントを取得するための準備ができたので、 まずは PowerShell スクリプトの実行を AMSI でブロックする動作を確認します。

AMSI のテストには、テスト用に公開ドキュメントで提供されている以下のスクリプトを使用します。²¹

# Save this sample AMSI powershell script as AMSI_PoSh_script.ps1
$testString = "AMSI Test Sample: " + "7e72c3ce-861b-4339-8740-0ac1484c1386"
Invoke-Expression $testString

上記のスクリプトを evil.ps1 などのファイル名で端末に保存して PowerShell で実行すると、 以下のようにスクリプトの実行がブロックされることを確認できます。

また、このテスト用スクリプトがブロックされる際に取得した ETW トレースを Get-AMSIEvent "$($env:USERPROFILE)\Downloads\AMSITrace.etl" コマンドで解析してみると、以下のようにスクリプト全体が評価された際には検知が発生しなかった(AMSI_RESULT_NOT_DETECTED)ものの、その後に $testString として連結された文字列 AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386 が評価された際には、AMSI による検知が行われた(AMSI_RESULT_DETECTED)ことを確認できます。

また、テスト検知用の文字列 AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386 を以下のように難読化したスクリプトでもテストを実施してみます。²¹

$base64 = "FHJ+YHoTZ1ZARxNgUl5DX1YJEwRWBAFQAFBWHgsFAlEeBwAACh4LBAcDHgNSUAIHCwdQAgALBRQ="
$bytes = [Convert]::FromBase64String($base64)
$string = -join ($bytes | %{ [char] ($_ -bxor 0x33) })
iex $string

このスクリプトを実行した場合も、難読化されたデータの復号処理を行った後、 'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386' という文字列が評価されたタイミングで AMSI による検知が行われることを確認できます。

このように、PowerShell に統合された AMSI を使用することで、 実行コードが高度に難読化されている場合でも復号処理後の実行コードをスキャンでき、 脅威が検知されることがわかります。

AMSI で VBScript スクリプトの実行をブロックする

続いて、VBScript でもスクリプトの実行が AMSI によりブロックされることを確認してみます。

VBScript についても、公開ドキュメントで提供されている以下のテストスクリプトを使用します。

Dim result
result = eval("AMSI Test Sample:" + "7e72c3ce-861b-4339-8740-0ac1484c1386")
WScript.Echo result

このスクリプトを evil.vbs として保存して実行すると、以下のようなエラーウィンドウが表示され、スクリプトの実行がブロックされたことを確認できます。

また、この時取得した ETW イベントトレースを解析してみると、 PowerShell の場合と同じく検知用のテスト文字列が評価されたタイミングで AMSI による検知が発生したことを確認できます。

1 章のまとめ

本章では、AMSI の概要やその保護機能を使用するメリット、 また実際に AMSI による検知が行われる場合のイベントの確認方法などを紹介しました。

次章からは、サンプルコードを使用し、実際に AMSI がアプリケーションにどのように統合されているか、 また AMSI によるスキャン要求をプロバイダーがどのように処理するかについて解説していきます。

本書のもくじ

• まえがき
• 1 章 AMSI (Windows Antimalware Scan Interface) について
• 2 章 AMSI クライアントインターフェース
• 3 章 AMSI プロバイダー
• 4 章 サンプルプログラムのカスタマイズ
• 5 章 PowerShell に統合された AMSI