Trend Microがこのブログを「Disease Vector」と誤判定 — URLを特定して再分類したら解決した

はじめに

普段からTrend Microを使っているのですが、あるとき自分のブログが検索結果でグレー 表示になっているのに気づきました。いつもの安全バッジではなく、そっけない「？」 マークが付いていたのです。

緑のチェックマークが欲しかったので、Trend MicroのSite Safety Centerにドメインの再分類を申請しました。ところが返ってきた 結果は、以前よりも悪くなっていました。評価は「Dangerous」、コンテンツタイプは 「Disease Vector」です。

本記事では、その後に行った調査と、評価を最終的に「Safe」に変えた一つの変更について解説 します。

テスト結果：91ベンダー中0件が悪意ありと判定

何よりもまず、サイトが本当に侵害されているのかを確かめたいと思いました。そこで https://oharu121.com/を、一度のチェックで91のセキュリティベンダーに照会して くれるVirusTotalにかけてみました。結果は全ベンダーがクリーンで、フラグを立てたものは 91件中0件でした。

これで一つの疑問は解消しましたが、代わりにもっと厄介な疑問が残りました。なぜ Trend Microだけが、他と違う判定をしているのか。

Google、Trellix、McAfee、Microsoftそれぞれで確認する

VirusTotalの91ベンダーは、いずれもマルウェアスキャンエンジンです。検索結果にバッジを 表示するレピュテーションとカテゴリのデータベース（Trend MicroのSite Safety Centerもその 一つです）とは、そもそも系統が違います。こちらは別々の基盤の上で、それぞれ独自の審査 プロセスで動いているので、一つずつ確認していくことにしました。

Google Safe Browsing

Google Safe Browsingは、Chrome・Firefox・Safariで表示される警告ページを管理しており、 実際の訪問者にとって最も影響が大きいサービスです。Search Consoleのセキュリティの問題 レポートと、一般公開されているTransparency Reportの見解は一致していました。問題は検出されず、 安全でないコンテンツも見つかりませんでした。

TrellixとMcAfee、分裂した2つのデータベース

McAfeeのWebレピュテーションデータベースは、かつては一つのものでした。2024年に法人向け部門が Trellixとして独立し、コンシューマー向けのMcAfeeブランドとデータを共有しなくなりました。 そのため、片方を確認しても、もう片方の判定はわからなくなっています。

TrellixのTrustedSourceでは、ドメインは「Uncategorized URL」、リスクは「Medium Risk」と 判定されていました。分裂後は別データベースとなったMcAfee独自のSite Lookupでは、 「Uncategorized」、信頼度は「Unverified」でした。どちらも危険とは判定していません。というより、 このドメインに関するデータをそもそも持っていませんでした。

Microsoft SmartScreen：能動的な申請手段がない

Microsoftのファイル送信ポータルは、一見すると正しい窓口に見えます。ただし wdsi/filesubmissionは実行ファイルのマルウェア解析用で、URLは受け付けません。普通に 検索すると真っ先に出てくるページなので、この遠回りもあえて書いておきます。

サイト報告フォームは、ユーザーがすでに見た警告に対する異議申し立ての仕組みであり、 未検出のサイトを安全だとMicrosoftに認めてもらう申請手段はありませんでした。

SmartScreen自体のレピュテーションは、ドメインの登録年数や証明書の有効性、クロール履歴 といった要素から受動的に構築される仕組みです。そのため、異議を申し立てる対象も、申請 する窓口も存在しませんでした。

自動スキャナーから見たService Workerの姿

他のどのチェックも、なぜTrend Microだけがこのサイトにフラグを立てたのかを説明してくれ ませんでした。そこで次に調べたのが、オフライン閲覧機能の裏側にあるコード、つまり Service Workerとその登録スクリプトです。

fetchハンドラーは、他の処理を行う前に、まず同一オリジンのリクエストだけに絞り込みます。

if (url.origin !== self.location.origin) return;

このコードには、サードパーティサーバーへの通信も、スクリプトの注入も、evalの実行も 一切ありません。サイト自身のページとアセットをキャッシュするだけです。ただし登録 スクリプトは、永続ストレージも要求しています。7日間アクセスがないとストレージを削除する Safariの仕様から、オフラインキャッシュを守るためです。

if (!storage?.persist) return;
if (await storage.persisted?.()) return;
storage.persist().catch(() => {});

Service Workerを登録し、永続ストレージを要求し、インストールを促す。このコードだけを 見れば、オフライン閲覧用に記事をキャッシュするPWAなのか、タブを閉じても生き残ろうと する詐欺ページなのか、区別がつきません。

sw.jsそのものを名指ししたブロック

その数週間後、この仮説は直接的な形で裏付けられました。自分のマシンにインストールして いたTrend Micro製品が、実際にページ遷移をブロックしたのです。ブロックログには、対象の リソースが明確に記録されていました。

これまでの検査でドメイン全体ではなく特定のファイルが名指しされたのは、これが初めて でした。最初の再分類申請はルートドメインに対するものだったので、Trend Microの データベースにあるこのファイル自体のエントリは、手つかずのままだったわけです。

ドメインではなくファイルを再分類する

そこで2回目の再分類申請を、今度はhttps://oharu121.com/sw.jsに対して直接行いました。 コメント欄には、VirusTotalの結果と、このファイルが何をしているかの平易な説明を添え ました。

ドメインではなく、フラグが立った具体的なリソースそのものを狙ったことが、結果を変えた 決め手でした。

まとめ

PWAのService Workerに付いた誤った「不正プログラム配信」評価は、実際の感染ではなく、 パターンマッチングの問題に起因していました。Service Workerを登録し、永続ストレージを 要求し、インストールを促すという振る舞いは、オフライン閲覧が目的でも、詐欺サイトの 居座りが目的でも、スキャナーからは同じに見えてしまうのです。

他のすべてのレピュテーションサービスを横断的に確認したことで、このフラグが実際の侵害 ではなく、Trend Micro固有のものだと確認できました。そして最終的にうまくいった対処は、 最初の試みよりも的を絞ったものでした。ドメインではなく、スキャナーが名指しした具体的 なファイルを再分類すること、それが答えでした。

参考リンク

• Trend Micro Site Safety CenterでのURLまたはWebサイトの再分類
• Trend Micro製品による誤検知について
• VirusTotal