いつも使っているブラウザが、ある日「このフォルダを見せてください」と尋ねてくる。深く考えず「許可」を押す——その何気ない一動作が、実は攻撃の入り口になりうるとしたら、どうでしょうか。
今回明らかになったのは、特別なウイルスを送り込むわけでも、ブラウザの穴を突くわけでもない、少し不気味な手口です。しかも、その手口を思いついたのは人間のハッカーではなく、AIでした。正確には、AIが山ほど吐き出した「動かないコード」の中に、たった一つ本物の攻撃につながる断片が紛れ込んでいた。研究者はそれを拾い上げ、「これは本当に成立してしまう」と実証してみせたのです。
道具として悪用されるAIは、これまでにも何度も報じられてきました。けれど今回は毛色が違います。攻撃を「作らされた」のではなく、AIが正規の機能同士を勝手に結びつけて、人間がまだ誰も実際にはやっていなかった攻撃の形を、偶然たぐり寄せてしまった。その一部始終を、これから順を追って見ていきます。
2026年7月1日、Check Point Researchが、DeepSeekで生成されたマルウェア検体InfernoGrabber v9.0を指摘したと報じられた。検体はPython製Flaskアプリ「deepseek_python_20260125_da0631.py」で、2026年1月25日にVirusTotalへアップロードされ、同サービスは情報窃取ツール兼ランサムウェアのツールキットと評した。偽のDiscordアバターAIアップスケーラーを装い、Discordトークン、クレジットカード情報、暗号資産ウォレット情報などの収集を狙うルーチンやスタブを含み、ランサムノート風画面でBitcoinを要求する。
攻撃はフィッシングの囮でファイルシステムアクセスを許可させ、ピッカー方式のFile System Access APIを介してファイルを暗号化する。File System Access APIはGoogle Chromeなど多くのChromium系ブラウザでWindows、macOS、ChromeOS、Linux、Androidに対応する。Check Pointが攻撃成立を確認した環境はWindows、macOS、Linux、Android、およびWindows上のMicrosoft Edgeで、iOSでは再現されなかった。Check Pointは過去1年で約3,000件のDeepSeek帰属ファイルを分析し、1,383件を悪意ある、または危険と分類した。ペドロ・ドリメル・ネトとエリ・スマジャがコメントを寄せた。
From: 
AI-Generated Browser Ransomware Abuses Chromium API on Windows, Linux, macOS, Android
【編集部解説】
このニュースの核心は「AIが未知の脆弱性を見つけた」ことではありません。むしろ、以前から知られていた正規のブラウザ機能を、AIが悪意ある目的へと”つなぎ合わせた”点にあります。ここを取り違えると事案の本質を見失うため、最初に整理しておきます。
問題の中心にあるFile System Access APIは、Webページがユーザーの許可を得た上でローカルのファイルやフォルダを読み書きできる、Google Chromeなどが備える正規の仕組みです。オンラインの画像編集やドキュメントアプリを、いちいちアップロード・ダウンロードせずに扱えるようにするための、本来は利便性のための機能です。
興味深いのは、Check Point自身がブログで認めているように、DeepSeekが生成した検体の大半は「ほとんど間違っていた」という事実です。キーロガーやWebカメラ乗っ取りなど、ブラウザの制約上そもそも動かない機能を1枚のページに詰め込もうとした、典型的なハルシネーションでした。ところがノイズの中に一つだけ、showDirectoryPicker()という実在するAPIを正しく呼び出すコードが紛れ込んでいた——そこが唯一「当たっていた」のです。
つまりこれは、AIが百発百中で攻撃を設計したという話ではなく、大量の的外れな出力の中に一つ実用に足るものが混ざり、それを人間の研究者が拾い上げて実証したという構図です。Check Pointの研究責任者エリ・スマジャが「次の攻撃手法は、たまたま一つを正しく言い当ててしまったAIのハルシネーションによって発見される」と表現したのは、この非対称性を突いた言葉だと言えます。
技術的な脅威の輪郭は、意外に限定的である点も公平に押さえておくべきでしょう。この手口はブラウザの脆弱性を突くものではなく、あくまでユーザーが「許可」ボタンを押すことが前提です。APIはディスク全体への任意アクセスを禁じており、システム領域には制限がかかります。裏を返せば、写真フォルダのような「ユーザーが日常的に触る場所」を選ばせるだけで、被害としては十分に成立してしまうということでもあります。
影響範囲は当初の想定より広いことが、Check Pointのマルウェア解析チームリーダーであるペドロ・ドリメル・ネトの実機テストで確認されています。File System Access API自体はChromeなど多くのChromium系ブラウザで、Windows・macOS・ChromeOS・Linux・Androidに対応します。そのうえで、Check Pointが実機で攻撃成立を確認した環境として明示しているのはWindows、macOS、Linux、Android、そしてWindows上のMicrosoft Edgeで、再現できなかったのはiOSのみ。Safariが同APIを実装していないためで、iPhoneユーザーがこの特定の手口の対象外である点は、数少ない安心材料です。
なお、File System Access APIの対応状況はブラウザとバージョンによって差があり、情報源によって記述が分かれる点には留意が必要です。デスクトップのChromeやEdgeではバージョン86以降で利用でき、Androidでは比較的新しいChrome（バージョン132）で到達したと報じられています。一方、やや古い技術資料ではAndroid非対応と記すものもあり、実際に狙われうる環境かどうかは、利用中のブラウザとバージョンに依存すると考えておくのが安全です。
見落とされがちですが、ランサムウェアという脅威はFile System Access APIの仕様書自体が明記して警告してきたものであり、2023年のUSENIX論文「RøB: Ransomware over Modern Web Browsers」でも同種の悪用可能性が実証されていました。既知のリスクだったからこそ、防御側は「理論上は可能だが現実的ではない」と棚上げしていた——その棚上げをAIが崩した、という順序が正確です。
ここから見えてくる長期的な論点は、規制やガバナンスの重心が動くということです。従来のAI安全対策は「ransomwareを作って」といった露骨な要求をモデルが拒否できるか、という入口の防御に偏りがちでした。しかしドリメル・ネトが指摘するように、脅威アクターは有害な要求に協力してくれるモデルを能動的に選別しており、トリガー語を外した婉曲な指示には既存の防御が効きにくいのが実情です。
とりわけDeepSeekが選ばれた背景——無料で使え、西側モデルが利用できない地域でも動き、拒否率が相対的に低いという条件——は、AI安全性が一社の努力では完結せず、市場全体のばらつきに左右されることを浮き彫りにします。1社が堅牢でも、代替が緩ければ攻撃者はそちらへ流れる。この「最も緩い選択肢に引きずられる」構造は、今後の国際的なAI規制議論で避けて通れない争点になるでしょう。
innovaTopia読者にとっての実務的な示唆はシンプルです。ブラウザが出す「このフォルダへのアクセスを許可しますか」というプロンプトは、これからは一つのセキュリティ判断として扱う必要があります。見慣れないWebツールには空のフォルダを与える、写真ライブラリのような不可逆なデータには安易に書き込み権限を渡さない、バックアップを常に別に持つ——地味ですが、AI時代の攻撃に対する最も現実的な備えは、こうした「許可の作法」の再習得にありそうです。
【用語解説】
File System Access API
Webページがユーザーの許可を得て、ローカルのファイルやフォルダを直接読み書きできるChromium系ブラウザの仕組み。オンライン画像編集やコードエディタなど、本来は利便性のために設計された正規機能である。今回の攻撃は、この正規機能を悪用の起点にしている。
showDirectoryPicker()
File System Access APIの中核となる関数の一つ。呼び出すとフォルダ選択ダイアログが開き、ユーザーが選んだフォルダへの「ハンドル」が返る。以降そのフォルダ内のファイルを列挙・読み取り・書き換えできる。検体の大半が機能しない中、この呼び出しだけが正しく動いた点が事案の核心だった。
ブラウザ内ランサムウェア（In-Browser Ransomware）
実行ファイルを端末に導入せず、ブラウザの中だけでファイルの暗号化や脅迫まで完結させる攻撃手法。従来は理論上の存在とされてきたが、今回それが実働可能と示された。
ハルシネーション
AIが事実や仕様に反する、もっともらしい出力を生成する現象。通常は誤りとして扱われるが、本件では大量の誤出力に一つだけ実在APIの正しい呼び出しが混ざり、結果的に攻撃の糸口になった。
Flask
Pythonで軽量なWebサーバーやWebアプリを構築するためのフレームワーク。検体はこのFlaskで作られた不正なWebサーバーとして動作した。
シードフレーズ
暗号資産ウォレットを復元するための複数語からなる秘密の鍵。流出すれば資産を丸ごと奪われるため、窃取対象として狙われた。
RøB: Ransomware over Modern Web Browsers
2023年のUSENIX Security で発表された研究論文。File System Access APIとWebAssemblyを用い、ブラウザからユーザーのファイルを暗号化する悪性WebアプリRøBを実証したもので、今回の手口が「以前から指摘されていた既知リスク」であったことを示す。
【参考リンク】
Check Point Research（外部）
本件の一次情報を発表したイスラエルのセキュリティ企業の研究部門。検体分析とPoC実証を公開。
DeepSeek（外部）
検体生成に使われた中国発の大規模言語モデルの公式サイト。無料のWebインターフェースを提供する。
Google Chrome：File System Access API 解説（外部）
悪用対象となったAPIの公式解説。設計思想や利用方法、権限管理の考え方が記載されている。
VirusTotal（外部）
Googleが所有するマルウェアスキャンサービス。検体をアップロードし挙動を分析・共有した場となった。
Discord（外部）
検体が偽のアバターAIアップスケーラーとして詐称した対象。攻撃とは無関係だが囮に利用された。
Microsoft Edge（外部）
Chromiumベースのため、Check Pointのテストで攻撃成立が確認されたブラウザの一つ。
MDN Web Docs：File System API（外部）
APIの技術リファレンス。ユーザー許可なしにはアクセスが認められない安全設計も解説する。
【参考記事】
When AI Invents the Attack: Browser-Native Ransomware（Check Point Blog）（外部）
約3,000件の分析で検体を発見。大半は動かず、showDirectoryPickerだけが正しかったと明かす。
Browser-Only Ransomware Abuses Chrome File System Access API to Encrypt Android Photos（Cyber Security News）（外部）
Chrome 86、Android版Chrome 132での対応や、DeepSeek V4の拒否と回避の検証を伝える。
Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique（Check Point Research）（外部）
一次技術レポート。機能の多くは崩壊したが、研究者がPoCを構築しリスクの実在を実証した。
RøB: Ransomware over Modern Web Browsers（USENIX Security 2023）（外部）
本件の手口が既知の学術研究であったことを示す一次論文。ブラウザからのファイル暗号化を実証。
New in Chrome 132（Chrome for Developers Blog）（外部）
AndroidとWebViewでFile System Access APIが利用可能になった時期を示す公式の根拠。
Browser-Only Ransomware Uses File System Access API to Encrypt Files Without Malware Installation（GBHackers）（外部）
仕様書やUSENIX論文「RøB」に触れ、本件が既知リスクの顕在化である点を補強する。
Check Point Uncovers AI-Generated Browser Ransomware Technique（Security MEA）（外部）
iOSが対象外である点を確認しつつ、許可プロンプトへの実務的な向き合い方を示す。
【関連記事】
ESET、生成AI悪用の初のAndroidマルウェア「PromptSpy」を発見─Google Geminiでデバイスを遠隔操作
AIが「実行フロー」に組み込まれたマルウェア。今回の「AIが開発に使われた」事例との対比で読みたい一本。
Gemini連携マルウェア「PromptFlux」の脅威 – 毎時間自己進化する攻撃の実態
LLMで自己進化する実運用寄りの脅威。PoC段階の今回と、AI悪用マルウェアの深度差を測る補助線。
中国発DeepSeek、12カ国が使用制限――AIコスト革命の裏にある地政学リスク
「なぜDeepSeekが悪用に選ばれたか」――拒否率と規制の背景を掘り下げた記事。
【編集部後記】
AIが嘘をつく、事実でないことをもっともらしく語る——ハルシネーションは長らく「精度の問題」「使う側が気をつければいい欠点」として語られてきました。実際わたし自身、生成AIの誤りを見つけては苦笑いして直す、その繰り返しに慣れきっていたところがあります。でも今回のケースは、その慣れに冷や水を浴びせてきました。的外れな出力が大量に積み上がったその中に、たまたま一つ、現実に機能してしまうものが混じっていた。そして、それを見抜いて形にする人間がそばにいれば、欠点はそのまま武器に変わる。ハルシネーションは「間違い」であると同時に、確率的にごくまれな「偶然の発見」でもあるという、当たり前なのに直視してこなかった事実を、あらためて突きつけられた気がします。
もう一つ、書きながらずっと考えていたのは、「許可」という行為の重さです。わたしたちは一日に何度、アプリやサイトに何かを許している。カメラ、マイク、位置情報、通知、そしてフォルダへのアクセス。その多くを、ほとんど反射で通しているはずです。攻撃者にとって、脆弱性を探して回るより、この反射をそっと利用するほうがずっと手軽だとしたら——守るべきはシステムの奥ではなく、指が「許可」に伸びるその一瞬なのかもしれません。技術の話のようでいて、最後は驚くほど人間くさいところに着地する。そこがこの一件のこわさであり、同時に、わたしたちにまだ打てる手が残されている理由でもあると思います。
とはいえ、これは「AIは危険だ、警戒しろ」という話で終わらせたくありません。同じ推論の力は、防御側にも回せます。実際、脆弱性を先回りして見つけるAIの取り組みも動き始めています。前のめりに新しい技術へ手を伸ばしたい気持ちと、その手が何を握らされているかを一拍おいて確かめる冷静さ。その両方を、これからも一緒に持っていけたらと思っています。次に「アクセスを許可しますか」が出たとき、ほんの一秒だけ立ち止まる。まずはそこから、ご一緒に。
