Next.js開発者を狙う「偽面接リポジトリ」攻撃の手口と対策──VS Codeの“信頼”が入口になる理由

Next.jsを使う開発者や転職活動中のエンジニアを狙い、コーディング課題や面接用プロジェクトを装ったリポジトリに誘導して、端末内の情報を盗み出す攻撃が報告されています。ポイントは「不審な実行ファイルを踏ませる」古典的手口ではなく、普段の開発ルーティン（VS Codeで開く、npm run devを叩く、バックエンドを起動する）そのものが感染トリガーになりうる点です。The Register+1

• Next.js開発者を狙う「偽面接リポジトリ」攻撃の手口と対策──VS Codeの“信頼”が入口になる理由
  • 何が起きているのか：偽の“面接課題”がマルウェアの入口に
  • 感染までの典型ルート：あなたの“いつもの操作”がトリガーになる
    • 1) VS Codeのワークスペース自動化を悪用：「信頼する」を押した瞬間に動く
    • 2) npm run dev / 開発サーバ起動を悪用：資産ファイルや改変ライブラリに仕込む
    • 3) バックエンド起動を悪用：モジュール読み込み時に“埋め込みロジック”が走る
  • 技術的に何がヤバいのか：メモリ実行＋C2で“後から何でもできる”
  • 今日からできる現実的な防御策：転職中・副業中ほど徹底したい
    • 1) “信頼”をデフォルトで押さない：VS CodeのTrustは最重要判断
    • 2) 面接課題は“隔離環境”で：ローカル直実行をやめる
    • 3) シークレット管理を見直す：端末に“置かない・残さない”
    • 4) 挙動監視：不審な通信を“気づける”ようにする
  • 採用担当・企業側も無関係ではない：課題配布の“安全設計”が信頼になる
  • まとめ：Next.jsの問題ではなく“開発ワークフロー”が攻撃面になっている

何が起きているのか：偽の“面接課題”がマルウェアの入口に

攻撃者は、もっともらしいNext.jsプロジェクトをGitHubなどに用意し、「面接課題」「技術試験」「サンプル実装」などの名目で開発者にクローンさせます。表面上は普通のリポジトリに見えるため、被害者側は疑いにくいのが厄介です。Microsoft+1

そして一度引き込まれると、最終的にJavaScriptがメモリ上で実行され、攻撃者のC2（指令サーバ）へ接続し、追加の命令を受け取る流れに繋がります。Microsoft

感染までの典型ルート：あなたの“いつもの操作”がトリガーになる

この手の攻撃が危険なのは、「怪しいexeをダブルクリック」のような分かりやすい行動を要求しないことです。報告されているルートは複数ありますが、共通しているのは開発者の日常行動に寄せている点です。Microsoft

1) VS Codeのワークスペース自動化を悪用：「信頼する」を押した瞬間に動く

VS Codeはプロジェクトを開くと「このワークスペースを信頼しますか？」と尋ねます。攻撃側はここを狙い、信頼された瞬間に自動タスクや設定経由でコードを読み込ませるように仕込みます。結果として、開発者が普段どおりにプロジェクトを開いただけで、裏で不正な処理が進む可能性があります。Microsoft

2) npm run dev / 開発サーバ起動を悪用：資産ファイルや改変ライブラリに仕込む

次に多いのが、開発サーバの起動（例：npm run dev）をトリガーにする手口です。フロント側のファイルや依存関係の一部が改変されており、起動時に不正ローダーの取得・実行へ繋げます。Microsoft

3) バックエンド起動を悪用：モジュール読み込み時に“埋め込みロジック”が走る

バックエンドを立ち上げたタイミング、あるいはモジュールのimport時に、初期化処理へ不正ロジックを潜ませるケースも確認されています。フロントだけではなく、サーバ側の起動手順に自然に混ぜられるのがポイントです。Microsoft

技術的に何がヤバいのか：メモリ実行＋C2で“後から何でもできる”

報告では、最終的に端末を登録し、JavaScriptローダーを実行してC2へ接続、そこから追加タスクを受け取ってメモリ上で実行する流れが説明されています。ディスク上の痕跡を抑えやすく、調査・検知を難しくする狙いがあります。Microsoft

さらに、開発者端末から狙われる情報は非常に広いです。個人情報だけでなく、以下が特に危険です。

• リポジトリや未公開ソースコード

• .env、APIキー、トークン、SSH鍵

• クラウド権限（AWS/GCP/Azure）やCI/CDの認証情報

• ブラウザや開発ツールが保持するセッション情報

開発者PCは“権限の塊”になりやすく、侵害されると個人被害に留まらず、所属組織のクラウドや顧客データへ波及する恐れがあります。Microsoft

今日からできる現実的な防御策：転職中・副業中ほど徹底したい

ここからは、過度に手間を増やさず「被害確率を大きく下げる」実務的な対策です。

1) “信頼”をデフォルトで押さない：VS CodeのTrustは最重要判断

• 知らない相手から渡された課題は、まず信頼しない状態で中身を確認

• .vscode/ 配下（tasks.json など）と、package.json のscriptsを最優先で目視

• 「開いたら自動で何か走る」前提で、最初は閲覧専用に近い運用にする

VS Codeの利便性機能が、攻撃者にとっては“自動実行の足場”になり得ます。Microsoft+1

2) 面接課題は“隔離環境”で：ローカル直実行をやめる

最も効果が高いのは、最初から隔離することです。

• Docker / Dev Container / 仮想マシンで実行

• 権限の弱いユーザー、ネットワーク制限、ファイル共有最小化

• 可能なら「コード閲覧 → 必要最低限だけコピペで再構築」で済ませる

「課題だから急いで動かす」が一番危険です。

3) シークレット管理を見直す：端末に“置かない・残さない”

• .env を長期間放置しない、使い回ししない

• 重要トークンは短命化（有効期限を短く）し、漏えい前提でローテーションできる体制に

• Gitの資格情報、クラウドCLIの認証、npmトークンなども棚卸し

開発者端末から盗まれる“価値”を下げるのが、攻撃の費用対効果を崩す近道です。Microsoft

4) 挙動監視：不審な通信を“気づける”ようにする

• 開発端末から未知ドメインへの定期的な外向き通信（ビーコン）を監視

• EDRやDefender系のアラートは「誤検知だろう」で流さない

• Nodeプロセスが不自然に別のNodeを起動していないか、プロセスツリーを確認

攻撃はC2接続が生命線なので、ネットワーク観点の検知は有効です。Microsoft

採用担当・企業側も無関係ではない：課題配布の“安全設計”が信頼になる

この種の攻撃は「転職市場の不安」を踏み台にします。企業側も、候補者保護とブランド毀損防止のために工夫できます。

• 課題は公式ドメイン・公式アカウントからのみ配布し、配布経路を固定

• 「初回は実行不要でレビュー可能」な形式（要件＋既存コードの差分レビュー等）も用意

• 候補者へ「不審なリポジトリを信頼しない」「隔離環境で実施」を明文化

候補者のセキュリティ意識を高めることは、選考の質にも直結します。

まとめ：Next.jsの問題ではなく“開発ワークフロー”が攻撃面になっている

今回の要点は、Next.js自体の脆弱性というより、開発者が日常的に行う操作（開く・起動する・信頼する）を攻撃フローに組み込んでいる点です。Microsoft

だからこそ対策も、難しい解析より先に「信頼しない」「隔離する」「シークレットを置かない」の3本柱が効きます。転職活動や副業で外部コードに触れる機会が増えるほど、ここを徹底するだけで被害確率は大きく下がります。