ネットワークの異常を利用したプロセスインジェクションの新たな検知方法

エグゼクティブサマリー

• Akamai の研究者は、ネットワークの異常を分析することにより、プロセスインジェクションを検知する新しい手法を開発しました。

• 現在の検知メカニズムは、新しい攻撃手法によってバイパスされる可能性がある、ホストベースの要因に依存しています。このため、脅威を特定する新しい方法が必要です。

• このような攻撃手法の進化にあわせて、防御メカニズムも進化させて、フォールス・ポジティブ（誤検知）を可能な限り少なくしなければなりません。

• プロセスインジェクション攻撃が成功すると、 ラテラルムーブメント（横方向の移動）、権限昇格、バックドアの設置など、多数の有害な影響が生じる可能性があります。

• Akamai の検知方法は、プロセスのネットワーク上のふるまいを監視するため、脅威が検知されずに存在し続けることをより困難にしています。

• WannaMine クリプトジャッキングキャンペーンと関係があることが発覚した実際のインシデントを使って、この方法が使用された事例を紹介します。

はじめに

プロセスインジェクションは、ほぼすべての攻撃で使用されています。攻撃者は、すでに有効になっているプロセス内にペイロードを隠して実行するなど、セキュリティソリューションを巧みに利用する方法を探し続けています。

インジェクション技術は、何年もかけて大幅に進化してきた脅威の 1 つです。この高度なメモリー専用技術は、エンドポイント検知応答（EDR）などの最新のセキュリティソリューションで簡単に検知できる従来のインジェクション技術に、急速に取って代わりつつあります。

攻撃者の最終的な目的が何であれ、インジェクションが成功すると、ラテラルムーブメント、ネットワークスキャン、バックドアとして機能するリスナーのインストールの試みにつながります。これにより、いたちごっこが始まります。攻撃者が新しい攻撃ベクトルを見つけると、セキュリティベンダーはそれに応じて検知をアップデートする、といった具合です。

この新しい検知手法は毎月導入されます。つまり、EDR テクノロジーは誤検出を最小限に抑えながら、検知をアップデートしなければなりません。インジェクションが成功した場合に負うリスクの大きさを考えれば、セキュリティベンダーは自らに問いかけなければなりませんでした。もっと違うやり方があるのでは、と。

ほとんどの検知メカニズムでは、API 呼び出し、メモリー保護フラグの変更、割り当て、その他のホストベースのアーティファクトの追跡などの手法が使用されます。しかし、このようなメカニズムは新たな手法や脅威によって悪用される可能性があることがわかっています。 この新しいインジェクション技術は、EDR 回避方法と組み合わせて使用され、検知やブロックを免れる場合があります。これが意味することは、私たちのような脅威ハンターはアンチウイルス（AV）ソリューションや EDR ソリューションだけを使用してホストベースの攻撃を緩和することはできず、攻撃の成功を効率的に検知する方法が必要であるということです。

このブログ記事では、上記のホストベースのアーティファクトではなく、ネットワーク異常検知を使用して Akamai Hunt チームが開発したプロセスインジェクション検知手法について説明します。 Akamai の手法は、プロセスのネットワーク上でのふるまいに注目します。 これは、ホストのアーティファクト（API 呼び出しやファイルシステムの変更など）よりもはるかに隠蔽しにくいものです。この手法やその他のさまざまな手法を使用して、お客様のネットワークでマルウェア、ラテラルムーブメント、データ窃取、その他のタイプの攻撃を検知します。

Akamai の検知は、主に次の 3 つのステップで行われます。

1. プロセス通信をポートグループに分類する

2. 通常のプロセス通信のためのスライディングウィンドウのベースラインを構築する

3. 新しいプロセスデータをそのベースラインと比較する

この記事で説明されているロジックを、ぜひ自社のセキュリティチームに自由に実装してもらってください。 Akamai Huntほど膨大な量のデータを保有していなくても、独自のデータを使用して、興味深い成果を得ることができます。

プロセスはどのように通信するのか？

