概要

Intelligence X（intelx.io）— 製品概要と価値

Intelligence Xは、セキュリティチーム、企業IT、調査・捜査・インテリジェンス業務に携わる担当者が、外部公開情報や漏えい由来データを用いて「露出（exposure）の有無を素早く検証し、証跡として保存し、運用に組み込む」ためのOSINT検索エンジン／データアーカイブです。一般的なキーワード検索とは異なり、Intelligence Xはセレクター（selector）—メールアドレス、ドメイン（限定的なワイルドカード挙動を含む）、URL、IP/CIDR、電話番号、暗号資産アドレスなど—のような“高信号の識別子”を中心に設計されており、インシデント対応やリスク評価のワークフローに直結する検索を行いやすいことが特長です。

価値の中核は「対象範囲（ソースの幅）＋実務向けのワークフロー」にあります。複数のソースカテゴリをひとつのUI（およびAPI）で扱い、バケット（bucket）によるカテゴリ絞り込み、日付やファイル種別でのスライス、アーカイブ内容のインライン閲覧、エクスポートなど、トリアージから記録・共有までを進めやすくします。さらに漏えい分析を強く求める組織向けに、Identity Portalが、行単位（line-by-line）での表示、セレクターのハイライト、漏えいアカウント／行のエクスポートなど、実務に特化した操作性を提供します。

運用面では、Intelligence Xはアナリスト主導の調査と自動化（API連携）の双方に対応します。ライセンスにより、検索・エクスポート等の上限や、APIの利用範囲（上限・用途・統合権など）が定義されます。SOC/IRのチケット、SIEM/SOARのエンリッチメント、IAMの検証などに、許諾範囲内で検索結果を取り込むことができ、必要に応じてIdentity Portalで大量結果の解釈と整理を加速できます。

製品概要

Intelligence Xは、次のような実務上の問いに、素早く・説明可能な形で答えるためのOSINT基盤です。

• 自社のメールアドレスやドメインが、漏えいデータやスティーラーログに含まれていないか？
• 不審なURLやIP、CIDR、電話番号、暗号資産アドレスなどが、リスクの高いソースに出現していないか？
• 露出の有無と範囲を検証し、証跡として保存・エクスポートできるか？
• 調査ロジックをAPIで運用フローに組み込み、再現性のある手順にできるか？

OSINTは有用な一方、構造がないと運用が崩れがちです。Intelligence Xは、セレクター中心とバケット分類によって調査を整理し、トリアージと証跡化を進めやすくします。

主な機能

セレクター中心の検索

Intelligence Xは、キーワード探索よりも、調査・対応で使う「識別子」を起点にする設計です。

• まず、メール／ドメイン／URL／IP／CIDRなどのセレクターを入力
• バケット、日付、ファイル種別などで絞り込み
• 結果をインラインで確認し、必要に応じてエクスポート
• ライセンスの許諾範囲内で、同じ手順をAPIで自動化

この流れは、IRや脅威ハンティング、ID露出確認などの現場手順に合わせやすいのが特長です。

対応セレクター（検索入力）

代表的なセレクター例：

• メールアドレス
• ドメイン
• URL
• IPアドレス（IPv4/IPv6）／CIDR
• 電話番号
• 暗号資産アドレス（例：Bitcoin、Ethereum）
• MACアドレス
• IPFSハッシュ／アドレス
• 個人・金融系の識別子形式（データセット内で該当する場合）

このため、ID露出（メール）、インフラ露出（ドメイン/IP/CIDR）、外部フットプリント（ドメイン/URL）、不正送金等の調査（暗号資産アドレス）など、複数の調査領域を横断できます。

バケット（ソース分類）

Intelligence Xは、収集・インデックスされた情報をバケットとして分類し、結果を絞り込みやすくします。バケットは、UI上の分析だけでなく、APIでのフィルタ設計にも活用できます。

例（考え方）：

• 漏えい・リーク由来のカテゴリに限定する
• Tor/I2P関連のカテゴリに寄せる
• 公開ウェブやpaste系に絞る
• 調査仮説に合うカテゴリを優先し、ノイズを減らす

バケットの提供範囲や制限は、ライセンスにより異なる場合があります。

検索仕様と制約（できないこと）

運用上の誤解を避けるために、次の点は前提として押さえる必要があります。

