Zero-day prevention. Is there a Windows program that encrypts files on-the-fly, keeping only the currently open file decrypted?

Question

I'm looking for a program for Windows that can securely store my code. The program should be able to encrypt my files on-the-fly, such that only the file I'm currently using is kept decrypted (mainly the current source file(s) I'm working on in Visual Studio 2022 for confidential projects).

Once I'm done with the file, it should be encrypted again. This would ensure that even if my PC were to be compromised by some kind of exploit/RCE, my code would remain safe as all source files are dynamically encrypted.

Yes, the attacker could potentially try accessing the files the same way I do, thus decrypting them. But this wouldn't work as easily if I need to enter a password or something prior to allowing the files to be decrypted.

Ideally, I'd prefer not to use a program like VeraCrypt, which requires me to manually mount and unmount the drive (leaving all files within the drive fully decrypted upon mount). I'm looking for a solution that can automatically encrypt and decrypt files on-the-fly.

Does such a program exist? If not, what would be a good approach to achieving this?

Lastly, I'm currently using Bitdefender Total Security as my anti-malware software and Microsoft Edge with malware protection enabled. I've put a lot of trust into Bitdefender's Advanced Threat Defense module (which is supposed to detect and prevent zero days), but I want to be as safe as humanly possible. So, if anyone has recommendations for more software that could protect me against exploits/RCEs I would be greatly appreciative.

And for those that want to preach the obvious, yes, I know I'm on Windows and that I could be coding on Linux or some other OS to reduce the attack surface, but it's not ideal for me to use anything other than Windows for software development at this time unfortunately (I am currently running Atlas OS).

I also know that I am unlikely to be specifically targeted by some kind of APT or have literal million dollar RCEs wasted on me, but I am VERY paranoid as something similar happened to me in the not so distant past (TLDR; got hit with a chromium RCE allowing the attackers full access to my file system, letting them steal highly confidential files).

Answer 1

First things first: Asking for software recommendations is off topic for this site and you should instead use the Software Recommendations site. I'm going to mostly talk about why what you're asking for is not very useful, security-wise.

---

A version of this feature is built into Windows, and has been since Windows 2000. It's called Encrypting File System, or sometimes just File Encryption. It does require the "Pro" or higher edition of Windows, though; "Home" editions don't have this feature. The way EFS works, the owner of a file can encrypt that file (or all files below a directory they own) such that only users currently authorized to read the file can decrypt it, but nobody else can. This is done using per-file keys encrypted to per-user public keys stored in the users' certificates; the corresponding private keys needed for decryption are themselves encrypted such that they can only be decrypted with the user's credentials. This encryption and decryption happens transparently, on demand, and only in memory; the decrypted data is never written back to the file system unless the owner chooses to decrypt it (or write it to a decrypted file).

Of course, this is completely useless against most malware, because typically, malware runs as you and therefore can do anything that any other software running in your user account can do. That includes opening EFS-encrypted files. EFS does protect against some cases where a program gains elevated privileges or an authorization bypass - specifically, the ability to read files that would normally be unauthorized. Even an Administrator can't directly decrypt an EFS file that the Admin wasn't granted access to, although an Admin could of course install a driver or similar to capture your EFS private key when you log in / are logged in already.

There's also a feature in recent versions of Windows (at least Win10 and later, possibly as far back as Win7) called "Controlled Folder Access" (h/t @falco), which attempts to restrict what programs are allowed to access files in certain folders. Unfortunately, this protection is pretty easy to bypass. Malware can take over an already-approved app (any app you've allowed before, or any app published by Microsoft) either by injecting code into the running app, remote controlling it using the accessibility/automation APIs, or potentially just launching it under a debugger. This would allow the malware to either directly access the files (via injected code), or to move them outside the "protected" folders and then access them there normally.

