
29.07.2026 browser-forensicsransomwareai-generated-malwarefile-system-access-api
Check Point Research has surfaced a finding that unsettles a core assumption of malware forensics: ransomware that writes no file to disk and spawns no process, running entirely inside a browser tab. The trigger wasn’t a human attacker but a large language model. While analyzing roughly 3,000 DeepSeek-attributed files, researchers found a Flask application dubbed InfernoGrabber, disguised as a Discord avatar upscaler. The generated application tried to pack a keylogger, credential stealer, webcam capture, and ransomware overlay into a single web page — most of which browsers simply won’t allow. Buried in the noise, though, was one working piece.
The generated code called showDirectoryPicker(), a legitimate browser API that lets a web page request access to a folder on the user’s device, read files inside it, modify them, and send their contents to a remote server. No installation. No exploit. Just a permission prompt. Check Point turned the finding into its own proof of concept: a fake AI photo-enhancement tool that uses the File System Access API to encrypt images in a selected directory.
The flow is deliberately unremarkable: a user opens a page, picks a photo, chooses a folder to save the improved version, and grants the permission Chrome asks for. Behind that normal flow, the page can silently encrypt every picture in the folder during what appears to be routine processing. The risk is most acute on Android, where modern Chrome versions expose a browser API that allows web pages to read and modify files in photo directories after user approval, with a fake AI image-enhancement workflow giving users a plausible reason to approve folder-level access. Testing confirmed the technique works across Windows, macOS, Linux, Android, and Microsoft Edge on Windows, with the only significant exception being iOS, where it could not be reproduced. Crucially, there is no evidence that the browser-native ransomware pattern has been abused in the wild. The underlying risk itself isn’t new: browser security researchers and the W3C itself had acknowledged since the specification was drafted in 2019 that the File System Access API created a ransomware attack vector.
This creates a genuine problem for DFIR teams. An EDR sensor watching process and file-system events sees, in this scenario, only the browser process itself writing — with user authorization — into a directory it has legitimate access to. There is no suspicious process chain, no code injection, no classic LOLBins. The forensically relevant traces shift entirely into browser-native data structures: content-settings and permission databases (stored in Chromium’s Preferences file or the “Web Data” SQLite database), IndexedDB entries holding serialized FileSystemFileHandle objects, service worker registrations, cache storage remnants, and network telemetry for any exfiltration traffic.
Academic groundwork already exists here. A browser-based ransomware proof of concept was tested with three different operating systems, 23 file formats, 29 distinct directories, 5 cloud providers, and 4 antivirus solutions, showing that such ransomware is capable of encrypting numerous file types possessing sensitive user information — including user directories, data partitions, external storage devices, network volumes, and cloud-integrated directories.
In practice, this means incident responders must treat Chrome permission grants as their own artifact class, evaluate enterprise policies restricting the File System Access API, and integrate browser telemetry — not just endpoint telemetry — firmly into the triage pipeline. The case also illustrates how AI models act as force multipliers: defenders must now account for AI-assisted, disposable malware artifacts that complicate detection and attribution, as AI can rapidly translate abstract malicious concepts into operational threats by mapping them onto legitimate platform features.
← Back to overview