Inhalt
Forensic readiness refers to a company’s ability to carry out digital forensics efficiently. Every incident is a stressful situation for everyone involved. A high degree of maturity in forensic readiness can shorten the analysis time of incidents and increase the quality of statements about the incident.
As with the handling of incidents, many different stakeholders and perspectives are involved in the preparation process. Forensic readiness can therefore be divided into several pillars and phases, as shown in the following diagram.
This article only looks at the requirements for Windows clients that make the analysis process more efficient. In addition to these technical requirements, there are also requirements for personnel and the processes used, for example. These topics will be described in more detail in future articles. In addition, the technical requirements for other operating systems and cloud services, for example, will also be described in future articles.
In summary, this means that forensic readiness basically pursues 2 objectives:
- Reduce the costs of digital forensics.
- Improve the possibilities and increase the probabilities of including relevant artifacts in the analysis to increase the informative value of digital forensics
As this graphic shows, forensic readiness can be viewed from different angles. In this article, we will focus exclusively on the topic of technology and specifically on the data basis.
Why do I need it?
Specifically, the degree of forensic readiness of your company has the following effects:
- If you have cyber risk insurance , you are usually obliged to provide all the necessary evidence so that external forensic experts can reconstruct the case in order to prepare a report for the insurance company. On the basis of this report, the insurance company decides on the payment and the amount of the payment. It is therefore in your interest to provide all the necessary data and to enable a complete reconstruction of the case in order to fulfill your obligation to cooperate.
- If you are affected by an incident, you may have to shut down your IT systems or even stop production as part of the incident response. To keep downtime to a minimum, it must be possible to carry out the analysis quickly and efficiently. This is only possible if you have a certain level of maturity in your forensic readiness. In addition, partners/suppliers of the affected company often need precise information about the impact of the incident in order to decide whether, for example, VPN tunnels need to be reactivated so that daily business can continue.
- In addition, you may be affected by compliance requirements that require forensic analysis. For example, the Digital Operational Resilience Act (DORA) defines a reporting obligation for serious incidents. A detailed forensic analysis is often required to classify the incident, which can only be achieved with the required forensic readiness. The same applies to the NIS-2 regulation, which still requires a final report.
Forensic readiness in the Windows environment
Since Windows systems make up the majority of operating systems in the corporate context, prioritization is necessary here. Windows systems offer many opportunities to improve the quantity and quality of forensic artifacts. The following checklist serves to activate the generation of these artifacts and to improve their quality. Initially, only Windows clients are considered, as servers sometimes have different requirements and application-specific log files often also need to be considered.
Eventlogs
Windows eventlogs form the basis of every forensic investigation. The eventlogs contain a lot of relevant information about events that take place on the system. The eventlogs are divided into several files (so-called channels) that log different events. Although many events are logged by default, some important events are missing.
Process Creation
Windows does not log the creation of new processes by default. As processes are one of the most important aspects of a forensic investigation, this entry should be activated as a matter of urgency. In addition, the logging of the complete command line should be activated. This drastically increases the information content, as in many cases the mere start of a process is of very little significance if it is not known with which parameters it was started. This is particularly relevant for so-called LOLBas programs , which are often used by attackers. The logs are logged by the Security Channel under the event ID 4688.
Outgoing network connections
Attackers need to communicate with other internal systems to spread, or with their own systems to reload tools and receive commands. For this reason, the logs of network connections are also essential for forensic analysis. The logs are logged by the Security Channel under the event ID 5156. The event also contains the process name and the process ID of the process that initiated the connection and can therefore be correlated with the event ID 4688
Execution of PowerShell
PowerShell is a powerful tool for administrators, but also for attackers, as can be seen in a threat report by Red Canary from 2023 (https://redcanary.com/threat-detection-report/techniques/). Due to the great functionality of PowerShell, attackers also like to use this tool. By default, PowerShell logging is not very meaningful, but Microsoft offers several ways to improve this. Specifically, PowerShell can be logged in 4 places, the PowerShell Logs, the Script Block Logging, the Transcription Logging and the Module Logging. Each of these logs has its pros and cons, but it is recommended to enable all of them.
Defender Logs
Every Windows client is delivered with a stripped-down version of Microsoft Defender. If no dedicated antivirus or EDR tool is used in the company, Microsoft Defender should remain activated. As soon as Defender detects a threat, an alarm is generated in the Defender log. Even if the detections here are rather rudimentary, relevant events are often recorded in the dedicated “Defender Operational” channel, which is analyzed in every incident. If another security tool is used, it must be ensured that the tool logs events and, if possible, in a usable format.
An alternative is the use of Sysmon. Sysmon is part of the Sysinternals suite and offers many helpful events that can be used for analysis and potentially forwarded to a SIEM. Sysmon offers far more possibilities than classic event logs, e.g. changes in the registry can also be logged. Sysmon uses a configuration file to determine what should be logged. If you are not quite sure what is required, the following configurations are recommended as a starting point https://github.com/olafhartong/sysmon-modular and https://github.com/Neo23x0/sysmon-config
In addition to activating the various logs, you should also pay attention to the log size. Each log file has a maximum log size. Once this is reached, older entries are deleted to make room for new entries. The default size of the logs is too small, so that even small delays in the preservation of evidence can lead to relevant information no longer being available. The size should therefore be increased. In principle, the aim should be for the logs to remain on the device for at least 2 to 4 weeks before they are rotated. The resulting size of the logs depends on the company; it is recommended to set the size to at least 2 GB.
Further artifacts
In addition to the event logs described, there are other interesting artifacts, the Program Compability Assistant (PCA) and the Background Activity Monitor (BAM). Both artifacts record the execution of processes and are therefore very relevant for any forensic analysis. Both artifacts are activated by default if the Windows system has the required version. This is Windows 10 Update 1709 for BAM and Windows 11 22H2 for PCA. It is therefore recommended to keep all clients on the latest version of the operating system . Although information about the execution of processes is already covered by the event ID 4688, it is advisable to have this information in several places, as attackers like to delete event logs to cover their tracks.
At this point, the question may arise as to whether such information is not already available in a SIEM or EDR, for example, and why redundant information needs to be available on the endpoints. There are several answers to this:
- The data in the SIEM/EDR may be incomplete. With a SIEM, for example, it should always be borne in mind that a larger volume of data also results in higher costs. EDRs work with their own telemetry, which is also incomplete. (see the following overview https://github.com/tsale/EDR-Telemetry).
- Attackers can, for example, “blind” EDRs or stop data transmission to SIEMs. Even if such techniques are not used by every attacker and are not trivial, as EDRs, for example, can protect themselves against them, a telemetry failure can conceal crucial information: https://www.huntress.com/blog/silencing-the-edr-silencers
- For a forensic analysis, it is helpful if all the data is in one place, namely in the system itself. Otherwise, the forensic analysis has to correlate data from several sources, which means additional effort.
Conclusion
Forensic readiness makes it possible to carry out in-depth forensic analyses and understand exactly what happened. In many cases, creating the necessary data sources is a one-off effort that pays off in the event of an incident.
While this article provides an insight into the technical forensic readiness of Windows clients , other operating systems and cloud providers will be described in more detail in the following articles.
Forensic readiness is a crucial factor in preparing your company for potential incidents and increasing the efficiency and validity of digital forensics. Early and comprehensive preparation can not only reduce costs, but also ensure that important evidence is available quickly and completely. If you need support in implementing forensic readiness in your company or have any questions, we will be happy to assist you. Do not hesitate to contact us – we are always here for you!
