Ransomware aversion and identification techniques

Question

I don't think there's a need to go into the background here, but identification of the process may be better explored.

From a developer pov, at a high level, the files are modified, by virtue of the attack and attacker, they are modified quickly. This is an I/O operation. If I wrote a service that would monitor the IO on my machine for a large bump (configurable, process aware etc but thats implementation) could I not easily identify that; something weird is going on and shut down I/O ops for that period.

I do understand the implications of having low lvl HW control from a service/application, but lets say its a unicorn.

Is this the fastest response to 0days which wont be picked up ? To write for the HW level ? Or are there other factors involved ?

I know retail machines, even enterprise deskptops would not fly, but datacenter lvl, where backup corruption would be catastrophic would surely see some value.

Thoughts welcome.

// EDIT

The initial idea was to write for the firmware level, then maybe the bios, maybe even if advanced options of SSD's for example, I don't mean a service that will sit in the OS, as close as possible to the the HW lvl, hopefully self container like a PLC .. Well better.

// Edit 2 Comment @sir-muffington

This wasn't mentioned yet: protecting your MBR/GPT against overwriting is a good approach to protect against ransomware.

Answer 1

Detection? Don't count on it.

Watching for changed files may not help. Some malware families reads the file in memory, encrypts it and writes a new file, and deletes the original. This will not trip a "lots of modified files" trigger.

Other will encrypt files in small batches, so there are no spike on disk activity or CPU usage and the user will not suspect anything (user is on Netflix after all) and the threshold would not be breached.

Some malware will schedule to start on next boot, before logon, mimicking a Windows Update process. It will kill every other process, so your defense arsenal would be dead before the encryption started.

Mitigation?

Backup. Offsite incremental backups (and I cannot stress Offsite with enough emphasis). A backup routine that does not direct access the backup storage is needed. If your backup tool just mounts a remote folder and copies files to it, so does the malware. If you have a service that receives files and metadata, and archives it, malware cannot easily delete all your backups.

Hourly if you can, twice a day if you cannot.

Sooner or later you will be infected, and if your backup destination is a mounted network drive, you backup is toast. It's not a matter of if, it's a matter of when, so backup is the only really safe mitigation possible.

You can have firewalls, antivirus, antimalware, mail scanners, honeypots, detection agents, you can have everything. Unless you have solid, tested and proven backup process, you will lose some files. It's a kind of game that you must win every single time, the attacker must win just once, and there are dozens of duels every day. You cannot win.

With backups, when you lose, you just load the quicksave...

Answer 2

The best mitigation against ransomware that has gotten onto your network isn't to stop it as quickly as possible, it's to already have backups.

The first step is to identify the vector and contain all of the potential malware, not just the ransomware.

Until you can rule out additional payloads, you do not want your users on the network where they can potentially be infected. If the user machines get infected, they can re-infect the servers more easily than an outside source, so you want to isolate them.

This means that the files on your server will be unavailable to your users, whether the files had been maliciously encrypted or not. It doesn't matter how quickly you stop the encryption: Once you have confirmed the vector and contained the malware, you should be taking off and nuking the entire site from orbit reformatting the disks and restoring from backups; it's the only way to be sure.

For many businesses, this means a couple of days where the office workers will be sitting idle while the servers are being rebuilt, but it's a much better option than having an undetected back door where attackers are able to get your business's sensitive information.

Watching I/O can help detect a ransomware attack, in addition to other ways, but in general, be wary of any tool that automatically stops I/O based on unusual usage, as it could create false positives, frustrating users who will seek other (less secure) ways to move a large number of files if they can't do so with the servers in the network.

Answer 3

To expand upon my comment:

Since popular ransomware like Petya after a reboot replace the MBR (Master Boot Record/ GPT (GUID Partition Table) with malicious code and only then encrypts the MFT (Master File Table, Windows-specific) it would a viable way to go (please keep in mind that not every ransomware encrypts the MFT).

To protect yourself against overwriting you could make a backup of your current MBR using dd if=/dev/sda of=backup-sda.mbr count=1 bs=512, GPT using dd if=/dev/sda of=backup-sda.mbr count=1 bs=2048 , restoring it in case of malware/malicious users.

In case you have custom/multiple partitions you can use sgdisk -p /dev/sda or sfdisk -d /dev/sda to print out the partition information for you to use in dd. Alternatively you can use the sgdisk or it's GUI counterpart gdisk for backing up your partition.

NTFS also supports adding read-only to certain partitions. Use following commands:

diskpart
list disk
select disk <disk number here>
list partition
select partition <partition number here>
attributes disk set readonly

So does ext4 with a recent kernel version:

tune2fs -O read-only ext4test

You remove NTFS Write protection with attributes disk clear readonly

You remove ext4 write protection with tune2fs -O ^read-only ext4test

Heck, you could theoretically even write a custom UEFI/BIOS to detect a high I/O, detecting not only thresholds but also certain regions, which would not be written by legit software such as updating software.

You could also dedicate your system files to one drive and make that drive read-only. But it's all software magic.

For some hardware protection you would need a pay quite a buck to get this proposed hardware. There are write-protectors used in forensics, used to connect a hard drive to a PC which guarantee that not a single byte on the evidence would get modified. As well the whole drive would be read-only. So financially this is something unplausible for you.

P.S You may find these Patents interesting:

https://patents.google.com/patent/US5268960A/en

https://patents.google.com/patent/US6813682B2/en

https://patents.google.com/patent/US8495432B2/en

Answer 4

This is a common naieve approach used in COTS anti ransomware protection products.

Other basic approaches include calculating the entropy of files, caching file writes, Honeypot folders/files, and versioning filesystems.