特表 2025-502604 「アンマネージＩＭＰＨＡＳＨ」を有する．ＮＥＴマルウェアの識別

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2025-01-28

(54)【発明の名称】「アンマネージＩＭＰＨＡＳＨ」を有する．ＮＥＴマルウェアの識別

(51)【国際特許分類】

   G06F 21/56 20130101AFI20250121BHJP

【ＦＩ】

G06F21/56 320

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024529898

(86)(22)【出願日】2022-12-05

(85)【翻訳文提出日】2024-07-19

(86)【国際出願番号】 US2022051866

(87)【国際公開番号】W WO2023121862

(87)【国際公開日】2023-06-29

(31)【優先権主張番号】17/557,992

(32)【優先日】2021-12-21

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

(71)【出願人】

【識別番号】517392861

【氏名又は名称】パロ アルト ネットワークス，インコーポレイテッド

【氏名又は名称原語表記】Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．

【住所又は居所原語表記】３０００ Ｔａｎｎｅｒｙ Ｗａｙ，Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａ ９５０５４，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100229448

【弁理士】

【氏名又は名称】中槇 利明

(72)【発明者】

【氏名】サミュエル，ヤロン

(72)【発明者】

【氏名】レイチェル，ドミニク

(72)【発明者】

【氏名】ジュン，ロバート

(72)【発明者】

【氏名】チェ，ローレン

(57)【要約】

本出願は、悪意のあるファイルを検出するための方法、システム、および、コンピュータシステムを提供する。本方法は、．ＮＥＴファイルを含むサンプルを受信するステップと、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得するステップと、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定するステップと、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、サンプルがマルウェアであるか否かを決定するステップと、を含む。

【特許請求の範囲】

【請求項1】

１つ以上のプロセッサ、および、メモリを含む、システムであって、
前記１つ以上のプロセッサは、
．ＮＥＴファイルを含むサンプルを受信し、
前記．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得し、
アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定し、かつ、
前記アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定する、
ように構成されており、
前記メモリは、
前記１つ以上のプロセッサに結合されており、かつ、
前記１つ以上のプロセッサに命令を与えるように構成されている、
システム。

【請求項2】

前記インポートされたＡＰＩ関数名を取得することは、
前記．ＮＥＴファイルの前記．ＮＥＴヘッダを構文解析すること、および、
構文解析された．ＮＥＴヘッダから前記インポートされたＡＰＩ関数名を抽出すること、
を含む、請求項１に記載のシステム。

【請求項3】

前記インポートされたＡＰＩ関数名は、インデックステーブルに少なくとも部分的に基づいて、前記構文解析された．ＮＥＴヘッダから抽出される、
請求項２に記載のシステム。

【請求項4】

前記インデックステーブルは、前記．ＮＥＴファイルの実行に関連してインポートされる、アンマネージな方法のセットを示すＩｍｐｌＭａｐテーブルを含む、
請求項３に記載のシステム。

【請求項5】

前記インポートされたＡＰＩ関数名は、少なくとも部分的にＭｅｔｈｏｄＤｅｆテーブルに基づいて、前記構文解析された．ＮＥＴヘッダから抽出される、
請求項２に記載のシステム。

【請求項6】

前記アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定することは、
前記．ＮＥＴヘッダに少なくとも部分的に基づいて取得された、前記インポートされたＡＰＩ関数名に基づいて、アンマネージなインポートされたＡＰＩ関数のセットを決定すること、および、
既定のハッシュ関数に少なくとも部分的に基づいて、前記アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを生成すること、
を含む、請求項１に記載のシステム。

【請求項7】

前記既定のハッシュ関数は、ＳＨＡ－２５６ハッシュアルゴリズム、ＭＤ５ハッシュアルゴリズム、および、ＳＨＡ－１ハッシュアルゴリズムのうちの少なくとも１つを含む、
請求項６に記載のシステム。

【請求項8】

前記１つ以上のプロセッサは、
前記サンプルが悪意のあるものであるという指示をセキュリティエンティティに対して送信する、
ように構成されている、
請求項１に記載のシステム。

【請求項9】

前記サンプルが悪意のあるものであるという指示をセキュリティエンティティに送信することは、
悪意があると見なされるファイルのブラックリストを更新することであり、前記ファイルのブラックリストは、前記サンプルに対応している識別子を含むように更新されること、
を含む、請求項８に記載のシステム。

【請求項10】

前記セキュリティエンティティは、ファイアウォールに対応している、
請求項８に記載のシステム。

【請求項11】

前記アンマネージなインポートされたＡＰＩ関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定することは、サンドボックス環境において実行される、
請求項１に記載のシステム。

【請求項12】

前記アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定することは、セキュリティエンティティにおいて実行される、
請求項１に記載のシステム。

【請求項13】

前記インポートされたＡＰＩ関数名は、ＩｍｐｏｒｔＮａｍｅフィールドに対応している値に少なくとも部分的に基づいて取得される、
請求項１に記載のシステム。

【請求項14】

前記ＩｍｐｏｒｔＮａｍｅフィールドに対応している値が０に等しくないと決定したことに応答して、
前記インポートされたＡＰＩ関数名を取得することは、
前記．ＮＥＴファイルの＃Ｓｔｒｉｎｇｓストリームに少なくとも部分的に基づいて、１つ以上のライブラリ名のセットを決定すること、
を含む、請求項１３に記載のシステム。

【請求項15】

前記ＩｍｐｏｒｔＮａｍｅフィールドに対応している値が０に等しいと決定したことに応答して、
前記インポートされたアプリケーションプログラミングインターフェイス関数名を取得することは、
ＭｅｔｈｏｄＤｅｆテーブルの行から値を取得すること、
前記ＭｅｔｈｏｄＤｅｆテーブルの行からの前記値に少なくとも部分的に基づいて、＃Ｓｔｒｉｎｇｓストリームから関数名を取得すること、
前記．ＮＥＴファイルのＰＥヘッダがインポートテーブルを含むか否かを決定すること、および、
前記．ＮＥＴファイルのＰＥヘッダがインポートテーブルを含まないと決定したことに応答して、前記インポートテーブルに少なくとも部分的に基づいて、前記関数名に対応しているライブラリ名を決定すること、
を含む、請求項１３に記載のシステム。

【請求項16】

前記インポートテーブルに少なくとも部分的に基づいて、前記関数名に対応しているライブラリ名を決定することは、
前記対応している関数名から前記ライブラリ名を取得するために、前記インポートテーブルを構文解析することを含む、
請求項１５に記載のシステム。

【請求項17】

前記１つ以上のプロセッサは、さらに、
アンマネージ関数に対応しているライブラリ名がファイル拡張子を有していないことを保証し、
前記ライブラリ名および前記アンマネージ関数に少なくとも部分的に基づいて、文字列を決定し、かつ、
前記文字列を、前記アンマネージなインポートされたＡＰＩ関数名のリストに追加する、
ように構成されている、
請求項１に記載のシステム。

【請求項18】

前記文字列は、
前記ライブラリ名および前記アンマネージ関数の名前が大文字を含まないことを保証すること、および、
前記アンマネージ関数の名前と前記ライブラリ名との間に含まれる既定のセパレータを用いて、前記アンマネージ関数の名前を前記ライブラリ名に付加すること、
によって決定される、
請求項１７に記載のシステム。

【請求項19】

方法であって、
．ＮＥＴファイルを含むサンプルを受信するステップと、
前記．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得するステップと、
アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定するステップと、
前記アンマネージなインポートされたＡＰＩ関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定するステップと、
を含む、方法。

【請求項20】

非一時的コンピュータ可読記憶媒体に保管されたコンピュータプログラムであって、複数のコンピュータ命令を含み、
前記コンピュータ命令がプロセッサにより実行されると、コンピュータに、
．ＮＥＴファイルを含むサンプルを受信するステップと、
前記．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得するステップと、
アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定するステップと、
前記アンマネージなインポートされたＡＰＩ関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定するステップと、
を実施させる、コンピュータプログラム。

【発明の詳細な説明】

【背景技術】

【0001】

悪意のある個人は、様々な方法でコンピュータシステムを危険にさらす（ｃｏｍｐｒｏｍｉｓｅ）ように試みる。一つの例として、そうした個人は、悪意のあるソフトウェア（「マルウェア（“ｍａｌｗａｒｅ”）」）を電子メール添付ファイルに埋め込み、または、他の方法で含め、疑うことを知らないユーザに対してマルウェアを送信し、または、送信させ得る。実行されると、マルウェアは、被害者のコンピュータを危険にさらす。いくつかのタイプのマルウェアは、遠隔ホストと通信するように、危険にさらされたコンピュータに命令する。例えば、マルウェアは、危険にさらされたコンピュータを「ボットネット（“ｂｏｔｎｅｔ”）」における「ボット（“ｂｏｔ”）」へと変えることができ、悪意のある個人の制御下で、命令と制御（ｃｏｍｍａｎｄ ａｎｄ ｃｏｎｔｒｏｌ、Ｃ＆Ｃ）サーバから命令を受信し、かつ／あるいは、Ｃ＆Ｃサーバにデータを報告する。マルウェアによって引き起こされる損害を軽減する一つのアプローチは、セキュリティ会社（または、他の適切なエンティティ）が、マルウェアを識別し、かつ、エンドユーザコンピュータに到達すること／そこで実行されることを防止するように試みることである。別のアプローチは、危険にさらされたコンピュータがＣ＆Ｃサーバと通信することを防止するように努めることである。残念ながら、マルウェアの作者は、彼らのソフトウェアの仕組みを難読化するためにますます高度な技術を使用している。一つの例として、いくつかのタイプのマルウェアは、データを密かに抽出する（ｅｘｆｉｌｔｒａｔｅ）ためにドメインネームシステム（ＤＮＳ）クエリを使用する。従って、マルウェアを検出し、かつ、その害を防止するための改善された技法に対する継続的な必要性が存在している。

【図面の簡単な説明】

【0002】

本発明の様々な実施形態が、以下の詳細な説明および添付の図面において開示されている。

【図1】図１は、様々な実施形態に従った、悪意のあるファイルが検出され、または、疑われる環境に係るブロック図である。

【図2】図２は、様々な実施形態に従った、悪意のあるファイルを検出するためのシステムに係るブロック図である。

【図3A】図３Ａは、例示的な．ＮＥＴファイルについての．ＮＥＴヘッダに係るＩｍｐｌＭａｐテーブルの図である。

【図3B】図３Ｂは、例示的な．ＮＥＴファイルに係るＭｏｄｕｌｅＲｅｆテーブルの図である。

【図3C】図３Ｃは、例示的な．ＮＥＴファイルについての．ＮＥＴヘッダに係るＩｍｐｌＭａｐテーブルの図である。

【図3D】図３Ｄは、例示的な．ＮＥＴファイルについてのＭｅｔｈｏｄＤｅｆテーブルの図である。

【図3E】図３Ｅは、例示的な．ＮＥＴファイルについてのＭｏｄｕｌｅＲｅｆテーブルの図である。

【図3F】図３Ｆは、例示的な．ＮＥＴファイルについてのＩｍｐｏｒｔテーブルの図である。

【図3G】図３Ｇは、例示的な．ＮＥＴファイルについてのＭｅｔｈｏｄＤｅｆテーブルの図である。

【図4】図４は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図5】図５は、様々な実施形態に従った、ファイルが悪意のあるものか否かを決定するための方法に係るフローチャートである。

【図6】図６は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図7A】図７Ａは、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図7B】図７Ｂは、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図8】図８は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図9】図９は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図10】図１０は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【図11】図１１は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【発明を実施するための形態】

【0003】

本発明は、プロセス、装置、システム、組成物、コンピュータ可読記憶媒体上に具現化されたコンピュータプログラム製品、及び／又は、メモリ上に保管された命令、及び／又は、プロセッサに結合されたメモリにより保管され、かつ／あるいは、提供される命令を実行するように構成されたプロセッサといった、プロセッサを含む、多数の方法で実施することができる。本明細書において、これらの実装、または、本発明がとり得る任意の他の形態は、技法（ｔｅｃｈｎｉｑｕｅ）と称され得る。一般的に、開示されたプロセスのステップの順序は、本発明の範囲内で変更され得る。特に明記しない限り、タスクを実行するように構成されているものとして説明されるプロセッサまたはメモリといったコンポーネントは、所与の時間にタスクを実行するように一時的に構成される汎用コンポーネント、または、タスクを実行するように製造される特定のコンポーネントとして実装され得る。本明細書で使用されるように、「プロセッサ（“ｐｒｏｃｅｓｓｏｒ”）」という用語は、コンピュータプログラム命令といった、データを処理するように構成された１つ以上のデバイス、回路、及び／又は、処理コアを指す。

【0004】

本発明の１つ以上の実施形態の詳細な説明が、本発明の原理を示す添付の図面とともに、以下で提供されている。本発明は、そうした実施形態に関連して説明されるが、本発明は、いかなる実施形態にも限定されるものではない。本発明の範囲は、請求項によってのみ限定されるものであり、かつ、本発明は、多数の代替、修正、および均等物を包含する。本発明の完全な理解を提供するために、以下の説明において多数の具体的な詳細が記載されている。これらの詳細は、例示の目的で提供されるものであり、そして、本発明は、これらの具体的な詳細の一部または全部を伴わずに、特許請求の範囲に従って実施され得る。明確にするために、本発明に関連する技術分野で知られている技術的材料は、本発明が不必要に不明瞭にならないように、詳細には説明されていない。

【0005】

本明細書で使用される際に、セキュリティエンティティは、ネットワークトラフィック、ファイル、等といった情報に関して１つ以上のセキュリティポリシを実施するネットワークノード（例えば、デバイス）である。一つの例として、セキュリティエンティティは、ファイアウォールであり得る。別の例として、セキュリティエンティティは、ルータ、スイッチ、ＤＮＳリゾルバ、コンピュータ、タブレット、ラップトップ、スマートフォン、等として、実装され得る。別の例として、セキュリティは、アンチマルウェアアプリケーションといった、デバイス上で実行されるアプリケーションとして実装され得る。

【0006】

本明細書で使用される際に、マルウェアは、秘密にするか否か（および、違法であるか否か）にかかわらず、完全に通知された場合にユーザが承認しない／承認しないであろう挙動（ｂｅｈａｖｉｏｒ）に関与するアプリケーションを指す。マルウェアの例は、トロイの木馬、ウイルス、ルートキット、スパイウェア、ハッキングツール、キーロガー、等を含んでいる。マルウェアの一つの例は、エンドユーザの位置を収集し、そして、リモートサーバに報告するデスクトップアプリケーションである（しかし、マッピングサービスといった、位置ベースのサービスをユーザに提供しない）。マルウェアの別の例は、エンドユーザにはフリーゲームであるように見えるが、ＳＭＳプレミアムメッセージ（例えば、それぞれ１０ドルのコストがかかる）をひそかに（ｓｔｅａｌｔｈｉｌｙ）送信し、エンドユーザの電話料金を上昇させる、悪意のあるアンドロイド（登録商標）・アプリケーション・パッケージ（Ａｎｄｒｏｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｃｋａｇｅ）．ａｐｋ（ＡＰＫ）ファイルである。マルウェアの別の例は、ユーザの連絡先をひそかに収集し、そして、それらの連絡先をスパマー（ｓｐａｍｍｅｒ）に対して送信するＡｐｐｌｅ ｉＯＳフラッシュライトアプリケーションである。他の形態のマルウェアも、また、本明細書で説明される技術を使用して検出／阻止され得る（例えば、ランサムウェア）。さらに、マルウェア署名（ｍａｌｗａｒｅ ｓｉｇｎａｔｕｒｅ）は、悪意のあるアプリケーションのために生成されるものとして本明細書では説明されているが、本明細書で説明される技法は、また、他の種類のアプリケーションのためのプロファイル（例えば、アドウェア（ａｄｗａｒｅ）プロファイル、グッドウェア（ｇｏｏｄｗａｒｅ）プロファイル、等）を生成するために様々な実施形態においても使用され得る。

【0007】

本明細書で使用される際に、アンマネージコード（ｕｎｍａｎａｇｅｄ ｃｏｄｅ）またはアンマネージ関数（ｕｎｍａｎａｇｅｄ ｆｕｎｃｔｉｏｎ）は、「マネージコード（“ｍａｎａｇｅｄ ｃｏｄｅ”）」と呼ばれる通常の．ＮＥＴコード（．ＮＥＴ ｃｏｄｅ）とは対照的に、インポートされたｗｉｎ３２ ＡＰＩ関数を指す。一つの例として、そうしたアンマネージコードまたはアンマネージ関数は、一般的に、．ＮＥＴファイル（．ＮＥＴ ｆｉｌｅ）のＰＥヘッダに反映されず／含まれず、むしろ、そうしたアンマネージコードまたはアンマネージ関数は、．ＮＥＴファイルの．ＮＥＴヘッダを介してインポートされる。

【0008】

従来技術に従って、マルウェアは、機械学習モデルを使用して識別される。関連技術に従った機械学習モデルは、インポート、ヘッダ、セクションといった特徴に基づいて、ポータブル実行可能（ｐｏｒｔａｂｌｅ ｅｘｅｃｕｔａｂｌｅ、ＰＥ）構造を使用して訓練／開発される。機械学習モデルは、マルウェアと良性ファイルとの間を区別するために、そうしたインポート、ヘッダ、およびセクションを使用する。しかしながら、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＰＥインストーラベースのファイルのＰＥファイル構造は、悪意のあるファイルと良性ファイルとの間で極めて類似しているように見える。従って、マルウェアを検出するためにＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラについてＰＥファイル構造を使用することは、非常に信頼できるものではない。なぜなら、そうしたＰＥファイル構造に基づいて悪意のあるファイルと良性ファイルとを区別することは、極めて困難だからである。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラファイルについて悪意のあるファイルを検出するためにＰＥファイル構造を使用することは、より高い偽陽性（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ）および低い検出率を導く。良性の目的のために使用されるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラファイルの一つの例は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｎｕｌｌｓｏｆｔ Ｓｃｒｉｐｔａｂｌｅ Ｉｎｓｔａｌｌ Ｓｙｓｔｅｍ（ＮＳＩＳ）インストーラであり、これは、合法的な製品によって、および、企業環境において広く使用されている。悪意のあるＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラファイルと良性のＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラファイルとの間を区別するためにＰＥ構造を分析するように訓練された各機械学習モデルは、悪意のあるファイルを正確に検出することができない。

【0009】

悪意のあるファイルを検出するためのシステム、方法、及び／又は、デバイスが開示される。システムは、１つ以上のプロセッサ、および、１つ以上のプロセッサに結合され、かつ、１つ以上のプロセッサに命令を提供するように構成されたメモリ、を含んでいる。１つ以上のプロセッサは、．ＮＥＴファイルを含むサンプルを受信し、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいてインポートされたＡＰＩ関数名を取得し、アンマネージなインポートされた（ｕｎｍａｎａｇｅｄ ｉｍｐｏｒｔｅｄ）ＡＰＩ関数名のリストのハッシュを決定し、かつ、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、サンプルがマルウェアであるか否かを決定する、ように構成されている。

【0010】

様々な実施形態に従って、悪意のあるファイルを検出するためのシステムは、１つ以上のサーバによって実装される。１つ以上のサーバは、１つ以上の顧客及び／又はセキュリティエンティティにサービスを提供し得る。例えば、１つ以上のサーバは、悪意のあるファイルを検出し、または、ファイルが悪意のあるものか否かを決定／評価し、そして、ファイルが悪意のあるものか否かの指示（ｉｎｄｉｃａｔｉｏｎ）を１つ以上の顧客及び／又はセキュリティエンティティに提供する。１つ以上のサーバは、ファイルが悪意のあるものであると決定したことに応答して、かつ／あるいは、ファイルが悪意のあるものか否かの指示に対するファイルのマッピングの更新に関連して（例えば、悪意のあるファイルに関連付けられた識別子を含むブラックリストに対する更新）、ファイルが悪意のあるものであるという指示をセキュリティエンティティに提供する。別の例として、１つ以上のサーバは、ファイルが悪意のあるものか否かの評価のための顧客またはセキュリティからの要求に応答して、ファイルが悪意のあるものか否かを決定し、そして、１つ以上のサーバは、そうした決定の結果を提供する。

【0011】

様々な実施形態に従って、悪意のあるファイルを検出するためのシステムは、セキュリティエンティティによって実装される。例えば、悪意のあるファイルを検出するためのシステムは、ファイアウォールによって実装される。別の例として、悪意のあるファイルを検出するためのシステムは、デバイス（例えば、コンピュータ、ラップトップ、移動電話、等）上で実行されるアンチマルウェアアプリケーションといったアプリケーションによって実装される。様々な実施形態に従って、セキュリティエンティティは、．ＮＥＴファイルを受信し、．ＮＥＴファイルの．ＮＥＴヘッダを取得し、そして、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、．ＮＥＴファイルが悪意のあるものか否かを決定する。ＮＥＴファイルが悪意のあるものであると決定したことに応答して、セキュリティエンティティは、．ＮＥＴファイルに関して１つ以上のセキュリティエンティティを適用する。ＮＥＴファイルが悪意のあるものではないと決定したことに応答して（例えば、．ＮＥＴファイルが良性である）、セキュリティエンティティは、．ＮＥＴファイルを悪意のないトラフィックとして取り扱う。いくつかの実施形態において、セキュリティエンティティは、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を決定すること（例えば、取得すること）、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定すること（例えば、計算すること）、および、．ＮＥＴファイルに対応しているアンマネージなインポートされたＡＰＩ関数名のリストのハッシュが、悪意があると見なされるファイルに関連付けられたハッシュと一致するか否かを決定すること、に少なくとも部分的に基づいて、ファイルが悪意のあるものか否かを決定する。例えば、セキュリティエンティティは、ハッシュ（例えば、アンマネージなインポートされたＡＰＩ関数名のハッシュ）の悪意のあるファイルへのマッピングに関してルックアップを実行して、マッピングが一致するハッシュを含むか否かを決定する（例えば、マッピングが、．ＮＥＴファイルの計算されたハッシュに一致するアンマネージなインポートされたＡＰＩ関数名のハッシュを有するファイルのレコードを含むこと）。

【0012】

ポータブル実行可能（Ｐｏｒｔａｂｌｅ ｅｘｅｃｕｔａｂｌｅ、ＰＥ）ファイルは、様々なＯＳコンポーネントとインタラクションするために、しばしば、外部ライブラリから関数をインポートするようにコード化される。マルウェアを検出するための関連技術の方法は、インポートのシーケンスを使用し、ハッシュ値を取得するためにインポートのシーケンスをハッシュし、そして、ハッシュ値を「インポートテーブルハッシュ（“Ｉｍｐｏｒｔ Ｔａｂｌｅ Ｈａｓｈｅｓ”）」（ｉｍｐｈａｓｈ）の既知のブロックリストに対して比較する。マルウェアインポートを検出するための関連技術の方法は、分析されているファイルのＰＥヘッダから、インポートされたＡＰＩ関数名および対応しているライブラリ名を取得する。しかしながら、ＰＥヘッダからＡＰＩ関数名および対応しているライブラリ名を決定すること、並びに、マルウェアを検出するために、そうしたＡＰＩ関数名おび対応しているライブラリ名を使用することは、．ＮＥＴファイルにとって理想的ではない。なぜなら、ほぼ全ての．ＮＥＴ ＰＥファイルが、同様のインポートテーブルを有するからである。一つの例として、．ＮＥＴアセンブリの大部分は、ＰＥヘッダ内に「＿ＣｏｒＥｘｅＭａｉｎ」（ＥＸＥ）または「＿ＣｏｒＤｌｌＭａｉｎ」（ＤＬＬ）という名前の単一のインポート関数（ｉｍｐｏｒｔｅｄ ｆｕｎｃｔｉｏｎ）を有している。一般的に、．ＮＥＴアセンブリの少ない部分だけが、ＰＥヘッダ内により多くのインポートを有している。そうした．ＮＥＴファイルは、一般的に、Ｖｉｓｕａｌ Ｃ＋＋およびＣ＋＋／ＣＬＩ拡張子を用いて作成される。ＰＥヘッダ内に含まれるインポート関数は、一般的に．ＮＥＴコンパイラによって決定され、そして、コード自体によって影響されない。この現象は、．ＮＥＴコードがネイティブアセンブリ（ｎａｔｉｖｅ ａｓｓｅｍｂｌｙ）へとコンパイルされず、むしろ、次いで、．ＮＥＴランタイムによって実行される、中間言語または中間バイトコード（ＭＳＩＬ）へとコンパイルされるので、生じるものである。

