Note: our stance is the same as the FBI’s and we advise against paying a ransom as there is no guarantee that the decryption tool will work, that it encourages these threat actors to continue, and that it signals that the victim is willing to pay and may still be willing in the future.
A phone call in the middle of the night: “nothing works, can you hop on it immediately?”. A few keystrokes and the worse is confirmed: most of the systems have fallen to a ransomware. Then what?
There is, of course, the investigation to find who is patient 0 and how the attacker got into the network: has someone clicked on a link in a phishing email? Or was the entry point that old server exposed to the Internet you planned to remove for the last six months but that a developer said “he needed a couple more weeks”?
Or maybe it was the supplier who sent a cryptic email three days ago stating that their systems were currently down without further explanations, and its other aspect: how did the attacker move so quickly between servers?
How did they control the machines? What happened?
But one thing is certain: after the feeling of being violated by the ransomware, having forensic investigators pulling your machines and logs apart is not going to feel any better.
Like a wildfire!
Once the main attack starts, that is when the threat actor starts encrypting the machine, things usually go very fast, and most of the machines connected to a corporate network can be encrypted in less than a couple of hours.
We often see this as the result of the threat actor taking the time to examine the systems and networks, to understand the relationships between machines, and to determine the places from where the attack will have the highest impact. Ironically, we have encountered cases where the threat actor seemed to have a better understanding of the network than the regular IT administrators.
With regards to the main attack, our investigation typically focuses on finding the accounts used by the threat actor, the mechanisms employed to move between machines, and the network indicators related to Command-And-Control servers, if any. This step is especially important as it yields the famous indicators of compromise (IOC), which are used in threat hunts.
Finding patient 0
In the digital forensic terminology, the patient 0 is the machine the threat actor first compromised: this is “through where they got into the network”. Often we find at the same time how this happened: did the threat actor use social engineering? Or did he exploit a vulnerability on an exposed server? Or maybe he stole credentials through phishing?
Typically, the search for patient 0 involves looking at how the threat actor moved from one system to another, the so-called “lateral movements.” We then unravel time until we cannot go further back or we find a totally different mechanism for the compromise: for example in many cases the lateral movement was done through PSEXEC/PSEXESVC, when we find a host on which the threat actor gained access through RDP, we know that it is patient 0, close to patient 0, or that that host has a special role in the attack.
To reimage or not to reimage
Soon the question will turn from “how did this happen?” to “how quickly can we go back to business?”, often followed by “what would you recommend us to resume business?”.
Our preference is always to reinstall from scratch: not from a backup but from the install media or from a golden image that is proven to have been untouched by the attaker. This “fresh start”, so to speak, limits the risk of re-triggering an infection or even to let something left by the attacker on a computer: in many recent attacks, we have found that the threat actor had replaced some system libraries and executable files. In that case, it may only be a matter of days or weeks before the computer reinfects itself, simply by accessing what should have been a system file, but that has been modified to contain instructions.
However, reinstalling is not always an option: in large cases, there may be hundreds or thousands of computers affected by the attack. there, reinstalling is simply not possible as it would require several weeks of downtime, not to mention that this may also entail re-creating configurations and profiles. Typically this leads to the second question: “how can we clean the systems?”
Unfortunately, there is no “one checklist to root the attacker out” or “magic bullet-point list of items to do” that will guarantee a system has effectively and actually been cleaned of infection, and knowing the extent of the modifications, the files added to the system, and the settings changed by the threat actor are the only ways of building such as list, and even then the list may be incomplete, for example a piece of malware may have survival mechanisms that will detect that the machine has been cleaned or is being cleaned, and trigger a defense mechanism, for example to reinfect the host.
When restarting afresh is not doable, we often end up recommending to re-deploy what can be, and install monitoring tools both on the network and on the hosts, and to monitor these tools for signs that indicate that unusual or non-authorized activities are taking place.
Going beyond the fortress mentality: adapting to a new cybersecurity paradigm
In the “good old days” or about 20 years ago, “being secure” meant “having an antivirus”. Then it became “in addition, having a firewall”, quickly followed by “stateful firewall”, “application aware firewall”, “endpoint protection suite”, “intrusion prevention systems”, “host intrusion prevention systems”. The common point was that it was believed a company could effectively have “enough security” to prevent an incident from happening.
This belief is no longer true, and actually has not been for a long time. Instead, cybersecurity experts advocate for a “defend-impede-detect-respond-restore” model. This model considers that security events and incidents are inevitable and that companies are better off preparing for it rather than to put all resources into avoiding an incident from happening in the first place.
In a few words, this model’s approach is to defend against the threats most likely to be faced by an entity, to configure the systems in a way that unusual or unexpected events are harder to perform, to have sensors to detect when events that should not happen have, to set up the mechanisms to quickly and effectively respond to said events, and lastly to be in a position to restore the systems to a known good state as well as all the data necessary to operate the business.
Contact LIFARS.com Immediately if you become victim of Ransomware.
How to protect your organization after a ransomware attack?
Resources:
Report Cyber Security Incident
Incident Response Retainer
Ransomware Advisory
Ransomware Response Guideline
Ransomware Response
