HarmonyPotから考える、観測データをCTIに変える3段階
先に結論
2026年9月1日時点のHarmonyPotは、Cloudflare Workers上で動く低対話型Webハニーポットであり、脅威インテリジェンス活動としては「レベル1: 公開観測」に位置付けられる。
一般利用者や自動scannerには一貫した認証ポータルに見える。一方、技術に詳しい第三者には、harmonypotというhost名、蜂蜜favicon、不可視のdiagnostics link、robots.txtから、デコイである可能性が高く見える。この公開性は欠陥と断定できず、秘匿収集ではなく研究、抑止、不確実性を目的にするなら整合するのだ。
重要なのは、見た目や取得量でレベルを決めないことである。
| 活動レベル | 問い | 得られる価値 | 言えないこと |
|---|---|---|---|
| 1 公開観測 | 独立した公開囮へ何が到達するか | 背景活動、探索面、Payload、収集基盤の検証 | 自社が狙われたとは言えない |
| 2 指向型収集 | 特定の脅威仮説に対して何が観測されるか | 比較、仮説評価、検知候補、TTP理解 | 保護対象の名前空間宛てとは言えない |
| 3 保護対象ドメイン指向型収集 | 守るべき名前空間へ何が到達するか | 組織適合性、固有の監視・防御優先度 | 到達だけで標的意図・本人性・侵入成功は示せない |
現在のHarmonyPotは、レベル1として探索系列や限定Payloadを安全に観測する基礎センサーである。レベル2へ進むには具体的なPIRと比較設計が、レベル3へ進むには保護対象の実サブドメイン、内部telemetryとの相関、法務・経営を含む追加承認が必要なのだ。
まず、混同しやすい四つの軸を分ける
「レベル」という言葉は混ざりやすい。少なくとも次の四つは別に考える。
| 軸 | 表すもの | 例 |
|---|---|---|
| 活動レベル | 保護対象への指向性とCTI活動の能動性 | レベル1〜3 |
| 対話レベル | 囮が送信者へ許す機能・操作の深さ | 低対話、高対話、Hybrid |
| 配置形態 | センサーを置く場所 | Internet、内部、研究網、実環境統合 |
| CTI組織成熟度 | 人員、process、技術、共有能力 | 組織のProgram maturity |
低対話型でも、保護対象の実サブドメインを使い、組織固有のPIRへ答え、防御判断へ接続すればレベル3になり得る。逆に、高対話型で大量のコマンドを取得しても、問い、分析、配布、Feedbackがなければ上位にはならない。
外部からはどう見えたか
第三者観測は、公開画面、HTML、CSS、JavaScript、HTTP応答、公開metadata、架空credentialによる3回の認証失敗だけを対象にした。repository、内部log、管理画面、Cloudflare accountは参照していない。
確認できた外形は次のとおりである。
Secure Access Portalという英語の認証画面- Email、Password、Remember this device、MFA案内
- password reset、help、status、release notes、admin console
XSRF-TOKEN、laravel_session、CSRF token、Vite風asset path- 401、429、403、404、503を使い分ける応答
- 同一sessionで3回目の認証試行を429へ変える状態
- responsiveなdesktop・mobile画面
- CSP、HSTS、X-Frame-Optionsなどのsecurity header
- 同一sessionの正しいdiagnostics tokenへ204、推測値へ404を返す挙動
これらは、Laravel/Vite風のSecure Access Portalという一つの人格を支えていた。実際のbackend技術を証明するものではないが、外形の整合性は高い。
一方、デコイ性を示す手掛かりも明瞭だった。
- host名に
harmonypotを含む - faviconが蜂と蜂蜜を示す
- 組織名、logo、連絡先、法的表記がない
- statusとrelease notesが短く汎用的である
- robots.txtが
/admin、/api/、/storage/、/vendor/を列挙する - 画面上で不可視のdiagnostics linkがHTMLから見つかる
したがって第三者には、「本物へ隠密に擬態するサイト」というより、「実サービスらしい外形を持ちつつ、ハニーポットと識別できる観測センサー」に見えた。この判断の分析確信度はHighである。ただし、内部の観測能力や活動効果は外部から確認できない。
公開性は目的によって意味が変わる
ハニーポットだと識別されれば、回避、無害な通信への切替、誤誘導用Payloadの投入が起こり得る。観測結果には「知らずに接触した活動」と「ハニーポットだと理解して接触した活動」が混ざるselection biasがある。
それでも公開性が直ちに失敗とは限らない。公開した欺瞞によって相手へ不確実性を与える、研究センサーとして挙動を説明可能にする、といったOperational Objectiveもあり得るからである。
秘匿性をKPIにする活動なら、host名やfaviconは弱点になる。研究、抑止、公開された観測面を目的にするなら、意図した設計になり得る。成否は「本物に見えたか」ではなく、PIRと評価指標に照らして判断するのだ。
内部設計から確認できたこと
外部観測とは別に、2026年9月1日時点のrepository設定と実装から、HarmonyPot v1.3の安全境界を確認した。
Internet
|
v
Cloudflare DDoS Protection / WAF / Rate Limit
|
v
Honeypot Worker
|-- 固定応答と行動分類
|-- 外部fetch、実認証、実command、uploadなし
|
+--> Analytics Engine: 匿名・正規化event
+--> Workers Logs: 高関心・異常eventのみ
+--> Durable Objects: 認証試行状態とRaw件数上限
+--> Private R2: 条件付きRaw、短期保持
主な境界は次のとおりである。
| 対象 | 確認した制御 |
|---|---|
| Raw Body | 最大16KiB |
| Raw Path / Query | 各最大4KiB |
| Raw保存件数 | 15,000 objects / UTC day |
| Raw保存先・保持 | private R2、最大7日 |
| 通常event | 生IP、生User-Agent、生Referer、Cookie、Authorizationを保存しない |
| 匿名相関 | visit IDとpath fingerprintでHMACの用途を分離 |
| 認証状態 | 3回でlock、作成から6時間で削除 |
| 危険機能 | 外部URL fetch、upload、実command、実脆弱性、実DB、実認証なし |
| 障害時 | Analytics、R2、状態管理の障害で公開応答を500にしない |
HMAC化は匿名化を保証しない。鍵管理、rotation、アクセス制御、保持制限は別に必要である。interestScoreも悪性度ではなく、機微path探索やCanary到達など、分析対象としての関心度を表す。
本番トラフィックについては確認できなかった
同日、Cloudflareの既存認証が期限切れで、Workers LogsとAnalytics Engineの本番履歴を取得できなかった。そのため、自然到達event、件数、国・ASN分布、Raw保存件数について、本記事は事実を主張しない。
確認できたのは、repository上の構成、契約test 14件とTypeScript型検査の成功、合成requestを用いた匿名event構造である。合成eventからは、機微path探索を403として分類し、Raw Path、Query値、生IP、生User-Agent、Cookie、Authorizationをcustom logへ出さないことを再現できた。
これは本番書き込みの成功や実攻撃の到達を示さない。取得不能は「logが存在しない」ことも意味しないのだ。
レベル1: 公開観測
レベル1は、保護対象から独立した公開センサーで、不特定の送信元から到達する探索、認証試行、Payload、Canary到達を観測する活動である。
現在のHarmonyPotが得意なのは次の領域である。
- 通常利用者のいない面で、管理、機微path、Canary到達を優先する
- 限定Rawから未知の文字列、endpoint、入力形式を調べる
- 匿名visit内の
landing → discovery → auth → sensitive → canaryを比較する - route familyとreason codeをWAFやSIEMの候補条件へ変換する
- 保存上限、匿名化、degraded動作、Canary、状態管理を検証する
一方、次は分からない。
- 保護対象企業への標的性
- 実資産の技術や利用者に対する適合性
- OS、shell、process、永続化、C2などの侵入後TTP
- 任意TCP、PCAP、Cloudflare前段で拒否された通信
- IPから人物や組織を特定する帰属
- HTTP応答からの脆弱性悪用や侵入成功
harmonypot.area11.orgがサブドメイン形式であるだけでは、レベル3にはならない。親ドメインが正式な保護対象で、その名前空間を使うPIR、承認、隔離、組織内telemetryとの相関がそろう必要がある。
レベル2: 指向型収集
レベル2では、文書化したPIRや脅威仮説に合わせて、囮のNarrative、技術stack、公開経路、Lure、観測項目、期間を意図的に変える。保護対象の実サブドメインは使わず、管理下の研究環境で比較する。
たとえば、次のような実験である。
- 異なるWeb技術を模した複数センサー間で探索系列を比較する
- 脆弱性公表前後でPayloadと到達時期の変化を測る
- 認証面のLureをA/B比較し、Canary conversionの差を評価する
- 既存WAF・SIEMで未検知の再現可能な系列を検知候補へする
レベル2の必須条件は、具体的PIR、比較可能なbaselineまたは対照、複数情報源との相関、分析確信度、推奨行動、Feedbackである。画面を特定製品風にしただけ、log項目や保存量を増やしただけではレベル2にならない。
レベル3: 保護対象ドメイン指向型収集
レベル3は、実際に守るべきドメインの管理下にあるサブドメインを隔離センサーへ割り当て、その名前空間宛ての偵察、探索、認証試行、Payloadを組織内情報と相関する活動である。
追加で得られるのは、一般的なInternet背景活動ではなく、保護対象の名前空間への到達という組織適合性である。ただし、Certificate Transparency、DNS辞書探索、検索engine、無差別scanから発見された可能性があるため、到達だけで「当社を狙った」とは言えない。
開始には少なくとも次が必要になる。
- 親ドメインが正式な保護対象である
- 独立ドメインではPIRを満たせない理由がある
- Domain/DNS Owner、Security、Legal/Privacy、経営の承認がある
- 実認証、SSO、Cookie、secret、業務data、内部networkから隔離している
- 一般Internet trafficや対照センサーと比較できる
- WAF、DNS、ID、mail、EDR、脆弱性管理、IRと相関できる
- 誤到達、brand、個人情報、有害data、外向き悪用のriskを受容している
- 24時間連絡先、停止、DNS切離し、保全、廃止のrunbookがある
組織を意識した活動の可能性は、宛先host、組織固有の名称・経路・文書、到達順序、時間集中、他の保護対象での同時観測など、独立性を確認した複数証拠で評価する。帰属、実行、権限取得、侵入成功には、それぞれを直接示す別証拠が必要なのだ。
レベルを上げる前のgate
| 移行 | 必要な証拠 |
|---|---|
| L1 → L2 | 承認済みPIR、脅威仮説、対照、変更したNarrative・Monitoring、完了したCTI cycle、検知・防御へのFeedback |
| L2 → L3 | 保護対象ドメインの正式指定、実サブドメイン利用承認、隔離・出口制御・データ保護の検証、組織内相関、追加risk受容、撤去手順 |
DNSを向けただけではレベル3にならない。必須条件を満たせなくなった場合は、活動を停止するか、満たせる下位レベルへ戻す。昇格は機能追加ではなく、問い、証拠、責任、危険の範囲が変わる承認なのだ。
観測結果を書くときの境界
HarmonyPotのような単一センサーから強く言えるのは、「その時点に、そのセンサーが、そのrequestを受け、所定の応答や分類を行った」という事実である。
次の表現は分ける必要がある。
| 観測 | 言えること | 追加証拠なしでは言えないこと |
|---|---|---|
| HTTP 200 | requestへ200を返した | Payloadが実行された、侵入した |
| 認証POST | formへ入力が送信された | 実credentialである、認証突破した |
| Canary到達 | 誘引経路へrequestが来た | 人が意図的に探索した |
| 送信元IP | network上の送信元として観測した | 人物、組織、所在地、帰属 |
| 匿名visit系列 | 同じ相関子でeventが続いた | 同じ人物・端末・組織である |
| log未取得 | 確認範囲でlogを取得できなかった | eventやlogが存在しない |
事実、分析判断、未確認事項を分けるだけで、ハニーポットのreportはかなり強くなる。派手な帰属より、どの証拠が次の判断を変えるかを明記する方が、長く使えるCTIになるのだ。
関連記事
参考資料
- FIRST CTI SIG, Curriculum: https://www.first.org/global/sigs/cti/curriculum/
- FIRST CTI SIG, Introduction to CTI: https://www.first.org/global/sigs/cti/curriculum/cti-introduction
- FIRST CTI SIG, Priority Intelligence Requirement: https://www.first.org/global/sigs/cti/curriculum/pir
- FIRST CTI SIG, Source Evaluation and Information Reliability: https://www.first.org/global/sigs/cti/curriculum/source-evaluation
- FIRST CTI SIG, Communicating Uncertainties in CTI Reporting: https://www.first.org/global/sigs/cti/curriculum/cti-reporting
- MITRE, A Practical Guide to Adversary Engagement, Version 1.0: https://engage.mitre.org/wp-content/uploads/2022/04/EngageHandbook-v1.0.pdf
- ENISA, Proactive Detection of Security Incidents: Honeypots: https://www.enisa.europa.eu/publications/proactive-detection-of-security-incidents-II-honeypots
- Cloudflare Workers Logs: https://developers.cloudflare.com/workers/observability/logs/workers-logs/
- Cloudflare Analytics Engine SQL API: https://developers.cloudflare.com/analytics/analytics-engine/sql-api/
- Cloudflare Analytics Engine sampling: https://developers.cloudflare.com/analytics/analytics-engine/sampling/
- Cloudflare R2 Object Lifecycles: https://developers.cloudflare.com/r2/buckets/object-lifecycles/