【0013】

従って、．ＮＥＴファイルのＰＥヘッダから抽出されたインポート関数の使用は、マルウェアの正確な検出を提供しない。しかしながら、様々な．ＮＥＴマルウェアファミリは、依然として、例えば、他のプロセスにコードを注入するために、ｗｉｎ３２ ＡＰＩと直接的にインタラクションする必要がある。そうしたコードは、．ＮＥＴから他のプロセスへと注入され得るが、そうするためのｗｉｎ３２関数は、．ＮＥＴファイルについてのＰＥヘッダのインポートテーブルには反映されない。むしろ、コード注入関数は、一般的に、．ＮＥＴファイルの．ＮＥＴヘッダを介して含まれる（または、インポートされる）。ＮＥＴヘッダは、．ＮＥＴファイルに含まれるヘッダである（例えば、ＰＥヘッダに加えて）。例えば、．ＮＥＴヘッダは、．ＮＥＴファイルのＰＥヘッダとは異なり／違っている。ＮＥＴファイルは、ＰＥヘッダおよび．ＮＥＴヘッダの両方を含んでいる。ＮＥＴヘッダは、一般的に、．ＮＥＴアセンブリに関する様々な情報を含んでいる、データストリームおよびテーブルを含む。．ＮＥＴヘッダに含まれる１つのそうしたデータストリームは、「＃Ｓｔｒｉｎｇｓ」と名付けられ、そして、ファイル内で使用されるストリングのリストを含んでいる。＃Ｓｔｒｉｎｇｓストリームないに含まれるリストは、また、任意の使用されるアンマネージｗｉｎ３２ ＡＰＩ関数の名前も含む。さらに、．ＮＥＴヘッダ内に含まれるテーブルの１つは、「ＩｍｐｌＭａｐ」と名付けられ、そして、任意のインポートされたアンマネージ関数に関する様々な情報を含んでいる。

【0014】

様々な実施形態は、．ＮＥＴファイルの．ＮＥＴヘッダを構文解析（ｐａｒｓｅ）し、．ＮＥＴヘッダ内の１つ以上のフィールドからアンマネージインポート（ｕｎｍａｎａｇｅｄ ｉｍｐｏｒｔｓ）（例えば、アンマネージ関数、ライブラリ、等）を抽出し、そして、抽出されたアンマネージインポートに少なくとも部分的に基づいて、．ＮＥＴファイルが悪意のあるものか否かを決定する。いくつかの実施形態において、システムは、．ＮＥＴファイルに対応しているアンマネージインポートのリスト（例えば、．ＮＥＴヘッダ内のフィールドから抽出されたもの）を決定し、そして、アンマネージインポートのリストのハッシュを決定する（例えば、計算する）。アンマネージインポートのリストのハッシュは、既定のハッシュ関数に基づいて決定され得る。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含んでいる。様々な他のハッシュ関数が実装され得る。本明細書で使用されるように、アンマネージｉｍｐｈａｓｈは、アンマネージインポート（例えば、．ＮＥＴヘッダ内のフィールドから抽出されたアンマネージインポート）のリストのハッシュを決定することによって取得される値を指す。

【0015】

様々な実施形態に従って、．ＮＥＴファイルの．ＮＥＴヘッダに含まれる情報は、ファイルが悪意のあるものか否かを決定することに関連して使用される。いくつかの実施形態において、システムは、アンマネージ関数＜－＞ライブラリ名ペアのセットを決定するために、ＩｍｐｌＭａｐテーブルに含まれる情報、および、「＃Ｓｔｒｉｎｇｓ」データストリームの文字列に含まれる情報を使用する。システムは、．ＮＥＴファイルのアンマネージなインポート関数（例えば、．ＮＥＴヘッダを介してインポートされたもの）に関するリストを決定することができる。いくつかの実施形態において、システムは、．ＮＥＴファイルのアンマネージなインポート関数に関するリストのハッシュを決定する。例えば、システムは、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定する。アンマネージＩｍｐｈａｓｈは、ファイルが悪意のあるものか否かを決定するために使用され得る。例えば、システムは、リストが、．ＮＥＴファイルについて決定されたアンマネージＩｍｐｈａｓｈに一致するアンマネージＩｍｐｈａｓｈを有するレコードを含むか否かを決定するために、悪意があると見なされるファイルのリスト（例えば、ブラックリスト）をクエリすることができる。

【0016】

様々な実施形態に従って、システムは、サンドボックス（ｓａｎｄｂｏｘ）環境において．ＮＥＴファイルを分析する。例えば、システムは、．ＮＥＴファイルを構文解析し、そして、サンドボックス環境内の．ＮＥＴヘッダから情報を抽出する。システムは、サンドボックス環境で動作している仮想マシン（ＶＭ）によって実装され得る。

【0017】

いくつかの実施形態において、システムは、ＶｉｒｕｓＴｏｔａｌ（Ｒ）といったサードパーティサービスから、ファイルの悪意に関する履歴情報（例えば、悪意のあるファイルの履歴データセットおよび良性ファイルの履歴データセット）を受信する。サードパーティサービスは、悪意があると見なされるファイルのセット、および、良性と見なされるファイルのセットを提供し得る。一つの例として、サードパーティサービスは、ファイルを分析し、そして、ファイルが悪意のあるものであるか、または、良性であるかの指示、及び／又は、ファイルが悪意のあるものである可能性を示すスコアを提供することができる。サードパーティサービスは、履歴データセットに含まれるファイルに対応しているアンマネージＩｍｐｈａｓｈｅ（例えば、ファイルのブラックリスト、ファイルのホワイトリスト、等）を提供することができ、または、リストは、履歴アンマネージＩｍｐｈａｓｈｅｓが悪意のあるものか否かの指示を含むことができる。システムは、新たに識別された良性または悪意のあるファイル、以前の誤分類（ｍｉｓ－ｃｌａｓｓｉｆｉｃａｔｉｏｎ）に対する訂正、等といった、サードパーティサービスからの更新を受信することができる（例えば、既定の間隔で、更新が利用可能であるとき、等）。いくつかの実施形態において、指示は、ファイルが悪意のあるものであるか、または、悪意のあるものである可能性が高いことを示す、コミュニティベースのスコアまたはレーティング（ｒａｔｉｎｇ）（例えば、評判スコア）といったソーシャルスコアに、履歴データセット内のファイルが対応しているか否かである。

【0018】

様々な実施形態に従って、セキュリティエンティティ及び／又はネットワークノード（例えば、クライアント、デバイス、等）は、ファイルが悪意のあるものであるという指示、及び／又は、ファイルが悪意のあるものであると示されたファイルと一致するという指示に少なくとも部分的に基づいて、ファイルを取り扱う。ファイル（例えば、サンプル）が悪意のあるものであるという指示を受信したことに応答して、セキュリティネットワーク及び／又はネットワークノードは、対応しているファイルが悪意のあるものか否かの指示に対するマッピング、及び／又は、ファイルのブラックリストを更新することができる。いくつかの実施形態において、セキュリティエンティティ及び／又はネットワークノードは、ファイル（例えば、悪意があると見なされるサンプル）に関する署名を受信し、そして、セキュリティエンティティ及び／又はネットワークノードは、（例えば、ファイルについて生成された署名を、ファイルのブラックリストに含まれるファイルについての署名と比較することに少なくとも部分的に基づいて）ネットワークトラフィックなどを介して、取得されたファイルが、悪意があるか否かを検出することに関連して使用するために、ファイルの署名を保管している。一つの例として、署名はハッシュであってよい。いくつかの実施形態において、ファイルの署名は、そうしたファイルに対応しているアンマネージＩｍｐｈａｓｈである。

【0019】

ファイアウォールは、典型的に、一式のルールに基づいてネットワーク送信を拒否または許可する。これらのルールのセットは、しばしば、ポリシ（例えば、ネットワークポリシ、またはネットワークセキュリティポリシ）として参照される。例えば、ファイアウォールは、不要な外部トラフィックが保護デバイスに到達するのを防ぐために、一式のルールまたはポリシを適用することによって、インバウンドトラフィック（ｉｎｂｏｕｎｄ ｔｒａｆｆｉｃ）をフィルタリングすることができる。ファイアウォールは、また、一式のルールまたはポリシを適用することによってアウトバウンドトラフィックをフィルタリングすることができる（例えば、許可（ａｌｌｏｗ）、ブロック（ｂｌｏｃｋ）、モニタリング（ｍｏｎｉｔｏｒ）、通知（ｎｏｔｉｆｙ）、またはログ（ｌｏｇ）、及び／又は、ファイアウォールルールまたはファイアウォールポリシにおいて指定され得る他のアクションであり、これらは、ここにおいて説明されるような、様々な基準に基づいてトリガすることができる）。ファイアウォールは、また、同様に一式のルールまたはポリシを適用することによって、ローカルネットワーク（例えば、イントラネット）トラフィックをフィルタリングすることもできる。

【0020】

セキュリティデバイス（例えば、セキュリティ機器、セキュリティゲートウェイ、セキュリティサービス、及び／又は、他のセキュリティデバイス）は、様々なセキュリティ動作（例えば、ファイアウォール、アンチ－マルウェア、侵入防止／検出、プロキシ、及び／又は、他のセキュリティ関数）、ネットワーク関数（例えば、ルーティング、クオリティオブサービス（ＱｏＳ）、ネットワーク関連リソースのワークロードバランシング、及び／又は、他のネットワーク関数）、及び／又は、他のセキュリティ及び／又はネットワーク関連の関数を実行することができる。例えば、ルーティングは、送信元（ｓｏｕｒｃｅ）情報（例えば、ＩＰアドレスおよびポート）、宛先（ｄｅｓｔｉｎａｔｉｏｎ）情報（例えば、ＩＰアドレスおよびポート）、および、プロトコル情報に基づいて実行することができる。

【0021】

基本的なパケットフィルタリング・ファイアウォールは、ネットワークを介して送信される個々のパケットを検査することによって、ネットワーク通信トラフィックをフィルタリングする（例えば、ステートレス（ｓｔａｔｅｌｅｓｓ）パケットフィルタリング・ファイアウォールである、パケットフィルタリング・ファイアウォールまたは第１世代ファイアウォール）。ステートレスパケットフィルタリング・ファイアウォールは、典型的に、個々のパケット自体を検査し、そして、検査されたパケットに基づいて（例えば、パケットの送信元および宛先のアドレス情報、プロトコル情報、および、ポート番号の組み合わせを使用して）ルールを適用する。

【0022】

アプリケーション・ファイアウォールは、また、（例えば、アプリケーション層フィルタリング・ファイアウォール、または、ＴＣＰ／ＩＰスタックのアプリケーションレベルにおいて関数する第２世代ファイアウォールを使用して）アプリケーション層フィルタリングを実行することもできる。アプリケーション層フィルタリング・ファイアウォールまたはアプリケーション・ファイアウォールは、一般的に、既定のアプリケーションおよびプロトコル（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用したウェブブラウジング、ドメインネームシステム（ＤＮＳ）要求、ファイル転送プロトコル（ＦＴＰ）を使用したファイル転送、および、Ｔｅｌｎｅｔ、ＤＨＣＰ、ＴＣＰ、ＵＤＰ、およびＴＦＴＰ（ＧＳＳ）といった、様々な他のタイプのアプリケーションおよび他のプロトコル）を識別することができる。例えば、アプリケーション・ファイアウォールは、標準ポートにおいて通信を試みる未認可（ｕｎａｕｔｈｏｒｉｚｅｄ）プロトコルをブロックすることができる（例えば、そのプロトコルについて非標準（ｎｏｎ－ｓｔａｎｄａｒｄ）ポートを使用することにより黙って通り抜けること（ｓｎｅａｋ ｔｈｒｏｕｇｈ）を試みる未認可／外れたポリシプロトコルは、一般的に、アプリケーション・ファイアウォールを使用して識別することができる）。

【0023】

ステートフル・ファイアウォールは、また、ステートフル・ベースのパケット検査を実行することもでき、そこでは、各パケットが、そのネットワーク送信のパケットフロー（ｆｌｏｗ ｏｆ ｐａｃｋｅｔｓ）と関連する一式のパケットのコンテキストの中で検査される。このファイアウォール技術は、一般的に、ステートフル・パケット検査として参照される。ファイアウォールを通過する全ての接続の記録を保持し、そして、パケットが、新しい接続の開始であるか、既存の接続の一部であるか、または、無効なパケットであるかを判断することができるからである。例えば、接続の状態は、それ自体が、ポリシの中のルールをトリガするクライテリアの１つになり得る。

【0024】

先進的または次世代ファイアウォールは、上述のように、ステートレスおよびステートフルなパケットフィルタリングおよびアプリケーション層フィルタリングを実行することができる。次世代ファイアウォールは、また、追加のファイアウォール技術を実行することもできる。例えば、先進的または次世代ファイアウォールとして、しばしば参照される既定の新しいファイアウォールは、また、ユーザおよびコンテンツを識別することができる。特に、既定の次世代ファイアウォールは、これらのファイアウォールが自動的に識別できるアプリケーションのリストを、何千ものアプリケーションまで拡大している。そうした次世代ファイアウォールの例は、Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓから市販されている（例えば、Ｐａｌｏ Ａｌｔｏ ＮｅｔｗｏｒｋｓのＰＡシリーズのファイアウォール）。例えば、Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓの次世代ファイアウォールは、様々な識別技術を使用して、企業およびサービスプロバイダが、アプリケーション、ユーザ、およびコンテンツ－単にポート、ＩＰアドレス、およびパケットだけでなく－を識別し、かつ、制御することを可能にする。様々な識別技術は、正確なアプリケーション識別のためのアプリケーションＩＤ（Ａｐｐ－ＩＤ）、ユーザ識別のためのユーザＩＤ（Ｕｓｅｒ－ＩＤ）（例えば、Ｕｓｅｒ ＩＤ）、リアルタイムなコンテンツスキャニングのためのコンテンツＩＤ（Ｃｏｎｔｅｎｔ－ＩＤ）（例えば、Ｗｅｂサーフィンを制御し、かつ、データおよびファイルの転送を制限する）、および、デバイスＩＤ（Ｄｅｖｉｃｅ－ＩＤ）（例えば、ＩｏＴデバイスタイプの識別のため）といったものである。これらの識別技術により、企業は、従来のポートブロッキングファイアウォールによって提供される従来のアプローチに従う代わりに、ビジネス関連の概念を使用して、アプリケーションの使用を安全に可能にすることができる。また、（例えば、専用装置として実装される）次世代ファイアウォールのための特定目的ハードウェアは、汎用ハードウェアにおいて実行されるソフトウェアよりも、アプリケーション検査についてより高いパフォーマンスレベルを一般的に提供する（例えば、Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ社が提供するセキュリティ機器といったものであり、シングルパス・ソフトウェアエンジンと堅く統合されている、専用の、関数固有の処理を利用し、Ｐａｌｏ Ａｌｔｏ ＮｅｔｗｏｒｋｓのＰＡシリーズ次世代ファイアウォールについて、レイテンシ（ｌａｔｅｎｃｙ）を最小化する一方で、ネットワークのスループットを最大化する）。

【0025】

先進的または次世代ファイアウォールは、また、仮想化ファイアウォールを使用して実装することもできる。そうした次世代ファイアウォールの例は、Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ社から市販されている（Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓのファイアウォールは、ＶＭｗａｒｅ（Ｒ） ＥＳＸｉ^ＴＭおよびＮＳＸ^ＴＭ、Ｃｉｔｒｉｘ（Ｒ）Ｎｅｔｓｃａｌｅｒ ＳＤＸ^ＴＭ、ＫＶＭ／ＯｐｅｎＳｔａｃｋ（Ｃｅｎｔｏｓ／ＲＨＥＬ、Ｕｂｕｎｔｕ（Ｒ））、および、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）を含む、様々な商用仮想化環境をサポートしている）。例えば、仮想化ファイアウォールは、物理的フォームファクタ機器で利用可能な、同様の、または、完全に同一の次世代ファイアウォールおよび先進的な脅威防止関数をサポートすることができ、企業は、プライベート、パブリック、およびハイブリッドなクラウドコンピューティング環境へのアプリケーションの流入を安全に可能にすることができる。ＶＭモニタリング、ダイナミックアドレスグループ、およびＲＥＳＴベースのＡＰＩといった自動化関数により、企業は、ＶＭの変化を動的にモニタすることができ、そのコンテキストをセキュリティポリシに反映させて、それにより、ＶＭの変化時に生じ得るポリシの遅れ（ｌａｇ）を排除している。

【0026】

システムは、悪意のあるファイルの検出を改善する。さらに、システムは、悪意のあるファイルがネットワーク内のノード間といったネットワークを横断することを防止する（または防止を改善する）ことによって、または、悪意のあるファイルがネットワークに入ることを防止することによって、ネットワークトラフィックの取り扱いをさらに改善する。システムは、．ＮＥＴファイルの．ＮＥＴヘッダに基づくなどして、悪意があると見なされ、または、悪意がある可能性が高い．ＮＥＴファイルを決定する。ファイルのためのＰＥヘッダの構造を使用する関連技術の検出技法は、悪意のある、または、良性ファイルの中で、類似の構造／プロファイルを有するファイルに関して、不十分／不正確であり得る。さらに、．ＮＥＴファイルは中間言語（ｉｎｔｅｒｍｅｄｉａｔｅ ｌａｎｇｕａｇｅ）へとコンパイルされるので、機械学習分類器、または、手動で書かれたＹＡＲＡルールを使用してファイルを、悪意がある／良性であるものとして分類することは困難である。ＹＡＲＡは、（これに限定されないが）マルウェア研究者がマルウェアサンプルを識別し分類するのを助けることを目的とするツールである。ＹＡＲＡルールは、テキストまたはバイナリパターンに基づいてマルウェアファミリの記述を作成することによって、マルウェアサンプルを分類および識別するために使用される。さらに、システムは、悪意のあるファイル（例えば、悪意のある．ＮＥＴファイル）を含むトラフィックに関して１つ以上のセキュリティポリシ（例えば、既定の、及び／又は、顧客固有のセキュリティポリシ）を実施するために、セキュリティエンティティ（例えば、エンドポイント、ファイアウォール、等）に対して正確で、かつ、低レイテンシの更新を提供することができる。従って、システムは、ネットワーク内のノードへの悪意のあるトラフィック（例えば、ファイル）の拡散を防止する。

【0027】

図１は、様々な実施形態に従った、悪意のあるファイルが検出され、または、疑われる環境に係るブロック図である。示される例において、クライアントデバイス１０４－１０８は、（「アクメ会社（“Ａｃｍｅ Ｃｏｍｐａｎｙ”）」に属している）企業ネットワーク１１０内に（それぞれに）存在するラップトップコンピュータ、デスクトップコンピュータ、および、タブレットである。データアプライアンス１０２は、クライアントデバイス１０４および１０６といった、クライアントデバイスと、企業ネットワーク１１０の外部のノード（例えば、外部ネットワーク１１８を介して到達可能なもの）との間の通信に関するポリシ（例えば、セキュリティポリシ）を実施するように構成されている。そうしたポリシの例は、トラフィックシェーピング、クオリティオブサービス（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）、および、トラフィックのルーティングを管理するものを含む。ポリシの他の例は、着信（及び／又は、発信）電子メール添付ファイル、ウェブサイトコンテンツ、インスタントメッセージングプログラムを介して交換されるファイル、及び／又は、他のファイル転送における脅威のスキャンを必要とするものといった、セキュリティポリシを含む。いくつかの実施形態において、データアプライアンス１０２は、また、企業ネットワーク１１０内に留まる（ｓｔａｙ）（または、そこへ入る）トラフィックに関してポリシを施行するように構成されている。

【0028】

本明細書で説明される技術は、様々なプラットフォーム（例えば、デスクトップ、モバイルデバイス、ゲームプラットフォーム、組み込みシステム、等）、及び／又は、様々なタイプのアプリケーション（例えば、Ａｎｄｒｏｉｄ．ａｐｋファイル、ｉＯＳアプリケーション、Ｗｉｎｄｏｗｓ ＰＥファイル、Ａｄｏｂｅ Ａｃｒｏｂａｔ ＰＤＦファイル、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＰＥインストーラ、等）と共に使用することができる。図１に示される例示的な環境において、クライアントデバイス１０４－１０８は、企業ネットワーク１４０内に（それぞれ）存在するラップトップコンピュータ、デスクトップコンピュータ、および、タブレットである。クライアントデバイス１２０は、企業ネットワーク１１０の外部に存在するラップトップコンピュータである。

【0029】

データアプライアンス１０２は、リモートセキュリティプラットフォーム１４０と協働して動作するように構成され得る。セキュリティプラットフォーム１４０は、様々なサービスを提供することができる。マルウェアサンプルに対して静的および動的分析を実行すること、既知の悪意のあるファイルの署名のリストを、サブスクリプションの一部としてデータアプライアンス１０２といったデータアプライアンスに提供すること、悪意のあるファイルを検出すること（例えば、オンデマンド検出、または、ファイルが悪意のあるものか、または、良性のものかの指示へのファイルのマッピングに対する定期的なベースの更新）、ファイルが悪意のあるものか、または、良性のものかの可能性を提供すること、良性と見なされるファイルのホワイトリストを提供／更新すること、悪意のあるドメインを識別すること、悪意のあるファイルを検出すること、ファイルが悪意のあるものか否かを予測すること、および、ファイルが悪意のあるもの（または、良性）であるという指示を提供すること、を含んでいる。様々な実施形態において、分析の結果（および、アプリケーション、ドメイン、等に関する追加的な情報）は、データベース１６０に保管されている。様々な実施形態において、セキュリティプラットフォーム１４０は、典型的なサーバクラスのオペレーティングシステム（例えば、Ｌｉｎｕｘ（登録商標））を実行する１つ以上の専用の市販のハードウェアサーバ（例えば、マルチコアプロセッサ、３２Ｇ＋のＲＡＭ、ギガビットネットワークインターフェイスアダプタ、および、ハードドライブを有する）を備える。セキュリティプラットフォーム１４０は、複数のそうしたサーバ、ソリッドステートドライブ、及び／又は、他の適用可能な高性能ハードウェアを含むスケーラブルなインフラストラクチャにわたり実装され得る。セキュリティプラットフォーム１４０は、１つ以上のサードパーティによって提供されるコンポーネントを含む、いくつかの分散コンポーネントを備えることができる。例えば、セキュリティプラットフォーム１４０の一部または全ては、Ａｍａｚｏｎ Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ（ＥＣ２）、及び／又は、Ａｍａｚｏｎ Ｓｉｍｐｌｅ Ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ（Ｓ３）を使用して実装され得る。さらに、データアプライアンス１０２と同様に、セキュリティプラットフォーム１４０が、データを保管すること、または、データを処理すること、といったタスクを実行するものとして言及されるときはいつでも、セキュリティプラットフォーム１４０のサブコンポーネントまたは複数のサブコンポーネントは、（個々に、または、サードパーティコンポーネントと協働して）そのタスクを実行するように協働し得ることが理解されるべきである。一つの例として、セキュリティプラットフォーム１４０は、１つ以上の仮想マシン（ＶＭ）サーバと協働して、任意的に、静的／動的分析を実行することができる。仮想マシンサーバの一つの例は、ＶＭｗａｒｅ ＥＳＸｉ、Ｃｉｔｒｉｘ ＸｅｎＳｅｒｖｅｒ、または、Ｍｉｃｒｏｓｏｆｔ Ｈｙｐｅｒ－Ｖといった、市販の仮想化ソフトウェアを実行する、市販のサーバクラスハードウェア（例えば、マルチコアプロセッサ、３２＋ギガバイトのＲＡＭ、および、１つ以上のギガビットネットワークインターフェイスアダプタ）を含む物理マシンである。いくつかの実施形態において、仮想マシンサーバは省略される。さらに、仮想マシンサーバは、セキュリティプラットフォーム１４０を管理する同じエンティティの制御下にあってよいが、また、サードパーティによって提供されてもよい。一つの例として、仮想マシンサーバは、ＥＣ２に依存することができ、セキュリティプラットフォーム１４０の残りの部分は、セキュリティプラットフォーム１４０のオペレータによって所有され、かつ、そのオペレータの制御下にある、専用ハードウェアによって提供される。

