Following in the wake of the articles developed to shed light on incident response in our group, it seems clear that the actions required to deploy ransomware with the maximum impact desired by the attacker require different phases and different states of compromise.
These phases start with an initial compromise of some asset of the organisation, which the adversary skilfully exploits to gain power over the infrastructure and eventually deploy the final artefact that is responsible for encrypting and leaving the ransom notes.
Usually, the mission of a “Threat Hunter” is to focus on locating these previous phases that the adversaries carry out (and the earlier this phase is detected, the better) to be able to solve and/or mitigate the incident produced with no or very minimised impact with respect to what a ransomware incident is.
So how can threat hunting add value when the incident is already complete?
A Threat Hunter is an analyst specialised in investigating various sources of information from the organisation’s infrastructure to extract threat data.
These threats are detected in the different anomalies caused by an adversary in the normal operation of the different assets. These anomalies are known and detected by the “Threat Hunter” in the information provided by tools such as EDR, XDR, SIEM, UEBA, etc., which provide the necessary context to differentiate between what is normal operation and what is not.
If this same process is adapted to incident response, the result is a flow of information that is fed back by the sharing of findings between the different roles. What a forensic officer finds can be investigated by the Threat Hunter to see in the EDR or SIEM how it got to that machine, from where and on how many other machines it has been seen. In turn, giving the forensic scientist new information (feedback) on the course of the incident, allowing the different lines of investigation to be accelerated (and containment to be better adjusted, in many cases).
Following these investigations with the data obtained by the Cyberintelligence team (as we saw in the previous post), the Threat Hunter will return to the rest of the team the different findings that will help this part of the team to advance quickly in the classification of the adversary. This allows them to know crucial data such as whether there is a site where data leaked by the attackers will be published or what other tools they may have used in the specific scenario, as they will have been seen in other incidents carried out by this same group.
But it does not only allow the incident response team to move faster in their respective tasks. The fact that they are actively investigating the behaviour of the machines in the organisation and with the different indicators of compromise (IOCs) available, allows the organisation to quickly bring up services that can be confirmed to be unaffected and the safe start-up of those affected by blocking the malicious artefacts already identified through EDR.
Acting from EDR for all assets
As mentioned above, the incident response is largely “EDR-centric”. The actions that the Threat Hunter performs on this platform are diverse:
- Evidence retrieval. Thanks to an EDR, it is possible to connect to the machines of interest and retrieve information directly from them, making it possible to obtain artefacts without the need to use the time of other technical groups in the organisation (given the situation, they usually have a much higher workload than normal).
- Event investigation. An EDR also provides telemetry on the machines on which the corresponding agent is running. This telemetry makes it possible to investigate artefact executions, understand the creation of artefacts, remove malicious files, trace connections created by each executed process and, among other things, detect the persistence of different software elements or malware. All this provides a very complete context of operation in which attack patterns can be studied in an optimal way.
- Asset isolation. As telemetry is investigated, it is possible to isolate those assets within the network that present malicious or clearly suspicious behaviours; at the same time, allowing the normal operation of those elements that have not been affected.
- Blocking of IOCs and creation of rules. Two of the most interesting results of the research are the Indicators of Compromise (IOCs) and the rules for the behaviour of the adversary in the incident. Both elements can be easily configured in the platform for automatic blocking and warning. So that if the adversary had left a logical bomb or maintained access with some persistence that relaunched the attack, it would be automatically blocked by the EDR as this configuration has previously been done.
Handing the baton back to the organisation
During the incident response, the team will ensure that the adversary has been successfully ejected and the incident has been resolved at all levels.
In that purpose, the Threat Hunter will be responsible for monitoring that the information produced by the EDR system “shows calm” and that no new activity related to the incident is present on any machine in the infrastructure.
To this end, any anomalous behaviour will be monitored and the different necessary alerts will be configured in the event that the incident is reproduced or that any machine may have activity (in order to automatically isolate that activity and continue with the recovery).
After a reasonable time in which it will be verified that there is no new relevant activity (normally one month since the incident), the Threat Hunter’s work will be terminated, returning the control to the client organisation or group of assigned EDR services.