• 全文検索（フルテキスト検索）は非対応
• 正規表現（regex）検索は非対応
• AND/ORなどのブール演算子検索は非対応

その代わりに、セレクター入力と、バケット／日付／ファイル種別などのフィルタを中心に検索を組み立て、追加の絞り込みが必要な場合はクライアント側で後処理します。

ドメイン・URL検索の挙動

ドメインやURLは入力形式により挙動が変わるため、運用手順（入力ルール）を揃えることが重要です。

• ドメイン検索：入力タイプに応じて、関連するサブドメイン、URL、メールなどがヒットし得ます（探索を広げやすい）
• パスを含むURL：特定のURLをより厳密に検証する意図に向きます
• URLの正規化：検索前にクエリ部分（「?」以降）を除去して扱われます

運用のコツ：

• 広く確認したいときはドメイン → 絞り込み
• 既知の不審パスの検証はURL（パス込み）で確認
• 入力の統一（正規化される前提）を手順書に落とし込む

Phonebook（強いセレクター探索）

調査では、最初から完全なセレクターが手元にないことが多いです。Phonebookは、断片的な手がかりから「検索に強いセレクター」を見つける発想を支える機能です。

活用例：

• 外部フットプリント把握（ブランド・露出調査）
• ベンダー／第三者の露出マッピング
• IRでのスコーピング（関連メールや関連ドメインを起点化）
• 自動化パイプラインの前段（ターゲットセレクター抽出）

アーカイブのインライン閲覧

アーカイブされた結果（HTML、PDF、Office文書、画像など）を、可能な範囲でプラットフォーム内で閲覧できるため、

• トリアージが速い（タブ移動やダウンロードが減る）
• リスクのあるブラウジングを抑えやすい
• 証跡化・共有の前処理がしやすい

といった運用メリットがあります。

エクスポートと証跡（エビデンス）

Intelligence Xは、調査結果をオフライン分析やケース管理に回すためのエクスポート導線を提供します。

代表例：

• 個別結果の保存（ファイル保存）
• 検索結果の一括エクスポート（例：ZIPなど）
• セレクター出現箇所の行抽出（Identity Portal）

エクスポート上限や扱える範囲は、ライセンスと利用条件に依存するため、運用ポリシーと合わせて設計します。

Identity Portal（漏えい分析向け）

漏えいデータやスティーラーログ由来の調査では、「見つける」より「大量結果を解釈し、実務で使える形に整理する」工程がボトルネックになりがちです。Identity Portalはその工程に最適化された別インターフェース／製品です。

主な特長：

• 行単位（line-by-line）で結果表示し、セレクターをハイライト
• 漏えいアカウントの抽出（Export Leaked Accounts）：パスワード表現／タイプやソース情報などを含めて出力
• スティーラーログのリバースルックアップ（ベータ）：対象ドメイン／URLに紐づく漏えいアカウントを抽出する用途
• CSVや行出力など、下流処理に載せやすい形式でエクスポート

ID露出確認、IRでのアカウント洗い出し、認証強化施策の対象抽出などに向きます。

ライセンスとエディション

ライセンスモデル（前提）

Intelligence Xは年額サブスクリプションの考え方を基本に、エディションごとに以下が定義されます。

• 日次の検索・Phonebook・エクスポート等の上限
• 利用できるデータカテゴリ（バケット等）の範囲
• Identity Portal機能の有無
• APIの利用範囲（上限、用途、統合権/OEM権の有無など）

代表的なエディション（例）

Researcher（個人・単独運用向け）

• 人手による調査を中心に、安定した利用上限を確保したい場合に適合
• APIは「許諾範囲内での利用」を前提とし、製品組み込み（OEM）用途とは切り分けて考える

API（統合／OEM向け）

• 内部ツールやワークフローに公式にAPIを組み込む権利を重視する場合に適合
• SOC自動化、ポータル連携、繰り返しレポーティングなどの用途に向く

Identity Portal（漏えい分析特化）

• 漏えい・スティーラーログ由来の大量データを、行単位で精査し、漏えいアカウントを抽出・エクスポートする運用に適合
• リバースルックアップ（ベータ）など、漏えい分析特化の機能を重視する場合に選択肢となる

Enterprise（複数ユーザー／高ボリューム）

• 複数部門・複数ユーザーで継続運用し、調査量・監視・エクスポートを拡張したい場合に適合
• チーム運用とガバナンス（役割分担、上限設計）を前提に導入しやすい

