Ransomware normally needs a foothold: a phishing attachment, a vulnerable service, a dropped binary, something that touches disk outside the browser sandbox. Check Point Research just demonstrated a variant that needs none of that — it runs entirely as JavaScript in a browser tab, encrypts files the user has granted access to, and never installs anything. The attack surface it abuses isn’t a bug. It’s a legitimate Chromium browser API exposed through a user permission flow.

The strange part is how it was found: Check Point analyzed a DeepSeek-attributed all-in-one malware sample that tried to behave like a native stealer and ransomware tool from inside a web page. Most of it was nonsense. But buried in the hallucination was a working idea that mapped to a real browser capability and a practical social-engineering path.

TL;DR

  • Check Point analyzed a DeepSeek-attributed combined stealer/ransomware sample; most of its claimed browser malware behavior was non-functional AI hallucination
  • One hallucinated capability mapped to a real feature: the File System Access API, which lets a web page read local files, and request write access, after a user grants file or folder permission
  • Researchers built a working proof of concept: a fake “AI photo upscaler” site requests folder access, then enumerates, reads, encrypts, and overwrites files client-side — no install, no exploit, no CVE
  • The sample behind the discovery, dubbed InfernoGrabber, was uploaded to VirusTotal in January 2026 as a Flask app with a Discord-themed front end
  • Chrome desktop (v86+) and Chrome/WebView on Android (v132+) expose the relevant picker primitives; Firefox and Safari do not expose equivalent methods, which narrows exposure to the Chromium family
  • Check Point states there is no evidence of in-the-wild abuse yet — this is demonstrated capability, not an active campaign

Why This Matters

If you or your users grant a website access to a folder — expecting a photo upscaler, a PDF tool, a file converter — you’re one permission click away from a ransomware payload that may look like ordinary browser file activity to Endpoint Detection and Response (EDR, software that monitors process and file activity for threats). This affects everyone who clicks “Allow” on a folder-access prompt without a second thought, but it’s sharpest on Android, where a convincing photo workflow can lead users to expose DCIM or Pictures directories — passports, banking screenshots, family photos included.

Table of Contents

What Check Point Actually Did

Check Point’s researchers analyzed a DeepSeek-attributed malware artifact that tried to be something a normal web page should not be able to become: a combined credential stealer and ransomware payload that runs without installation. The original prompt is unknown, but the code structure suggests a broad request for an all-in-one malicious browser tool.

The result, a Python Flask application uploaded to VirusTotal on January 25, 2026 under the filename deepseek_python_20260125_da0631.py, was mostly what you’d expect from an LLM (Large Language Model, the type of AI behind chatbots like ChatGPT or DeepSeek) trying to satisfy an incoherent malware wish list: features that don’t work, capabilities that don’t exist, logic that contradicts itself. The malware author had named it InfernoGrabber v9.0.

Most of it was scrap. One line wasn’t.

The Hallucination That Turned Out to Be Real

Among the fictional capabilities, the AI-generated sample referenced browser access to a user’s file system and photo directories — something that sounds like classic LLM confabulation, the same category of error covered in our piece on slopsquatting, where AI models invent package names that don’t exist.

Except this one did exist. The File System Access API is a real browser capability in Chromium, and it does let a web page request access to local files and directories. It is documented through the WICG File System Access draft, not a finalized W3C standard. The AI didn’t invent a vulnerability — it stumbled onto an underappreciated legitimate feature and described it as if it were already a malware primitive.

Check Point’s researchers took that single accurate detail, discarded everything else in the sample, and built their own working proof of concept around it. That’s the actual research contribution here: not the AI-generated malware itself, which barely functioned, but the confirmation that the one true thing it said was enough to build a real attack.

What the File System Access API Is For

To be clear about what’s being abused: this is not a browser exploit, and there’s no CVE attached to it. The File System Access API is a deliberate, documented Chromium capability, shipped on Chrome desktop since version 86, designed for legitimate use cases — browser-based photo editors, IDEs like a VS Code web version, local document tools that need to read and save files without routing everything through a cloud upload.

The security model is permission-based: a site calls showDirectoryPicker() or showOpenFilePicker(), the browser shows a native OS folder/file picker, and the user explicitly selects what to share. Nothing happens without that click. In isolation, that’s a reasonable design — arguably safer than blind uploads to a server.

The problem is what happens after the user clicks “Allow.” Within the selected scope, and subject to the browser’s read/write permission checks and sensitive-location restrictions, a page can read, overwrite, or remove files through the same legitimate handles.

The Attack Chain

The proof of concept Check Point built mirrors classic social engineering, with the browser’s own legitimate permission system doing the work a dropped binary normally would.

  1. Lure. Victim visits a site disguised as a free tool — Check Point’s PoC used a Discord-themed “AI avatar upscaler.”
  2. Permission request. The page calls the File System Access API and prompts for folder access, framed as “select where to process or save your photos” or similar.
  3. Grant. The user picks a folder — often Photos, Pictures, or DCIM — believing it matches the tool’s advertised function.
  4. Enumeration and read. JavaScript walks the directory tree using the granted handle and reads file contents, entirely client-side.
  5. Encryption. Files are encrypted in place and overwritten using the same file handles — no server round-trip required for this step.
  6. Extortion. An overlay replaces the page, demanding payment, in the same visual pattern as traditional ransomware.

