技術 約9分で読めます

Adobe Creative Cloudがhostsファイルを勝手に書き換えている

Adobe Windows セキュリティ

Redditのr/sysadminで、Adobe Creative CloudがWindowsのhostsファイルを無断で書き換えているという報告が上がった。投稿者は正規ライセンスユーザーで、違法ソフトウェアの使用歴もない。複数のユーザーが同じ現象を確認しており、ファイルの更新日時から3月18日頃には変更が始まっていたようだ。

hostsに何が書き込まれるか

hostsファイルに以下のエントリが追加される。

## Adobe Creative Cloud WAM - Start ##
166.117.29.222 detect-ccd.creativecloud.adobe.com
## Adobe Creative Cloud WAM - End ##

WAMはWeb Account Managerの略で、Creative Cloudのローカルコンポーネントの一つ。detect-ccd.creativecloud.adobe.com をIP 166.117.29.222 に固定している。

hostsファイルはOSの名前解決で最優先される設定ファイルだ。通常はDNSサーバーに問い合わせてドメイン名からIPアドレスを引くが、hostsに記載があればDNSを飛ばしてそのIPに接続する。テスト環境の構築やアクセス制御でシステム管理者が使うもので、アプリケーションが黙って書き換えていいファイルではない。

ブラウザからCC検出を行う仕組み

RedditユーザーのthenickdudeがAdobeサイトのJavaScriptを解析し、この仕組みの全容を突き止めた。

ユーザーがadobe.comにアクセスすると、ページ内のJavaScriptが以下のURLをfetchする。

https://detect-ccd.creativecloud.adobe.com/cc.png

hostsエントリがある環境では、このドメインがAdobe管理のIP（166.117.29.222）に解決されてfetchが成功する。エントリがなければ名前解決に失敗し、fetchも失敗する。成否でCreative Cloudのインストール状態を判定している。

graph TD
    A["adobe.comにアクセス"] --> B["JSがcc.pngをfetch"]
    B --> C{"hostsエントリ"}
    C -->|あり| D["166.117.29.222に接続<br/>cc.png取得成功"]
    C -->|なし| E["名前解決失敗"]
    D --> F["CC インストール済み"]
    E --> G["CC 未インストール"]
    F --> H["ダウンロードUIの出し分け<br/>Web→Desktop連携"]
    G --> H

検出コード

thenickdudeがデミニファイしたコードが以下。

{
    key: "detectCCDForLNARestrictedBrowsers",
    value: function detectCCDForLNARestrictedBrowsers(options) {
        const wamImageUrl = options?.wamImageUrl?.trim();
        const baseUrl = (wamImageUrl && wamImageUrl.length > 0)
            ? wamImageUrl
            : "https://detect-ccd.creativecloud.adobe.com/cc.png";

        // キャッシュバスティング: タイムスタンプをクエリに付加
        const url = baseUrl.includes("?")
            ? `${baseUrl}&q=${Date.now()}`
            : `${baseUrl}?q=${Date.now()}`;

        return new Promise((resolve) => {
            let timeoutId;
            let settled = false;

            const finish = (result) => {
                if (settled) return;
                settled = true;
                if (timeoutId) {
                    clearTimeout(timeoutId);
                    timeoutId = undefined;
                }
                resolve(result);
            };

            // 10秒でタイムアウト → 未インストール扱い
            timeoutId = setTimeout(() => finish(false), 10000);

            fetch(url, {
                method: "GET",
                headers: { "x-adobe-client": "wam-client" }
            })
                .then((response) => finish(response.ok))
                .catch(() => finish(false));
        });
    }
}

Date.now() でブラウザキャッシュを無効化し、x-adobe-client: wam-client ヘッダー付きでGETリクエストを送る。10秒以内に 200 OK が返ればインストール済み、タイムアウトか失敗なら未インストール。

メソッド名の LNARestrictedBrowsers はLocal Network Access制限のあるブラウザ向けの検出手段であることを示唆している。ブラウザ拡張やカスタムURLスキームが使える環境ではそちらが優先され、使えない場合のフォールバックとしてhosts経由の検出が動く構造だろう。

なぜhostsなのか

ブラウザからローカルアプリの存在を検出する手段は限られている。

