ESETの研究者は、ECサイトで顧客の決済情報を盗むことを目的にしている、これまで検出・文書化されていなかったトロイの木馬を検出・分析しました。ESETは、このトロイの木馬をIIStealerと命名しました。ESETのセキュリティソリューションではWin64/BadIISとして検出されます。

攻撃の概要

IIStealerは、マイクロソフト社のWebサーバーソフトウェアであるIIS（Internet Information Services）に悪意のある拡張機能として実装されます。IIStealerはサーバーの一部として組み込まれ、サーバーを通過するすべてのネットワーク通信にアクセスし、攻撃者にとって価値の高いデータ（今回のケースではECサイトの決済情報）を盗み出します。

図1に示すように、IIStealerは、特定のURIパスに対するHTTP POSTリクエストを標的として、セキュリティが侵害されたサーバーとそのクライアント（販売側と購入側）間の通常のトラフィックを傍受します。IIStealerは、/checkout/checkout.aspxまたは/checkout/Payment.aspxのURIのパスを標的にします。

正規のユーザーがWebサイトにアクセスし、これらのチェックアウトページ（1）にリクエストを行うと、IIStealerはHTTPリクエストのボディをログファイル（2）に記録します。この時、正規のWebサイトのコンポーネント（3）により生成されるHTTP応答には一切影響を与えません。

攻撃者は、セキュリティが侵害されているIISサーバーに特殊なHTTPリクエストを行うことで、収集したデータを取得します。IIStealerは、X-IIS-Dataヘッダーに攻撃者のパスワードが含まれている特定のURI（/privacy.aspx）へのリクエストを検出すると（4）、そのリクエストに対するHTTP応答に収集したデータを埋め込みます（5、6）。

図1.IIStealerがデータを収集し外部へ送信する仕組み

IIStealerはこれらの機能を使用して、サードパーティのペイメントゲートウェイを使用していないECサイトに送信されたクレジットカード情報を盗み出します。通信チャネルでSSL/TLSが使用されていても、また、暗号化されていても、IIStealerの攻撃を受けると、これらのトランザクションの安全性は確保されません。このマルウェアはサーバーが処理するすべてのデータにアクセスできます。これは、クレジットカード情報は暗号化されない状態のままサーバーで処理されるためです。

ESETが分析したこのマルウェアの検体では、チェックアウトページのURIがハードコードされていることから、特定のECサイトを攻撃するように設計されていると考えられます。ESETのテレメトリ（監視データ）によると、2020年9月から2021年1月までの間に、米国にある数台のIISサーバーが攻撃対象となっていましたが、これはESETが監視しているIISサーバーが限定されていることが影響している可能性があります。これらのIISサーバーでは、管理者がセキュリティソフトウェアを使用しないケースが依然として一般的です。

技術的な分析

IIStealerは、悪意のあるネイティブIISモジュールとして実装されます。C++ DLLは、侵害されたIISサーバーの%windir%system32\inetsrv\フォルダにドロップされ、%windir%system32\inetsrv\config\ApplicationHost.configファイルで設定されます。IIStealerはdir.dllという名前で展開され、図2に示すように、偽造されたVERSIONINFOリソースを使用して、dirlist.dllという正規のWindows IISモジュールになりすます場合もあります。

図2.正規のdirlist.dllモジュール（右）になりすますIIStealerのVERSIONINFOリソース（左）

これはIISモジュールであるため、IIS Webサーバーへのリクエストを処理するIISワーカープロセス(w3wp.exe) によってIIStealerが自動的にロードされます。これがIIStealerが常駐化し、受信したリクエストを処理できる仕組みです。

このマルウェアの拡散方法については不明点が多くありますが、IISのネイティブモジュールとしてインストールするためには管理者権限が必要であることから、最初のセキュリティ侵害となっている可能性があると考えられます。これはWebアプリケーションまたはサーバー自体の構成上の弱点や脆弱性が原因となっている可能性があります。

技術的な特徴としては、IIStealerはCHttpModule（モジュールクラス）から継承したコアクラスを実装し、CHttpModule::OnPostBeginRequestメソッドを悪意のあるコードでオーバーライドします。他のIISネイティブモジュールと同様に、IIStealerはRegisterModuleという名前の関数をエクスポートします（図3を参照）。ここでモジュールクラスをインスタンス化し、メソッドをサーバーイベントに登録します。具体的には、サーバーが受信したHTTPリクエストの処理を開始するときに毎回生成されるRQ_BEGIN_REQUESTイベント後通知に登録します。これにより、新しいリクエストが発生すると毎回OnPostBeginRequestメソッドが呼び出され、IIStealerがリクエストの処理に関与するようになります。

図3.IIStealerのRegisterModuleエントリポイント

IIStealerは、OnPostBeginRequestハンドラでリクエストのURIによって受信したHTTPリクエストをフィルタリングします。checkout/checkout.aspxまたはcheckout/Payment.aspxに送信されたすべてのPOSTリクエストは、そのHTTPボディと一緒にC:WindowsTemp\cache.txtファイルに記録されます。これらのリクエストは、セキュリティが侵害されたECサイトにアクセスした正規のユーザーが実行したものであり、個人情報やクレジットカード番号などの機密情報が含まれている可能性があります。

収集したデータは、攻撃者が特別に細工したHTTPリクエストを介して外部に送信される場合があります。このリクエストのX-IIS-Data HTTPヘッダーにはハードコードされた32バイトの英数字のパスワード（ここでは公開しません）が設定され、マルウェアの検体で指定される以下のURLパスに送信されます。

