producing-threat-intelligence

脅威インテリジェンスの作成

インテリジェンスは、インジケーターを積み上げたものではありません。意思決定者の不確実性を減らす分析です。コンテキストも確信度も推奨アクションもない IOC は、データであってインテリジェンスではありません。アトリビューションは、脅威アクターの名前を当てはめた推測ではなく、証拠に基づいて擁護できる主張でなければなりません。成果物が完成したかどうかの基準はシンプルです。それによって、誰かの意思決定が変わったでしょうか？

使用する場面

• ドメイン、IP、ハッシュ、TLS 証明書、登録者を起点に、関連するインフラストラクチャをたどる場合
• 脅威アクターやキャンペーンを時系列で追跡する場合
• 生のインジケーターを有用なインテリジェンスへとエンリッチし、コンテキストを付与する場合
• 明確な利用者向けに完成したインテリジェンス成果物を作成する場合
• 外部ベンダーや政府機関のレポートが自組織に関連するかを評価する場合
• 自組織にとって実際に重要な敵対者の脅威モデルを構築し、管理する場合

使用しない場面

• 自組織のテレメトリ内で活動を検索する場合 — hunting-threats を使用してください
• 特定のサンプルをリバースエンジニアリングする場合 — analyzing-malware を使用してください
• ATT&CK のテクニック ID に対応するスキルを特定する場合 — mapping-attack-techniques を使用してください
• 進行中で、発生が確認されたインシデントの場合 — responding-to-incidents を使用してください
• インテリジェンスを導入済みの検知ルールにする場合 — engineering-detections を使用してください

インテリジェンスのライフサイクル

すべての成果物は同じサイクルをたどります。各段階に名前を付けるのは形式主義のためではありません。CTI を無価値にする二つの失敗を見つけるためです。

1. Direction     — whose decision, which question (a PIR)
2. Collection    — gather against the requirement, not everything reachable
3. Processing     — normalize, deduplicate, translate, enrich
4. Analysis      — assess, weigh hypotheses, assign confidence
5. Dissemination — deliver in a form the consumer can act on
6. Feedback      — did it help; refine the next requirement

CTI の労力の大半を無駄にする二つの失敗は、サイクルの中盤ではなく両端で起きます。

• 方向付けを省略すると、誰も求めていないインテリジェンスが生まれます。利用者と意思決定を明記した優先インテリジェンス要件（PIR）がなければ、集めやすい情報を集め、興味深い情報を報告することになり、誰の手元にも届きません。フィードではなく、問いから始めてください。
• 配布を省略すると、分析が意思決定に結び付きません。誰も読まない Wiki に優れた評価が置かれていても、何も変わりません。成果物は書き終えた時点で完成するのではありません。それに基づいて行動する人のもとに、必要な形式とタイミングで届いた時点で完成します。

情報を収集する前に PIR を作成してください。例：「どのランサムウェアグループが自組織の業界を標的にしており、初期アクセスにどのような手法を用いているか？」「先週のインシデントに関与したアクターは再び攻撃してくる可能性が高いか？」「このベンダーレポートは自組織への脅威について述べているか？」それぞれ、利用者と意思決定を明確にしています。

インジケーターのピボット

ピボットによって、1つのオブザーバブルからインフラストラクチャの全体像を把握できます。基本はまず受動的に調査することです。以下のピボットでは、すべて第三者のデータや過去の記録を参照し、いずれも攻撃者の稼働中のインフラストラクチャには接触しません。

起点	ピボット先	判明する情報
ドメイン／IP	パッシブ DNS（PDNS）	過去の名前解決、同じ IP を共有する関連ドメイン、ドメインが過去に使用した IP
ドメイン	WHOIS／登録履歴	登録者のメールアドレス、レジストラー、作成日、ネームサーバーの再利用
ドメイン／IP	証明書の透明性（crt.sh）	同じ証明書に含まれる他のホスト名、SAN の再利用、発行のタイムライン
IP／サービス	TLS フィンガープリント — JARM（サーバー）、JA3/JA3S（クライアント／サーバー間のハンドシェイク）	同じ C2 またはフレームワークのデフォルト TLS スタックを実行するホスト
Web サービス	ファビコンハッシュ（Shodan の http.favicon.hash、Censys）	同一のパネルやログインページを提供する他のサーバー
IP／ホスト	Shodan／Censys のバナー	開放ポート、製品のバージョン、応答本文、自己署名証明書の CN

ピボットの連鎖の例：フィッシングドメインが PDNS で IP に解決されます。crt.sh で、その証明書の SAN に、よく似た別のドメインが4つ含まれていることがわかります。その IP の JARM は既知の Cobalt Strike のデフォルト値と一致し、Shodan でパネルのファビコンハッシュを検索すると、同じインターフェースを提供する IP がさらに9つ見つかります。1つのインジケーターから、攻撃者に接触することなく、10件のクラスターが見つかりました。

