10 things you should know about Incident Response and Forensics in 2023

2022 in the cybersecurity consulting world has been absolutely intense. Still, there is room for cybersecurity posture improvement. Besides the regular penetration tests that we deliver, we have also dealt with too many incidents happening on the Customers’ side. Even though every story is unique, they all have a couple of things in common.

Here are the 10 things you should know about Incident Response and Forensics:

1. Incident response readiness is a key to successfully surviving the incident. That may sound like an obvious conclusion, however when looking into IBM research statistics, we learn that over 70% of organizations do not have an incident response plan in place. If an organization is hit by ransomware or data breach and it does not have a strategy to handle the aftermath, the consequences can be tragic. Components of the solid incident response plan include:

• Preparation of the incident response policy,
• Prioritizing the resources for recovery (Business Impact Analysis),
• Building the incident response team and supporting team,
• Defining incident communication,
• Compliance considerations,
• Appropriate hardware and software,
• Staff training.

2. Evidence collection procedure requires testing. There is nothing more ironic than a blue screen while collecting memory dump. Tools change. Although it seems to be very natural to download the most up-to-date tool to perform the evidence collection, it may cause more issues than using the older but tested set of tools. The advice is simple: prepare a set of tools for the evidence collection. For example, for a memory dump, you can use FTK Imager from Access Data, DumpIT from Matthieu Suiche, or Belkasoft RAM Capturer, for the disk image and analysis we usually use FTK Imager, Encase of X-Ways. Up to this point, we should add hardware or a place where evidence can be stored and later shared. This needs to be arranged in advance, as there is nothing worse than looking for free space on a random drive for evidence collection – especially during the incident.

3. Understanding what information we have. There is always something you can find. No monitoring does not mean no evidence. Believe it or not but in most cases we dealt with, there was a lack of central monitoring or monitoring at all. Keep looking – and you will find something. Great sources of information are: USN journal, event logs, Prefetch files, user accounts and current login information, running processes, the output of Autoruns (Sysinternals), information about running processes, drivers installed and running, services running, DLLs running, list of handles from processes, established network connections, scheduled tasks & jobs, installed software, compatibility cache, DNS cache, Automatic Destinations (LNK files), temporary internet files and cookies, remote desktop cache, shares, mapped drives, type and status of the antivirus, etc.

4. Understanding what information we need. A major part of incident response readiness is the identification of data that is needed to build a full incident picture. That includes rethinking what are the organization’s signaling events. Every time the identity is misused, and, for example, an attacker logs in somewhere with the stolen account, we should be alerted. During a post-incident analysis, we should be able to identify the path of how that identity was used. Another important factor is files that have been used during the attack, including executable files or scripts (exe, dll, vbs, ps1, etc.) that were launched. To understand activities, we need to track identity and processes at least.

5. Growing your threat hunting and forensic skillset to identify Indicators of Compromise. Identification of Indicators of Compromise (IoC) is a key factor to be able to contain the threat properly. If monitoring is not complete, then this activity requires a lot of manual work to be done to spot the occurrences. Frankly, this skill is always needed, even for the moments when you are not sure whether there is something going or not. It is important to note that when the attack signals are received, the actions taken do not destroy the evidence or do not cause the attack’s spreading. Starting with the account lockouts, strange computer behavior, unidentified network communication, all these alerts first get to the helpdesk / SOC. This first line of support needs to be in line with the incident response team, to make sure that when helping users, the evidence is not destroyed.

6. Planning for automatic containment and remediation. When it is already clear what is going on, a quick reaction is a priority. When your environment consists of thousands of workstations and servers, it is crucial to be able to contain the incident in just a couple of clicks. Unfortunately, the affected machines quite often need to be isolated either completely or partly, being available only through a controlled and limited channel. If so, then what is the possibility of fixing these machines, could you enforce some configuration settings on them? Another aspect is reporting. At some point, you would need to know if the machine was cleaned.

7. Importance of team commitment and composition. Incident Response Team (IRT) has to be created before the incident happens. IRT has one chair, usually a senior security analyst or CISO. IRT Manager coordinates action with stakeholders, helping other IRT members to perform their tasks, so there is a requirement of having good communication skills. Whoever manages the incident has to have high credibility within the organization, both for competence and excellent communication skills.

Enough technical background to understand the situation is necessary as well. We have been also in situations where an incident was going on, but a bigger part or even the entire team left the building as work time was over. It has to be arranged that people are willing to stay overtime and appropriate conditions need to be provided. Staff designated to respond to incidents need to have the capability to learn during the incidents, so you need to make sure that there is always a post-incident follow-up training arranged. Responsibilities of the incident responders are:

• Quickly identifying threats to the infrastructure,
• Assessing the level of risk based on own experience,
• Collecting evidence,
• Taking immediate steps to mitigate risks,
• Notifying management about the status and associated risk,
• Issuing a report, including lessons learned.

8. Lack of tools for communicating and escalating. When an incident occurs in your organization, you need to be able to communicate effectively with everyone, not only with employees involved in some required actions. It all depends on getting in touch with the right people. Therefore, it is important to set up the best communication channels in advance to reach people, raise the incident information portal, send SMSs to all employees, use chat apps, and set up the portal to exchange data like memory and disk dumps. In communication with the public, a supporting team is advisable. You may want to involve media relations, legal counsel, and sometimes law enforcement, depending on the scale of the incident.

9. Risk assessment of data and credential leakage. As always, to gain more insights, we need the appropriate monitoring capability. It is important to look at this situation from a slightly different angle. Even if there is simply an obfuscated exe running and it can be evaluated what places it reached (USN journal), you still need to be able to access what types of credentials potentially leaked. In short words – most of our secrets are protected by Data Protection API (Windows).

There are a few risks we must remember when talking about DPAPI. Firstly, one thing is obvious, if someone would gain access to our session, the secrets are exposed, because we are the ones who are permitted to view them (and we do not have to provide our password every time DPAPI decrypts our secrets). Secondly, without the user’s password, the secrets of the local user will not be able to decrypt (the exception is when hackers use hiberfil.sys).

Even if someone with e.g., local administrator privileges will change the user password (and in effect will know its plaintext value), they would not be able to recover the secrets, as the master key will be protected by the key derived from the old password. Not only is this something to remember in terms of the attackers, but keep in mind, that if you reset the password of a local account as an admin, DPAPI-protected secrets will become useless, which sometimes affects the analysis.

And one more very important thing, in the case of domain accounts and Active Directory, we need to remember, that the master keys of all domain users in the organization can be decrypted by hidden certificates stored in AD. As a result, in the case of domain accounts, having sufficient privileges attacker (or “evil” administrator) can also get access to our secrets.

10. Backups and backup resources. In terms of backups, we need to define whom we are going to call if the administrator of that database is not available. Some teams are bigger, and they have several people engaged in the administration of the same resource. Some companies are smaller and there needs to be cooperation established with some managed service provider that can (with a certain SLA) respond to our requests. The conclusion here is simple: identify the resources that cannot be recovered quickly and identify hidden dependencies that can disrupt smooth recovery and support.

Summary and preparation for the aftermath. The incident response does not end with the incident itself; it is just the beginning. It is crucial to ensure that the organization learns from the incident and that proper post-incident analysis is performed. It is also important to prepare a report for stakeholders, including a summary of the incident, actions taken, and recommendations for future improvements. Additionally, legal and regulatory requirements must be considered, including data breach notification laws and other compliance obligations.