First, we prepare a plan for the possibility, then when a ransomware attack occurs we execute the plan. So easy to say, so difficult to do correctly.
To help, we break down the process into the following steps:
- How to Prepare for Ransomware
- Ransomware Response
- Simple Ransomware Recovery
- A Checklist of Post-Attack Tasks
Preparation remains the key to ransomware recovery. An organization must:
- Prepare a good backup policy and procedure
- Install layered security
- Test both security and policies for effectiveness
When installing layered security we need to focus on the most likely target and the most likely attack paths.
We must cover the basics. A zero-trust architecture with continuous authorization might be the preferred option for some, but a traditional security framework can provide adequate security for many. The classic approach of a modern firewall, robust network security, and advanced endpoint security would be reasonable. We should encrypt data at rest. We should use multi-factor authentication.
Budgets and IT capabilities may limit how much security we can afford to deploy, but not all security costs a fortune. Many of us ignore the embedded options and features of our current operating systems and software that can significantly reduce the effectiveness of attacks.
This is particularly true of server protection, where, as Symantec Endpoint Security VP and General Manager Adam Bromwich notes, “traditionally IT has not turned on all the protection technologies available to them. They have become a weak point that attackers are exploiting.”
“Lay of the land” attacks that exploit legitimate tools, such as PowerShell, WMI and PsExec, add to that insecurity. Symantec has added behavioral blocking around such tools and sandboxing, and the Broadcom company’s new Adaptive Protection tool shuts down processes that aren’t in use, further hardening systems and disrupting the attack chain.
“By the time you can react to an EDR alert, it is too late,” Bromwich told eSecurity Planet.
Planning and Testing
For an incident response plan or policy, we must be honest about our valuable assets, our security capabilities, and our team’s ability to respond to an incident. The key is functionality. A robust plan that cannot be executed by our team is worthless.
The plan does not require sophistication or even technical ability. It could simply be a list of numbers to call to escalate the issue to experts in incident response, an attorney, key executives, and so on.
Testing involves periodic checks of our processes and procedures. We need to verify that our security has been correctly installed and is functioning.
Internal assessments are okay, but can miss critical issues our team did not consider. Paying for internal assessments and penetration tests by a third party can provide fresh thinking and a level of assurance for stakeholders such as customers, the board of directors, and the insurance company that wrote our cyber insurance policy.
We also need to periodically check that the policy is up to date with the latest insurance providers, incident response vendors, attorneys, and executives’ contact information. We should also do drills to make sure our staff confidently can find and use the policy should a ransomware attack or other incident occur.
It can also be wise to ensure that all employees in the company receive and understand the incident response policy. Intermedia surveyed employees and estimated that 59% personally paid to recover from ransomware rather than admit to becoming a victim. However, our IT teams need to make sure that the malware has been removed from the system and we can only do that if we are informed about the attack.
Let’s say our nightmare has been realized and ransomware has struck. The first thing to do is contain the damage. Cut off network and internet access for the affected computer, server, or office. If necessary, shut down all networks for the organization to stop the spread.
Next, assess the situation. Some ransomware attacks automatically launch when someone clicks a phishing link and might only affect a single computer. Other attacks only launch after attackers have significantly penetrated the environment, accessed many different systems, downloaded company information, and deleted backups. In the latter case, the advanced persistent threat (APT) of the more sophisticated attacker may not be stopped by only isolating affected devices.
Is the attack small enough that we do not need to file a cyber insurance claim? If we are lucky, we have a single machine or limited number of users affected by ransomware and we may only need to recover from the ransomware itself.
However, in the case of a broad, APT-style attack, we may need to call in professional help to detect and remove the full extent of the attack. This will likely trigger a cyber insurance claim and our insurance policy might define who we need to call to to recover from the attack. These details should be spelled out in the incident response plan we prepared earlier.
In any case, larger attacks involve more complexity and variance than we can cover in an article, so we will limit the rest of this article’s focus to a limited, manageable scope involving automated ransomware striking only a handful of endpoint computers.
Our incident response plan may require us to notify executives and possibly our legal counsel. Some attorneys recommend proceeding in a specific fashion under the direction of the attorney so that they might extend the protection of Work Product Privileged communication to the process. Preferably, this possibility will be covered in advance during the creation of the incident response procedure, but if not, it will still be a good idea to contact the organization’s attorney and involve them in the process.
Ransomware typically announces its presence by locking up the victim’s computer with a message screen with the ransom instructions. This will provide information regarding the type of ransomware infecting the computer and provide a key regarding the next steps.
Some organizations may be tempted to pay a ransom. Organizations that depend upon uptime such as hospitals, law enforcement, or emergency services have mandates to be available and responsive that go beyond simple financial considerations. Deaths associated with ransomware are rare, but at least one death is directly associated with a ransomware attack and roughly 25% of healthcare providers noted an increase in mortality rates following ransomware attacks.
Unfortunately, there are three big reasons not to pay a ransom.
- The FBI discourages payment. If we need law enforcement cooperation later, it may not help to have gone against their published advice.
- We could violate US Treasury Sanctions. The Office of Foreign Assets Control (OFAC) issued an advisory reminding companies that payments to entities under sanction may trigger significant penalties. Some ransomware actors operate within sanctioned countries (Iran, North Korea, etc.) and others have been sanctioned as separate entities (terrorists, organized crime, etc.).
- It doesn’t work. Sophos conducted a survey and found that of victims who paid the ransom:
- 4% paid and received no decryption keys
- 8% paid and were able to fully recover
- 92% of those who paid did not fully recover their systems.
If we are lucky, our ransomware may have decryption tools available through public sources or through anti-ransomware tools that may be purchased. These tools may make it possible to remove the ransomware and fully restore the system and files.
More likely, a decryption tool is not an option, so we can next check if we have available backups through System Restore. If we know the date of the infection, we can roll back the computer to a system restore point prior to the infection, which should automatically remove the ransomware, clean the registry, and restore the operating system. However, we still have to restore files from backup and we may lose any changes since the last backup.
If we are unlucky, the ransomware may be more sophisticated and thus also encrypted or deleted any backup files. In this case, we may need to completely wipe the system, reinstall all software and load all files from backups.
While it is possible to manually restore systems instead of wiping them, we need a lot of time available and a deep understanding of Windows Registry to carefully examine it to remove any lingering infections. Generally, this option consumes too much time to be practical.
Further reading on ransomware protection and recovery:
Whether we can restore our systems ourselves or if we must hire incident response specialists, fully recovering our systems from an attack only marks the start of the process. We will also need to:
- Recover our data
- Assess for data breach
- Report to regulators and stakeholders
- Apply lessons learned
First, we need to recover our data. Full recovery of our systems will test the quality and thoroughness of our backup processes. We will need to go back far enough to locate data free of malware, but not so far back that we lose a lot of work product. Sophisticated ransomware attackers will always locate and delete backups available on the network, so we may also need to pull from our off-line or off-site backup resources. Our preparation prior to the attack will be critical to our success.
Next, we need to assess the potential of a breach. Did the ransomware simply encrypt the local system or did the attackers exfiltrate the data? Many ransomware gangs have adopted the tactic of exporting sensitive data prior to triggering the ransomware attack and extorting the victim company with the threat of publicly releasing their data.
If exfiltration has occurred, what types of data was stolen? Depending upon the type of data affected, a full forensic investigation of the attack may need to be performed to gather evidence for criminal prosecution or to defend the organization from civil and regulatory action.
The assessment may then trigger reporting requirements. Certain types of data (personal information, credit card data, healthcare information, etc.) are protected by law and the loss of this data may trigger regulation violations and reporting requirements.
Breached customer data may also trigger both contractual and moral obligations for reporting the extent of the breach to the affected parties. We also will need to report internally to executives and possibly the board of directors regarding the details of the attack and the recovery. Once the type of breached data is known, our legal counsel will determine what types of internal and external reports may be required.
Finally, our IT teams will need to analyze the method of attack and determine how we can prevent such attacks in the future. Often this will be referred to as a Lessons Learned report and it should cover what security was bypassed to allow the ransomware attack, such as email screening, firewall security and the like, what adjustments have been made or could be made to existing security, and what additional security may need to be installed.
Some organizations may not have the budget or time to immediately address all issues, so unaddressed issues will also need to be evaluated for risk to the organization. For example, it may not be practical to prevent phishing attacks from leading to future ransomware attacks, but the organization may decide to encrypt more devices or block email access from critical systems to limit the future risk to the organization.