Malware response plan recovers data in 6 steps

Identify affected endpoints

You're probably made aware of an attack because a user called into the help desk complaining they have ransomware, their machine is running slowly -- a symptom of cryptojacking -- or they think they may have clicked on something they shouldn't have. Because of this, it's more than likely you have at least one endpoint to start with. But to properly clean out an infection post-attack, you need to know every endpoint that has been affected. This may be tough, even in the case of ransomware where it clearly identifies an infected endpoint with a message about encryption. It's not always easy to tell which machines are affected without some kind of endpoint detection response tools in place.

Malware may be lying dormant on some endpoints, running in memory evading detection and, in the case of ransomware, other endpoints may have been accessed via SMB and encrypted without installing any malware. According to a report from security awareness training vendor KnowBe4, the average time it takes to identify all affected machines is between four and nine hours.

Communicate method of entry

In the next step of your malware response plan, you need to know how the malware accessed your network so you can close the door on its means of entry. This is done primarily by looking at any available digital evidence. You'll need to interview the relevant users to see if the malware was a specific phishing email, a website they visited or something else.

Once you have the smoking gun -- for example, an email with a misleading subject -- you need to communicate your findings as soon as possible to every user in the organization to avoid further infection.

Block access

If you have the ability, I recommend blocking access to the originating website, malicious email, and command and control (C2) IP address to ensure the same attack method can't be used. Keep in mind that malware is now being written with counterincident response measures to keep it alive. Recent attacks have seen malware with coding that enables it to lie dormant and then use a backup C2 server should the initial one no longer be accessible (read: if you block it as part of your response plan).

With the badness somewhat under control, let's work on the next part of your malware response plan: putting the pieces back together.

Restore endpoints to a known-good state

Every endpoint that has been infected needs to be brought back to a state where you are 150% certain there is zero chance of the malware remaining. While some organizations rely on antivirus-type products to quarantine or remove the malware, I don't see them as the best route. Sure, they're designed to handle malware, but it's the cautious part of me that says it's not good enough.

There are a few ways you can put endpoints back into a known-good state:

• Reimage. This option is only as good as how updated your images are.
• Rebuild. This is a lot of work and may only be a good option for one-off endpoints, like your CEO's laptop.
• Combination of the two. I'm hoping you have a gold image and some form of application deployment so that the process of wiping a machine and bringing it back to a current state is completely automated.

Recover affected data

How can you be 100% certain the data is error-free when decrypted? The reality is that you can't.

This part of a malware response plan is probably most applicable to ransomware attacks, where lots of data has been encrypted. However, it could be applicable in cases where there is data on a reimaged endpoint that is not included in the gold image. For the purposes of this article, I'm going to stick with the ransomware scenario.

The data is either still encrypted, or you paid the ransom and it was previously encrypted and possibly tampered with by an outside attacker. I'm of the school of thought that you should have backups of anything you deem critical, so there should never be a case where you need to pay a ransom. But even if you do pay the ransom, your data was modified. How can you be 100% certain the data is error-free when decrypted? The reality is that you can't.

So, I promote the idea that you need to restore as much data to a pre-attack, known-good time frame as you have backups for. You may need to repeat step one with ransomware attacks that use EternalBlue code to traverse SMB connections and encrypt data on other systems, as there may be no infection of those systems, just encrypted data.

Re-examine your security strategy

There's a reason you were vulnerable to an attack, so you will need to work backward to find the gaps in your security strategy. If it's your users, look at security awareness training. If the problem is too many phishing emails coming through, look at an email scanning product. The best position to protect your organization from malware is to have a layered approach, with each step addressing the problem of attacks from a different angle.

There are a lot of unknowns when it comes to malware attacks. It's one of the reasons this six-step malware response plan is so high-level. The key is to have a plan in place and proactively work backward to be ready. Determine what backups you require in the event of a successful attack and have a means by which users can inform IT of a possible infection. By following these steps, you have the foundation for a response plan that can address just about any malware attack.