Incident Response Ransomware Series - Part 3
So far in this series, we have looked at what ransomware is, what it does after it has compromised a system, and what organizations can do to detect and prevent ransomware. (Catch up with Part 1 & Part 2 before continuing!) However, that is only half the story. Organizations need to assume that they will be compromised with ransomware at some point and must plan on how they will respond. This blog post will discuss strategies for responding and recovering from a ransomware attack.
Containment
Once ransomware is found on a system, it is absolutely necessary to contain the system as soon as possible. Ransomware often encrypts local files first and then moves to files on shared folders; some ransomware, like CryptoFortress, will even scan for and encrypt files on open network shares. Therefore, it is imperative that systems with ransomware on them are quickly contained.
Containment is the process of stopping the spread, additional impact, or continued damage of an incident. In a ransomware incident, the best way to contain a system is to isolate it and take it offline. This can be done in a number of ways, such as:
- Shutting the system down
- Turning off the system’s port at the switch
- Utilize network access control (NAC) to isolate the system
- Implement the quarantine feature of your EDR solution
Remember, as discussed in the second post of this series, ransomware rarely propagates on its own within a network and often has help from a secondary malware. In order to determine how ransomware got onto a system, forensic analysis is needed. However, there is a trade-off between the containment solution you choose and the amount of forensic data you will have available after .
If you shut the system down, the ransomware stops encrypting files (assuming you did it in time), but any volatile data that could be useful in an investigation will be lost. If you isolate it on the network, the ransomware will continue to encrypt local files, but volatile data will still be available. These decisions and their associated procedures need to be made by an organization and documented in a run book before any ransomware incidents take place.
Depending on what is known about the ransomware and how the ransomware was placed onto the system, additional containment measures may be required. This includes:
- Disabling accounts used or compromised by the ransomware
- Resetting passwords for known compromised accounts
- Blocking domains or IP addresses to prevent external communications and detect other compromised systems
Eradication
Once the system has been contained and the appropriate forensic data obtained, the ransomware needs to be eradicated. Eradication in an incident occurs when the attackers, or ransomware in this case, are removed from the systems and any associated vulnerabilities are mitigated to prevent further compromises. Eradication with ransomware comes in two (2) parts.
First, the ransomware must be eradicated. As with all malware compromises, the best way to do this is to rebuild or reimage the system that was compromised and restore data from a known good backup. This is the only way to ensure that any malware on the system has been removed.
If the system is unable to be rebuilt or reimaged, then automated and manual removal of the ransomware and any other malware on the system is necessary. Automated means of malware removal typically involve utilizing anti-virus (AV) or endpoint detection and response (EDR) software to remove known pieces of the malware. However, in our experience, even if AV/EDR can detect the malware, it typically misses a few pieces. This is why you must also utilize manual removal of the malware.
Manual removal of the ransomware involves performing malware analysis to determine exactly what the malware does. During analysis, indicators of compromise (IoCs), such as where it drops its files and how it sets up persistence, are gathered so they can be manually removed from a system. While the malware sample can be uploaded to a public malware sandbox, this is not always recommended for operational security (OPSEC) reasons. Instead, a staffer or contractor should perform the malware analysis and get the indicators as quickly as possible so any residual artifacts can be removed.
Remember, ransomware may not be the only malicious code on the system. A forensic analysis should be performed to determine the root cause of how the ransomware got on the system. If there is additional malware on the system, that malware will also have to be removed before the system can be put back online and the incident closed; otherwise, a recompromise of the organization could occur at a later date.
Recovery
The purpose of the recovery phase is to restore the systems back to normal operations. If a compromised system was reimaged during eradication or restored from backup, then ensuring the system is running properly will complete this phase. Do not forget that if a network file share was encrypted by the ransomware, then these files will also have to be recovered from backup.
But what do you do if a backup is not available? Some systems are not backed up, and threat actors are smart—they do not just randomly deploy ransomware in an organization. They do their research and figure out which systems, when encrypted, will hurt the organizations the most. This might include your backup servers.
If a backup is not available, there are only three (3) options: try to find a decryption program, rebuild from scratch, or pay the ransom.
Decryption Programs and Identifying Ransomware
Programs that decrypt ransomware encrypted files do exist for some ransomware variants. If a decryption program is available, it can be a quick way to recover files. However, before determining whether a decryption program is available, the type and version of ransomware that encrypted the system needs to be found.
There are multiple ways to determine this. First, most ransomware variants use a specific extension on the files they encrypt, which can be used to identify them. For example, Locky ransomware uses .locky, Ryuk uses .ryk, and CryptXXX uses .crypt. The ransom notes themselves will also often state the name of the ransomware, or if not, its format and name can be used to fingerprint the ransomware as well.
Fortunately, much of this manual work has been automated for you. By uploading a copy of the ransom note and a few of the encrypted files, the sites below may be able to determine the ransomware variant and whether a decryption program exists.
If the ransomware executable is available, its hash or the binary itself can be uploaded to a site like VirusTotal to determine what it is. We recommend searching for the hash first, in case the attack came from targeted malware.
Rebuild from Scratch
If a decryption program is not available and the ransom will not or cannot be paid, then the only other choice is to rebuild systems from scratch. Depending on the system that was compromised, starting over may be the best decision. For example, if the compromised system was a workstation with few files on it, then rebuilding it from scratch is probably the best solution. If the compromised system was an organization’s only Exchange server, then paying the ransom may have to be considered.
Paying the Ransom
Whenever ransomware is involved, the decision on whether or not to pay the ransom will eventually have to be made. TrustedSec does not advocate paying the ransom in any situation, as this reinforces the criminal business model behind ransomware.
However, we understand that sometimes organizations do not have a choice. Sometimes backups are not available and the only way to recover data is by paying the ransom. If this decision is made, there are a few things that should be kept in mind:
- These are criminals. There is no guarantee that paying the ransom will result in the decryption program or key.
- If the decryption program is given, there are likely to be files that are still not decrypted. In incidents TrustedSec has worked where clients have paid the ransom, they often get back most but not all of their files. Hopefully, the files that are not decrypted are not the ones needed by the organization.
Organizations need to have the pay-or-no-pay discussion with executives now, before a ransomware incident affects the organization, as they will be the ones who have to stand behind this decision. Executives need to understand the vulnerability associated with paying the ransom, and if there is a possibility a ransom would be paid, some aspects need to be set up prior to an incident. These include:
- The procedure for procuring Bitcoin
- Who will pay it—the organization or a third party?
- The criteria surrounding whether or not a ransom will be paid
- Determining if there are any legal or regulatory repercussions from paying
Again, remember that paying the ransom is no guarantee that files will be returned.
Conclusion
Ransomware is here to stay. Almost every week, there is a new news story where another organization has been compromised with ransomware. The ransoms are being paid, so attackers know this is a profitable business for them. However, there are ways to protect an organization from ransomware and the first step is by understanding the threat. The goal of this series has been to provide that knowledge by defining what ransomware is, how it works, how it can be defended against, and how those attacked can respond to it. We hope this knowledge can be used to gain a better security stance and prevent the need to think about paying a ransom.