Microsoft Could Fix Ransomware Tomorrow

vtqhtr413

Level 27
Thread author
Verified
Top Poster
Well-known
Forum Veteran
Aug 17, 2017
1,280
17,222
2,568
Ransomware works by going through files, one by one, and replacing their content with an encrypted version. (Sometimes it also sends copies elsewhere, but that turns out to be slow, and sometimes sets off alarms.) Software on Microsoft Windows uses an application programming interface (API) called "CreateFile" to access files. Somewhat confusingly, CreateFile not only creates files but is also the primary way to open them.

Microsoft should rate-limit the CreateFile() API. That is to say, it should limit how often a given program can use the API. Because you can't encrypt a file until you can open it, this would have a dramatic impact on ransomware. It would slow it down, and help defensive tools catch it in time for humans to react. Now, I say Microsoft should do this, and I hope it does.

The first question is, what rate is reasonable? Pick low and you break applications; pick high and you lessen the protective value. For a lot of cases, one open per second seems fine, but when we get to things like compilers, which are going to open a lot of files, we see that we may need both a general limit and allow bursts. When we get to backup software, it gets even more complicated. The backup software needs to open all the files, or at least all the changed files, which, if you think about it, is really similar to what ransomware wants to do. We can't allow an exception for read-only opens. The ransomware will open a file, encrypt the contents, write it to a new file or append it to a database, and delete the original.
 
Implementing rate-limiting for the CreateFile API in Microsoft Windows could indeed be a potential solution to slow down the impact of ransomware attacks. However, finding the right balance between limiting the API's usage and maintaining compatibility with legitimate applications, like compilers and backup software, poses challenges. Determining an appropriate rate and considering exceptions for certain file operations would require careful consideration. Nonetheless, such rate-limiting measures could help impede ransomware's ability to encrypt files rapidly.
 
Ransomware has many types. Some has delayed action i.e. encrypt slowly without alarming behaviour detection, some only modifies a few bytes of the file without changing the file name, some don't encrypt etc. And ransomware don't just encrypt those files you want them to encrypt (i.e. monitored and protected), they also encrypt files which are not monitored and not protected. The latter files cannot be restored since they are not monitored and not protected by MS/3rd-party software

I still find files backup/restore not so useful as compared to a system backup/restore due to the aforementioned reason.
 
Last edited:
Ransomware has many types. Some has delayed action i.e. encrypt slowly without alarming behaviour detection, some only modifies a few bytes of the file without changing the file name etc. And ransomware don't just encrypt those files you want them to encrypt (i.e. monitored and protected), they also encrypt files which are not monitored and not protected. The latter files cannot be restored since they are not monitored and not protected by MS/3rd-party software

I still find files backup/restore not so useful as compared to a system backup/restore due to the aforementioned reason.
And then there are disk wipers 🥳