脅威ハンティングとは何か、そしてサイバー犯罪者を適切に狩る方法

脅威ハンティングまたはTHは、標準的な保護手段では検出されないマルウェアの痕跡やハッキングのプロアクティブな検索です。今日は、このプロセスがどのように機能するか、脅威を検索するために使用できるツール、および仮説を作成してテストするときに留意すべきことについて話します。

脅威ハンティングとは何か、なぜそれが必要なのか

脅威ハンティングのプロセスでは、アナリストは保護システムのセンサーがトリガーされるまで待機せず、意図的に侵害の痕跡を探します。これを行うために、攻撃者がどのようにネットワークに侵入できたかについての仮定を作成し、検証します。このようなチェックは、一貫性があり定期的に行う必要があります。



プロセスを正しく実装するには、次の原則を考慮する必要があります。

• システムがすでに侵害されていると想定する必要があります。主な目標は、侵入の痕跡を見つけることです。
• 検索するには、システムがどの程度正確に侵害されたかについての仮説が必要です。
• 検索は繰り返し実行する必要があります。つまり、次の仮説をテストした後、アナリストは新しい仮説を提示して検索を続行します。

多くの場合、従来の自動防御は高度な標的型攻撃を見逃します。その理由は、このような攻撃は時間の経過とともに広がることが多いため、セキュリティツールは攻撃の2つのフェーズを関連付けることができないためです。同時に、攻撃者は侵入ベクトルを注意深く検討し、インフラストラクチャでのアクションのシナリオを作成します。これにより、彼らはマスキング解除アクションを実行せず、正当なものとして彼らの活動を偽ることができます。攻撃者は常に知識を向上させ、新しいツールを購入または開発しています。



標的型攻撃の特定に関する問題は、以前にハッキングされた組織に特に関連しています。レポートによるとFireEye M-Trends、以前に侵害された組織の64％が再び攻撃されました。ハッキングされた企業の半数以上が依然として危険にさらされていることが判明しました。これは、妥協の事実を早期に発見するための対策を適用する必要があることを意味します-これはTHの助けを借りて達成できます。



脅威ハンティングは、情報セキュリティの専門家が侵害を検出する時間を短縮し、保護されたインフラストラクチャに関する知識を更新するのに役立ちます。THは脅威インテリジェンス（TI）を使用する場合にも役立ちます。特に、仮説を立てるときにTIインジケーターを使用する場合に役立ちます。

テストの仮説を立てる方法

THを実施する場合、攻撃者はすでにインフラストラクチャに侵入していることが事前に想定されているため、最初に行うことは、ハッキングの痕跡を探す場所を特定することです。これは、侵入がどのように発生し、これがインフラストラクチャで確認できるかについての仮説を立てることによって決定できます。仮説を立てると、アナリストは彼の仮定の真実をチェックします。仮説が確認されない場合、専門家は新しい仮説の開発とテストに進みます。仮説をテストした結果、ハッキングの痕跡が見つかったり、マルウェアの存在が確認されたりすると、調査が始まります。







図2.脅威ハンティング



のスキーム仮説のアイデアは、アナリストの個人的な経験から生まれるかもしれませんが、その構築には他のソースがあります。たとえば、次のようなものがあります。

• threat intelligence (TI-). , : X, MD5- Y.
• , (TTPs). TTPs MITRE ATT&CK. : .
• . . , asset management . .
• , .

threat hunting

仮説を立てたら、それをテストするための情報を含むことができるデータソースを特定する必要があります。多くの場合、そのようなソースには多すぎるデータが含まれており、その中で関連性を見つける必要があります。したがって、THプロセスは、インフラストラクチャで発生していることに関する膨大な量のデータの調査、フィルタリング、および分析に要約されます。：情報が検索仮説をテストするために見つけることができる、情報源を検討







THを行うための情報源の図3.分類



