NearSeal

2026-08-10

Does encrypting your backup files protect you from a ransomware data leak?

Ransomware used to work in one step: lock every file on the network, then demand payment for the key. By 2026, that's the old version of the attack. Most ransomware groups now spend hours or days quietly copying files off a network to their own servers before anyone notices anything is wrong — and locking the files on the way out has become, for some groups, optional rather than the main event. That shift changes what "protecting a file" actually needs to mean, and it's worth being specific about where file-level encryption genuinely helps and where it doesn't.

Ransomware now steals your files before it locks anything

The industry term for this is "double extortion": encrypt what you can, but exfiltrate first, so there's still leverage even if the victim restores from backup and refuses to pay. It's no longer the exception. Security firm BlackFog reported that 96% of ransomware attacks in Q3 2025 involved data exfiltration, and Mandiant/Google Cloud's own incident-response data shows confirmed data theft in 77% of ransomware intrusions in 2025 — up from 57% in 2024. Encrypting the victim's own systems, once the entire point of the attack, is now sometimes skipped in favor of a simpler message: "we already have your files, pay or we publish them." The model is large enough to have its own leaderboard: GuidePoint Security tracked 7,515 victim organizations added to ransomware groups' public leak sites in 2025, a 58% jump from roughly 4,750 the year before.

A backup restores access. It doesn't undo a leak.

Regular backups remain the right defense against the original threat — a locked, unusable network. They do nothing about the second one. Security vendor Huntress puts it plainly in its own guide to double extortion: "Backups help you recover systems, but they don't undo data theft," because "your backup ran last night, but your data left the network three days ago" — by the time recovery even starts, the stolen copy is "already on an attacker's server, ready to be published or sold." The same guide sums up the gap in one line: "Backups solve one problem: They restore access. But they do nothing for data that's already exfiltrated or sold." Restoring from backup answers "can I get back to work." It has no answer at all for "is the client file, the ID scan, or the contract that got copied out three days ago still going to end up on a leak site."

Where this risk actually sits for individuals and small teams

Large organizations get the headlines, but the mechanics apply just as directly to a home NAS, a small firm's shared drive, or a folder synced to cloud storage — anywhere a real collection of documents sits in one place, in plain form, waiting to be backed up or shared. That's precisely the kind of target these attacks are built around: not a single file, but a whole folder's worth at once — scanned IDs, signed contracts, financial records, client files. None of that has to belong to a large organization to be a real target; it's exactly the kind of collection an individual or a two-person business tends to keep as exactly one plaintext copy, sitting in exactly the kind of storage location this attack model is built to reach.

What actually leaves when a backup gets exfiltrated? Backup left as plain files Ransomware exfiltrates the folder before locking anything What leaves: readable documents — full leverage for a leak-site threat Encrypted first (e.g. NearSeal) Ransomware exfiltrates the same folder, same way What leaves: ciphertext only — nothing readable to publish without the passphrase
Same exfiltration, same attacker — what determines whether the stolen copy is actual leverage is whether it was already ciphertext before it left.

What pre-encrypting a file changes — and what it doesn't

The one variable that decides whether a stolen copy is actually useful to an attacker is whether it was readable at the moment it left. If a backup folder holds plain files, an exfiltrated copy is the real document — fully usable as leak-site leverage. If those same files were encrypted, passphrase-only, before they were ever copied into that folder, an exfiltrated copy is ciphertext: unreadable without a passphrase that was never stored anywhere near the files themselves. That's a real, structural difference — but it only holds under a condition worth stating plainly: the passphrase can't live on the same machine or in the same backup location as the files, and the encryption has to happen before the copy is made, not after. Pre-encrypting a file doesn't stop ransomware from locking a device, doesn't restore anything, and doesn't replace a real backup strategy — it only changes what a stolen copy is worth to whoever stole it.

Where NearSeal fits

NearSeal encrypts files entirely in the browser — the file and the passphrase never leave the device, and there's no server anywhere in the process. For a folder with more than one file, it batches them: encrypt every selected file, then bundle the results into a single ZIP for download, handling files that share a name across different source folders by appending "(2)", "(3)" rather than letting one silently overwrite another. Two output formats are available: the default NearSeal container (AES-256-GCM, PBKDF2-SHA256 key derivation), or the open age-encryption.org format (ChaCha20-Poly1305, scrypt), which opens with the standard age or rage CLI as well as this site. Neither is a ransomware-removal tool, a backup product, or full-disk encryption — it's one layer, applied to specific files, that decides what a stolen copy of them is actually worth if the storage location holding them is ever the one that gets breached.