Could ransomware be stalled while encrypting?

Question

I have been reading about ransomware, and I was wondering if it could be defended against by having certain "trap" files on a drive. Sometimes I look through Code Golf and am thoroughly impressed by some of the solutions posted, some of which I wouldn't think are possible.

So I wondered: Is there a way to have ransomware's encryption process get hung up by specially created files (not just exceedingly large files)?

Could a file be created that, when encryption was attempted, would send the encryption process into an infinite loop, or at least one that might take a long time to complete? Maybe a monitoring program that is able to begin creating dummy files, while at the same time deleting encrypted dummy files as they are encrypted, so that the encrypting process is led down an endless path?

Of course the idea here is to stall the encryption process midway. Or, perhaps, could accessing the special file cause the computer to enter some form of "safe mode" that halts current processes?

(Note: this would obviously be a last-line-of-defense strategy, certainly not something that one would ever want to rely on for security, but an extra measure in case more proper measures all fail)

Answer 1

Your suggestion is interesting; unfortunately a generic solution is not possible as there is no combination of bits that would cause an encryption algorithm to "stall". Encryption is just math, after all. Perhaps use of a rootkit could trick ransomware into believing that it's encrypting a fake yottabyte-long dummy file handle, or it could have delays built in that hand out the bytes from the file very very slowly, but those kind of approaches are likely to impact normal usage of the computer as well.

There might be specific versions of ransomware that have implementation bugs that you could somehow exploit to make this happen, but that approach has numerous problems. Malware authors and script kiddies evolve and change ransomware programs all the time, so depending on a bug in today's version is no assurance that you'll be infected by the same version of ransomware tomorrow. And there are hundreds or thousands of different ransomware programs out there today; no exploitable flaw is going to be present in all of them.

@HameJames approach is one way of attempting to detect ransomware in action, but there's no guarantee that his trap file will be the first file encrypted by the malware and will shut it down in time, or if it's the last file and the shutdown just makes it worse.

Your best defense at this point is still operational security. Make regular backups of important files and keep them offline. Don't open unexpected email attachments, or click on phishing links. Keep your security software up to date, and your systems patched. All the normal advice still applies.

Answer 2

You could create a watchdog that creates a fake file, C:/A, and looks for changes in it. As soon as a change is detected, shut down the computer immediately. That's most likely the safest.

Answer 3

Encryption can be stopped in certain situations: e.g. if ransomware uses common libraries like CryptoAPI and one can hook their core functions and check the caller. However, this is not a safe approach to fighting ransomware, because, for example, many ransomware variants can embed encryption algorithms in their code or even not use encryption at all.

Using special or trap files is not a safe approach either, because when the trap catches something, it might be too late, or it might be a false positive if there are legit apps (like backup solutions, archiving, synch or even legit encryption solutions) which operate on all files in a volume or multiple folders. Things can get even more complicated if we think about ransomware which doesn't encrypt all the files or don't process all folders.

A solution is to use behavior analysis which tracks and correlates several items including processes, file activity, and other changes. Products which follow this approach can detect and block ransomware with good accuracy, but they usually trigger the alert only after several files (usually at least tens) have been encrypted already. The best solutions can even give those files back.

Answer 4

One way you could do this is to create a sparse file. A sparse file is a file that contains large sections of zeros, which are stored in the filesystem as just a metadata describing how large the zero section is. A sparse file allows you to create a file that appears to be very large, but actually takes little space on disk.

When an encryption program tries to encrypt this file, it is likely to try to read the file from start to finish, encrypting all the zeros. At one point, either the system will run out of memory or you'll run out of disk space, and whatever the ransomware hadn't encrypted up to that point, could potentially be salvaged if the ransomware crashes at that point and doesn't try to delete the trap file and resume on next file. Weakness is, of course, that you'd likely run out of disk and memory space, which could crash other processes as well. You could end up with corrupted files if there's any buggy database system in your computer. It also doesn't all files, as this mechanism would only be tripped after the ransomware encounters this file.

You could increase the chance of the trap file being the first file, by reading on your filesystem's source code, and researching what it needs to make the trap file more likely to be one of the first returned by readdir(). For example, if your filesystem return readdir() by order of file creation, you'd want it to be first file that's created, if it returns the files alphabetically, you'd want to add many "A" to the filename, or if it hashes the filename, you'd want to make sure the hashed filename contains lots of zeros.

Answer 5

You could have a monitoring process that watches certain "canary" files, or even just tried to monitor overall file activity to detect ransomware; but the problem is you don't control what and in what order the ransomware encrypts, and by the time it ate one of your canaries, you might be in deep anyway.