Hands-On AWS Penetration Testing with Kali Linux

4.7 (6 reviews total)
By Karl Gilbert , Benjamin Caudill
  • Instant online access to over 8,000+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Setting Up a Pentesting Lab on AWS

About this book

The cloud is taking over the IT industry. Any organization housing a large amount of data or a large infrastructure has started moving cloud-ward — and AWS rules the roost when it comes to cloud service providers, with its closest competitor having less than half of its market share. This highlights the importance of security on the cloud, especially on AWS. While a lot has been said (and written) about how cloud environments can be secured, performing external security assessments in the form of pentests on AWS is still seen as a dark art.

This book aims to help pentesters as well as seasoned system administrators with a hands-on approach to pentesting the various cloud services provided by Amazon through AWS using Kali Linux. To make things easier for novice pentesters, the book focuses on building a practice lab and refining penetration testing with Kali Linux on the cloud. This is helpful not only for beginners but also for pentesters who want to set up a pentesting environment in their private cloud, using Kali Linux to perform a white-box assessment of their own cloud resources. Besides this, there is a lot of in-depth coverage of the large variety of AWS services that are often overlooked during a pentest — from serverless infrastructure to automated deployment pipelines.

By the end of this book, you will be able to identify possible vulnerable areas efficiently and secure your AWS cloud environment.

Publication date:
April 2019


Chapter 1. Setting Up a Pentesting Lab on AWS

This chapter aims to help penetration testers who don't have direct access to targets for penetration testing set up a vulnerable lab environment within AWS. This lab will allow testers to practice various exploitation techniques using Metasploit and rudimentary scanning and vulnerability assessment using multiple tools within Kali. This chapter focuses on setting up a vulnerable Linux VM and a generic Windows VM on AWS, putting them on the same network.

In this chapter, we will cover the following topics:

  • Setting up a personal pentesting lab for hacking on the cloud
  • Configuring and securing the virtual lab to prevent unintended access

Technical requirements

In this chapter, we are going to use the following tools:

  • Damn Vulnerable Web Application
  • Very Secure File Transfer Protocol Daemon (vsftpd) version 2.3.4

Setting up a vulnerable Ubuntu instance

As the first of the two vulnerable machines that we will be creating, the vulnerable instance of Ubuntu will contain a single vulnerable FTP service, as well as some other services.

Provisioning an Ubuntu EC2 instance 

The very first step in setting up our vulnerable lab in the cloud will be to provision an instance that will be running a vulnerable operating system. For this purpose, we can use an Ubuntu LTS version. This can be accessed from the AWS Marketplace for quick deployment.

We will use Ubuntu 16.04 for this purpose:

Once we click on the Continue to Subscribe button, we are prompted to configure the instance that we are going to launch. Since this is a pretty standard image, we will proceed with the default settings except for Region and VPC settings.

For Region, you can use the AWS Region that is closest to yourself. However, keep in mind that all the other instances you create on AWS need to be hosted in the same region or they cannot be a part of the same network.

For VPC, make sure you note down the VPC and the subnet IDs that you are using to set up this instance. We will need to reuse them for all the other hosts in the lab. In this case, I will be using the following:

It should be noted that the VPC IDs and the subnet IDs will be unique for everyone. Once done, we can proceed to deploy the EC2 instance by clicking on the Launch with the 1-Click button.

Once done, the next step is to SSH into the newly created VM using the following command:

ssh -i <pem file> <IP address of the instance>

Once connected, run the following command:

sudo apt-get update && sudo apt-get dist-upgrade

These commands will update the repository listing and all the packages installed on the instance, so we don't have to deal with any old packages.

Installing a vulnerable service on Ubuntu

For this Ubuntu host, we will be installing a vulnerable version of an FTP server, vsftpd. Version 2.3.4 of this FTP software was found to be backdoored. In this chapter, we will be installing this backdoored version and then will attempt to identify it using a pentesting box we will set up in the next chapter, and finally we will exploit it.

