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