【0030】

様々な実施形態に従って、セキュリティプラットフォーム１４０は、ＤＮＳトンネリング検出器１３８、及び／又は、悪意のあるファイル検出器１７０を含む。悪意のあるファイル検出器１７０は、ファイル（例えば、．ＮＥＴファイル）が悪意のあるものか否かを決定することに関連して使用される。サンプルを受信することに応答して、悪意のあるファイル検出器１７０は、ファイルを分析し、そして、ファイルが悪意のあるものか否かを決定する。例えば、悪意のあるファイル検出器１７０は、分析されているファイルに対応しているアンマネージＩｍｐｈａｓｈが、履歴データセットに含まれるファイル（例えば、悪意のあると見なされるファイルのリスト、良性と見なされるファイルのリスト、等）に一致するか否かを決定する。いくつかの実施形態において、悪意のあるファイル検出器１７０は、．ＮＥＴファイルを含むサンプルを受信し、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得し、アンマネージなインポートされたＡＰＩ関数名（例えば、アンマネージＩｍｐｈａｓｈ）のリストのハッシュを決定し、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、サンプルがマルウェアであるか否かを決定する。いくつかの実施形態において、悪意のあるファイル検出器１７０は、．ＮＥＴファイルパーサ１７２、アンマネージ関数抽出器１７４、予測エンジン１７６、及び／又は、キャッシュ１７８のうちの１つ以上を備える。

【0031】

．ＮＥＴファイルパーサ１７２は、．ＮＥＴファイルといったサンプルに関する情報を取得することに関連して使用される。いくつかの実施形態において、．ＮＥＴファイルパーサ１７２は、．ＮＥＴファイルの．ＮＥＴヘッダ、及び／又は、．ＮＥＴヘッダからの情報を取得する。．ＮＥＴファイルパーサ１７２は、．ＮＥＴヘッダに含まれる１つ以上のデータストリーム、及び／又は、．ＮＥＴヘッダに含まれる（または、．ＮＥＴヘッダによって参照される）１つ以上のテーブルを取得する。例えば、．ＮＥＴファイルパーサ１７２は、．ＮＥＴヘッダ内に含まれる＃Ｓｔｒｉｎｇｓストリームを取得する。別の例として、．ＮＥＴファイルパーサ１７２は、．ＮＥＴファイルから（例えば、．ＮＥＴヘッダから）ＩｍｐｌＭａｐを取得する。いくつかの実施形態において、．ＮＥＴファイルパーサ１７２は、．ＮＥＴファイルにインポートされる、インポート関数のセット（例えば、インポートされたＡＰＩ関数名）を決定する。

【0032】

アンマネージ関数抽出器１７４は、．ＮＥＴファイルにインポートされる、アンマネージなインポート関数のセットを決定する（例えば、取得する）ことに関連して使用される。例えば、アンマネージ関数抽出器１７４は、．ＮＥＴファイルにインポートされた、インポート関数のセット（例えば、インポートされたＡＰＩ関数名）から、アンマネージなインポート関数のセットを決定する。様々な実施形態に従って、アンマネージ関数抽出器１７４は、．ＮＥＴヘッダに含まれる（または、．ＮＥＴヘッダによって参照される）情報を使用して、アンマネージコードまたはアンマネージ関数（例えば、アンマネージ関数、および、対応しているライブラリ）を決定する。いくつかの実施形態において、アンマネージ関数抽出器１７４は、．ＮＥＴファイルにインポートされた、使用されたアンマネージなｗｉｎ３２ ＡＰＩ関数のセットを決定する。アンマネージ関数抽出器１７４は、．ＮＥＴファイルにインポートされたアンマネージなインポート関数（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリのセットを予測エンジン１７６に提供する。

【0033】

予測エンジン１７６は、ファイル（例えば、．ＮＥＴファイル）が悪意のあるものか否かを決定するために使用される。予測エンジン１７６は、対応している．ＮＥＴファイルが悪意のあるものか否かを決定することに関連して、．ＮＥＴヘッダに含まれる情報を使用する。例えば、予測エンジン１７６は、アンマネージなインポート関数のセット（または、アンマネージ関数の名前）、及び／又は、アンマネージ関数抽出器１７４から．ＮＥＴファイルにインポートされた、対応しているライブラリを取得する。いくつかの実施形態において、予測エンジン１７６は、．ＮＥＴファイルにインポートされた、アンマネージなインポート関数のセット（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリについてのハッシュ（例えば、ハッシュ値）を決定する。例えば、予測エンジン１７６は、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを計算する。予測エンジン１７６は、．ＮＥＴファイルにインポートされた、アンマネージなインポート関数のセット（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリのセットのリストを決定し、そして、そうしたリストのハッシュを決定する。アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストは、既定の順序に従って決定される。例えば、インポートされたアンマネージ関数、及び／又は、対応しているライブラリの順序付け（ｏｒｄｅｒｉｎｇ）は、アンマネージ関数が．ＮＥＴヘッダの要素に含まれる順序（例えば、アンマネージ関数が、．ＮＥＴテーブルに含まれるか、または、それによって参照される＃Ｓｔｒｉｎｇｓストリーム及び／又はテーブルに含まれる順序）に対応している。アンマネージ関数がリストに追加される（または、リストが構成される）様々な他の順序が実施され得る。予測エンジン１７６は、既定のフォーマットに従って、リスト、及び／又は、アンマネージ関数（例えば、アンマネージ関数名、及び／又は、対応しているライブラリ）をフォーマットする。既定のフォーマットの例は、（ｉ）小文字の英数字ストリング、（ｉｉ）ファイル拡張子の除去、（ｉｉｉ）ライブラリ拡張子の除去（例えば、対応しているライブラリ名からの．ｄｌｌの除去）、（ｉｖ）アンマネージ関数名および対応しているライブラリの付加、および、（ｖ）アンマネージ関数名と、対応しているライブラリとの間の事前定義されたセパレータの使用、が含まれる。いくつかの実施形態において、予測エンジン１７６は、関数名（例えば、アンマネージ関数名）を対応しているライブラリに付加し、そして、ドットまたはピリオド（例えば、「．」）によって、対応しているライブラリから関数名を分離する。関数名およびライブラリを（例えば、「．」といった事前定義されたセパレータを用いて）付加することによって文字列（ｓｔｒｉｎｇ）を決定したことに応答して、予測エンジン１７６は、そうしたエントリを、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに追加する。

【0034】

様々な実施形態に従って、予測エンジン１７６は、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに関してハッシュを決定する。ハッシュの決定に関連して、様々なハッシュ関数を使用することができる。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含む。様々な他のハッシュ関数が実装され得る。予測エンジン１７６は、ハッシュ関数を使用して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定する。

【0035】

様々な実施形態に従って、予測エンジン１７６は、．ＮＥＴファイルが悪意のあるものか否かを決定するために、．ＮＥＴファイルの．ＮＥＴヘッダから取得された情報を使用する。いくつかの実施形態において、予測エンジン１７６は、．ＮＥＴファイルが悪意のあるものか否かを決定することに関連して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを使用する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定することに応答して、予測エンジン１７６は、アンマネージＩｍｐｈａｓｈが、悪意があると見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、予測エンジン１７６は、アンマネージＩｍｐｈａｓｈが、良性であると見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。いくつかの実施形態において、悪意のあるファイル検出器１７０（例えば、予測エンジン１７６）は、特定のファイルに関する情報（例えば、分析されている．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈ）が、履歴ファイルのデータセット、および、特定のファイルが悪意のあるものか否かを示す履歴データセット（例えば、ＶｉｒｕｓＴｏｔａｌ^ＴＭといったサードパーティサービス）に関連する履歴情報、に含まれるか否かを決定する。特定のファイルに関する情報が、履歴ファイルおよび履歴情報のデータセットに含まれていない、または、利用可能でないと決定したことに応答して、悪意のあるファイル検出器１７０は、ファイルを良性であると見なし得る（例えば、ファイルを悪意のあるものではないと見なす）。特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連付けられた履歴情報の一つの例は、ＶｉｒｕｓＴｏｔａｌ（Ｒ）（ＶＴ）スコアに対応している。特定のファイルについてのＶＴスコアが０より大きい場合、その特定のファイルは、サードパーティサービスによって悪意があると見なされる。いくつかの実施形態において、特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連付けられた履歴情報は、ファイルが悪意のあるものであるか、または、悪意のあるものである可能性が高いことを示す、コミュニティベースのスコア、または、レーティング（例えば、評判スコア）といったソーシャルスコアに対応している。（例えば、サードパーティサービス、コミュニティベースのスコア、等からの）履歴情報は、他のベンダまたはサイバーセキュリティ組織が、特定のファイルを悪意のあるものであると見なすか否かを示す。

【0036】

いくつかの実施形態において、悪意のあるファイル検出器１７０（例えば、予測エンジン１７６）は、受信されたファイルが新たに分析されたことを決定する（例えば、ファイルが履歴情報／データセット内にないこと、ホワイトリストまたはブラックリスト上にないこと、等）。悪意のあるファイル検出器１７０（例えば、スクリプト抽出モジュール１７２）は、セキュリティプラットフォーム１４０がネットワーク内のセキュリティエンティティ（例えば、ファイアウォール）またはエンドポイントからファイルを受信したことに応答して、ファイルが新たに分析されたことを検出し得る。例えば、悪意のあるファイル検出器１７０は、セキュリティプラットフォーム１４０、または悪意のあるファイル検出器１７０が、ファイルを受信するのと同時に新たに、ファイルが分析されたと決定する。別の例として、悪意のあるファイル検出器１７０（例えば、予測エンジン１７６）は、バッチプロセスに関連するといった、既定のスケジュール（例えば、毎日、毎週、毎月、等）に従って、ファイルが新たに分析されたと決定する。そうしたファイルが悪意のあるものか否かに関して未だ分析されていないと決定したことに応答して（例えば、システムが、そうしたファイルに関する履歴情報を備えていない）、悪意のあるファイル検出器１７０は、ファイルが悪意のあるものか否かを決定することに関連して（例えば、ファイルが．ＮＥＴファイルであると決定したことに応答してなど）、ファイルに関連する．ＮＥＴヘッダを使用するか否かを決定し、そして、悪意のあるファイル検出器１７０は、．ＮＥＴファイルの．ＮＥＴヘッダから．ＮＥＴファイルに関する情報を解析及び／又は抽出するために、．ＮＥＴファイルパーサを使用する、。いくつかの実施形態において、．ＮＥＴファイルパーサ１７２は、システムのサンドボックス環境内の．ＮＥＴヘッダから情報を抽出する。

【0037】

様々な実施形態に従って、ファイルが悪意のあるものであると予測エンジン１７６が決定したことに応答して、システムは、ファイルが悪意のあるものであるという指示をセキュリティエンティティ（または、クライアントといったエンドポイント）に送信する。例えば、悪意のあるファイル検出器１７０は、セキュリティエンティティ（例えば、ファイアウォール）またはネットワークノード（例えば、クライアント）に対して、ファイルが悪意のあるものであるという指示を送信する。ファイルが悪意のあるものであるという指示は、ファイルが悪意のあるものであると見なされる場合といった（例えば、悪意のあるファイルに対応している）ファイルのブラックリストへの更新、または、ファイルが良性であると見なされる場合といった（例えば、悪意のないファイルに対応している）ファイルのホワイトリストへの更新に対応し得る。いくつかの実施形態において、悪意のあるファイル検出器１７０は、ファイルが悪意のあるものであるか、または、良性であるという指示に関連して、ファイルに対応しているハッシュまたは署名を送信する。セキュリティエンティティまたはエンドポイントは、ファイルのハッシュまたは署名を計算し、ファイルが、悪意がある／良性であるか否かの指示へのハッシュ／署名のマッピングに対してルックアップを実行し得る（例えば、ホワイトリスト及び／又はブラックリストをクエリする）。いくつかの実施形態において、ハッシュまたは署名は、ファイルを一意に識別する。

【0038】

キャッシュ１７８は、ファイルに関する情報を保管している。いくつかの実施形態において、キャッシュ１７８は、ファイルが悪意のあるものである（または、悪意のあるものである可能性が高い）か否かの指示の特定のファイルへのマッピング、または、ファイルが悪意のあるものである（または、悪意のあるものである可能性が高い）か否かの指示のファイルに対応しているハッシュまたは署名へのマッピングを保管する。キャッシュ１７８は、ファイルのセットに関する追加の情報を保管することができる。ファイルのセット内のファイルのスクリプト情報、ファイルのセット内のファイルに対応しているハッシュまたは署名、ファイルのセット内のファイルに対応している他の一意の識別子、ファイルによって呼び出される実行可能ファイル、ファイルによって呼び出されるビットコインウォレット、ファイルに含まれるポインタ、といったものである。

【0039】

図１に戻り、（システム１２０を使用している）悪意のある個人がマルウェア１３０を作成したと仮定する。悪意のある個人は、クライアントデバイス１０４といった、クライアントデバイスがマルウェア１３０のコピーを実行し、クライアントデバイスを危険にさらし、そして、クライアントデバイスをボットネット内のボットにさせることを望んでいる。危険にさらされたクライアントデバイスは、次いで、タスク（例えば、暗号通貨マイニング、または、サービス妨害攻撃への参加）を実行するように、かつ／あるいは、コマンドおよび制御（Ｃ＆Ｃ）サーバ１５０といった外部エンティティ（例えば、そうしたタスクに関連付けられた、機密の企業データを抽出するなど）に情報を報告するように、並びに、適用可能な場合、Ｃ＆Ｃサーバ１５０から命令を受信するように、命令され得る。

【0040】

マルウェア１３０は、（例えば、Ｃ＆Ｃサーバ１５０に電子メールを送信するように、クライアントにさせることによって）危険にさらされたクライアントデバイスに、Ｃ＆Ｃサーバ１５０と直接的に通信させるように試みることができるが、そうした明白な通信の試みは、疑わしい／有害であるとして（例えば、データアプライアンス１０２によって）フラグ付けされ、そして、ブロックされ得る。ますます、そうした直接的な通信を発生させる代わりに、マルウェアの作者は、本明細書でＤＮＳトンネリングと呼ばれる技法を使用する。ＤＮＳは、ｐａｌｏａｌｔｏｎｅｔｗｏｒｋｓ．ｃｏｍといった人間に優しいＵＲＬを、１９９．１６７．５２．１３７といったマシンに優しいＩＰアドレスへと変換するプロトコルである。ＤＮＳトンネリングは、ＤＮＳプロトコルをエクスプロイト（ｅｘｐｌｏｉｔ）して、クライアント－サーバモデルを介してマルウェアおよび他のデータをトンネリングする。添付ファイル（ａｔｔａｃｈ）の例では、悪意のあるファイル（例えば、マルウェア）が、電子メール、インスタントメッセージ、等といったメッセージに対する添付ファイルとして送信される。一旦、添付ファイルを選択すると、マルウェアプログラムが、クライアントデバイスにインストールされ得る。攻撃の一つの例において、攻撃者は、ｂａｄｓｉｔｅ．ｃｏｍといった、ドメインを登録する。ドメインのネームサーバは、トンネリングマルウェアプログラムがインストールされている、攻撃者のサーバを指し示す。攻撃者は、コンピュータを感染させる。ＤＮＳ要求は、従来、セキュリティ機器の内外に移動することが許可されているので、感染したコンピュータは、ＤＮＳリゾルバ（例えば、ｋｊ３２ｈｋｊｑｆｅｕｏ３２ｙｌｈｋｊｓｈｄｆｌｕ２３．ｂａｄｓｉｔｅ．ｃｏｍ、ここでは、クエリのサブ領域部分はＣ＆Ｃサーバによる消費のために情報をエンコーディングする）に対してクエリを送信することが許可される。ＤＮＳリゾルバは、ＩＰアドレスに対する要求を、ルートおよびトップレベルドメインサーバに対して中継（ｒｅｌａｙ）するサーバである。ＤＮＳリゾルバは、トンネリングプログラムがインストールされている、攻撃者のＣ＆Ｃサーバにクエリをルーティング（ｒｏｕｔｅ）する。被害者と攻撃者との間に、今や、ＤＮＳリゾルバを介して、接続が確立される。このトンネルは、データを抽出するため、または、他の悪意のある目的のために使用され得る。

【0041】

ＤＮＳトンネリング攻撃を検出し、かつ、防止することは、様々な理由で困難である。多くの正当なサービス（例えば、コンテンツ配信ネットワーク、ウェブホスティング会社、等）は、ドメイン名のサブドメイン部分を正当に使用して、それらの正当なサービスの使用をサポートするのを助けるための情報を、エンコーディング。そうした正当なサービスによって使用されるエンコーディングパターンは、プロバイダ間で大きく異なる可能性があり、そして、良性のサブドメインは、悪意のあるサブドメインと視覚的に区別できないように見える可能性がある。第２理由は、既知の良性、および、既知の悪意のある、両方のトレーニングセットデータの大きなコーパス（ｃｏｒｐｕｓ）を有する他の領域（例えば、コンピュータ研究）とは異なり、ＤＮＳクエリのためのトレーニングセットデータは、ひどく偏っていることである（例えば、何百万もの良性ルートドメインの例、および、非常に少数の悪意のある例を有する）。そうした困難にも関わらず、かつ、本明細書で説明される技法を使用して、悪意のあるドメインを、効率的かつ積極的に（例えば、ドメインの登録直後に）検出することができ、かつ、ネットワーク内、または、ネットワークに入る悪意のあるファイルに関してセキュリティポリシを実施することができ、そして、そうした悪意のあるファイルをブロックし、もしくは、そうでなければ、悪意のあるファイルのユーザまたは管理者に警告する（例えば、通知を送信する、ユーザにプロンプトを提供する、等）。

【0042】

図１に示される環境は、３つのドメインネームシステム（ＤＮＳ）サーバ（１２２－１２６）含んでいる。示されるように、ＤＮＳサーバ１２２は、（ネットワーク１１０内に配置されたコンピューティングアセットによる使用のために）ＡＣＭＥの制御下にあり、一方で、ＤＮＳサーバ１２４は、公的にアクセス可能である（そして、また、ネットワーク１１０内に配置されたコンピューティングアセット、並びに、他のネットワーク（例えば、ネットワーク１１４および１１６）内に配置されたものといった、他のデバイスによっても使用され得る）。ＤＮＳサーバ１２６は、公的にアクセス可能であるが、Ｃ＆Ｃサーバ１５０の悪意のあるオペレータの制御下にある。エンタープライズＤＮＳサーバ１２２は、企業ドメイン名をＩＰアドレスへと解決するように構成されており、そして、さらに、１つ以上の外部ＤＮＳサーバ（例えば、ＤＮＳサーバ１２４および１２６）と通信して、適用される場合、ドメイン名を解決するように構成されている。

【0043】

上述のように、正当なドメイン（例えば、サイト１２８として示されるｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ）に接続するために、クライアントデバイス１０４といった、クライアントデバイスは、ドメインを、対応しているインターネットプロトコル（ＩＰ）アドレスへ解決する必要がある。そうした解決が行われ得る１つの方法は、クライアントデバイス１０４が、ドメインを解決するために、ＤＮＳサーバ１２２及び／又は１２４に要求を転送することである。要求されたドメイン名について有効なＩＰアドレスを受信したことに応答して、クライアントデバイス１０４は、ＩＰアドレスを使用して、ウェブサイト１２８に接続することができる。同様に、悪意のあるＣ＆Ｃサーバ１５０に接続するために、クライアントデバイス１０４は、ドメイン「ｋｊ３２ｈｋｊｑｆｅｕｏ３２ｙｌｈｋｊｓｈｄｆｌｕ２３．ｂａｄｓｉｔｅ．ｃｏｍ」を、対応しているインターネットプロトコル（ＩＰ）アドレスへ解決する必要がある。この例において、悪意のあるＤＮＳサーバ１２６は、＊．ｂａｄｓｉｔｅ．ｃｏｍに対して権限があり、そして、クライアントデバイス１０４の要求は、（例えば）解決のためにＤＮＳサーバ１２６に転送され、究極的に、Ｃ＆Ｃサーバ１５０がクライアントデバイス１０４からデータを受信することを可能にする。

【0044】

データアプライアンス１０２は、クライアントデバイス１０４および１０６といった、クライアントデバイスと、企業ネットワーク１４０の外部のノード（例えば、外部ネットワーク１１８を介して到達可能なもの）との間の通信に関するポリシを実施するように構成されている。そうしたポリシの例は、トラフィックシェーピング、クオリティオブサービス、および、トラフィックのルーティングを管理するものを含んでいる。ポリシの他の例は、着信（及び／又は、発信）電子メール添付ファイル、ウェブサイトコンテンツ、インスタントメッセージングプログラムを介して交換されるファイル、及び／又は、他のファイル転送における脅威のスキャンを必要とするものといった、セキュリティポリシを含む。いくつかの実施形態において、データアプライアンス１０２は、また、企業ネットワーク１４０内に留まるトラフィックに関してポリシを実施するように構成されている。

【0045】

様々な実施形態において、データアプライアンス１０２は、クライアントデバイス（例えば、クライアントデバイス１０４－１０８）が悪意のあるＤＮＳトンネリングに関与しようとしているか否かを決定することを容易にし、かつ／あるいは、悪意のあるＤＮＳサーバへの（例えば、クライアントデバイス１０４－１０８による）接続を防止するように構成された、ＤＮＳモジュール１３４を含んでいる。ＤＮＳモジュール１３４は、（図１に示されるように）アプライアンス１０２に統合されることができ、そして、また、種々の実施形態において、独立型アプライアンスとして動作することもできる。そして、図１に示される他のコンポーネントと同様に、ＤＮＳモジュール１３４は、アプライアンス１０２（または、セキュリティプラットフォーム１４０）を提供する同一のエンティティによって提供されることができ、そして、また、サードパーティ（例えば、アプライアンス１０２またはセキュリティプラットフォーム１４０のプロバイダとは異なるもの）によって提供されることもできる。さらに、悪意のあるＤＮＳサーバへの接続を防止することに加えて、ＤＮＳモジュール１３４は、クライアントによって行われたトンネリング試行（ｔｕｎｎｅｌｉｎｇ ａｔｔｅｍｐｔ）の個別化されたロギング（所与のクライアントが危険にさらされており、かつ、隔離されるべきであり、または、そうでなければ管理者によって調査されるべきであるという指示）といった、他のアクションをとることができる。

【0046】

様々な実施形態において、クライアントデバイス（例えば、クライアントデバイス１０４）がドメインを解決しようと試みる場合、ＤＮＳモジュール１３４は、セキュリティプラットフォーム１４０に対するクエリとしてドメインを使用する。このクエリは、ドメインの解決と同時に実行され得る（例えば、ＤＮＳサーバ１２２、１２４、及び／又は、１２６、並びに、セキュリティプラットフォーム１４０に送信される要求と同時）。一つの例として、ＤＮＳモジュール１３４は、ＲＥＳＴ ＡＰＩを介して、セキュリティプラットフォーム１４０のフロントエンド１４２にクエリを（例えば、ＪＳＯＮフォーマットで）送信することができる。以下でより詳細に説明される処理を使用して、セキュリティプラットフォーム１４０は、クエリされたドメインが悪意のあるＤＮＳトンネリングの試みを示すか否かを（例えば、ＤＮＳトンネリング検出器１３８を使用して）決定し、そして、結果（例えば、「悪意のあるＤＮＳトンネリング」または「非トンネリング」）をＤＮＳモジュール１３４に返す。

【0047】

様々な実施形態において、クライアントデバイス（例えば、クライアントデバイス１０４）が、電子メール、インスタントメッセージへの添付ファイルを介するなどして、受信されたファイルを開くことを試みる場合、または、クライアントデバイスがそうしたファイルを受信する場合、ＤＮＳモジュール１３４は、セキュリティプラットフォーム１４０へのクエリとしてファイル（つまり、計算されたハッシュまたは署名、もしくは、他の一意の識別子、等）を使用する。このクエリは、ファイルの受信と同時に、または、ファイルをスキャンするためのユーザからの要求に応答して、実行され得る。一つの例として、データアプライアンス１０２は、ＲＥＳＴ ＡＰＩを介して、セキュリティプラットフォーム１４０のフロントエンド１４２にクエリを（例えば、ＪＳＯＮフォーマットで）送信することができる。以下でより詳細に説明される処理を使用して、セキュリティプラットフォーム１４０は、クエリされたファイルが悪意のあるファイルであるか（または、悪意のあるファイルである可能性が高いか）否かを（例えば、悪意のあるファイル検出器１７０を使用して）決定し、そして、結果（例えば、「悪意のあるＤＮＳトンネリング」または「非トンネリング」）をＤＮＳモジュール１３４に返す。

