How I Built a Cybersecurity Digital Forensics and Incident Response Lab in Amazon Web Services
Solid digital forensic and incident response (DFIR) skills are the cornerstone of an effective incident responder and cybersecurity analyst. More so than logs, network traffic, and automated detections, forensic analysis requires a deep understanding of an operating system’s architecture and functions. And like most skills in the cybersecurity sector, this one only gets better with exposure, training, and repetition.
Easier said than done, however. Access to a dedicated and extensible lab for sharpening forensic skills is either costly, convoluted, or both. To combat this issue and provide a simple, cost-effective solution available to anyone, I decided to design and implement a DFIR lab in Amazon Web Services (AWS). This solution provided a number of benefits:
- Low barrier-to-entry — By building in the cloud, there’s no need to have an expensive rig in your home that has the capacity to virtualize multiple virtual machines without sacrificing performance. Hardware and its associated costs can be an obstacle for many.
- Modularity — Adding workstations, updating the environment, adding/reducing resources assigned a host, networking configuration changes — all of these sysadmin tasks are simplified in the cloud.
- Cross-training — There’s no better way to get more familiar with cloud architecture than by building cloud resources. While creating a digital forensic lab, I was able to work on my AWS chops as well.
The goal of this article is to be as explicit as possible about the creation process to enable others to get the same experience.
Goals
Before I began, I outlined what I wanted out of the project:
- Functionality — an environment where I could practice forensics on any OS… but specifically Windows for this iteration.
- Low cost — I wanted to keep the cost to around $5.00 a month.
- Repeatable — there needed to be a method to quickly tear down, revert, and rebuild resources after running a set of scenarios.
- Simplicity — let’s not overcomplicate things. One Windows workstation. One analysis workstation.
And here’s what I wanted in the lab:
- SANS Investigative Forensic Toolkit (SIFT) Workstation — a free and open-source incident response and digital forensics platform. Essentially, it’s a Linux distribution configured with forensics and IR tools such as Autopsy (The Sleuth Kit), ClamAV, Plaso, Volatility, and RegRipper — just to name a few.
- A Windows Server — since I wanted to focus on Windows forensics, I decided upon including a Windows server to serve as the target of the analysis.
- Velociraptor EDR — Velociraptor is a phenomenal open-source EDR, continuous monitoring, and forensic analysis tool. In this lab, I wanted the SIFT workstation to serve as a Velociraptor server and the Windows server to serve as the Velociraptor client.
Alright, now right to the point…
How to Build The Lab
Step 1 — AWS Organizations and SSO
The first thing you need to do is create access to your AWS environment… securely! AWS Organizations and SSO enables you maintain the principles of least privilege and minimize permission redundancy between roles. This is helpful for the separation of multiple facets of your online portfolio and preventing management plane compromise. Rather than reinvent the wheel on how to do this, I’ll point you to one of the best walkthroughs I’ve ever read on the internet by Wojciech Matuszewski:
For this walkthrough, I’m assuming you already have an AWS account. If not, it’s a straightforward process, and there are many guides out there on how to do it.
Step 2 — EC2 and SIFT
Once you’ve set up SSO access, we can create our Linux SIFT workstation. To begin, open the EC2 resource console and select “Launch Instances.”
From there, enter a name for the workstation, such as “sift_workstation.”
Just beneath here, in the Amazon Machine Image search bar, search for “sift.” Navigate to the Community AMIs and select the SANS SIFT workstation.
Selecting this option will bring you back to the original launch menu. Now, you’ll select the instance type. I recommend a t2.medium — the 4 GiB of memory seems to be just enough to work a GUI and the multiple tools I have running at any given time.
Then, under “Key pair (login)”, unless you already have a key pair you’re using in your environment, select “Create new pair.” Name your key pair and select your preferred method of access. Save this file somewhere accessible.
Now, we’ll adjust the network settings. Right off the bat, I recommend you change your SSH access to the following:
Doing so will limit (albeit not completely!) access to your instance from the outside world. Keep in mind, when/if your public IP address changes, you will lose SSH access to this endpoint and will have to update the security group in AWS!
“Configure storage” should default to 20 GiB of gp3 storage. While 20 GiB is enough to get started with your SIFT workstation, importing large memory dumps will quickly eat this up. I recommend at least 30 GiB of storage.
With that, you’re ready to launch the instance!
Step 3 — EC2 and Windows
Now, we’ll walk through a similar process to setup the Windows server EC2 instance. I’ll be a bit more brief with this description as the steps are largely the same.
To begin, select “Launch Instances” from the EC2 instance overview dashboard. Name your instance as your see fit, such as “win_host.” This time, under Amazon Machine Image, select “Windows” and then find the “Microsoft Windows Server 2016 Base” AMI, like so:
Once again, I recommend the t2.medium instance type.
I generated a different key pair for this instance and I recommend you do the same.
Now, within “Network settings,” we’ll make a familiar deviation. Update the “Allow RDP traffic from” setting to “My IP” like we previously did for SSH.
“Configure storage” should default to 30 Gib of gp2 volume — that’s fine as well. With that, launch this instance.
Step 4 — Security Group Updates
Once your EC2 instances have spawned, you’ll need to update their security groups to enable communication between the Windows host and SIFT workstation. Security groups are like firewalls that exist within the management plane of AWS. They allow and prevent communication between EC2 hosts in tandem with host-based firewalls. Updating the security groups for our new EC2 hosts is necessary in order to transfer files and tools as well as enable server-client EDR communication. To update a security group, select the instance from the main EC2 dashboard by clicking on its Instance ID. Below, I’ll start with the Windows server and open the instance summary. Scroll down to the bottom pane and select the “Security” tab. In the Security tab, select the link for the EC2 instance’s security group (launch-wizard-2 below).
Now, you’ll see the existing security group inbound rules. To edit these, select “Edit inbound rules.” Once within the configuration wizard, you’ll need to select “Add rule.” Here, click the leftmost drop down bar and select “All TCP.” This will automatically update your port range. Finally, you need to add in your IP space. Simply add in a CIDR range that covers the two IPs in your EC2 instances’ VPC. For me, this was 172.31.0.0/16. Add an optional note and save the updated configuration. Below, you can see a transient configuration from my Windows host instance — I’ve allowed a ping test and RDP from my personal home workstation and all TCP traffic within my VPC subnet.
After you’ve configured your security group for the Windows server, you’ll need to do the same for your SIFT workstation. This process is exactly the same as before. When complete, at a minimum, both workstations’ security groups will have an ALLOW inbound rule for all TCP traffic within their VPC. Additionally, you should create ALLOW inbound rules for port 3389 on the Windows host and port 22 on the SIFT workstation. In the next step, we’ll continue to configure the environment and make one additional change to the AWS security groups.
Step 5 — Configure SIFT
To access GUI-based tools like Autopsy and Velociraptor, we’ll need a GUI configured on the SIFT workstation. To do this, we’ll install xfce, an open-source Desktop environment for Linux. Additionally, we need to set up a xrdp server to allow GUI-based access.
Digital Ocean has an excellent guide on how to do this:
Once xfce is configured and xrdp is installed, we’ll need to go back to our AWS security group for the SIFT workstation and allow traffic over 3389 from “My IP”. Doing so will allow us to RDP into the workstation and access our freshly installed desktop environment. At this point, you’ll be able to access your SIFT workstation via RDP. I recommend giving this a go (SIFT has a set of default credentials — they’re easy to look up) and then immediately updating the password (you can never be too safe!).
Step 6 — Configure Windows Server
If you haven’t yet, start out by connecting to your Windows server via RDP. Instructions for this can be found by selecting “Connect” and then “RDP Client” from the EC2 instance summary for the Windows host. In this section, we’re going to accomplish the following:
- Update the Windows Administrator password
- Install Eric Zimmerman tools for forensic analysis
- Install and configure Sysmon for better logging
- Ensure Sysmon is configured by checking Windows Event Viewer
Windows Administrator Password
First thing is first, I recommend changing the Administrator password to something that’s easy for you to remember. While it’s possible to get the Admin password from the EC2 “Connect” and “RDP Client” interface, it’s far simpler to save a custom password. Additionally, if in the future you decide to save your Windows Server as an AMI or launch template, AWS EC2Launch will no longer be able to provide you with the account’s password from the management console. This will create access issues when trying to revert back to that saved AMI state. Changing the password is straightforward, too. Open a PowerShell prompt and run the following:
$Password = Read-Host -AsSecureString
$UserAccount = Get-LocalUser -Name "Administrator"
$UserAccount | Set-LocalUser -Password $PasswordEric Zimmerman Tool Installation
Let’s start with Eric Zimmerman’s tools. For those unfamiliar, EZ tools are open-source forensic utilities used to analyze a host. They’re used to simplify and expedite both the common and complex forensic tasks. EZ tools require .NET 6.0 or newer to run — but installation is very straightforward. First, download .NET 6.0 or higher (ensure you download and install the Desktop runtime in order to use the GUI tools):
After that, download and execute the Get-ZimmermanTools Powershell script from Eric Zimmerman’s site:
You may receive the following error when running the Git-ZimmermanTools Powershell script. This error occurs because Powershell uses TLS 1.0 by defeault, but the site requires TLS 1.2.
It’s a simple fix. Execute the following line of code in your terminal before running the Get-ZimmermanTools script again:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls, [Net.SecurityProtocolType]::Tls11, [Net.SecurityProtocolType]::Tls12, [Net.SecurityProtocolType]::Ssl3To see if everything is running correctly, try opening up one of the GUI-based tools like Timeline Explorer.
If this doesn’t work, it’s typically a .NET issue. An easy, quick workaround is to skip the .NET installation (or remove it if you’re already past that) and open up the Timeline Explorer application anyway. This will prompt you to download and install the appropriate version of .NET — sometimes this is easier than doing the installation manually.
Sysmon Installation
Sysmon is a free Microsoft product that improves upon native Windows Event logging by increasing verbosity, efficiency, and the breadth of coverage. It’s a phenomenal tool to have in a DFIR lab as it provides granular and customizable logging. On top of that, Microsoft does a great job of making installation incredibly easy. Download Sysmon from the following link:
Additionally, you’ll want to download SwiftOnSecurity’s Sysmon configuration template (sysmonconfig-export.xml).
This template configures which Sysmon event codes will be logged and why. It’s definitely worth giving it a read over to understand when events will be logged and when they will not be. As per Microsoft’s documentation, installation is a one-liner:
sysmon -accepteula -i ./sysmonconfig-export.xmlViewing Sysmon in Event Viewer
You can verify Sysmon was configured correctly and is logging by finding Sysmon event codes in Windows Event Viewer. To do so, open up Windows Event Viewer, and on the left side of the application, open subsequent folders to Applications and Services → Microsoft → Windows → Sysmon → Operational. Once Operational is selected, you should be able to see Sysmon logs. If none are present, create a canary by opening the Windows calculator from the search bar, close it, and then click on Operational again.
Alternatively, you can run the following Powershell command to see if Sysmon is logging:
Get-WinEvent -LogName 'microsoft-windows-sysmon/operational' If this generates output, then Sysmon is functioning correctly. With EZ tools installed and Sysmon configured, we can move onto the final step — setting up Velociraptor.
Step 8 — Configure Velociraptor
Velociraptor is a free, open-source Endpoint Detection and Response (EDR) platform that simplifies the process of collecting memory and disk artifacts for DFIR. It can produce raw memory dumps for analysis with Volatility (pre-installed on SIFT) as well as KAPE output for interrogation with Eric Zimmerman’s toolset. Outside of its forensic capabilities, it can also be leveraged as a continuous monitoring solution — but that’s out of scope for this writeup. Primarily, we’ll use Velociraptor to extract disc and memory artifacts.
I’ll keep things simple — the Linux SIFT workstation will act as the Velociraptor server and the Windows host will be the client. The server provides a GUI that can be used to interrogate the client for artifacts and information. You can follow the subsequent steps in the official Velociraptor documentation: https://docs.velociraptor.app/docs/deployment/
Please note, you’ll need to be the root user for each step of the installation process.
Server Installation — SIFT Workstation
To begin, download the most recent version of the linux-amd64 file from the releases page of the Velociraptor Github:
Chmod the file to enable execution:
chmod +x velociraptor-v0.72.1-linux-amd64Then run the following:
./velociraptor-v0.72.1-linux-amd64 config generate -iThis will initiate a wizard that will walk you through all the steps you need to generate configuration files for both the server and the client. Before you continue, you’ll need to identify your SIFT workstation’s private IP DNS name from the instance summary back in the AWS console.
For the most part, replicate the items listed in the following configuration — with a couple exceptions!
For the wizard’s question regarding the master frontend DNS name, input the private IP DNS name of the SIFT workstation found in the AWS console. Please be aware that if you change the private IP DNS name of your SIFT workstation, this configuration process will need to be repeated. It will benefit you in the long run to not adjust the private IP address of the SIFT workstation within AWS. Then, pick a better name for your username than “test”. Additionally, I recommend you name your config files “server.config.yaml” and “client.config.yaml” (mine were adjusted to avoid overwriting existing configurations).
The Velociraptor documentation explains each of the wizard’s questions and what impact they have on deployment:
With your server and client configuration YAML files generated, run the following to create an installation file for the server:
./velociraptor-v0.72.0-linux-amd64 --config server.config.yaml debian server --binary velociraptor-v0.72.0-linux-amd64This will then produce a .deb package that you can use install the Velociraptor server on your SIFT workstation. Do so with the following command:
sudo dpkg -i velociraptor_*_server.debYou can check and see if the Velociraptor is functioning correctly by browsing to localhost and the port you specified for the GUI in the wizard (I used 8889). You should see something like this:
With that, the server is functional! Next, we’ll tackle the client installation.
Client Installation — Windows Host
Here’s a link to the Velociraptor documentation that will walk you through the following steps:
The installation process starts in the Velociraptor GUI. Here, we will create a .msi that can be used to install Velociraptor on the client (Windows host) with the necessary configurations. Open the server artifacts tab (shown below) and then the plus sign to open the server artifact menu.
From there, search for “create” and select “Server.Utils.CreateMSI”.
After that is selected, click “Launch” in the bottom of the window. Velociraptor will now take a few moments to generate the .msi that we’ll install on the Windows hosts. When it’s complete, return to the server artifacts tab and select the “Server.Utils.CreateMSI” item in the menu. Browse to the “Uploaded Files” tab and then click on the green box under “vfs_path”. This will initiate the download of the .msi file within your browser. Once complete, save it to a convenient location.
At this point, you can use the .msi to install the Velociraptor client on the Windows host. Transfer the file to the Windows host however you deem best, but I recommend using a Python Simple HTTP Server on the SIFT workstation. Thanks to our earlier security group configurations in the AWS console, the network will already allow the transfer. If you’re unfamiliar, use the following command on the SIFT workstation to serve your current working directory’s contents over port 8080:
python3 -m http.server 8080You can then browse to your SIFT workstation’s private IP address (specify your selected port as well) from a browser in Windows to retrieve the .msi. Once downloaded, simply run the .msi in Powershell.
Once the installation is complete, your Windows host should be running Velociraptor as a service. You can double check this by opening up the Services application:
If Velociraptor is running, then you should be able to go back to the server GUI and check for a connection. In the GUI, click the magnifying glass at the top of the screen adjacent to the search box.
If you see a host listed under “Client ID”, then the installation and configuration was successful! You can select the gray/green dot next to the client ID to connect to the client and begin interrogation and artifact collection.
Troubleshooting Velociraptor Installation
Initially, I had a couple failed attempts with the Velociraptor installation process. If you’ve found that any of the preceding steps didn’t work for you, I strongly recommend you read through the Velociraptor installation documentation. Secondly, double check the configurations you made during the Velociraptor setup wizard. Review your AWS DNS names and selected ports, and conduct connectivity tests between hosts when you’re unsure if something is working correctly.
Step 9 — See It In Action
Take a step back to look at what’s been accomplished — we now have a fully functioning DFIR environment. You can use Velociraptor to pull raw memory dumps or disc artifacts from the Windows host and then use Volatility or EZ tools to analyze them. Let’s try exactly that.
This article isn’t a tutorial on how to use Velociraptor or how to conduct digital forensics — there are plenty of resources out there to learn those skills. I’d like to create subsequent writeups with walkthroughs of disc and memory forensics as well. Nonetheless, we can start off with something simple — we’ll use Velociraptor to pull the Windows host’s MFT and then conduct analysis with EZ tools. This begins in the Velociraptor GUI by selecting the “Collected Artifacts” tab on the left side of the screen. Select the plus sign to begin a new collection.
This will open the “New Collection” page. From here, search for “mft” and select “Windows.Timeline.MFT”. This artifact will query the host for the MFT along with additional helpful metadata. It can then be parsed and read in any .csv accessible program like Excel or TimelineExplorer.
Once selected, click “Launch”. Velociraptor will now pull the MFT from the Windows host — this may take some time since the file can be large. Once complete, though, there will be a check mark under the “State” column.
Click on the artifact and then navigate to the “Results” tab. From there, you can select the .csv icon to initiate downloading the output as a .csv.
Once finished, transfer the .csv to the Windows host. Again, I’ve found that it’s easiest to use a Python Simple HTTP Server and download the file via Powershell or a browser on the Windows host.
Finally, browse to your freshly installed EZ tools and open the TimelineExplorer application. TimelineExplorer can be used for a variety of applications, but I’ve found it most useful for parsing MFTs or USN journals. Import your MFT Timeline .csv into the application and you can begin forensic analysis. Below, I’ve filtered down to all the MFT entries involving the .msi I used to install Velociraptor.
A Couple More Things…
With this complete, our lab is functional. You can now begin to explore memory and disc forensics with a variety of tools. I recommend reading about EZ tools and the SIFT workstation tools if you’re unfamiliar with their capabilities. Before wrapping things up, I want to offer one other recommendation — review AWS’s penetration testing policy for your left and right limits within the lab. Violating their Terms of Service can land your account in hot water, so if you’re considering conducting any kind of penetration-testing-esque actions, review their rules. Here’s a link:
When you finish with the lab for a day, be sure to change the instance state to “Stop” for each of your EC2 instances — this will save on costs. Over the course of a month, I spent around $7.00 on AWS running these machines for 15–20 hours a week — not bad at all!
Final Notes
My goal with creating a DFIR lab in AWS was to improve my cloud expertise and create a space to further develop my forensic skills in an extensible environment; my goal in creating this write up was to help others (particularly those new to DFIR and AWS) to learn something new and overcome some of the obstacles that prevent DFIR self-development. I’m a big proponent of diving into new or difficult problems and “eating dirt” so to speak until things start to make sense — that’s how I’ve always learned the best in my cybersecurity endeavors. If you have comments, questions, recommendations, or need some clarification, please leave a comment or reach out. If you’ve found success from this write up, please let me know as well — I’d love to hear that it’s done some good!