Skip to content ↓ | Skip to navigation ↓

We are familiar with the problem of ransomware – malicious software that seeks to encrypt user data and demand a ransom in return for the decryption key.

There are several defensive measures that help work against crypto-malware. Backups work, in theory, but are not always available or are partial. We need to realize that ransomware does, and will, continue to find victims.

These victims are not eCrime or DefCon or BSides conference attendees. Mostly, these are average computer users. In the past, ransomware developers and operators have gone for the low-hanging fruit – victims who fall for common phishing scams, expose RDP services with poor passwords, neglect security updates, etc. Targeted ransomware is now seeking bigger victims as seen in the case of the City of Atlanta.

In our paper, we assume that crypto-malware has the infiltrated host. What can be done from this point forward as a corrective measure for victims? Can we get files back without paying the ransom? Here, we realized that not every ransomware is the same. Some can be broken due to their poor cryptosystems. But which ones? We need a classification system.

How do we classify? Enter key management.

Key management is crucial for a ransomware operation. A fundamental constraint on ransomware is that the ransomware operator needs to be the sole possessor of the decryption key until the ransom is paid. Errors in key management lead to key leakage, which neutralizes the leveraging power of the attacker and hence neutralizes the ransomware campaign.

After looking at several samples, we realized that many ransomware developers are not sophisticated coders – they frequently resort to cargo-cult programming or “copy-pasting.”

Our paper discusses several key management models that we observed being deployed in crypto-malware. For example, no key or no encryption is where we observed the ransomware to be a fake scareware that does not really encrypt anything. Single encryption is when an asymmetric public key is used to encrypt user files. However, RSA public keys are not meant for bulk data encryption, and this is slow.

But by far the most common model is the hybrid key cryptosystem – a system where attackers use a combination of symmetric and asymmetric key encryption. In the hybrid cryptosystem, crypto-malware use an attack vector (such as phishing) to infiltrate the host. It then generates a unique symmetric encryption key and encrypts this encryption key with the attacker’s public key such that only the attacker can now decrypt this key.

The attacker is provided a copy of the key, and encryption commences. A symmetric key is purged from the host, making the attacker the sole possessor of the decryption key. The last step is to demand ransom. There are, of course, minor variations of this approach.

So, we now that we understand several key management models deployed in ransomware, can we use them to categorize ransomware? Why categorize in the first place?

Crypto-malware is different. There is a clear need for systemization of knowledge regarding their cryptosystems and sophistication. Users especially do not comprehend the level of threat they are facing after being infected with a particular ransomware variant. Consider CVSS for vulnerabilities. It exists to convey the severity of a flaw on a simple scale of 1 to 10.

Are ransomware getting more sophisticated over time? How do we study this?

Again, victims need to understand the risk they are facing. Maybe the ransomware is lying to them and has not really encrypted anything. Maybe the cryptosystem was not implemented correctly causing key leakage, or maybe paying the ransom is the only way to decrypt files.

We envision a community-powered database that people can query when they are hit. This database will also provide insights into the general trend of change in sophistication in ransomware over time.

What does one see when they query the database?

One of the six proposed categories that is associated with the variant affects them. A variant can be identified using ID-ransomware. Any one of the several conditions pertinent to a category is enough for a ransomware to belong in that category. Ransomware can change categories over time. The intricacies of the categories and the conditions can be read in our paper.

We primarily noted the following observations after crypto-malware classification: weak variants continue to appear as late as 2018. The ransomware variants that are actually potent and effective will make the news and cause victims of even ineffective ransomware to pay the ransom.

In summary, crypto-malware developers consistently introduce several design, operation and implementation flaws in their extortion attempts. Bad programming and bad cryptography in ransomware variants can be exploited to the victim’s advantage.

About the Authors:

Pranshu Bajpai is a security researcher working towards his PhD in Computer Science and Engineering at Michigan State University. His research interests lie in computer and network security, malware analysis, digital forensics and cyber crimes. He has been an active speaker at industry and academic conferences and spoken at IEEE APWG eCrime conference, DEF CON, GrrCon, BSides and others.

Aditya K Sood is a cyber security practitioner with an experience of more than 10 years. Dr. Sood has research interests in cloud security, malware secure software design and cyber security. His work has been featured in several media outlets including AP, Fox News, The Register, Guardian, CBC and others. He has been an active speaker at industry conferences and presented at BlackHat, DEFCON, HITB, RSA, Virus Bulletin, OWASP and many others.

Richard Enbody has been a professor at Michigan State University since 1987 in the Department of Computer Science & Engineering in the College of Engineering. His current research is in cyber security, especially how hackers hack and how to defend against them with interest in ransomware, cryptojacking and automotive vulnerabilities.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.