【0048】

様々な実施形態において、ＤＮＳトンネリング検出器１３８（セキュリティプラットフォーム１４０上、データアプライアンス１０２上、または、他の適切な場所／場所の位置の組み合わせ、のいずれかで実装される）は、悪意のあるＤＮＳトンネリングを識別する際に２面アプローチ（ｔｗｏ－ｐｒｏｎｇｅｄ ａｐｐｒｏａｃｈ）を使用する。第１手法は、ルートドメインについてＤＮＳトラフィックのリアルタイムプロファイル（１５６）のセットを構築するために、（例えば、パイソン（ｐｙｔｈｏｎ）を使用して実装される）異常検出器（ａｎｏｍａｌｙ ｄｅｔｅｃｔｏｒ）１４６を使用する。第２アプローチは、署名生成およびマッチング（本明細書では、また、類似性検出とも呼ばれ、かつ、例えば、Ｇｏを使用して実装される）を使用する。２つのアプローチは、相補的である。異常検出器は、以前には未知であったトンネリングトラフィックを識別することができる、汎用検出器として関数する。しかしながら、異常検出器は、検出が行われる前に複数のＤＮＳクエリを観察する必要とすることがある。第１ＤＮＳトンネリングパケットをブロックするために、類似性検出器１４４は、異常検出器１４６を補完し、そして、検出されたトンネリングトラフィックから署名を抽出する。それは、検出されたルートドメインに類似するツール／マルウェアを使用して、攻撃者が新しい悪意のあるトンネリングルートドメインを登録し、そのように行った、状況を識別するために使用され得る。

【0049】

データアプライアンス１０２がＤＮＳクエリを（例えば、ＤＮＳモジュール１３４から）受信すると、データアプライアンス１０２は、それらを、異常検出および類似性検出の両方を実行するセキュリティプラットフォーム１４０に対して、それぞれに、提供する。様々な実施形態において、（例えば、セキュリティプラットフォーム１４０によって受信されたクエリにおいて提供されるような）ドメインは、いずれかの検出器がドメインにフラグ付ける場合に、悪意のあるＤＮＳトンネリングルートドメインとして分類される。

【0050】

ＤＮＳトンネリング検出器１３８は、（そこからデータが受信される）機器ごとに、それらのルートドメインに関してグループ化された（図１ではドメインプロファイル１５６として集合的に示されている）、完全に指定されたドメイン名（ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ ｄｏｍａｉｎ ｎａｍｅ、ＦＱＤＮ）のセットを維持する。（ルートによるグループ化を通じて、ドメインは、本明細書において一般的に説明されているが、本明細書で説明される技法は、また、任意のレベルのドメインまで拡張され得ることも理解されるべきである。）様々な実施形態において、所与のドメインについての受信されたクエリに関する情報は、固定された時間量について（例えば、１０分のスライディング時間ウィンドウ）、プロファイル内に持続される。

【0051】

一つの例として、様々なｆｏｏ．ｃｏｍサイトについてデータアプライアンス１０２から受信されたＤＮＳクエリ情報は、以下のように（ルートドメインｆｏｏ．ｃｏｍについてのドメインプロファイルへと）グループ化される。
Ｇ（ｆｏｏ．ｃｏｍ）＝［ｍａｉｌ．ｆｏｏ．ｃｏｍ、ｃｏｏｌｓｔｕｆｆ．ｆｏｏ．ｃｏｍ，ｄｏｍａｉｎ１２３４．ｆｏｏ．ｃｏｍ］。
第２ルートドメインは、同様の適用情報を有する第２プロファイルを有するだろう（例えば、Ｇ（ｂａｄｄｏｍａｉｎ．ｃｏｍ）＝［ｌｓｋｊｄｆ２３ｒ．ｂａｄｄｏｍａｉｎ．ｃｏｍ，ｋｊ２３５ｈｄｓｓｄ２３３．ｂａｄｄｏｍａｉｎ．ｃｏｍ］）。各ルートドメイン（例えば、ｆｏｏ．ｃｏｍまたはｂａｄｄｏｍａｉｎ．ｃｏｍ）は、悪意のあるＤＮＳトンネリングに固有の特性のセットを使用してモデル化され、その結果、良性ＤＮＳパターンが多様であってさえも（例えば、ｋ２ｊｈ３ｉ８ｙ３５．ｌｅｇｉｔｉｍａｔｅｓｉｔｅ．ｃｏｍ，ｘｘｘ８８８２２２０００４４４．ｏｔｈｅｒｌｅｇｉｔｉｍａｔｅｓｉｔｅ．ｃｏｍ）、それらが、悪意のあるトンネリングとして誤分類される可能性は非常に低い。以下は、ドメインの所与のグループ（すなわち、ルートドメインを共有する）についての特徴として（例えば、特徴ベクトルへと）抽出され得る例示的な特性である。

【0052】

いくつかの実施形態において、悪意のあるファイル検出器１７０は、データアプライアンス１０２といった、セキュリティエンティティに対して、ファイルが悪意のあるものか否かの指示を提供する。例えば、ファイルが悪意のあるものであると決定したことに応答して、悪意のあるファイル検出器１７０は、ファイルが悪意のあるものであるという指示をデータアプライアンス１０２に送信し、そして、データアプライアンスは、次に、ファイルが悪意のあるものであるという指示に少なくとも部分的に基づいて、１つ以上のセキュリティポリシを実施し得る。１つ以上のセキュリティポリシは、ファイルを隔離すること、ファイルを削除すること、ユーザがファイルを開く／実行する以前にファイルの悪意性をユーザに警告し、または、促すこと、等を含み得る。別の例として、ファイルが悪意のあるものであると決定したことに応答して、悪意のあるファイル検出器１７０は、セキュリティエンティティに対して、対応しているファイルが悪意のあるものか否かの指示に対するファイル（または、ハッシュ、署名、アンマネージなＩｍｐｈａｓｈｅｓ、もしくは、ファイルに対応している他の一意の識別子）のマッピングの更新、または、悪意のあるファイルについてのブラックリスト（例えば、ファイルドメインを識別している）、もしくは、良性ファイルについてのホワイトリスト（例えば、悪意のあるものと見なされないファイルを識別している）に係る更新を提供する。

【0053】

図２は、様々な実施形態に従った、悪意のあるファイルを検出するためのシステムに係るブロック図である。様々な実施形態に従って、システム２００は、悪意のあるファイル検出器１７０についてなど、図１のシステム１００に関連して実装される。様々な実施形態において、システム２００は、図４のプロセス４００、図５のプロセス５００、図６のプロセス６００、図７Ａのプロセス７００、図７Ｂのプロセス７５０、図８のプロセス８００、図９のプロセス９００、図１０のプロセス１０００、及び／又は、図１１のプロセス１１００に関連して実装される。システム２００は、１つ以上のサーバ、ファイアウォールといったセキュリティエンティティ、及び／又は、エンドポイントに実装され得る。

【0054】

システム２００は、サーバといった１つ以上のデバイスによって実装され得る。システム２００は、ネットワーク上の様々な場所で実施され得る。いくつかの実施形態において、システム２００は、図１のシステム１００の悪意のあるファイル検出器１７０を実装する。一つの例として、システム２００は、ウェブサービスといった、サービスとして展開される（例えば、システム２００は、ファイルが悪意のあるものか否かを決定し、そして、そうした決定をサービスとして提供する）。サービスは、１つ以上のサーバによって提供され得る（例えば、システム２００または悪質なファイルの検出器は、電子メール、インスタントメッセージ、等に対する添付ファイルを介するなどして、ネットワーク内、または、ネットワークの内／外に送信されるファイルを監視または受信し、そして、ファイルが悪意のあるものか否かを決定し、かつ、ファイルが悪意のあるものか否かの指示といったファイルに関する通知または更新を送信し／プッシュする、リモートサーバ上に展開される）。別の例として、悪意のあるファイル検出器は、ファイアウォール上に展開される。

【0055】

示される例において、システム２００は、ファイル（例えば、新たに受信されたファイル）が悪意のあるものか否かを予測すること、ファイルが悪意のあるものである可能性を決定すること、及び／又は、ファイルが悪意のあるものか否かの通知もしくは指示を提供すること、に関連して、１つ以上のモジュールを実装している。システム２００は、通信インターフェイス２０５、１つ以上のプロセッサ２１０、ストレージ装置２１５、及び／又は、メモリ２２０を備えている。１つ以上のプロセッサ２１０は、通信モジュール２２５、．ＮＥＴヘッダ抽出モジュール２３０、アンマネージ関数抽出モジュール２３５、リスト生成モジュール２４０、予測モジュール２４５、及び／又は、通知モジュール２５０、のうちの１つ以上を備えている。

【0056】

いくつかの実施形態において、システム２００は、通信モジュール２２５を含んでいる。システム２００は、様々なノードもまたはエンドポイント（例えば、クライアント端末、ファイアウォール、ＤＮＳリゾルバ、データアプライアンス、他のセキュリティエンティティ、等）、もしくは、アドミニストレータシステムといったユーザシステムと通信するために、通信モジュール２２５を使用する。例えば、通信モジュール２２５は、通信される情報を通信インターフェイス２０５に提供する。別の例として、通信インターフェイス２０５は、システム２００によって受信された情報を通信モジュール２２５に提供する。通信モジュール２２５は、セキュリティエンティティ（例えば、ファイアウォール）といったネットワークエンドポイントまたはノードからなど、分析されるファイルを受信するように構成されている。通信モジュール２２５は、ファイルに関する情報についてサードパーティサービスをクエリするように構成されている（例えば、ファイルの悪意性のサードパーティスコアまたは評価、ファイルに関するコミュニティベースのスコア、評価、もしくは、評判、ファイルのブラックリスト、及び／又は、ファイルのホワイトリストのファイルの情報を公開するサービス、等）。例えば、システム２００は、サードパーティサービスをクエリするために、通信モジュール２２５を使用する。通信モジュール２２５は、管理者から１つ以上の設定または構成を受信するように構成されている。１つ以上の設定または構成の例は、ファイルが悪意のあるものか否かを決定するプロセスの構成、．ＮＥＴファイルのアンマネージＩｍｐｈａｓｈを決定するために．ＮＥＴファイルの情報が編成／配置されるフォーマット、ファイルのアンマネージＩｍｐｈａｓｈの決定に関連して使用されるハッシュ関数、ドメイン（例えば、疑わしいと見なされず、かつ、トラフィックまたは接続が許可されるドメイン）のホワイトリストに関する情報、ドメイン（例えば、疑わしいと見なされ、かつ、トラフィックまたは接続が制限されるドメイン）のブラックリストに関する情報、を含む。

【0057】

いくつかの実施形態において、システム２００は、．ＮＥＴヘッダ抽出モジュール２３０を含んでいる。システム２００は、ファイルのヘッダに関連する情報を（例えば、ヘッダから）抽出するか否かを決定すること、および、（例えば、ファイルが悪意のあるものか否かの分析のために）ファイルの情報を抽出することに関連して、．ＮＥＴヘッダ抽出モジュール２３０を使用する。いくつかの実施形態において、．ＮＥＴヘッダ抽出モジュール２３０は、分析されるべきファイルを受信する。電子メール、インスタントメッセージへの添付ファイルとして含まれるファイル、もしくは、そうでなければ、ネットワークを介して、または、ネットワークの内／外から通信されるファイル、といったものである。．ＮＥＴヘッダ抽出モジュール２３０は、ファイルが．ＮＥＴファイルであると決定したことに応答して、ファイルのヘッダに関する情報の抽出を実行することを決定する。一つの例として、．ＮＥＴヘッダ抽出モジュール２３０は、ファイルが．ＮＥＴファイルに対応しているという指示を受信することに基づいて、ファイルが．ＮＥＴファイルであると決定する。別の例として、．ＮＥＴヘッダ抽出モジュール２３０は、ファイルが．ＮＥＴヘッダを含むという決定に少なくとも部分的に基づいて、ファイルが．ＮＥＴファイルであると決定する。別の例として、．ＮＥＴヘッダ抽出モジュール２３０は、ＰＥヘッダ内のディレクトリ項目が非ゼロ値（ｎｏｎ－ｚｅｒｏ ｖａｌｕｅ）を有するという決定に少なくとも部分的に基づいて、ファイルが．ＮＥＴファイルであると決定する（例えば、システム２００は、ファイルのバイナリ構造を検査し、かつ、任意的なヘッダ値内の値が非ゼロ値／場所を含むか否かを決定し、そして、そうである場合には、ファイルが．ＮＥＴファイルであると決定する）。別の例として、．ＮＥＴヘッダ抽出モジュール２３０は、ファイルが「＿ＣｏｒＥｘｅＭａｉｎ」または「＿ＣｏｒＤｌｌＭａｉｎ」関数をインポートするかを決定するためのチェックに少なくとも部分的に基づいて、ファイルが．ＮＥＴファイルであると決定する。

【0058】

いくつかの実施形態において、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴファイルの．ＮＥＴヘッダから．ＮＥＴヘッダ及び／又は情報を取得する。ファイルが．ＮＥＴファイルであると決定したことに応答して、．ＮＥＴヘッダ抽出モジュール２３０は、ファイルのヘッダに関する情報（例えば、ヘッダからの情報）を取得する。いくつかの実施形態において、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴヘッダを決定し、そして、．ＮＥＴヘッダによってインポートされる（または、参照される）インポート関数を取得する。例えば、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得する。ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴヘッダに含まれる１つ以上のデータストリーム、及び／又は、．ＮＥＴヘッダに含まれる（または、．ＮＥＴヘッダによって参照される）１つ以上のテーブルを取得する。例えば、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴヘッダに含まれる＃Ｓｔｒｉｎｇｓストリームを取得する。別の例として、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴファイルから（例えば、．ＮＥＴヘッダから）ＩｍｐｌＭａｐを取得する。ＩｍｐｌＭａｐは、．ＮＥＴファイルのインポートされたアンマネージ関数に関する様々な情報を含み得る。いくつかの実施形態において、．ＮＥＴヘッダ抽出モジュール２３０は、．ＮＥＴファイルにインポートされる、インポート関数のセット（例えば、インポートされたＡＰＩ関数名）を決定する。

【0059】

様々な実施形態に従って、ファイルが悪意のあるものか否かを決定するために分析されるべきファイルを受信したことに応答して、システム２００は、ファイルを、そのファイルが分析されるべきサンドボックス内に配置する。いくつかの実施形態において、．ＮＥＴヘッダ抽出モジュール２３０は、ファイルのヘッダに関連する情報（例えば、ヘッダからの情報）を抽出する。一つの例として、．ＮＥＴヘッダ抽出モジュール２３０は、サンドボックス内の．ＮＥＴファイルについての．ＮＥＴヘッダ及び／又はＰＥヘッダから、ヘッダ情報を抽出する。例えば、システム２００は、特定のファイルの分析のためにサンドボックスを呼び出す（ｉｎｖｏｋｅ）。別の例として、システム２００は、様々なファイルの分析のために共通のサンドボックスを使用する。

【0060】

いくつかの実施形態において、システム２００は、アンマネージ関数抽出モジュール２３５を含んでいる。システム２００は、アンマネージ関数抽出モジュール２３５を使用して、．ＮＥＴファイルの．ＮＥＴヘッダを介してインポートされたアンマネージ関数のリストといった、．ＮＥＴファイルに含まれ、または、参照される、アンマネージ関数のセットを決定する（例えば、取得する）。例えば、アンマネージ関数抽出モジュール２３５は、．ＮＥＴファイルにインポートされたインポート関数（例えば、インポートされたＡＰＩ関数名）のセットからアンマネージなインポート関数のセットを決定する。様々な実施形態に従って、アンマネージ関数抽出モジュール２３５は、．ＮＥＴヘッダに含まれる（または．ＮＥＴヘッダによって参照される）情報を使用して、アンマネージコードまたはアンマネージ関数（例えば、アンマネージ関数、および、対応しているライブラリ）を決定する。いくつかの実施形態において、アンマネージ関数抽出モジュール２３５は、．ＮＥＴファイルにインポートされた、使用されたアンマネージなｗｉｎ３２ ＡＰＩ関数のセットを決定する。アンマネージ関数抽出モジュール２３５は、．ＮＥＴファイルにインポートされたアンマネージなインポート関数（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリのセットをリスト生成モジュール２４０、及び／又は、予測モジュール２４５に提供する。

【0061】

いくつかの実施形態において、システム２００は、リスト生成モジュール２４０を含んでいる。システム２００は、アンマネージ関数、及び／又は、対応しているライブラリのリストを生成するために、リスト生成モジュール２４０を使用する。いくつかの実施形態において、システム２００は、．ＮＥＴファイルにインポートされるアンマネージなインポート関数（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリのセットをフォーマットするために、リスト生成モジュール２４０を使用する。リスト生成モジュール２４０は、既定のフォーマットに従って、リスト及び／又はアンマネージ関数（例えば、アンマネージ関数名、及び／又は、対応しているライブラリ）をフォーマットする。既定のフォーマットの例は、（ｉ）小文字の英数字ストリング、（ｉｉ）ファイル拡張子の除去、（ｉｉｉ）ライブラリ拡張子の除去（例えば、対応しているライブラリ名からの．ｄｌｌの除去）、（ｉｖ）アンマネージ関数名および対応しているライブラリの付加、および、（ｖ）アンマネージ関数名と、対応しているライブラリとの間の事前定義されたセパレータの使用、を含む。いくつかの実施形態において、リスト生成モジュール２４０は、関数名（例えば、アンマネージ関数名）を対応しているライブラリに付加（ａｐｐｅｎｄ）し、そして、ドットまたはピリオド（例えば、「．」）によって、対応しているライブラリから、関数名を分離する。関数名およびライブラリを（例えば、「．」といった既定のセパレータを用いて）付加することにより文字列（ｓｔｒｉｎｇ）を決定することに応答して、リスト生成モジュール２４０は、そうしたエントリを、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに追加する。様々な実施形態に従って、リストに追加されるべきさらなるアンマネージ関数、及び／又は、対応しているライブラリがないと決定したことに応答して、リスト生成モジュール２４０は、予測モジュール２４５のリストを提供する。

【0062】

いくつかの実施形態において、システム２００は、予測モジュール２４５を含んでいる。システム２００は、ファイルが悪意のあるものか否かを予測するか、または、ファイルが悪意のあるものである可能性を予測するために、予測モジュール２４５を使用する。様々な実施形態に従って、予測モジュール２４５は、ファイルの．ＮＥＴヘッダに含まれる（または、参照される）情報に少なくとも部分的に基づいて、ファイルが悪意のあるものか否かを決定する。例えば、予測モジュール２４５は、ファイルに対応しているアンマネージＩｍｐｈａｓｈを決定し、そして、アンマネージＩｍｐｈａｓｈに少なくとも部分的に基づいて、ファイルが悪意のあるものか否かを決定する。

【0063】

様々な実施形態に従って、予測モジュール２４５は、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに関してハッシュを決定する。ハッシュの決定に関連して、様々なハッシュ関数が使用され得る。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含む。様々な他のハッシュ関数が実装され得る。予測モジュール２４５は、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定するために、ハッシュ関数を使用する。

【0064】

様々な実施形態に従って、予測モジュール２４５は、．ＮＥＴファイルが悪意のあるものか否かを決定するために、．ＮＥＴファイルの．ＮＥＴヘッダから取得された情報を使用する。いくつかの実施形態において、予測モジュール２４５は、．ＮＥＴファイルが悪意のあるものか否かを決定することに関連して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを使用する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、予測モジュール２４５は、アンマネージＩｍｐｈａｓｈが、悪意があると見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、予測モジュール２４５は、アンマネージＩｍｐｈａｓｈが、良性であると見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。いくつかの実施形態において、予測モジュール２４５は、特定のファイルに関する情報（例えば、分析されている．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈ）が、履歴ファイルのデータセット、および、特定のファイルが悪意のあるものか否かを示す履歴データセット（例えば、ＶｉｒｕｓＴｏｔａｌ^ＴＭといったサードパーティサービス）に関連する履歴情報、に含まれるか否かを決定する。特定のファイルに関する情報が、履歴ファイルおよび履歴情報のデータセットに含まれていない、または、利用可能でないと決定したことに応答して、予測モジュール２４５は、そのファイルを良性であると見なし得る（例えば、悪意のあるものではないと見なす）。特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報の例は、ＶｉｒｕｓＴｏｔａｌ（Ｒ）（ＶＴ）スコアに対応している。特定のファイルについてＶＴスコアが０より大きい場合に、その特定のファイルは、サードパーティサービスによって悪意があると見なされる。いくつかの実施形態において、特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報は、ファイルが悪意のあるものであるか、または、悪意のあるものである可能性が高いことを示すコミュニティベースのスコアまたはレーティング（例えば、評判スコア）といったソーシャルスコアに対応している。履歴情報（例えば、サードパーティサービス、コミュニティベースのスコア、等からのもの）は、特定のファイルを、他のベンダまたはサイバーセキュリティ組織が、悪意のあるものと見なすか否かを示す。

【0065】

システム２００は、ファイル（例えば、アンマネージＩｍｐｈａｓｈ）に対応しているハッシュまたは署名を決定し（例えば、計算し）、そして、履歴情報（例えば、ホワイトリスト、ブラックリスト、等）に対してルックアップを実行し得る。いくつかの実装において、予測モジュール２４５は、予測エンジン１７６に対応しており、または、同様である。システム２００（例えば、予測モジュール２４５）は、通信インターフェイス２０５を介して、ファイル（または、以前に悪意のあるもの、または、良性であると見なされたファイルについてのファイルまたはハッシュ／署名のセット）に関する履歴情報について、サードパーティ（例えば、サードパーティサービス）をクエリすることができる。システム２００（例えば、予測モジュール２４５）は、既定の間隔（例えば、顧客指定の間隔、等）でサードパーティをクエリすることができる。一つの例として、予測モジュール２４５は、毎日（または、ビジネス週間の最中には毎日）、新たに分析されたファイルの登録情報についてサードパーティをクエリすることができる。

【0066】

いくつかの実施形態において、システム２００は、通知モジュール２５０を含んでいる。システム２００は、ファイルが悪意のあるものか否かの指示を提供するために、通知モジュール２５０を使用する。例えば、通知モジュール２５０は、予測モジュール２４５から、ファイルが悪意のあるものか否かの指示（または、ファイルが悪意のあるものである可能性）を取得し、そして、ファイルが悪意のあるものか否かの指示を、１つ以上のセキュリティエンティティ、及び／又は、１つ以上のエンドポイントに提供する。別の例として、通知モジュール２５０は、ファイルのホワイトリスト及び／又はファイルのブラックリストに対する更新を、１つ以上のセキュリティエンティティ（例えば、ファイアウォール）、ノード、または、エンドポイント（例えば、クライアント端末）に提供する。様々な実施形態に従って、通知モジュール２５０は、ファイルに関連付けられたハッシュ、署名、または、他の一意の識別子（例えば、ファイルに対応しているアンマネージＩｍｐｈａｓｈ）を取得し、そして、ファイルに関連付けられたハッシュ、署名、または、他の一意の識別子に関連して、ファイルが悪意のあるものか否かの指示を提供する。

【0067】

種々の実施形態に従って、ファイルのハッシュは、既定のハッシュ関数を使用するハッシュ（例えば、ＭＤ５ハッシュ関数を使用するアンマネージＩｍｐｈａｓｈ、ファイルのＭＤ５ハッシュ、等）に対応している。セキュリティエンティティまたはエンドポイントは、受信したファイル（例えば、添付ファイル、等）のハッシュを計算し得る。セキュリティエンティティまたはエンドポイントは、ファイルに対応している計算されたハッシュが、良性ファイルのホワイトリスト、及び／又は、悪意のあるファイルのブラックリストといったセット内に含まれるか否かを決定し得る。マルウェアについての署名（例えば、受信されたファイルのハッシュ）が、悪意のあるファイルの署名のセット（例えば、悪意のあるファイルのブラックリスト）に含まれる場合に、セキュリティエンティティまたはエンドポイントは、エンドポイント（例えば、クライアントデバイス）へのマルウェアの送信を防止し、かつ／あるいは、それに応じて、マルウェアのオープンまたは実行を防止することができる。

