This is the first blog in a 2 part series that will walk you through the entire process of building your first custom practical lab. You’ll learn how to do everything from launching and configuring an EC2 instance in your AWS account to imaging it and seamlessly integrating it into our platform.

In this blog, we’ll walk through the process of creating and importing your own machines. In part 2 we’ll walk you through building a simple Linux privilege escalation scenario as a working example. Our goal is to give you the foundational steps so you can confidently design scenarios tailored to your own creativity, environment, and organizational needs.

Building your machine in AWS

The first step is to log into your AWS account and provision your first EC2 machine to be configured. Access to AWS will depend on your organization and its access rules (e.g., logging in via console.aws.amazon.com). 

Provision an EC2 

Once logged in, the first step is to launch an EC2 instance. Search for “EC2” in the top search bar and click “EC2” under Services.

In the EC2 Dashboard, click on “Launch instance”.

The lab will use a standard Linux distribution. It’s recommended to start with a clean slate.

Select Ubuntu Server 22.04 LTS (HVM), SSD Volume Type, or a similar recent Ubuntu LTS version. This is a widely used and well-documented distribution. It’s also in the free tier, which means we can keep costs as low as possible.

The next step is to select the instance type. Lab Builder supports t3.micro, t3.medium, and t3.large. 

You can select whichever CPU type and associated resources your machine needs in the lab that best suits your needs. Since this is a reasonably straightforward Linux privilege escalation lab, we are going to use t3.micro.

Now, we’ll need to configure the instance details. You can generally leave most of these settings as the default for the current purpose.

• Network: Ensure your default VPC and a subnet are selected.
• Auto-assign Public IP: Check this is enabled so you can SSH into the instance from the internet and configure it.

Security Groups control the machine's inbound and outbound access. Since you need to configure the machine, make sure you have SSH open to SSH into it (alternatively, you can use AWS Systems Manager to control access without the need for SSH or direct network access). 

When using Security Groups, it's a good practice only to allow sources from trusted IPs.

• Select “Create Security Group.”
• Select Allow SSH traffic from
• For the source, it is recommended to select a trusted IP range or your own IP.

The storage you’ll need will depend on the machine you’re building. However, the default storage (8 GiB General Purpose SSD gp2) is usually sufficient unless you're installing and configuring large applications.

Note: We do not currently support encrypted EBS volumes. 

Now you’re ready to launch your machine! Review all your settings carefully and click Launch.

You’ll be prompted to add an SSH key to the machine. You’ll use this key to connect to the instance and configure it. 

• To create a new key pair, choose a name like my-lab-key and click Download Key Pair. Keep the downloaded .pem file secure—you’ll need it to SSH into your instance.
• If you’re using an existing key pair, select it.

Once you have your key sorted, select Launch Instance.

Your EC2 instance will now start to launch. It might take a few minutes for it to be ready.

Configuring the instance for use as a lab

Once your EC2 machine is launched and ready, it’s time to connect to and configure it, ready to be used in a custom lab!

Connect to the running instance via SSH, using the key you downloaded previously when you provisioned the EC2.

ssh -i <key>.pem ubuntu@<public_ip></public_ip></key>

Note: You may need to change the permissions on the key first by running chmod 400 .pem 

Next, update the system packages. 

sudo apt update sudo apt upgrade -y

Note: Depending on the future labs you create, you may not want to update system packages if you need specific versions of software or libraries installed. 

Setting up SSH for the lab user

With Lab Builder, labs can be configured to have a session open when the lab loads. This session can be SSH, RDP, or HTTP. For this lab, we want the lab to load in the platform with the lab user already SSH’d into the machine, so they can get to work on the scenario straight away without needing to worry about connecting to a machine themselves.

Many default Ubuntu AMIs disable SSH password authentication and only allow key-based authentication by default, but this can be changed. Password authentication needs to be enabled to allow our lab user to connect with a password (Lab Builder does not support key-based authentication).

To do this, we can update the configuration for SSH. In the examples below, we use nano, but you can use whichever file editing tool you are comfortable with (Vi/Vim, etc.)

sudo nano /etc/ssh/sshd_config

Find the line that says: #PasswordAuthentication no or PasswordAuthentication no. We want to change this to allow our users to connect via a password:

PasswordAuthentication yes

Make sure ChallengeResponseAuthentication no is set to no (it usually is). Save the file.

While this will work for most distributions, certain images provided by AWS can have additional config for SSH that needs to be changed. For our image that we are using in this example (Ubuntu Server 22.04 LTS (HVM), SSD Volume Type), we also need to change the file at the location below:

/etc/ssh/sshd_config/60-cloudimg-settings.conf

Open this file and make the same change we did for the other sshd_config file

PasswordAuthentication yes

For the changes to SSH to take effect, restart the SSH service:

sudo systemctl restart ssh

Next, let's create a dedicated user account for our lab participants.

sudo adduser lab-user

When prompted:

• Enter a password that will be used for lab-user (make sure you remember this, as we will need it later!)
• Re-enter the password to confirm.
• You can press Enter for all the full name, room number, etc., prompts.
• Confirm with Y when asked if the information is correct.

Note: We recommend changing the password above to something unique to you and this machine.

At this point, we recommend logging out of the existing SSH session as the Ubuntu user and logging in as the newly created lab-user to verify that the SSH configuration has been updated and that you can successfully connect to the machine via password-based SSH authentication. 

ssh lab-user@<ec2-ip></ec2-ip>

You should be prompted to enter the user's password, which will connect you to the machine.

ssh lab-user@52.18.126.144 lab-user@52.18.126.144's password: >Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1029-aws x86_64) >lab-user@ip-172-31-17-115:~$

Ready to create the lab challenge? Read part 2 here.