Lastline Labs’ Engin Kirda now describes the encryption, deletion and locking mechanisms leveraged by ransomware and also focuses on mitigation techniques.
So what are the attack payloads? Encryption, of course, is a popular thing. About 5% of the samples that we actually looked at were using some sort of encryption. It’s generally well-known that older samples used to implement this encryption themselves, so basically the malware authors decided that they wanted to implement this. So there is custom encryption, which actually leads to mistakes. There have been many reports where you actually look at the encryption, it’s actually not implemented well, or the attackers make mistakes like leaving keys on disk. And you can actually use these things to decrypt the data. This is something that used to happen quite a bit in the past. It was not perfect.Recently we have seen more samples that actually use standard libraries (see right-hand image). Current popular families like Crypt0l0cker and Cryptowall use the Windows crypto libraries. These are standard libraries, and they are being used because they are standard libraries. They do the crypto, they do the software engineering, so if something is encrypted with them, of course it’s difficult to decrypt it, especially if you don’t have the key.
The question, though, is whether this is sophistication or just good software engineering. Every good software engineer knows that you don’t implement encryption algorithms yourself. You use things that other people have implemented and verified. So this is actually good software engineering. The fact that they are using standard libraries is good practice. It just makes their product more stable, but it’s not that sophisticated in the sense that they are using standard libraries.
Using strong crypto libraries is actually a double-edged sword for the attackers. On the one hand, they can actually create damage that’s irreversible, that’s tough for us. But at the same time, if you are doing dynamic analysis, if you are looking at this piece of code before it reaches the end users, it gives you the chance to catch certain things such as the use of these libraries. So if you see that something suspicious is using crypto libraries, maybe you can actually use that against that sample, and you’ll know that you are potentially dealing with a ransomware sample.What are the deletion mechanisms? About 36% of the five most common ransomware families in the data set were deleting files (see right-hand image). If you didn’t pay up, the files were actually being deleted. Most of the deletion, in fact, was quite straightforward. How would a professional person do this? They would actually aim to wipe the disk so that it’s difficult to recover the data. You would write over the disk, you would wipe that file off the disk. But most of them were, of course, lazy, and they were directly working on the Master File Table entries and marking things as deleted, but the data was still remaining on disk.
So yes, it was deleted, but you had the potential and the possibility of recovering the data in some of these samples, because it wasn’t actually completely corrupted. So recovery was actually possible in many cases. Just because you are hit by ransomware doesn’t mean that you cannot recover the data. In some cases, if it’s a simpler variant you might be able to recover the data, too.
But at the same time, this use of MFT could be an effective venue for detecting ransomware during analysis. If you see that a lot of MFT activity is being done, maybe bulk deletions are being performed during the analysis that might give you the chance to say, hey, this looks suspicious, benign software wouldn’t typically do this. Combining it with other things that you see maybe would give you the possibility of detecting ransomware more effectively.Many samples, of course, also lock the desktop (see right-hand image). That’s another classic ransomware behavior. Rather than deleting things, rather than encrypting them, in the course of a simple attack you basically lock the desktop and you keep the users out of the desktop. This is classic ransomware behavior. More than 60% of the samples that we looked at – if you think of this historically, this was a very popular thing in the past – use things like CreateDesktop to create a persistent new desktop, and you just lock the user out of the machine. And because the end user is not very technically sophisticated, they think they can’t recover the data. But in reality, the data is still there. So you do have a chance to recover the data.
Another approach is to display HTML pages and disable certain components so that it’s actually difficult for the user to get rid of that. Again, they are locked and they can’t access their machines. In all cases, though, a message was displayed to the victim. So remember the ransom notes that I showed at the beginning. If you think about it, they have very similar messages. These messages are quite similar, so we should be able to do some sort of analysis as well to be able to detect these types of attacks, especially if something is locking the desktop and displaying it. In a way, it’s not that complicated also from a defense point of view, because there are things we can do automatically to be able to detect this type of an attack.
Locking mechanisms are also typically a nuisance, but the data is typically not harmed. So the data is still there, and if you are a more technically sophisticated user you can basically unlock your desktop without paying up. Of course, what you are seeing is that if there are simple things, the attackers take the simple route because you still make the money, you don’t have to be super-complicated. This is something that we also see in other types of malware, not just in ransomware. They take the easiest path.
What about better mitigation, though? Can we actually do things to mitigate this threat in a better way? The Achilles’ heel of ransomware, actually, is that the ransomware has to inform the victim that the attack has taken place. This is actually quite unique to ransomware, and this is something that you don’t see in other types of malware. If you look at nasty malware, they try to remain hidden, they try to remain stealthy. They might inject themselves into other processes, because if you do a “ps” you wouldn’t see it running, right? They try to hide the activity. And they try to remain hidden over longer periods of time as they are doing bad, malicious activity in the background.Compared to that, ransomware gives us the advantage by actually informing us, right? So it tells us “Hey, you’ve been attacked, I’ve just encrypted all of your files.” So from a defense point of view, if you are analyzing something before it reaches the end users, it gives you that advantage (see right-hand image), it tells you “I am bad and I’ve actually infected you.” So this behavior is actually inherent in ransomware’s nature, this is something that is difficult to change because this is how money is made with ransomware.
There are certain behaviors that are predictable, things like entropy changes. When you are actually encrypting a file, the entropy of that file changes, which is one way that you can detect that the file has been encrypted. Or if a modal dialog is displayed and there is some background activity at the same time, this is something that you can use to detect suspicious ransomware-like behavior.
Or accessing “honey” files – what if you are doing dynamic analysis and you put these files that look like interesting files, but you have created them and suddenly you see that they are being touched and their entropy has changed, so somebody is encrypting them? This is behavior that you would not see in a benign sample, but this is something that ransomware would do. So behaviors, actually, should be predictable and it should be detectable. We should be doing a better job in dynamic analysis systems in catching things like that.Let’s look at an example (see right-hand image). If you look at Cryptolocker and you run it in a dynamic analysis environment, the types of behavior you would see would be things like the autostart is modified. Why? Because the attacker is trying to make this persistent. Every time you reboot, the same things is displayed. You would see things like memory activities, you would see network activities. So all sorts of things you would also see in other malware samples would be displayed typically by ransomware, too.
But one thing that you would see, potentially, would be evasion attempts. They might be checking for specific image filenames, or they might be checking for certain module names that typically get automatically loaded into sandboxes. Or they might look for certain indications that the code is running in a sandbox to be able to detect this. So yes, evasion is a possibility, and this is what we actually often say is complexity, but this is not unique to ransomware.
What is unique to ransomware is that you might see file activity, so you might see that this thing is searching for files across mounted drives. Or you might see that it’s iterating over directories. So you run it, there is some evasion, but at the same time it’s doing ransomware-like things, because it’s trying to encrypt all the files – very suspicious.If you look at the report, other things you might be able to see would be loaded libraries (see right-hand image). You see a bunch of libraries that are loaded: there are standard ones, there are kernel operations. But one thing that actually pops up is that it’s using cryptbase.dll. And what is that? That is actually Microsoft’s base cryptographic API DLL. This by itself doesn’t actually tell you that you are dealing with a malicious sample, because benign software could also use this. But when you start combining these behaviors – you have cryptography usage, you have something that’s actually searching over many files, in some cases it might be displaying something and doing this in the background – we should actually be doing a good job detecting these things, and these behaviors are not too complex. These are actually things that we should be able to catch. So the key takeaways (see right-hand image). Again, the majority of ransomware actually launches relatively straightforward attack payloads. If you look at the attack that is taking place, yes, encryption happens and the encryption might be good. But if you are doing some analysis, maybe at a gateway or something, before this thing actually hits the users, you should be able to catch things like the use of standard cryptography libraries. And even after the infection, in some cases, bad crypto is used, there are many examples of that; or things like files are deleted but they are not wiped off disk.
So, again, typically malware authors take the easiest path and they don’t always put a lot of complexity into whatever they create. So it’s not always Stuxnet that we’re talking about that actually shows a lot of real complexity.
Compared to other types of malware that tries to remain stealthy and in the background, ransomware actually has very distinct, predictable behavior. It does these things, and we know that it does these things – things like ransom notes with background behavior. So you might be able to do OCR and look at these images automatically, trying to extract certain words, and then use them during your detection phase to detect malicious code like ransomware. Or the changes of the entropy of files – this is actually difficult to hide. So if you see that happening you know that the file is being encrypted, right? Things like that should give you indication that should allow you to catch ransomware with better technology. These could also be things like the iteration over large numbers of files.
Thanks so much!