もくじ
エグゼクティブ・サマリー 2 イントロダクション 3 ユーザーの操作 3 設定 5 環境 11VMware
によるサンドボックスの回避手法 14 一般公開されているサンドボックスの比較 17 まとめ 17FireEye
について 18エグゼクティブ・サマリー
サイバー攻撃がますます深刻な脅威となる中、仮想マシンを利用したサンドボックスで大量のファイルを高速検査し、 疑わしい活動の有無を調べる手法が普及しています。サンドボックスとは、ファイルを実際に実行したときの振る舞い を監視する、隔離された仮想環境を指します。サンドボックスを使用すれば、シグネチャに基づく従来型のセキュリティ 対策をすり抜けてしまう不正なコードも、理論上は検知可能となります。 ただしサンドボックスが有効に機能するためには、サンドボックス内でのファイルの振る舞いを適切に解析する必要が あります。サンドボックス自体の役割は、あくまでもファイルの活動を監視して報告することであり、解析ではありません。 また残念ながら、多くのベンダーの製品で採用されているファイルベースのサンドボックスでは、最新のマルウェアを 検知できない実態が明らかになりつつあります。攻撃者は、さまざまな手法を駆使してサンドボックスによる検知を 免れ、サンドボックスを無力化しようと試みているからです。 一口に「サンドボックス」と言っても、その概念は広範であり、コードを隔離するにしてもさまざまな方法があります。 本レポートで対象とするのは、特定のコンピュータをシミュレートした組み込みの仮想マシン環境で未知のファイルを 実行し、その活動を監視および解析して、結果をレポートするファイルベースのサンドボックス技術です。高度な マルウェアは、本レポートで解説する手法を用いて実行環境が仮想マシンであることを見抜き、このタイプのサンドボックス を無力化します。このようなマルウェアを検知するためには、マルチフロー解析によって振る舞いのコンテキストを 解析し、一見無関係な攻撃の個々のフェーズを関連付けるメカニズムが必要となります。実際にFireEye?の研究者 は、この手法によって、本レポートで解説しているマルウェア・サンプルを発見しています。 本レポートでは、次のサンドボックス回避手法について詳しく解説します。 • ユーザーの操作 ー フマウス・クリックやダイアログ・ボックスの操作など • 設定 ー スリープAPIの呼び出し、タイム・トリガー、プロセスの隠 など • 環境 ー バージョン、埋め込みiframe、DLLローダー • VMware ー システム・サービスのリスト、VMware固有のファイル、VMXポートイントロダクション
セキュリティ実施のためのコア・エンジンとして、シグネチャ・マッチングを利用する従来型のセキュリティ対策では、 最新の高度なサイバー攻撃に立ち向かうことができません。これは、多くのセキュリティ担当者に共通する見方です1。 今日の攻撃者は、ダイナミックに姿を変える高度なポリモーフィック型マルウェアを使用して、未知の脆弱性を悪用し、 複数の経路から連動した攻撃を仕掛けてきます。 そこでマルウェア対策では、シグネチャ・マッチングに依存するのではなく、自動解析システムとサンドボックス技術を 使用して、マルウェアの振る舞いそのものを検証するようになりました。こうした自己完結型のシミュレーション環境を 使用すれば、実際の環境に影響を及ぼすことなく疑わしいファイルを実行できます。セキュリティ・システムは、仮想 環境内でのファイルの動作を監視しながら、オペレーティング・システムの改変や攻撃者の指令（C&C）サーバーとの 通信など、疑わしい振る舞いをチェックします。 これに対し、攻撃者の側も進化を遂げています。巧妙な攻撃者は、標的にたどり着く前にサンドボックスでファイルが実行 される可能性を考慮して、仮想マシンの検知機能をマルウェアに組み込み、標的以外の環境では不正な活動を行わない ように抑制しています。サンドボックスで疑わしい活動をしなかったファイルは無害と見なされ、サンドボックスを通過 できるからです。 マルウェア作成者にとって重要なのは、ファイルの実行環境が仮想環境であるか標的の物理的なコンピュータである かを判断することです。そのためマルウェア作成者は、この目的に向けたさまざまな手法を開発しています。ユーザーの操作
ファイルベースのサンドボックスは物理的なシステムをエミュレートします。しかしエミュレートでは、ユーザーによる 操作は発生しません。攻撃者は、物理的なシステムとサンドボックスのこの違いをマルウェア作成に利用しています。 つまり、マウスのクリックやダイアログ・ボックスへの意味のある応答など、実際のユーザーによるものと思われる操作 が行われるまで、マルウェアを活動させないようにしているのです。このセクションでは、ユーザー操作の有無に基づく サンドボックス回避技術について詳しく説明します。マウス・クリック
FireEyeが2012年12月に分析したトロイの木馬「UpClicker」は、マウス・クリックを手がかりにしてユーザーの操作を 検知する、最も古いマルウェアの1つです2（もう少し単純な手口はその数か月前に確認されています3）。UpClickerは、 サンドボックスによる検知を回避するため、マウスの左クリックを確認してからC&Cサーバーとの通信を開始します。 このマルウェアは、APT（Advanced Persistent Threat）攻撃で広く使用されているリモート・アクセス・ツール（RAT） 「Poison Ivy」のラッパーです4。図1に示したのは、UpClickerのコードの一部です。ここでは、0Ehをパラメータ値として、SetWinodwsHookExA という関数を呼び出しています。これにより、低レベルのマウス入力を監視するWindowsのフック・プロシージャ WH_MOUSE_LLがインストールされます5。
1 Gartner. Best Practices for Mitigating Advanced Persistent Threats. January 2012. 2 FireEye. Don t Click the Left Mouse Button: Introducing Trojan UpClicker. December 2012.
3 Symantec. Malware Authors Using New Techniques to Evade Automated Threat Analysis Systems. October 2012. 4 ZDNet. Nitro targeted malware attacks hit chemical companies. November 2011.
図1：マウス操作をフックするマルウェア・コード（強調表示されているfnはポインタ） 図1で強調表示しているポインタfnは、図2の赤い枠内のフック・プロシージャを参照しています。 図2：ポインタfnで参照されているコード（マウスのアップクリックに対するアクション） このコードはマウスの左クリック（厳密には、マルウェア名の由来であるアップクリック）を監視します。アップクリックを 検知すると、関数UnhookWindowsHookEx ()を呼び出してマウス操作の監視を停止し、関数sub_401170 ()を呼び 出して不正なコードを実行します。 UpClickerの6か月後に確認された、APT関連のマルウェア「BaneChant」では、この仕組みがさらに巧妙化して おり、マウス・クリックが3回行われた後で活動を開始します6。
ダイアログ・ボックス
ユーザーの応答を要求するダイアログ・ボックスも、実行環境が物理的なコンピュータであるかどうかを確認する手 段として使用されます。典型的な手口は、WindowsのAPI関数であるMessageBoxとMessageBoxExを使用 して、EXEファイルやDLLファイルでダイアログ・ボックスを作成するというものです。マルウェアは、ユーザーがボタン をクリックしたことを確認してから活動を開始します。
Adobe Acrobat PDFファイルを使用するマルウェアでは、JavaScript for Acrobat APIに用意されているapp.alert() メソッドを使用してダイアログ・ボックスが作成されます。図3に示したのは、このメソッドを使用してダイアログ・ボックス を開くコードです。ユーザーがOKをクリックすると、app.launchURL()メソッドを使用して不正なURLに接続します。 図3：ダイアログ・ボックスを開き、特定のWebサイトにアクセスするJavaScript コード（WebサイトのURLは加工してあります）
設定
サンドボックスは保護対象の物理的なコンピュータを模倣する技術ですが、サンドボックスによる仮想環境は特定の パラメータに従って設定されています。そのためサイバー攻撃者は、これらの設定を利用してサンドボックスによる 検知を回避しようとします。スリープAPIの呼び出し
通常、ファイルベースのサンドボックスは、多数のファイルを検査するために、ファイルの動作を数分程度しか監視 しません。この間に疑わしい振る舞いが見つからなければ検査を終了し、次のファイルに移ります。 このためマルウェアは、「検査時間中は何もせずにやり過ごす」というごく単純な対策でサンドボックスによる検知を 免れることができます。マルウェア作成者は、スリープAPIの呼び出しを追加し、サンドボックスによる監視中に疑われる ような振る舞いをしないようマルウェアを制御しています。 この手法を採用しているのが、2013年2月に発見されたトロイの木馬「Nap」です7。Napは、MicrosoftとKasperskyが 2011年に閉鎖を宣言したボットネット「Kelihos」と関係しています8。7 FireEye. An Encounter with Trojan Nap. February 2013.
図4に示したのは、Napのコードの一部です。実行されたNapは、wowrizep.ruという不正なドメインにホストされた ファイルnewbos2.exeに対するHTTPリクエストを送信します。 図4：不正なドメインとダウンロードされる実行可能ファイル 続いて、図5にあるようにSleepEx()メソッドを呼び出し、タイムアウトのパラメータ値として60万ミリ秒（10分）を示す 0x0927C0を渡します。さらに、10分経過するまで戻り値を返さないよう、alterableフィールド属性をfalseに設定し ます。10分というのは、ほとんどのサンドボックスのファイル実行時間よりも長い時間です。 図5：SleepExメソッドを呼び出すNapのコード
またこのコードは、不正な活動の開始を遅らせるもう1つの対策として、文書化されていないAPIメソッドの NtDelayExecution()を呼び出します。
PDFファイルの場合は、JavaScript for Acrobat APIに用意されている同様のメソッドapp.setTimeout()が使用され ます。不正なPDFファイルで使用されていた図6のコードでは、このメソッドを使用して、不正な関数mystr()を呼び出す 前に100万ミリ秒（約16分）待機しています。
図6：app.setTimeout()メソッドを使用して、不正な関数mystr()を呼び出す前に 100万ミリ秒待機するJavaScript for Acrobatコード
タイム・トリガー
スリープAPIの呼び出しとタイム・トリガーを組み合わせて、一定時間経過後にのみ活動を開始するよう設定されている マルウェアもあります。これよりも短い時間しか監視を行わないサンドボックスでは、不正な活動を検知できません。 2013年3月に韓国で発生した大規模なデータ破壊攻撃で使用されたトロイの木馬「Hastati」は、まさにその代表例 と言えるマルウェアです9。Hastatiは、WindowsのSystemTime構造体にポインタをインポートするAPIメソッド GetLocalTime()を使用して、システムの現在の日時を取得します。仮想マシンが特定の時間にこのマルウェアを監視 していなかった場合、マルウェアは検知を免れます。 図7で、SystemTime構造体は次の値を返しています（16進数のペアは、メモリ内では逆の順序で格納されています）。 • 07 DD（wYear）− 2013（年に対応） • 00 06（wMonth）− 6月（月に対応） • 00 01（wDayofWeek）− 月曜日（曜日に対応） • 00 11（wDay）− 17（日に対応）図7：Hastatiのコードの一部。赤い枠内のGetLocalTime()メソッドの呼び出しで、 現在の時刻を確認 ここでは、現在の日時（2013年6月17日月曜日）がトリガーとなる日時（2013年3月20日午後2時）を経過しているため、 不正なコードが実行されます。一方、現在の日時がトリガーとなる日時を超えていない場合、マルウェアはSleep()関数 を呼び出し、値として0EA60（6万ミリ秒）を渡します（図8）。そして6万ミリ秒経過後に、再び日時を確認します。こうして、 現在の日時がトリガーとなる日時を経過するまで、Sleep()関数の呼び出しを繰り返します。 図8：トリガー条件が満たされていない場合、マルウェアはSleep()関数を呼び出す
プロセスの隠
ファイルベースのサンドボックスは、オペレーティング・システムで起動しているすべてのプロセスを監視して、 マルウェアの活動と思われる振る舞いを検知します。このとき多くのサンドボックスでは、Microsoftが提供する PsSetCreateProcessNotifyRoutineというカーネル・ルーチンを使用します。ハードウェア・ドライバでは、この ルーチンを使用することで、Windowsプロセスの開始または終了時に呼び出されるソフトウェア・ルーチンのリスト を作成、修正することができます。ファイルベースのサンドボックスは、この情報を使用してシステム・アクティビティ を追跡し、重要なリソースを保護します。 Windowsでは、PsSetCreateProcessNotifyRoutineの開始アドレスを使用して一連の内部コールバック・オブジェクト を管理します（Windows XP SP2の場合、登録可能なコールバック数は最大8）。しかし、一般の開発者がこの内部 ルーチンの内部ポインタをエクスポートすることはできません。また、サードパーティ製アプリケーションでこれらの 通知を容易に登録するためのメソッドも公開されていません。 ところがマルウェア作成者は、文書化されていない内部ポインタの使用方法を発見しており、内部ポインタを悪用する マルウェアの存在がすでに確認されています。そうしたマルウェアの中でも特に悪名高いのが、6年ほど前に出現した マルウェア・ファミリーの「Pushdo」です。Pushdoは非常に悪質な破壊活動を行い、動作の停止が困難なマルウェア として知られています10。 PushdoはPsCreateProcessNotifyRoutineにアクセスして、登録済みのすべてのコールバック（セキュリティ・ ソフトウェアのコールバックを含む）を削除します。コールバックを削除するのは、警戒されることなくプロセスの作成 や停止を行えるようにするためです。 マルウェア作成者にとっての成否は、PsSetCreateProcessNotifyRoutineの内部ポインタを発見できるかどうかに かかっています。図9に示したのは、逆アセンブラのIDAを使用してWindowsのカーネル・イメージ（ntoskrnl.exe） から抽出したコードです。このコードから、PsSetCreateProcessNotifyRoutineのx86アセンブリにポインタのオフ セットが含まれていることが分かります。 図9：ntoskrnl.exeのPsSetCreateProcessNotifyRoutinePushdoはこの情報を元に、セキュリティ・ソフトウェアへのプロセス通知を容易に解除することができます。図10に 示したPushdoのコードは次の手順で動作します。 1. マルウェアは、NtBuildNumber関数を使用してWindowsのビルド番号を確認します。Windows XPの場合、 ビルド番号は32ビット版が2600、64ビット版が3790です。 2. マルウェアは、PsSetCreateProcessNotif yRoutineの 実 行 時 のアドレスを取 得します。図 11 に示したjmp_PsSetCreateProcessNotif yRoutineのアセンブリ・コード（抜粋）には、外部の PsSetCreateProcessNotifyRoutineルーチンへのjmpコマンドが含まれています。jmp演算コードの長さは 2バイトであるため、メモリに格納されたPsSetCreateProcessNotifyRoutineの実行時のアドレスは、 jmp__PsSetCreateProcessNotifyRoutine + 2となります。 3. マルウェアはアセンブリ・コードを直線的にスキャンして、5バイト後に「0x57」が続く「0xBF」を探します。この 「0xBF」の直後にある値が、PspCreateProcessNotifyRoutineの内部アドレスです。 4. マルウェアはこのアドレスからPsCreateProcessNotifyRoutineポインタをたどり、すべてのコールバック・ オブジェクトを無効にします。Windows XPの場合、演算コード0xBFは「mov edi」、0x57は「push edi」を意味 します。
図10：PsCreateProcessNotifyRoutineの取得
環境
サンドボックスで実行されるコードは、理論上、物理的なコンピュータでも同じように実行されるはずです。しかし実際 には、ほとんどのサンドボックスには隠しきれない固有の特徴があります。そのため攻撃者は、そうした特徴を手がかり にして実行環境がサンドボックスかどうかを確認する機能をマルウェアに組み込んでいます。このセクションでは、環境 に関する情報を利用したサンドボックスの回避技術について説明します。バージョン・チェック
多くの不正なファイルは、特定バージョンのアプリケーションやオペレーティング・システムでのみ動作するように設定 されています。マルウェア作成者が自ら設定しているこのような制限は、必ずしもサンドボックスの回避を狙ったもの ではありません。多くの場合は、特定バージョンのアプリケーションにしか存在しない脆弱性を悪用することなどを目的 としています。 ただし、意図は違っていても結果はほとんど同じです。すべてのサンドボックスには、あらかじめ設定が用意されてい ます。使用している設定に特定のオペレーティング・システムとアプリケーションの組み合わせが用意されていない 場合、マルウェアは動作を開始せず、検知を免れる場合があります。Flash
図12に示したのは、不正なFlashダウンローダのActionScriptコードです。システムにインストールされている Flash Playerのバージョン番号が、getUrl()関数の入力（変数v）に指定されています。このコードは、特定のドメインに 対してGETリクエストを行い、特定バージョンのFlashに含まれる脆弱性を悪用する不正ファイルf.swfをダウンロード します。図12：バージョン・チェックを行う不正なFlashダウンローダ
サンドボックスにこのバージョンのFlashがインストールされていない場合、不正なFlashファイルはダウンロードされ ないため、このダウンローダがサンドボックスによって検知されることはありません。
GIF
やFlashファイルに埋め込まれたiframe
多くのマルウェアは、一見無害なファイルを利用してセキュリティ対策をすり抜け、不正なペイロードをダウンロード しようとします。典型的な手口は、GIF画像やAcrobat Flashファイルなど実行可能形式ではないファイルにHTMLの iframe要素を埋め込むというものです。 GIFやFlashファイル自体は実行されないため、サンドボックス内で疑わしい振る舞いを示すことはありません。しかし、 物理的なコンピュータに侵入してこのファイルを待機していた別のファイルによって、内部に隠し持ったデータが実行 されます。GIF
GIF形式の画像ファイルは、次の要素で構成されています。 • ヘッダー • 画像データ • メタデータ（オプション） • フッター（トレイラーとも呼ばれる） フッターは1つのフィールドからなるブロックで、GIFデータ・ストリームの終端を示します。通常は、0x3Bという決まった 値が使用されます。多くの不正なGIFファイルでは、フッターの後にiframeタグが追加されています（図14）。 図14：GIFファイルに埋め込まれた不正なiframeタグFlash
GIFファイルと同様、Flashファイルにも不正なWebサイトへのiframeリンクが埋め込まれているケースがあります。 図15に示したのは、不正なiframe要素が埋め込まれたFlashファイルのコードです。 FlashはHTMLのレンダリング・エンジンではないため、Flashファイルをサンドボックスで開いても、埋め込まれた iframeは何もしません。そのため、GIFファイルの場合と同様、このファイルは検知されません。 図15：Flashファイルに埋め込まれた不正なiframeタグDLL
ローダーのチェック
通常、ダイナミック・リンク・ライブラリ（DLL）ファイルを実行する際には、run32dll.exeを使用するか、実行元の プロセスで対象のDLLを読み込みます。しかしマルウェアの中には、DLLの実行に特定のローダーが必要となる別の プロセスを使用するタイプがあります。このローダーが存在しない場合、DLLは実行されないため、サンドボックスで 検知されることはありません。 図16のマルウェア・コードは、特定のローダーであるかどうかを確認するため、ローダーのハッシュを計算します。 図16：ローダーのハッシュを計算するマルウェア・コードVMware
によるサンドボックスの回避手法
ここまで解説してきたサンドボックスの回避手法は、主に高度なマルウェアやAPTで使用されているテクニックです。 しかし、FireEyeが収集しているデータによると、古典的な回避手法も依然として広く使用され、有効に機能しています11。 特に、主要な仮想化ソフトウェアであるVMwareを利用したサンドボックスは、その固有の構成を手がかりにして容 易に回避することができます。システム・サービスのリスト
一部のマルウェアは、実行環境がVMwareによるサンドボックスであるかどうかを確認するため、VMwareに関連する サービスの有無をチェックします。VMwareに固有のサービスには、vmicheatbeat、vmci、vmdebug、vmmouse、 vmscis、VMTools、vmware、vmx86、vmhgfs、vmxnetなどがあります。図17に示したコードは、関数RegOpenKeyExA()を使用して、VMwareの仮想マシンに関連するサービスをチェック しています。関数RegOpenKeyExA()の実行が成功した場合、ゼロ以外のエラー・コードが返されます。 図17：関数RegOpenKeyExA()を使用して、VMware関連のサービスをチェック するマルウェア・コード
VMware
固有のファイル
マルウェア・コードの実行環境がVMwareによるサンドボックスかどうかを確認するために利用できるもう1つの手がかりは、 VMwareに固有のファイルの存在です。図18に示したのは、関数GetFileAttributeA()を使用してVMwareのマウス・ ドライバの有無を確認するマルウェア・コードです。 図18：関数GetFileAttributeA()を使用して、VMwareのマウス・ドライバの有無を 確認するマルウェア・コード 関数GetFileAttributeA()は、指定されたファイルまたはディレクトリのシステム属性を取得します。この関数が呼び 出されると、cmp eax、0FFFFFFFhというコードによって、戻り値が-1であるかどうかが確認されます。この値は、 vmmouse.sysというファイルがシステム上に存在せず、その属性を取得できなかったこと、つまりコードの実行環境 がVMware環境ではないことを意味しています。VMX
通信ポート
VMwareが仮想マシンとの通信に使用するVMXポートも、実行環境がVMwareによるサンドボックスであることを示す 明確な手がかりになります。このポートが見つかった場合、マルウェアは「死んだふり」をして検知を免れようとします。 図19は、このポートの有無を確認するマルウェア・コードです。 図19：I/Oポートを手がかりにVMwareを検知するマルウェア・コード このコードは次の手順で動作します。1. 命令move eax, 'VMXh'によって、値0x564D5868がEAXレジスタに読み込まれます。 2. 任意の値とともにEBXが読み込まれます。
3. ECXが0Ahに設定されます。これにより、VMwareのバージョンが取得されます。
4. レジスタDXがポートVXに設定されます。これにより、VMwareとのインタフェースが確立されます。
5. 命令in eax, dxが呼び出され、ポートからEAXへの読み込みが行われます。コードの実行環境がVMwareによる サンドボックスである場合は呼び出しが成功し、マルウェアは検知を免れるため動作を停止します。
一般公開されているサンドボックスの比較
表1は、マルウェアの検知にファイルベースのサンドボックスを使用している、主要な無料オンライン・マルウェア解析 サービス3種を比較したものです。程度の差はありますが、いずれのサービスもサンドボックス回避手法を利用する マルウェアをある程度検知できています。ただし、すべての回避手法に対応できたサービスはなく、またバージョン・ チェックと埋め込みiframeに対応できたサービスは皆無でした（FireEye Multi-Vector Virtual ExecutionTM（MVX）、 静的チェック、コールバック監視の組み合わせでは、この両手法を採用したマルウェアも検知できています）。 ユーザーの操作 Flash/JPG ファイルに 埋め込まれた iframe スリープAPIの 呼び出し バージョン・ チェック 固有のプロセスVMwareに 通信ポートの チェック サンドボックス1 × × ○ × ○ ○ サンドボックス2 フックは検知し たものの、不正な 振る舞いは検知 できず × ○ × ○ ○ サンドボックス3 ○ × ○ × ○ ○ 表1：オンライン・マルウェア解析サービス3種のサンドボックス回避手法への対応状況
まとめ
ファイルベースのサンドボックスは、高度なマルウェアを検知する特効薬ではありません。確かに仮想環境は、ファイル の振る舞いを安全に観察できる有用なツールですが、あくまでも1つのツールに過ぎません。マルウェアは、多くの セキュリティ・ベンダーが採用している既製のサンドボックスで実行されていることを容易に見抜き、不正な活動を抑制 します。 最新の高度なマルウェアを検知するには、1つのツールだけに頼らない包括的な脅威対策アプローチが必要です。 仮想マシン環境の位置付けは、あくまでも、マルチフロー解析によって攻撃のコンテキストを解析する総合プラットフォーム の一部でなければなりません。振る舞い解析と静的解析を組み合わせるとともに、複合的な攻撃を構成する個々の要素 の関係性を詳しく把握することで、従来型のセキュリティ対策に欠けている要素を補うことができます。 一般的なサンドボックス技術では検知できないマルウェアにも対応するFireEye MVXエンジンの詳細については、 http://www.fireeye.co.jp/products-and-solutions/virtual-execution-engine.html をご覧ください。© 2013 FireEye, Inc. All rights reserved. FireEyeはFireEye, Inc.の商標です。本資料のその他のブランド名、製品またはサービス名はそれぞれの 所有者の商標またはサービスマークとして登録されている場合があります。 – RPT.HKTB.JA.082013 FireEyeについて FireEye®は、次世代のサイバー攻撃をリアルタイムで防御するために専用設計された、仮想マシンベースのセキュリティ・ プラットフォームを提供するリーディング・カンパニーです。FireEyeのソリューションは、世界中の民間企業や官公庁 に導入されています。高度なサイバー攻撃は、次世代ファイアウォールやIPS、アンチウイルス、各種ゲートウェイ など、多くのネットワークに導入されているシグネチャベースのセキュリティ対策を容易にすり抜けてしまいます。 FireEyeプラットフォームは、シグネチャを利用することなくリアルタイムかつダイナミックに脅威を防御でき、正確性 やネットワーク・パフォーマンスにも優れています。FireEyeプラットフォームの核となる仮想実行エンジンは、Web、 電子メール、ファイル・システムという3つの主要な攻撃経路にわたって情報資産を保護します。FireEyeのソリューションは、 2012年12月31日時点で世界40か国以上の900を超える組織に導入されており、Fortune 500企業の100社以上で利用 されています。 詳細な情報は http://www.fireeye.co.jp をご参照ください。