【0068】

様々な実施形態に従って、ストレージ２１５は、ファイルシステムデータ２６０、ハッシュデータ２６２、及び／又は、キャッシュデータ２６４のうちの１つ以上を含んでいる。ストレージ２１５は、共有ストレージ（例えば、ネットワークストレージシステム）、及び／又はデータベースデータ、及び／又はユーザアクティビティデータを含んでいる。

【0069】

いくつかの実施形態において、ファイルシステムデータ２６０は、１つ以上のデータセット（例えば、ファイル及び／又はファイル属性、ファイルまたはハッシュに対する悪意があることのインジケータ（ｉｎｄｉｃａｔｏｒ）のマッピング、アンマネージＩｍｐｈａｓｈｅｓ、ファイルの署名または他の一意の識別子、ファイルまたはハッシュへの良性ファイルのインジケータのマッピング、ファイルの署名または他の一意の識別子、等についての１つ以上のデータセット）といった、データベースを備える。ファイルシステムデータ２６０は、ファイルに関する履歴情報（例えば、ファイルの悪意性）、安全である（例えば、不審でない）と見なされるファイルのホワイトリスト、不審または悪意があると見なされるファイル（例えば、悪意があると見なされる可能性が既定の／事前設定された可能性閾値を超えるファイル）のブラックリスト、不審または悪意のあるファイルに関連付けられた情報、等のデータを含んでいる。

【0070】

ハッシュデータ２６２は、１つ以上のファイルに関するハッシュ値といった、１つ以上のファイルに関するデータを含んでいる。いくつかの実施形態において、ハッシュデータ２６２は、ファイルが悪意のあるものか否かを決定するためにシステム２００によって分析されるファイルといった、ファイルについてのアンマネージＩｍｐｈａｓｈｅｓ、または、サードパーティよってなど、悪意のあるものであると以前に評価された履歴データセットを含んでいる。ハッシュデータ２６２は、ハッシュ値（アンマネージＩｍｐｈａｓｈｅｓ）の、悪意のある指示（例えば、対応しているものが悪意のあるものであり、または、良性であるとの指示、等）へのマッピングを含む。いくつかの実施形態において、ハッシュデータ２６２は、ファイルまたはファイルに関連する情報（例えば、スクリプト、バイトといった属性、構造、等）と、ファイルが悪意のあるものか、または、良性であるかの指示または可能性との間の関係および関連付けを含んでいる。例えば、ハッシュデータ２６２は、ハッシュ値（アンマネージＩｍｐｈａｓｈｅｓ）の、悪意があることの指示（例えば、対応しているものが悪意のあるものか、または、良性であるかの指示、等）へのマッピングを含んでいる。

【0071】

キャッシュデータ２６４は、ファイルが悪意のあるものか否かの予測に関する情報を含んでいる。一つの例として、予測キャッシュデータ２６４は、１つ以上のファイルが悪意のあるものか否かの指示を保管している。

【0072】

様々な実施形態に従って、メモリ２２０は、実行アプリケーションデータ（ｅｘｅｃｕｔｉｎｇ ａｐｐｌｉｃａｔｉｏｎ ｄａｔａ）２７０を含んでいる。実行アプリケーションデータ２７０は、ハッシュ関数を実行するアプリケーション、または、ファイルから情報を抽出するアプリケーションといった、アプリケーションの実行に関連して取得され、または、使用されるデータを含んでいる。実施形態において、アプリケーションは、クエリまたはタスクを受信及び／又は実行すること、実行されたクエリまたはタスクに応答する情報のレポート及び／又は構成を生成すること、かつ／あるいは、クエリまたはタスクに応答する情報をユーザに提供すること、のうちの１つ以上を実行する、１つ以上のアプリケーションを含んでいる。他のアプリケーションは、任意の他の適切なアプリケーションを含んでいる（例えば、インデックスメンテナンスアプリケーション、通信アプリケーション、機械学習モデルアプリケーション、疑わしいトラフィックを検出するためのアプリケーション、文書作成アプリケーション、レポート作成アプリケーション、ユーザインターフェイスアプリケーション、データ分析アプリケーション、異常検出アプリケーション、ユーザ認証アプリケーション、セキュリティポリシ管理／更新アプリケーション、等）。

【0073】

図３Ａは、例示的な．ＮＥＴファイルについての．ＮＥＴヘッダに係るＩｍｐｌＭａｐテーブルの図である。図３Ａに示されるテーブル３００には、３２ビットＤＬＬサンプルのＩｍｐｌＭａｐテーブルが提供されている。いくつかの実施形態において、サンプルについてのＩｍｐｌＭａｐテーブルは、３２ビットＤＬＬサンプルを、デバッガ、及び／又は、．ＮＥＴアセンブリエディタに入力することによって取得される。そうしたデバッガ、及び／又は、．ＮＥＴアセンブリエディタの例は、ｄｎＳｐｙである。様々な他のデバッガ、及び／又は、．ＮＥＴアセンブリエディタが実装され得る。

【0074】

様々な実施形態に従って、システムは、ＩｍｐｌＭａｐテーブルに少なくとも部分的に基づいて、＃Ｓｔｒｉｎｇｓストリームへのインデックスを決定する。いくつかの実施形態において、＃Ｓｔｒｉｎｇｓストリームへのインデックスは、ＩｍｐｏｒｔＮａｍｅテーブルに対応している。＃Ｓｔｒｉｎｇｓストリームは、一般的に、．ＮＥＴファイルのストリングの大部分が存在する、ヌル終端ストリング（ｎｕｌｌ－ｔｅｒｍｉｎａｔｅｄ ｓｔｒｉｎｇ）のアレイに対応している。システムは、ＩｍｐｏｒｔＮａｍｅとラベル付けされた列（ｃｏｌｕｍｎ）を使用して、＃Ｓｔｒｉｎｇｓストリームへのインデックスを決定する。関数の名前は、ＩｍｐｏｒｔＮａｍｅ列からのインデックス値を使用して、決定され得る。テーブル３００では、ＩｍｐｏｒｔＮａｍｅの値に対応している関数の名前が情報列に提供される。

【0075】

ＩｍｐｏｒｔＮａｍｅからのインデックス値、及び／又は、インポート関数の関数名を決定したことに応答して、システムは、対応しているライブラリ（例えば、ＤＬＬ）についてのライブラリ名を決定する。いくつかの実施形態において、システムは、．ＮＥＴファイルのＭｏｄｕｌｅＲｅｆテーブルに少なくとも部分的に基づいて、ライブラリ（例えば、ライブラリ名）を決定する。

【0076】

図３Ｂは、例示的な．ＮＥＴファイルに係るＭｏｄｕｌｅＲｅｆテーブルの図である。図３Ｂに示されるテーブル３１０には、図３Ａのテーブル３００に関して分析された３２ビットＤＬＬサンプルのＭｏｄｕｌｅＲｅｆテーブルが提供さていれる。いくつかの実施形態において、サンプルのＭｏｄｕｌｅＲｅｆテーブルは、３２ビットＤＬＬサンプルを、デバッガ、及び／又は、．ＮＥＴアセンブリエディタに入力することによって取得される。

【0077】

様々な実施形態に従って、システムは、対応しているライブラリ（例えば、ライブラリ名）を決定するために、ＩｍｐｌＭａｐテーブルのＩｍｐｏｒｔＮａｍｅフィールド（例えば、列）からのインデックス値を、インデックスとして使用する。システムは、インデックス値を、テーブル３１０の名前列におけるルックアップとして使用する。例えば、名前列は、＃Ｓｔｒｉｎｇｓストリームに対するインデックスである。ＭｏｄｕｌｅＲｅｆテーブルの情報（Ｉｎｆｏ）列は、フィールドの指示を含んでいる。例えば、名前（Ｎａｍｅ）列のインデックス値０ｘ１８Ｆ３に対応しているライブラリ名は、ｋｅｒｎｅｌ３２．ｄｌｌである。

【0078】

．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈの決定に関連して、システムは、アンマネージ関数のリストを決定する。アンマネージ関数のリストは、既定のフォーマットまたはシンタックスを使用して、生成される。例えば、システムは、インポート関数に対応しているライブラリ名を取得し、そして、拡張子を除去する。システムは、ライブラリが「．ｄｌｌ」拡張子を有するか否かを決定し、そして、有する場合に、システムは、拡張子を除去する。別の例として、システムは、任意の大文字を小文字に変換するために、関数名およびライブラリ名をフォーマットする。いくつかの実施形態において、システムは、インポート関数（例えば、アンマネージなインポート関数）の関数名と、インポート関数に対応しているライブラリ名との組み合わせに対応している、文字列を構築する。例えば、システムは、ライブラリ名を関数名に付加するやり方で文字列を構築し、そして、既定のセパレータ（例えば、「．」）が、ライブラリ名と関数名との間に含まれている。様々な実施形態に従って、システムは、＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞というフォーマットに従って、文字列を決定する。システムは、次いで、文字列を、アンマネージなインポート関数のリスト（例えば、アンマネージＩｍｐｈａｓｈが決定されたリスト）に追加する。

【0079】

図３Ａのテーブル３００および図３Ｂのテーブル３１０に対応している例示的なサンプルを使用すると、ライブラリ－関数名のペアのリストは、以下のとおりである。ｋｅｒｎｅｌ３２．ｃｒｅａｔｅｐｒｏｃｅｓｓ、ｋｅｒｎｅｌ３２．ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｒｅａｄｐｒｏｃｅｓｓｍｅｍｏｒｙ、ｋｅｒｎｅｌ３２．ｗｒｉｔｅｐｒｏｃｅｓｓｍｅｍｏｒｙ、ｎｔｄｌｌ．ｎｔｕｎｍａｐｖｉｅｗｏｆｓｅｃｔｉｏｎ、ｋｅｒｎｅｌ３２．ｖｉｒｔｕａｌａｌｌｏｃｅｘ、ｋｅｒｎｅｌ３２．ｒｅｓｕｍｅｔｈｒｅａｄ、ｋｅｒｎｅｌ３２．ｌｏａｄｌｉｂｒａｒｙ、ｋｅｒｎｅｌ３２．ｇｅｔｐｒｏｃａｄｄｒｅｓｓである。リスト内のエントリは、コンマ、セミコロン、コロンといった、既定のセパレータによって分離され得る。

【0080】

様々な実施形態に従って、．ＮＥＴファイルについてのアンマネージなインポート関数のリストを決定したことに応答して、システムは、既定のハッシュ関数（例えば、ＭＤ５、ＳＨＡ１、ＳＨＡ－２５６、等）を使用して、リストのハッシュを実行する。一つの例として、図３Ａの表３００および図３Ｂの表３１０において分析されたサンプルを使用している、アンマネージなインポート関数のリストについてのアンマネージＩｍｐｈａｓｈは、（ハッシュ関数としてＳＨＡ－２５６を使用して）
４ｂ３８６ｆａｆ５３７８３ｃ４ｆｄ１７ｄｅ６ｃ０４３ｆｄ３１３７４３０２ａ４４５５４５６ｂ４ａｆ３ｄ７８ａｂｄ７４ｃ８６５ｆｆ８である。

【0081】

図３Ｃは、例示的な．ＮＥＴファイルについての．ＮＥＴヘッダに係るＩｍｐｌＭａｐテーブルの図である。図３Ｃに示されるテーブル３２０では、３２ビットＥＸＥサンプルのＩｍｐｌＭａｐテーブルが提供されている。３２ビットＥＸＥは、Ｖｉｓｕａｌ Ｃ＋＋コンパイラおよびＣ＋＋／ＣＬＩ拡張を使用して作成されたものである。いくつかの実施形態において、サンプルのＩｍｐｌＭａｐテーブルは、３２ビットＤＬＬサンプルをデバッガ、及び／又は、．ＮＥＴアセンブリエディタに入力することによって取得される。そうしたデバッガ、及び／又は、．ＮＥＴアセンブリエディタの一つの例は、ｄｎＳｐｙである。様々な他のデバッガ、及び／又は、．ＮＥＴアセンブリエディタが実装され得る。

【0082】

図３Ｃに示されるように、テーブル３２０の最初の３行は、情報（Ｉｎｆｏ）列に含まれる値を有している。従って、最初の３行について、関数名および対応しているライブラリ名を決定するために（例えば、ライブラリ－関数名ペアを決定するため）、図３Ａの表３００および図３Ｂの表３１０に関連して説明されたプロセスが実行され得る。しかしながら、図３ＣのＩｍｐｌＭａｐテーブルの残りの行は、ヌル値または０を有している。対応している関数がサンプル作成者によって使用されず、代わりに、内部で使用されるＣ＋＋／ＣＬＩ作成ランタイムメソッドの一部であるため、残りの行にヌル値またはゼロエントリが生じ得る。いくつかの実施形態において、システムは、ファイルのＭｅｔｈｏｄＤｅｆテーブルに基づいて、関数名およびライブラリ名を決定する。例えば、システムは、ＩｍｐｌＭａｐテーブル（例えば、テーブル３２０）のＭｅｔｈｏｄＦｏｒｗａｒｄ列に含まれる値を、ＭｅｔｈｏｄＤｅｆテーブルに対するインデックスとして使用する。一つの例として、ＭｅｍｂｅｒＦｏｒｗａｒｄ値は、ＭｅｔｈｏｄＤｅｆテーブルへのコード化インデックスと呼ばれる（例えば、コード化インデックスは、．ＮＥＴ規格ＥＣＭＡ－３３５において定義されている）。

【0083】

様々な実施形態に従って、システムは、図３ＣのＩｍｐｌＭａｐテーブルのＭｅｔｈｏｄＦｏｒｗａｒｄ列の残りの行から値を取得し、ＭｅｔｈｏｄＦｏｒｗａｒｄ列から取得された値をデコーディングし、デコーディングされた値をＭｅｔｈｏｄＤｅｆテーブルに対するインデックスとして使用する。一つの例として、ＭｅｍｂｅｒＦｏｒｗａｒｄ列の４番目の行からの値は０ｘ９９であり、これは７６に対応するようにデコーディングされる。従って、７６は、ＭｅｔｈｏｄＤｅｆテーブルから情報を決定するためのインデックス値として使用される。

【0084】

図３Ｄは、例示的な．ＮＥＴファイルについてのＭｅｔｈｏｄＤｅｆテーブルの図である。図３Ｄに示される表３３０には、図３Ｃの表３２０に関して分析されたサンプルのＭｅｔｈｏｄＤｅｆ表が提供されている。いくつかの実施形態において、サンプルについてのＭｅｔｈｏｄＤｅｆテーブルは、サンプルをデバッガ、及び／又は、．ＮＥＴアセンブリエディタに入力することによって取得される。

【0085】

ＩｍｐｌＭａｐのＭｅｔｈｏｄＦｏｒｗａｒｄ列から取得されたインデックス値を使用して、システムは、＃Ｓｔｒｉｎｇｓストリームに対するインデックスを決定する。例えば、システムは、ＩｍｐｌＭａｐのＭｅｔｈｏｄＦｏｒｗａｒｄ列から取得されたインデックス値を、ＭｅｔｈｏｄＤｅｆテーブルの名前列におけるルックアップとして使用する。ＭｅｔｈｏｄＦｏｒｗａｒｄ列からのインデックス７６に対応している名前（Ｎａｍｅ）列のインデックス値は０ｘ１８３１である。表３３０に示されるように、ＭｅｔｈｏｄＤｅｆ表のＩｎｆｏ列は、関数名が＿ａｍｓｇ＿ｅｘｉｔであることを示している。

【0086】

図３Ｅは、例示的な．ＮＥＴファイルについてのＭｏｄｕｌｅＲｅｆテーブルの図である。図３Ｅに示される表３４０には、図３Ｃの表３２０に関して分析されたサンプルのＭｏｄｕｌｅＲｅｆ表が提供されている。いくつかの実施形態において、サンプルのＭｏｄｕｌｅＲｅｆ表は、サンプルをデバッガ、及び／又は、．ＮＥＴアセンブリエディタに入力することによって取得される。

【0087】

様々な実施形態に従って、システムは、関数名（例えば、ＭｅｔｈｏｄＤｅｆテーブルから取得された関数名）を決定したことに応答して、ライブラリ名を決定する。例えば、システムは、ＩｍｐｌＭａｐテーブル（例えば、図３Ｃのテーブル３２０）内のルックアップを実行し、そして、ＩｍｐｏｒｔＳｃｏｐｅ列における値が残りの行について２であると決定する。システムは、ＩｍｐｏｒｔＳｃｏｐｅ列からのインデックス値２をＭｏｄｕｌｅＲｅｆテーブルのインデックスとして使用する。インデックス値２（例えば、ＩｍｐｌＭａｐテーブルのＩｍｐｏｒｔＳｃｏｐｅ列から）を使用して、ＭｏｄｕｌｅＲｅｆテーブル（例えば、テーブル３４０）内でルックアップを実行することに応答して、システムは、名前列内の値も、また、０であると決定する。従って、システムは、ＭｏｄｕｌｅＲｅｆがライブラリ名の指示を提供しないと決定する。

【0088】

様々な実施形態に従って、ＭｏｄｕｌｅＲｅｆが関数に対応しているライブラリ名の指示を提供しないと決定したことに応答して、システムは、ＭｅｔｈｏｄＤｅｆテーブルから取り出された（ｒｅｔｒｉｅｖｅｄ）関数名を使用し、そして、ＰＥヘッダ内のインポートテーブルを構文解析するように決定する。ＰＥヘッダ内のインポートテーブルは、静的に使用される関数が存在する、それらのペア応しているライブラリ名（ＤＬＬ）を有するファイルの全ての静的に使用される関数を含んでいる。例えば、システムは、ＰＥヘッダ内のインポートテーブルを構文解析するために、ＰＥヘッダパーサを使用する。ＰＥヘッダパーサの一つの例は、Ｐｙｔｈｏｎでコード化されたＰＥヘッダパーサである、ｐｅｆｉｌｅである（例えば、ｐｅｆｉｌｅと呼ばれるオープンソースプロジェクト）。いくつかの実施形態において、システムは、ＭｅｔｈｏｄＤｅｆテーブルから取得された関数名と、ＰＥヘッダのインポートテーブル内の関数との一対一（１：１）比較を実行する。一つの例として、Ｃ＋＋で書かれたファイル（混合アセンブリのようなもの）は、インポートテーブル内の関数名としていわゆる修飾名を有することができる。これらの名前を作成するプロセスは、名前マングリング（ｎａｍｅ ｍａｎｇｌｉｎｇ）として知られている。そうした修飾された関数名は、関数がｅｘｔｅｒｎ「Ｃ」として定義されている場合を除いて、Ｃ＋＋コンパイラによって自動的に全てのＣ＋＋関数に対して作成される。

【0089】

図３Ｆは、例示的な．ＮＥＴファイルについてのＩｍｐｏｒｔテーブルの図である。図３Ｆに示される例において、テーブル３５０は、．ＮＥＴファイルのＰＥヘッダに含まれるインポートテーブルである。

【0090】

図３Ｇは、例示的な．ＮＥＴファイルについてのＭｅｔｈｏｄＤｅｆテーブルの図である。示される例において、テーブル３６０は、．ＮＥＴファイルのＭｅｔｈｏｄＤｅｆテーブルである。いくつかの実施形態において、ＭｅｔｈｏｄＤｅｆテーブルから取得された関数名がＰＥヘッダに含まれるインポートテーブル内の関数名と一致するとシステムが決定したことに応答して、システムは、インポートテーブルから対応しているライブラリ名を取得する。様々な実施形態に従って、システムは、対応しているライブラリ名を取得するために、ＭｅｔｈｏｄＤｅｆと、ＰＥヘッダに含まれるインポートテーブルとの間で、一致する関数名のルックアップを実行する。

【0091】

．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈの決定に関連して、システムは、アンマネージ関数のリストを決定する。アンマネージ関数のリストは、既定のフォーマットまたはシンタックスを使用して生成される。例えば、システムは、インポート関数に対応しているライブラリ名を取得し、そして、拡張子を除去する。システムは、ライブラリが「．ｄｌｌ」拡張子（ｅｘｔｅｎｓｉｏｎ）を有するか否かを決定し、そして、有する場合に、システムは拡張子を除去する。別の例として、システムは、任意の大文字を小文字に変換するために、関数名およびライブラリ名をフォーマットする。いくつかの実施形態において、システムは、インポート関数（例えば、アンマネージなインポート関数）の関数名と、インポート関数に対応しているライブラリ名との組み合わせに対応する、文字列を構築する。例えば、システムは、ライブラリ名を関数名に付加する方法で文字列を構築し、そして、既定のセパレータ（例えば、「．」）が、ライブラリ名と関数名との間に含まれる。様々な実施形態に従って、システムは、＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞というフォーマットに従った文字列を決定する。システムは、次いで、アンマネージなインポート関数のリスト（例えば、アンマネージＩｍｐｈａｓｈが決定されたリスト）に対して文字列を追加する。

【0092】

図３Ａのテーブル３００および図３Ｂのテーブル３１０に対応している例示的なサンプルを使用すると、ライブラリ－関数名ペアのリストは、以下とおりである。ｎｔｄｌｌ．ｚｗａｌｌｏｃａｔｅｖｉｒｔｕａｌｍｅｍｏｒｙ、ｎｔｄｌｌ．ｚｗｆｒｅｅｖｉｒｔｕａｌｍｅｍｏｒｙ、ｎｔｄｌｌ．ｌｄｒｇｅｔｐｒｏｃｅｄｕｒｅａｄｄｒｅｓｓ、ｍｓｖｃｒ８０．ａｍｓｇ＿ｅｘｉｔ、ｋｅｒｎｅｌ３２．ｓｌｅｅｐ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｔｈｒｏｗｍｏｄｕｌｅｌｏａｄｅｘｃｅｐｔｉｏｎ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｔｈｒｏｗｍｏｄｕｌｅｌｏａｄｅｘｃｅｐｔｉｏｎ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｄｏｄｌｌｌａｎｇｕａｇｅｓｕｐｐｏｒｔｖａｌｉｄａｔｉｏｎ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｔｈｒｏｗｎｅｓｔｅｄｍｏｄｕｌｅｌｏａｄｅｘｃｅｐｔｉｏｎ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｒｅｇｉｓｔｅｒｍｏｄｕｌｅｕｎｉｎｉｔｉａｌｉｚｅｒ、．＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｄｏｃａｌｌｂａｃｋｉｎｄｅｆａｕｌｔｄｏｍａｉｎ、ｍｓｖｃｒ８０．＿ｃｅｘｉｔ、ｍｓｖｃｒ８０．＿ｅｎｃｏｄｅ＿ｐｏｉｎｔｅｒ、ｍｓｖｃｒ８０．＿ｄｅｃｏｄｅ＿ｐｏｉｎｔｅｒ、ｍｓｖｃｒ８０．＿ｅｎｃｏｄｅｄ＿ｎｕｌｌ、ｍｓｖｃｒ８０．＿ｆｒａｍｅｕｎｗｉｎｄｆｉｌｔｅｒ。リスト内のエントリは、コンマ、セミコロン、コロン、等といった、既定のセパレータによって分離されてよい。ライブラリ関数ペア＜ｃｒｔｉｍｐｌｅｍｅｎｔａｔｉｏｎｄｅｔａｉｌｓ＞．ｔｈｒｏｗｍｏｄｕｌｅｌｏａｄｅｘｃｅｐｔｉｏｎは、関数が、いわゆるオーバーロードされた関数であるため、２回含まれる。そうした関数は、同じ名前を有するが、それらのパラメータタイプ、数、または、戻り値（ｒｅｔｕｒｎ ｖａｌｕｅ）が異なっている。従って、これらは異なる関数である。

【0093】

様々な実施形態に従って、．ＮＥＴファイルについてのアンマネージなインポート関数のリストを決定したことに応答して、システムは、既定のハッシュ関数（例えば、ＭＤ５、ＳＨＡ１、ＳＨＡ－２５６、等）を使用して、リストのハッシュを実行する。一つの例として、図３Ａの表３００および図３Ｂの表３１０で分析されたサンプルを使用する、アンマネージなインポート関数のリストについてのアンマネージＩｍｐｈａｓｈは（ハッシュ関数としてＳＨＡ－２５６を使用して）、
ｃｄ２ｆ２７ｂ６４２ａ８５ｃ３ｆ０ｃ１０ｄｂ４ｅ８８７ｄ５０４ｄ３ｂ４ｃ０８８２ｆ９２６４９９４３６７ｃ０ｃ９ｂ４ｅａ７ａ５３７である。

