NIKKE公式PCランチャー改ざん事件を検証――K2Fマルウェアの実態、感染確認と初期化の判断

⚠ 対象者と対処方法（要点）

■ 対象者
2026年9月27日15時41分以降に、Windows版『NIKKE』公式PCランチャーを一度でも起動した人（現在アンインストールしていても対象。モバイル版のみの人は対象外）。

■ 対処方法

感染の確認：ランチャーの Launcher\intl_service\debug.log を開き、k2f_chan registered を検索する。見つかれば感染が強く疑われる（見つからなくても安全とは限らない）。
疑わしい場合はネットワークを切断し、運営の公式ガイドに従って検査・削除する。Defenderのフルスキャンとオフラインスキャンも実施する。
安全な別端末から、メール・Google／Microsoft・SNS・ゲーム等のパスワードを変更し、全セッションを失効（全端末からログアウト）させ、二要素認証を設定する。Cookieやトークンが盗まれた可能性があるため、パスワード変更だけでは不十分。感染が疑われるPCの上では新しいパスワードを入力しない。
APIキー・SSH鍵などを置いていたPCは、失効・再発行を検討する。
感染が確認されたPCは、Windowsのクリーンインストールを強く検討する。

詳細は本文の「5. 自分のPCは対象か」「6. 影響が疑われるPCで取るべき対応」を参照。

結論から言う。今回の『勝利の女神：NIKKE』のセキュリティ問題は、公式PCランチャーが信頼して読み込むスクリプトを第三者が改ざんし、利用者のPCに遠隔操作・情報窃取型マルウェアを送り込める状態にした、重大なサプライチェーン攻撃である。「怪しい非公式ツールを使ったから感染する」という話ではない。正規のゲームを普通に起動した人が危険にさらされた点が深刻だ。

ただし、SNS上には正しい注意喚起と未確認の断定が混在する。2026年11月10日時点で、運営が点検を求めているのは「9月27日15時41分以降にWindows版PCランチャーを一度でも起動した利用者」。「7月以降の全PCが感染した」「対象者全員のOS再インストールが必須」という情報は確認できない。感染の可能性と感染の確定、さらに実際の情報流出は分けて考える必要がある。

調査基準日：2026年11月10日。公式告知、独立研究者MotherSphere氏の解析、セキュリティ企業・専門媒体の検証を照合した。未確定事項はその旨を明記する。

1. 何が起きたのか――正規ランチャーが攻撃経路に

『NIKKE』のPCランチャーは、起動時にコンテンツ配信ネットワーク（CDN）からJavaScriptなどのリソースを読み込む。攻撃者は、この公式CDN上のスクリプト4件に不正なコードを仕込んだと運営は説明する。コードは外部の攻撃者管理ドメインに接続し、さらなる不正プログラムを取得・実行する仕組みだった。

ユーザーから見ると、正規サイトからインストールした正規のランチャーを起動しているだけだ。これが「サプライチェーン攻撃」の怖さである。信頼済みの配信経路が破られると、個々の利用者が一般的なダウンロード上の注意を守っていても攻撃を受け得る。

運営は、ゲーム関連で利用していたドメイン insightjs.com が第三者に乗っ取られたと説明する。ただし、ドメインの乗っ取りが具体的にどうCDNファイル4件の書き換えにつながったかは、まだ解明・公表されていない。ドメインを奪われただけで、当然に別のCDNファイルを書き換えられるわけではない。この接続部分が事件の重要な未解明点だ。

2. 時系列――運営発表と研究報告には食い違いがある

日時（日本時間）	出来事と情報の位置付け
9月27日 10:59	運営発表：`insightjs.com` が第三者に乗っ取られる。
9月27日 15:41～15:42	運営発表：ランチャーが取得する公式CDNのスクリプト4件が改ざんされる。
10月23日ごろ	研究者報告：一部端末のログ等から、この時点で遠隔操作用エージェントが実行されていた可能性。運営の確定発表ではない。
10月30日 03:52	運営発表：不正プログラムの配布が開始されたとする日時。
11月4日 00:00ごろ	運営発表：異常を認識し調査開始。
11月4日 02:04～02:23	運営発表：不正なスクリプト3件を交換し追加配布を遮断。
11月4日 12:09	運営発表：残る1件に関連するCDNキャッシュの更新を完了し、正常ファイルを順次反映。
11月5日 08:00以降	運営発表：公式PCクライアントに今回の不正プログラムの検査・削除機能を提供。

注目すべきは10月23日と10月30日の差だ。MotherSphere氏は一部利用者の記録を根拠に、運営が説明する「配布開始」より早い時期のエージェント実行を報告している。セキュリティ企業Malwarebytesも、この日時の不一致を指摘している。報告が事実なら運営側の時系列には補足・訂正が必要になるが、現時点で公開情報から最終判断はできない。

