マルウェアの開発者たちは、ターゲットの防御システムからの検出を回避する方法を常に探しています。その 1 つが、難読化、暗号化、ステガノグラフィなどの手法を駆使して、アンチウイルスソフトウェアがペイロードの目的を理解できないようにし、スキャナに対抗する方法です。もう 1 つは、マルウェアがスキャンすらされないようにしてしまう方法です。
Windows 10 や最新世代の Windows Server プラットフォームが普及してくると、マルウェア開発者やその他の攻撃者は、これらのプラットフォームのマルウェア対策機能であるマイクロソフトのマルウェア対策スキャンインターフェイス (AMSI: Antimalware Scan Interface) への対策を取り入れて、検知を逃れようと企むようになってきました。2015 年に導入された AMSI は、ソフトウェアがセキュリティ製品と連携する手段を提供します。ベンダーに依存しない方法で、ファイル、メモリ、またはストリームのスキャンを要求でき、悪意のあるペイロードを検出します。
AMSI は、Windows の PowerShell エンジンやスクリプトホスト (wscript.exe および cscript.exe)、Office ドキュメントマクロ、現行の .NET Framework (バージョン 4.8)、Windows Management Instrumentation (WMI) など、マイクロソフトのコンポーネントやアプリケーションを可視化します。これらのコンポーネントは、攻撃者による環境寄生型/自給自足型攻撃やファイルレスマルウェアの実行に頻繁に使用されています。Windows サードパーティの開発者は、自社のアプリケーションでも AMSI を活用し、マルウェア対策ソフトウェアが、自社のアプリケーションを、マルウェアやネットワークへの侵入者が悪用するアプリケーション (LOLbins) にする恐れのあるコンテンツをチェックすることができます。
このような理由から、AMSI はマルウェア開発者にとって非常に重要なターゲットになっています。AMSI が導入された当初から、攻撃者（およびセキュリティ研究者）は、AMSI を回避したり無効にしたりするツールを作成してきました。マイクロソフトやセキュリティソフトウェアプロバイダは、AMSI の回避に使われるアプローチの一部をブロックする措置をとってきましたが、攻撃者はそのような対策にも対応しています。自動化されたツールを使って攻撃コードを難読化したり、防御システムを調べ上げてその穴を最終的に見つけたり、あるいは完全に AMSI を回避する方法を見つけたりしています。
本レポートでは、一般的に使用されている AMSI の回避方法と、Windows システムの防御を回避しようとするマルウェアがそれらをどのように使用しているかを検証します。
Fail フラグを立てる
2016 年 5 月、PowerShell ハッカーの Matt Graeber 氏は、AMSI を回避する方法をツイートしました。
この Graeber 氏の PowerShell コードは、PowerShell の AMSI 統合用の属性であるamsiInitFailed のフラグを「true」にすることで、現在の PowerShell プロセスがスキャンの要求を停止するというものです。これにより、悪意のある PowerShell スクリプトは、(理論上は) アンチマルウェアソフトウェアによるスキャンされることなく、意図した通りに攻撃を実行できます。
この回避手法は、現在では広く検出され、悪意のあるコンテンツとしてブロックされています (5 年前に公開されたエクスプロイトなので当然かもしれません)。しかし、攻撃者は、シグネチャベースのスキャンを回避するために、難読化されたバージョンをいまだに使用しています。また、2021 年 2 月から 5 月までの 90 日間のテレメトリデータによると、amsiInitFailed の回避手法は依然として検出の約 1% を占めています。
これらの検出のほとんどは、ラテラルムーブメントや侵入テストを目的としたエクスプロイト実行後の手動による試みと思われます。何故なら、これらの検出に関連するパッケージの配信で利用された IP アドレスがローカルネットワークのものであったためです。たとえば、最近発見されたこの回避方法は、ネットワークのプライベート IP アドレス空間内の安全な Web サーバーから PowerShell バックドアを取得しようとしています。
しかし、最近検出された同じ回避方法の使用例では、リモートサーバーに接続して PowerShell ベースのマルウェアダウンローダーを取得していたことがわかりました。これは、ロシアにあるサーバーから Meterpreter バックドア DLL をロードしようとした Proxy Logon を利用する攻撃の一部であったようです。
Web ワーカープロセスを使用してシェルコマンドを実行し、攻撃者はこのコマンドを PowerShell.exe に送信しました。
この文字列の 2 番目の URL は、通常は Windows Defender によって「Ploty-C」と識別されて実行がブロックされる PowerShell スクリプトを参照しています。しかし、最初に実行されたスクリプト部分は、検出を回避するために Base64 でエンコードされ GZip で圧縮された、難読化された AMSI 回避手法のものです。
同じエクスプロイトを実現する別の方法では、リフレクションを使用して、PowerShell から .NET フレームワークを介して同じコマンドを呼び出します。最近検出されたこのタイプの侵入事例では、サイバー攻撃者 (ペネトレーションテスト担当者の可能性もありますが、すでに侵入されたネットワーク内でのラテラルムーブメントを試行している攻撃者である可能性が高いでしょう) は、「Seatbelt」という攻撃的なセキュリティエクスプロイトツールを使用していました。このケースでは、PowerShell スクリプトは、リフレクションを使用して AmsiUtils の .NET インターフェイスにアクセスするデリゲートプロセスを作成し、文字列の難読化をすることで検出を回避しようとしています。
メモリの改変
AmsiUtils インターフェイスのプロパティを操作することは、AMSI を回避する一般的な方法ですが、最近のテレメトリで確認された回避試行の 98% 以上が、スキャン要求を失敗させるために、すでにメモリにロードされているAMSI ライブラリ自体のコードを改ざんするという別のアプローチに集中しています。この攻撃では、メモリにすでにロードされている AmsiScanBuffer というライブラリを探し出し、そのアドレスの命令を上書きしてエラーメッセージを表示させます。この攻撃では、マルウェアがメモリ内のライブラリ「AmsiScanBuffer」を探し出し、そのアドレスの命令を、エラーメッセージにリダイレクトする新しい命令で上書きします。この攻撃を難読化せずに PowerShell で実行すると、次のようになります。
この攻撃の別バージョンでは、バッファスキャンの結果を返すコードを格納しているメモリが変更され、スキャンを失敗させます。
このメモリパッチの手法は、商用の攻撃用セキュリティプラットフォームである Cobalt Strike に、amsi_disable というオプションとして組み込まれています。また、この手法は、ソフォスが最近分析したリモートアクセスツール (RAT) マルウェア「Agent Tesla」のダウンローダー、クリプトジャックマルウェア「WannaMine」のインストール、PowerShell ベースの RAT をドロップする最近の ProxyLogon ベースの侵入など、多くのマルウェアファミリーでも確認されています。
3 月には、ソフォスが担当するお客様のシステム上で WannaMine のペイロードのインストールが繰り返し試みられているのを検出しました。保護されていなかった Windows システムが 1 台感染し、保護されたシステムでの実行をブロックしている間にも、クリプトジャックワームがこれらのシステムに拡散しようとする試みが継続的に確認されました。これらの試みは、AMSI テレメトリを提供している各システム上で、ピーク時には 1 日に 300 回以上行われました。
AMSI がサポートされているバージョンの Windows を実行しているシステムでは、WannaMine は、システムが 32 ビットまたは 64 ビットの Windows を実行しているかどうかに応じて、リモートスクリプトを呼び出すコマンドラインを実行します。
このリモートスクリプトのオブジェクトは高度に難読化されています。
難読化されたコマンドを解凍した後、リモートスクリプトは、検出された Windows のバージョンに応じた適切なコードで amsi.dll にパッチを当てようと試みます。
ソフォスは、この AMSI 回避スクリプトの実行をブロックするとともに、WannaMine のスクリプトが他のシステムに拡散し、そのクリプトマイナーをインストールしようとする試みも阻止します。しかし、ネットワーク上でひとつでも無防備なシステムが感染してしまうと、それがネットワーク全体での継続的な攻撃につながります。
偽の DLL を使う
AMSI を回避するもう 1 つのよくある方法は、2016 年に Cornelis de Plaa 氏が明らかにした、PowerShell を騙して偽バージョンの amsi.dll を読み込ませる方法に基づいています。当初の手法はシンプルなものでした。
- ターゲットディレクトリに「amsi.dll」という名前の空の DLL を作成します。
- PowerShell.exe を同じディレクトリにコピーします。
- 悪意のある PowerShell スクリプトを起動すると、偽の DLL が先にロードされるため、PowerShell.exe のコピーによる AMSI スキャンは失敗します。
しかし、マイクロソフトはその後、PowerShell のコードに変更を加え、amsi.dll で適切なインターフェイスが利用できない場合、PowerShell がクラッシュするようにしました。そのため、現在このタイプの DLL ハイジャックを実行するには、攻撃者は必要なインターフェイスが定義された偽の DLL を提供する必要があります。
AMSI の回避
AMSI を回避する他の手法としては、スクリプトエンジンを、AMSI が利用可能になる前のバージョンにダウングレードするか、あるいは、AMSI と相互作用するプロセスから完全に離れることが一般的です。 PowerShell のバージョン 2 がインストールされているシステムでは、攻撃者はスクリプトが使用する PowerShell のバージョンを切り替えることができます (PowerShellをコマンドラインから -Version 2 のパラメータを付けて実行します)。
powershell.exe -Version 2
AMSI を回避するもう一つの方法は、AMSI をサポートしていないスクリプトエンジンを持ち込むことです。AMSIは、.NET フレームワークを利用しているものはすべて検出しますが、攻撃者の中には、独自のスクリプトホスト (Node.JS エンジンなど) を持ち込んだり、他のスクリプト言語 (Pythonなど) からコンパイルした実行ファイルを使用したりする者もいます。
極端なケースでは、スクリプトを検出されないようにするために、仮想マシン全体を持ち込む攻撃者も見られます。たとえば、Ragnar Locker は、ランサムウェア攻撃の一環として VirtualBox の仮想マシンを導入し、そのプロセスをマルウェアスキャナから完全に隠蔽しました。
多層防御
AMSI は、マイクロソフトのコンポーネントを利用した LOL の手法に対する防御を提供し、アプリケーション開発者が悪意のあるスクリプトやコードに悪用されないように自らのツールを強化する方法を提供することを目的としています。特にランサムウェアを使った不正侵入など、こうした手口が一般的になっていることを考えると、Windows 10 やWindows Server のシステムが危険にさらされないようにするために、AMSI は特に重要な役割を果たすことができるでしょう。それでも、AMSI は万能薬という訳ではありません。また、マイクロソフトの Windows Defender は、AMSI の回避に対してある程度の防御機能を備えていますが、攻撃者は、マルウェア対策ツールのシグネチャに検出されないように、悪意のあるコンテンツを難読化して隠す方法を絶えず見つけ出しています。
ソフォスなどのマルウェア対策ソリューションのプロバイダは、シグネチャベースの検出以外の AMSI 回避に対する防御機能を提供しています。しかし、攻撃者も、AMSI の防御を回避する新たな方法を常に考えています。また、防御策やセキュリティパッチの展開が一貫していないために、システムの一部がそれほど高度ではない攻撃に対しても脆弱になっており、それによってマルウェアが AMSI ベースの防御を部分的または完全に回避する足がかりを得てしまうことがよくあります。エンドポイントとネットワーク上の検知機能を組み合わせた「多層防御」は、こうした侵入者の攻撃による被害を事前に食い止めるために重要です。
コメントを残す