　o /privacy.aspx
　o /checkout/Payment.asp

この悪意のあるモジュールが、このようなリクエストを検出すると、IHttpResponse::Clearメソッドを使用して、IISサーバーが用意したHTTPレスポンスを削除し、図4に示したように、IHttpResponse::WriteEntityChunks API関数を使用して、暗号化されていないログファイルのコンテンツをHTTPレスポンスのボディにコピーします。

図4.IIStealerは、HTTPレスポンスボディを自身のデータで置き換える

これにより、IIStealerのオペレーターは、侵害されたIISサーバーに特別なリクエストを送信するだけで、収集したデータにアクセスし、データを入手できます。このマルウェアは別のC&Cチャネルを追加したり、C&Cサーバーのドメインを構成に組み込んだりする必要はありません。

IIStealerの影響を軽減する方法

IIStealerはサーバー側の脅威であり、セキュリティが侵害されたECサイトと顧客との間の通信を傍受し、機密性の高い決済情報を窃取します。この悪意のあるIISモジュールは、認証情報なども標的にします。SSL/TLSは、クライアントとサーバー間のデータ転送を保護するために不可欠ですが、IIStealerはサーバーの一部として組み込まれており、この攻撃シナリオを防ぐことはできません。Webポータルを管理している組織にとって、認証情報や決済情報などアクセスしたユーザーのデータを保護しなければならないため、これは気がかりな問題です。

IIStealerなどの脅威に対してIISサーバーを強固にするには、以下の方法があります。

• IISサーバーを管理する場合には、強力で固有のパスワードを設定した専用のアカウントを使用してください。
• OSに定期的にパッチを当て、インターネットに公開するサービスを慎重に検討することで、サーバーが悪用されるリスクを軽減できます。
• IISのネイティブモジュールは、信頼できるソースからのみインストールしてください。
• IISサーバーに、Webアプリケーションファイアウォールやエンドポイントセキュリティソリューションを使用することを検討してください。
• 構成ファイル%windir%\system32\inetsrv\config\ApplicationHost.configと%windir%\system32\inetsrv\および%windir%\SysWOW64\inetsrvフォルダを定期的に確認し、インストールされているすべてのネイティブモジュールが正規のものであることを確認してください（信頼できるプロバイダーによって署名されているか、自らがインストールしたものであるかを確認します）。

Web開発者側の対策：WebサービスがホストされているIISサーバーを管理できなくても、特にセキュリティ侵害が発生した場合にWebサービスのユーザーへの影響を軽減する対策を講じることができます。

• パスワードをサーバーに送信しないでください（SSL/TLSでも送信しない）。SRP（Secure Remote Password）などのプロトコルを使用して、暗号化されていないパスワードをサーバーに送信したり、再認証に使用される可能性のあるデータの送信をせずに、ユーザーを認証してください。IIS情報窃取型マルウェアは、サーバーサイドのハッシュが十分なセキュリティ対策にならないことを示す良い例です。
• Webアプリケーションから機密情報を送信することはできるだけ避け、ペイメントゲートウェイを使用してください。
• セキュリティ侵害が確認された場合、侵害に関わるすべての関係者に通知し、迅速に対応できるようにします。

ユーザー側の対策：ECサイトにアクセスするユーザーは、IISサーバーのセキュリティが侵害されているかどうかを知ることはできませんが、以下のヒントを参照してリスクを軽減してください。

• クレジットカードの番号を入力する場所には注意してください。ECサイトの評判を確認し、その評判が芳しくない場合には、信頼できる第三者機関のペイメントゲートウェイを利用することを検討してください。ペイメントゲートウェイを利用すれば、そのようなサイトで機密性の高い決済情報を扱うことはありません。
• 小規模あるいは通常とは異なる取引がクレジットカード明細にないか常に注意しておいてください。クレジットカードが有効であるか確認するために、攻撃者が最初に少額を請求することがよくあります。
• 通常とは異なる不審な点があれば、すぐに銀行やクレジットカード会社に知らせてください。

今回説明したマルウェア、セキュリティ侵害の痕跡、YARAルールに関する技術的な詳細については、ESETのホワイトペーパーや GitHubを参照してください。

このブログ連載では、ESETの研究者がIIS Webサーバーで検出した一連の脅威について特集します。今回は連載の第一弾です。第二弾は、サイバースパイやSEO詐欺に使用されている悪意のあるIIS拡張機能について説明します。

IISマルウェアの検出、分析、削除の方法については、詳細を解説したホワイトペーパー「ネイティブIISマルウェアの解析」（英語のみ）を参照してください。

セキュリティ侵害の痕跡（IoC）

ESETの検出名

Win64/BadIIS.F
Win64/BadIIS.O

SHA-1

706EAB59C20FCC9FBC82C41BF955B5C49C644B38
7A2FA07A7DC05D50FE8E201A750A3DC7F22D6549
A1C5E7424E7C4C4C9902A5A1D97F708C6BB2F53A

ファイル名とパス

dir.dll
isapicache___.dll
isapicache_.dll_の
C:\Windows\Temp\cache.txt

ネットワークの侵害の痕跡

対象のURI

/checkout/checkout.aspx
/checkout/Payment.aspx
/privacy.aspx

HTTPヘッダー

X-IIS-Data

MITREのATT&CK手法

注：この表は、MITRE ATT&CKフレームワークのバージョン9を使用して作成されています。