手段問題点
カスタムURLスキームブラウザがダイアログを出す。UXが悪い
localhost通信HTTPSページからHTTPへの通信がmixed contentでブロックされる
ブラウザ拡張全ブラウザ対応が必要。導入コストが高い
hostsファイル + 固定IPDNS非依存。ブラウザの制約を回避できる

hostsを使えばDNS設定の差異やキャッシュの問題を回避でき、mixed contentの制約にも引っかからない。技術的には合理的だが、これはブラウザのセキュリティ制約を迂回するための裏技であって正攻法ではない。

問題点

OSレベル設定への無断介入

hostsはOS層の名前解決設定だ。アプリケーション層が直接書き換えるのは設計上のレイヤ違反で、通常はインストーラで明示するか設定画面でオプトインさせる。Creative Cloudはどちらもやっていない。

削除しても戻る

複数のユーザーがエントリを消した後に再追加されたと報告している。Creative Cloud Desktopの起動時に書き戻していると見られ、一度入れたら勝手に消せない系の挙動になっている。

ローカルサーバーの起動

ある報告ではIIS（Internet Information Services）がポート80で起動しているとされている。Creative Cloud DesktopはElectronベースで内部にNode.jsプロセスを持っており、ローカルのWebサーバーを立てること自体はAdobe製品では珍しくない。だがユーザーが認識していないサービスがポートを開けているのは、ポートスキャンの対象にもなり得る。

公式ドキュメントに記載がない

Adobeのサポートページではむしろ「hostsファイルのAdobe関連エントリはすべて削除してください」と案内している。これは海賊版ユーザーがAdobeサーバーへの通信をhostsでブロックするのを解除させるための記述で、自社のWAMが書き込んでいるエントリについては一切触れていない。

セキュリティ監視のノイズ

企業環境では、hostsの変更はセキュリティインシデントの指標になる。マルウェアがhostsを改変してフィッシングサイトにリダイレクトするのは古典的な攻撃手法で、EDR（端末の挙動を監視して脅威を検知するセキュリティ製品）やSIEM（セキュリティログの統合監視基盤）がhosts変更でアラートを出す運用は多い。Adobeの正規挙動がノイズになる。

McAfeeはもっとタチが悪い

Adobeのhosts改変は行儀が悪いが、「OSの主導権を奪う大手ソフト」というくくりで見ると、もっと攻めた挙動をしているものがある。

McAfeeは開発環境との相性が最悪だ。Node.jsがlocalhostでポートを開く、node_modulesの数万ファイルを読む、ビルドで大量にファイルを書く。全部マルウェアに似た振る舞いとして検知される。

重くなるだけならトレードオフとして許容できる。McAfeeはその先に行く。dev serverが立ち上がらない、ビルドが途中で止まる、localhost接続が切られる。実際にAstroの開発サーバーがMcAfeeに止められて、削除したら何事もなかったかのように動いた。

当時使っていたMcAfee LiveSafeでは、除外設定がファイル単位しかなかった記憶がある。node_modulesの中身を1ファイルずつ除外リストに入れろということだが、数万ファイルに対してそれは無理だ。製品やバージョンによってはディレクトリ単位やプロセス単位の除外ができるのかもしれないが、少なくとも当時の環境ではそんな選択肢は見当たらなかった。

McAfeeが開発を壊すメカニズム

McAfeeがNode.js環境で問題を起こす構造を図にするとこうなる。

graph TD
    A["Node.jsプロセス起動"] --> B["node_modules読み込み<br/>数千〜数万ファイル"]
    A --> C["dev server起動<br/>localhost:4321"]
    A --> D["ビルド実行<br/>大量ファイル生成"]
    
    B --> E["ファイルI/Oフック<br/>全ファイルをリアルタイムスキャン"]
    C --> F["通信監視<br/>localhostポートを不審と判定"]
    D --> G["振る舞い検知<br/>大量書き込みをマルウェアと誤認"]
    
    E --> H["タイムアウト<br/>起動失敗"]
    F --> H
    G --> H

    style E fill:#f96,stroke:#333
    style F fill:#f96,stroke:#333
    style G fill:#f96,stroke:#333

セキュリティソフトの仕事はファイルや通信を監視することなので、検知自体は正しい。問題は誤検知したら即ブロックすることと、除外の粒度が開発用途に堪えないこと。

サードパーティAVはまだ必要か