A minimal illustration of the core primitive being abused (this is the legitimate API call, not the malicious logic around it):

// Standard File System Access API call — legitimate use in any browser tool
const dirHandle = await window.showDirectoryPicker({ mode: "readwrite" });


// Once granted, the page can iterate every file in the folder
for await (const [name, handle] of dirHandle.entries()) {
  if (handle.kind === "file") {
    const file = await handle.getFile();
    const buffer = await file.arrayBuffer();
    // A malicious page would encrypt `buffer` here and write it back
    // using handle.createWritable() — no install, no exploit needed
  }
}

No native binary, no APK, no browser exploit, no elevated privileges. The only “vulnerability” exploited is a user believing a fake tool’s cover story.

Why This Is an EDR Blind Spot

Traditional ransomware detection watches for process behavior: mass file renames, suspicious process trees, unusual write patterns from an unrecognized binary, ransom notes dropped to disk by an external executable. This technique removes many of those signals from the OS’s point of view — the process doing the reading and writing is the browser itself, a fully trusted, code-signed application the user runs all day.

There’s no new process spawned, no binary dropped outside the browser’s own sandbox, no registry or driver activity. Everything happens inside JavaScript execution within a tab. Endpoint tools built to alert on unfamiliar processes touching many files quickly have to distinguish “user’s legitimate photo tool saving edited images” from “ransomware encrypting the same folder” — with the file activity attributed to the same trusted browser process.

This is the same structural blind spot we’ve discussed with living-off-the-land techniques on Windows: the tooling used is legitimate, so detection has to shift from “what ran” to “what it did and why.”

Platform Scope: Why Android Is the Sharper Edge

PlatformFile System Access API supportPractical risk
Chrome desktop (Windows/Linux/macOS)v86+ (2020)Moderate — user selects a specific folder, usually not their entire filesystem
Chrome / WebView on Androidv132+Elevated — photo-processing lures naturally steer users toward DCIM/Pictures roots containing photos of IDs, banking screenshots, 2FA backup codes
FirefoxNo equivalent picker APINot currently exposed to this technique
Safari / WebKitNo equivalent picker APINot currently exposed to this technique

The concentration in Chromium-based browsers narrows the blast radius, but Chrome’s desktop and mobile market share means “narrowed” still covers most of the browsing population. On Android specifically, the directories users are most likely to grant access to — photo galleries — are also the ones most likely to contain irreplaceable personal documents with no separate backup.

MITRE ATT&CK Mapping

Neither technique needs a new sub-technique to describe this — the ATT&CK framework already models the behavior correctly. What’s genuinely new is the execution context: impact achieved entirely within a browser tab, with the browser itself as the only “process” involved.

What You Can Do Today

For individual users:

  • Treat a folder-access prompt with the same suspicion as a permission request from an unknown mobile app. If a tool asks for access to your entire Photos or DCIM folder to do something that should only need one file, that’s a red flag.
  • Prefer showOpenFilePicker()-scoped tools (single file) over ones demanding full directory access, when you have the choice.
  • Keep an offline or immutable backup of anything irreplaceable — this defeats the extortion regardless of how the encryption happened. See our ransomware backup strategy guide for the immutability and validation details that matter here.
  • Keep Chrome and Android updated; this doesn’t patch a vulnerability (there isn’t one) but keeps you aligned with any future permission-model hardening Google ships in response to this research.

For security teams:

  • Don’t rely solely on process-based EDR heuristics for ransomware detection — build detection logic that accounts for browser-mediated file access at volume, not just unrecognized binaries.
  • Add browser extension and site-permission audits to your endpoint hardening checklist; for managed Chrome fleets, review whether enterprise controls for file and directory picker behavior fit your risk model before allowing broad use of browser-based local file tools.
  • Include this technique in phishing-awareness training alongside classic ClickFix and pastejacking patterns — see our breakdown of ClickFix, FileFix, and pastejacking attacks for the broader family of “user does the dangerous action themselves” techniques this belongs to.
  • Track this as a capability demonstration, not an active campaign — Check Point reports no confirmed in-the-wild exploitation as of publication. Treat it as a “fix this before it’s exploited” item, not an incident.

The Broader Pattern

The genuinely interesting part of this story isn’t the ransomware — it’s how it was found. Check Point didn’t set out to research the File System Access API. They set out to see what garbage an AI produces when asked for something absurd, and one piece of that garbage happened to be true.

That’s a pattern worth watching independent of this specific technique. As we noted when covering AI-generated slopsquatting attacks, LLMs fail in ways that are often plausible rather than random — they blend real and fictional elements convincingly enough that separating them requires actual verification, not intuition. Here, that failure mode ran in the opposite direction from usual: instead of an AI hallucinating a dangerous-sounding thing that turns out to be fake (a nonexistent package, a fabricated CVE), it hallucinated a dangerous-sounding capability that turns out to be real. An AI can now function as an unintentional vulnerability-research assistant, simply by confidently describing things that don’t quite exist yet — until one of them does.

This is a single-vendor disclosure at time of writing, with independent outlets (The Hacker News, The Register, GBHackers) corroborating Check Point’s technical description but not yet publishing independent testing of their own. Treat the “no in-the-wild exploitation” claim as Check Point’s assessment, not an independently confirmed absence.

Sources