【0094】

いくつかの実施形態において、システムは、既定のフォーマットに従って、リストを変換またはフォーマットする。例えば、ライブラリ＜－＞関数（＜－＞ｍａｐｐｉｎｇｆｌａｇｓ）名ペアのリストは、コンマで分離された文字列へと変換される。システムは、単一のリスト項目を有する（ライブラリ＜－＞関数ペア）、コンマで分離された文字列を作成する。単一のリスト項目を有するコンマで分離された文字列を変換／作成することに応答して、システムは、そうした文字列に関して決定する（例えば、ハッシュを計算する）。

【0095】

図４は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス４００は、図１のシステム１００及び／又は図２のシステム２００によって、少なくとも部分的に実施される。いくつかの実装において、プロセス４００は、ネットワーク（例えば、セキュリティエンティティ及び／又はクライアントデバイスといったネットワークエンドポイント）に対してサービスを提供することに関連するといった、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス４００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するといった、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス４００は、電子メール添付ファイルなどのファイルを実行すること又は開くことに関連するといった、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって、実装され得る。

【0096】

４１０において、サンプルが受信される。いくつかの実施形態において、システムは、セキュリティエンティティ（例えば、ファイアウォール）、エンドポイント（例えば、クライアントデバイス）、等から、サンプル（例えば、．ＮＥＴファイル）を受信する。例えば、電子メールまたはインスタントメッセージといった通信にファイルが添付されていると決定したことに応答して、セキュリティエンティティまたはエンドポイントは、ファイルをシステムに提供する（例えば、送信する）。サンプルは、ファイルが悪意のあるものか否かを決定するための要求に関連して受信され得る。

【0097】

プロセス４００がセキュリティエンティティによって実施される場合に、サンプルは、適用可能なネットワークエンドポイントへのトラフィックのルーティングに関連するなどして、受信され得る（例えば、ファイアウォールは、クライアントデバイスに向けられた電子メールの電子メール添付ファイルからサンプルを取得する）。プロセス４００がクライアントデバイスによって実装される場合において、サンプルは、着信／発信情報をモニタリングするアプリケーションまたはレイヤによって、受信され得る。例えば、プロセス（例えば、アプリケーション、オペレーティングシステムプロセス、等）は、電子メール添付ファイル、インスタントメッセージングプログラムを介して交換されるファイル、等をモニタリングし、そして、取得するためにバックグラウンドで実行され得る。

【0098】

４２０では、インポートされたＡＰＩ関数名が、サンプルの．ＮＥＴヘッダを使用して、取得される。いくつかの実施形態において、サンプル、及び／又は、サンプル（例えば、．ＮＥＴファイル）が悪意のあるものか否かを評価するための要求を受信したことに応答して、システムは、サンプルを解析して、サンプルの．ＮＥＴヘッダに関連する（例えば、それに含まれる）情報を取得する。

【0099】

様々な実施形態に従って、システムは．ＮＥＴヘッダを決定し、そして、．ＮＥＴヘッダによってインポートされる（または、参照される）インポート関数を取得する。例えば、システムは、．ＮＥＴファイルの．ＮＥＴヘッダに少なくとも部分的に基づいて、インポートされたＡＰＩ関数名を取得する。システムは、．ＮＥＴヘッダに含まれる１つ以上のデータストリーム、及び／又は、．ＮＥＴヘッダに含まれる（または、．ＮＥＴヘッダによって参照される）１つ以上のテーブルを取得する。例えば、システムは、．ＮＥＴヘッダに含まれる＃Ｓｔｒｉｎｇｓストリームを取得する。別の例として、システムは、．ＮＥＴファイルから（例えば、．ＮＥＴヘッダから）ＩｍｐｌＭａｐを取得する。ＩｍｐｌＭａｐは、．ＮＥＴファイルの任意のインポートされたアンマネージ関数に関する様々な情報を含み得る。いくつかの実施形態において、システムは、．ＮＥＴファイルにインポートされる、インポート関数のセット（例えば、インポートされたＡＰＩ関数名）を決定する。

【0100】

いくつかの実施形態において、システムは、．ＮＥＴファイルの．ＮＥＴヘッダを介してインポートされたアンマネージ関数のリストといった、．ＮＥＴファイルに含まれるか、または、．ＮＥＴファイルによって参照されるアンマネージ関数のセットを決定する（例えば、取得する）。例えば、システムは、．ＮＥＴファイルにインポートされたインポート関数（例えば、インポートされたＡＰＩ関数名）のセットから、アンマネージインポート関数のセットを決定する。システムは、．ＮＥＴヘッダに含まれる（または、．ＮＥＴヘッダによって参照される）情報を使用して、アンマネージコードまたはアンマネージ関数（例えば、アンマネージ関数および対応しているライブラリ）を決定する。いくつかの実施形態において、システムは、．ＮＥＴファイルにインポートされた、使用されたアンマネージｗｉｎ３２ ＡＰＩ関数のセットを決定する。

【0101】

４３０では、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュが決定される。いくつかの実施形態において、インポートされたＡＰＩ関数名を取得したことに応答して、システムは、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定する（例えば、計算する）。例えば、システムは、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを計算する。

【0102】

アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを決定したことに関連して、システムは、．ＮＥＴファイルにインポートされたアンマネージなインポート関数（または、アンマネージ関数の名前）、及び／又は、対応しているライブラリのセットのリストを決定し、そして、そうしたリストのハッシュを決定する。アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストは、既定の順序に従って決定される。例えば、インポートされたアンマネージ関数、及び／又は、対応しているライブラリの順序付けは、アンマネージ関数が、．ＮＥＴヘッダの要素に含まれる順序（例えば、アンマネージ関数が、．ＮＥＴテーブルに含まれるか、または、それによって参照される＃Ｓｔｒｉｎｇｓストリーム及び／又はテーブルに含まれる順序）に対応している。アンマネージ関数がリストに追加される（または、リストが配置される）様々な他の順序が実施され得る。システムは、既定のフォーマットまたはシンタックスに従って、リスト、及び／又は、アンマネージ関数（例えば、アンマネージ関数名、及び／又は、対応しているライブラリ）をフォーマットする。既定のフォーマットの例は、（ｉ）小文字の英数字ストリング、（ｉｉ）ファイル拡張子の除去、（ｉｉｉ）ライブラリ拡張子の除去（例えば、対応しているライブラリ名からの．ｄｌｌの除去）、（ｉｖ）アンマネージ関数名および対応しているライブラリの付加、および、（ｖ）アンマネージ関数名と、対応しているライブラリとの間の事前定義されたセパレータの使用、が含まれる。いくつかの実施形態において、システムは、関数名（例えば、アンマネージ関数名）を対応しているライブラリに付加し、そして、ドットまたはピリオド（例えば、「．」）によって、対応しているライブラリから関数名を分離する。関数名およびライブラリを（例えば、「．」といった既定のセパレータを用いて）付加することによって文字列を決定したことに応答して、システムは、そうしたエントリを、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに追加する。

【0103】

様々な実施形態に従って、システムは、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに関してハッシュを決定する。ハッシュの決定に関連して、様々なハッシュ関数を使用することができる。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含む。様々な他のハッシュ関数が実装され得る。システムは、ハッシュ関数を使用して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定する。

【0104】

４４０では、サンプルが悪意のあるものか否かについての決定が行われる。いくつかの実施形態において、アンマネージなインポートされたＡＰＩ関数名を決定したことに応答して、システムは、サンプルが悪意のあるものか否かを決定することに関連してハッシュ（例えば、アンマネージＩｍｐｈａｓｈ）を使用する。

【0105】

いくつかの実施形態において、システムは、．ＮＥＴファイルが悪意のあるものか否かを決定することに関連して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを使用する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定することに応答して、システムは、アンマネージＩｍｐｈａｓｈが悪意のあるものとみなされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。サンプル（例えば、分析されているファイル）についてのアンマネージＩｍｐｈａｓｈが、履歴データセット内の悪意のあるファイル（例えば、悪意のあるファイルのＩｍｐｈａｓｈリストに含まれるレコード）のアンマネージブラックリストと一致する場合に、システムは、サンプルを悪意のあるものと見なす。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、システムは、アンマネージＩｍｐｈａｓｈが、良性と見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。サンプル（例えば、分析されているファイル）のアンマネージＩｍｐｈａｓｈが、履歴データセット内の良性ファイル（例えば、良性ファイルのホワイトリストに含まれるレコード）のアンマネージＩｍｐｈａｓｈと一致する場合に、システムは、サンプルを良性であると見なす。いくつかの実施形態において、システムは、特定のファイル（例えば、分析されている．ＮＥＴファイルに対応するアンマネージＩｍｐｈａｓｈ）に関する情報が、履歴ファイルのデータセットに含まれるか否か、および、特定のファイル（例えば、ＶｉｒｕｓＴｏｔａｌ^ＴＭといったサードパーティサービス）が悪意のあるものか否かを示す履歴データセットに関連する履歴情報を決定する。一つの例として、特定のファイルに関する情報が履歴ファイルおよび履歴情報のデータセットに含まれていない、または、利用可能でないと決定したことに応答して、システムは、そのファイルを良性であると見なす（例えば、そのファイルを悪意のあるものではないと見なす）。特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報の例は、ＶｉｒｕｓＴｏｔａｌ^ＴＭ（ＶＴ）スコアに対応している。特定のファイルについてＶＴスコアが０より大きい場合、その特定のファイルは、サードパーティサービスによって悪意のあるものと見なされる。いくつかの実施形態において、特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報は、ファイルが悪意のあるものか、または、悪意のあるものである可能性が高いことを示す、コミュニティベースのスコアまたはレーティング（例えば、評判スコア）といったソーシャルスコアに対応している。履歴情報（例えば、サードパーティサービス、コミュニティベースのスコア、等からのもの）は、他のベンダまたはサイバーセキュリティ組織が、特定のファイルを悪意のあるものと見なすか否かを示す。

【0106】

サンプルが悪意のあるものであるという４４０での決定に応答して、プロセス４００は、４５０に進み、そこでは、サンプルが悪意のあるものであるという指示が提供される。

【0107】

４４０においてサンプルが悪意のあるものであると決定したことに応答して、プロセス４００は、４５０に進み、サンプルが悪意のあるものであるという指示が提供される。例えば、サンプルが悪意のあるものであるという指示は、そこからサンプルが受信される、コンポーネントに対して提供され得る。一つの例として、システムは、サンプルが悪意のあるものであるという指示を、セキュリティエンティティに提供する。別の例として、システムは、サンプルが悪意のあるものであるという指示を、クライアントデバイスに提供する。一つの例として、セキュリティは、サンプルが悪意のあるものであるという指示を、クライアントデバイスに提供する。いくつかの実施形態において、サンプルが悪意のあるものであるという指示は、クライアントデバイスのユーザ及び／又はネットワーク管理者といったユーザに提供される。

【0108】

様々な実施形態に従って、サンプルが悪意のあるものであるという指示を受信したことに応答して、能動的な措置（ａｃｔｉｖｅ ｍｅａｓｕｒｅ）が実行され得る。能動的な措置は、１つ以上のセキュリティポリシに従って（例えば、少なくとも部分的に基づいて）、実行され得る。一つの例として、１つ以上のセキュリティポリシが、ネットワーク管理者、悪意のあるファイルの検出を提供するサービスに対する顧客（例えば、組織／会社）などによって、事前設定され得る。実行され得る能動的な措置の例は、以下を含む。ファイルを隔離すること（例えば、ファイルを検疫すること（ｑｕａｒａｎｔｉｎｉｎｇ））、ファイルを削除すること、悪意のあるファイルが検出されたことをユーザに警告するようにユーザに促すこと、デバイスがファイルを開くか、または、実行しようとするときにユーザにプロンプトを提供すること、ファイルの送信をブロックすること、悪意のあるファイルのブラックリストを更新すること（例えば、ファイルが悪意のあるものであるという指示へのファイルのハッシュのマッピング、等）。

【0109】

４４０においてサンプルが悪意のあるものではないと決定したことに応答して、プロセス４００は、４６０に進む。いくつかの実施形態において、サンプルが悪意のあるものではないと決定したことに応答して、ファイルが悪意のあるものではないという指示に対するファイル（または、ファイルのハッシュ／署名）のマッピングが更新される。例えば、良性ファイルのホワイトリストは、サンプル、または、ハッシュ、署名、もしくは、サンプルに関連する他の一意の識別子を含むように、更新される。

【0110】

４６０では、プロセス４００が完了したか否かについての決定が行われる。いくつかの実施形態においては、さらなるサンプルが分析されるべきではない（例えば、ファイルについてのさらなる予測は必要とされない）と決定したことに応答して、プロセス４００は、完了したと決定され、管理者は、プロセス４００が一時停止または停止されるべきであることを示す、など。プロセス４００が完了したと決定したことに応答して、プロセス４００は、終了する。プロセス４００が完了していないと決定したことに応答して、プロセス４００は、４１０に戻る。

【0111】

図５は、様々な実施形態に従った、ファイルが悪意のあるものか否かを決定するための方法に係るフローチャートである。いくつかの実施形態において、プロセス５００は、図１のシステム１００及び／又は図２のシステム２００によって、少なくとも部分的に、実施される。いくつかの実装において、プロセス５００は、ネットワーク（例えば、セキュリティエンティティ、及び／又は、クライアントデバイスといったネットワークエンドポイント）にサービスを提供することに関連するなど、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス５００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス５００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって、実装され得る。

【0112】

様々な実施形態に従って、プロセス５００は、図４のプロセス４００の４４０に関連して呼び出される。

【0113】

５１０では、リストのハッシュが取得される。いくつかの実施形態において、システムは、アンマネージＩｍｐｈａｓｈを取得する（例えば、受信する、決定する、等）。例えば、システムは、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュを受信する。

【0114】

５２０では、ハッシュが、マッピングのクエリに関連して使用される。リスト（例えば、アンマネージＩｍｐｈａｓｈ）のハッシュを受信したことに応答して、システムは、悪意のあるファイル及び／又は良性ファイルの履歴データセットに対してルックアップを実行する。例えば、履歴データセットは、アンマネージＩｍｐｈａｓｈｅｓと、対応しているファイルが悪意のあるものであるか、または、良性であるかの指示との間の関連付けを含んでいる。

【0115】

いくつかの実施形態において、システムは、．ＮＥＴファイルが悪意のあるものか否かを決定することに関連して、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを使用する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、システムは、アンマネージＩｍｐｈａｓｈが、悪意のあるものとみなされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。一つの例として、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定したことに応答して、システムは、アンマネージＩｍｐｈａｓｈが、良性と見なされるファイルのアンマネージＩｍｐｈａｓｈに一致するか否かを決定する。いくつかの実施形態において、システムは、特定のファイルに関する情報（例えば、分析されている．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈ）が、履歴ファイルのデータセット、および、特定のファイルが悪意のあるものか否かを示す履歴データセット（例えば、ＶｉｒｕｓＴｏｔａｌ^ＴＭといったサードパーティサービス）に関連する履歴情報、に含まれるか否かを決定する。一つの例として、特定のファイルに関する情報が、履歴ファイルおよび履歴情報のデータセットに含まれていない、または、利用可能でないと決定したことに応答して、システムは、そのファイルを良性であると見なす（例えば、そのファイルを悪意のあるものではないと見なす）。特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報の例は、ＶｉｒｕｓＴｏｔａｌ（Ｒ）（ＶＴ）スコアに対応している。特定のファイルについてＶＴスコアが０より大きい場合に、その特定のファイルは、サードパーティサービスによって悪意があると見なされる。いくつかの実施形態において、特定のファイルが悪意のあるものか否かを示す履歴ファイルに関連する履歴情報は、ファイルが悪意のあるものであるか、または、悪意のあるものである可能性が高いことを示すコミュニティベースのスコアまたはレーティング（例えば、評判スコア）といったソーシャルスコアに対応している。履歴情報（例えば、サードパーティサービス、コミュニティベースのスコア、等からのもの）は、特定のファイルを、他のベンダまたはサイバーセキュリティ組織が、悪意のあるものと見なすか否かを示す。

【0116】

５３０では、ハッシュが悪意のあるファイルに対応していることをマッピングが示すか否かについての決定が行われる。

【0117】

５３０での、ハッシュが悪意のあるファイルに対応していることをマッピングが示すと決定したことに応答して、プロセス５００は、５４０に進み、そこで、サンプルは悪意のあるものであると決定される。

【0118】

５３０での、ハッシュが悪意のあるファイルに対応しないことをマッピングが示していると決定したことに応答して、プロセス５００は、５５０に進み、そこで、サンプルは悪意のあるものではないと決定される。いくつかの実施形態において、システムは、ファイルへのハッシュのマッピングが、ハッシュは悪意のあるファイルにマッピングされているという指示を、含んでいないと決定したことに応答して、サンプルが良性であると決定する。一つの例として、システムは、ハッシュが悪意のあるファイルへのハッシュのマッピングに含まれていないと決定する。別の例として、システムは、マッピングが悪意のあるファイル（または、悪意のあるファイルの指示）にマッピングされたレコードを含んでいないと決定する。

【0119】

サンプル（例えば、分析されているファイル）のアンマネージＩｍｐｈａｓｈが、履歴データセット内の悪意のあるファイル（例えば、悪意のあるファイルのＩｍｐｈａｓｈリストに含まれるレコード）のアンマネージブラックリストと一致する場合に、システムは、サンプルを悪意のあるものと見なす。

【0120】

サンプル（例えば、分析されているファイル）のアンマネージＩｍｐｈａｓｈが、履歴データセット内の良性ファイル（例えば、良性ファイルのホワイトリストに含まれるレコード）のアンマネージＩｍｐｈａｓｈと一致する場合に、システムは、サンプルを良性であると見なす。いくつかの実施形態において、特定のファイルに関する情報が履歴ファイルおよび履歴情報のデータセットに含まれていない、または、利用可能でないと決定したことに応答して、システムは、ファイルを良性であると見なす（例えば、ファイルを悪意のあるものではないと見なす）。

【0121】

５６０では、悪意性の結果が提供される。いくつかの実施形態において、システムは、ハッシュが悪意のあるファイルに対応しているという指示を提供する。例えば、システムは、ハッシュに対応しているファイルが悪意のあるものであるという指示を提供する。

【0122】

５７０では、プロセス５００が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス５００は、さらなるハッシュが分析されるべきではない（例えば、ファイルについてのさらなる予測が必要とされない）と決定したことに応答して、完了したと決定され、管理者は、プロセス５００が一時停止または停止されるべきであることを示す、等。プロセス５００が完了したと決定したことに応答して、プロセス５００は、終了する。プロセス５００が完了していないと決定したことに応答して、プロセス５００は、５１０に戻る。

【0123】

図６は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス６００は、図１のシステム１００及び／又は図２のシステム２００によって、少なくとも部分的に、実施される。いくつかの実装において、プロセス６００は、ネットワーク（例えば、セキュリティエンティティ、及び／又は、クライアントデバイスといったネットワークエンドポイント）にサービスを提供することに関連するなど、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス６００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス６００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって、実装され得る。

【0124】

６０２では、サンプルが受信される。

【0125】

６０４では、サンプルに対応している．ＮＥＴアセンブリが取得される。いくつかの実施形態において、サンプルは（例えば、ＺＩＰフォーマット、等で）圧縮されており、そして、．ＮＥＴアセンブリが圧縮ファイルから抽出される。いくつかの実施形態において、．ＮＥＴアセンブリを取得することは、サンプルが．ＮＥＴファイルであると決定することを含んでいる。

【0126】

６０６では、．ＮＥＴアセンブリがＭｏｄｕｌｅＲｅｆテーブルを含むか否かの決定が行われる。ＮＥＴアセンブリがＭｏｄｕｌｅＲｅｆテーブルを含まないと決定したことに応答して、プロセス６００は、終了する。逆に、．ＮＥＴアセンブリがＭｏｄｕｌｅＲｅｆテーブルを含むと決定したことに応答して、プロセス６００は、６０８に進む。

【0127】

６０８では、．ＮＥＴアセンブリがＩｍｐｌＭａｐテーブルを含むか否かの決定が行われる。ＮＥＴアセンブリがＩｍｐｌＭａｐテーブルを含まないと決定したことに応答して、プロセス６００は、終了する。逆に、．ＮＥＴアセンブリがＩｍｐｌＭａｐテーブルを含むと決定したことに応答して、プロセス６００は、６１０に進む。

【0128】

６１０では、ＩｍｐｏｒｔＮａｍｅ値が取得される。いくつかの実施形態において、システムは、ＩｍｐｏｒｔＮａｍｅテーブルのＩｍｐｏｒｔＮａｍｅ列からＩｍｐｌＭａｐ値を取得する。例えば、システムは、ＩｍｐｏｒｔＮａｍｅ列の該当する行（例えば、選択された行）からＩｍｐｏｒｔＮａｍｅ値を取得する。いくつかの実施形態において、システムは、ＩｍｐｏｒｔＮａｍｅの行にわたり反復して、ＩｍｐｏｒｔＮａｍｅ列の各該当する行の値を取得する。

【0129】

６１２では、６１０で取得されたＩｍｐｏｒｔＮａｍｅ値が０に等しいか否かの決定が行われる。６１０で取得されたＩｍｐｏｒｔＮａｍｅ値が０に等しいと決定したことに応答して、プロセス６００は、６２６に進む。６１０で取得されたＩｍｐｏｒｔＮａｍｅ値が０に等しくないと決定したことに応答して、プロセス６００は、６１４に進む。

【0130】

６１４では、関数名が、＃Ｓｔｒｉｎｇｓストリームから取得される。いくつかの実施形態において、システムは、選択された行を使用して、．ＮＥＴアセンブリの＃Ｓｔｒｉｎｇｓストリームから、関数名を取得する。

【0131】

６１６では、ＩｍｐｏｒｔＳｃｏｐｅ列からの値が取得される。いくつかの実施形態において、システムは、ＩｍｐｌＭａｐテーブルのＩｍｐｏｒｔＳｃｏｐｅ列から、値を取得する。システムは、．ＮＥＴヘッダを使用して、ＩｍｐｌＭａｐテーブルを取得する（例えば、．ＮＥＴヘッダはＩｍｐｌＭａｐテーブルを含む）。ＩｍｐｏｒｔＳｃｏｐｅ列の値は、選択された行から取得される（例えば、ＩｍｐｏｒｔＮａｍｅ値が取得されるＩｍｐｌＭａｐテーブルの行、及び／又は、＃Ｓｔｒｉｎｇｓストリーム情報が取得されるＩｎｆｏ列の行）。いくつかの実施形態において、ＩｍｐｏｒｔＳｃｏｐｅ列からの値は、ＭｏｄｕｌｅＲｅｆテーブルへのルックアップを実行することに関連して（例えば、対応しているライブラリの名前について）インデックスとして使用される。

【0132】

６１８では、値を得るために、ＭｏｄｕｌｅＲｅｆテーブルにおける行インデックスとして、ＩｍｐｏｒｔＳｃｏｐｅ値が使用される。いくつかの実施形態において、システムは、．ＮＥＴヘッダを使用して、ＭｏｄｕｌｅＲｅｆテーブルを取得する（例えば、．ＮＥＴヘッダはＭｏｄｕｌｅＲｅｆテーブルを含む）。システムは、インデックスとしてＩｍｐｏｒｔＳｃｏｐｅ列から取得された値を使用して、ＭｏｄｕｌｅＲｅｆテーブル内のルックアップを実行する。例えば、システムは、ＩｍｐｏｒｔＳｃｏｐｅ列から取得された値を使用して、そこからシステムが名前列から値を取得するべきＭｏｄｕｌｅＲｅｆテーブルの行を決定する。いくつかの実施形態において、ＭｏｄｕｌｅＲｅｆテーブルの名前列から取得された値は、＃Ｓｔｒｉｎｇｓストリームに対するインデックスとして使用される。

【0133】