2026年時点で、Windows DefenderはAV-TESTやAV-Comparativesでトップ層のスコアを出している。OS統合のおかげでフックが最小限で済み、開発環境への副作用も小さい。SmartScreen、Exploit Guard、ランサムウェア対策まで標準搭載されていて、単なるウイルス対策を超えた多層防御になっている。

サードパーティAVを追加する合理性があるのは、EDR統合やSIEM連携が必須の企業環境、あるいはマルウェア検体を日常的に扱うセキュリティリサーチくらいだ。一般的な開発環境では、余計なAVは「セキュリティ強化」ではなく「ノイズ増加」になる。

とか言いつつ、家族のスマホにはウイルスバスターを入れている。特にAndroid版はSMS、メール、ブラウザ、起動アプリを個別に監視できるので、ITリテラシーが高くない家族の端末にはちょうどいい。こないだパッケージ版でアカウント更新したら詐欺バスターもついてきたので、ついでにそれも入れた。自分のPCでは無効化しているし、自分のスマホにも入れていない。PCのウイルススキャン機能はマジで使ったことがない。公式のマイページもやれることが少なくて微妙だが、家族の端末管理は自分の環境とは別の問題なので、この辺はトレードオフと割り切っている。

行儀の悪い大手ソフトたち

Avastがまだ生きていたことに驚いた。NortonLifeLock（現Gen Digital）に2022年に買収されており、かつての「軽い無料AV」とは別物になっている。有料誘導の通知が増え、2020年にはユーザーのブラウザ履歴を収集して企業向けに販売していたJumpshot問題も発覚している。Norton本体も同傾向で、PCプリインストールと自動更新の組み合わせで「入れた覚えがないのに入っている」状態を作る。Gen Digitalの傘下にNortonもAvastもいて、McAfeeも別の投資会社に売却されて似たような立ち位置にいるので、結局またお前かという感じだ。

ロシア製のKaspersky（カスペルスキー）も昔は定番だったが、2024年にアメリカで販売禁止になり、既存ユーザーは自動的にUltraAVという別製品に移行された。ロシア政府との関係が疑われたのが理由で、日本では販売継続しているものの、以前ほど名前を聞かなくなった。

Adobe、McAfee、Norton/Avast以外にも、ユーザーの環境に黙って手を入れる大手はいる。

ソフトウェアやっていること
Adobe CChostsファイルの無断書き換え。解約時に値下げ提案
McAfee / Norton開発ツールのブロック。削除しても残骸。PCプリインストール
Avast過剰通知。ブラウザ履歴の企業向け販売（Jumpshot、終了済み）
Oracle (Java)ライセンス体系の複雑化。過去のツールバーバンドル
MicrosoftEdge / OneDriveの既定ブラウザ・既定保存先への押し込み

共通しているのは、ユーザーの環境をユーザーが知らないところで変更する点だ。重くなるのは我慢できても、設定を勝手に変えられるのは話が違う。Adobeは仕事で使うからまだ妥協点はあるが、hostsを黙って書き換えるのはその妥協を相当に削っている。

対処

個人環境

hostsエントリは削除して問題ない。副作用はadobe.comでのCC検出が効かなくなるだけで、アプリの動作には影響しない。Creative Cloud Desktopが再追加する可能性があるため、根本的に止めるならhostsファイルのACL（ファイルのアクセス権設定）で書き込みを制限する。

企業環境

hosts変更をセキュリティ監視に組み込んでいる場合は対応が必要になる。Adobeのエントリをホワイトリストに入れるか、ACLでhostsへの書き込みを制限する。Creative Cloud関連のバックグラウンドプロセスの挙動も把握しておいたほうがいい。

プロセス名役割
Creative Cloud DesktopメインのUI。Electronベース
CCXProcess拡張機能の管理
Adobe Desktop Serviceライセンス認証・アップデート管理
CoreSyncファイル同期

hostsを書き換えたい気持ちは正直わかる。
投票システムやユーザー認証系のサービスを作っていると、不正アクセスを弾くためにブラウザ側で取れる情報の少なさに絶望する。
hostsで固定IPに向けて検出する手法は、制約の中での現実解として理解できる。
でも、ユーザーの預かり知らぬところでシステムの深いところをいじられるのは普通にムカつく。
解約ボタンを押したら値下げを提案してくるし、Adobeはユーザーとの信頼関係の築き方が根本的にずれている。