# Certificate transparency — all certs/SANs seen for a domain
curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

# Shodan: everything serving an identical favicon
shodan search "http.favicon.hash:-247388890"

# Censys: hosts presenting a given JARM fingerprint.
# Censys Platform (CenQL) prefixes every parsed field with its dataset:
censys search "host.services.jarm.fingerprint: <jarm_hash>"
# Legacy Search used the unprefixed form below. It is deprecated as of
# September 2026, so treat any older query you find as needing conversion:
#   services.jarm.fingerprint: <jarm_hash>

攻撃者に気づかれないようにしてください。 稼働中の C2 に curl でアクセスしたり、自分に関連付けられるネットワークからそのドメインを名前解決したり、まだ有効なサンプルを公開マルチスキャナーに送信したり、インフラストラクチャを直接スキャンしたりしないでください。いずれも、オペレーターに監視されていると知らせ、インフラストラクチャの切り替えや、こちらの可視性を失わせるための焼却を招くおそれがあります。受動的なデータセットを優先してください。能動的な操作が本当に必要な場合は、自分に関連付けられないインフラストラクチャを経由し、意図的に記録を残す判断として実施してください。

追跡対象の優先順位付けに使うフレームワーク

ダイヤモンドモデル

すべての侵入イベントには、攻撃者、能力（マルウェア、ツール、エクスプロイト）、インフラストラクチャ（C2、ステージング、リダイレクター）、被害者という、相互に結び付いた4つの要素があります。どの要素からも別の要素をたどれます。能力からは、それを使う攻撃者がわかり、インフラストラクチャからは他の被害者がわかります。ピボットとは、文字どおりダイヤモンドの辺をたどることです。調査結果をこの4つの頂点に関連付けて記録しておけば、不完全な情報も次の情報と組み合わせられます。

ペインのピラミッド

インジケーターによって、変更にかかる攻撃者のコストは異なります。追跡対象が上位になるほど攻撃者への影響が大きくなり、インテリジェンスの有効期間も長くなります。

TTPs             ← hardest to change — track these
Tools
Network/Host artifacts
Domain names
IP addresses
Hash values      ← trivial to change — useful now, dead tomorrow

ハッシュや IP は攻撃者が簡単に切り替えられるため、これらを基にしたインテリジェンスは数日で陳腐化します。ツールや TTP を変更するには、実際の再開発が必要です。収集と追跡はピラミッドの上位を優先し、下位の情報はすぐに使えなくなるものとして扱い、それに応じたタイムスタンプを付けてください。

帰属の規律

帰属は、CTIで最も乱用されている言葉です。次の2つの作業は厳密に分けてください。

• クラスタリングでは、共通する観測可能な特徴（インフラのパターン、ツール、TTP、トレードクラフト、タイミング）に基づいて活動をグループ化します。これは証拠に基づいて正当化でき、ほとんどの場合に行うべき作業です。
• 命名では、あるクラスターが既知のアクターであると断定します。そのアクターの過去の活動、動機、地政学的な背景を引き継ぐことになり、誤りであることも少なくありません。

確認できていないクラスターには、暫定的で断定を避けたラベルを使ってください。UNC形式の未分類識別子、または独自の内部用 CLUSTER-#### を使います。証拠が裏付けている場合に限り、クラスターを名前の付いたアクターに昇格させ、どの証拠に基づくのかを明示してください。「同じTTP」は根拠として弱いものです。ツール、エクスプロイトキット、公開されているトレードクラフトが共通していれば、2つのオペレーターが同一に見えることがあります。

分析上の確信度は、主張とは別の軸です。明確に示してください。

• 高 — 複数の独立した情報源から一貫した裏付けのある証拠が得られており、妥当な代替説明がほとんどありません。
• 中 — 信頼できる証拠はありますが、欠落や単一の情報源への依存により、代替説明の余地が残っています。
• 低 — 断片的、または裏付けがありません。この評価は作業仮説です。

確信度は、自分がどれほど強く確信しているかと同じではありません。証拠と、依然として成り立つ代替説明の数によって決まります。

競合仮説分析（ACH）： 帰属や意図に異論がある場合は、まず妥当な仮説を列挙し、次に証拠を挙げ、各証拠がそれぞれの仮説とどの程度 整合するか を評価します。目的は、仮説を 否定する 証拠を見つけることです。反証を試みた後に残る仮説は、当初証明しようとしていた仮説よりも強いものです。

認知バイアスの罠を認識し、避けてください。

