Intro
In today’s article, we will discuss the good and bad practices when facing a major incident.
Facing an incident is stressful for both : the victim and incident handlers. Therefore, to reduce the impact of that stress, we need to understand what are the good practices to adopt and what are the poor decisions one may make under the effect of the stress.
As for an example of an incident, we will run through a Human Operated Ransomware case scenario and see what could lead to a longer analysis time, communication difficulties, or at worst, your infrastructure being compromised again after the first attack.
Confine, confine, confine!
All your indicators are red, a part of your infrastructure doesn’t work anymore, a ransom note is displayed on a non-operational machine. There’s no room for doubt; your infrastructure has been ransomed.
Do
The very first step to take when facing such an incident, is to isolate and heavily segment your machines at network level, infected but also healthy ones and isolate the company from the Internet. To best limit the malware propagation.
The main goal of shutting down the Internet access is to stop the attacker from sending instructions to the ransomware from their command-and-control server (CC). So, you will be able to destroy all the momentum the malware has gained through time. The attacker will not be able to spread the ransomware further in your infrastructure. He would lose access to its backdoor, making it impossible for him to hide it by sending it dormant somewhere else; or will be prevented to install one if he hasn’t already done so.
Cutting all access will, therefore, not only reduce the impact of the malware, but also will stop the threat actor from exfiltrating more data by stopping the ransomware from communicating with its owner. This, of course, is crucial.
Don’t
How about the don’ts ? We have just seen how important it is to cut all accesses to Internet in order to avoid the threat actor from going further.
Let’s go back in time in that scenario, instead of shutting down the access to Internet, you decide not to do it. What could have gone wrong ? Well, the answer is quite simple. Cutting all internet access may stop your production, hence strongly impact your business. So, you probably won’t do it because you are trusting that “the compromised server doesn’t have access to internet, so it’s fine”.
Well, that would be quite thoughtless, as, by experience, we know that the network knowledge is often not-quite-up-to-date and might be wrong. Thinking like this will probably lead to an isolated server with uncontrolled outgoing traffic that will keep connection alive with the CC or with an unknown intermediate server between the attacker and your ransomed infrastructure.
Speak up!
All internet traffic down might not only stop your production system but also alert your customers that something is happening.
Do
Why communicate on a crisis is important ? Your customers expect to be warned if a cyber-security incident is happening. Even more if their personal or sensitive data are in jeopardy. A clear and transparent public communication would depict your company as responsible, transparent, and honest. A cybersecurity incident is something that may happen to everyone. Remember that even the strongest walls have an exploitable crack somewhere, at some point.
Alongside your public communication, if any personal data have been stolen (either your employees’ or customers’) you need to report the cyber-heist, in a timely manner, to the CNPD (in Luxembourg) or to the Gegevensbeschermingsautoriteit/ Autorité de protection des données (APD, in Belgium) due to GDPR-regulations. Not doing so puts you at risk of a fine (from €10 million to 4% of a firm’s annual revenue from the preceding financial year ) as well as greatly damaging your public reputation if the media and the public initiates communication on their owns.
Don’t
“Ok, but maybe no one will notice it. For now, we have other things to handle. It’ll be just fine, right? Right?” Well, no. As you may know, the threat actor groups now have the habits to publishing everything publicly and journalists following the activity of those gangs will scream on social networks that *your company* have been ransomed, dragging your reputation through the gutter. You must be aware that everything, soon or later, is known by everyone nowadays. So not disclosing the incident correctly puts your company at a risk of a stained reputation. Or worse.
Hold on
Do
As your company have been ransomed, of course you won’t pay the ransom, because you don’t want to finance criminal activities but also because you don’t want to tell the threat actor that your company is willing to pay (they might want to come back). So, you contacted a CSIRT to help understanding how this happened to fix the issue.
Don’t
But, as the analyses are starting, you might want to get your production back in business already (you sure have offline backups! don’t you ?) which would be a dreadful idea at this stage. Why ? First of all, you need to be sure that your offline backups are clean and do not hold any activities of the attackers. They may be several weeks (or months) old, but the compromise often occurs for about, usually, fifteen days before the first alert. The attackers use this time to escalade their privileges, steal your data, all that unnoticed, long before you may ever know.
So keep in mind that, as long as you don’t know for how long the attacker first breached in, you may deploy your compromised backups. And everything will start all over again. Which, well, is quite bad.
Next, let’s say your backups are hopefully safe, you restage your production from backups right now, on the impacted machines : you just erased the evidence that the CSIRT could have used to answer “how this happened ? What was done by the threat actor ?”. You must be prepared and wait until the CSIRT analyze all needed information from your infrastructure (eg. dump the impacted workstations/servers).
Unfortunately, if not prepared, you might also discover that the retention is too short, or some essential fields are missing in logs to allow for a proper investigation. This happens more often than you might think, so assessing your response capabilities regularly is crucial to be prepared the day the attack will engage.
HOLD ON (still)
We’ve seen it, you might be tempted to restart your production with your backups. But that still would be unwise to do so that early. You still need crucial results from the CSIRT team’s analyses to be sure to detect all traces of compromission.
The CSIRT team will try to find, at least:
- The earliest compromise date : the first time the threat actor got foothold and potentially implanted backdoors or rogue accounts. This will tell you which backups you can restore.
- How the ransomware was deployed : How the attacker gets from one host to the other, we need to detect the lateral movements that occurred across your network, hence identify infected devices that need to be isolated.
- All command-and-control servers : To cut all the traffic towards the threat actors.
- The exfiltrated files : To be aware of all the data that have been stolen, which may include personal or sensible data.
If everything is going smoothly, between one and three days might be necessary to evaluate the first date of compromise. Of course, this delay depends on the amount of data to analyze, on how many machines must be analyzed before finding the patient zero and more specifically if everything goes fine, (given for instance that you have ready at hand all the data and logs for the analyses).
From scratch
The final, major step is about your Active Directory (AD). Indeed, it’s always an important target for the threat actor and numerous means of persistence exists on an AD due to its inherent complexity. This means that cleaning the AD from any threat actor operations is not realistic. It means that, yes, you will probably need to entirely rebuild your AD, on a fresh instance. Resetting all passwords will not be sufficient, even if it includes users, but also for services accounts and for the special KRBTGT Kerberos account, the one that deliver access tickets. Indeed, an Active Directory is a complex directory with many objects. Backdoors can be added in many places.
Conclusion
From a pure cybersecurity point of view, we cannot assume we are safe. However, knowing how to manage a crisis may reduce its impact by a lot. In this case, we have seen how to handle properly the worst of all, the ‘Almighty Ransomware’.
So, let’s review the most important points to secure your infrastructure that we have covered in this newsletter:
- Add detection capabilities. As an incident is always easier to face when it is detected early, when the threat actor tries to get a foothold, or at its very beginning stage (during infrastructure discovery).
- Know your infrastructure. Documentation should be backed up offline to keep it safe but also be complete and up to date to ensure you are not worsening the incident while trying to solve it.
- Proper segregation. A correct segregation can limit the crisis to only a few days and a handful of servers instead of letting the incident spreads to the whole infrastructure or allowing the attacker to reiterate its attack a few days later. It also minimizes the loss of income during the crisis, as part of your infrastructure may be operational with heathy environments being untouched thanks to a good segregation.
