Hey guys, I wanted to do a follow-up to the Anatomy of a ransomware blog and talk about how to react when it's about facing a ransomware attack.
Spoiler alert ! About some of the advice you'll read in this blog today... you've heard them many times already! They make sense, they are realistic (not always I agree), but after reading the news we can conclude that they're not always enough. But I have some additional tips in my back-pocket that I would like to share with you !
So what are the steps to take before an attack ? And how to react when the first signs of an attack appear?
Obviously I cannot cover everything in a blog (it's really a full time job!), and it is only my point of view, but I'll try my best to provide an answer (one of many) to these questions !
I will make a few references to content packs you can find on the app exchange as an additional help for the detection, but I will try to focus on the prevention and response to an attack because we already have talked a lot about the detection part.
Prevent Control the risk
Did I say prevention ? Let's be realistic, the risk zero doesn't exist. As long as you are connected, you're at risk.
In fact, on top of the traditional attack origins, we start seeing ransomware attacks originated from the supply chain, this new attack surface is only making the task harder than before.
So you need to get ready!
Let's start with 3 essentials you need to implement to get ready for any type of attack:
- Ensure you have offline backups at all times.
As we mentioned, the risk 0 doesn't exist, and even if you are willing to pay the ransom, there is very little chance that you'll get back to normal, so having a real backup plan is probably the most important part of your whole plan. This is then a crucial step, you might never be able to recover the last 24 hours of activity, but you'll save a great amount of data.
- Build and rehearse playbooks to prevent the panic and get better results.
If you know who to contact, how to react and have every step defined in a centralized place, you'll gain time and limit the mistakes when the incident happens for real. You'll find a cool example here: https://www.publicpower.org/system/files/documents/Public-Power-Cyber-Incident-Response-Playbook.pdf.
- Implement the relevant supervision.
By conducting a risk analysis, you'll be able to identify where you are vulnerable (including the supply chain we mentioned previously) and where the value of your company is located. By doing so, you'll get a better idea of the use cases you need to implement.
I would like to take a break and emphasis something here guys. Identifying your weaknesses is the most important thing to do to implement the right protection, and then the right supervision to avoid triggering hundreds of lesser priority alerts everyday.
How can you ensure the SOC analysts will catch a ransomware that has been observed on 5 different machines and keep spreading ? How do you ensure you keep the attention of the team and avoid them to fall in a routine where alert processing becomes an automatism more than an actual alerting?
Tools can help, but proper use cases definition is a mandatory step.
Now if we go back to our ransomware concern, there are using 3 main vectors of attack:
- Software vulnerabilities
For phishing, we must focus on the users. The training of the users must be constant and substantial. I've myself received many trainings over the years, I don't remember hearing once about homographs, yet they are so common (time to refer to our Threat Monitoring content extension that includes homograph detection rules and searches and the Mail and phishing content extension that can help you detect other suspicious email behaviour).
For software vulnerability and RDP the advice are similar. Vulnerability assessment and risk analysis would help evaluate if improvements are possible in network isolation, account management, etc.
Also, you can limit the risks by closing the services and ports that are not necessary, I didn't come up with anything new here, many advisories on CVEs are mentioning this last point. Obviously with vulnerability management comes patch management, keeping your machines up to date is one of the most important rules when it's about defense.
Take a minute to get an overview of the situation
You might be up to date in your vulnerability management, have an A+ in accesses review and do everything following all the guidelines, you could still end up being under attack. The reality is that attackers will always find a way in, but that's what we are getting ready for, let's work to make the battle a bit easier for us and harder for them !
When you see the first signs of an attack you can't waste any time, so taking a minute seems to be a luxury I know, but you still need to know where you are being attacked, so it's actually mandatory if you want to contain the attack.
For this step, you can use many tools (SIEM, AV console, EDR console, IPS alerts, etc), the most important is for you to generate any sort of report that will provide the location of the infected machines, in the least time possible.
The Endpoint content extension can be used as a quick hit as it includes many rules to catch ransomware, from the first warning signs (distribution phase) to the actual end of the process (notification phase). The process of a ransomware attack and the content of the pack are detailed in two blogs.
→ Please refer to this blog to understand the typical path of a ransomware attack: Anatomy of a ransomware attack
→ And this blog to get a more detailed point of view: Endpoint monitoring essentials for QRadar
Once you have the Endpoint content extension on your system, you can refer to the existing Pulse dashboard included in the content extension and adapt it to your needs:
You can also use this content extension to create your own search that will look at the events generated by the rules triggering on ransomware behaviour.
We used a similar technique for the rule Ransomware IOCs Detected on Multiple Machines. For the search you can remove the threshold and tune the list of events you want to catch (adding the rules Attempt to Delete Shadow Copies or Recovery Disabled in Boot Configuration Data as an example).
This would give you quickly an overview of the number of machines potentially affected, identify the networks it is spreading in, etc, allowing you to move to the next part or the plan.
It is time to act
Get your playbooks out ! Now the chapter on risk control will help you to limit the costs greatly, because you'll know exactly what to do and how to not waste time.
I separated the last part of the plan into 4 steps, but it is really an arbitrary decision and can definitely be split differently.
You probably called one or two persons already, and more are coming. In your playbooks you should find most of these entities represented:
Some won't apply to every company, but you can take it as a base to review the need to add contacts or not. These people will help you go through every step coming.
Step 1: Contain
If you've read the Anatomy of a ransomware blog, you probably remember a mention to potential exfiltration of data to threat the victim of making their breach public or simply releasing the stolen documents. That's why you need to take immediate action if possible and turn off the internet access to stop / avoid potential data exfiltration.
This step is not necessarily valid for any type of threat, particularly when you are facing a polymorphic or metamorphic malware because you don't want the attacker to suspect they have been discovered before you can take more actions, but to avoid blackmailing it becomes essential. For more information about data exfiltration monitoring, refer to the dedicated Need help to monitor data exfiltration ? blog entry.
Isolate the infected systems in a separated network or from the network if not possible.
When the machines are compromised, if you managed to isolate them, it is in your best interest to keep them up to preserve the volatile memory for post mortem analysis.
Step 2: Communicate
Now that the bleeding stopped, the team needs to track any potential sign of persistence left on the network to prevent a second wave to come.
In the meantime you can keep going with your playbook and call your forensics team, machines/application administrators, legal people, insurance if you have any, etc. It might also be time to do a first evaluation of the impact of the attack to inform your stakeholders.
This step will be different for every company so I can't extend my recommendations so much, but I can reiterate my advice of getting ready for the incident and reviewing the procedure regularly (technologies, contact information, etc)
Step 3: Recover
Once the attack is confirmed contained, it is time to start with the recovery plan.
The last step before the actual restoration of the machines is the prioritization of the most critical to recover, hopefully the risk analysis will help you in this task.
Having a backup plan will allow to re-image the machines and get them up and running in no time.
Step 4: Retrospective
What did you do right and what can you improve in the ransomware incident? Doing a post-incident analysis to identify what went well and what didn’t is critical to respond faster in the future. Learning from mistakes is one of the best response you can give to an incident .
To conclude this blog, I can tell that while I was writing I realized that every piece of the process would deserve a dedicated blog, there is so much things to say.#Spotlight
The incident preparation, detection and response topic is immense and complex, that's why you need to work on it in advance, and gather the team that will help you go through it.
I hope this beginning of checklist will help you in any way, I can at least give you a number to add to your playbook, in case you need assistance you can connect with the IBM Security X-Force Incident Response team, who is available to assist 24×7, at US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.