検索の網を広げたら294件――「即調査」に浮上した3つの公開サービスを追う
インターネットの外側から、公開されているサーバーやネットワーク機器、サービスを観測すると何が見えるのでしょうか。
「ネット探検EYE ― インターネット観測」の第2回です。
前回は、インターネット上に公開されている資産を実際に観測し、取得した情報を記録するところから始めました。
今回は観測先そのものを増やすのではなく、同じ観測先に対する検索クエリ（query＝検索条件/）を少し広げてみました。（具体的には、観測する空いるポート番号を増やした）
すると、想像していた以上に景色が変わりました。
今回観測された資産は294件。
前回との比較では、
NEW：196件
GONE：1件
MODIFIED：0件
となりました。
さらに、ネット探検EYEの自動スコアリングによって“173件が「要調査」”として抽出されました。
そして、その最上位に現れたのが、
- 120点・Tier1（ティアワン／即調査）――3件。
- 場所は香港。
- ポートは「4444」。
さらに3つの公開サービス（ノード）が、同一のTLS証明書を共有していました。
さて、これは何なのでしょうか？
今回は、単に「怪しいものを見つけた」で終わらせません。
観測 → 自動検出 → 相関分析 → 即調査 → 人による検証 → 判定 → 検知ルールの改善
まで、一連の流れを追ってみます。
1．観測先はまだ増やさない
今回、まず決めたことがあります。
観測先を一気に増やさないことです。
インターネットを外側から観測するサービスはいくつも存在します。将来的には複数の観測先から情報を取得し、それぞれの結果を突き合わせたいと考えています。
しかし、観測先を増やせば当然ながら取得するデータ量も増えます。
それによって…
取得処理、正規化、データベースへの保存、重複排除、差分比較、スコアリング、ASNによる分類、TLS証明書による相関分析、レポート生成――
システムのさまざまな部分へ負荷がかかります。
そこで当面は、システム障害を起こさないことを優先し、動作を確認しながら観測先を段階的に増やしていくことにしました。
今回利用した情報源も前回と同じ1か所です。
変えたのは検索クエリです。
ところが、その変更だけで観測資産数は294件まで増えました。
ここで一つ面白いことが分かります。
OSINT（オシント／Open Source Intelligence＝公開情報を利用した情報収集・分析）では、「どこを見るか」だけでなく、「何を問いかけるか」によって見える世界が変わるということです。
検索エンジンでも同じでしょう。
Googleを変えなくても検索語を変えれば、出てくる情報はまったく違います。
インターネット観測も、それに似ています。
2．今回観測した294件をどう処理するのか
294件のデータを人間が最初から1件ずつ調査するのは効率的ではありません。
そこでネット探検EYEでは、取得した公開資産に一定のルールを適用してスコアリングします。
“スコアリング（scoring）”とは、観測された特徴に応じて点数を付け、調査の優先順位を決める処理です。
ここで非常に重要なのは、スコア＝危険度ではないということです。
例えば120点だから「危険なサーバー」、40点だから「少し危険」という意味ではありません。
「人間が確認するなら、こちらを先に見た方がよい」という調査優先度です。
今回の294件のうち、173件が要調査キューへ送られました。
“キュー（queue）”とは、処理を待っている項目を順番に並べておく仕組みです。
つまりネット探検EYEは…
294件を取得
↓
特徴を機械的に評価
↓
173件を要調査キューへ
↓
その中から優先度の高いものを人間が調べる
という流れで動きます。
そして今回、その最上位に3件が並びました。
3．香港で3件が同時にTier1へ
3件はいずれも香港で観測されたホストでした。
公開記事では個別の公開サービス（ノード）を容易に特定できないよう、IPアドレスを次のようにマスキングします。
183.179.XXX.XXX:4444
183.179.XXX.XXX:4444
183.178.XXX.XXX:4444
3件ともAS9269に属していました。
ここで出てくるのが、ASN（エーエスエヌ／Autonomous System Number＝自律システム番号）です。
インターネットは、巨大な一つのネットワークではありません。
ISP（アイエスピー／Internet Service Provider＝インターネット接続事業者）、通信事業者、クラウド事業者、大学、企業などが運用する多数のネットワークが相互接続されてできています。
そのネットワークのまとまりであるAS（Autonomous System＝自律システム）を識別する番号がASNです。
したがって、「同じASNに複数の似た公開サービス（ノード）が集中している」という情報は、相関分析の一つの手掛かりになります。
ただし、同じASNに存在するというだけで、それらが同一人物や同一組織によって運用されているとは限りません。
同じホスティング事業者を利用しているだけかもしれないからです。
この区別は重要です。
4．なぜ3件が120点になったのか
今回の3件には、二つの検出条件が同時に発火していました。
一つ目が、cert_shared_multi_ipです。
簡単に言えば、同一TLS証明書が複数のIPアドレスで共有されていることを検出するルールです。
これが80点。
もう一つが、cluster_densityです。
こちらは、同一ASN上に同一ポートを使用するノードが一定数集中している状態を検出するルールです。
今回、AS9269では4444番ポートを使用する公開サービス（ノード）が8台観測されました。
これが40点。
したがって…
TLS証明書共有 80点
＋
同一ASN・同一ポート集中 40点
＝
120点
となり、3件がそろってTier1／即調査へ上がりました。
ここで機械による選別は終了です。
ここから先は、人間が調べます。
5．TLS証明書とは何か
少し技術的な話に入ります。
“TLS（ティーエルエス／Transport Layer Security）”は、インターネット上の通信を暗号化するための仕組みです。
WebブラウザでHTTPS通信を行う際などに使われています。
その際に登場するのが、TLS Certificate（ティーエルエス・サーティフィケート／TLS証明書）です。
証明書には、公開鍵をはじめ、Subject（サブジェクト＝証明書の主体）、Issuer（イシュアー＝発行者）、有効期間などの情報が含まれます。
OSINTでは、この証明書が別の意味を持つことがあります。
それが、インフラ同士を結び付けるピボット（pivot＝調査の足掛かり）としての利用です。
例えば、地理的に離れた複数のIPアドレスがまったく同じ証明書を提示していたとします。
偶然かもしれません。
同じ製品を使っているだけかもしれません。
同一事業者が大量展開した機器かもしれません。
しかし場合によっては、同じ攻撃者が構築した複数のC2サーバーが同一証明書を使い回している可能性もあります。
そこで証明書を、SHA-256（シャー・ツー・フィフティシックス）などのハッシュ関数で計算し、その値を証明書の“フィンガープリント（fingerprint＝指紋）”として比較する方法があります。
今回も、この証明書相関が発火しました。
ただし、実際のSHA-256フィンガープリントは本記事には掲載しません。
公開情報を組み合わせることで個別ノードへ容易にピボットできる可能性があるためです。
※“ピボット（Pivot）”とは、IPアドレスやドメイン、TLS証明書など、一つの情報を足掛かりに関連情報を次々とたどっていく調査手法です。
6．そして「4444番」
もう一つ目を引いたのが、TCP/4444です。
ポート（port）は、一台のコンピューターが複数の通信サービスを使い分けるための「通信の出入口」のようなものです。
例えばWebでは80/TCPや443/TCP、SSHでは22/TCPなどがよく知られています。
4444番でセキュリティ関係者が思い浮かべるものの一つが、
Metasploit（メタスプロイト）です。
Metasploitは、脆弱性検証やペネトレーションテスト（penetration test＝侵入試験）などで利用される正規のセキュリティフレームワークです。
一方で、その機能が攻撃者に悪用されることもあります。
Metasploitでは4444番が既定のリスナーポートとして知られています。
それでも、だからといって、TCP/4444が開いている → Metasploit → 攻撃者とは判断できません。
そんな単純な判定をすれば、大量の誤検知を生みます。今回重要だったのは、4444番だけではなかったことです。
- 同一ASN。
- 同一ポートの集中。
- そして同一TLS証明書を3つのIPが共有。
複数の特徴が重なったため、「人間が調べる価値がある」とシステムが判断したわけです。
7．「C2かもしれない」――そこで止めない
ここで、「香港で怪しいC2サーバーを3台発見！」と書けば、刺激的な記事にはなるでしょう。
しかし、それではOSINTではなくなってしまいます。
C2（シーツー／Command and Control＝指令・制御）サーバーとは、マルウェアや侵害された端末などへ攻撃者が命令を送り、情報を受け取るための指令統制インフラです。
今回の3件についても、観測段階ではC2である可能性を排除できません。
しかし、「可能性がある」ことと「確認した」ことは別です。
そこで3件を個別に調べました。
- TLS証明書の内容を確認します。
- 公開されているサービスの特徴を確認します。
- 3ノードの共通性を確認します。
- そして、なぜ同じ証明書が共有されているのかを追います。
そこで見えてきたのが、pfSense（ピーエフセンス）でした。
8．正体はpfSenseだった
そこで、3つの公開サービスが共有していたTLS証明書を詳しく調べました。
すると、その証明書は“pfSense（ピーエフセンス）”に由来するものであることが分かりました。
pfSenseは、企業や組織などでも利用されているファイアウォール／ルーター系のソフトウェアです。
そしてpfSenseでは、管理画面（GUI）で暗号化通信を行うために、導入時に“自己署名証明書（Self-Signed Certificate）”を生成して利用することがあります。
自己署名証明書とは、認証局（CA）から発行された証明書ではなく、機器やソフトウェア側で自ら生成した証明書です。
今回3つの公開サービスで観測された共通のTLS証明書を調べたところ、これがpfSenseの初期設定に由来する自己署名証明書であることが確認できました。
つまり…
「3つが同じTLS証明書を使っている」
↓
「同じ攻撃インフラなのでは？」
↓
詳しく調査
↓
「pfSense由来の証明書だった」
…ということです。
ここで、最初の見立てが大きく変わりました。
さらに4444/TCPについても確認したところ、今回観測されたものはC2（Command and Control＝攻撃者が侵害した端末などを遠隔操作するための指令・制御基盤）の待受ポートではなく、pfSenseの管理インターフェースとして公開されていたものと判断されました。
つまり今回、Tier1へ上がってきた3件については、C2としての疑いを裏付ける結果は得られませんでした。
以上から、この3件を“False Positive（フォールス・ポジティブ／誤検知）”として整理しました。
9．False Positive――「誤検知」は失敗なのか
False Positive（フォールスポジティブ／偽陽性・誤検知）とは、本来問題ではないものを検知システムが「確認対象」として拾ってしまうことです。
反対に、本当に検出すべきものを見逃すことを、False Negative（フォールスネガティブ／偽陰性・見逃し）と呼びます。
セキュリティ監視では、この二つのバランスが非常に重要です。
誤検知をゼロにしようとして条件を厳しくし過ぎれば、本物の脅威を見逃す可能性が高くなります。反対に、何でも拾うようにすれば大量のアラートが発生し、人間が処理できなくなります。
わゆる、Alert Fatigue（アラート・ファティーグ／アラート疲労）につながります。
今回の3件はFPでした。
しかし私は、このFPはかなり有益だったと考えています。
なぜなら、機械が何を根拠に疑い、人間が何を根拠に否定したのかが明確だからです。
10．機械は、ある意味では正しかった
今回の自動判定を振り返ると、「間違ったから120点になった」わけではありません。
実際に、同一TLS証明書を3IPが共有していました。
実際に、AS9269上に4444番ポートを使用する8つの公開サービス（ノード】が集中していました。
つまり、観測された特徴そのものは事実です。
機械が間違えたのは事実の観測ではなく、その特徴が「人間による優先調査を必要とするものか」という評価の部分です。
そして、その評価を修正するのが今回の人手調査です。
ここは、ネット探検EYEの仕組みを作っていくうえで非常に重要だと思っています。
機械に最終判断を任せない。
しかし、人間が294件を全部読むこともしない。
機械に絞らせ、人間が確かめる。
その結果を、再び機械側へ戻します。
11．今回のFPをシステムへ返す
そこで登場するのが、suppress（サプレス）です。
セキュリティ監視では、既知の正常パターンや調査不要と判断した条件について、以後のアラートやスコアリングから除外する仕組みを設けることがあります。
今回の調査によって、pfSenseの初期自己署名証明書が、複数の正常ホストで共通して観測されるノイズ源になり得ることが分かりました。
ならば、この特徴をそのまま80点として扱い続ける必要はありません。
既知のpfSense初期証明書をsuppress対象として扱えば、次回以降、同じ理由によるFPを減らせます。
すると、同じ「証明書共有」でも、既知の正常パターンでは説明できない証明書共有が相対的に目立つようになります。
これが大事です。
今回の処理を流れにすると…
Collection（収集）
↓
Normalization（正規化）
↓
Correlation（相関分析）
↓
Scoring（スコアリング）
↓
Triage（トリアージ／優先順位付け）
↓
Human Analysis（人手分析）
↓
FP判定
↓
Suppression Rule（除外ルール）へ反映
↓
次回観測
…となります。
ネット探検EYEは、単に検索結果を並べるシステムではなく、この循環を作ろうとしています。
12．それでも、この3件は記録から消さない
ここでもう一つ重要な判断があります。
FPだからといって、今回の3件をデータベースから消してしまうわけではありません。
C2ではなかった。
しかし、香港のAS9269上で、同一テンプレートから複製されたとみられるpfSense群が観測されたという事実そのものは残ります。
これは将来、意味を持つかもしれません。
- 次回も存在するのか。
- 台数が増えるのか。
- 減るのか。
- 証明書が変わるのか。
- 公開ポートが変化するのか。
- 別のASNでも同じ特徴が現れるのか。
一回だけ見れば「よくあるネットワーク機器群」で終わる情報でも、半年、1年と蓄積すれば変化が見える可能性があります。
ここが定点観測の意味です。
13．今回の世界分布にも興味深いクラスタがある
今回の報告書では、観測したIPアドレスを世界地図上へプロットしています。
灰色が観測IP、赤が要調査IP。
さらに、同一TLS証明書で相関したノードが存在する場合には、それらを線で結ぶことができます。
つまり単なる「世界のどこにサーバーがあるか」という地図ではありません。
地理情報とインフラ相関を同時に見るための地図です。
今回の観測では、香港の3件だけでなく、同一ASN上に同一ポートが集中する複数のクラスタも観測されています。
例えば報告書には、ブラジルのAS54252で4444番ポートを使用する18台のクラスタも記録されています。
ただし、これらは香港の3件と同じ意味ではありません。
香港の3件には、同一ASN × 同一ポート集中に加えて、同一TLS証明書という別の相関軸が存在しました。
だからこそ120点になったのです。
このように、一つの特徴だけを見るのではなく…
- IP
- Port
- Protocol
- ASN
- TLS Certificate
- Geolocation
- 時間的変化
…といった複数の属性を重ね合わせることで、単独では見えなかった関係を探します。
14．IPアドレスだけを追うと見失うことがある
ここは今後の観測でも重要になる部分です。
インフラを追跡するとき、IPアドレスだけを識別子にしてしまうと限界があります。
IPは変わるからです。
クラウドやVPS（ブイピーエス／Virtual Private Server＝仮想専用サーバー）では、インスタンスを作り直したり、プロバイダーを変更したりすればIPアドレスが変わることがあります。
しかし、TLS証明書、ドメイン、ASN、サービスの特徴、HTTPレスポンス、バナー、使用ポートなど、別の属性が残る場合があります。
そこで一つの観測対象から別の観測対象へ調査を広げる、Pivoting（ピボッティング）という考え方が重要になります。
今回なら…
IP
↓
4444/TCP
↓
ASN
↓
同一ASN内の4444クラスタ
↓
TLS証明書
↓
同一証明書を共有する別IP
↓
証明書のSubject
↓
pfSense
…というように調査を進めることができます。
もっとも、公開記事でこのピボットを完全に再現できる情報を出してしまえば、読者も個別ノードへ到達できてしまいます。
そのため本記事では、IPアドレスの一部をXXXで伏せ、TLS証明書のSHA-256フィンガープリントなども掲載していません。
調査できることと、公開すべきことは別です。
これは今後もネット探検EYEの公開原則にしたいと思います。
15．NEW 196件、GONE 1件、MODIFIED 0件
今回の観測では、前回との比較結果も記録されています。
NEW：196件
GONE：1件
MODIFIED：0件
ここで用語を整理しておきます。
NEW（ニュー）
前回には存在せず、今回新たに観測されたもの。
GONE（ゴーン）
前回は観測されたものの、今回は確認できなかったもの。
MODIFIED（モディファイド）
同じ観測対象について、前回から属性の変化が確認されたもの。
ただし、ここにも注意が必要です。
NEW＝新しくインターネットに出現したとは限りません。
今回はこちら側の検索クエリを広げています。
したがって、以前から存在していたものが今回初めて検索条件に入った可能性があります。
同様にGONEも、「サーバーが消滅した」と即断することはできません。
観測条件、応答状態、情報源側の収集状況などによって見えなくなる場合があります。
だから、一回の差分だけではなく、継続して観測する必要があります。
16．「観測した」と「危険だ」はまったく違う
今回の記事で最も強調しておきたいのはここです。
ネット探検EYEが294件を観測したからといって、「294台の危険なサーバーを発見した」という意味ではありません。
173件が要調査になったからといって、「173台が攻撃インフラだった」という意味でもありません。
そしてTier1になった3件ですら、詳しく調べた結果はFP（False Positive（フォールス・ポジティブ／誤検知）でした。
むしろ今回の結果は、自動検出結果を、そのまま脅威情報として扱ってはいけないことを実際のデータで示しています。
OSINTでもサイバー脅威インテリジェンスでも、検索結果やスコアは「答え」ではありません。
そこから、なぜ？と調べるための入口です。
17．だから観測先は少しずつ増やす
今回、検索クエリを少し広げただけでも294件まで増えました。
これで、観測先そのものを一気に何か所も追加すればどうなるでしょう。
単純に件数が増えるだけではありません。
同一ノードの重複、情報源による表記差、異なるタイムスタンプ、ASN情報の差異、TLS情報の取得差、GeoIP（ジオアイピー／IPアドレスから推定した地理情報）の差などを整理しなければならなくなります。
さらに複数ソースで同じ公開サービスが観測された場合、「別々の2件」なのか「同じ1件を二方向から見ている」のかを正規化する必要があります。
ここを雑に作ると、データ量だけが増えて観測精度が落ちます。
そのため、ネット探検EYEでは観測先を一気に増やしません。
一つ追加する。
- 動かす。
- 負荷を見る。
- データを見る。
- 重複を見る。
- 相関を見る。
- 問題がなければ、次を追加する。
この方法で徐々に観測域を広げていく予定です。
18．今回見つけたのは「C2」ではなく、観測システムの改善点だった
第2回の観測結果を振り返ってみます。
検索条件を広げると、294件が見えました。
173件が要調査になりました。
その最上位に、香港の3件が120点で浮上しました。
- 4444番ポート。
- 同一ASN。
- 同一TLS証明書。
一見すると、調べる価値のある特徴がそろっていました。
そこで実際に調べました。
結果は…
- C2非該当。
- pfSenseの複製クラスタ。
- False Positive。
…でした。
しかし、その結果から新しいことが分かりました。
pfSenseの初期自己署名証明書が、TLS証明書共有を利用した検出ロジックにおけるノイズになり得る。
ならばsuppressへ反映する。
次回は同じノイズが減る。
すると、その向こう側にあった別の特徴が見えやすくなる。
これこそ今回の収穫だったと思います。
おわりに――見つけることより、確かめること
インターネットを観測していると、「怪しく見えるもの」はいくらでも出てきます。
- ポート4444。
- 共有されたTLS証明書。
- 同一ASNへの集中。
- 120点。
- Tier1。
単語だけ並べれば、いかにも攻撃インフラのように見えます。
しかし調べてみたら違いました。
だから面白いのだと思います。
最初から答えが分かっているものを探しているわけではありません。
- 見つける。
- つながりを探す。
- 仮説を立てる。
- 調べる。
- 違っていれば違ったと記録する。
- そして、その結果を次の観測へ渡す。
ネット探検EYEでは、この作業を積み重ねていきます。
次回、この294件のうち何が残っているでしょうか。
今回のクラスタはそのまま存在するでしょうか。
別のTLS証明書共有が現れるでしょうか。
そして観測先を一つ増やしたとき、今まで見えなかった何が見えてくるでしょうか。
まだ分かりません。
だから、観測を続けます。
みつける。追跡する。より安全な未来へ。
調査資料について
今回の調査では、IPアドレス、ポート、ASN、TLS証明書、証明書フィンガープリントなど、個別ノードの特定や相関分析につながる情報を取得しています。
これらの中には、公開情報としてインターネットから取得できるものもあります。
しかし、
「公開されている情報」＝「そのまま再公開してよい情報」
とは考えていません。
本記事では、IPアドレスの一部を「XXX」でマスキングし、TLS証明書のSHA-256フィンガープリントなど、個別ノードを容易に特定したり、別のノードへピボットしたりできる情報については掲載を控えています。
詳細な観測データは内部調査資料として保持します。
読者向けには、ノードを特定できる情報を一部マスキングした公開用の報告書を貼付します。
コメント