の関連情報の最大量は、ログやネットワークトラフィックに含まれています。SIEM（セキュリティ情報とイベント管理）およびNTA（ネットワークトラフィック分析）クラスの製品は、それらの情報の分析に役立ちます。外部ソース（TIフィードなど）も分析プロセスに含める必要があります。

実際の仕組み

THの主な目的は、自動セキュリティツールでは検出されなかった違反を検出することです。



たとえば、2つの仮説をテストすることを検討してください。実際には、トラフィック分析とログ分析システムが仮説テストのプロセスでどのように相互補完するかを示します。

仮説1：攻撃者はワークステーションを介してネットワークに入り、WMIコマンドの実行を使用してネットワーク上の他のノードを制御しようとします。

攻撃者はrootユーザーの資格情報を入手しました。その後、貴重なデータを持つホストに到達するために、ネットワーク内の他のノードを制御しようとします。リモートシステムでプログラムを起動する方法の1つは、Windows Management Instrumentation（WMI）テクノロジを使用することです。彼女は、コンピューターインフラストラクチャのさまざまな部分の集中管理と監視を担当しています。ただし、作成者は、このアプローチを単一のホストだけでなくリモートコンピューターのコンポーネントやリソースにも適用できる可能性を予見しました。このため、DCERPCプロトコルを介したコマンドと応答の送信が実装されました。



したがって、仮説をテストするには、DCERPCクエリを調べる必要があります。トラフィック分析とSIEMシステムを使用して、これをどのように実行できるかを見てみましょう。図では4は、すべてのフィルタリングされたDCERPCネットワークの相互作用を示しています。たとえば、06：58から12:58までの時間間隔を選択しました。図4.フィルタリングさDCERPCセッション 。 4 2つのダッシュボードが表示されます。左側はDCERPC接続を開始したノードです。右側は、クライアントが接続しているノードです。図からわかるように、ネットワーク上のすべてのクライアントはドメインコントローラにのみアクセスします。 Active Directoryドメインに統合されたホストはDCERPCプロトコルを使用して同期のためにドメインコントローラーに接続するため、これは正当なアクティビティです。このようなユーザーホスト間の通信は、疑わしいと見なされます。















選択した期間に疑わしいものは何も特定されていないため、タイムラインに沿って移動しているため、次の4時間を選択します。現在は12:59から16:46までのインターバルです。その中で、宛先ホストのリストの奇妙な変化に気づきました（図5を参照）。図5.時間間隔を変更すると、2つの新しいノードがサーバー リストに表示され、宛先ホストのリストには2つの新しいノードがあります。 DNS名のないもの（10.125.4.16）を検討してください。10.125.4.16に接続されている人を見つけるために、フィルタの図6.洗練 あなたが図からわかるように。 6、ドメインコントローラー10.125.2.36がアクセスします（図4を参照）。これは、この相互作用が正当であることを意味します。



























次に、図2の2番目の新しいノードに接続したユーザーを分析する必要があります。 5はwin-admin-01.ptlab.ru（10.125.3.10）です。ノードの名前から、これは管理者のコンピュータであることがわかります。フィルターが調整された後、2つのセッションソースノードのみが残ります。図7.フィルターを絞り込んでwin-admin-01 に接続したユーザーを見つける前のケースと同様に、イニシエーターの1つはドメインコントローラーでした。これらのセッションは、Active Directory環境では一般的であるため、不審ではありません。ただし、名前で判断すると、2番目のノード（w-user-01.ptlab.ru）はユーザーのコンピューターです。このような接続は異常です。このフィルターを使用して[セッション]タブに移動すると、トラフィックをダウンロードして、Wiresharkで詳細を確認できます。図8.関連するセッションのダウンロード























トラフィックでは、WMI接続の使用を示すIWbemServicesインターフェイスへの呼び出しを確認できます。図9. IWbemServices（Wireshark）インターフェースの 呼び出しさらに、送信された呼び出しは暗号化されているため、特定のコマンドは不明です。図10. DCERPCトラフィックは暗号化されているため、送信されたコマンドは表示されません（Wireshark） このような通信が不正であるという仮説を最終的に確認するには、ホストログを確認する必要があります。ホストに移動してローカルでシステムログを表示できますが、SIEMシステムを使用する方が便利です。 SIEMインターフェースでは、DCERPC接続の確立時にターゲットノードのログのみを残す条件をフィルターに導入し、次の画像を見ました。



































