Ransomware: When to pay (and when not to)
While most security professionals argue against paying the ransom, there are some cases where paying is the right choice for an organization. Learn what to consider, and how to decide.
Sheet of euros (source: geralt via Pixabay)
Pros and Cons of Paying the Ransom
Ask any security professional whether or not a victim should pay the ransom, and the answer will almost assuredly be a loud no. Unfortunately, as covered briefly in Chapter 1. Introduction to Ransomware, in the wake of a ransomware incident, the answer can be more complicated and may depend on the amount of advanced planning the organization has done.
Before diving any deeper into this topic, take a step back and remember what ransomware does. Almost all ransomware looks for certain files on the hard drive of the victim and then encrypts those files. Generally those files include things like Microsoft Office documents, PDFs, images, movies, music, and text files; each ransomware family has a slightly different set of files it chooses to encrypt. Some ransomware also looks for shared drives and proceeds to encrypt the same file types on those shared drives. The ransomware usually does not encrypt everything on the hard drive because then the computer would cease to function and the hacker group would not get their money. One notable exception to this is the Petya ransomware family, which overwrites the master boot record and encrypts the master file table, making the system nonfunctional.
Learn faster. Dig deeper. See farther.
In most cases, ransomware is designed to be nondestructive. This means that any computer hit by ransomware can easily be restored from backup. In fact, if the developers behind the ransomware don’t know what they are doing, ransomware can often be defeated by pulling the backup files out of the Volume Shadow Copy.
As long as an organization has a good backup system in place, with backup files stored offline and a well-tested restore process, even if the security team fails to detect a ransomware attack and a target machine is successfully infected, it is often easy to fix the mistake.
“Oh”
“Oh” is the expression that makes security teams who try to clean up ransomware infections cringe more than any other. “Oh” means one of two things: either there are no backups, or the backups have not been tested any time recently. It changes the nature of the conversation from, “No, of course you don’t pay the ransomware” to “Let’s see what our options are.”
Taking an honest assessment of the backup infrastructure in a network needs to be done prior to a ransomware infection, because if the assessment is done after the infection it is too late. The thing is, every security professional and network administrator reading this book understands that. They know that backup systems and endpoint processes should not only be closely monitored, but restores should be tested on a regular basis. Unfortunately, in a world where IT and security are often short staffed and always have more projects than they have time for, backups often get ignored.
Knowing What Is Actually Backed Up
Knowing what is being backed up is important as well. Many organizations only back up servers, leaving workstation users to fend for themselves. Of course, ransomware tends to target workstations. So, the group that is most often targeted by ransomware has the least amount of protection. Backing up every workstation in the network may not be feasible, but it is worth investigating whether or not there are key endpoints that should be part of the backup routine. While it may not be necessary to back up every workstation in the technical support group, backing up all laptops assigned to those in the executive suite could pay dividends later. It is also important to understand whether the organization is using versioning for backups. Versioning, versus incremental or differential backups, keeps multiple copies of a backed up file. The helps protect an organization during a ransomware attack, because if an encrypted file is backed up, there will still be an earlier version of the file to restore. While incremental and differential backups make better use of available storage, an organization is more likely to back up an encrypted file and replace the good copy.
Backups should also not be stored on shared drives that are easily accessible from workstations or servers on the network. Yes, having backups on shared drives makes it easier to quickly restore a file, but if a user can reach those files, so can the ransomware, and there are ransomware families, such as Stampado, that specifically target backup files. Most ransomware families have the ability to reach out to networked drives and encrypt the files on those drives as well. Backups should be isolated. Having restricted privileges is not enough, as some of the more advanced threat actors who have added ransomware to their arsenal are able to gain administrator access and will be able to encrypt the files on those connected backup drives.
Knowing Which Ransomware Family Infected the System
If there is no good backup, or the backup cannot be easily restored still the ransomware still doesn’t necessarily have to be paid, it just means there’s more digging to do. The next step is to determine which ransomware has infected the machine. Fortunately, most ransomware identifies itself, as shown in Figure 1-1.
There are actually a number of options at this point. As discussed, not all ransomware is created equal. Some hacker groups are better programmers than others; and thus, some ransomware is more effective than others. For example, a number of ransomware families don’t bother to encrypt the Windows Volume Shadow Copy. The Windows Volume Shadow Copy Service (VSS) is a continually updating snapshot of the system. It is not as robust as a full backup, but it does create a temporary backup of the system designed to retrieve files if they are accidentally deleted. If the ransomware does not encrypt the VSS, and the system has not been rebooted, then most of the files should be able to be restored.
Even if the ransomware does encrypt the VSS, there may be other options (e.g., there may be a decryptor for the ransomware). While there are a number of standard encryption libraries available for almost every language, not everyone knows how to implement them properly. While most hackers know how to program, they don’t all know how to program well. This means a number of malware families can be decrypted without the key. This is especially true for earlier versions of ransomware families. As with legitimate code, ransomware has flaws that get patched in subsequent versions. It is worth investigating to see if there is a decryptor built for the ransomware that has infected the system.
Warning
Warning About Decryptors
This should go without saying, but it is worth pointing out: only download decryptors from reliable and verified sources (usually security researchers or companies, such as the No More Ransom team or the teams at Trend Micro or Sophos). For example, the Kaspersky-led No More Ransom allows users to upload a sample encrypted file to determine if there is a decryptor available (remember not to upload sensitive files to these third-party services). There are many people out there who offer “decryptor programs” that are really just more malware.
If the ransomware is not poorly coded and does not have a poor implementation of the encryption library, the next question to ask is: how valuable is the data on the system? Many organizations have started moving business functions to the cloud, which means that more and more critical data is stored in a data center somewhere. If this is the case, then there is a good chance that there is no data critical to the organization on a workstation, since all critical data should exist in the cloud. Therefore, even though it may seem counterintuitive, there is a strong argument to be made that there is no benefit to paying the ransom and the system should just be reinstalled.
When to Pay the Ransom
But what if the infected system does have critical information on it? What if there are clients lists, payroll data, or tax information, for example, that needs to be recovered? What if the workstation is a critical system that controls a supervisory control and data acquisition (SCADA) system or a medical device? In cases like this, where there are no alternatives, such as contacting the vendor of the SCADA system or medical device to see if there are other options, or where it could be a life-and-death situation, pay the ransom. Then after paying the ransom, make sure key data is backed up, and then wipe and reinstall the system.
Note
Security Is Not the Only Consideration
In a perfect world, all business decisions would be made with security in mind. But that is not how the world works. In the event of a ransomware attack, an organization may find it expedient to pay the ransom even if there are ways to restore the system. For example, if the ransom is $10,000, but the cost to the restore the system from backup and clean it up is closer to $20,000, it may be best to just cut your losses and pay the ransom.
There may also be legal and regulatory considerations as well. While it is not fully settled whether a ransomware infection is a reportable event, there still may be legal considerations that an organization has to take into account, irrespective of whether or not they pay the ransom. For example, in cases of medical facilities in certain states, they cannot resume operations until they can confirm that the infection has been removed and they know that all electronic protected health information (ePHI) is secure. This would mean a daily per-bed loss that could equal thousands of dollars.
This is another reason planning ahead is so important. Advanced planning is especially important when it comes to mission critical systems where a speedy response is required to keep an organization running. The last thing an organization wants to do in the middle of a crisis is for everyone to sit around and ask each other, “How do we get Bitcoin?” It is probably a good idea to have a Bitcoin wallet somewhere in the organization before someone gets infected, as it is surprisingly difficult (though becoming easier) to purchase bitcoins with a corporate credit card. Once a Bitcoin wallet is in place add the information about the wallet to the security plan. Several things should be well-documented, such as:
- Where is it?
- Who has access to it?
- How much is in it?
- How to add more Bitcoin to it if need be.
The hope is that it will never be needed, but it is better to be prepared (Figure 1-2).
One concern that comes up with organizations, especially in light of breach disclosure laws (laws that require companies to disclose the fact that someone or some group has broken into their network), is that paying the ransom and the subsequent reporting may make the organization a target for other hacker groups, or even the same group. However, historically, this has not been the case. Once an organization has been a victim of a ransomware attack and paid the ransom, it does not usually fall victim again. This is often due to more focused security efforts.
Also, how can an organization be sure its files will actually be decrypted if the ransom is paid? After all, these are hacker groups who are infecting systems with ransomware. The truth is, ransomware campaigns would not be successful if they didn’t actually give victims the keys and let them restore their files. An unfortunate side effect of paying the ransom, even if the transaction goes well, is that it continues to fund these groups and helps make their ransomware even more effective against the next victim.
Sensationalist headlines are generated every time a new ransomware family is reported or a new technique is uncovered.1 If there was a hacking group that was taking money and not giving the victims the keys when they paid it would be all over the news. A story like that would be bad for business. Hacker groups that distribute malware are so concerned about victims not being able to get their files that some have set up chat services to specifically walk victims through how to pay and how to decrypt their files. There is an old saying that there is “honor among thieves.” That is not necessarily true with the hacking groups behind ransomware campaigns, but not decrypting files could disrupt their revenue stream, and that is something they will not want to do.
That being said, remember that some of these ransomware families have some very shoddy programming behind them, especially the earliest releases. It is possible that the ransom gets paid, and the correct key is given to decrypt the files, but the program simply does not work. Fortunately, with the private key, it may still be possible to decrypt the files.
Ransomware and Reporting Requirements
Ransomware is not simply a security and financial matter; it may also be a reporting matter as well, depending on the regulations that govern the industry of the victim organization. In the United States alone, many organizations have strict reporting requirements and must maintain regulatory compliance with the Payment Card Industry (PCI), the Health Insurance Portability & Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOX), the Gramm-Leach Bliley Act (GLBA), or the Family Educational Rights and Privacy Act (FERPA). International organizations have a whole different set of reporting requirements.
So does an organization have to report a successful ransomware attack? While each compliance guideline is different, the general answer is yes, an organization that has been successfully infected with ransomware has to report it.
Because ransomware does not typically remove files from the system, some people argue that these types of attacks don’t need to be reported. Instead, the files remain on the system for the duration of the compromise; they are simply encrypted. So, in most ransomware attacks, no personally identifiable information (PII) or personal health information (PHI) leaves the network. However, during an attack, the data on the system is under the control of attackers. This means that an unauthorized person or group has control of the data, which is clearly a reportable incident for most compliance guidelines.
The US Department of Health and Human Services (HHS) pointed this out in a fact sheet they released entitled “Fact Sheet: Ransomware and HIPAA:”2
Whether or not the presence of ransomware would be a breach under the HIPAA Rules is a fact-specific determination. A breach under the HIPAA Rules is defined as, “…the acquisition, access, use, or disclosure of PHI in a manner not permitted under the [HIPAA Privacy Rule] which compromises the security or privacy of the PHI.” See 45 C.F.R. 164.402.6
When electronic protected health information (ePHI) is encrypted as the result of a ransomware attack, a breach has occurred because the ePHI encrypted by the ransomware was acquired (i.e., unauthorized individuals have taken possession or control of the information), and thus is a “disclosure” not permitted under the HIPAA Privacy Rule.
Warning
Always Consult with an Expert
While this book attempts to provide readers with the most accurate information possible, it is not meant to be authoritative, especially on legal matters. Instead, the point of this section is to provoke readers into thinking beyond just the security aspects of ransomware.
PCI DSS and Ransomware
While the HHS makes the requirements pretty clear, there is some room for interpretation with the Payment Card Industry data security standard (PCI DSS) when it comes to ransomware. PCI DSS standards only apply to systems that are involved in the processing, storing, and maintaining of credit card processing infrastructure. If an organization is segmented properly (which is often a big if), then systems that are not part of the cardholder data environment (CDE) do not fall under the purview of PCI DSS. In other words, a workstation outside of the CDE that is infected by ransomware would not be subject to PCI DSS reporting.
For those systems within the CDE that do fall under PCI DSS reporting requirements, ransomware is not explicitly called out by PCI DSS version 3.2. However, version 3.2 of the PCI DSS specifically mentions the following types of malware:
- Virus
- Worms
- Trojans
- Adware
- Spyware
- Rootkits
The PCI DSS guidelines also add the following in “Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs:”
Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.
In other words, while ransomware is not specifically mentioned in PCI DSS, it does require that organizations protect against evolving threats, which includes ransomware. While PCI DSS only requires antivirus solutions be in place in order to maintain compliance, signature-based antivirus protection may not be enough to protect against ransomware.
However, antivirus solutions, even fully updated ones, are not always capable of detecting ransomware attacks; in fact they often miss them. Ransomware can even affect systems when it is not installed on them. Consider a Linux system being used as a file server. If it is being used as a shared drive by a victim system, files being stored on that system could be encrypted. Consider the guidance requirement 5-1 provides:
There is a constant stream of attacks using widely published exploits, often called “zero day” (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. Without an anti-virus solution that is updated regularly, these new forms of malicious software can attack systems, disable a network, or lead to compromise of data.
Even up to date antivirus solutions often cannot stop a ransomware attack, so it is worth investigating more advanced end-point solutions.
HIPPA
While the HHS is pretty clear about what is considered a reportable offense, not everyone agrees with them.
In fact, congressmen Ted Lieu and Will Hurd wrote a letter to the HHS asking that it consider ransomware as a distinct type of attack. The argument is that while a breach has to occur in order for a ransomware attack to be successful, not all ransomware attacks involve the disclosure of patient records.
That doesn’t mean that the congressmen felt that ransomware attacks shouldn’t be reported; instead, they make three recommendations:
- Patients should only be notified of ransomware attacks if patient safety was in jeopardy.
- Credit counseling services are not necessary in cases where patient data was not compromised.
- Ransomware attacks should be reported to HHS and other healthcare-focused information-sharing services.
That last point applies to all industries. Information sharing and analysis centers (ISACs) exist for every major sector and serve as important clearinghouses for understanding cyberthreats. These ISACs can help members keep up to date with the latest ransomware threats and the tactics ransomware teams are using. But ISACs are only effective if members are sharing their information as well. New tactics and techniques are developed by the hacking groups behind ransomware all the time, and some of those tactics are industry specific. So, sharing information about how an attack worked (whether successful or not) can help other organizations in the industry protect themselves from the same ransomware attack.
Summary
While most security professionals would argue against paying a ransom, there are some cases where paying the ransom is the best option for the organization.
Whatever the security strategy of an organization might be, it needs to be developed ahead of a ransomware attack. The worst time to make a decision about whether or not to pay a ransom is after a successful attack has occurred. Prior to an attack, an organization should gather the appropriate teams to discuss how prepared the organization is to recover from a ransomware attack and what that recovery would cost the organization. The appropriate teams, in this case, are not just security and system administrative teams but also legal, marketing/PR, and senior leadership. The more stakeholders involved in this discussion before a ransomware attack happens, the better an organization will be prepared to handle the event. This planning may include creating and maintaining a Bitcoin wallet.
Organizations also need to understand regulatory reporting requirements before a ransomware attack occurs. When a ransomware attack occurs, there won’t be any guessing about reporting; the plan will already be in place.
1Just search for the #ransomware hashtag on Twitter to see plenty of sensationalist headlines.
2Department of Health and Human Services, “FACT SHEET: Ransomware and HIPAA,” page 11, July 2016.