Besides the essential tools, including hardware and software, which will be discussed later, there are some other factors to consider while building the lab. The investigator usually will spend a long time in the lab workspace. So, it should be comfortable enough and they must have full control over its environment. In the next section, we will highlight some factors that need to be considered in the planning phase.
It is always a good idea to prepare for future expansion while planning for the lab from the beginning. If you are expecting an expansion, for example, the number of current team members will be raised by 50% in two years, you will need to consider a larger lab size in the planning phase so that you can have all your members working in the same place, instead of two separate locations.
Suitable lab size can be affected by the following factors:
The number of the investigators working concurrently, and the overlapping between different work shifts if any
Besides the size of the hardware tools that could occupy large space in the lab, the size of the evidence could be large enough to occupy additional space in the lab in case you don't plan to have a separate locked evidence storage room
During the acquisition and analysis phases, some disassembly work can take place in the lab; thus, having a separate workbench for such tasks will be better for the sake of lab organization
All these points must be considered while asking for lab size.
Many devices that will be running in the lab will generate a lot of heat. Controlling the room temperature and keeping it at an acceptable level will prevent the devices from failure due to overheating, and it will make the lab comfortable for team members.
Besides the digital evidence acquisition process, which is a time-consuming process because it may take hours to image some evidence, the analysis process itself may take longer time in some processes, such as Indexing. During the lab planning, considering an alternative power source and a backup power plan along with a reliable main power source to keep all these processes to continue without interruption is critical to save time and keep operations smooth.
In some environments with a big number of cases received in parallel, it will be hard to follow up with these cases and their progresses without automated management software. To control the workflow and prevent unauthorized access, a case management system that provides administrative control over the cases and the ability to assign access to investigators to work on specific cases must be installed in the lab. The management system can measure the work progress, and they can create statistics about workflow to notice weaknesses for future improvements.
Usually, cases in the lab are related to criminal actions. This makes it important to secure the working location from any physical or virtual unauthorized access to prevent any possible manipulation to the evidence or the analysis results. The physical location of the lab needs to be chosen with care. These are some of the parameters that are needed to maintain physical security:
The ground floor in your building is easier to access for outsiders. Locating the lab at a higher floor in a no-windows room will help in access control and in preventing eavesdropping, recording, or breaking into the lab.
The room's walls must be toughened. Having very advanced room access controls, but gypsum board walls, is not a very good idea.
The basic security solutions, such as keeping access logs with time stamps, cameras, and security personnel must be provided if the lab is not already in a secured facility.
Most digital forensics phases don't require an Internet connection to run. Disconnecting the lab from the Internet is favorable for secrecy and to prevent infections or unwanted remote control by offenders who can change case results or damage evidence. However, some tasks will require an Internet connection such, as software updates. The lab should be provided with two separate networks, where one locally connects the analysis workstations, and the other one connects other computers to the Internet for daily research and updates and is provided with security solutions to help in preventing unauthorized access from the internet to the lab network.
During this book's chapters, we chose to use all very effective, either free or open source tools in the wild. However, there are many commercial tools that can be purchased and added to the digital forensics lab in order to verify the results or perform some tasks in parallel.
Before using any tool, a verification process must take place first. We will verify the tool's functions by running this tool against preanalyzed evidence to make sure that it will produce the same results. After the tool passes this test, we can rely on its results in the future. An example of such tests is the acquisition process, where we calculate the hash of a resulted image from the new tool and compare it with the hash that we previously had for this evidence from the verified tool. If the hash differs, it means that this tools doesn't create a forensic image correctly, and we must not use it.
Also, verifying the results by different tools is a great way to be certain of the results that will be reported, especially for the sensitive cases, which required many analysis steps that depends on each other.
The tools required in the digital forensics lab usually categorized, but not limited, to the following categories:
Incident response, including live analysis and evidence acquisition for different platforms
Data recovery
Media recovery
Password recovery
E-mail investigations
Memory analysis
Network forensics
Browser investigation
Mobile forensics
Internet investigation
Note that some tools don't support all known filesystems, so you need to have different tools that understand and parse different filesystems (FAT, NTFS, EXT, UFS, and HFS).
Due to the acquisition and the processing of large amounts of data in digital forensics, the analysis requires very powerful workstations. Some people prefer to work on servers, which will provide sufficient resources, including memory, processor, and storage.
Today, the budget to build a powerful machine is the limit. The more powerful machine you build, the more time you will save during analysis. Also, the reliability of the machine is very important. It will be very frustrating to work on a task for long time, then the machine fails and you lose all the work. For this reason, usually the forensics workstations come with a Xeon processor that is more reliable for such tasks.
Having multioperating systems is mandatory in digital forensics, such as different Windows versions and different Linux and UNIX distributions. Instead of having single machine for each operating system, virtualization gives us the ability to build different operating systems on the main operating system. In this section, we will briefly discuss the virtualization concept:
Figure 1: The virtualization blocks
In virtualization, what is actually virtualized is the computer hardware. Normally on the same hardware, we can't run more than one operating system concurrently. However, by adding an extra layer of software over the running operating system, called the virtualization solution, a virtual hardware will appear to be ready to install the new operating system. The new hardware is, of course, part of the main computer hardware, but virtually assigned to the new operating system. Every new virtual machine consumes part of the original machine resources.
The main operating system is called the HOST machine and any created operating system is called the GUEST virtual machine. The host shares all the computer resources with the Guests, even the network connection. As we can see in Figure 1, a virtual network connection can connect all the machines together with the Host and with each other. Also, a connection can only be shared with two Guests without the Host or between the Host OS with one Guest without the other. Many possibilities can take place in this approach. Sharing folders and files between the host and the guests is also applicable.
Note
Backing up the guest virtual machine is very easy with virtualization. To back up a system, we need to take what is called a snapshot. A snapshot is a copy of the machine status at a specific time, including the hard disk changes and the memory. If the user decided to retrieve a previously taken snapshot without taking another snapshot of the machine, all the changes that took place from the last snapshot will be lost.
This is why virtualization provides a controlled environment, as this is needed during the analysis for testing or to run malicious code and monitor its behavior in what is called dynamic or behavior malware analysis. The investigator needs to take a snapshot before executing the malware, execute and test the malware, and then recover the system from the snapshot.
In virtualization, everything is a file parsed by the Host operating system, including the hard disk and the memory. This makes the acquisition process much easier. If the case under investigation is related to a virtual system, the acquisition of memory, for example, will be just copying the memory file.
If the machine has previous snapshots, this will provide the investigator with different statuses of the machine from different times in the past, where the investigator can follow the machine's behavior to detect when the machine was, for instance, infected or compromised.
Every virtual machine has different files, and each file represents one resource as stated earlier. We will take the VMware software as an example and discuss the files that the program creates for each virtual machine:
Configuration file: This is a VMX file, which stores the configurations of the machine itself, including hardware and network settings that the user has selected for this guest machine.
Memory file: This is a VMEM file, which contains the running memory of the guest virtual machine.
Hard drive file: This is a VMDK file, is the virtual hard drive of the guest virtual machine. It can consist of single or multiple files, according to the selection of the user while creating the virtual machine. In some cases, one guest machine can have multiple hard drives. Each hard drive will have a different file.
Snapshot file: This is a VMSN file. When the user takes a snapshot of the guest machine, the state of the machine is stored in this file.
Suspend state file: This is a VMSS file, the user can suspend the machine without turning it off. In this case, the memory of the machine is stored in this single file. When the user restarts the machine, this file is used to reload the machine memory.
Note
There are other different types of files. All file types can be found in VMware website at https://www.vmware.com/support/ws55/doc/ws_learning_files_in_a_vm.html.
In an enterprise environment or when the need for quick and remote analysis arises, the distributed forensic system can help. During the incident response, the investigator will be interested in collecting some data, such as running processes, registry keys, and user accounts in order to identify possible infection or test some IOCs. However, what if the physical access to the suspected environment is not possible in the meantime?
Many companies are now investing in producing live monitoring and analysis systems that can be deployed in an environment by installing a client on each machine in the network and have all these clients be connected to a server. The authorized investigator can access these machines from the server using the installed clients and acquire some data or build some statistics and perform some live and remote forensic analysis.
In this section, we will discuss the GRR Rapid Response framework, https://github.com/google/grr. GRR is an Incident Response Framework that is focused on Remote Live Forensics. It provides remote analysis using some famous digital forensics' frameworks such as TSK and Rekall. It consists of a server which can control a large number of clients at the same time.
We will run a demonstration to discuss GRR using a virtualization where we have two virtual machines. These are a Linux Ubuntu machine with the IP 192.168.153.142 and a Windows 7 Enterprise 64-bit machine with the IP 192.168.153.146. The server will be installed on the Linux machine and the client will be installed on the Windows machine. For the Server-Client schema, both machines must be connected to the same network. We can use the NAT network configuration for both machines using any virtualization software and then test the connection between both machines.
To install the server, you can follow the documentation at https://github.com/google/grr-doc/blob/master/quickstart.adoc. After you finish installing the server, it will ask you to initiate the server configuration, which it will use to build the clients for this specific server besides the admin username and password. For this exercise, the administration URL is http://192.168.153.142:8000, and the client frontend URL is http://192.168.153.142:8080/control.
After making sure that both server and client can reach each other, we can proceed to installing the client on the Windows machine. For this exercise, we recommend that you disable the Windows virtual machine firewall. Open the following URL from the client machine http://192.168.153.142:8000/#main=BinaryConfigurationView&t=_executables-windows-installers, and enter the admin username and password:
Figure 2: Downloading the GRR client
This link will open the Windows clients directly. Our Windows machine is 64 bit, so we need to download the GRR_3.0.0.7_amd64.exe file. This client was configured to connect directly to the server at the Linux machine by the server IP, so make sure that there is no IP conflict in the testing environment. After downloading the client, we need to run it on the client machine with administrator privileges. Give it some time and then go to the server and open the admin URL again.
Note the following:
The client can be transferred in any way, and not necessarily by opening the admin portal.
In real life, if the client is really remote, the server must be published on the Internet with real IP. The Cloud can be used in such cases.
After opening the administration URL, the clients will not appear directly. Therefore, we need to have any information about the client to search for it. According to GRR documentation, any information, such as the hostname, MAC, username, IP, and so on, will be enough to locate the client if it is connected. In our exercise, we will use the client IP 192.168.153.142:
Figure 3: Search for client by IP
Double-clicking in the machine will open all the information about the machine, as shown in the following figure:
Figure 4: A newly-connected client
To execute command on the client machine, we need to start what is called a flow. There are different types of flows in GRR, which are as follows:
Figure 5: Different flows in the machine
We will make one flow as an example by listing the processes in the remote Windows client. Select the flow under Memory, then select AnalyzeClientMemory. As we discussed in the memory forensics chapter, the plugin to list the system running processes in both Volatility and Rekall is the pslist plugin.
We will add this plugin in the requested plugins, as shown in the following screenshot:
Figure 6: The request to run the pslist plugin on the remote client.
The execution of such a command will take some time. After it finishes, the server will notify the administrator:
Figure 7: Admin notification of the results
Clicking on the notification will open the results of the analysis. The results will be the same as it shows in the Rekall output, as shown in the following screenshot:
Figure 8: The pslist plugin reuslts received in the server
GRR has many different usages, such as listing the files in the machine filesystem as seen by the normal operating system and by the TSK framework, where the investigator can notice any differences or recover deleted files.
The full documentation of the tool's capabilities can be found at https://github.com/google/grr-doc/blob/master/user_manual.adoc.