How to recover from a ransomware attack: A complete guide

What is ransomware recovery?

With ransomware, the two paths to recovery are: pay up or don't pay up.

The basic premise in a ransomware attack is that an organization can decide to pay the ransom, and, in exchange, the perpetrators will unlock the captured systems and allow the business to regain access to its data.

The "just pay up" option has gotten steadily less viable as the number of bad actors and ransomware packages has increased. It has become more common for perpetrators to ask for more money instead of removing their malware and restoring access, for example, or to simply take the money and not send the release codes. It is also not unheard of for the malware itself to malfunction when the unlock keys are provided -- or it might not uninstall itself cleanly. And it has become clear that an organization that demonstrates a willingness to pay a ransom will be targeted for subsequent attacks. A ransomware incident also can be a jumping-off point for a deeper attack or, worse still, launched only as a distraction from such an attack.

No matter what cybercriminals ultimately do or appear to do, an organization under attack has to treat all compromised systems as still compromised, which requires that they be restored or rebuilt. It also has to treat all data as potentially corrupted, leaked or sold to other bad actors, no matter what the perpetrators say.

What this means is that an organization might get up and running more quickly by paying the ransom, but it still has to behave as though all the systems and data are suspect and go through all the steps it would if it had not paid.

How to recover from a ransomware attack: Step by step

To deal well with a ransomware attack, an organization will need to have prepared well. The decision to just pay, not surprisingly, is most popular with those that have not prepared well.

Ransomware recovery depends on how well an organization has done or can do the following:

• Access backups.
• Implement an incident response plan.
• Trained on and practiced implementing the plan.
• Make use of all relevant security systems to isolate, contain and disrupt an attack.
• Communicate.
• Restore affected systems to normal function.
• Improve the plan.

Have backups

"Do you have a backup?" is a sort of standing joke for IT service desks, much like "Have you tried turning it off and on again?" Everyone knows the answer should be yes, but all too often it is no.

It's crucial to have backups of data stored on user endpoints, including mobile devices if they hold business-relevant data locally, and of centrally stored data. Protected backups should be the first step in ransomware preparedness because the eventual recovery from an attack depends on having something to recover.

An organization should back up as frequently as it can afford. Confirm through regular testing that the backups work and that you are able to restore from those backups. Store some backups offline so they are not attached to or directly reachable by systems in the production environments. This prevents backups from being infected by malware introduced after the time of backup. Ideally, the organization's backup tool scans data flowing in for known infections as well as data flowing out.

Have an incident response plan

Every organization should have a cybersecurity incident response plan to guide its actions when it is, or might be, under attack. An incident response plan should, among other things, define appropriate courses of action. It must specify decision points -- the times and conditions under which people make the choices that will guide the response. It should also specify relevant roles: who, in terms of position, makes those decisions and who, by name, holds that position. Be sure the plan includes details on how to contact those decision-makers and who their alternates are if they can't be reached. The response plan also needs to explain who is supposed to implement decisions once made.

One of the most important considerations in a ransomware response plan will be whether to pay the ransom, assuming company policy does not forbid it. The response should specify who has the authority to make the decision -- i.e., the holder of which management position -- and when that person should decide.

It is not inevitable that every organization will experience a successful ransomware attack. It is inevitable that those that fail to plan for one will be at a serious disadvantage should one occur.

Every incident response plan should be reviewed and updated annually, if not quarterly. The organization should also define events that trigger a review and revision, such as reorganizations that affect any of the roles named in the plan, staff turnover that affects any of the people in those roles, addition or removal of any tools important to a response and adjustments in environment or architecture that will change visibility into an attack in progress or affect a response.

Train on and practice implementing the plan

Far too many incident response plans are superficial, developed mainly to let leadership check an audit box to indicate that the plan exists. Such plans are prone to being out of date and out of alignment with current infrastructure, services, staff or processes. They might be ignored or forgotten during real events. As a result, staff in such organizations wind up doing things they need not or should not do while not doing the things they should. Even a plan that is kept up to date has little meaning if the affected teams haven't internalized its existence and content.

To respond effectively to an actual ransomware attack, organizations should regularly rehearse the steps laid out in the incident response plan. A further step would be to either run or have a third party run ransomware war games to see if everyone involved remembers the response plan, follows the plan and can figure out ways to improve the plan after trying to execute on it.

Isolate, contain and disrupt an attack

When the security operations center detects that a ransomware attack is underway, that team should begin executing the incident response plan. Guided by the response plan, the SOC team should also be triggering defenses, such as the following, to contain and disrupt the spread of the malware:

• Shift networks to automatic quarantining of endpoints behaving suspiciously.
• Lock down network segments not yet at full zero-trust network access to prevent the infection from spreading.
• Block command-and-control connections, if possible.
• Shut down access to central storage or core applications, both on-premises and with cloud providers.

As much as possible, automation should be in place to execute reactive security tightening across networks, cloud services and storage resources as fast as possible. Responses programmed in advance can be set so they are triggered manually by staff or triggered by other automation in response to predetermined indicators of ransomware-like behavior.

Communicate

An incident response plan should specify who should be informed about expected operational effects. Consider when to tell which parts of the organization, which partners, which clients, which customers. This step should specify who is responsible for that communication, as well as how and when the message is delivered; boilerplate language can be prepared in advance.

Restore affected systems to normal function

Remember those backups? Time to put them to use. Wipe and restore endpoints, or rebuild them from scratch. Delete and replace central system instances. Scan restored data for infections to prevent reinfection from corrupted files.

Improve the plan and reduce risks

Finally, soon after the dust settles, conduct an after-action review. This should be a frank and blame-free review of everything done -- and not done -- in response to the incident. Review which elements of the response plan worked and which didn't. Add whatever is missing, and trim what turned out to be extraneous. The old saying goes that "No plan survives first contact with the enemy"; on the assumption that a perfect plan is not possible, no plan should survive contact. With retrospective analysis, you turn that truism from a bug into a feature.

Outside the incident response plan itself, consider if the post-incident review can identify ways to reduce the risk of future attacks succeeding or at least limit the damage a future attack might do. This might be anything from recognizing the need to implement a full software-defined perimeter strategy to a simple change in how staff cybersecurity awareness training is conducted.

Expectations for recovery from a ransomware incident

It is not inevitable that every organization will experience a successful ransomware attack. It is inevitable that those that fail to plan for one will be at a serious disadvantage should one occur. Don't assume that recovery is a foregone conclusion. Some small and midsize companies, and even some large ones, have been driven out of business by ransomware.

Even with a plan, getting back to normal operations after a ransomware incident is likely to take days or even weeks, depending on the severity of the infection. Also, any serious attack will wind up costing the company a lot of money. Costs come directly, in terms of cybersecurity, network, systems, storage and cloud staff time expended on defense and recovery -- as well as any expenses for added software or services to aid in detection and eradication of the malware, plus restoration of data and systems. Costs also come indirectly, thanks to the disruption; normal work is not getting done, and that comes with a cost. There might also be fines, penalties and even lawsuits in the aftermath.

A savvy organization will address the threat of ransomware by taking steps in advance that will minimize the chance of infection, limit the infection's ability to spread and diminish the possibility of data loss. Also, consider that thorough preparation improves the speed and effectiveness of a well-considered response.

John Burke is CTO and a research analyst at Nemertes Research. Burke joined Nemertes in 2005 with nearly two decades of technology experience. He has worked at all levels of IT, including as an end-user support specialist, programmer, system administrator, database specialist, network administrator, network architect and systems architect.