Setting Up Isolated Penetration Testing Lab Environments on Azure

In the previous chapter, we successfully built and automated a relatively simple penetration testing lab inside an isolated network environment in Google Cloud Platform (GCP). We primarily focused on one of the most important aspects when building lab environments in the cloud – protecting the vulnerable lab resources from the outside world.

In this chapter, we will take things a step further and build a more intricate lab environment using various services in Microsoft Azure. Our lab setup in this chapter will help us practice container breakout techniques, which involve escaping from a Docker container environment to gain unauthorized access to the host system. With containers being a fundamental component in modern deployments, understanding their security vulnerabilities is critical for ensuring the security of cloud-based applications. In addition to this, we will look at how managed identities in Azure...

Technical requirements

Before we start, we must have the following ready:

• A Microsoft Azure 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

Similar to AWS and GCP, Azure is a mature cloud platform that offers a wide range of services that allow us to build penetration testing environments in the cloud. We’ll find various options for configuring virtual machines, databases, and other cloud resources for building vulnerable-by-design lab environments in Azure. The costs associated with running these resources can vary, so 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 addition to this, make...

Preparing the necessary components and prerequisites

In this section, we will be setting up a few key components and prerequisites before we proceed with preparing the Terraform code in the next section. We will start by manually creating a resource group for storing some of the resources later in this chapter. In addition to this, we will generate the SSH keys that will be used to access the attacker’s virtual machine (VM) instance.

Before we proceed with the hands-on portion of this section, let’s familiarize ourselves first with a few key services and terminologies relevant to this section:

• Resource group: A logical container for grouping multiple resources together
• Golden image: A custom VM image containing all applications, along with the configuration settings designed to serve as a standardized template for provisioning multiple instances with identical software and configuration
• Cloud Shell: A browser-based interactive command-line environment...

Defining the project’s structure

In this chapter, we will use a Terraform project structure similar to what we had in Chapter 4, Setting Up Isolated Penetration Testing Lab Environments on GCP. While there are similarities between the lab environments in the previous chapter and this one, the lab environment in this chapter will have a few additional components to give it a bit more complexity:

Figure 5.4 – What our lab setup looks like (without the network environment)

One of the major components of the lab environment in this chapter will be a secure secrets store (Azure Key Vault) where we will store one of the flags. We will also make it possible for lab users (assuming the role of an attacker) to break out of a running container and gain unauthorized access to the host system inside the VM instance. Once access to the host system has been obtained, a system-assigned managed identity will allow access to the Azure Key Vault secrets from...

Preparing the isolated network

In this section, we will focus on setting up the isolated network environment that will contain the resources for our penetration testing lab. We will establish a secure network environment setup in Microsoft Azure that restricts traffic from external hosts from reaching the cloud resources deployed inside the network environment:

Figure 5.7 – Isolated network environment

Of course, the resources deployed inside should be able to communicate with each other even if they are deployed in different VNets. We will accomplish this by setting up a VNet peering connection to bridge two virtual networks, similar to how a VPC peering connection bridges two Google Cloud VPCs, as we saw in the previous chapter.

Before we proceed with preparing the isolated network environment, let’s quickly go through some of the Azure concepts, features, and terminologies relevant to this chapter:

• Subscription: A logical unit...

Setting up the target resources

With our isolated network environment ready, we can now proceed with setting up the target VM instance, along with a few additional resources such as the Azure Key Vault (containing an additional flag secret) and a vulnerable container running inside the VM instance with elevated privileges:

Figure 5.8 – The target resources we will set up in this section

In this section, we will set up the target VM instance inside VNet 01, similar to how we set up the target VM instance in the previous chapter. One major difference we will have in this chapter is that we will run the Metasploitable 2 container instead of the OWASP Juice Shop container. Like OWASP Juice Shop, Metasploitable 2 intentionally includes a variety of insecure configurations and vulnerable software packages. While Metasploitable 2 was primarily designed and distributed as a vulnerable VM, it is possible to configure and run it as a container. We will run...

Manually setting up the attacker VM instance

With our peered network environment setup ready (with the target resources running inside it), we can now proceed with setting up our Kali Linux attacker. In the previous chapter, we took a step-by-step approach to setting up and configuring the attacker VM instance. In this chapter, we will optimize things a bit and make use of a couple of scripts to further speed up the installation process.