API利用と「統合権」の考え方

API連携は“技術”ではなく、契約・コンプライアンス上の権利（用途の許諾）として整理するのが重要です。
同じAPI呼び出しでも、調査補助なのか、製品組み込み（OEM）なのかで扱いが変わるため、用途と運用範囲をライセンスに合わせて設計します。

導入効果

• 露出確認の迅速化：ドメイン／メール／IP等のセレクターで、必要な範囲に絞って検証できる
• トリアージ工数の削減：バケット、日付、ファイル種別、インライン閲覧でノイズを減らす
• 証跡化のしやすさ：アーカイブ閲覧とエクスポートにより、説明可能な形で記録しやすい
• 運用の再現性：セレクターとフィルタ条件を標準化し、チーム内で手順を揃えやすい
• 漏えい分析の実務化：Identity Portalで行単位表示と漏えいアカウント抽出を行い、大量結果を処理しやすい

※効果は運用設計、対象範囲、チーム成熟度により変動します。

ユースケース

1) 漏えい露出確認（ドメイン／メール）

• 対象ドメインや重要メールをセレクターにし、漏えい関連のバケットを優先して絞り込み
• Identity Portalで行単位確認と漏えいアカウント抽出を実施し、IAM対応に接続

2) インシデント対応のエンリッチメント（ドメイン／URL／IP）

• 既知IOCをセレクターに検索
• バケットと日付で優先度を整理し、証跡としてエクスポートしてケース管理へ

3) 脅威ハンティング（ピボット調査）

• URL→ドメイン→関連成果物のようにピボット
• ファイル種別で高信号アーティファクトを優先し、共同分析用にまとめる

4) 第三者・ベンダー露出の確認

• ベンダー所有ドメインや関連セレクターで外部露出を確認
• 結果を根拠として、是正依頼や追加確認の材料にする

5) スティーラーログ由来の調査（Identity Portal）

• 対象サービスのドメイン／URLに対してリバースルックアップ（ベータ）を活用
• 抽出結果をエクスポートし、影響範囲の洗い出しや対応優先順位付けに利用

一般的な競合・代替との比較観点（特定製品名なし）

OSINTや露出確認の領域は、用途により代替・補完関係が発生します。比較の際は、次の観点で整理すると評価しやすくなります。

• 検索起点：キーワード中心か、セレクター中心か
• 結果の整理：ソース分類（バケット等）とフィルタが実務に耐えるか
• 証跡化：アーカイブ閲覧、エクスポート、再現性のある手順が組めるか
• 漏えい分析の実務性：行単位表示、漏えいアカウント抽出など“後工程”が強いか
• 自動化・統合：API連携の許諾範囲、上限、用途（統合権/OEM）を明確にできるか
• 運用ガバナンス：上限設計や役割設計で、使い過ぎ・データ拡散を抑えられるか

FAQ

Q1. 月額契約はありますか？
A. いいえ。年間契約です。

Q2. キーワードの全文検索やフレーズ検索はできますか？
A. いいえ。セレクター中心の検索を前提としており、全文検索は想定していません。

Q3. 正規表現（regex）やAND/OR検索はできますか？
A. できません。セレクター入力と、バケット／日付／ファイル種別などのフィルタで検索を組み立てます。

Q4. セレクターとは何ですか？
A. メールアドレス、ドメイン、URL、IP/CIDR、電話番号、暗号資産アドレスなど、検索入力として扱える識別子のことです。

Q5. バケットとは何ですか？
A. 収集・インデックスされた情報をカテゴリ分けした単位です。結果の絞り込みや、APIでのフィルタ設計に使います。

Q6. URL検索では何に注意すべきですか？
A. URLは正規化され、検索前にクエリ部分（「?」以降）が除去されます。運用手順として入力ルールを統一すると再現性が上がります。

Q7. Identity Portalは何が違いますか？
A. 漏えい分析の後工程（行単位表示、漏えいアカウント抽出、スティーラーログのリバースルックアップ［ベータ］など）に最適化されたインターフェース／製品です。

Q8. API連携はどのエディションが適していますか？
A. 製品組み込みや公式な統合権（OEM）を重視する場合は、APIエディション（またはそれ以上）の選択が前提になります。用途と許諾範囲はライセンスに合わせて整理します。