A ransomware attack that needs no malware download, no browser exploit, and no root access. Just a convincing phishing page and a single permission click. That is the reality Check Point Research revealed this week when it published its analysis of InfernoGrabber v9.0 — a browser-native ransomware proof of concept generated almost entirely by an AI model.
The attack abuses the File System Access API, a legitimate Chromium feature designed to let web applications read and write local files. It works across Windows, macOS, Linux, ChromeOS, and Android. No CVE exists because the API is functioning exactly as intended.
TL;DR
- Check Point Research has documented AI-generated browser-native ransomware that encrypts local files without installing any payload, using the legitimate Chromium File System Access API.
- The attack works across Windows, macOS, Linux, ChromeOS, and Android — iOS is not affected because Safari does not implement the API.
- DeepSeek V4 generated a working attack scaffold from a single broad prompt, independently discovering how to map malicious goals to legitimate browser capabilities.
- No CVE exists — the API works as designed, making this a permission-model and social-engineering problem rather than a vulnerability in the traditional sense.
- Development teams building web applications that request file access must rethink their permission UX, Content Security Policy headers, and user education strategies immediately.
How the Attack Works
The attack chain is deceptively simple. A phishing page — in the documented sample, a fake “AI-powered Discord avatar upscaler” — tricks the user into granting folder access through the browser’s native permission dialogue. Once the user clicks Allow, the page has persistent read-write access to the selected directory.
From there, the JavaScript payload:
- Enumerates the directory contents recursively using
showDirectoryPicker() - Reads file contents through browser file handles
- Exfiltrates data to a Flask backend server
- Encrypts and overwrites the original files in place
- Displays a ransom overlay with a Bitcoin payment demand and countdown timer
The entire operation runs inside the browser sandbox. No binary drops to disk. No system-level privilege escalation. No antivirus signature to trigger. Traditional endpoint detection tools are effectively blind to this attack vector.
Why Android Is the Primary Risk
While the technique works on desktop operating systems, Check Point identifies Android as the most dangerous target. Chrome 132 introduced File System Access on mobile, and Chrome 148 confirmed that the DCIM folder — where years of photos, identity documents, medical records, and banking screenshots accumulate — is accessible through the API.
On mobile, the browser permission prompt appears contextually reasonable. A user asked to “select your photo folder” by a tool claiming to enhance images will comply without thinking twice. There is no APK installation warning, no Play Protect scan, and no sideloading gate to clear. The attack surface is the permission dialogue itself.
The AI Dimension: DeepSeek as Attack Architect
What makes this research particularly significant is the role AI played in constructing the attack. Check Point analysed approximately 3,000 DeepSeek-attributed files over one year and classified 1,383 samples as malicious or dangerous.
The InfernoGrabber sample demonstrates something researchers have warned about: AI models can independently discover novel attack paths. DeepSeek V4 connected the concept of browser-based ransomware — previously dismissed as impractical due to sandboxing limitations — to the File System Access API’s real capabilities. As Eli Smadja, Check Point’s research head, puts it: “The next attack technique will be discovered not by a human researcher, but by an AI hallucination.”
Pedro Drimel Neto, Check Point’s malware lead, adds a pointed observation: “Threat actors are actively selecting LLMs based on which ones will cooperate with harmful requests.” DeepSeek demonstrated lower refusal rates for cyber-related prompts than competing models, generating functional attack scaffolds from single broad requests where others required decomposed, multi-step prompt engineering.
What Development Teams Must Do Now
This is not a theoretical concern to file away. If your web application requests file system access, or if your users interact with sites that do, your attack surface just expanded. Here is what needs to happen.
1. Audit Your File System Access API Usage
If your application uses showDirectoryPicker() or showOpenFilePicker(), audit exactly what you are requesting and why. Apply the principle of least privilege ruthlessly — request access to the narrowest possible scope and release file handles as soon as operations complete. Document the business justification for every file-access permission your application requests.
2. Harden Your Content Security Policy
A strict CSP can prevent injected scripts from reaching out to exfiltration endpoints. Ensure your connect-src directive restricts outbound connections to known origins. If your application does not need the File System Access API, consider using Feature Policy headers to disable it entirely:
Permissions-Policy: file-system-access=()3. Educate Users on Permission Prompts
Browser permission dialogues have become the new attack surface. Your security awareness training needs to evolve beyond “don’t click suspicious links” to include “treat file-access browser prompts as high-stakes security decisions.” If your application triggers these prompts, provide clear contextual explanations of what access is being requested and why.
4. Implement Behavioural Monitoring
Traditional signature-based detection will not catch browser-native attacks. Consider implementing client-side behavioural monitoring that can flag anomalous file-access patterns — bulk enumeration, rapid sequential reads, or unexpected write operations after reads. This is new territory for most security teams, but the attack surface demands it.
5. Plan for the AI-Generated Threat Curve
The barrier to weaponising browser APIs is collapsing. Attackers no longer need to understand the File System Access API specification — they need only describe their desired outcome to a cooperative AI model. Your threat modelling must account for the fact that every documented browser capability is now a potential attack vector, because AI can bridge the knowledge gap between intent and implementation.
The Bigger Picture: Permission Models Under Pressure
This research exposes a fundamental tension in modern web platform design. The File System Access API exists because web applications genuinely need local file access — document editors, media tools, development environments. The permission model assumes users can make informed decisions about granting access. But social engineering has always been more effective than technical exploitation, and AI-generated phishing lures are only getting more convincing.
Browser vendors are aware of the tension. Chromium already blocks access to sensitive system directories like Program Files, AppData, and the Windows folder. But the directories users care about most — photos, documents, downloads — remain accessible by design. The trade-off between capability and security is unlikely to be resolved by the browser alone.
At REPTILEHAUS, we work with development teams to build applications that take security seriously from the architecture layer, not as an afterthought. Whether it is CSP hardening, permission-model auditing, or threat modelling for AI-era attack vectors, our team can help you stay ahead of threats that traditional security tools were never designed to catch. Get in touch if your team needs to tighten its security posture.