That said, we will divide this section into two parts:

• Part 1 of 2 – Manually launching and configuring the attacker instance
• Part 2 of 2 – Verifying that our setup is working

Part 1 of 2 – Manually launching and setting up the attacker instance

Follow these steps:

1. In the search bar, type virtual machines and press Enter:
   

   Figure 5.10 – Navigating to the Virtual machines page

   Select Virtual machines from the list of available options to navigate to the Virtual...

Leveraging Terraform to automatically set up the attacker VM instance

The previous section primarily focused on setting up the attacker VM instance using pre-built scripts. This was necessary because we will utilize this VM instance (kali-00) as a reference to create a golden image. This golden image will be used in the Terraform configuration file to automatically set up the attacker VM instance (vm-kali).

Note

What will happen to the original VM instance (kali-00) we created? After using it to create the golden image, it becomes generalized and cannot be started again. That said, once the golden image has been successfully created, we will delete the original VM instance (kali-00).

This section is divided into the following subparts:

• Part 1 of 3 – Creating the golden image
• Part 2 of 3 – Deleting the manually created resources
• Part 3 of 3 – Preparing the Terraform configuration files

Without further ado, let’s begin!

Part...

Simulating penetration testing in the isolated network environment

Given that our lab environment in Microsoft Azure has been set up successfully, we can now proceed with a simplified penetration testing simulation to verify if everything has been (mis)configured correctly. Compared to the previous chapter, our penetration testing simulation in this chapter will be a bit longer as we are dealing with a relatively more complex setup:

Figure 5.18 – Penetration testing simulation

Our simulation starts by compromising a Metasploitable 2 container running inside the VM instance. Given that this running container has been configured with the --privileged flag enabled, we can escape the container environment using a container breakout technique and access the host system, where we’ll find the first flag. We will then utilize the system-assigned managed identity assigned to the VM instance to access Azure Key Vault, where we’ll find the second...

Cleaning up

Cleaning up the cloud resources we created or deployed is a crucial step when working with vulnerable cloud applications and environments. If we don’t clean up and delete the resources we created right away, we might end up paying for unused cloud resources. In addition to this, these cloud resources may end up being attacked by malicious users. At a minimum, we will be paying for the time the following resources are running:

• 1 x Standard_DS1_v2 Azure VM instance for the attacker machine
• 1 x Standard_D2s_v3 Azure VM instance for the target machine

Please be aware that there are other costs we have to take into account as well — including data transfer fees, storage costs for persistent data used by the instances, and potential charges for other Azure services utilized in the account, along with any applicable taxes or fees associated with the usage of Azure resources.

Note

Since the overall cost when running these resources depends...

Summary

In this chapter, we focused on setting up a penetration testing lab environment in Microsoft Azure. We prepared a vulnerable-by-design lab setup where we can practice container breakout techniques to gain unauthorized access to host systems. Our lab environment also highlighted the potential misuse of managed identities in Azure as these inadvertently create other exploitable attack paths for attackers. After setting everything up, we performed a penetration testing simulation to validate if our lab environment had been (mis)configured correctly.

In the next chapter, our focus will shift to preparing a penetration testing lab environment on AWS. In addition to setting up an isolated network environment, we’ll focus on preparing a lab setup where we can practice pivoting techniques that can be used to access internal systems and networks using the initially compromised machine. If you are excited to learn how to build a pivoting lab, 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:

• Connecting from your application to resources without handling credentials (https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview-for-developers?tabs=portal%2Cdotnet)
• How managed identities for Azure resources work with Azure virtual machines (https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-managed-identities-work-vm)
• Authentication in Azure Key Vault (https://learn.microsoft.com/en-us/azure/key-vault/general/authentication)
• Manage Key Vault using the Azure CLI (https://learn.microsoft.com/en-us/azure/key-vault/general/manage-with-cli2)
• Best practices for using Azure Key Vault (https://learn.microsoft.com/en-us/azure/key-vault/general/best-practices)
• Metasploitable 2 Exploitability Guide (https://docs.rapid7.com/metasploit/metasploitable...