Researchers Develop A Way To Stop Ransomware By Watching The Filesystem (phys.org)

An anonymous reader quotes a report from Phys.Org: Ransomware -- what hackers use to encrypt your computer files and demand money in exchange for freeing those contents -- is an exploding global problem with few solutions, but a team of University of Florida researchers says it has developed a way to stop it dead in its tracks. The answer, they say, lies not in keeping it out of a computer but rather in confronting it once it's there and, counterintuitively, actually letting it lock up a few files before clamping down on it. "Our system is more of an early-warning system. It doesn't prevent the ransomware from starting [...] it prevents the ransomware from completing its task [...] so you lose only a couple of pictures or a couple of documents rather than everything that's on your hard drive, and it relieves you of the burden of having to pay the ransom," said Nolen Scaife, a UF doctoral student and founding member of UF's Florida Institute for Cybersecurity Research. Scaife is part of the team that has come up with the ransomware solution, which it calls CryptoDrop. "Antivirus software is successful at stopping them when it recognizes ransomware malware, but therein lies the problem," reports Phys.Org. "'These attacks are tailored and unique every time they get installed on someone's system,' Scaife said. 'Antivirus is really good at stopping things it's seen before [...] That's where our solution is better than traditional anti-viruses. If something that's benign starts to behave maliciously, then what we can do is take action against that based on what we see is happening to your data. So we can stop, for example, all of your pictures from being encrypted.' The results, they said, were impressive. 'We ran our detector against several hundred ransomware samples that were live,' Scaife said, 'and in those case it detected 100 percent of those malware samples and it did so after only a median of 10 files were encrypted.'" The University of Florida uploaded a video briefly explaining its software.

Comments

Hey, you can do this too

[sonamchauhan]

1. Your main computer (call it 'right brain') automatically takes a 'VM snapshot' of itself at a point in time.
2. Another computer ('left brain') inspects the VM to check if data files are still accessible
3. If not, left brain 'diffs' the VM with previous 'known-good' VMs to find the source of the problem
4. Swap VMs
5. profit!

Re:Hey, you can do this too

[greenfruitsalad]

ok, 2 years ago (when i first heard about ransomware) i wrote a nagios plugin that through inotify watched for activity on dummy files automatically placed around my directory trees. with that, nagios also watched for out of hours IO load. it had watched for processes hogging io/cpu during the day, i just made it more sensitive at night. plus, i have hourly filesystem snapshots.

i then tested it with whatever trojan came in my email on a windows7 pc with a samba volume mounted. it detected it straight away.

this really is a ms windows only problem. any bsd/linux admin has so many tools of protection available that it's virtually a non-issue for us.

Heuristics

[The MAZZTer]

Scaife said. 'Antivirus is really good at stopping things it's seen before [...] That's where our solution is better than traditional anti-viruses. If something that's benign starts to behave maliciously, then what we can do is take action against that based on what we see is happening to your data.

That's called "heuristics" and AV has been doing that for quite a while now. And attackers will work around this system the same way they work around heuristics... if your system is freely available, they can download and test their ransomware against it until they can escape notice.

Nice try, but with 3 potential problems

[guardiangod]

The software detects the behavior of an application. The detection is probably like 'if a process accesses each image file (OpenFile/CreateFile) , read it, create a new file with "same_name+.encrypted", then delete the original image file.' x 10 times, then that process is likely guilty.

1. What happens if the malware instead use MapFileView and 10 others potential Win32/kernel32 APIs combination? This quickly become a arms race and is going to be terrible in terms of system overhead, not to mention the time gap between a new method appearing and the detection software catching it.

2. What about Windows' internal processes that, for example, shadow copy the file? Would the detection software catches it? What about false detection of, say, the disk defragmentation software?

3. Since the system is already compromised, what stops the malware from detecting the countermeasure and just delete all the files in the system straight out? If that's too obvious, then how about write a random byte per x bytes offset to all files? Even if you killed the malware process, you can't be sure that there no other malware running on the system that can go into revenge mode.

Re:Nice try, but with 3 potential problems

[CanadianMacFan]

I hope if I run an application to convert a bunch of music files from one format to another then their program isn't going to be set off.

Re:Nice try, but with 3 potential problems

[Rei]

The team isn't very explicit on what they're doing. But if they're doing it in a reasonable manner, it's probably not that naive, as to only look for "sequentially read, encrypt, write, delete" patterns. I think it's more fundamental. No matter what pattern it uses, a piece of ransomware has to fundamentally do the following.