プロセスの通信がほぼ一貫していることは容易に推測できます。つまり、異なるネットワークでも、同じプロセスであれば同じ通信パターンがあるということです。これは一部のプロセスには当てはまりますが、そうではないプロセスもあります。OS ネイティブのプロセスであれば、同じようなドメインに通信し、同じようなネットワークプロトコルを使って、同じような振る舞いをすると思うかもしれませんが、この仮定には不確定要素がたくさんあります。OS のビルド、地域、プロキシサーバー、その他のネットワーク固有の設定はすべて、通信先や使用するネットワークプロトコルに影響を与えます（図 1）。

Akamai Guardicore Segmentationから収集したこのデータでは、動作中のポート使用状況の不整合が見られます。このままでは検知が非常に困難になる可能性があるため、次のステップでは分析可能な形式にデータをパースする方法を見つけます。それでは、ポートグループの話に入りましょう。

ポートグループを使用してプロセス通信を分類する

Akamai が行った調査では、類似のポートをグループ化して特定のアプリケーションと関連付けることで、検知アルゴリズムにコンテキストを提供し、より簡単に通信パターンを見つけられることがわかりました。これは、通信パターンの異常を検知するのに役立ちます。

たとえば、あるネットワークではポート 636 とポート 389 を使用して通信する特定のプロセスが、別のネットワークではポート 3268 とポート 3269 を使用して通信するとします。これらはすべて Lightweight Directory Access Protocol（LDAP）の一部であるため、LDAP 通信という 1 つのポートグループとして分類できます。

これはほとんどのアプリケーションでうまく機能しますが、有効なポート範囲全体を分類するのは困難です。多くのポートが複数のアプリケーションで使用されているため、他のソフトウェアとポートを共有しているプロセスが誤って分類される可能性があります。そのため、1 つのタイプのアプリケーションで主に使用されるポートのみに分類を絞り込み、ハイポート範囲は 1 つのポートグループとして残すことにしました。

ポートマッピングの全容は、 付録 Aでご確認いただけます。

結論を出すのに十分なデータ量とは？

たとえば、特定のプロセスが 7 台のマシンで実行されており、そのプロセスは HTTPS を使用して特定の Web サーバーにすべての接続を行うとします。同じプロセスは絶対に他の通信形式を使用しないと断定することはできるでしょうか？おそらくできません。

プロセスごとにどれくらいの量のデータがあれば信頼するに足るかを判断するためには、プロセスとポートグループの各ペアが確認されたネットワーク数をカウントします。

まずは、3 つ以上の顧客ネットワークで見られるプロセスのみを検討します。プロセスが現れたネットワークの数が（データセットに含まれる数百のネットワークのうち）3 つ未満である場合、そのネットワークプロファイルに関して確信を持って判断をすることは困難です。

そこで、お客様ごとのネットワークのふるまいの違いに応じて、プロセスの安定性レベルを判断します。あるプロセスが確認されたすべての顧客で同じポートグループを使用して通信する場合、そのプロセスは 安定していると見なされます。プロセスがお客様のネットワークごとに完全に異なる方法で通信する場合、そのプロセスは 安定していないと見なされます。

Akamai はさらに、 トップ 12、トップ 25、トップ 100 という安定性レベルを追加しました。これは、上位 12、25、100 の最もよく使用されるポートからのポートのみを考慮するものです。また、 半安定 というレベルも追加しました。これは、ハイポート（ポート番号 49151 より上のポート）を無視します。

支持度と信頼度

単一のネットワークから抽出されたデータを扱っている場合は、データマイニングを利用して支持度と信頼度を測定することができます。データマイニングは、データセット内のデータの強度と関連性を評価するために役立ちます。

支持度 は、データセット内の項目セットの頻度を測定します。 信頼度 は、相関ルール内の 2 つの項目セット間の関係の信頼度を測定します。この場合は次のようになります。

支持度（プロセス） = （プロセスを含むデータポイントの数） / （データポイントの総数）

支持度（プロセス -> ポートグループ） = （特定のポートグループでプロセスが通信したデータポイントの数） / （プロセスを含むデータポイントの総数）

データポイントは、個別のさまざまなホスト、プロセス、ポートグループです。