To be clear, lots of malware won't be aware of Controlled Folder Access, and may well be stymied by it (though a 0-day in a browser might be a problem if the browser is already allowed access). However, the techniques to bypass it are not very advanced, and a competent malware author will include them even in mass-distribution malware, in addition to targeted malware customized for the victim. That's especially true since, as a built-in feature, it's something that lots of potential targets can be expected to already have.

If you want something that will require a separate credential (e.g. a password) from you when you try to open a file but but the decrypted data is lost (until the next time you enter the credential) when the file is closed... well, such software might exist. It's not conceptually hard; you could do it with e.g. a filter driver + some UI to prompt for the credential. It'd even be possible to make it such that malware has a hard time (needs elevated privileges) stealing the credential or opening the file again itself. However, it'd be somewhat more difficult to prevent the malware from accessing the file through the program you're using as you have the file open. Most malware won't be written to do this, of course, but it's possible via the debug APIs.

Answer 2

The most reasonable thing to do here would be to leverage filesystem access controls by running Visual Studio under a separate user account.

I'd:

1. Create a new Windows user account, eg code.
2. Lock down the directory containing your files such that only the code account has any permissions to its contents. This means disabling inherited ACLs, deleting all entries, then giving code "Full control". Importantly, this means you remove the Administrators group and SYSTEM account's read/write permissions.
3. Launch Visual Studio using "Run as different user". With UI changes in recent Windows, this command is harder to find. You have to shift+right click the exe (or shortcut to the exe, but only in Explorer; not from the Start menu sadly) and you'll find the command in the classic context menu. (Alternatively, use runas at the command line.) You then enter the username and password of your code account.

This will prevent any programs running under your normal user account from accessing your files.

Even if a program manages to elevate to Administrator privileges, they do not automatically get read or write permissions on your files — in contrast to Unix systems, where root automatically can read and write anything, on Windows, the only special permission that an Admin gets is the ability to take ownership of a file.

This means that upon encountering your protected folder, malware would first need to take ownership of the directory, then assign itself (ie the user account its running under) read/write permission, then proceed. None of this is particularly difficult, but depending on the sophistication level of the malware, it may not be coded to take those steps since it's an unusual situation.

Combining EFS file encryption would then add an extra layer of protection, since in addition to malware needing to reassign permissions (trivial), it would also need to steal the special user's crypto keys (harder).

The combination of a special-purpose user account + file permissions + EFS should strike a good balance between usability and extra security, keeping in mind that once malware executes on a machine, no protection can be airtight.

Also keep in mind that any plugins, extensions, and build tools you run in Visual Studio will necessarily run under the code account, and therefore have access to your protected files. If one of those tools contains malware, it doesn't even need any kind of elevated permissions to steal your data.

If your files are truly so valuable, the only real solution is to only work with them on a fully airgapped machine with no network access.

Answer 3

I would like to point that this approach is potentially flawed.

Specifically, the question mentions "Zero-day prevention". But the hypothetical program that does what is described in the question could itself have one or more zero day vulnerabilities.

Its implementation of encryption could be broken, thus decreasing difficulty of revealing plaintext files. It is your program that will ask you to enter the password. The hypothetical malware will have access to raw data on the drive (with restrictions imposed on the user account under which it will run) and it could attempt decrypting them using whatever approach it likes regardless of how your program prefers to decrypt them. If the encryption was indeed broken, then the existence of the password and the fact that your program asks you to enter it will be irrelevant.

The attacker could try to steal the files and attempt brute force attack offline using powerful systems, but this gets into model treat domain (does it worth the effort?), which was already pointed out by some commenters.

That being said, even if there is such a program, depending on how paranoid one is, there are still things to worry about.

Answer 4

Wouldn't you be able to create a visual studio plugin/extension that simply encrypts your project folder with a password you specify. On file open/load it decrypts the file with password you enter to memory and sets the IDE text without touching the file itself, on save it simply encrypts and saves it?

So the file itself would be encrypted 100% of the time and only unencrypted in your IDE editor (ofc the automatic backup files etc would need to be handled also).