1) Read the data. So, for each block that there's actual reads of, flag it.
2) Write data, somewhere, somehow. Can be to a disk, card, even over the net. Writes to disk might be to new files, archives, overwrites, etc. Even if compression is used, the writes have to be a relevant fraction of the size of the data read in.
3) Somehow invalidate the original block. There are different approaches one can use to invalidate data, and all of them need to be covered.

The key factors are #1 and #3. A process that just reads blocks isn't a problem. A process that just invalidates original blocks isn't a problem (that can't be ransomware, only deletion... and you can't get a ransom for files that are outright gone). But a process that reads and then later writes over blocks may or may not be a problem. We can divide this down into different scenarios.

1) Processes that only slowly, randomly, modify things that they've read, only on a limited number of files. These are most likely not a problem.
2) Processes that do read and write over a large amount of files, but always - in some recoverable form or another - keep an understandable copy of the file around (for example, writing the same file out elsewhere). These are not a problem.
3) Processes that modify vast numbers of things, without keeping a recoverable copy on hand. Particularly processes that do it quickly. Particularly processes that do it to files that aren't modified frequently. These are most likely a problem.

There is some level of nuance and heuristics involved here, of course. And another nuance is that this clearly has to be done at the system level, something dug into the operating system everywhere reads and writes are done. It probably needs to modify a number of pieces of system functionality as well to make sure that they don't do anything weird that might unintentionally trigger the heuristics. It might also be wise to break down the file system into monitored and unmonitored segments, where the unmonitored sections are where OS files, temp files, etc tend to be stored, while the monitored sections tend to be user files.

But the key issue is that - if they're doing this right - they're looking at the fundamental things that ransomware has to do - in particular, reading data blocks, then trying to leave then unrecoverable at some point afterward. The protection software should not interfere when a program reads, but when it tries to invalidate things that it's read - in a manner that triggers the "this is excessive, strange, suspicious behavior" heuristics - then it suspends the application. Because, say, the overwrite behavior of a person using MS Word or Photoshop doesn't look at all like when ransomware does it - no matter what "pattern" they use for their encoding. They could mimic the overwrite behavior of programs like that to avoid the heuristic.... but then it'll take them weeks, months, or even years to get through all of the files on a person's computer, and they'll get caught long before that.

Re:Meh

[freeze128]

That exists?!?! Heck, I thought protecting the MBR was a problem that was solved DECADES AGO.

What would really help

[Anonymous Coward]

...is if a few of these ransomware authors/operators started turning up dead.

Seriously.

Versioning Filesystems

[Phydeaux314]

The real solution, of course, is a proper versioning filesystem with a regularly scheduled snapshot - say, once a week, or once a day if you're extra paranoid. You can even cycle the snapshots if you want to cut disk usage down.

Tripwire

[Scutter]

Tripwire (and tripwire-like software such as bit9/Carbon Black) has been a thing for years. What's different about this approach?

Re:Better yet

[vux984]

Just have your files backed up on another computer at your house, on a NAS, or online.

Bingo.

If you get ransomware then just nuke the computer and restore everything from your backup.

double bingo.

I wouldn't suggest backing up to a hard drive connected directly to the computer because the ransomware will also encrypt those files too.

Yes... but that's not nearly going far enough. The vast majority of 'simple' backup systems fail hard on ransomware; especially the roll-your-own sort often advocated here.

cloud sync, torrent sync, etc. Fail. So you've got 3 redundant storage sites; The encrypted files get synchronized and overwrite the backups; and you've got nothing.

rsync, or any thing to an offsite or local nas/server/whatever = fail. same reason. double fail if the local system mounts the drives on the remote system as part of the procedure giving the ransomware direct access to the remote filesystem.

Essentially any backup solution that cannot easily and reliably restore to a given point in time, including deleted files is a hard fail vs ransomware.

You need continuous ongoing incremental backups via an agent/daemon/service on a remote system. Its certainly possible to set something like this up and manage it yourself, but its not simple.

Honestly for personal / home / small businesses stuff like carbonite and crashplan and spideroak are probably your best line of defense vs ransomware.

That's not to say having torrent sync setup with 3 offsite systems is a bad idea. Its a fine idea for all sorts of disaster scenarios; and is probably quicker to recover from in the event of a system failure. Its just not much defense against ransomware.

For that you really need continual incremental backups.

Re:FBI

[JustAnotherOldGuy]

Did you happen to find a sale on asterisks or something?