Cyber incident needs a strong response – Who you gonna call?

The Nixu Digital Forensics & Incident Response (DFIR) team is a team dedicated to Incident Response investigations. Basically, the team is the one that comes to the scene when the roof is on fire – like the firemen – but with a difference compared to law enforcement: officials investigate the devices that have been used by the threat actor, and the incident responders are usually investigating the devices of the victims.

The DFIR team is working 24/7, so should you need to use our services, we would be there for you when the incident happens – not a day or two after. This is very important in case of an emergency because a cyber attack might spread just like the before-mentioned fire. We've been in many situations where there has been a chance that a slow adaptation to a cyber attack could have caused a massive ransomware outbreak. This is especially true when the bad guys – often called threat actors – have been introducing what I like to call the "drive-by-encryption" method. What I mean by this is that the threat actors are very fast, and often the encryption starts quickly after the environment has been breached. Sometimes in a matter of hours.

As the DFIR is a very specific thing and requires a quite high level of understanding of computer forensics, it is often not viable to have your own in-house team for this. The incident responders are (hopefully) not needed that often in a single company environment, which makes it often more efficient from the business perspective to buy this as a service. Again, just like the firemen: very seldom do you run a company that would need their own fire brigade, even though those companies do exist. The Nixu DFIR team's main responsibility is the actual incident response cases, with which the team members are working on a daily basis. This keeps the team's required skills sharp, and also gives visibility to the current trends in our customer space.

Case example

One of the investigations that the team has been involved with was a ransomware attack. The customer environment had been encrypted by a threat actor, at least partly. The Nixu DFIR team was included in the investigation only after the encryption had occurred and the team had the task of investigating how the threat actor got in, what was the scope of the attack, and if they were able to exfiltrate data from the environment before the encryption started.

The threat actor was able to use a publicly available remote access service (a service that allows employees to connect to internal services over the internet) to access the network. The Nixu team was able to pinpoint that the threat actor had initially accessed the environment two weeks prior to the encryption. Interestingly, after the initial access, the threat actor was idle for some time before they continued the attack, trusting that the credentials that they had would not be reset. This was the case, and after some time of idling, the threat actor started the actual attack. This is a common phenomenon, and the understanding is that there might be a switch of teams. One team to breach, another to do the job – the threat actors also have their own specializations. There are also other reasons, like statutory holidays. The threat actors might be on vacation, and thus the attack can be paused for days.

At the very beginning of the attack, the threat actor utilized a lot of native/built-in Windows tools. They were able to compromise accounts, which held enough administrative permissions, to move laterally on to different servers. They were scanning the environment, looking for potential targets for their attack. While having hands-on keyboard access, the threat actor was able to move throughout the company's network. This approach was somewhat fruitful for the threat actor, as they were able to find some data that might have some additional value to them, and the data was then exfiltrated out of the network. After some of the data had been exfiltrated, the threat actor started to encrypt the environment, at least the devices that they had currently access to.

Although the threat actor was able to steal data and encrypt the environment partly, the attack wasn't as devastating as it could have been. Fortunately, the threat actor was only able to access the subnet to which they had the initial access. There were many other subnets, to which the threat actor was not able to move. This meant for the customer that only a small portion of their entire environment was affected. Although this had a big effect on the environment, it could have been much worse. Much, much worse.

As these situations are not daily bread and butter for our clients, they asked the Nixu DFIR team to take the lead in the technical investigation of the incident. The team investigated the modus operandi and was able to discover and pinpoint the attack path and also prove the amount of data that was exfiltrated from the environment. While investigating, the scope of the attack was identified, and steps to contain the situation were planned in cooperation with the client. The steps were efficiently launched by the client's technical personnel with the aim of containing the threat, and stopping the threat actor from accessing the environment anymore. During the investigation, the persistence methods used by the threat actor were found, and the threat actor was eradicated from the environment. The recovery was done according to the recommendations of the Nixu DFIR team. The incident report, which was released by the Nixu DFIR team, included many recommendations that the client could use to bolster their environment and stop this kind of attack from happening again. As Nixu has a broad security offering, we are happy to help in implementing the recommendations after the investigation has closed.

During the last year, we've experienced quite a lot of attacks, which have started by utilizing publicly available services of the companies. The common factor is that the services have been left without multi-factor authentication, which again has enabled relatively easy access for the threat actors. This was just one example, but we've seen many incidents where a similar attack vector has been utilized. Folks, do remember to enable MFA!

What do you get from the Nixu Incident Response services?

What we offer is a dedicated Digital Forensics and Incident Response team – available with a single phone call. The team has been working on thousands of different incident response investigations; some small and some very large. The team is very experienced in technical incident response investigations and easily adapts to different environments. The team will help the clients throughout the incident response process, every step of the way.

Although the main competence of the team is with the technical investigation of the incidents, we can also take the role of Lead Incident Handler, having the responsibility of coordinating the incident handling activities. Some members of the team are particularly experienced in dealing with the tough situations, and also able to point out relevant actions to potential third-party providers when needed. When thinking of the traditional 6-step incident response process, the Nixu DFIR team usually takes action already in the identification phase. After identifying the security incident, Nixu will help the clients in assessing the situation. After this, the incident response process steps will be followed in cooperation with the client's personnel. The diagram below presents how the Nixu DFIR team can help when there is an incident.

Diagram showing the incident response process steps and how Nixu DFIR can help in each of the steps.

While the investigation is ongoing, the Nixu DFIR team will also be constantly reporting on the progress of the investigation. Often this is done in daily catch-up meetings, although in some investigations, this might be too often – or even too seldom. The investigation is documented in a Nixu-provided platform, to which the client also has access. This allows for cooperation in the investigations, especially when multiple service providers are involved. Also, in some situations, the customer's own systems could be compromised and should thus not be used. When the investigation is concluded, the team writes an incident report of the investigation. The report includes a section especially tailored for less technical personnel. The main report includes the technical details and findings from the technical investigation.

The nature of the work has been changing over the last couple of years, and most of the work is nowadays done remotely. This makes the response much faster, as the whole disk images often don't have to be acquired, rather only the specific evidence is gathered from the affected endpoints.  The team also has its own tooling, which enables remote incident response. Although, they are able to use some of the client's own if there is tooling already in place. Especially the different kinds of endpoint detection and response tools can help in investigations if they have been in place already when the incident happened. If an agent is installed afterwards, it often lacks the crucial evidence – that's when the more traditional evidence will come in handy.

On a closing note, I've been included in hundreds of incident response cases during my career. One of the things that I have learned visibility-wise is that often the data is lacking. Having Endpoint Detection and Response (EDR) in place to tackle this issue is great, but it is not always plausible for the companies. If this is the case, I recommend installing Sysmon to all of the endpoints. Sysmon is a free tool from Microsoft that enhances the Windows Operating System logging capabilities to include a lot more interesting details from a forensics perspective. It is great if the logs can be shipped to a central location, however even having the agent logging locally can help in many cases – unless the logs are cleared by the threat actor of course. We are obviously happy to help you before the incident to prevent it or maximize the possibilities of succeeding in the incident response and investigation.

Who you gonna call?
 

Author: Jouni Mikkola, Nixu, DFIR Team Lead