６２０では、ライブラリ名が、＃Ｓｔｒｉｎｇｓストリームから取得される。いくつかの実施形態において、システムは、．ＮＥＴヘッダを使用して、＃Ｓｔｒｉｎｇｓストリームを取得する（例えば、．ＮＥＴヘッダは、＃Ｓｔｒｉｎｇｓストリームを含む）。システムは、名前列から取得された値をインデックスとして使用して、＃Ｓｔｒｉｎｇｓストリーム内でルックアップを実行する。

【0134】

６２４では、ライブラリ名－関数名のペアに対応している文字列が、リストに追加される。例えば、ライブラリ名－関数名のペアが、アンマネージなインポート関数のリストに追加される。いくつかの実施形態において、システムは、既定のフォーマットまたはシンタックスに従って、文字列を生成する。

【0135】

６２６では、．ＮＥＴアセンブリがＭｅｔｈｏｄＤｅｆテーブルを含むか否かの決定が行われる。ＮＥＴアセンブリがＭｅｔｈｏｄＤｅｆテーブルを含まないと決定したことに応答して、プロセス６００は、６に進み、そこで、システムは、．ＮＥＴヘッダが空（ｅｍｐｔｙ）の関数名を有していると見なす。逆に、．ＮＥＴアセンブリがＭｅｔｈｏｄＤｅｆテーブルを含むと決定したことに応答して、プロセス６００は、６２８に進む。

【0136】

６２８では、ＩｍｐｌＭａｐテーブルのＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ列から、値が取得される。システムは、．ＮＥＴヘッダを使用してＩｍｐｌＭａｐテーブルを取得する（例えば、．ＮＥＴヘッダはＩｍｐｌＭａｐテーブルを含む）。ＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ列の値は、選択された行から取得される（例えば、ＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ値が、そこから取得されるＩｍｐｌＭａｐテーブルの行）。いくつかの実施形態において、ＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ列からの値は、ＭｏｄｕｌｅＲｅｆテーブルへのルックアップを実行することに関連してインデックスとして使用される（例えば、対応しているライブラリの名前について）。

【0137】

６３０では、値を得るために、ＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ値が、ＭｏｄｕｌｅＲｅｆテーブルにおける行インデックスとして使用される。いくつかの実施形態において、システムは、．ＮＥＴヘッダを使用して、ＭｏｄｕｌｅＲｅｆテーブルを取得する（例えば、．ＮＥＴヘッダはＭｏｄｕｌｅＲｅｆテーブルを含む）。システムは、インデックスとしてＭｅｍｂｅｒＦｏｒｗａｒｄｅｄ列から取得された値を使用して、ＭｏｄｕｌｅＲｅｆテーブル内のルックアップを実行する。例えば、システムは、名前列から取得された値を使用して、そこからシステムが値を取得するべきＭｏｄｕｌｅＲｅｆテーブルの行を、＃Ｓｔｒｉｎｇｓストリームから、決定する。

【0138】

６３２では、関数名が、＃Ｓｔｒｉｎｇｓストリームから取得される。いくつかの実施形態において、システムは、．ＮＥＴヘッダを使用して、＃Ｓｔｒｉｎｇｓストリームを取得する（例えば、．ＮＥＴヘッダは、＃Ｓｔｒｉｎｇｓストリームを含む）。システムは、ＭｏｄｕｌｅＲｅｆテーブルの名前列から取得された値をインデックスとして使用して、＃Ｓｔｒｉｎｇｓストリームのルックアップを実行する。

【0139】

６３６では、ＰＥヘッダが、インポートテーブルを有するか否かの決定が行われる。いくつかの実施形態において、システムは、関数名（例えば、＃Ｓｔｒｉｎｇｓストリームから取得された関数名）に対応しているライブラリ名を決定することに関連して、ＰＥヘッダが、インポートテーブルを含むか否かを決定する。

【0140】

６３６において、ＰＥヘッダがインポートテーブルを有していないと決定されたことに応答して、プロセス６００は、６３８に進み、システムは、ライブラリ名を空のライブラリ名であると見なす。逆に、６３６において、ＰＥヘッダがインポートテーブルを有すると決定したことに応答して、プロセス６００は、６４０に進み、そこで、関数名に対応しているライブラリ名が取得される。いくつかの実施形態において、システムは、関数名に対応しているライブラリ名を取得するために、インポートテーブルを構文解析する。ライブラリ名を取得したことに応答して、プロセス６００は、６２４に進む。

【0141】

６２４において、関数名および対応しているライブラリ名がリストに追加された後で、プロセス６００は、６４２に進む。

【0142】

６４２では、リストのポピュレーション（ｐｏｐｕｌａｔｉｏｎ）（例えば、生成）が完了したか否かについての決定が行われる。いくつかの実施形態において、リストのポピュレーション／生成は、さらなるインポート関数、及び／又は、対応しているライブラリがリストに追加されないと決定したことに応答して（例えば、さらなるインポート関数が、．ＮＥＴヘッダに含まれず、または、参照されない）、完了したと決定され、管理者は、プロセス６００が、一時停止または停止、等されるべきであることを示す。６４２における、さらなるインポート関数、及び／又は、対応しているライブラリがリストに追加されないと決定したことに応答して、プロセス６００は、６４４に進み、システムは、リスト（例えば、アンマネージなインポート関数のリスト）のハッシュを決定する（例えば、計算する）。プロセス６００が完了していないと決定したことに応答して、プロセス６００は６０２に戻る。いくつかの実施形態において、ハッシュ（例えば、アンマネージＩｍｐｈａｓｈ）を計算することに応答して、システムは、アンマネージＩｍｐｈａｓｈに少なくとも部分的に基づいて、サンプルが悪意のあるものか否かを決定する。例えば、ハッシュの計算に応答して、図５のプロセス５００が呼び出される。

【0143】

いくつかの実施形態において、システムは、図７Ａのプロセス７００、または、図７Ｂのプロセス７５０を呼び出すことによって、リストのハッシュを決定する。

【0144】

図７Ａは、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス７００は、図１のシステム、１００及び／又は、図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス６００は、ネットワーク（例えば、セキュリティエンティティ、及び／又は、クライアントデバイスといったネットワークエンドポイント）にサービスを提供することに関連するなど、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス７００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス７００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって実装され得る。

【0145】

７０２では、ライブラリ名、及び／又は、関数名が取得される。いくつかの実施形態において、．ＮＥＴヘッダを使用して取得される関数名および対応しているライブラリ名は、アンマネージなインポート関数のリストを生成することに関連してなど、取得される。

【0146】

７０４では、ライブラリ名がファイル拡張子を有するか否かの決定が行われる。７０４においてライブラリ名がファイル拡張子を有すると決定したことに応答して、プロセス７００は、７０６に進み、そこで、ファイル拡張子が除去される。７０４においてライブラリ名がファイル拡張子を有していないと決定されたことに応答して、プロセス７００は、７０８に進む。

【0147】

７０８では、関数名およびライブラリ名がフォーマットされる。いくつかの実施形態において、システムは、既定のフォーマットまたはシンタックスに従って、ライブラリ名－関数名ペアをフォーマットする。別の例として、システムは、任意の大文字を小文字に変換するために、関数名およびライブラリ名をフォーマットする。

【0148】

７１０では、関数名とライブラリ名が組み合わされる。いくつかの実施形態において、システムは、インポート関数（例えば、アンマネージなインポート関数）の関数名と、インポート関数に対応しているライブラリ名との組み合わせに対応している文字列を構築する。例えば、システムは、ライブラリ名を関数名に付加するように文字列を構築し、そして、ライブラリ名と関数名との間に既定のセパレータ（例えば、「．」）が含まれる。様々な実施形態に従って、システムは、フォーマット、すなわち＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞、に従って文字列を決定する。次いで、システムは、アンマネージなインポート関数のリスト（例えば、アンマネージＩｍｐｈａｓｈが決定されたリスト）に文字列を追加する。

【0149】

様々な実施形態に従って、様々なフォーマットまたはシンタックスが、関数名とライブラリ名を組み合わせるシステムに関連して実装され得る。既定のフォーマットの例は、（ｉ）小文字の英数字ストリング、（ｉｉ）ファイル拡張子の除去、（ｉｉｉ）ライブラリ拡張子の除去（例えば、対応しているライブラリ名からの．ｄｌｌの除去）、（ｉｖ）アンマネージ関数名および対応しているライブラリの付加、および、（ｖ）アンマネージ関数名と、対応しているライブラリとの間の事前定義されたセパレータの使用、（ｖｉ）ストリングを決定するためのライブラリ名と関数名の結合順序（例えば、＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞、または＜ＦｕｎｃｔｉｏｎＮａｍｅ＞．＜ＬｉｂｒａｒｙＮａｍｅ＞）を含む。いくつかの実施形態において、システムは、関数名（例えば、アンマネージ関数名）を対応しているライブラリに付加し、そして、ドットまたはピリオド（例えば、「．」）によって、対応しているライブラリから関数名を分離する。関数名およびライブラリを（例えば、「．」といった既定のセパレータを用いて）付加することによって文字列を決定したことに応答して、システムは、そうしたエントリを、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに追加する。様々な他の既定のフォーマット／シンタックスが実装され得る。

【0150】

７１２では、関数名とライブラリ名の組合せが、アンマネージなインポート関数のリストに追加される。

【0151】

７１４において、リストに追加されるべきより多くの関数が存在するか否かについての決定が行われる。例えば、システムは、そのファイルのアンマネージなインポート関数のリストに、より多くのアンマネージなインポート関数が追加されるべきか否かを決定する。７１４において、リストに追加されるべきさらなる関数が存在しないと決定したことに応答して、プロセス７００は、７１６に進む。追加的な関数がリストに追加されるべきであると決定したことに応答して、プロセス７００は、７０２に戻る。

【0152】

７１６では、リストに関してハッシュが計算される。様々な実施形態に従って、システムは、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに関してハッシュを決定する。ハッシュの決定に関連して、様々なハッシュ関数を使用することができる。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含む。様々な他のハッシュ関数が実装され得る。システムは、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定するために、ハッシュ関数を使用する。

【0153】

いくつかの実施形態において、システムは、既定のフォーマットに従ってリストを変換またはフォーマットする。例えば、ライブラリ＜－＞関数（＜－＞ｍａｐｐｉｎｇｆｌａｇｓ）名ペアのリストは、コンマで分離された文字列へと変換される。そうした例に従って、以下のリストに対してハッシュを計算する代わりに、
ｋｅｒｎｅｌ３２．ｃｒｅａｔｅｐｒｏｃｅｓｓ
ｋｅｒｎｅｌ３２．ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｗｏｗ６４ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｗｏｗ６４ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｒｅａｄｐｒｏｃｅｓｓｍｅｍｏｒｙ

システムは、単一のリスト項目（ライブラリ＜－＞関数ペア）を有するコンマで分離された文字列を作成する。すなわち、
「ｋｅｒｎｅｌ３２．ｃｒｅａｔｅｐｒｏｃｅｓｓ、ｋｅｒｎｅｌ３２．ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｒｅａｄｐｒｏｃｅｓｓｍｅｍｏｒｙ、…」。単一のリスト項目を有するコンマで分離された文字列を変換／作成することに応答して、システムは、そうした文字列に関して決定する（例えば、ハッシュを計算する）。

【0154】

７１８では、ハッシュが提供される。いくつかの実施形態において、システムは、ファイルが悪意のあるものか否かを決定するそうしたシステムまたはモジュールに関連するといった、別のシステムまたはモジュールにハッシュを提供する。例えば、ハッシュは、プロセス７００の呼び出し（ｉｎｖｏｃａｔｉｏｎ）に対する応答として提供される。

【0155】

７２０では、プロセス７００が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス７００は、さらなるハッシュが計算されるべきではない（例えば、ファイルについてさらなる予測が必要とされない）と決定したことに応答して、完了したものと決定され、管理者は、プロセス７００が、一時停止または停止、等されるべきであることを指示する。プロセス７００が完了したと決定したことに応答して、プロセス７００は、終了する。プロセス７００が完了していないと決定したことに応答して、プロセス７００は、７０２に戻る。

【0156】

図７Ｂは、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。

【0157】

いくつかの実施形態において、プロセス７００は、図１のシステム１００及び／又は図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス６００は、ネットワーク（例えば、セキュリティエンティティ、及び／又は、クライアントデバイスといったネットワークエンドポイント）にサービスを提供することに関連するなど、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス７００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス７００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって実装され得る。

【0158】

様々な実施形態に従って、７５０は、アンマネージ関数の追加情報（例えば、アンマネージ関数が作成者によってコード内で定義された方法に関する情報、等）を含んでいる、７５０は、図７Ａの７００と比較してより厳密である。一つの例として、７５０の最終ハッシュ（ｆｉｎａｌ ｈａｓｈ）も、また、より厳密であり、そして、潜在的に偽陽性の傾向（ｆａｌｓｅ ｐｏｓｉｔｉｖｅ ｐｒｏｎｅ）が、より少ない。しかしながら、欠点は、７５０の最終ハッシュが、７００の最終ハッシュよりも少ないマルウェアサンプルにおいて潜在的にヒットすることである。

【0159】

７５２では、ライブラリ名、及び／又は、関数名が取得される。いくつかの実施形態において、．ＮＥＴヘッダを使用して取得される、関数名および対応しているライブラリ名は、アンマネージなインポート関数のリストを生成することに関連してなど、取得される。

【0160】

７５４では、ライブラリ名がファイル拡張子を有するか否かの決定が行われる。７５４においてライブラリ名がファイル拡張子を有すると決定したことに応答して、プロセス７５０は、７５６に進み、そこで、ファイル拡張子が除去される。７５４においてライブラリ名がファイル拡張子を有していないと決定されたことに応答して、プロセス７００は、７６０に進む。

【0161】

７５８では、関数名およびライブラリ名がフォーマットされる。いくつかの実施形態において、システムは、既定のフォーマットまたはシンタックスに従って、ライブラリ名－関数名ペアをフォーマットする。別の例として、システムは、任意の大文字を小文字に変換するために、関数名およびライブラリ名をフォーマットする。

【0162】

７６０では、ＭａｐｐｉｎｇＦｌａｇｓ値が取得される。いくつかの実施形態において、システムは、ＩｍｐｌＭａｐテーブルからＭａｐｐｉｎｇＦｌａｇｓ値を取得する。例えば、システムは、関数に対応しているＩｍｐｌＭａｐテーブル内の行からＭａｐｐｉｎｇＦｌａｇｓ値を取得する。ＭａｐｐｉｎｇＦｌａｇｓ値は、Ｐ／Ｉｎｖｏｋｅ属性を含んでいる。

【0163】

７６２では、ＭａｐｐｉｎｇＦｌａｇｓ値、関数名、および、ライブラリ名が組み合わされる。いくつかの実施形態において、システムは、ＭａｐｐｉｎｇＦｌａｇｓ値、インポート関数（例えば、アンマネージインポート関数）の関数名、および、インポート関数に対応しているライブラリ名の組み合わせに対応する、文字列を構築する。例えば、システムは、ＭａｐｐｉｎｇＦｌａｇｓ値およびライブラリ名を関数名に付加するように文字列を構築し、そして、ライブラリ名と関数名との間に既定のセパレータ（例えば、「．」）が含まれる。様々な実施形態に従って、システムは、フォーマット、すなわち＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞．＜ＭａｐｐｉｎｇＦｌａｇｓ＞、に従って文字列を決定する。次いで、システムは、アンマネージなインポート関数のリスト（例えば、アンマネージＩｍｐｈａｓｈが決定されたリスト）に文字列を追加する。

【0164】

様々な実施形態に従って、様々なフォーマットまたはシンタックスが、関数名とライブラリ名を組み合わせるシステムに関連して実装され得る。既定のフォーマットの例は、（ｉ）小文字の英数文字列、（ｉｉ）ファイル拡張子の除去、（ｉｉｉ）ライブラリ拡張子の除去（例えば、対応しているライブラリ名からの．ｄｌｌの除去）、（ｉｖ）アンマネージ関数名および対応しているライブラリの付加、および、（ｖ）アンマネージ関数名と対応しているライブラリとの間の既定のセパレータの使用、（ｖｉ）文字列を決定するためのライブラリ名と関数名の結合順序（例えば、＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＦｕｎｃｔｉｏｎＮａｍｅ＞．＜ＭａｐｐｉｎｇＦｌａｇｓ＞、＜ＦｕｎｃｔｉｏｎＮａｍｅ＞．＜ＬｉｂｒａｒｙＮａｍｅ＞．＜ＭａｐｐｉｎｇＦｌａｇｓ＞、等）を含む。いくつかの実施形態において、システムは、関数名（例えば、アンマネージ関数名）を対応しているライブラリに付加し、そして、ドットまたはピリオド（例えば、「．」）によって、対応しているライブラリから関数名を分離する。関数名およびライブラリを（例えば、「．」といった既定のセパレータを用いて）付加することによって文字列を決定したことに応答して、システムは、そうしたエントリを、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに追加する。様々な他の既定のフォーマット／シンタックスが実装され得る。

【0165】

７６４では、関数名とライブラリ名の組合せが、アンマネージなインポート関数のリストに追加される。

【0166】

７６６では、リストに追加されるべきより多くの関数が存在するか否かについての決定が行われる。例えば、システムは、そのファイルのアンマネージなインポート関数のリストに、より多くのアンマネージなインポート関数が追加されるべきか否かを決定する。７６６において、リストに追加されるべきさらなる関数が存在しないと決定したことに応答して、プロセス７５０は、７５２に進む。追加的な関数がリストに追加されるべきであると決定したことに応答して、プロセス７５０は、７５２に戻る。

【0167】

７６８では、リストに関してハッシュが計算される。様々な実施形態に従って、システムは、アンマネージなインポート関数、及び／又は、対応しているライブラリのセットのリストに関してハッシュを決定する。ハッシュの決定に関連して、様々なハッシュ関数を使用することができる。ハッシュ関数の例は、ＳＨＡ－２５６ハッシュ関数、ＭＤ５ハッシュ関数、ＳＨＡ－１ハッシュ関数、等を含む。様々な他のハッシュ関数が実装され得る。システムは、．ＮＥＴファイルに対応しているアンマネージＩｍｐｈａｓｈを決定するために、ハッシュ関数をする。

【0168】

いくつかの実施形態において、システムは、既定のフォーマットに従ってリストを変換またはフォーマットする。例えば、ライブラリ＜－＞関数（＜－＞ｍａｐｐｉｎｇｆｌａｇｓ）名のペアのリストは、コンマで分離された文字列へと変換される。そうした例に従って、以下のリストに対してハッシュを計算する代わりに、
ｋｅｒｎｅｌ３２．ｃｒｅａｔｅｐｒｏｃｅｓｓ
ｋｅｒｎｅｌ３２．ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｗｏｗ６４ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｗｏｗ６４ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ
ｋｅｒｎｅｌ３２．ｒｅａｄｐｒｏｃｅｓｓｍｅｍｏｒｙ

システムは、単一のリスト項目（ライブラリ＜－＞関数ペア）を有するコンマで分離された文字列を作成する。すなわち、
「ｋｅｒｎｅｌ３２．ｃｒｅａｔｅｐｒｏｃｅｓｓ、ｋｅｒｎｅｌ３２．ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｇｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｗｏｗ６４ｓｅｔｔｈｒｅａｄｃｏｎｔｅｘｔ、ｋｅｒｎｅｌ３２．ｒｅａｄｐｒｏｃｅｓｓｍｅｍｏｒｙ、…」。単一のリスト項目を有するコンマで分離された文字列を変換／作成することに応答して、システムは、そうした文字列に関して決定する（例えば、ハッシュを計算する）。

【0169】

７７０では、ハッシュが提供される。いくつかの実施形態において、システムは、ファイルが悪意のあるものか否かを決定するそうしたシステムまたはモジュールに関連するといった、別のシステムまたはモジュールにハッシュを提供する。例えば、ハッシュは、プロセス７５０の呼び出しに対する応答として提供される。

【0170】

７７２では、プロセス７５０が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス７５０は、さらなるハッシュが計算されるべきではない（例えば、ファイルについてのさらなる予測が必要とされない）と決定したことに応答して、完了したと決定され、管理者は、プロセス７５０が、一時停止または停止、等されるべきであることを指示する。プロセス７５０が完了したと決定したことに応答して、プロセス７５０、は終了する。プロセス７５０が完了していないと決定したことに応答して、プロセス７５０は、７５２に戻る。

【0171】

図８は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス８００は、図１のシステム１００及び／又は図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス８００は、ネットワーク（例えば、セキュリティエンティティ、及び／又は、クライアントデバイスといったネットワークエンドポイント）にサービスを提供することに関連するなど、１つ以上のサーバによって実装され得る。いくつかの実装において、プロセス８００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス８００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ等といったクライアントデバイスによって実装され得る。

【0172】

８１０では、サンプルが悪意のあるものであるという指示が受信される。いくつかの実施形態において、システムは、サンプルが悪意のあるものであるという指示、および、サンプルまたはハッシュ、署名、または、サンプルと関連付けられた他の一意の識別子を受信する。例えば、システムは、サンプルが悪意のあるものであるという指示を、セキュリティまたはマルウェアサービスといったサービスから受信し得る。システムは、サンプルが悪意のあるものであるという指示を１つ以上のサーバから受信し得る。

【0173】

様々な実施形態に従って、サンプルが悪意のあるものであるという指示は、以前に識別された悪意のあるファイルのセットに対する更新に関連して受信される。例えば、システムは、サンプルが悪意のあるものであるという指示を、悪意のあるファイルのブラックリストに対する更新として受信する。

【0174】

８２０では、サンプルと、サンプルが悪意のあるものであるという指示との関連付けが保管される。サンプルが悪意のあるものであるという指示を受信したことに応答して、システムは、サンプルが悪意のあるものであるという指示を、サンプルまたはサンプルに対応している識別子に関連して保管し、その後に受信されるファイルが悪意のあるものか否かのルックアップ（例えば、ローカルルックアップ）を容易にする。いくつかの実施形態において、サンプルが悪意のあるものであるという指示に関連して保管されたサンプルに対応している識別子は、ファイル（または、ファイルの一部）のハッシュ、ファイル（または、ファイルの一部）の署名、もしくは、ファイルに関連する別の一意の識別子を含んでいる。いくつかの実施形態において、サンプルが悪意のあるものか否かの指示に関連してサンプルを保管することは、サンプルが悪意のあるものか否かの指示に関連して．ＮＥＴファイルについてのアンマネージＩｍｐｈａｓｈを保管することを含む。

【0175】

８３０では、トラフィックが受信される。システムは、ネットワークにおいて／にわたりトラフィックをルーティングすること、または、ファイアウォールといったネットワークの中／外へのトラフィックを仲介（ｍｅｄｉａｔｉｎｇ）すること、もしくは、電子メールトラフィックまたはインスタントメッセージトラフィックのモニタリングに関連してなど、トラフィックを取得し得る。

【0176】

８４０では、トラフィックが悪意のあるファイルを含むか否かの決定が実行される。いくつかの実施形態において、システムは、受信したトラフィックからファイルを取得する。例えば、システムは、ファイルを、電子メールに対する添付ファイルとして識別し、ファイルを、インスタントメッセージプログラムまたは他のファイル交換プログラム、等を介して、２つのクライアントデバイス間で交換されているものとして識別する。システムは、トラフィックからファイルを取得したことに応答して、ファイルが、悪意のあるファイルのブラックリストといった以前に識別された悪意のあるファイルのセットに含まれるファイルに対応しているか否かを決定する。ファイルが、悪意のあるファイルのブラックリストにおけるファイルのセットに含まれると決定したことに応答して、システムは、ファイルが悪意のあるものであると決定する（例えば、システムは、トラフィックが悪意のあるファイルを含んでいると、さらに決定し得る）。

【0177】

いくつかの実施形態において、システムは、ファイルが、良性ファイルのホワイトリストといった以前に識別された良性ファイルのセットに含まれるファイルに対応するか否か、を決定する。ファイルが良性ファイルのホワイトリストにおけるファイルのセットに含まれると決定したことに応答して、システムは、ファイルが悪意のあるものではないと決定する（例えば、システムは、トラフィックが悪意のあるファイルを含んでいると、さらに決定し得る）。

【0178】

様々な実施形態に従って、ファイルが、以前に識別された悪意のあるファイルのセット（例えば、悪意のあるファイルのブラックリスト）、または、以前に識別された良性ファイルのセット（例えば、良性ファイルのホワイトリスト）に含まれていないと決定したことに応答して、システムは、ファイルを悪意のない（ｎｏｎ－ｍａｌｉｃｉｏｕｓ）ものである（例えば、良性）と見なす。

