Acquiring an Image of an Amazon EC2 Linux Instance

As cloud services continue gaining popularity and become more affordable, more people are learning about what is available and are increasingly opting-in to the idea of having computers in the cloud.  This became evident during a recent conversation with my old friend JJ, @jxor2378.  I called JJ to get his opinion on what an ideal password cracking rig would be?  Without hesitation, JJ answered, “Why would you invest in buying the hardware, when you can just rent it!”  And he was right, for what I needed, using cloud computing services was in fact a good match for me.

It is not like I didn't know about the concept of cloud computing, it was just simply that because I hadn't had a need for it, I hadn't taken the time to do my computing in the cloud just yet.  By that afternoon that changed.  JJ recommended that I play with Amazon's Elastic Compute Cloud, also known as their EC2 service.

Paraphrased from their website, http://aws.amazon.com/ec2/.  Amazon's EC2 is a service that provides resizable compute capacity, designed to make cloud computing easier.  The web service interface allows you to obtain and configure capacity with minimal friction, and complete control of your computing resources.  You can quickly scale capacity, both up and down, as your computing requirements change, and you only pay for capacity that you actually use.

That last line is the neat thing about the service.  You only pay for what you use, and they even offer you a chance to try their service for free.  It only took a few minutes to get an instance up and running.  Once I had access to the instance, I couldn't help but wonder how I would go about analyzing it for forensic artifacts.

In this article we are going to go over the steps of how to acquire an image of a Linux Ubuntu Server Amazon EC2 Instance.  For the purposes of this article I used a Live Linux Distribution of LosBuntu.  LosBuntu is our own Ubuntu 14.04 distribution that can be downloaded here. 

Installing the Tools:

The tools that we will be using during the process are ssh, dd and netcat.  All of these tools come preinstalled in the Live version of LosBuntu, so there is no need to install anything else.

The Plan:

The plan is to go fire up an EC2 instance, remotely log-in to the instance and then go through the steps of acquiring an image of the instance back to a remote location of your choice.  Let's get started

  

The Test:

To set up your instance, you can use your current amazon username and password to log in to aws.amazon.com.  Once authenticated, navigate to the EC2 dashboard and click on create instance.  The instance that we will use for the test is the Ubuntu Server 14.04 LTS t2.micro instance that you can try for free.

For added security purposes we created a public/private key pair that can be used to securely SSH into the instance.  Using a key to SSH into a system offers a bit more security than a username and password combination alone.  I named the key ec2key and downloaded the key.

Once you have downloaded the key, simply launch the instance with all of the defaults.  The service shines due to the amount of customization that you can do to your instance, but that is beyond the scope of this article.  For now, all defaults will work.

Once you have your instance running, locate the “Connect” icon and click it.

A set of instructions on how to connect will appear on your screen, including the username and public IP address of the instance.

That's it.  That is all the information that is needed to SSH into the instance.  We now have the information that we need, so let’s take care of some final things.  For the command on the screenshot to work, you will need to make sure that, if your key is not in your current working directory, you will need to provide the path to it.  Also, the permissions of the key must be set so no other users or groups can read it, the command $ sudo chmod 400 yourkey.pem  will take care of that requirement.

Now type the below command to SSH into the server.  SSH is the remote login tool that will establish a secure encrypted connection to the server, the “-i” is the option that points SSH to your identity file (key), ubuntu is the username and @51.11.255.55 is the public IP of the instance.  Remember to change the key to the name that you provided and use the IP of your instance.

$ ssh -i ec2key.pem ubuntu@52.11.255.55

We are now logged-on to the EC2 instance.  From here you can remotely control the system and do whatever it is that you intent to do with it.  The possibilities are endless, but there is one caveat...  Since we set up the instance for remote access using a key, anytime that we want to access the instance we are going to have to pass it this key so that access can be granted.  This means that if you, for example, want to use Remote Desktop Protocol (RDP) to get a GUI on your screen, you may have to do it by authenticating to the instance first using an SSH tunnel.

Which is exactly what we are going to do to acquire the image of this instance.  We are going to establish a second SSH connection to a second remote server a pass the entire contents of the instance's hard drive through an SSH tunnel.  This process can be accomplished by standing up a second EC2 instance with enough space to store your image, or you can use an already publicly accessible existing server that you control.