• ミラーイメージング — 敵対者も自分と同じように考え、優先順位を付け、行動すると仮定することです。
• 確証バイアス — すでにたどり着いた結論を支持する証拠を集めて重視し、それに矛盾する証拠を軽視することです。
• アンカリング — 最初に提示された帰属（多くの場合はベンダーのもの）に固執し、新たな証拠が得られても十分に見直さないことです。

構造化ストレージと標準

フリーテキストのメモでは、情報を組み合わせたり、相関付けたり、自動化に活用したりできません。最初から構造化モデルでインテリジェンスを保存してください。

• STIX 2.1 — 情報交換の文法です。オブジェクト（SDO）には indicator、malware、threat-actor、campaign、intrusion-set、infrastructure、identity、attack-pattern などが含まれます。uses、targets、indicates、attributed-to などの関係（SRO）がそれらを結び付けます。STIX の indicator には、パターン、有効開始日時／終了日時、確信度が含まれます。これは、単独のIOCにはないコンテキストです。
• MISP — イベント中心の共有プラットフォームです。イベントには、タイプ、カテゴリ、属性ごとのIDSフラグを持つ属性（インジケーター）が含まれます。ギャラクシーでは、アクター、ツール、ATT&CKのコンテキストを付与します。イベントをまたいで相関付けることで、自分のデータとパートナーのデータの重複が明らかになります。
• OpenCTI — STIXを取り込み、レポート間のオブジェクトを関連付けるナレッジグラフです。関係（どのキャンペーンがこのマルウェアを使用するか、このアクターがどのインフラを再利用しているか）をクエリできるため、関係を再度導き出す必要がありません。
• TLP — 共有区分です。すべての成果物にタグを付けてください。TLP:RED（指定された受信者のみ）、TLP:AMBER／TLP:AMBER+STRICT（受信者の組織、またはその組織内のみ）、TLP:GREEN（コミュニティ）、TLP:CLEAR（制限なし）です。タグはデータとともに引き継がれます。タグを引き下げるかどうかを決めるのは共有者であり、受信者ではありません。

エンリッチメントソース

エンリッチメントによって、コンテキストと確信度を伴わない単なるオブザーバブルに、コンテキストと確信度を加えます。問いに合ったソースを選びます。

ソース	分かること
VirusTotal	検出状況、関連性（接続先ドメイン、ドロップされたファイル、兄弟ファイル）、初回／最終確認日時、コミュニティの状況
パッシブ DNS（Farsight/DNSDB、SecurityTrails、Circl）	名前解決の履歴、同じホストで運用されているドメイン、時間の経過に伴うインフラの再利用
Shodan / Censys	公開されているサービス、バナー、証明書、JARM、ファビコンのハッシュ — 対象に直接触れずに把握できるインターネット側からの見え方
GreyNoise	IP がインターネット全体を一斉にスキャンしている（バックグラウンドノイズ）のか、それとも自組織を狙った活動なのか
URLScan	URL が実際に提供するもの — ページの内容、リダイレクト、リソース、スクリーンショット — 自分で閲覧せずに確認できます

GreyNoise の価値は、対象を絞り込めることにあります。 フラグが付いた IP の大半は、日和見的なスキャナーがあらゆる対象をスキャンする、インターネット上のバックグラウンドノイズです。GreyNoise を使えば、あるインジケーターがそうしたノイズなのか、標的を狙ったものなのかが分かります。そのため、Shodan のクローラーをエンリッチメントするのに分析担当者の時間を浪費せず、自組織を狙った活動に集中できます。

完成したレポートを作成する

レポートこそが成果物であり、それより前の作業はすべて情報の収集です。作業に感心する分析担当者ではなく、意思決定者に向けて構成します。

• BLUF（結論を先に述べる） — 評価と、その「つまり何が重要なのか」を最初の 2 文で示します。読者が最初の段落までしか読まなくても、答えが分かるようにします。
• 確信度と情報源 — 重要な判断ごとに分析上の確信度を示し、観測した事実と評価を分けます。主張を根拠に結び付け、単一の情報源によるものか、複数の情報源で裏付けられているかを明確にします。
• つまり何が重要なのか／推奨する対応 — 分析を、情報を利用する側の意思決定に結び付けます。何を実行、ブロック、ハンティング、優先すべきなのか、そしてなぜ今なのかを示します。推奨する対応のない評価では、読者自身が意味するところを考え直すことになり、多くの場合、それは行われません。

読者に合わせて書きます。経営幹部にはリスクと意思決定が必要です。SOC のリーダーには検出結果とピボットが必要です。同じ基盤となるインテリジェンスでも、成果物はそれぞれ異なります。

防御のループにおける CTI

脅威インテリジェンスは最終成果物ではありません。防御プログラムの他の部分を動かす燃料であり、その出力を取り込んでもいます。

