検出ロジックは、最新のエンドポイント保護ソフトウェアにおけるさまざまなメカニズムによって使用されている。また、サイバーセキュリティ業界では、多くの別の名前でも知られている。セキュリティ業界で「マルウェア」と呼んでいるものが、一般には、「ウイルス」という言葉で呼ばれている（技術的に言えば、「ウイルス」とは、別のプログラム、データファイル、またはブートセクタに自身のコピーを作成することによって拡散するプログラムを指す）のと同様に、検出ロジックは、「シグネチャ」から「フィンガープリント」、「パターン」、「IOC(英文)」まで、さまざまな呼び方をされてきた。誰かがウイルスの話をしていると思ったら、本当はマルウェアについての話だったということがよくある。そして、誰かがシグニチャの話をしていると思ったら、実は検出ロジックについての話だったということもたびたびある。もっとも、80年代や90年代に用いられたシンプルな検出ロジックが話題になっていたのだとしたら、話は別なのだが。
当社、エフセキュアでは、「detection logic（検出ロジック）」のことを、単に「detections（検出）」と言うこともよくある。
このシリーズの以前の記事で、スキャンエンジン(英文)、ビヘイビアエンジン(英文)、およびネットワークレピュテーションについて記した。そして、それらがどのように連携して悪意のある脅威をブロックするのかについて説明した。ここでは、それらのエンジンによって使用されている検出ロジックがどのようなものなのか、そして、それらはどのように作成されるのかについて説明しようと思う。
少し長い記事になるが、お付き合いいただきたい。わかりやすく詳細に説明するには、かなり多くの異なる領域をカバーする必要が生じるようだ。これらの別々の機能の間には多くの接点があり、それゆえに、何本もの記事を別々に投稿するのではなく、長い1本の記事で投稿することにした。この記事の草稿を多くの仲間に読んでもらおうとしたが、何人かは夏休みに入ってしまっており、このような内容をつまびらかにしても問題ないかどうか、多少、心配が残る。
最新のセキュリティ製品には、多くの異なるタイプの検出ロジックがある。それぞれのセクションで1つずつ説明していく。
あれは何だったか？そうだ、複雑な数学に人工知能だ。
クラウドベースの検出ロジック
最新の保護ソフトウェアには、インターネットを介して問い合わせを行う1つまたは複数のクライアントコンポーネントが備えられていることが多い。検出ロジックはクライアントとサーバとの間でしばしば共有される。非常にシンプルな例では、ユニークなオブジェクト識別子（その暗号学的ハッシュなど）がサーバに送られ、good（安全）/bad（危険）/unknown（不明）という簡単な判定が送り返され、クライアントはその結果を考慮に入れて最終的な意思決定を行う。
複雑な例では、クライアントがオブジェクトから一連のメタデータを抽出し、それをサーバに送る。サーバは一連の独自ルールを適用し、判定を返すか、または、判定に到る前にクライアントが処理する新たな値のセットを返す。
クラウド参照の最もシンプルなものでさえも、非常に強力である。バックエンドシステムは、当社の顧客ベース全体から取得した情報およびメタデータだけでなく、当社のすべてのサンプルストレージシステムへアクセスできる。こうした追加情報は、エンドポイント単独ではアクセスできないものである。クラウドへの問い合わせを行うことにより、こうしたメタデータはクライアントへ提供され、システム上のさまざまな保護技術すべてで利用可能になる。疑わしさを判定するために拡散状況のスコアを利用するというのが、このよい例である。
クラウドベースの検出ロジックは、たいていは自動的に生成される。そのため、サンプル発見から保護までのレスポンスタイムはきわめて速い。サンプル検出の所要時間は、秒または分単位である。
このセクションで、クラウドスキャンについても触れておかないといけない。エンドポイントからクラウドへサンプルをアップロードして、クライアントサイドでは不可能な複雑な分析処理を行うことができる。分析手順としては、複数のスキャンエンジンでのサンプルのスキャン、静的分析、および動的分析などの手順がある。バックエンドの検出ロジックは、これらの分析により生成されたメタデータを処理することによって判定を配信するよう設計されている。この点については、バックエンド検出ロジックのセクションで詳しく説明する。
ヒューリスティック検出ロジック
ヒューリスティック検出ロジックは、疑わしさを判定するために、悪意のあるファイルに典型的に見られるパターンを探すように設計されている。ヒューリスティック検出ロジックは、機械学習の手法によって、または手動で生成できる。
手動で生成されるヒューリスティック検出ロジックの例としては、スクリプトに何回、「+」の文字が出てくるかを調べるというものがある。これは、よくあるスクリプト難読化の手法をチェックするものだ。より複雑な手動生成のヒューリスティック検出ロジックには、複数のパターンを検索するものもある。疑わしさのスコアは、通常、それらのパターンがあるかどうか、ある場合はそれらの種類を基にして算出され、その後、他のメタデータと組み合わされて、最終的な判定に到る。
クリーンなファイルではなく、悪意のあるファイルの中によく見られる構造的なパターンを識別するように機械学習システムをトレーニングすることにより、複雑なヒューリスティックロジックの構築が可能になる。これは、専門家が調査済みの悪意のあるファイルとクリーンなファイルの大量のセットを機械学習システムに入力し、出力を徹底的にテストすることによって実現される。結果として生成された検出ロジックが、効率が良く、誤検出なし、見逃しなしであれば、エンドポイントへデプロイされる。こうしたプロセスは、脅威のランドスケープの変化に適応するために定期的に繰り返される。さらに、これらの検出ロジックは、サンプルに見られる特徴およびパターンを探し、一連の数理モデルを適用して疑わしさのレベルを算出することによって機能する。
PEファイルの構造に含まれる情報が、ファイルの疑わしさの判定に用いられることがある
ヒューリスティック検出ロジックの質は、どれくらい入念にトレーニングされているかによるところが大きい。そしてその質は、トレーニングやテストの段階で用いられたサンプルの質によるところが大きく、サンプルの質は、オートメーションと人間の操作の組み合わせによるところが大きい。正しくプロセスを動かすのに十分な専門知識、時間、および資源があれば、大きな成果が挙げられる。
ビヘイビアルール
コードの実行をビヘイビア（振る舞い）の点から分析するエンジンには、観察されたビヘイビアのパターンが疑わしいか悪意のあるものであるかどうかを判定するように設計された一連のルールが備えられている。
一部のビヘイビアルールは、自動で作成できる。また、手作業で綿密に作成されるものもある。新たなエクスプロイトの手法や攻撃ベクトルを調査することにより、ビヘイビアルールは、マルウェアに新たな手法が広まる前に作成することが可能だ。また、汎用的なビヘイビアルールを、あらゆる種類の悪意のある活動を捕捉するように設計することもでき、そうすることにより、先回りをすることが可能になる。当社のラボの研究員は、マルウェアのランドスケープにおける将来のトレンドに、常に目を光らせている(英文)。新たな手法を確認すると、彼らはそのリサーチ結果を基にして新たなルールの作成に着手する。
では、ビヘイビアルールはどのように機能するのだろうか。何かが実行されると（実行ファイルの実行、それぞれのリーダーでのドキュメントのオープンなど）、システム内のさまざまなフックにより実行の痕跡(英文)が生成される。この痕跡は、一定のイベントシーケンスによってトリガーされるよう設計されている検出ルーチンに渡される。ビヘイビアルールがチェックするイベントの種類には、以下のものがある。
- プロセスの作成、破棄、または中断
- コード挿入の試み
- ファイルシステム操作
- レジストリ操作
ビヘイビアルールに渡される各イベントには、そのイベントに関連のある有用な一連のメタデータが含まれる。また、実行の痕跡についてのグローバルなメタデータ（これにはPIDのようなものが含まれる）、ファイルパス、および親プロセスも、ルールで利用可能になる。クラウドへの問い合わせや他の保護コンポーネントから取得されたメタデータも利用可能になる。これには、拡散状況のスコアやファイルオリジントラッキング（ファイルがシステム上に現れた時点以降のファイルの履歴で、ダウンロード元のURLなどが含まれることがある）などが含まれる。ご想像の通り、こうした情報すべてが手元にあれば、かなり独創的なロジックの構築が可能だ。
もちろん当社では、脅威のランドスケープが変化するのに合わせて、そして機能強化を行うたびに、常に当社の検知コンポーネントのロジックおよび機能のアップデートを行っている。言うまでもないことではあるが。
ジェネリック検知ロジック
エンドポイントで実行されるように設計された複雑なプログラムを作成することにより、マルウェア検出のためのリバースエンジニアリングの手法をある程度自動化できるようになっている。ここから佳境に入るが、多少、説明が長くなるかもしれない。
悪意のあるコードを含む可能性のあるファイルの種類には、さまざまなものがある。以下にその例を示す。
- PDFまたはMS Office形式などのドキュメント
- PE、ELF、Mach-O、dotnetなどの、各種OSおよびアーキテクチャ用の実行ファイル
- APK、OS Xアプリケーションバンドル（.app）、Flash(英文)（SWF）などの、アプリケーションパッケージおよびバンドル
- ISOおよびDMG(英文)などのディスクイメージ
- Java classまたはAndroid dexなどの、コンパイル済みバイトコード
- html またはxmlなどのマークアップ
- Visual Basic、JavaScript、OS固有のシェルスクリプトなどのスクリプト
- zip、7z、およびRARなどのコンテナ
このようにさまざまなファイル形式のすべてを扱うためには、パーサが必要となることがたびたびある。パーサは、有用な埋め込まれた構造を識別し、それぞれのコンテナからそれらを抽出する。埋め込まれた構造の例としては、リソース（サウンド、グラフィックス、ビデオ、およびデータ）、PEヘッダ、PEセクション、Authenticode署名(英文)、Androidマニフェスト、およびコンパイル済みコードなどがある。
簡単に言えば、パーサは入力ファイルをその構成要素に分解し、検出ロジックがアクセスしやすいデータ構造としてそれらを提供してくれる。ファイル形式の多くは複雑なものになっており、多くのコーナーケースを含んでいる。ファイルを解析してデータ構造を検出ロジックに提供することにより、複雑な解析コードの複製を何度も繰り返さずに済む。また、コードが堅牢で効果的であることを確認することもできる。
ファイル（種類はさまざま）が悪意のあるファイル内に埋め込まれることはよくある。たとえば、悪意のあるPDFに、flashのコード、実行ファイルのコード、シェルコード、またはスクリプトが埋め込まれているかもしれない。そのような埋め込まれたファイルは、暗号化または難読化されていることが多い。そのため、一番外側の悪意のあるファイルが開かれ、実行されると、その中にあるオブジェクトが復号され、メモリまたはディスクへ書き込まれて実行される。
悪意のある実行ファイルそのものは、コードおよび構造を難読化するために、UPXやASPackなどの既製のパッカーまたはプロテクターを使用している。ほとんどの場合、複数のパッカーが重なり合って適用されており、マルウェア作者によってカスタマイズされた難読化が施されているケースも多い。悪意のある実行ファイル内にある実際のコードにたどり着こうとすることは、タマネギの皮をむくことに似ている。
パックされたファイルについて厄介なのは、どれも同じように見える点である。また、悪意のない実行ファイルでもパッカーを使用している場合がある。悪意のあるものかどうかを適切に識別するには、そのような層を除去することが必要になることがよくある。
既製のパッカーの除去は、比較的簡単に行える。標準的なプロテクターを識別することは簡単である。それらを復号する方法と同様だ。カスタマイズされた難読化をアンパックすることはより厄介である。カスタマイズされた難読化を解除する方法の1つは、マルウェア本体から復号コードおよびデータブロックを抽出し、サンドボックスで全体を実行して、マルウェア自身のコードにイメージをアンパックさせるというものである。よく用いられる別の方法は、マルウェアの難読化解除コードの逆アセンブリを分析し、対象となる暗号鍵およびデータの位置を抽出してイメージを抽出するルーチンを記述する方法である。
悪意のある実行ファイルの防御層をすべて剥ぎ取ることで、検出ロジックは、奥深くに隠れているマルウェアコード本体を解析できるようになる。ここから先は、結果として生じたイメージを、それ以上どのように処理するかについて制約はない。PDFやMS Officeドキュメントなどの非PEファイルからオブジェクトを取り出すのにも、同じ手法が用いられる。また、同じような復号トリックを用いることで、悪意のあるJavaScriptなどの難読化解除を行うことも可能だ。
このような検出ロジックを作成するのには、多大な時間が必要になりがちだ。だが、それによって得られるものは、相応の価値があるものであることは間違いない。そのようにして記述されたジェネリック検出ロジックは、悪意のあるファイルを数多く捕捉できるというだけでなく、有効に機能し続ける期間が長い。多くの場合、同一のマルウェアファミリーの新たな亜種は、何も修正しなくても、1つのうまく記述されたジェネリック検出ロジックで検出される。当社の世界地図(英文)を見てみれば、当社のトップ10の検出ロジックのうち、すべてではないにしてもそのほとんどは、手作業で記述されたジェネリックであることに気付くことだろう。
正直なところ、ここに記してきたことは、これらの技術で行うことができ、実際に行われていることについて、表面をさらっとなでているに過ぎない。検出ロジックは、クラウドへの問い合わせやファイルオリジントラッキングのようなものからの情報へもアクセスでき、また、メモリスペースや受信ネットワークデータなどを含む、あらゆる種類のデータストリームについても扱うことができることを心に留めておいてほしい。そうすれば、このトピックがなぜそれほど複雑になるのかご理解いただけるだろう。深く掘り下げて説明するとすれば、本が1冊、出来上がるかもしれない。
ネットワーク検出ロジック
エクスプロイトキットなど、ネットワーク上での攻撃をブロックすることは、当社が大いに重点を置いている分野である。攻撃の連鎖における早い時点で脅威を止めることは、マシンの感染を防ぐ効果的な方法である。
前セクションで述べたように、ネットワーク経由で届いたデータストリームは、ディスク上のファイルの検査と同様の方法で分析することができる。ただし、ネットワークの場合、情報の到着と同時に、さらなる攻撃ベクトルへのアクセスをその場でブロックまたはフィルタリングするためのメカニズムが加わる。
エンドポイントにおけるネットワーク検出ロジックは、IPアドレス、URL、DNSクエリ、TLS証明書、HTTPヘッダ、HTTPコンテンツ、および他のメタデータのすべてのホストへアクセスする。また、クラウドへの問い合わせを介して、URL、証明書、IPレピュテーションを含む、ネットワークレピュテーション情報へもアクセスする。こうした情報すべてにアクセスできると、興味深いことをいくつか行うことができる。以下はその例だ。
- ウェブサイトのビヘイビアをリアルタイムで調査でき、エクスプロイトキットの検出およびブロックを行える
- IPアドレスの問い合わせ中に、またはボットが接触しようとしているIPを基にして、ボットとコマンド＆コントロール（C&C）サーバ間の通信をブロックできる。また、ネットワークトラフィックのパターンを基にしてC&C通信をブロックすることもできる
- HTTPヘッダ、ボディおよびその両方の内容を基にしてフィッシングサイトをブロックできる
- flashリダイレクションを含む、多種多様な悪意のあるリダイレクションをブロックできる
ネットワークレベルのインターセプション技術により、システムに届いたオブジェクトについてのメタデータを抽出および保管することが可能となる。そうしたメタデータはシステム上の他の保護コンポーネントで利用可能になり、意思決定のプロセスで考慮に入れられる。
メモリ検出ロジック
アクティブなメモリ内で悪意のあるコードの兆候を探すことは、有用な手法である。特に、以前に保護されていなかったシステムへインストールを行う際は有効である。ある種のマルウェア、特にルートキットは、こうした手法でのみ検出可能だ。
一部のマルウェアは、システムへのエンドポイント保護ソフトウェアのインストールを、がっちりと阻止しようとする。そのため、インストーラを実行する前に、システムをクリーニングしておくことは重要な手順と言える。当社製品のインストールの場合は、過去に発生した可能性のあるあらゆる感染を除去するために、インストール手順の早い段階で、メモリスキャン機能を含むフォレンジクスルーチンを実行する。何も当社の保護層をすり抜けないようにするために、これと同じフォレンジクスルーチンを、システム上で定期的に、または手動で実行できるようになっている。
前述の通り、難読化の層をかいくぐっていく作業は、ときに煩雑な作業である。マルウェアが使用しているアドレス空間に目を向けることで、難読化が解除されたイメージを見つけられることもよくある。ただし、いつもそうできるわけではない。既製のパッカーは通常プログラムをメモリへダンプするが、悪意のあるプログラムがカスタマイズされた難読化ツールを使用している場合は、メモリ内でさえ、難読化されたままにするために用いることのできるさまざまなトリックが存在する。これを行う簡単な方法としては、文字列を難読化することだろう。より複雑なケースとしては、コードを、カスタムな仮想マシンの下で実行される、プロプライエタリな、1回限りの、コンパイル時に生成される命令セットへ変換するものもある。
バックエンドの検出ロジック
当社のバックエンドシステムでは、膨大な量の処理能力を活用できるため、エンドポイントでは不可能な、費用も時間もかかるタイプのサンプルの検査を実施することができる。一連の分析ステップを実行し、そうした処理の出力と、クライアントの問い合わせやサンプルストレージシステムから収集されたメタデータとを組み合わせることにより、手動では不可能なほどの大量のサンプルを自動的に処理し、分類できる。大量の卓越したスレットインテリジェンス（脅威対策の知見）(英文)も、こうしたプロセスを通じて導き出すことができる。
当社のエンドポイント製品で用いられているのと同じ技術のいくつかが、厳密な静的分析手順を実行するためにも利用されている。これは、単に判定を配信するだけでなく、サンプルのメタデータおよび特徴を抽出するように設計された特殊な検出コードを記述することによって実現される。これはサンプルの分析に使用する1つの方法にすぎない。また、特定の種類のファイルを処理するように設計された他のシステムは、関連のあるメタデータを当社の意思決定ロジックに提供する。さらに当社では、構造的特徴に基づいてヒューリスティックに、疑わしさを判定するように設計されたシステムを用いてサンプルを処理している。
ClassyおよびGemmyという、2つのマルウェア識別オートメーションコンポーネントは、約5年前にアアルト大学との共同研究プロジェクトの一部として開発された。
実行可能なURLおよびサンプルは、動的分析のためにサンドボックス環境へ送られる。サンプルのビヘイビアの痕跡は、サンプルを実行する環境を設定することによって取得される。その痕跡からは、サンプルを分類するのに用いられる追加のメタデータが得られる。
こうした分析から、新たなサンプルが得られることがある。たとえば、悪意のあるサンプルが、コマンド＆コントロールサーバへ接続しようとするかもしれない。そのような振る舞いが観察されると、サーバのアドレスがシステムへフィードバックされて分析される。別の例としては、これは以前に述べたものだが、一部のマルウェアがどのようにして埋め込まれたペイロードをドロップするかに関するものだ。ドロップが発生すると、ドロップされたサンプルはシステムへフィードバックされる。そういうことから、最初の悪意のあるペイロードに対してだけでなく、攻撃の連鎖のうち、後続の部分に対応する検出ロジックも備えられていることがお分かりいただけるだろう。
当社の製品はクラウドへ問い合わせを行うため、当社の顧客ベース全体に渡るメタデータの収集が可能だ。こうしたメタデータは、サンプルの疑わしさの判定に利用できる。たとえば、サンプルの拡散状況は、それが悪意のあるものかどうかについて判断するヒントを与えてくれることがある。
1つのファイルまたはURLを完全に処理し終えたら、収集されたすべてのメタデータがSample Management Automation（SMA）というルールエンジンに渡される。このシステムにおけるルールは、一部は手書きされ、一部は脅威の環境の変化に応じて修正される。このシステムは当社のオペレーション全体の中枢部である。当社のストレージシステムにおけるサンプルの分類およびタグ付けから、脅威の判定や新たな脅威の警告までのすべてを行うシステムである。
ベータ検出ロジック
適切なテストなしには、よいソフトウェアは作れない。当社の研究員はときに、マルウェアを検出する独創的な方法を思いつくことがあるが、それらが現実世界でどのように機能するかは未知数である。たとえば、新たなタイプの検出手法は、アグレッシブ過ぎて多くの誤検出を生み出してしまう結果に終わるかもしれないが、それが流行するまでは、それは本当にはわからない。このようなケースでは、我々はベータ検出ロジックを使用する。
ベータ検出は、製品またはシステムにおいて実際には何もアクションをトリガーすることなく、何を行おうとしたかを報告する。これらのコードからアップストリームデータを収集することにより、それらは最適に動作するよう調整され、意図した通りに動作するようになったらリリースされることもある。
ベータ検出ロジックは、かなり最先端を行くものであることが多い。多くの場合、それらは、すでに捕捉している脅威に対処するように設計された新たな技術であり、これまでとは別の、より効果的な方法を取り入れたものである。当社では、手書きの検出ロジックをデプロイするたびに、それらを使ってできるだけ多くの実際のサンプルを捕捉しようと常に努めているため、ベータ検出ロジックは、その方面における新たな理論のための素晴らしいテストベッドも提供してくれると言える。ベータ検出ロジックは当社のバックエンドとエンドポイントの両方で活用されている。
結論
ご推察の通り、検出ロジックは多くの形態があり、非常に多くのさまざまなことを行うのに使用されている。これらのさまざまな検出手法すべての背後にある技術は、広範囲に渡るさまざまな攻撃ベクトルからマシンやユーザを保護するために連携して機能するように設計されている。システム全体は、かなり複雑だが、非常に強力でもある。脅威のランドスケープの変化に合わせて、当社ではこれらの技術および方法論を常に進化させている。一つにすべてを賭けるのではなく、複数の異なる保護層を重ねて使用することにより、攻撃者が当社の技術スタックをすり抜けることを難しくしている。そのため、今度、最新のエンドポイント保護製品の話の流れで、誰かが「シグネチャ」について話しているのを耳にすることがあったら、その人はあまり詳しくないか、作り話を広めようとしているのだと思ってよいかもしれない。
追伸 ご心配いただいているかもしれないが、記事の最初のほうで、こうした情報を開示しても大丈夫かどうかわからない、と述べたのは冗談だ。この解説シリーズに対しては、素晴らしいフィードバックを数多くいただいており、当社の技術プロセスについて、すべての人に対してオープンにお話しできることは何よりの喜びである。
カテゴリ