The preferred method for the acquisition of memory is through direct contact with the suspect system. This allows for adaptability by incident response analysts in the event that a tool or technique does not work. This method is also faster at obtaining the necessary files since it doesn’t depend on a stable network connection. Although this is the preferred method, there may be geographical constraints, especially with larger organizations where the incident response analysts are a plane ride away from the location containing the evidence.
In the case of remote acquisition, incident response analysts can leverage the same tools that are utilized in local acquisition. The one change is that incident response analysts are required to utilize remote technology to access the suspect systems and perform the capture. As with any method that is utilized, incident response analysts should ensure that they document any use of remote technology. This will allow for the proper identification of legitimate versus suspect connections later on.
In this chapter, we will cover the following main topics:
The previous chapter focused on acquiring evidence when an analyst or a responder has physical access to the system. The reality of the situation is that this is often not the case. Infrastructure moved to cloud services such as Amazon Web Services (AWS) or the move toward a remote workforce creates a situation where responders most likely will not have physical access to plug a USB device in and run their tools to acquire evidence.
Compounding this challenge is the need to get more actionable information much quicker than what traditional digital forensics can provide. For example, a traditional digital forensics methodology has analysts make a full image of an infected system, and capture the memory and other artifacts. These are then transferred to an analysis workstation and, over the course of hours or days, the analyst can obtain the necessary data. In situations where an incident may be localized or more detailed intrusion analysis needs to take place, this may be necessary. In other circumstances, this type of analysis methodology does not scale when looking at hundreds or even thousands of systems that may be impacted.
Moving away from this traditional digital forensics and investigation model is one that focuses on Live Triage. In this methodology, data is collected from systems that are suspected of being compromised. The focus here is on collecting high-value data in a central location where it can be indexed and analyzed. With the data in a central location, the analysts can then leverage tools and techniques to scale their investigation. Leveraging this technique will allow analysts to focus their efforts on systems with the greatest evidentiary value. It is on these systems that analysts can apply the full focus of digital forensics to gain the best understanding of the adversary and their behavior.
Ransomware has arguably been the one key threat that has changed how an incident response is conducted. The speed and widespread impact of such attacks has highlighted the need for tools that provide analysts with a method to search across the entire network infrastructure. This is where endpoint detection and response (EDR) tools come into the picture.
EDR tools grew out of the traditional signature-based antivirus that permeated the industry for nearly two decades. Building on the capability to match hash values and other signatures, EDR tools bring much-needed distributed capabilities to security and incident response teams. There are a variety of commercially available EDR platforms, each with distinctive features, but at a high level, they can generally perform the following functions:
Depending on the EDR platform, organizations also have flexibility in terms of deployment. The primary method of deployment is using a cloud management console that individual endpoints communicate with via an agent. This type of deployment can monitor both internal and cloud-based systems and provides flexibility for remote analysts and incident responders.
The one major disadvantage of EDR platforms is cost. This functionality does not come without a cost. Given the visibility and functionality of EDR platforms, they are quickly becoming a critical tool for organizations of all sizes and an important asset to incident responders to quickly gain incident awareness and the ability to investigate widespread adversary activity across the entire network.
Aside from commercial platforms, there are open source tools that incident response teams can use that provide at least some of the functionality found in EDR platforms. One of these is Velociraptor. This tool uses a combination of a central server that endpoint agents connect to, as seen in Figure 7.1. These endpoint agents, called clients, manage the search of artifacts on remote systems. This places the load for searching and evidence acquisition on the endpoint, reducing the load on the server, and allowing for concurrent searches across multiple remote clients.
Velociraptor documentation
This chapter can only cover a limited portion of the features of Velociraptor. For a full breakdown of the features, including additional digital forensic use cases, review the Velociraptor documentation at https://docs.velociraptor.app/.
Figure 7.1 – Velociraptor setup
To demonstrate some of the functionality of Velociraptor, a server will be configured. After that, a Windows client will be created and deployed to a Windows endpoint. From there, we will look at how Velociraptor can be used to gain data on an endpoint’s behavior and extract meaningful evidence for further investigation.
The first portion of the Velociraptor tool is the server, which manages the agents that will later be installed on the endpoint. There are detailed instructions on deployment available on the Velociraptor GitHub page at https://github.com/Velocidex/velociraptor. There are also several options for deploying the server, including using Windows and Linux OS and Docker. In this case, the server application will be installed on an Ubuntu 20.04 LTS server. After installing the server, go through the following steps to install the application:
Static IP
One key consideration before getting started is to give Velociraptor a static IP address. The agents that will be configured later will need to have this IP address and any changes will make the agents useless.
mkdir velociraptor
cd velociraptor
wget https://github.com/Velocidex/velociraptor/releases/download/v0.6.4- 1/velociraptor-v0.6.4-1-linux-amd64
chmod +x velociraptor-v0.6.4-1-linux-amd64
./velociraptor-v0.6.4-1-linux-amd64 config generate > velociraptor.config.yaml
nano velociraptor.config.yaml
sudo mv velociraptor.config.yaml /etc
./velociraptor-v0.6.4-1-linux-amd64 --config /etc/velociraptor.config.yaml user add admin --role administrator
./velociraptor-v0.6.0-1-linux-amd64 --config /etc/velociraptor.config.yaml frontend -v
Figure 7.2 – Velociraptor welcome screen
As the previous directions show, setting up Velociraptor is easy. Further, the server can be deployed in either the internal network or within a cloud infrastructure such as AWS or Azure. This allows incident response analysts to collect data from any system with connectivity to the internet. This also removes the need to maintain a system as Velociraptor can be deployed as necessary in the event of an incident or maintained as a virtual system and powered up as needed.
Now that the server has been configured, let’s go ahead and build a Windows collector that will allow an analyst to examine a remote Windows system.
The Velociraptor collector is the agent that is installed on monitored endpoints and is connected to the server. To configure a collector, follow these steps:
sudo nano /etc/velociraptor.config.yaml
use_self_signed_ssl: true
Refer to the following screenshot for reference:
Figure 7.3 – Configuring the Velociraptor YAML file
cd velociraptor
./velociraptor-v0.6.4-1-linux-amd64 --config /etc/velociraptor.config.yaml config client > client.config.yaml
wget https://github.com/Velocidex/velociraptor/releases/download/v0.6.4-1/velociraptor-v0.6.4-windows-amd64.exe
./velociraptor-v0.6.0-1-linux-amd64 config repack --exe velociraptor-v0.6.0-1-windows-amd64.exe client.config.yaml Velociraptor_Agent.exe
sudo apt install openssh-server -y
The collector is now configured. To get the collector off the Velociraptor server, simply use any SFTP to transfer it off the system. Then, transfer it to the Windows endpoint or endpoints that you would like to monitor. Next, install the Velociraptor service using the Windows Command Prompt Velociraptor_Agent.exe service install command, as shown here:
Figure 7.4 – Velociraptor Agent intallation
Velociraptor is a feature-rich platform that can be leveraged for a wide range of digital forensics and incident response tasks. For the purposes of this discussion, the focus will be on using Velociraptor to access the remote system command line to return data along with running evidence collection binaries.
Velociraptor is a feature-rich tool with a wide range of capabilities. In this chapter, the focus will be on getting basic information about the endpoint, evidence acquisition through the command line, and finally, acquiring an evidence package for further analysis. This should be enough to at least gain some familiarity with Velociraptor. In later chapters, we will look at using Velociraptor for analysis and threat hunting.
One tool that is often overlooked when conducting an initial triage analysis is the Windows command line. From here, an analyst can examine running processes and network connections and extract files. Velociraptor has the capability for an analyst to run commands and evidence tools via the command line on a remote system:
Figure 7.5 – Searching for clients
Figure 7.6 – Client list
Figure 7.7 – Client information
Figure 7.8 – Accessing Shell
Figure 7.9 – Windows netstat command output
This feature is useful when conducting an initial analysis or triage of a system. Checking the network connections or running processes may reveal the presence of malware or command and control. This enables the analyst to focus on systems that may have those indicators. Another technique for evidence gathering is running tools that were discussed in the previous chapter from the command line.
A simple way to acquire evidence from a remote system is to use the CyLR tool that was discussed in the previous chapter. In this case, the results can be sent to a remote server or workstation using SFTP. Simply run CyLR with the following command with the destination server username and password:
CyLR.exe -u username -p password -s 192.168.0.15
One technique that is useful is to send all the evidence to a central server where multiple analysts can work. In Chapter 12, CyLR will be combined with additional tools available on the Skadi platform.
WinPmem can be deployed on remote systems through native applications such as Remote Desktop or PsExec. Once installed on the remote system, the output of WinPmem can be piped to another system utilizing NetCat. For example, suppose that the incident response analyst is utilizing a system located at 192.168.0.56. If the analyst is able to access the compromised host via PSExec or RDS, they can establish a NetCat connection back to their machine by using the following command:
C:/winpmem-2.1.exe - | nc 192.168.0.56 4455
The preceding command tells the system to perform the capture and send the output via NetCat to the incident response analyst workstation over port 4455. The drawback of this technique is that it requires access to Command Prompt, as well as the installation of both NetCat and WinPmem. This may not be the best option if the incident response analyst is dealing with a system that is suspected of being compromised.
Another key feature of Velociraptor is the virtual file system (VFS). This allows analysts to examine the file structure on a remote system. This is a handy feature for instances where the analysts know a specific file or files that they would like to collect in relation to an alert or incident. In the following example, the analyst has been alerted to a suspicious DLL file located on a remote system and has been tasked with collecting it for analysis:
Figure 7.10 – Accessing the VFS
Figure 7.11 – The VFS
Figure 7.12 – Refresh buttons
In addition to refreshing the directory, the additional icons from left to right will either recursively refresh the directory, recursively download the directory, or view the artifacts collected.
Figure 7.13 – Suspect DLL
Figure 7.14 – Collecting files
The VFS is useful for those events and incidents where the analyst has some data pointing to a specific file or directory to search for evidence. This feature significantly decreases the time necessary to acquire specific files. There are some circumstances though where the analyst needs to acquire an evidence package from a remote system. In this case, Velociraptor can be leveraged to acquire a range of files and other data related to an incident investigation.
The last feature that this chapter will look at is gathering evidence from a remote system for analysis. This feature gives the analyst a significant advantage in gathering this data remotely without the need to use the sneaker-net approach. In this case, Velociraptor will be used to gather KAPE evidence collection from a remote system:
Figure 7.15 – Client list
Figure 7.16 – Collection icon
Figure 7.17 – Starting a new collection
Figure 7.18 – Selecting artifacts
Figure 7.19 – KAPE Targets details
Figure 7.20 – Collection parameters
Figure 7.21 – Collection parameters detail
Figure 7.22 – Collection request review
Figure 7.23 – Collection request progress
Figure 7.24 – KAPE Targets ready for download
Figure 7.25 – Acquired evidence
With this, we have come to the end of this chapter.
A major challenge of digital forensic acquisition is scaling it to remote systems and being able to quickly analyze the data. Even with this challenge, incident response analysts can leverage tools such as Velociraptor both as a standalone solution and by integrating the tools that they already have. Through this combination, they are able to quickly focus their efforts on those systems that have the greatest evidentiary value. This provides decision-makers with an understanding of the nature of the adversary's actions and what measures they can take without having to wait for a full analysis that is severely limited due to the remote nature of IT operations today.
In this chapter, we looked at how endpoint detection and response tools can provide analysts with the ability to conduct investigations at scale. Building on this, we examined the open source tool Velociraptor, going through the setup and configuration, agent deployment, and several scenarios where Velociraptor can aid in the gathering of evidence and analysis related to an incident. Keep these scenarios in mind when we discuss ransomware investigations in Chapter 17.
In the next chapter, we will examine how to properly image a system’s storage for follow-on analysis.
Answer the following questions to test your knowledge of this chapter: