Forensic Disk Copies in Azure

By

In a previous blog post, we presented how libcloudforensics facilitates digital forensics investigation in the cloud, in particular we focused on disk copy functionality in Google Cloud Platform (GCP) and Amazon Web Services (AWS). We recently added support for Microsoft Azure. In this post we show how the library can be used to respond to incidents occurring on Azure, and present solutions to the main challenges we faced while adding support for this cloud provider.


Architecture

Azure’s architecture is pretty straightforward: each account has a set of “subscriptions”, within which resources can be organized by “resource groups”. Resource groups can contain any valid Microsoft Azure resource, be it a Compute resource (e.g. a virtual machine) or another kind of resource (e.g. a Network resource such as a network interface).


Snapshotting disks in the cloud

The following code snippets give examples of forensic acquisition within the Azure environment using the libcloudforensics API. Note that these are examples intended to showcase how one can carry analysis in a different account than that where the disk is copied from. For other scenarios, please refer to the official documentation.


The snippet below shows how libcloudforensics makes a forensic copy of the disk 'disk1' that is attached to the instance 'instance1' in the Azure resource group 'blogpost'. It then attaches that copy to a VM that it creates ('vm-forensics') in a different account, referred to by 'analysis_profile'.

from libcloudforensics.providers.azure import forensics


# Create a forensic copy of the disk 'disk1', 'disk1-copy' 

copy = forensics.CreateDiskCopy('blogpost',

                                disk_name='disk1',

                                src_profile='src_profile',

                                dst_profile='analysis_profile')


# Start an analysis VM 'vm-forensics' for investigation in the destination account 

# and attach the copy created in the previous step.

analysis_vm, _ = forensics.StartAnalysisVm('blogpost',

                                           'vm-forensics',

                                            50, 

                                            'ssh-rsa AAAbbbbFFFF...',

                                            cpu_cores=4,

                                            attach_disks=['disk1-copy'],

                                            dst_profile='analysis_profile')


Libcloudforensics also provides a command line interface (CLI) to accomplish the same objective:


# Create a forensic copy of the disk 'disk1', 'disk1-copy'  

cloudforensics az 'blogpost' copydisk --disk_name='disk1' 

                                                 --src_profile='src_profile' 

                                                 --dst_profile='analysis_profile'


# Start an analysis VM 'vm-forensics' for investigation in the destination account 

# and attach the copy created in the previous step.

# A SSH key pair will be automatically generated and associated with the instance.

cloudforensics az 'blogpost' startvm 'vm-forensics'  --disk_size=50 

                                                     --cpu_cores=4 

                                                     --attach_disks='disk1-copy' 

                                                     --dst_profile='analysis_profile'

How does cross-account/region disk copies work?

Microsoft Azure does not directly provide a simplified way to achieve the above scenario, e.g. by offering a --destination-account parameter in their CLI. Luckily for us there’s a workaround. Snapshots can be shared through a Shared Access Signature (SAS) URI. A SAS provides secure delegated access to resources in one’s storage account without compromising the security of the data [1]. Anyone with this link can access the snapshot. This is how cross-account/cross-region disk copies can be automated in Azure. 


Libcloudforensics takes care of creating a temporary storage account in the destination account, downloads the snapshot from the SAS URI into the storage account, and subsequently creates the disk copy. The process is depicted below:




Summary

In this post we outlined Azure’s resource organization and showed how libcloudforensics could be used to automate forensic disk copies, both within the same Azure account and across different accounts.


We hope this blog post has given you inspiration on how to further automate your cloud incident response. If you have questions, reach out on the Open Source DFIR Slack, you can find us in the libcloudforensics channel.

Resources

Comments

Post a Comment

Popular posts from this blog

Parsing the $MFT NTFS metadata file

By
Background Numerous articles have been written about parsing the $MFT NTFS metadata file before. Some of these explain the technique itself [ 1 ] and others mostly focus on how to use tools. Rarely do articles mention the pros and cons of the technique from a digital forensics perspective [ 2 ].  What is $MFT parsing?  For readers not familiar with the NTFS file system, MFT stands for Master File Table. This table is stored in a file system metadata file, meaning that as far as the file system is concerned it is a file, however that the file contains file system metadata not “regular” content. The name of this file is “$MFT”.  The MFT consists of a sequence of (predetermined) fixed-size entries (or MFT entries). These entries are typically 1024 bytes in size, however the size is defined in the NTFS volume header and in a “regular” MFT entry itself.  The first 4-bytes of a “regular” MFT-entry (or record) starts with the signature “FILE”. The MFT entry can also be filled wit
Read more

Incident Response in the Cloud

By
Many organizations have begun moving a majority of their services towards the cloud in recent years. As a result, attackers have shifted their focus towards the cloud. This has resulted in new techniques and methods specifically designed to compromise cloud infrastructure, like the recent SALTSTACK vulnerability that was widely exploited [ 1 ]. Therefore it is critical for these organizations to have an incident response team that understands the new risks attached to cloud and how cloud can make incident response easier or harder.  In this blog post we will walk you through each phase you may encounter in traditional incident response and highlight the differences when adopting cloud computing. It is aimed towards both those who are new to incident response and cloud computing. We’ve included insights that will benefit organizations taking that step towards cloud who want to ensure they are prepared to respond efficiently to cloud incidents.  Traditional Incident Response Before jump
Read more

Container Forensics with Docker Explorer

By Anonymous
  Introduction As previous blog posts on cloud forensics have noted, applications are increasingly being deployed using container orchestration frameworks such as Kubernetes, especially in cloud environments.  Similar to traditional deployments on physical servers or virtual machines (VMs), when a containerised application has a security issue it can lead to a compromise of the underlying compute architecture. In the case of container deployments this means a compromise of the container itself, the container host, or even a wider cluster compromise via abuse of orchestration tools. Often digital forensics is required to establish what went wrong and remediate any issues. This article will provide an introduction to container forensics with Docker Explorer by working through a scenario involving a compromised container running within a Kubernetes cluster. Although Kubernetes is briefly mentioned, this article will focus on analysis of an individual container rather than the wider clust
Read more