図11. DCERPC接続の確立時のシステムログwin-admin-01



ログでは、最初のセッションの開始時刻と完全に一致していることがわかりました（図9を参照）。接続の開始者はホストw-user-01です。ログをさらに分析すると、PTLAB \ Adminアカウントで接続してコマンド（図12を参照）を実行し、ユーザーjohnをパスワードpassword !!!で作成したことがわかります。netuser john password !!! / 追加。図12.接続中に実行されたコマンド











ノード10.125.3.10から、PTLAB \ Adminアカウントに代わってWMIを使用している誰かが新しいユーザーをホストwin-admin-01.ptlab.ruに追加したことがわかりました。実際のTHを実施する場合の次のステップは、これが管理活動であるかどうかを確認することです。これを行うには、PTLAB \ Adminアカウントの所有者に連絡して、説明されているアクションを実行したかどうかを確認する必要があります。検討した例は合成であるため、このアクティビティは不正であると想定します。また、本物のTNを実施する際に、アカウントの不正利用の事実が判明した場合は、インシデントを作成し、詳細な調査を行う必要があります。

仮説2：攻撃者がネットワークに侵入し、データ漏えいの段階にあり、トラフィックトンネリングを使用してデータを出力している。

トンネリングトラフィック-あるネットワークプロトコルのパケットが（おそらく変更された形式で）別のネットワークプロトコルのフィールド内に送信されるようにチャネルを編成します。トンネリングの一般的な例は、SSHのような暗号化されたパイプの構築です。暗号化されたチャネルは、送信される情報の機密性を確保し、現代の企業ネットワークでは一般的です。ただし、ICMPトンネルやDNSトンネルなどのエキゾチックなオプションがあります。そのようなトンネルは、サイバー犯罪者が合法的にその活動を偽装するために使用されます。



SSHプロトコルを介してトラフィックをトンネリングする最も一般的な方法を見つけることから始めましょう。これを行うには、SSHプロトコルを使用してすべてのセッションをフィルタリングします。図13.トラフィック内のDNSセッションの検索











この図では、インフラストラクチャにSSHトラフィックがないため、トンネリングに使用できる次のプロトコルを選択する必要があります。企業ネットワークではDNSトラフィックが常に許可されているため、以下で検討します。



DNSでトラフィックをフィルタリングすると、ノードの1つに異常に多数のDNSクエリがあることがわかります。







図14. DNSクライアントセッションの統計を含むウィジェット



リクエストの送信元でセッションをフィルタリングした後、この異常な量のトラフィックが送信される場所と、宛先ノード間でどのように分散されるかを学びました。図では図15は、一部のトラフィックがローカルDNSサーバーとして機能するドメインコントローラーに送信されることを示しています。ただし、要求の大部分は不明なホストに送られます。 Active Directory上に構築された企業ネットワークでは、DNS名前解決のためのユーザーコンピューターは、企業のDNSサーバーをバイパスするために外部DNSサーバーを使用しないでください。このようなアクティビティが検出された場合は、トラフィックで送信されているものと、これらのすべての要求が送信された場所を見つける必要があります。図15. SSHセッションのトラフィックの検索











「セッション」タブに移動すると、不審なサーバーへのリクエストで何が送信されているかを確認できます。リクエスト間の時間はかなり短く、多くのセッションがあります。このようなパラメータは、正当なDNSトラフィックでは一般的ではありません。







図16. DNSトラフィックのパラメーター