If you read the article titled “Analyzing Plain Text Log Files Using Linux Ubuntu” then you may know that I like to run a publicly accessible server to transfer data and serve files.  So I took advantage of the SSH access to this server that I control, and authenticated back into it from the EC2 instance using an SSH tunnel.

The SSH tunnel consists of an encrypted tunnel created through the SSH protocol connection that can be used to transfer unencrypted traffic over the network through an encrypted channel.  The purpose here is to use the SSH tunnel to securely transfer the entire contents of the hard drive using DD and Netcat through the tunnel, even though Netcat itself does not use encryption.  All of the contents of the drive from the EC2 instance will travel encrypted through the tunnel back to my forensic machine in my lab.

You do not need to go through the trouble of setting up a public server for this.  A second EC2 instance will also work, but you will then have to transfer the now acquired image back to you.  Accessing a server that you control kills two birds with one stone.

Using its own terminal window on the EC2 instance, type the below command set up the SSH tunnel back to your server.  SSH is the command -p 5678 is to tell SSH to use a non-default port to connect to the server you control, -N is used so SSH does not execute any remote commands, which is useful when just forwarding ports, -L is to specify the port on the local host that is to be forwarded to the given host and port on the remote side.  Secretuser is the user on my server and 432.123.456.1 is the public IP of the server is that will be receiving the data.

$ ssh -p 5678 -N -L 4444:127.0.0.1:4444 secretuser@432.123.456.1

secretuser@432.123.456.1's password:

If everything went well and you entered the password correctly, this shell window is simply going to hang and will not show any output.  From this point forward, any data that is sent to localhost on port 4444 is going to be redirected to the server back in my lab.

On that server you will now need to set up a netcat listening session with the below command.  Nc is the netcat command, -l is to listen, -p is the port to listen on, and we are piping that data to pv and redirecting it to a file titled ec2image.dd.  Pv is a neat utility that will measure the data that is passed through the pipe.  A visual of what data is coming in, helps in determining if things are going according to plan.

$ nc -l -p 4444 | pv > ec2image.dd

Finally, on the EC2 instance run dd to image the instance’s hard drive and pipe it to netcat using the below command.  Remember that you are piping to netcat on localhost to port 4444.

$ sudo dd if=/dev/xvda bs=4k | nc -w 3 127.0.0.1 4444

This is an illustration of how the data should flow.

# Image courtesy of Freddy Chid @fchidsey0144 

After about 30 minutes it had sent over 4GB of data to my server located many states away from the EC2 instance.

$ nc -l -p 4444 | pv > ec2image.dd

4.39GB 0:32:28 [2.51MB/s] [           <=>                                      ]

It finished in less than an hour and transferred the entire 8GB (default) bit-by-bit image of the hard drive from the instance.

$ nc -l -p 4444 | pv > ec2image.dd

8GB 0:57:30 [2.37MB/s] [                                  <=>               ]

Speeds will vary depending on bandwidth.  In reference to image verification, since this was a live acquisition, doing a hash comparison at this point will not be of much value.  At the very least, check and compare that the size of your dd image matches the amount of bytes contained in /dev/xvda from the instance.  This can be accomplished by comparing the output of fdisk -l /dev/svda against the size of the acquired dd.

Check the size of the hard drive on the instance:

$ sudo fdisk -l /dev/xvda

Disk /dev/xvda: 8589 MB, 8589934592 bytes

Check the size of the dd on your sever.

$ ls -l

total 8388612

-rw-r--r-- 1 secretuser secretgroup 8589934592 Apr 17 18:20 ec2image.dd

We have a match.  And there you have it.  You have acquired an image of an Ubuntu 14.04 Server running on Amazon EC2.

Conclusion:

Amazon offers a full set of developer API tools for EC2 that might offer an easier way of accomplishing this task.  If in a pinch, and if you have an evening to spare, know that at least you have this option available to get the job done.  If this procedure helped your investigation, we would like to hear from you.  You can leave a comment or reach me on twitter: @carlos_cajigas