From the moment we decided to deploy a Kali Linux instance on Amazon Web Services, our primary objectives were clear: stay within the Free Tier, ensure the environment remained isolated and secure, and enable convenient, password-based SSH access. We began by subscribing to the official Kali Linux AMI through the AWS Marketplace, which allowed us to use a prebuilt, cloud-optimized image without incurring additional charges. Although AWS does not charge for the AMI itself, it is essential to confirm that the chosen image is marked as Free Tier eligible; the official Kali Linux AMI meets that requirement and includes cloud-init support, which we would later leverage to configure SSH settings automatically on first boot.

With the AMI in hand, we turned our attention to network architecture. Rather than slipping our instance into the default VPC, which tends to be overly permissive and shared among multiple users, we created a dedicated VPC with a /16 IPv4 CIDR block. Within that VPC, we established a single public subnet by carving out a /24 block, enabling auto-assignment of public IPv4 addresses so our Kali instance could communicate with the outside world. To tie this subnet to the Internet, we provisioned an Internet Gateway and attached it to the VPC. Finally, we defined a route table for the public subnet and added a default route to the Internet Gateway, ensuring that traffic destined for any external address would flow through the gateway rather than remaining isolated.

Securing inbound and outbound traffic was our next priority. We created a security group specifically for SSH access, restricting incoming connections to port 22 and limiting the source to our own IP address. This guarded against unauthorized login attempts from the broader Internet. We left the outbound rule open—allowing all traffic—so that once the Kali instance was up and running, it could reach external repositories for updates and tool installation without impediment. This balance of tight ingress controls and open egress rules is a foundational best practice for cloud-based systems, particularly those used for penetration testing where frequent downloads of exploits and tools are routine.

Launching the instance itself was straightforward once the network and security groundwork had been laid. We selected a t2.micro instance type, the smallest AWS offers that remains free for eligible accounts, and attached it to our newly minted VPC, subnet, and security group. To automate system configuration, we supplied a small cloud-init script in the user-data field. This script set a strong password for Kali’s default “kali” user, modified the SSH daemon configuration to permit password authentication and root login, and then restarted the SSH service. By doing this at instance launch, we eliminated the need for manual reconfiguration after first boot, cutting down on steps and ensuring reproducibility if we ever needed to recreate the environment.

After AWS finished provisioning the instance, we retrieved its public IPv4 address from the EC2 console and initiated an SSH session. The SSH client rightly warned us about the unfamiliar host key fingerprint; once we accepted and saved it, we entered the password previously defined in our cloud-init script. Despite an initial “Permission denied” when the password prompt appeared, a second attempt succeeded and delivered us to the minimal Kali shell. At this point, we confirmed our identity by noting the Kali version string and system messages displayed upon login, acknowledging that this was indeed the cloud-tailored build of Kali Linux.

Once inside, our hands-on tasks continued with privilege escalation and system hardening. Using sudo, we switched to the root user and, if desired, set a dedicated root password to further simplify or control future logins. We updated the package index with apt update, ensuring our repositories were current before installing any additional software. Recognizing that the cloud image is deliberately minimal, we discussed two installation paths: the full kali-linux-default meta-package for a comprehensive toolset or the more restrained kali-linux-top10 for a lighter footprint that respects the Free Tier’s 8 GiB storage cap. We also explored re-securing SSH by changing its listening port, installing Fail2Ban to block repeated failed logins, and ultimately reverting to key-only authentication once we were comfortable—restoring the default “passwordAuthentication off” security posture.

Finally, we emphasized cost control and cleanup. AWS Free Tier benefits apply only while resources exist, so terminating the EC2 instance and deleting the VPC, subnet, Internet Gateway, route table, and security group when our testing concludes is crucial. This step not only prevents unexpected billing but also ensures that no orphaned resources remain accessible. By the end of this process, we had achieved a resilient, Free Tier–compliant Kali Linux environment, fully customizable via cloud-init, isolated within its own VPC, and secured for SSH access. This foundation empowers us to conduct penetration tests, develop security tools, or learn offensive techniques without worrying about undue exposure or runaway costs.

Creating a deliberately vulnerable target instance within a controlled AWS environment begins with careful planning of network architecture and instance configuration. First, you must establish a secure Virtual Private Cloud (VPC) that isolates your testing environment from production workloads. Within this VPC, create two subnets: one public subnet for the Kali attacker instance and one private subnet for the vulnerable target instance. Assign the Kali machine a public IP so that you can SSH into it from your local network, while the target remains private, reachable only through internal routing and security‐group rules. Each instance is placed in its own security group: the Kali security group permits SSH (TCP/22) from your workstation’s IP, and the target security group permits only a single custom TCP rule for port 21, with the source restricted to the Kali security group.

Once the network is in place, launch a minimal Ubuntu server in the private subnet using an appropriate AMI and assign no public IP. Supply a cloud‐init user‐data script that performs the following actions automatically on first boot: update package lists, install a specific legacy version of vsftpd (2.3.4) from an archive pool, resolve dependencies, and adjust the vsftpd configuration to enable anonymous logins and bind to IPv4 only. Finally, the script ensures that the vsftpd service is enabled and restarted. This automated configuration guarantees that the target instance boots up with the vulnerable FTP daemon listening on port 21, ready to be discovered and exploited.

From the Kali instance, the penetration test begins by enumerating the internal network. Using tools like ifconfig and ip addr, the tester confirms their IP address and network mask. A quick ping sweep or Nmap ping scan identifies live hosts on the 10.0.1.0/24 network. With the target’s private IP in hand, a focused port scan (for example, nmap -sS -p21 -Pn 10.0.1.54) reveals that TCP port 21 is open and running vsftpd version 2.3.4. The presence of this specific version is critical, as it contains a known “smiley” backdoor that spawns a root shell on a high-numbered port when a specially crafted username is provided.

To exploit the vulnerability, the tester uses netcat to send the backdoor trigger and then connect to the resulting remote shell:

# trigger backdoor
echo "USER backdoor:)" | nc <target-ip> 21

# connect to spawned shell
nc <target-ip> 6200
      

Once a shell is obtained, the tester can navigate the filesystem, escalate privileges if necessary (although the backdoor already grants root), and demonstrate the impact of the vulnerability. Throughout this process, all actions are confined within the private network and controlled by security-group rules, ensuring that the only path to compromise is the intended vulnerable service.

By combining AWS’s networking and instance automation features with classic pentesting methodologies, one can safely create, discover, and exploit a deliberately vulnerable target. This setup not only illustrates how misconfigured cloud services and unpatched software can lead to complete system compromise but also provides a reproducible, sandboxed environment for learning and practicing offensive security techniques.