• 検出に活用します：TTP とツールを、engineering-detections を通じてデプロイ済みのルールにします。生のフィードではなく、振る舞いと段階付けされたインジケーターを引き継ぎます。
• ハンティングに活用します：インテリジェンスレポートに記載された振る舞い（すでに使われていない IOC ではありません）を仮説にし、hunting-threats でテレメトリを対象に調査します。
• ATT&CK マッピングを活用します：mapping-attack-techniques を通じて技術を解決し、検出やハンティングと同じ分類体系を製品で使えるようにします。そうすることで、カバレッジのギャップが見えるようになります。

検出、ハンティング、意思決定のいずれにも反映されないインテリジェンスは、能力ではなく研究趣味にすぎません。

棄却すべき合理化

• 「指標は多いほど、インテリジェンスの質が高まる。」 いいえ。優先順位の付いていない IOC はノイズとなり、重要なわずかな情報を埋もれさせます。量は価値ではありません。文脈を伴う、順位付けされた少数の情報のほうが、1 万件のフィードに勝ります。
• 「同じアクターです。TTP が一致しています。」 TTP の重複は、同じオペレーターが使っている場合と同じくらい、ツールを共有している場合にも起こります。公開キットや流出したフレームワークにより、無関係なグループが同一に見えることがあります。証拠に基づいてクラスター化し、名前を付けないでください。
• 「ベンダーのレポートが帰属を示しているので、確定です。」 ベンダーによる帰属判断は、独自の偏りや動機を持つ一つの情報源にすぎません。その証拠を読み、評価し、自分で確信度を割り当ててください。相手の判断をそのまま引き継いではいけません。
• 「もっと知るために C2 をスキャンしましょう。」 監視していることをオペレーターに知らせたばかりで、相手はインフラをローテーションします。まずは受動的なデータセットを利用し、能動的なやり取りは、帰属につながらないインフラから意図的な判断としてのみ行ってください。
• 「確信度は高いです。しっくりきます。」 確信度は、確信の強さではなく、証拠と、なお残る代替仮説の数に基づいて説明できなければなりません。証拠を示せないなら、確信度は高くありません。
• 「レポートを作成しました。これで完了です。」 共有されなかったインテリジェンスは、どの判断も変えません。ライフサイクルは分析で終わるのではなく、利用者が行動を起こしたとき、または行動しなかった理由を伝えたときに終わります。
• 「このレポートは別の業界についてのものなので、関係ありません。」 関連性は、自分自身の脅威モデルに照らして判断するものであり、決めつけるものではありません。標的が異なっていても、TTP は転用される可能性があります。

外部ソースの読み込み

公開されているアドバイザリ、仕様書、ベンダーレポートを Markdown として取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの定型部分が取り除かれ、文章主体のページではトークン数が約 78％削減されます。また、要約ではなく全文が返されるため、grep で検索でき、見つからなかった場合の結果も信頼できます。

この方法に適さないものが 3 つあります。JSON と API のレスポンスは、可読性を高める抽出処理によって構造化データが損なわれるため、未加工のまま取得してください。認証が必要なページや JavaScript で描画されるページは、匿名で取得されるため、直接取得してください。また、敵対者のインフラ（フィッシングリンク、C2、マルウェアのホスティング）、クライアント所有のホスト、エンゲージメント URL は、決してこの方法で中継してはいけません。リクエストが自分のマシンから第三者へ送信され、稼働中の敵対者のインフラの場合は、オペレーターにも察知されるためです。

サイトによっては抽出ツールをブロックし、ページの代わりにエラーの内容を返すことがあります。たとえば freedesktop.org の {"error":"Failed to fetch: 418 I'm a teapot"} です。これは取得が拒否されたことを示すのであって、その情報源が対象のものは存在しないと述べているわけではありません。そこから結論を導く前に、URL を直接再取得してください。

参考資料

• hunting-threats — インテリジェンスから導いた仮説を、自分自身のテレメトリに対して検証する
• analyzing-malware — インテリジェンスに活用する、サンプル由来の設定、機能、IOC
• engineering-detections — 追跡対象の TTP を、導入済みのルールに変換する
• mapping-attack-techniques — ATT&CK 参照を解決し、標準化する
• responding-to-incidents — 進行中の事象における利用者と情報源
• reporting-security-findings — 完成した文書の構成と言葉遣い
• MISP、OpenCTI — 構造化された保存、相関分析、共有のためのプラットフォーム
• STIX 2.1 — 情報交換のためのオブジェクトと関係のモデル
• crt.sh — インフラのピボット調査に使う証明書透明性検索
• Shodan、Censys — インターネット全体を対象としたサービス、バナー、JARM、ファビコンの検索
• GreyNoise — インターネット上のバックグラウンドノイズと標的型の活動を区別する
• VirusTotal — 検知、関係性、エンリッチメントのコンテキスト