プロセスに必要な最小支持度のしきい値と、ポートグループがベースラインの一部と見なされために必要な最小信頼度を設定します。これは、 Apriori アルゴリズムの最初の一歩でもあります。Apriori アルゴリズムとは、大規模なデータセットのパターンを見つけるために使用される一般的なアルゴリズムです。評価後、信号対ノイズ比が低く、興味深い発見が得られる値を決定します。

スライディングウィンドウのベースラインを構築する

Akamai の検知手法は、各プロセスの通信を過去のふるまいのベースラインと比較することで機能します。

具体的には、特定の日に発生したすべてのプロセス通信を、前月のデータに基づくベースラインと比較します（図 2）。

これにより、ネットワークの変更、システムの導入、初めて使用されるツールが翌日には考慮されるため、お客様のネットワークの傾向に適応することができます。

よくある誤検知への対処

一部のアプリケーション設定では、プロセスのネットワークプロファイルを変更できます。あるアプリケーションの設定で、IP アドレスの使用をホスト名の使用に変更した場合、DNS トラフィックが発生し始めます。同じことが内部プロキシサーバーの使用にも当てはまり、この場合は各ネットワークにおいて同じ目的のために異なるポートが使用される可能性があります。他の宛先ポートでは誤検知が少なくなる傾向があり、お客様ごとに許可リストを使用して元のロジックをそのまま維持することができます。

この誤検知の数を減らすために、生成された各アラートは次のロジックを使用して検査されます。

プロセスの異常なポートが DNS／プロキシポートである場合：

1. 宛先 IP を抽出します

2. 前月中に同じポートで同じ宛先 IP にコンタクトした資産の数を確認します

3. その数がネットワークホスト数の 20% を超える場合は、アラートを誤検知と見なします
   

このロジックは、極めてノイズの多い 2 つの通信タイプであるDNS 通信とプロキシ通信のネットワーク固有の設定に対処する上で役立ちます。

実際の脅威の検知：Hunt を利用しているお客様が受けた攻撃の例

Hunt を利用しているお客様に新しい検知方法を使用したところ、5 つのプロセスがそれぞれの通信のベースラインから逸脱しているのを検知しました。この 5 つのシステムネイティブ実行可能ファイルはすべて、Web 関連ポートの非常に特殊な通信パターンを使用しており、サーバー・メッセージ・ブロック（SMB）プロトコルを使用してネットワーク内の他の資産との通信を開始しました（図 3）。

プロセスのベースラインを見ると、どのプロセスも SMB 通信を開始するはずがないことがわかります（図 4）。

アラートを調査したところ、ファイル「 C：\Windows\NetworkDistribution\svchost.exe 」が 2 台のホスト上で実行されているのが見つかりました。また、一方のマシンではファイル「

C:\Windows\System32\dllhostex.exe.」が見つかりました。

別のマシンでは、巧妙な悪性スクリプトが見つかりました（図 5）。

図 6：今回の攻撃と過去の攻撃の比較

Akamai の調査結果はすべて、改善策とネットワークポリシーの推奨事項とともに、判明したとおりにお客様に伝えられました。

総括

脅威や攻撃手法が多様化する中では、正確な検知方法の必要性が非常に高まっています。ネットワークはそれぞれ異なるエコシステムであり、固有の課題があるため、検知を「標準化」することは困難です。多くの組織が攻撃を検知しようとして失敗していますが、その理由は、攻撃者が新しい手法を使用したためか、検知ツール自体が複雑すぎたためです。 

プロセスの通信パターンに注目することで、従来の検知手法をまったく異なる角度から強化することができます。このパターン分析と独自の大規模なデータセットを組み合わせることにより、Akamai はこの手法を開発して使用し、プロセスネットワークの異常を効率的に検知し、お客様のネットワークに潜む攻撃者を見つけることができました。

Akamai Guardicore Segmentation と Akamai Hunt サービスは、 ランサムウェアの拡散やラテラルムーブメントの試みの拡大を阻止します。さらに、攻撃が行われるたびにアラートを発する検出サービスによって、その機能を補完することができます。