したがって、対策対象を「10月30日以降」だけに狭めるべきではない。9月27日15時41分以降を対象とする運営の注意喚起に従うのが妥当である。

3. マルウェア「K2F」は何をできるのか

運営はマルウェアの詳細をすべて公表していない。一方、MotherSphere氏は改ざんスクリプト、ダウンロードされたLuaJITベースのペイロード、ログなどを解析し、「K2F」と呼ばれる遠隔操作用エージェントを報告している。BleepingComputerも改ざん済みスクリプトの一部と関連DLLの痕跡を独自に検証した。

遠隔コマンド実行：感染端末上でプログラムやコマンドを実行できる。
ファイルの閲覧・持ち出し：ローカルファイル、スクリーンショットなどを取得できる。
認証情報の窃取：ブラウザに保存したパスワード、Cookie、ログイントークン、NIKKEの認証情報などが標的になる。
開発者・管理者向け秘密情報：SSH鍵、APIトークン、Git関連の認証情報、クラウドサービスやAI開発ツールの資格情報なども標的として列挙されている。
暗号資産：ブラウザ拡張機能のウォレット情報、秘密鍵・リカバリーフレーズなどを狙う機能が指摘されている。
持続化：WindowsのレジストリとChrome関連のDLLを利用して、ランチャー終了後にも悪意ある処理が残る仕組みが解析されている。

重要な区別がある。これらは解析されたプログラムに備わる機能・狙いであって、すべての対象PCで機能が実行されたことや、すべてのデータが実際に流出したことを意味しない。侵害台数・被害総額・外部への実際の流出規模は、少なくとも確認した公開資料では確定していない。

4. パスワードを変更するだけでは足りない理由

今回、特に危険なのがブラウザのセッションCookieや認証トークンだ。これらは、サービス側が「すでにログイン済み」と判断するために利用することがある。窃取されたセッションが有効なままだと、攻撃者がパスワードを知らなくても既存のログイン状態を悪用できる場合がある。

つまり、パスワード変更と二要素認証の有効化は重要だが、それだけですべての盗まれたセッションが無効になるとは限らない。安全な別端末からパスワードを変更し、各サービスの「すべての端末からログアウト」「セッションの取り消し」「不審な端末の削除」を併せて行うことが必要になる。APIキーやアクセストークン、SSH鍵は別途無効化・再発行を検討すべきだ。

また、感染した疑いがあるPC上で新しいパスワードを入力すると再び取得されるおそれがある。まず別の安全な端末でアカウント保護に着手するのが基本だ。

5. 自分のPCは対象か――まず確認すること

運営の説明では、2026年9月27日15時41分以降にWindows版PCランチャーを一度でも起動した人がセキュリティ確認の対象となる。現在すでにNIKKEをアンインストールしていても、その期間に使っていたなら確認対象からは外れない。iPhone／Androidのモバイル版しか使っていない人は、今回のPCランチャー問題による点検対象ではないと運営は案内している。

ログの確認

ランチャーをまだ利用している場合、インストール先の Launcher\intl_service\debug.log をテキストエディターで開き、k2f_chan registered を検索する。これが見つかれば不正エージェントが実行された疑いが強く、感染端末として対応すべきだ。ログファイルの場所はインストール先によって異なるため、「必ずCドライブ」とは限らない。

逆にこの文字列がないから安全、とは言い切れない。ログが消去済みだったり、攻撃が途中まで進んだだけだったり、別の痕跡だけが残ったりする可能性がある。k2f や agent という一般的な単語の有無だけで感染を確定するのも不正確だ。運営の手動確認ガイドが示す具体的な文字列と手順を参照したい。

調査の証拠を残したい場合

MotherSphere氏は、公式ランチャーの検査・削除機能に同意すると関連ログ・DLL・レジストリ情報が削除されるため、感染の有無や時刻を後から調べたい場合は、先にログやランチャーのキャッシュを保全するよう提案している。研究者や被害申告を考える利用者にとっては重要な注意点だ。ただし、一般利用者が未知のファイルをむやみに開いたり実行したりする必要はない。保存先の安全性と個人情報にも注意する。

感染確認用として第三者のツールが公開されているが、公式製ではない検査ツールを無条件に推奨はしない。利用する場合も公開元・ソースコード・配布経路を確認したい。SNSで回ってくる「修復コマンド」やPowerShellの一行コマンドを安易に実行するのは、二次感染の原因になり得る。

6. 影響が疑われるPCで取るべき対応

