People responsible for computer security incident response and digital forensic examination need to continually update their skills, tools, and knowledge to keep pace with changing technology. No longer able to simply unplug a computer and evaluate it later, examiners must know how to capture an image of the running memory and perform volatile memory analysis using various tools, such as PsList, ListDLLs, Handle, Netstat, FPort, Userdump, Strings, and PSLoggedOn. This paper presents a live response scenario and compares various approaches and tools used tocapture and analyze evidence from computer memory.
Live response gives security operations teams instantaneous access to a device (also referred to as a machine) using a remote shell connection. This gives you the power to do in-depth investigative work and take immediate response actions to promptly contain identified threats in real time.
Live response is designed to enhance investigations by enabling your security operations team to collect forensic data, run scripts, send suspicious entities for analysis, remediate threats, and proactively hunt for emerging threats.
As in [
In [
Authors of [
All of this suggests that the problem of choice and optimizing between live response and static analysis is quite extensive in the tasks of computer forensics.
During initiation of a live response session on a device, a dashboard opens. The dashboard provides information about the session such as the following: ● Who created the session ● When the session started ● The duration of the session The dashboard also gives you access to: ● Disconnect session ● Upload files to the library ● Command console ● Command log 2.2.
Initiation of a live response session on a device (Windows platform) ● Sign in to Microsoft 365 Defender portal. ● Navigate to Endpoints > Device inventory and select a device to investigate. The devices page opens. ● Launch the live response session by selecting Initiate live response session. A command console is displayed. Wait while the session connects to the device. ● Use the built-in commands to do investigative work. For more information, see Live response commands.
● After completing your investigation, select Disconnect session, then select Confirm. 2.3.
The traceability matrix of Table 1 is a mapping of the capabilities of live response and memory analysis tools during an investigation of a memory image (or running memory). The Live Response part of Figure 1 lists the tools used in live response, and the Memory Analysis part shows tools that analyze physical memory dumps. This section contains hints for creating and maintaining Word files and suggestions for avoiding common mistakes.
In our virtual environment scenario, we start with a Windows XP Service Pack 2 virtual machine with an IP address of 192.168.203.132. Netcat was used to establish a telnet connection on port 4444 (PID: 3572) with a second machine at 192.168.203.133. MACSpoof was also installed and running (PID: 3008). This machine was then compromised by installing the FUTo rootkit and a ProRat server listening on port 5110. The netcat and MACSpoof processes were then hidden using the FUTo rootkit. In the following sections, we present two possible techniques to approach the compromised system and we discuss what details are visible and invisible concerning the various compromises using each approach. The first approach we present is a live response process using sys-internal style tools. The second is a static memory dump analysis using open source memory analysis tools. Finally, we discuss the benefits and drawbacks of both approaches. 2.4.
The first approach is live response. Here an investigator would first establish a trusted command shell. In addition, they would establish a method for transmitting and storing the information on a data collection system of some sort. One option is to redirect the output of the commands on the compromised system to the data collection system. One popular tool is netcat, a network utility that transmits data across network connections. Another approach would be to insert a USB drive and write all query results to that external drive. Finally, investigators would attempt to bolster the credibility of the tool output in court. During a live interrogation of a system, it is important to realize that the state of the running machine is not static. This could lead to the same query producing different results based on when it is run. Therefore, hashing the memory is not effective. Rather, an investigator could compute a cryptographic checksum of the tool outputs and make a note of this hash value in the log. This would help dispel any notion that the results had been altered after the fact. In this exercise, HELIX (a live response and Linux bootable CD), was used to establish a trusted command shell.
Once the above data collection setup is complete, an investigator can begin to collect evidence from the compromised system. The sys-internal style tools used in this exercise are not meant to be an exhaustive list. Rather, they are representative of the types of tools available. The common thread for the tools used is that each relies on native API calls to some degree, and thus the results are filtered through the operating system. The tools used in this case were PsList, ListDLLs, Handle, Netstat, FPort, Userdump, Strings, and PSLoggedOn.
PsList allows investigators to view process and thread statistics on a system. Applying PsList reveals all running processes on the system but does not reveal the presence of the rootkit or the other processes that the rootkit has hidden (netcat and MACSpoof).
ListDLLs allows investigators to view the currently loaded DLLs for a process. Applying ListDLLs reveals the DLLs loaded by all running processes. However, since there are processes that are hidden, ListDLLs cannot show the DLLs loaded for them. Thus, critical evidence that could reveal the presence of the rootkit is missed. The problem is that an attacker may have compromised the Windows API upon which an investigator’s toolkit depends. To a degree, this is the case with our scenario. As a result, rootkit manipulation cannot be easily detected with these tools. A more sophisticated and nonintrusive approach is necessary to find what could be critical evidence.
The Handle utility allows investigators to view open handles for any process. It reveals the open files for all the running processes, which includes the path to the file. In this case, one of the сommand shells is running from a directory labeled …\FUTo\EXE. This is a strong hint of the presence of the FUTo rootkit. Similarly, there is another instance of cmd.exe running from C:\tools\nc11nt. The nc11nt folder is a default for the windows distribution of netcat. While it is useful to show the implications of the tool results, it is important to remember that simply renaming these directories or running the cmd.exe from a different directory would have prevented these disclosures.
The Netstat utility allows investigators to view the network connections of a running machine. Nestat (with the –an option) reveals nothing immediately suspicious in this case.
Thus far, was described incident response approaches to the scenario discussed. The approach is the well-known live response where an investigator surveys the crime scene, collects the evidence, and at the same time probes for suspicious activity. The approach is the relatively new field of volatile memory analysis where an investigator collects the memory dump and performs analysis in an isolated environment. In different approaches, was described what types of information gave an investigator insight into the scenario. Now, it will be discussed some of the issues with live response that hinder effective analysis of a digital crime scene. It also will be discussed why volatile memory analysis should be the ideal approach to investigating cyber crime. While the purpose of live response is to collect all relevant evidence from the system that will likely be used to confirm whether an incident occurred, the implementation of the process has significant setbacks, including the following: ● First Responder toolkit may rely on Windows API: The problem is that if an attacker compromises the system and changes system files without an investigator suspecting, then an investigator could collect a large amount of evidence that is based on compromised sources. As a result, this would damage the credibility of the analysis in a court of law. ● Live response is not repeatable: The information in memory is volatile and with every passing second, bytes are being overwritten. As we saw in our scenario, the tools may produce the correct output and in themselves can be verified by a third-party expert. However, the input data supplied to them can never be reproduced. As a result, this puts the evidence collected at risk in a court of law. Therefore, it becomes difficult for investigators to prove the correctness of their analysis of the evidence. [Walters 2007]. ● Investigators cannot ask new questions later: The live response process does not support examination of the evidence in a new way. This is mainly because the same inputs to the tools from the collection phase cannot be reproduced. As a result, investigators cannot ask new questions later on in the analysis phase of the investigation [Walters 2007]. By the analysis phase, it becomes impossible to learn anything new about the compromise. In addition, as we saw in our scenario, once critical evidence is missed during collection, it can never be recovered again. It damages the case against the attacker.
On the other hand, a volatile memory analysis shows promise in that the only source of evidence is the physical memory dump. Moreover, collection of physical memory has become more commonly practiced. An investigator can then build the case by analyzing the memory dump in an isolated environment that is non-obtrusive to the evidence. Thus, volatile memory analysis addresses the drawbacks facing live response as follows: ● It limits impact to the compromised system: Unlike live response, memory analysis uses a simplified approach to investigating a crime scene. It involves merely extracting the memory dump and minimizes the fingerprint left on the compromised system. In addition, the nature of live response puts the analysis of the evidence at risk in a court of law. As a result, an investigator gets the added benefit of analyzing the memory dump fully confident that the impact to the data is minimal. ● Analysis is repeatable: Since the memory dumps are analyzed directly and in isolated environments, this allows for multiple sources to validate and repeat the analysis. We saw this in our scenario, where the hidden malware processes were identified by the two tools. In addition, it allows for conclusions made by investigators to be verified by third-party experts. Essentially, it improves the credibility of the analysis in a court of law. ● Nature of analysis supports asking new questions later: Contrary to live response, memory analysis allows investigators with more expertise, technique, or understanding to ask new questions later on in the investigation [Walters 2007]. We saw this in our scenario. Our initial analysis of the memory dump with Volatility gave us some suspicion of a rootkit being present on the system. We later confirmed this with evidence of the terminated rootkit process using the Lsproc script. This important evidence may have been missed in a live response.
One of the greatest drawbacks with volatile memory analysis is that the tools’ support has not matured enough. This is because with every release of a new operating system, the physical memory structure changes. Development of memory analysis tools has been gaining velocity recently, but the kinks still remain. This is an emerging field and new ground is being broken across the area of study.
The work was carried out using the equipment of the Center for Collective Use of North-Caucasus Federal University with financial support from the Ministry of Science and Higher Education of Russian Federation, unique project identifier RF —— 2296.61321X0029 (agreement no. 075-152021-687).