Take forensic disk images from the OVH Cloud

0

This article explains how a disk image can be taken from a virtual machine running on the public cloud. The acquired disk image can then be used with offline forensic tools like Autopsy and Encase.

When to Acquire a Forensic Image

Cybercriminals often abuse public cloud services due to the low cost and relaxed verification process around registering new user accounts. For example, criminals rely on virtual machines to host command and control services, malware and ransomware campaigns, and distribute phishing emails. A forensic image of these virtual machines can reveal who and how was involved in criminal activity.

The second reason to take an image is data breach. Businesses rely on virtual machines to run services for the public over the Internet. Unfortunately, these services can be hacked, and the virtual machine becomes the source of a data breach. When this happens, IT professionals can retrieve crucial evidence from the virtual machine to determine the root cause of the security breach. Forensic analysis of the compromised virtual instance can also reveal what the perpetrators did to the virtual machine as well as the extent of the data breach.

The following sections will show how IT professionals can legally acquire disk images from OVH’s public cloud environment.

Preparing the CLI tools

The digital device that we will analyze is a virtual machine running at the cloud provider called OVH. Why OVH? In one Spamhaus 2021 Threat Analysis Report, OVH is ranked the fourth most popular hosting provider among botnet operators in the second quarter of 2021. The same article claims that other major cloud providers, such as Microsoft Azure, Hetzner and DigitalOcean, are also a hotbed of criminal activities.

OVH’s public cloud service is based on the OpenStack cloud computing platform. Therefore, we will use standard OpenStack CLI tools in the forensic acquisition process. To install the command-client client, please refer to the instructions on OpenStack.

Once the CLI client is installed, log in to the OVH control panel via the web browser to generate an API token.

Retrieve an API token

OVH divides its customer accounts into logical groups called ‘projects’. Each project can include virtual machines, virtual networks, block storage devices, and other cloud services. To generate an API token for acquisition, we need to open the appropriate OVH project running our web server. Next, log in to the OVH console, choose the correct public cloud project and click on the Users and roles on the left side under the Project management section.

On the new page, click the Create a user button.

Enter a descriptive name for the new role (for example Forensic User) and click Following.

In the next pop-up choose all roles and press To confirm.

After a few seconds, the service user’s password should appear at the top of the web page. Save this password for later.

Click on the three dots on the right and select the Download OpenStack RC File option. The name of this configuration file must be openrc.sh.

Test connection

To run source openrc.sh to initialize the OpenStack command line client.

# source ./openrc.sh

The configuration script should ask for the password of the API user we created earlier. The following command should show all virtual machines running under the OVH project if everything is working fine.

# openstack server list

Acquisition of forensic images by OVH

Once the OpenStack client is working properly, we can move on to forensic image acquisition.

The first step is to create a snapshot image from the virtual machine. Assuming the virtual machine is called Web server, the following OpenStack command should create a snapshot:

# openstack server image create --name WebServer-bkp01 "Web Server"

Depending on the size of the virtual machine, the process can take 10-15 minutes. We can track the snapshot process with the following command:

# openstack image list --private

If the snapshot process is still running, the process state is queued. When the process is complete, the status should change to active.

Snapshots can also be viewed on the OVH console under the Storage -> Image Backup page.

Finally, the virtual machine snapshot can be transferred from the public cloud to the local machine with the following command:

# openstack image save --file ovh-webserver.qcow2 

Once the file transfer is ready, the virtual machine image should be available as a file named ‘ovh-webserver.qcow‘. Unfortunately, there is no progress bar to track the process, and the download speed is relatively slow.

The virtual machine snapshot file format is qcow2, which is the standard file format of QEMU, an open source virtualization software. Therefore, to load this image file into the Autopsy, we need to convert the file from qcow2 to believed picture format.

# qemu-img convert -f qcow2 ovh-webserver.qcow2 -O raw ovh-webserver.raw

The raw image can be loaded into Autopsy and other traditional forensic toolkits for forensic analysis.

Acquiring images from other cloud providers

Major public cloud providers like AWS and Azure also allow for self-service VM imaging. Please refer to the corresponding documentation on Amazon and Microsoft for details.

Other public cloud providers may not allow this approach to image acquisition due to technical platform limitations. For example, Linode recommends using the combination of ‘dd’ and SSH for the disk acquisition process. One of the drawbacks of this on-the-fly imaging approach is that the resulting forensic disk image is not an accurate and consistent snapshot of the virtual machine running during the imaging process. acquisition. The inconsistency results from running the virtual machine during the imaging process, as the operating system may modify or delete files, metadata, and other crucial information during the process.

Alternatively, it is worth engaging the cloud platform’s technical support team. Support engineers should be able to work around any technical limitations because they have direct access to the hypervisor with their internal tools and services; thus, the support team must be able to generate consistent snapshots of virtual machines.

Share.

Comments are closed.