Setting Up Isolated Penetration Testing Lab Environments on AWS

If you have worked on real-world projects and systems running in the cloud, you are probably aware that actual network environments generally involve more than a single cloud resource. To ensure that critical resources are not exposed and directly accessible from resources outside of the network environment, cloud resources are grouped and proper network configuration involving security groups, network access control lists, and routing rules is implemented as well. With a segmented network architecture, attackers may need to compromise a less secure system first and then use this compromised system to pivot to critical resources in internal networks. This technique, known as pivoting, involves using the right set of tools along with the correct sequence of steps, which can be mastered through practice. If only we had a lab environment where we could try out various tools and techniques for pivoting! Well, I have some good...

Technical requirements

Before we start, we must have the following ready:

• An Amazon Web Services account
• Any text editor (such as Notepad++, Visual Studio Code, or Sublime Text) where we can temporarily store specific values (for example, our local machine’s IP address) used in the hands-on solutions in this chapter

You may proceed with the next steps once these are ready.

Important note

Make sure you read the available documentation, along with the FAQs, to have a solid understanding of what is free (and what is not free) when creating resources in AWS. In addition to this, make sure you don’t use any existing AWS account with production (or staging) environment resources for the hands-on exercises and solutions in this book. It is strongly recommended that you create a new AWS account specifically for launching intentionally vulnerable resources. This will ensure that your production (or staging) environment resources remain separate and secure...

Leveraging Terraform to automatically set up the lab environment

In this chapter, we will have a network environment in AWS that mimics the peered network setup we prepared in Chapter 4, Setting Up Isolated Penetration Testing Lab Environments on GCP, and Chapter 5, Setting Up Isolated Penetration Testing Lab Environments on Azure. It is important to note that while the chapter titles are very similar, the design of the lab environments in these chapters has significant differences.

Like the previous chapters, we will use Terraform to set up the lab environment using various types of resources and components in our AWS account. We must familiarize ourselves with the key AWS concepts and services before proceeding with the hands-on portion of this chapter. Once we have a solid understanding of the relevant AWS concepts and services, it will be much easier to interpret and tweak the Terraform configuration code. In case you are not yet familiar with the concepts, services, and resource...

Validating network connectivity and security

When building a pivoting lab, we must test and validate the network connectivity of the environment. This will help ensure that the network configuration, necessary routes, and firewall rules have been set up to facilitate the movement of traffic between different segments and systems in the network.

Important note

Even if we use automation tools to build the lab infrastructure, it is still possible to encounter network connectivity issues.

There are a variety of ways to validate network connectivity and security. In this section, we will test and validate network connectivity the manual way and the automated way. That said, this section is divided into the following subparts:

• Part 1 of 3 – Authorizing the use of the serial console
• Part 2 of 3 – Manually verifying network connectivity with ping tests
• Part 3 of 3 – Using the Reachability Analyzer to validate network connectivity

Without...

Setting up the attacker VM instance

In this section, we will be setting up our attacker EC2 instance. Compared to Chapter 4, Setting Up Isolated Penetration Testing Lab Environments on GCP, and Chapter 5, Setting Up Isolated Penetration Testing Lab Environments on Azure, our attacker instance setup in this chapter will be much simpler as we will only work with a Terminal.

That being said, let’s proceed with setting up the attacker VM instance:

1. Navigate to the list of EC2 instances (using the sidebar). Toggle the checkbox on to select vm-kali and then click the Connect button. This will redirect you to the Connect to instance page.
2. In the last tab (EC2 serial console), click the Connect button to access the instance via the EC2 serial console.

Note

Inside the serial console, if you are seeing a blank black screen, simply press the Enter key to see the root@kali:~# command prompt. If you are having issues accessing the attacker VM instance, vm-kali, feel...

Simulating penetration testing in the isolated network environment

Given that our lab environment in AWS has been set up successfully, we can now proceed with having a penetration testing simulation to verify that everything has been configured correctly. Of course, we will work with a simplified penetration testing process as our primary goal is to assess if the lab environment has been set up and configured properly.

Before we start the simulation, let’s quickly discuss the relevant concepts, terminologies, and tools we need to know for this section:

• Network pivoting: Network pivoting refers to the technique of using a compromised system as a gateway to access other interconnected systems or segments within a network. Using various network pivoting techniques and tools, an attacker can extend their reach, navigate through internal resources, and potentially escalate privileges.
• Lateral movement: Lateral movement refers to the act of an attacker moving horizontally...

Cleaning up

Wait a minute... we are not done yet! Cleaning up the cloud resources we created or deployed is a crucial step when working with penetration testing lab environments. If we don’t clean up and delete the resources we created right away, we might end up paying for unused cloud resources.

At a minimum, we will be paying for the time the t3.medium EC2 instance (for the attacker instance) and the two t2.micro EC2 instances (for the target instances) are running. Note that there are other costs we should consider as well, including data transfer fees, storage costs for any persistent data used by the instances (such as EBS volumes attached to the EC2 instances), potential charges for additional AWS services utilized in the lab environment (for example, monitoring logs), and any applicable taxes or fees associated with AWS usage.

Note

Since the overall cost when running these resources depends on several parameters, it is best to refer to the pricing documentation...

Summary

In this chapter, we discussed how to set up a pivoting lab on AWS where we can practice pivoting techniques. We started by using Terraform to automatically build a simple environment with an attacker instance, along with two target instances. We then tested the network connectivity and security of the lab to validate the network configuration specified in the Terraform code. Lastly, we performed a penetration testing simulation to verify if the lab environment had been set up properly.

Now that we’ve finished this chapter, we will shift our focus to preparing an IAM privilege escalation lab environment in the next chapter. If you are wondering how an IAM privilege escalation lab is (mis)configured, then the next chapter is for you!

Further reading

For additional information on the topics covered in this chapter, you may find the following resources helpful:

• Amazon Virtual Private Cloud – What is VPC peering? (https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)
• Amazon Virtual Private Cloud – What is Network Access Analyzer? (https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html)
• New – VPC Reachability Analyzer (https://aws.amazon.com/blogs/aws/new-vpc-insights-analyzes-reachability-and-visibility-in-vpcs/)
• AWS Architecture Blog – Reduce Cost and Increase Security with Amazon VPC Endpoints (https://aws.amazon.com/blogs/architecture/reduce-cost-and-increase-security-with-amazon-vpc-endpoints/)
• AWS Architecture Blog – One to Many: Evolving VPC Design (https://aws.amazon.com/blogs/architecture/one-to-many-evolving-vpc-design/)
• AWS re:Invent 2022 – Advanced VPC design and new Amazon...