対象かどうか判断し、異常や実行痕跡があるならネットワークを切断する。ランチャーを終了し、不要な操作を控える。証拠を残したい場合は、削除処理の前にログを保全する。
運営の公式ガイドに従って検査・削除する。最新版PCランチャーのACE検査機能を使う方法と、ランチャーを起動しない手動確認方法が案内されている。公式機能を使う際はChromeなどのブラウザを完全に終了する。
信頼できる対策ソフトでフルスキャンし、Microsoft Defenderのオフラインスキャンも実施する。ただし検出ゼロは、過去の感染や情報流出がなかったことの証明ではない。
安全な別端末からアカウントを守る。メール、Google／Microsoft、SNS、ゲーム、金融などのパスワードを変更し、他のログインセッションを失効させ、可能なら二要素認証を設定する。
開発用・業務用の秘密情報を点検する。APIキー、Gitやクラウドのアクセストークン、SSH鍵などを保有していた場合は、漏えいを想定した失効・再発行と利用履歴の確認を行う。
感染が確認されたPCではWindowsのクリーンインストールを強く検討する。遠隔コマンド実行が可能だった以上、既知のDLLやレジストリ項目を消しただけで攻撃者が別途残した変更まで完全に除去できたとは証明できない。復旧する場合は必要な個人データを慎重に退避し、信頼できるインストール媒体を使う。

特に業務で使うPC、銀行・暗号資産を扱うPC、開発者のPCなどでは、再インストールを選ぶ合理性が高い。一方、「対象期間に一度起動しただけで、全員の初期化が公式に必須とされた」という事実は確認できない。一般的な点検対象と、感染が強く疑われる端末の復旧判断は分けるべきだ。

7. 話題のX投稿はどこまで正しいのか

今回の調査のきっかけになったXの投稿は、Cookieやトークンが危険であること、感染したPCではOS再インストールが安全側の選択になることを強調している。危険性の方向性は理解できるが、以下は修正が必要だ。

「2026年7月〜11月にランチャーを使った人は初期化推奨」：確認した公式発表と研究解析に、7月を開始時点とする根拠は見つからなかった。運営の点検対象開始日は9月27日15時41分である。
「ログでk2fとagentを探す」：実務上は公式が指定した k2f_chan registered などの具体的な痕跡を見る。ログがない・見つからない場合でも安全とは断定できない。
「Cookieファイルが抜かれた」：ブラウザCookieやトークンを盗める機能は確認・報告されているが、全端末で実際に窃取されたという意味ではない。
「レジストリが残るためRDP・RCEの脆弱性が非常に危険な状態」：既知の不正DLLを起動し続けるためのレジストリ登録は報告されている。しかし、これを「Windows自体にRDPの脆弱性が残る」と説明するのは不正確だ。RCEは攻撃者が命令を実行する能力を指す文脈で使われており、RDPの脆弱性が悪用されたと確認されたわけではない。

危険な攻撃であるほど、警告する側も「最悪の可能性」と「確認済みの被害」を混ぜないことが大切だ。不確かな数字や技術用語の誤用は、かえって利用者の判断を難しくする。

8. 問題の本質――CDNを信頼しすぎた設計と説明責任

今回の事件は、一般的な「ユーザーが怪しいファイルをダウンロードした」という構図ではない。正規アプリの実行時に外部から読み込むコードが、そのまま利用者の端末上で強い権限につながる構造こそ問題だ。外部依存を減らす、読み込むリソースの完全性を署名やハッシュ等で検証する、ランチャー機能の権限を最小化する、といった対策が重要になる。

運営は再発防止として、PCランチャーと関連システムの監視強化、外部リソースの完全性確認、ランチャーの権限見直しを挙げている。しかし、本当に検証したいのは今後の具体的な実装と検証結果だ。

さらに説明が求められるのは、①ドメイン乗っ取りからCDN改ざんに至った侵入経路、②実際の配布開始日が10月23日なのか10月30日なのか、③感染台数と情報流出の範囲、④感染端末の復旧・被害補償の方針である。

CDNそのものが常に危険という意味ではない。大規模配信には大きなメリットがある。ただし、配信元が正規であることと、配信されたコードが改ざんされていないことは別問題だ。今回のNIKKEは、その違いが大規模なユーザーリスクに直結した事例といえる。

まとめ

今回のNIKKE問題は、正規のランチャーを通じてマルウェアが実行され得たという点で重大なインシデントだ。対象期間にWindows版を使った人は、公式の手順で点検し、安全な別端末で認証情報を守る必要がある。感染が確認された場合のクリーンインストールは十分合理的な選択だが、「7月から全員が感染」「全員一律に初期化必須」という言い方は避けたい。

今後も、研究者の解析と公式発表の時系列の食い違い、CDNに書き込めた根本原因、被害規模が明らかになるかを注視する必要がある。

主な参照資料

注意：本記事は公開資料に基づく調査・考察であり、個々の端末の安全性を保証するものではない。状況が変わった場合は公式の最新案内を優先してほしい。