【0179】

様々な実施形態に従って、ファイルが以前に識別された悪意のあるファイルのセット（例えば、悪意のあるファイルのブラックリスト）、または、以前に識別された良性ファイルのセット（例えば、良性ファイルのホワイトリスト）に含まれていないと決定したことに応答して、システムは、ファイルが悪意のあるものか否かを決定するために、悪意のあるファイル検出器をクエリする。例えば、システムは、ファイルが悪意のあるものか否かについて、悪意のあるファイル検出器からの応答を受信するまで、ファイルを隔離することができる。悪意のあるファイル検出器は、システムによるトラフィックの処理と同時に（例えば、システムからのクエリとリアルタイムで）など、ファイルが悪意のあるものか否かの評価を実行することができる。悪意のあるファイル検出器は、図１のシステム１００、及び／又は、図２のシステム２００の悪意のあるファイル検出器１７０に対応し得る。

【0180】

いくつかの実施形態において、システムは、ファイルが以前に識別された悪意のあるファイルのセット、または、以前に識別された良性ファイルのセットに含まれるか否かを決定する。ファイルに関連付けられたハッシュを計算すること、もしくは、署名または他の一意の識別子を決定すること、および、ハッシュ、署名、または、他の一意の識別子に一致するファイルについて、以前に識別された悪意のあるファイルのセット、または、以前に識別された良性ファイルのセットにおいてルックアップを実行すること、によるものである。様々なハッシュ技法が実装され得る。様々な実施形態に従って、ファイルが以前に識別された悪意のあるファイルのセット、または、以前に識別された良性ファイルのセットに含まれるか否かを決定することは、ファイルに対応しているアンマネージＩｍｐｈａｓｈを決定すること、および、アンマネージＩｍｐｈａｓｈが履歴データセット（例えば、悪意性に係る以前の決定の結果を含むデータセット）に含まれるか否かを決定すること、を含む。

【0181】

８４０で、トラフィックが悪意のあるファイルを含まないと決定したことに応答して、プロセス８００は、８５０に進み、そこで、ファイルは、悪意のないトラフィック／情報として取り扱われる。

【0182】

８４０で、トラフィックが悪意のあるファイルを含むと決定したことに応答して、プロセス８００は、８６０に進み、そこで、ファイルは、悪意のあるトラフィック／情報として取り扱われる。システムは、１つ以上のセキュリティポリシといった１つ以上のポリシに少なくとも部分的に基づいて、悪意のあるトラフィック／情報を取り扱うことができる。

【0183】

様々な実施形態に従って、ファイルの悪意のあるトラフィック／情報の取り扱いは、能動的な措置を実行することを含み得る。能動的な措置は、１つ以上のセキュリティポリシに従って（例えば、少なくとも部分的に基づいて）、実行され得る。一つの例として、１つ以上のセキュリティポリシは、悪意のあるファイルの検出を提供するサービスに対して、ネットワーク管理者、顧客（例えば、組織／会社）、等によって、事前設定され得る。実行され得る能動的な措置は、以下を含む。ファイルを分離すること（例えば、ファイルを隔離すること）、ファイルを削除すること、悪意のあるファイルが検出されたことをユーザに対して警告するようにユーザに促すこと、デバイスがファイルを開く、又は、実行しようとするときに、ユーザに対してプロンプトを提供すること、ファイルの送信をブロックすること、悪意のあるファイルのブラックリストを更新すること（例えば、ファイルが悪意のあるものであるという指示へのファイルのハッシュのマッピング）、等。

【0184】

８７０では、プロセス８００が完了したか否かについての決定が行われる。いくつかの実施形態においては、さらなるサンプルが分析されるべきではない（例えば、ファイルに対するさらなる予測が必要とされない）と決定したことに応答して、プロセス８００は、完了したと決定され、管理者は、プロセス８００が一時停止または停止されるべきであることを示す、など。プロセス８００が完了したと決定したことに応答して、プロセス８００は、終了する。プロセス８００が完了していないと決定したことに応答して、プロセス８００は、８１０に戻る。

【0185】

図９は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス９００は、図１のシステム１００及び／又は図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス９００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）、及び／又は、クライアントシステム上で実行されるアンチマルウェアアプリケーションによって実装され得る、等。いくつかの実装において、プロセス９００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって、実装され得る。

【0186】

９１０では、ファイルが、トラフィックから取得される。システムは、ネットワーク内／ネットワークにわたるトラフィックをルーティングすること、または、ファイアウォールといったネットワークの中／外のトラフィックを仲介すること、もしくは、電子メールトラフィックまたはインスタントメッセージトラフィックのモニタに関連してなど、トラフィックを取得し得る。いくつかの実施形態において、システムは、受信したトラフィックからファイルを取得する。例えば、システムは、ファイルを電子メールに対する添付ファイルとして識別し、インスタントメッセージプログラムまたは他のファイル交換プログラムを介して２つのクライアントデバイス間で交換されているファイルとして識別する、等。

【0187】

９２０では、ファイルに対応している署名が決定される。いくつかの実施形態において、システムは、ハッシュを計算し、もしくは、ファイルに関連付けられた署名または他の一意の識別子を決定する。様々なハッシュ技法が実装され得る。例えば、ハッシュ技法は、ファイルについてのＭＤ５ハッシュを決定すること（例えば、計算すること）であり得る。いくつかの実施形態において、ファイルに対応している署名を決定することは、．ＮＥＴファイルのアンマネージＩｍｐｈａｓｈを計算することを含む。

【0188】

９３０では、ファイルに対応している署名が悪意のあるサンプルからの署名と一致するか否かを決定するために、悪意のあるサンプルの署名のデータセットがクエリされる。いくつかの実施形態において、システムは、ハッシュ、署名、または、他の一意の識別子に一致するファイルに対して、悪意のあるサンプルの署名についてデータセット内でルックアップを実行する。悪意のあるサンプルの署名についてのデータセットは、システムにおいてローカルに、または、システムにアクセス可能なストレージシステムにおいてリモートに保管され得る。

【0189】

様々な実施形態に従って、ファイルが、以前に識別された悪意のあるファイルのセット、または、以前に識別された良性ファイルのセットに含まれるか否かを決定することは、ファイルに対応しているアンマネージＩｍｐｈａｓｈを決定すること、および、アンマネージＩｍｐｈａｓｈが履歴データセット（例えば、悪意性に係ツ以前の決定の結果を含むデータセット）に含まれるか否かを決定すること、を含む。

【0190】

９４０では、ファイルが悪意のあるものか否かの決定が、ファイルの署名が悪意のあるサンプルの署名と一致するか否かに、少なくとも部分的に基づいて、行われる。いくつかの実施形態において、システムは、悪意のある署名のデータセットが、トラフィックから取得されたファイルの署名に一致するレコードを含むか否かを決定する。アンマネージＩｍｐｈａｓｈに対応しているファイルが悪意のあるものである（例えば、アンマネージＩｍｐｈａｓｈがフィールドのブラックリストに含まれる）という指示を、履歴データセットが含むと決定したことに応答して、システムは、９１０においてトラフィックから取得されたファイルを、悪意のあるものと見なす。

【0191】

９５０では、ファイルが悪意のあるものか否かに従って、ファイルが取り扱われる。いくつかの実施形態において、ファイルが悪意のあるものであると決定したことに応答して、システムは、ファイルに関して１つ以上のセキュリティポリシを適用する。いくつかの実施形態において、ファイルが悪意のあるものではないと決定したことに応答して、システムは、ファイルを良性であるとして取り扱う（例えば、ファイルは通常のトラフィックとして取り扱われる）。

【0192】

９６０では、プロセス９００が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス９００は、さらなるサンプルが分析されるべきではない（例えば、ファイルについてのさらなる予測が必要とされない）と決定したことに応答して、完了したと決定され、管理者は、プロセス９００が一時停止または停止されるべきであることを示す、等。プロセス９００が完了したと決定したことに応答して、プロセス９００は、終了する。プロセス９００が完了していないと決定したことに応答して、プロセス９００は、９１０に戻る。

【0193】

図１０は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス１０００は、図１のシステム１００及び／又は図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス１０００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）によって実装され得る。いくつかの実装において、プロセス１０００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって実装され得る。

【0194】

１０１０では、トラフィックが受信される。システムは、ネットワークにおいて／にわたりトラフィックをルーティングすること、または、ファイアウォールといったネットワークの中／外へのトラフィックを仲介すること、もしくは、電子メールトラフィックまたはインスタントメッセージトラフィックのモニタリングに関連してなど、トラフィックを取得し得る。

【0195】

１０２０では、ファイルがトラフィックから取得される。いくつかの実施形態において、システムは、受信したトラフィックからファイルを取得する。例えば、システムは、ファイルを電子メールに対する添付ファイルとして識別し、インスタントメッセージプログラムまたは他のファイル交換プログラムを介して、２つのクライアントデバイス間で交換されているファイルとして識別する、等。

【0196】

１０３０では、ファイルの．ＮＥＴヘッダを使用して、インポートされたＡＰＩ関数名が取得される。いくつかの実施形態において、１０３０は、図４のプロセス４００の４２０に対応しているか、または、それと同様である。

【0197】

１０４０では、アンマネージ関数が決定される。いくつかの実施形態において、システムは、インポートされたＡＰＩ関数名からのアンマネージ関数のセットが、ファイルの．ＮＥＴヘッダを使用して、取得されると決定する。例えば、システムは、インポートされたＡＰＩ関数のうちのどれがアンマネージ関数に対応しているかを決定する。一つの例として、プロセス６００の少なくとも一部は、アンマネージ関数を決定することに関連して呼び出され得る。

【0198】

１０５０では、ファイルが悪意のあるものか否かについての決定が行われる。いくつかの実施形態において、システムは、アンマネージ関数（例えば、．ＮＥＴヘッダを介するなどして、ファイルにインポートされたアンマネージ関数のセット）に少なくとも部分的に基づいて、ファイルが悪意のあるものか否かを決定する。いくつかの実施形態において、１０５０は、図４のプロセス４００の４４０に対応しているか、または、それと同様である。いくつかの実施形態において、図５のプロセス５００は、１０５０と関連して行われる。

【0199】

１０５０においてファイルが悪意のあるものであると決定したことに応答して、プロセス１０００は、１０６０に進み、そこで、１つ以上のセキュリティポリシが、ファイルに関して適用される。いくつかの実施形態において、１０６０は、図８のプロセス８００の８６０に対応しているか、または、それと同様である。その後、プロセス１０００は、１０７０に進む。

【0200】

１０５０においてファイルが悪意のあるものではないと決定したことに応答して、プロセス１０００は、１０７０に進み、そこで、ファイルは、悪意のないトラフィックとして取り扱われる。いくつかの実施形態において、１０７０は、図８のプロセス８００の８５０に対応しているか、または、それと同様である。

【0201】

１０８０では、プロセス１０００が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス１０００は、さらなるサンプルが分析されるべきではない（例えば、ファイルのさらなる予測が必要とされない）、さらなるトラフィックが分析されるべきではないと決定したことに応答して、完了したと決定され、管理者は、プロセス１０００が一時停止または停止されるべきであることを示す、等。プロセス１０００が完了したと決定したことに応答して、プロセス１０００は、終了する。プロセス１０００が完了していないと決定したことに応答して、プロセス１０００は、１０１０に戻る。

【0202】

図１１は、様々な実施形態に従った、悪意のあるファイルを検出するための方法に係るフローチャートである。いくつかの実施形態において、プロセス１１００は、図１のシステム１００及び／又は図２のシステム２００によって少なくとも部分的に実施される。いくつかの実装において、プロセス１１００は、ネットワークを介して、または、ネットワークの内外で通信されるファイルに関するセキュリティポリシを実施することに関連するなど、セキュリティエンティティ（例えば、ファイアウォール）、及び／又は、クライアントシステム上で実行されるアンチマルウェアアプリケーションによって実装され得る、等。いくつかの実装において、プロセス１１００は、電子メール添付ファイルといったファイルを実行すること、または、開くことに関連するなど、ラップトップ、スマートフォン、パーソナルコンピュータ、等といったクライアントデバイスによって、実装され得る。

【0203】

１１１０では、トラフィックが受信される。いくつかの実施形態において、１１１０は、図１０のプロセス１０００の１０１０に対応しているか、または、それと同様である。

【0204】

１１２０では、ファイルが、トラフィックから取得される。いくつかの実施形態において、１１２０は、図１０のプロセス１０００の１０２０に対応しているか、または、それと同様である。

【0205】

１１３０では、インポートされたＡＰＩ関数名が、ファイルの．ＮＥＴヘッダを使用して、取得される。いくつかの実施形態において、１１３０は、図１０のプロセス１０００の１０３０に対応しているか、または、それと同様である。

【0206】

１１４０では、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュが決定される。いくつかの実施形態において、システムは、インポートされたＡＰＩ関数名に少なくとも部分的に基づいて（例えば、ファイルの．ＮＥＴヘッダを介して）、アンマネージ関数を決定する。いくつかの実施形態において、システムは、インポートされたＡＰＩ関数名から、アンマネージ関数のセットが、ファイルの．ＮＥＴヘッダを使用して、取得されることを決定し、システムは、アンマネージ関数のリストを決定し、そして、リストに少なくとも部分的に基づいて、ハッシュを決定する。一つの例として、リストは、アンマネージ関数のセットに対応しているアンマネージ関数名を含んでいる。

【0207】

１１５０では、ファイルへのハッシュのマッピングがクエリされる。いくつかの実施形態において、システムは、アンマネージなインポートされたＡＰＩ関数名のリストのハッシュに少なくとも部分的に基づいて、ファイルへのハッシュのマッピングをクエリする。例えば、システムは、ファイルへのハッシュのマッピングに関してルックアップを実行して、マッピングがアンマネージなインポートされたＡＰＩ関数名のリストのハッシュを含むか否かを決定する（例えば、マッピングが決定／計算されたハッシュに対応しているレコードを含むか否かを決定する）。いくつかの実施形態において、１１５０は、図８のプロセス８００の８４０、及び／又は、図９のプロセス９００の９３０に対応しているか、または、それらと同様である。

【0208】

１１６０では、ファイルが悪意のあるものか否かについての決定が行われる。いくつかの実施形態において、１１６０は、図１０のプロセス１０００の１０５０に対応しているか、または、それと同様である。

【0209】

１１６０においてファイルが悪意のあるものであると決定したことに応答して、プロセス１１００は、１１７０に進み、そこで、１つ以上のセキュリティポリシが、ファイルに関して適用される。いくつかの実施形態において、１１７０は、図８のプロセス８００の８６０に対応しているか、または、それと同様である。その後、プロセス１１００は、１１９０に進む。

【0210】

１１６０においてファイルが悪意のあるものではないと決定したことに応答して、プロセス１１００は、１１８０に進み、そこで、ファイルは、悪意のないトラフィックとして取り扱われる。いくつかの実施形態において、１１８０は、図８のプロセス８００の８５０に対応しているか、または、それと同様である。

【0211】

１１９０では、プロセス１１００が完了したか否かについての決定が行われる。いくつかの実施形態において、プロセス１１００は、さらなるサンプルが分析されるべきではない（例えば、ファイルのさらなる予測が必要とされない）、さらなるトラフィックが分析されるべきではないと決定したことに応答して、プロセス１０００は、完了したと決定され、管理者は、プロセス１０００が一時停止または停止されるべきであることを示す、など。プロセス１１００が完了したと決定したことに応答して、プロセス１１００は、終了する。プロセス１１００が完了していないと決定したことに応答して、プロセス１１００は、１１１０に戻る。

【0212】

本明細書で説明される実施形態の様々な例は、フローチャートに関連して説明されている。実施例は、特定の順序で実行されるいくつかのステップを含み得るが、様々な実施形態に従って、様々なステップは、様々な順序で実行されてよく、かつ／あるいは、様々なステップが、単一のステップへと、または、並列に組み合わせられてよい。

【0213】

前述の実施形態は、理解を明確にする目的で、ある程度詳細に説明されてきたが、本発明は、提供される詳細に限定されない。本発明を実施する多くの代替的な方法が存在している。開示された実施形態は、例示的であり、かつ、限定的なものではない。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図3D】

【図3E】

【図3F】

【図3G】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2024-10-17

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

１つ以上のプロセッサ、および、メモリを含む、システムであって、
前記１つ以上のプロセッサは、
.NETファイルを含むサンプルを受信し、前記.NETファイルは、（ｉ）マネージされるインポートされたAPI関数のセットを含むPEヘッダ、および、（ｉｉ）アンマネージなインポートされたAPI関数のセットを含むPEヘッダを含んでおり、
前記.NETファイルの.NETヘッダに少なくとも部分的に基づいて、前記アンマネージなインポートされたAPI関数の第２セットについて、アンマネージなインポートされたAPI関数名を取得し、
アンマネージなインポートされたAPI関数名のリストのハッシュを決定し、かつ、
前記アンマネージなインポートされたAPI関数名のリストのハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定する、
ように構成されており、
前記メモリは、
前記１つ以上のプロセッサに結合されており、かつ、
前記１つ以上のプロセッサに命令を与えるように構成されている、
システム。

【請求項2】

前記インポートされたAPI関数名を取得することは、
前記.NETファイルの前記.NETヘッダを構文解析すること、および、
構文解析された.NETヘッダから前記インポートされたAPI関数名を抽出すること、
を含む、請求項１に記載のシステム。

【請求項3】

前記インポートされたAPI関数名は、インデックステーブルに少なくとも部分的に基づいて、前記構文解析された.NETヘッダから抽出される、
請求項２に記載のシステム。

【請求項4】

前記インデックステーブルは、前記.NETファイルの実行に関連してインポートされる、アンマネージな方法のセットを示すImplMapテーブルを含む、
請求項３に記載のシステム。

【請求項5】

前記インポートされたAPI関数名は、少なくとも部分的にMethodDefテーブルに基づいて、前記構文解析された.NETヘッダから抽出される、
請求項２に記載のシステム。

【請求項6】

前記アンマネージなインポートされたAPI関数名のリストのハッシュを決定することは、
前記.NETヘッダに少なくとも部分的に基づいて取得された、前記インポートされたAPI関数名に基づいて、アンマネージなインポートされたAPI関数のセットを決定すること、および、
既定のハッシュ関数に少なくとも部分的に基づいて、前記アンマネージなインポートされたAPI関数名のリストのハッシュを生成すること、
を含む、請求項１に記載のシステム。

【請求項7】

前記既定のハッシュ関数は、SHA-256ハッシュアルゴリズム、MD5ハッシュアルゴリズム、および、SHA-1ハッシュアルゴリズムのうちの少なくとも１つを含む、
請求項６に記載のシステム。

【請求項8】

前記１つ以上のプロセッサは、
前記サンプルが悪意のあるものであるという指示をセキュリティエンティティに対して送信する、
ように構成されている、
請求項１に記載のシステム。

【請求項9】

前記サンプルが悪意のあるものであるという指示をセキュリティエンティティに送信することは、
悪意があると見なされるファイルのブラックリストを更新することであり、前記ファイルのブラックリストは、前記サンプルに対応している識別子を含むように更新されること、
を含む、請求項８に記載のシステム。

【請求項10】

前記セキュリティエンティティは、ファイアウォールに対応している、
請求項８に記載のシステム。

【請求項11】

前記アンマネージなインポートされたAPI関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定することは、サンドボックス環境において実行される、
請求項1に記載のシステム。

【請求項12】

前記アンマネージなインポートされたAPI関数名のリストのハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定することは、セキュリティエンティティにおいて実行される、
請求項１に記載のシステム。

【請求項13】

前記インポートされたAPI関数名は、ImportNameフィールドに対応している値に少なくとも部分的に基づいて取得される、
請求項１に記載のシステム。

【請求項14】

前記ImportNameフィールドに対応している値が0に等しくないと決定したことに応答して、
前記インポートされたAPI関数名を取得することは、
前記.NETファイルの#Stringsストリームに少なくとも部分的に基づいて、１つ以上のライブラリ名のセットを決定すること、
を含む、請求項１３に記載のシステム。

【請求項15】

前記ImportNameフィールドに対応している値が0に等しいと決定したことに応答して、
前記インポートされたアプリケーションプログラミングインターフェイス関数名を取得することは、
MethodDefテーブルの行から値を取得すること、
前記MethodDefテーブルの行からの前記値に少なくとも部分的に基づいて、#Stringsストリームから関数名を取得すること、
前記.NETファイルのPEヘッダがインポートテーブルを含むか否かを決定すること、および、
前記.NETファイルのPEヘッダがインポートテーブルを含まないと決定したことに応答して、前記インポートテーブルに少なくとも部分的に基づいて、前記関数名に対応しているライブラリ名を決定すること、
を含む、請求項１３に記載のシステム。

【請求項16】

前記インポートテーブルに少なくとも部分的に基づいて、前記関数名に対応しているライブラリ名を決定することは、
前記対応している関数名から前記ライブラリ名を取得するために、前記インポートテーブルを構文解析することを含む、
請求項１５に記載のシステム。

【請求項17】

前記１つ以上のプロセッサは、さらに、
アンマネージ関数に対応しているライブラリ名がファイル拡張子を有していないことを保証し、
前記ライブラリ名および前記アンマネージ関数に少なくとも部分的に基づいて、文字列を決定し、かつ、
前記文字列を、前記アンマネージなインポートされたAPI関数名のリストに追加する、
ように構成されている、
請求項１に記載のシステム。

【請求項18】

前記文字列は、
前記ライブラリ名および前記アンマネージ関数の名前が大文字を含まないことを保証すること、および、
前記アンマネージ関数の名前と前記ライブラリ名との間に含まれる既定のセパレータを用いて、前記アンマネージ関数の名前を前記ライブラリ名に付加すること、
によって決定される、
請求項１７に記載のシステム。

【請求項19】

方法であって、
.NETファイルを含むサンプルを受信するステップであり、前記.NETファイルは、（ｉ）マネージされるインポートされたAPI関数のセットを含むPEヘッダ、および、（ｉｉ）アンマネージなインポートされたAPI関数のセットを含むPEヘッダを含んでいる、ステップと、
前記.NETファイルの.NETヘッダに少なくとも部分的に基づいて、前記アンマネージなインポートされたAPI関数の第２セットについて、アンマネージなインポートされたAPI関数名を取得するステップと、
アンマネージなインポートされたAPI関数名のリストのハッシュを決定するステップと、
前記アンマネージなインポートされたAPI関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定するステップと、
を含む、方法。

【請求項20】

非一時的コンピュータ可読記憶媒体に保管されたコンピュータプログラムであって、複数のコンピュータ命令を含み、
前記コンピュータ命令がプロセッサにより実行されると、コンピュータに、
.NETファイルを含むサンプルを受信するステップであり、前記.NETファイルは、（ｉ）マネージされるインポートされたAPI関数のセットを含むPEヘッダ、および、（ｉｉ）アンマネージなインポートされたAPI関数のセットを含むPEヘッダを含んでいる、ステップと、
前記.NETファイルの.NETヘッダに少なくとも部分的に基づいて、前記アンマネージなインポートされたAPI関数の第２セットについて、アンマネージな
インポートされたAPI関数名を取得するステップと、
アンマネージなインポートされたAPI関数名のリストのハッシュを決定するステップと、
前記アンマネージなインポートされたAPI関数名のリストの前記ハッシュに少なくとも部分的に基づいて、前記サンプルがマルウェアであるか否かを決定するステップと、
を実施させる、コンピュータプログラム。

【請求項21】

前記アンマネージなインポートされたAPI関数名のリストは、アンマネージドなインポートされたAPI関数ごとに、（ａ）アンマネージなAPI関数名の指示と、（ｂ）対応するライブラリ名の指示とを含んでいる、ペアを備えており、
前記アンマネージなインポートされたAPI関数名のリストをハッシュするステップは、
前記アンマネージなAPI関数名の指示、および、複数のアンマネージなAPI関数についての前記対応するライブラリ名の指示に少なくとも部分的に基づいて、前記アンマネージなインポートされたAPI関数名のリストを表す文字列を生成するステップと、
前記アンマネージなインポートされたAPI関数名のリストを表す前記文字列に基づいて、前記ハッシュを計算するステップと、
を含む、請求項１に記載のシステム。

【国際調査報告】