1

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.

Improve this question
4
  • 1
    This wasn't mentioned yet: protecting your MBR/GPT against overwriting is a good approach to protect against ransomware. There is for example a tool (in reality a driver) developed called MBRFilter (for Windows only AFAIK) – Sir Muffington Nov 11 '19 at 19:14
  • But this is made in the OS level, which is probably not what you want. You could do the same thing on the BIOS I guess. Hey, maybe even a hardware hack? – Sir Muffington Nov 11 '19 at 19:20
  • @SirMuffington a 'hardware hack' was my 'last resort' thinking, given the answer, maybe there is a need for investigating it.. Ideas welcome. – Pogrindis Nov 11 '19 at 21:43
  • I added an answer which expands upon my comment – Sir Muffington Nov 14 '19 at 11:30
4
+50

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...

Improve this answer
4
  • This. Absolutly this, thank you for laying out how its not easy to identify, even on the HW level, especially on the HW level, and for also highlighting how creative these attacks have become already. +1 – Pogrindis Nov 11 '19 at 21:24
  • Curious though, and maybe this goes to a chat discussion, but any thoughts on another way to identify? I can't believe that there is no way to detect the pattern of attack.. – Pogrindis Nov 11 '19 at 21:31
  • @Pogrindis You can detect one or more patterns, but never all, and never with complete certainty. If your tool is popular, then new malware will be written with a different pattern that is even harder to detect. – jpaugh Nov 11 '19 at 23:52
  • Malware authors have time and capability for installing the majority of tools and modifying their code to disable or bypass all of them. APT attacks are fine tuned to the environment they are attacking, so they surely know what your defenses are, down to the version number. Don't count on it. They cannot easily delete an offsite backup, they can easily bypass your defenses. – ThoriumBR Nov 12 '19 at 14:57
4

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.

Improve this answer
2
  • This was the kind of answer I would expect from your first, thank you. I think It might be useful for mitigation ideas later for me and others. – Pogrindis Nov 11 '19 at 21:26
  • Sorry - Your edits are much better too, its a great point about dormant malware. – Pogrindis Nov 11 '19 at 21:29
1

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

Improve this answer
0

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.

Improve this answer
5
  • This doesnt really address the question though .. Why is it a naieve approach ? – Pogrindis Nov 11 '19 at 10:45
  • I am curious too. Naive insinuates that the approaches have some obvious flaw to go along with their intuitive nature. Honeypots, overall file entropy, and unexpected high IO outside of a normal baseline, seem like good triggers to me for a manual review. Versioning filesystems I'd be worried about though, as that assumes ransomware can't wipe or clear out the versioning (shadow copies are known targets of ransomware for example). – Jarrod Christman Nov 11 '19 at 14:22
  • 1
    Calculate the entropy will take so much CPU and IO that the user will not like it any bit. False positive rate will be high for some workloads too. – ThoriumBR Nov 11 '19 at 19:57
  • @ThoriumBR what if it was at the hardward level in a make believe world, we had something like a plc on the R/W ? - Something we don't have now – Pogrindis Nov 11 '19 at 21:27
  • 1
    We do have backups now, they work against ransomware, against data corruption, user error, fire ants, meteor strike, so let's use what we have. – ThoriumBR Nov 12 '19 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.