mthcht/threathunting-keywords脅威ハンティングセッションのためのキーワードとアーティファクトの素晴らしいリスト
🎯 ThreatHuntingセッションのためのキーワードリスト
Threat huntingは、組織のネットワークまたはシステム内で、自動化されたセキュリティ対策を迂回した可能性のある悪意のある活動を検出するための、プロアクティブかつ反復的なアプローチです。セキュリティアラートによってトリガーされるリアクティブな調査とは異なり、Threat huntingは脅威インテリジェンス（TI）に基づくチェックと、体系的かつ機会的な分析から導き出された仮説によって推進されます。これらの仮説 💡 は、ハンターが未知の脅威、潜在的な脅威、またはセキュリティ検出を回避した可能性のある既知の脅威に加えて、自動化システムが見逃したり除外したりする可能性のある脆弱性や侵害指標（IoC）を発見するのに役立ちます。このプロセスはまた、アラート/ダッシュボードの前兆を特定し、SOC/トリアージワークフローを改善することに焦点を当て、シャドウ資産インベントリ管理にも貢献し、さらなる調査を必要とする低/中忠実度のイベントをエスカレーションします。主な目的は、脅威アクターが使用する戦術、技術、手順（TTP）を特定し、組織が潜在的な攻撃を先制的に検出して軽減する能力を強化することです。
SOC内で高品質な検出ルールを維持するために、部分的に自動化されたThreat Huntingセッションを組織化するための私のプロセス提案です。
SOCチームは、検出成熟度ピラミッドのすべてのレベルにわたって高忠実度の検出を展開し、誤検知を最小限に抑えながら既知の脅威をターゲットにすることに注力しています。Threat Huntingはこれを補完し、未知の脅威、高度なTTP、高い誤検知率が発生しやすい異常に対処し、ギャップを埋めて標準的なSOC機能を超えた検出カバレッジを強化します。
理想的には、各Threat Huntingセッションには明確な目的が必要です。このフローチャートは、準備と調査から実践可能な推奨事項まで、プロセスを導く構造化されたアプローチを提供します。
🎯 ThreatHuntingセッションのためのキーワードリスト
ThreatHunting-Keywordsリストは、脅威アクター（またはレッドチーマー 😆）がログ内で有名な悪用ツールのデフォルト設定を使用していることを特定するのに役立つため、SIEMでの静的解析においてThreat Hunter、SOC、CERTチームにとって貴重です。 このリストはIOCフィードとは異なり、永続的な関連性を持ちます。ここにあるキーワードには「有効期限」がなく、追加から数年後でも脅威を検出でき、ワイルドカードと大文字小文字を区別しないマッチングを受け入れ、デフォルトのキーワードにのみ焦点を当てた柔軟性があります。
主にThreat Hunting用に設計されたこのリストは、複雑なシナリオでも役立ちます。 管理していないSIEMにアクセスでき、データがパースされていない場合でも、適切に管理されたSIEMを使用するSOCチームの一員である場合でも、ここに記載された例は何もパースする必要なく悪意のある活動の検出プロセスを迅速化できます。ログがすでにパースされている場合は、このリストを使用してデータ内のフィールドとマッチングでき、選択したキーワードタイプのカテゴリに基づいて検出ルールに変換できる可能性があります（誤検知率が十分に低い場合）。
⚠️ すべてをこのリストに追加できるわけではありません。ここでは複雑な動作検出は行わず、デフォルト設定を検出することを目的とした、フィールドまたはrawログでの単純なキーワード検出のみを行います
⚠️ リスト内の多くのツールには専用の検出ルールがあり、イベントをしきい値や固有のプロセス関係と相関させています...ここではツールの可能な検出をすべて網羅するわけではなく、キーワード検出のみを扱います
セキュリティオペレーションセンター（SOC）の一員であり、フィールドやイベントの相関なしに単純なキーワード検出のみに依存する何百もの検出ルールを管理している場合は、アプローチの再考を検討してください。私の意見では、これらは個別の検出ルールを構成すべきではありません。代わりに、このような統合リストの方が適している可能性があります。ただし、Splunkのようなプラットフォームを使用していない場合、実装はより困難になるかもしれません。
このアプローチは、単純なフィールドキーワード検出を1か所で整理して管理しやすく保ちながら、高品質で目的のあるルールの作成を促進します。最終結果は？それらすべてをカバーする1つの包括的な検出ルールです。これによりプロセスが合理化され、検出機能が最適化されます。
インシデントレスポンダーは、調査中にrawログやファイルでこのリストを使用して、既知の悪用ツールを迅速に特定できます。Yaraルール、powershellスクリプト、またはSplunk4DFIRでログをSplunkにすばやく取り込むことによって。
単純なキーワード検出による検出を回避するには、操作中に使用しているツールに関連付けられる可能性のあるすべてのカスタム文字列、クラス名や関数名、変数名、引数名、実行可能ファイル名、デフォルトのユーザーエージェント、証明書、その他の文字列を再コンパイルしてリネームすることが重要です。通常のトラフィックに溶け込むために、すべてに最も一般的な名前を使用してください。こちらにあるスクリプトは、これらの一部を特定するのに役立ちます。
ただし、公開の「レッドチームツール」を開発している場合は、明確な名前を使用してブルーチームを支援することを検討してください。エキゾチックなポート、カスタム証明書、独自のユーザーエージェント、一般的ではない特定の関数名と引数を備えたデフォルト設定を使用してください。これにより、単純なキーワード検出に使用できる明確なシグネチャの作成が支援され、ブルーチームが少なくともスクリプトキディを簡単に検出できるようになります。
keyword,metadata_keyword_type,metadata_tool,metadata_description,metadata_tool_techniques,metadata_tool_tactics,metadata_malwares_name,metadata_groups_name,metadata_category,metadata_link,metadata_enable_endpoint_detection,metadata_enable_proxy_detection,metadata_tags,metadata_comment,metadata_severity_score,metadata_popularity_score,metadata_github_stars,metadata_github_forks,metadata_github_created_at,metadata_github_updated_at