To make things easier, the backdoored version of vsftpd 2.3.4 is archived on GitHub. We shall be using that code base to install the vulnerable software. To start with, we need to clone the git repository:

git clone https://github.com/nikdubois/vsftpd-2.3.4-infected.git

Next, we need to install packages for setting up a primary build environment. To do this, we run the following:

sudo apt-get install build-essential

Now, we cd into the vsftpd folder to build it from source. However, before doing that, we need to make a small change to the Makefile. The -lcrypt value needs to be added as a linker flag:

Once done, save the file and just run make.

If all goes well, we should see a vsftpd binary in the same folder:

Next, we need to set up some prerequisites before installing vsftpd. Namely, we need to add a user called nobody and a folder called empty. To do that, run the following commands:

useradd nobody
mkdir /usr/share/empty

Once done, we can run the installation by executing the following commands:

sudo cp vsftpd /usr/local/sbin/vsftpd
sudo cp vsftpd.8 /usr/local/man/man8
sudo cp vsftpd.conf.5 /usr/local/man/man5
sudo cp vsftpd.conf /etc

With that done, we need to execute the vsftpd binary to confirm whether we can connect to the localhost: 

The next step is to set up anonymous access to the FTP server. To do this, we need to run the following commands:

mkdir /var/ftp/
useradd -d /var/ftp ftp
chown root:root /var/ftp
chmod og-w /var/ftp

Finally, enable local login to the vsftpd server by making the following change to /etc/vsftpd.conf:


Setting up a vulnerable Windows instance

With a vulnerable Linux Server set up, we now set up an attack vector through a Windows server that's running a vulnerable web application. This application shall provide two environments that readers without an actual test environment can try their hand at.

Provisioning a vulnerable Windows server instance

For the purpose of this lab host, we will be using a Server 2003 instance from the AWS Marketplace:


The provisioning steps are pretty much identical to what we used to set up the Linux instance earlier. Care should be taken that the VPC settings are similar to what we used for the previous instance. This will later allow us to configure the VMs to be on the same network.

After verifying the VPC settings and the region, we proceed to launch the instance—precisely as we did earlier. Finally, we set the key-pair that we have been using all along and we are good to go. Once the instance has been launched, we need to follow a slightly different process to access a Windows instance remotely. Since Remote Desktop Protocol (RDP) doesn't support certificate-based authentication, we need to provide the private key to decrypt and get the password using which we can log in. This is done by simply right-clicking on the instance and selecting Get Windows Password:

On the following screen, we are required to upload the private key that was downloaded earlier:

Once done, simply clicking on Decrypt Password will provide us with the password that we can use to RDP into our Windows server instance. Once done, it's a simple matter of firing up Remote Desktop and connecting to the IP address using the displayed credentials.

Once we are logged in, the next step is to set up XAMPP on the Windows server so we can host a vulnerable website on the server. But before we proceed, we need to install the latest version of Firefox on the server, since the Internet Explorer version that comes packaged with Windows Server 2003 is pretty old and doesn't support some website configurations. To download XAMPP, just access https://www.apachefriends.org/download.html and download the version that's built for XP and Windows Server 2003:

Note that you will need to scroll down and download the correct version of XAMPP:

Finally, we need to follow the default installation process, and we will be set up with a working installation of PHP, Apache, and MySQL, along with a few necessary utilities that we need to manage a website. 

Configuring a vulnerable web application on Windows

In this section, we will be setting up an extremely vulnerable web application for the pentesting lab. To begin with, let's clear up the XAMPP hosting folder by accessing C:\xampp\htdocs.

Create a new folder called _bak and cut and paste all the existing files into that folder. Now, let's download the vulnerable website's source code. For this, we will use one of the many vulnerable PHP samples that are available on GitHub: https://github.com/ShinDarth/sql-injection-demo/.

The fastest way to get the files is to directly download the ZIP file:

Downloading the source code

Once downloaded, it's simply a matter of copying the contents of the ZIP file into the C:\xampp\htdocs folder. If done correctly, this is what the file structure should look like:

The file structure

Once completed, the next step is to create a database for the application and import the data into it. To achieve this, you need to access the phpMyAdmin interface, which is accessible at Once here, select the New option under Recent:

Here we create a new database called sqli:

Next, to import data into the newly created database, we go into the Import tab and browse to the database.sql file that we just extracted into the htdocs folder:

Once we click on Go we will see a success message. Now, if we browse to in our browser, we will be able to access the vulnerable website:

Congratulations, you have successfully configured a vulnerable web application on the Windows server! The next step will be to set up the networking rules within our VPC so that the vulnerable hosts are accessible from the other EC2 instances.


Configuring security groups within the lab

Now that we have set up two vulnerable servers, the next step is to configure network so that our web application isn't accessible to outsiders and, at the same time, so that the other lab machines can communicate with each other.

Configuring security groups

We had originally set all of the EC2 instances to be on the same VPC. This implied that the EC2 instances would be on the same subnet and would be able communicate with each other through internal IP addresses. However, AWS doesn't want to allow all 4,096 addresses on the same VPC to be communicating with each other. As a result, the default security groups don't allow communication between EC2 instances.

To allow connectivity from the Ubuntu instance to the Windows instance (you can repeat these steps for the Kali instance that will be set up in the next chapter), the first step is to get the Private IP address of the Ubuntu host:

Description tab showing the Private IPs

Next, we need to modify the security group rules for the first Windows instance. This is as simple as clicking on the security Group Name in the summary pane to get to the Security Group screen:

Security Group screen

Now we simply need to click on the Edit button and add the rule allowing all traffic from the Kali Linux instance:

Once done, just save this configuration. To confirm that Kali can now communicate with the Windows server, let's run a curl command to see if the site is accessible:

curl -vL

Make sure to replace the IP address with your IP address for Windows. If all is well, there should be a bunch of JavaScript in response:

In the next chapter, once the Kali PentestBox has been set up, the preceding steps can be used to whitelist the Kali Linux IP address on both the Ubuntu and the Windows server instances so we can get started with hacking the lab environment!



In this chapter, we have set up a lab that can prove useful to beginner penetration testers who do not have access to a test environment or hands-on exposure to a lab. In our lab, we have set up one Ubuntu host with a vulnerable service running on it, and we also set up a Windows server host that is running a vulnerable web application. This represents the two biggest surface areas for an attack in any environment. Additionally, we also went through the process of establishing a network connection between the various instances that we have set up so far. With these steps taken care of, the user can set up any operating system instances in the cloud, set up security groups to configure networking, and protect against unauthorized access as well.

In the next chapter, we will be looking at setting up a Kali PentestBox, using which we can perform scanning, enumeration, and exploitation of the two vulnerable EC2 instances that we have set up.


About the Authors

  • Karl Gilbert

    Karl Gilbert is a security researcher who has contributed to the security of some widely used open-source software. His primary interests relate to vulnerability research, 0-days, cloud security, secure DevOps, and CI/CD.

    Browse publications by this author
  • Benjamin Caudill

    Benjamin Caudill is a security researcher and founder of pentesting firm Rhino Security Labs. Built on 10+ years of offensive security experience, Benjamin directed the company with research and development as its foundation, into a key resource for high-needs clients.

    Benjamin has also been a major contributor to AWS security research. With co-researcher Spencer Gietzen, the two have developed Pacu (the AWS exploitation framework) and identified dozens of new attack vectors in cloud architecture. Both GCP and Azure research are expected throughout 2019.

    As a regular contributor to the security industry, Benjamin been featured on CNN, Wired, Washington Post, and other major media outlets.

    Browse publications by this author

Latest Reviews

(6 reviews total)
O livro foi disponibilizado de imediato após o pagamento, o download em pdf e para o Kindle foi sem complicação.
Not yet, will plan to continue training
Fast response and good experience

Recommended For You

Book Title
Access this book, plus 8,000 other titles for FREE
Access now