You know, usually in cloud architecture, you're building a fortress. You can figure your keys, you lock down all the ingress rules, and the security engineer just kind of points at the architecture and says, there it is impenetrable.
Right, that's the standard goal. You want to keep everyone out exactly.
But today we are taking the exact opposite approach. We're deliberately building a house of cards. We are looking at excerpts from the book hands on AWS Penetration Testing with Caulli Linux by Carl Gilbert Benjamin Caddle.
Yeah, and it's a really fascinating text because it flips the script.
It really does. The mission for this deep dive is to demystify how cybersecurity professionals practice their craft. We are going to guide you through the exact blueprint for building a personal quarantine hacking laboratory entirely in the Amazon Web Services cloud.
Because you know, abstract theory only gets you so far, right, So.
Instead of learning how to build secure servers today, we are intentionally building incredibly vulnerable ones. Okay, let's impact it. Why why would anyone pay Amazon to host a server that is basically begging to be hacked?
Well, because you can't meaningfully patch a vulnerability if you have never watched it being exploited in real time.
Oh sure that makes sense.
Yeah, I mean to really understand the mechanics of an attack, you need a controlled, completely isolated environment, somewhere you can launch live exploits without the risk of bringing down your company's actual production database. You need infrastructure that is meant to be compromised, which.
Means before you can practice those exploits, you need something to actually hack. You have to meticulously construct the crash test dummies basically exactly.
And the blueprint we're following starts with provisioning two highly vulnerable target machines. Right in AWS, we start with a Linux machine specifically and one to sixteen point zero four.
Instance, which is pretty outdated, right.
Very outdated, and that gives us a fragile foundation. But the real focal point is the application layer design calls for downloading a specific heavily backdoored FTP server directly from a gehabripo. It's called VSFTPD. Doatch two point three point four infected dot get.
Man the two point three point four version of VSFTPD that is like legendary and offensive security sort of absolutely for anyone who hasn't encountered it. This is the infamous smiley face backdoor from way back in twenty eleven. Basically, if an attacker tries to log into the FTP server and just adds a smiley face like a colon and a parenthesis to the end of their username, the malicious code intercepts that strength.
And it silently forks a root shell on port sixty two hundred.
Yes, it is a literal wink to the attacker. It's crazy.
It is brilliantly simple. But getting that infected code to actually run on our modern lab instance, that requires some bizarre reverse engineering.
Because you aren't just downloading a package, right, You're building this malware from the raw.
Source code, right, And the raw code for this specific back door is actually, well, it's a bit. If you just run the standard make command to compile it, the compilation completely fails.
Yeah, you have to open the make file and manually append a dollar crypt linker flag before compiling it.
What's fascinating here is the deliberate precision required to be insecure. I love that phrase, right, because that doacwork flag. It tells the compiler to link the operating system's cryptography libraries into the FTP executable. The back door needs to intersect the authentication process, which means it has to interface with the system's password hashing mechanisms.
And without that flag, it just breaks.
Exactly Without it, the malware throws a segmentation FAULL and crashes. So you're basically debugging the attacker's malware to ensure it successfully compromises your own system.
That is so wild. It's like building a custom escape room, but instead of trying to break out, you are intentionally planting flaws so you can practice breaking in.
That's a perfect analogy.
And we don't stop there. The text says we have to create a system user named nobody and a directory named empty.
Right, you're carefully satisfying all the environmental prerequisites the damon expects, just so the back door can run silently in the background.
Yeah. And then finally we edit the vsftpd dot com file to explicitly enable local user logins.
Which ensures the authentication mechanism is fully active and ready to process that smiley faced trigger. It really moves vulnerability from a theoretical concept into very specific lines of compiled code running in memory.
Right, So, okay, we have our network level backdoor in the Linux dummy, but we also need to observe application layer flaws, which brings us to the Windows target.
Ah, yes, the Windows target.
Yeah. If the Linux machine is an old workhorse, this Windows target is a total relic. We are provisioning a Windows Server two thousand and three instance straight from the AWS marketplace.
Which is wild because Server two thousand and three lacks address base layout randomization and like most modern execution protections.
But getting into this instance in the cloud introduces a really unique AWS workflow.
Right it does. AWS strongly discourages password authentication, but since we're using Remote Desktop Protocol to access the Windows GUI, we actually need a password.
And AWS doesn't just email you the administrator credentials that would be too easy. When the EC two instance books up, it generates a random password, encrypts that password using the public rsakey you assigned at launch, and then dumps that ciphertext into the system log via the EC two metadata service.
It's actually a very elegant way to handle credentials without the hypervisor or AWS itself ever knowing your actual plain text password.
So to get in you have to download that encrypted payload from the console and process it locally with your private RSA key.
Exactly, your local machine decrypts the log, revealing the plaintext passwords.
Piece of cryptography. But once we use that password to RDP into the box, we just completely ruin the neighborhood.
Oh totally.
We install an old bundled version of xampp so that's a patchy myseqel and PHP, and drop a vulnerable web app, specifically a SQL injection demo called Shindarth Sickle injection demo directly into the c stocks folder.
We even log into FEASTPMI admin to manually import the database dot spl file.
Just bypassing every modern web application firewall and serving up a brittle database architecture on a silver platter YEP, handing it right to them.
Okay, here's where it gets really interesting. You've just created digital biohazards on the public Internet. If we don't immediately lock them down, real malicious actors will find and compromise them before we even start.
Exactly, So we have to talk about quarantining these biohazards using AWS, virtual Private clouds or vpcs.
Right, and a VPC can hold up to what four ninety six internal IP addresses, but by default AWS blocks them from talking to each other.
Yeah, it's zero trust out of the box. To allow the lab machines to communicate. The text tells us to manually capture the private IP of your attack machine and edit the inbound rules in the AWS security.
Groups, and you change those rules to allow all traffic exclusively from that one specific IP, right, effectively cutting off the rest.
Of the world precisely.
But wait, we are putting incredibly vulnerable machines on the largest public cloud in the world and relying entirely on a virtual firewall rule to keep the bad guys out? Isn't that inherently risky? I mean, it sounds reckless, it really does. But this is the ultimate lesson in cloud access control. You have to understand that security groups are the fundamental perimeter defense in AWS.
Okay, so it's not like a normal firewall, right.
It's not a traditional operating system firewall like IPTA BOWLS or Windows firewall. It operates independently at the hypervisor layer. Understanding how to strictly define a loud praffic Essentially, whitelisting is a non negotiable skill for any cloud engineer.
I see, so the hypervisor acts as the bouncer before traffic even gets near the operating system.
Exactly.
Okay, so the biohzards are quarantined safely inside the sandbox. But now you need to sneak your own attack machine inside that sandbox.
Right, you need to build the attacker's cock pit. The blueprint specifies deploying the Calli Linux Amazon Machine image, specifically an older twenty eighteen point one build running on a T two dot medium instance.
And that T two dot medium gives you two virtual cores and four gigabytes of RAM, which is super important because penetration testing tools will just chew through memory.
Oh they absolutely will.
Yeah.
But deploying Collie in the cloud introduces a major access dilemma.
Because AWS requires secure key based authentication by default. But the book shows how to configure the machine for easy mobile or browser access.
Right, yes, And to do that you have to alter the aescetrous config file to change permit root log in and password authentication to yes.
Wow.
Yeah, this raises an important question. You are actively reducing your security stance to enable root password logins. It highlights this eternal tug of war and tech between ultimate security, so key based limited users and ultimate convenience, which is browser based root access.
Right, and we get that convenience by installing a patch Guacamole. I like to think of Guacamole as having a high tech remote control that lets you pilot your attack ship from a coffee shop using just a web browser.
That's exactly what it is. But to set it up you need specific hardening steps because you just open up your SSH canfig right.
You don't want someone else stealing your attack.
Ship exactly, So you install it too the uncomplicated firewall and fail to banning to stop root force attacks. Then you open port twenty two for SSH and port five five five five five for Guacamole.
Yeah, and the book details changing the Tomcat eight server port to five five five five five, installing XRDP for the remote desktop, and setting up the userbambing dot xml file.
That user dash mapping dot xml file is critical because it tells Guacamole how to connect the browser session to the local XRDT service.
It's an amazing setup. So, Okay, you are sitting in the cockpit, you have the controls, but right now you are flying blind. Before you attack you need to map out the vulnerabilities of your.
Targets because you need to know exactly what you're dealing with, which means installing nessa's a really popular automated vulnerability scanner.
Right, But there are logistics involved. The text mentions you have to download the dot deb package from tenable and use a tool like win SCP to securely transfer it to the KALIEC two INSI.
Yeah, and then you install it via the dpkg command. But here is the final trick. NESSUS runs its own local web interface.
And you can't just open a browser on a headless server.
Exactly To securely view it on your local computer, you must create an SSH tunnel. You forward Colley's port eight eight three four back to your local one two seven by zero point one point eight eight three four.
Oh that is so clever. So once you do that, you just open your local browser, register a home license, and initialize the scanner data.
Yep, it pipes the interface securely over SSH right to your screen.
So what does this all mean for our toolkit? It's basically like turning on the targeting radar in a fighter jet. It automates all the heavy lifting of finding exactly where the armor is weak.
It really is, and running these NESSA scans mimics the exact to automated reconnaissance that malicious spots perform constantly across the entire Internet. By seeing the output of the scan on your intentional vulnerabilities, you learn exactly what the enemy sees when they look at a poorly configured network.
Wow. Okay, so let's summarize where we are. We've taken you from a completely empty AWS account to a fully functioning, quarantined cyber warfare.
Lab a pretty dangerous one too.
Yeah, no kidding. You've got an infected Linux server and Arcaic Windows SQL injection target, and a browser controlled Kali Linux attack box armed with.
A nessa's radar, all running in the cloud.
Right. And this matters because the cloud isn't just for hosting websites. It is a highly dynamic, disposable learning environment where you can build and destroy complex networks for pennies an hour.
It's an incredible resource for cybersecurity professionals, it really is.
But I want to leave you with a final kind of lingering question to ponder. We just saw how fast and easy it is to spin up intentionally vulnerable infrastructure using pre configure AMIS and code.
From GitHub literally just a few minutes, right.
So, if it's this easy to automate the deployment of vulnerabilities on purpose, what does that mean for real companies? Companies whose automated deployment scripts, infrastructure is code might contain a single, tiny misconfiguration.
Oh that is a terrifying thought.
How many accidental crash test dunies are out there on the real Internet right now, just waiting for someone's radar to ping them