セッションカードを開くと、要求と応答の詳細な説明が表示されます。サーバーからの応答にはエラーはありませんが、ホストには通常、より短くて意味のあるDNS名があるため、要求されたレコードは非常に疑わしく見えます。図17.疑わしいDNSレコード要求 トラフィック分析により、win-admin-01ホストでDNS要求の送信に関する疑わしいアクティビティが行われていることがわかりました。次は、ネットワークノードのログを分析します。このアクティビティのソースです。これを行うには、SIEMに移動します。















システムログwin-admin-01を見つけて、17：06あたりに何が起こったかを確認する必要があります。疑わしいPowerShellスクリプトが同時に実行されていたことがわかります。図18.疑わしい要求 の送信と同時にPowerShellを実行ログには、実行されたスクリプトが記録されます。図19.ログ内の実行中のスクリプトの名前の修正 実行されたスクリプトの名前admin_script.ps1は正当性を示していますが、管理者は通常、特定の機能のスクリプトに名前を付けていますが、ここでは名前が一般的です。さらに、スクリプトは一時ファイルのフォルダーにあります。重要な管理スクリプトが、いつでも空になる可能性のあるフォルダに格納されることはほとんどありません。



























発見されたイベントの中には、Logos.Utilityライブラリからの異常な暗号クラスの作成がありました。このライブラリはまれであり、開発者によってサポートされなくなったため、そのクラスの作成は珍しいものです。それを使用するプロジェクトを見つけましょう。図20.カスタム暗号クラスの作成 検索を使用すると、DNSトンネルを編成し、2番目のリンクを使用してこのクラスを使用するユーティリティを見つけることができます。図21.クラス名によるスクリプトに関する情報の検索 これが最終的に必要なユーティリティであることを確認するために、ログで追加の兆候を探しましょう。それで証拠が明らかになりました。 1つは、スクリプトを使用してnslookupユーティリティを実行することです。図22.スクリプトによるnslookupユーティリティの実行



































nslookup.exrユーティリティはネットワーク診断中に使用され、通常のユーザーが実行することはほとんどありません。開始は、ユーティリティのソースコードに表示されます。図23. nslookupユーティリティ（GitHub）を起動するためのコード 2番目の証明は、ランダムな値を生成するためのかなりユニークな文字列です。図24.スクリプトによるランダムな値の生成 ソースコードで検索を使用すると、この行が表示されます。図25.ランダムな値を生成するためのコード トンネルの仮説は確認されましたが、実行されたアクションの本質は不明のままでした。その後のログの分析中に、2つのプロセスの起動に気付きました。図26.さらなる引き出しのためのオフィス文書の検索















































見つかったプロセスの起動行は、ダウンロードするドキュメントの検索を示しています。したがって、仮説は完全に確認され、攻撃者は実際にトラフィックトンネリングを使用してデータをダウンロードしました。

結論

最新の調査レポートが示すように、攻撃者がインフラストラクチャに留まる平均時間は長いままです。したがって、自動防御からの信号を待たずに、積極的に行動してください。インフラストラクチャと最新の攻撃方法を調査し、TIチーム（FireEye、Cisco、PT Expert Security Center）が実施した調査を使用します。



自動化された保護の放棄を求めているのではありません。ただし、そのようなシステムのインストールと正しい構成が最終的なポイントであるとは限りません。これは最初の必要なステップにすぎません。次に、制御されたネットワーク環境の開発と機能を監視し、常に最新情報を把握する必要があります。



次のヒントが役立ちます。

1. . . , .
2. . , .
3. . , . . , TH , .
4. 日常業務を自動化して、創造力を発揮し、創造的な解決策を試す時間を増やすことができます。
5. 大量のデータを分析するプロセスを簡素化します。これを行うには、分析担当者がネットワークとネットワークノードで何が起こっているかを1つの画像として確認するのに役立つツールを使用すると便利です。これらのツールは、TIの指標を交換するためのプラットフォーム、トラフィック分析システムとSIEMシステムを。

Positive TechnologiesのPT Expert Security Center、Anton Kutepov による投稿。



分析全体は、PT Network Attack Discoveryトラフィック分析システムとMaxPatrol SIEMセキュリティイベント管理システムで実行されました。