Speaker 1: So welcome to today's deep dive. I'm really glad you're
Speaker 1: joining us for this one because we are getting into
Speaker 1: something incredibly cool today.
Speaker 2: Yeah, we're basically looking at how to safely play with
Speaker 2: fire exactly.
Speaker 1: I mean, if you want to learn how to fuse
Speaker 1: a bomb, you practice on a dummy, right, Yeah, you
Speaker 1: build this controlled environment where you know, clipping the wrong
Speaker 1: wire just triggers a loud buzzer instead of doubling a city.
Speaker 2: Block, right, which makes sense. But in the realm of
Speaker 2: professional cybersecurity and ethical hacking, people constantly try to learn
Speaker 2: their trade by just poking around on live critical networks,
Speaker 2: which is terrifying. It's completely terrifying. So today we're digging
Speaker 2: into this customized, exclusive exploration of Kevin Cardwell's comprehensive guide.
Speaker 2: It's called building Virtual pen Testing Labs for advanced penetration testing.
Speaker 1: And the mission for this deep dive isn't just learning
Speaker 1: how to hack. It's about how to actually think like
Speaker 1: a professional security tester, understand their exact systematic methodology, and
Speaker 1: discover how to build a safe virtual playground to practice
Speaker 1: these dark arts.
Speaker 2: Yeah, without going to jail or you know, accidentally taking
Speaker 2: down a hospital's database.
Speaker 1: Right, But before we can build that sandbox, we have
Speaker 1: to fundamentally understand what a professional tester is actually trying
Speaker 1: to achieve in the first place.
Speaker 2: And more importantly, what they're trying to break. Because the
Speaker 2: industry throws the term penetration testing around quite loosely.
Speaker 1: Oh totally. They treat security like it's a product you
Speaker 1: can just buy and install exactly.
Speaker 2: But Cardwell's entire thesis rests on the fact that security
Speaker 2: is a process. It's a methodology, not a product.
Speaker 1: Okay, let's unpack this because we all know the standard basics, right, authentication, authorization, confidentiality, integrity, availability,
Speaker 1: and non repudiation, right, the.
Speaker 2: Core components of security testing.
Speaker 1: But the source material makes this fascinating point about confidentiality.
Speaker 1: It's incredibly hard to protect because of the Internet's Bedrock
Speaker 1: protocol TCPIP.
Speaker 2: Yeah, the Transmission Control Protocol and Internet Protocol Suite, which.
Speaker 1: Is built back in the early nine teen seventies, right.
Speaker 2: For Arpinett, which was essentially just this tiny network connecting
Speaker 2: a few academic institutions and military researchers.
Speaker 1: Or everyone inherently trusted each other exactly.
Speaker 2: The foundational assumption baked into The actual mathematics of TCPIP
Speaker 2: was inherent trust.
Speaker 1: Wow.
Speaker 2: It was assumed that if you received a packet of data,
Speaker 2: it came from a reliable, friendly source. It wasn't designed
Speaker 2: for secrecy.
Speaker 1: So we basically took a protocol designed for a friendly
Speaker 1: neighborhood block party and used it to build a highly
Speaker 1: hostile global metropolis.
Speaker 2: That's a great way to put it. What's fascinating here
Speaker 2: is how that inherent trust issue completely undermines non repudiation, right.
Speaker 1: The idea that you can mathematically prove a specific person
Speaker 1: sent a specific.
Speaker 2: Message exactly, because all it takes is one compromised machine
Speaker 2: to throw that ole concept out the window. If a
Speaker 2: machine has a remote access trojan on it, you can't
Speaker 2: guarantee its state because.
Speaker 1: You can't prove the human sitting at the keyboard actually
Speaker 1: like send rather than like a malicious script running in
Speaker 1: the background.
Speaker 2: Precisely, and that shaky foundation brings up this massive corporate
Speaker 2: myth that Cardwall talks about.
Speaker 1: Oh, the vulnerability assessment versus pen testing thing.
Speaker 2: Yeah, most clients do not know what a penetration test
Speaker 2: actually is. They sign a contract for one, but they
Speaker 2: really just want a vulnerability assessment.
Speaker 1: I mean, a vulnerability assessment is basically like walking around
Speaker 1: a house checking if the windows are unlocked.
Speaker 2: Right, it's just a mapping exercise.
Speaker 1: But a true penetration test is actually climbing through the window,
Speaker 1: walking into the living room and seeing if you can
Speaker 1: carry out the TV.
Speaker 2: Yes. True penetration testing involves actual exploitation to validate the vulnerability,
Speaker 2: and clients usually panic when they realize you intend to
Speaker 2: climb through the window.
Speaker 1: Wait, there was that amazing anecdote in the book.
Speaker 2: About this, right, Oh, the Foreign stock market it director. Yeah,
Speaker 2: so Cardwell recalls meeting with this director outlining the methodology.
Speaker 1: And he gets to the validation phase.
Speaker 2: Right, he explains they'll run real exploit code, and the
Speaker 2: director just haddocks and says, that is my stockbroker records,
Speaker 2: and if we lose them, we lose a lot of money.
Speaker 1: Oh, man, I bet they skip the validation step.
Speaker 2: They absolutely skip the validations.
Speaker 1: Because proving the windows unlocked isn't worth the risk of
Speaker 1: accidentally burning the house down exactly. But okay, armed with
Speaker 1: this knowledge that true pen testing requires exploitation, how does
Speaker 1: a professional systematically get to that point?
Speaker 2: Well, we have to look at the hackers blueprint, and
Speaker 2: card Well notes the crucial difference in the planning phase
Speaker 2: between a pro and a malicious hacker.
Speaker 1: Right time and legality. A malicious hacker has what six
Speaker 1: to nine months to plan, yeah.
Speaker 2: Six to nine months to passively stalk a target, and
Speaker 2: they can break the law. A professional tester bound by
Speaker 2: ethics has a two week contract and strict legal lines.
Speaker 1: Which means the pro has to rely heavily on ocentth
Speaker 1: right open source intelligence that non intrusive target.
Speaker 2: Search exactly, gathering public info without sending a single packet
Speaker 2: directly to the target's internal network use tools like end
Speaker 2: slook up or server sniff.
Speaker 1: Oh. Server sniff is so clever because Microsoft servers often
Speaker 1: block standard icmpping requests by default.
Speaker 2: Right, so a normal trace road just dies at the firewall.
Speaker 1: But Servicesniff gets around that by doing a TCP trace rope.
Speaker 2: Yes, it sends a tcps yn packet, usually to port
Speaker 2: eighty or four to forty three, and if they're hosting
Speaker 2: a public web server, the firewall has to let.
Speaker 1: That packet through or their website wouldn't work.
Speaker 2: Exactly, so you bypass the block by exploiting the ports
Speaker 2: that the business requires to be open.
Speaker 1: That's brilliant. And then there's the whole wayback machine strategy.
Speaker 2: Oh yeah, finding deleted tools.
Speaker 1: The specific example he gave was wild. He was looking
Speaker 1: for this stiganography tool called infistago right.
Speaker 2: From anti Labs. They had pivoted to antivirus software and
Speaker 2: completely scrubbed infistago from their site.
Speaker 1: But Cardwell just used the two thousand and eight archives
Speaker 1: on the way back Machine to find the old site
Speaker 1: and download the executable.
Speaker 2: Anyway, because the Internet never really forgets see.
Speaker 1: That is amazing. But then we get to Showdan and
Speaker 1: this is where I have to push back a little bit.
Speaker 2: Okay, lay it on me.
Speaker 1: Showdan is basically this massive cloud scanner. Right, Cardwell searches
Speaker 1: for like iPhone RU and instantly gets a list of
Speaker 1: specific vulnerable servers in Russia.
Speaker 2: Yeah, with IP addresses and open ports.
Speaker 1: Right. So, if tools like showdan are publicly indexing vulnerable
Speaker 1: servers globally, isn't that blurring the line between passive research
Speaker 1: and handing a loaded gun to the bad guys.
Speaker 2: Well, that's exactly why the methodology is so rigid. Showdowan
Speaker 2: is doing the active scanning as user, You're just reading
Speaker 2: a public database. The progression from passive observation to active probing.
Speaker 2: That's where the legal and ethical lines are drawn.
Speaker 1: Ah okay, so looking at Shrodan is just reading the
Speaker 1: phone book exactly.
Speaker 2: But the moment you direct your own machine to interact
Speaker 2: with those ips, you enter the intrusive target search phase.
Speaker 2: You're dialing the numbers.
Speaker 1: And that requires authorization.
Speaker 2: Explicit written authorization. Once you have that, you start finding
Speaker 2: live systems with en mapping sweeps, checking open ports, and.
Speaker 1: The OS numeration is wild. Using the n.
Speaker 2: Map a command, Yeah, it analyzes the microscopic quirks in
Speaker 2: how the server's TCPIP stack responds to guess the OS version.
Speaker 2: Then you bring in a vulnerability scanner like nexpos.
Speaker 1: And finally exploitation.
Speaker 2: Right cardwill uses metasploit exploiting the MS zero eight zero
Speaker 2: six seven vulnerability as his example to get a command shell.
Speaker 1: But getting there means analyzing the data correctly, like reading
Speaker 1: wire shark packet capture.
Speaker 2: Oh, the ICLC type three code thirteen example, that's a classic, Yeah.
Speaker 1: Walk us through that because to an untrained eye it
Speaker 1: just looks like a connection error.
Speaker 2: Right, So type three means destination unreachable, but the specific
Speaker 2: code thirteen means the communication is administratively.
Speaker 1: Filtered, meaning it's not a broken network exactly.
Speaker 2: It alerts the tester that a router explicitly blocked it
Speaker 2: because there is an access control list and ACL in place.
Speaker 1: It's like navigating a maze by tapping a cane against
Speaker 1: the wall and listening to the echo.
Speaker 2: That's a perfect analogy.
Speaker 1: But executing a buffer overflow or probing an ACL on
Speaker 1: a live corporate network is exactly what caused that stock
Speaker 1: market director.
Speaker 2: To panic, which is why you have to build the matrix.
Speaker 1: The virtual sandbox.
Speaker 2: Yes, choosing your virtual environment is critical, and Cardwall breaks
Speaker 2: it down into type one versus type two virtualization.
Speaker 1: Okay, here's where it gets really interesting because using a
Speaker 1: type one hypervisor like vSphere Hypervisor or esen, it rides
Speaker 1: directly on the hardware. Right, it's incredibly powerful, but it's
Speaker 1: basically like demolishing a house to the foundation just to
Speaker 1: build a custom recording studio. It dictates the OS directly,
Speaker 1: which is terrible for a.
Speaker 2: Laptop because you still need to write reports and check emails.
Speaker 1: Exactly, So use a type two hypervisor like virtual Box,
Speaker 1: hyper v or VMware Workstation, which.
Speaker 2: Rides on top of your existing operating system.
Speaker 1: It's like putting up soundproof partition walls in your existing
Speaker 1: spare bedroom. You still get the studio, but you don't
Speaker 1: have to wreck the house.
Speaker 2: I love that, but the tool nuances matter here. Virtual
Speaker 2: Box is great and it's free, but Cardwell notes it
Speaker 2: suffers from keyboard input.
Speaker 1: Glitches, yeah, requiring special extensions to fix. And then Microsoft's
Speaker 1: hyper V.
Speaker 2: Hyper v is tricky. It requires a sixty four bit
Speaker 2: OS and a CPU that supports.
Speaker 1: Sell it second level address translation.
Speaker 2: Right, And even if you have that, it historically struggles
Speaker 2: with Linux networking, which is a huge problem since so
Speaker 2: many pen testing tools are Linux based.
Speaker 1: So the winner is VMware Workstation.
Speaker 2: Yes, it costs money, but it is the winner, and.
Speaker 1: It's the winner because of the virtual switches. Right. It
Speaker 1: allows for up to ten virtual switches on Windows.
Speaker 2: And up to two hundred and fifty five on Linux hosts.
Speaker 2: If we connect this to the bigger picture, the reason
Speaker 2: those ten virtual switches matter so much is because real
Speaker 2: world corporate networks are never flat.
Speaker 1: They aren't just one router with everything plugged in exactly.
Speaker 2: They are segmented. You have firewalls, DMZs, internal routing rules.
Speaker 2: If you can't simulate those complex, multi layered architectures, your
Speaker 2: practice lab is useless. For advanced testing.
Speaker 1: You can't practice pivoting from a web server to an
Speaker 1: internal database if everything's on a single flat network.
Speaker 2: Precisely, VMware Workstation gives you the infrastructure to build the
Speaker 2: actual maze.
Speaker 1: The room is useless if it's empty, right, how do
Speaker 1: we put realistic targets inside it?
Speaker 2: Well, you can populate it using pre built vulnerable ISOs.
Speaker 2: The security community has great options.
Speaker 1: Like the Samurai Web Testing Framework Samurai WTF.
Speaker 2: Yeah, or the oas Broken Web Application Project, which is
Speaker 2: actually sponsored by Mandian and.
Speaker 1: That includes tools like webgoat and Mutility.
Speaker 2: Exactly, you just mount the ISO, boot it up, and
Speaker 2: you have a target rich environment.
Speaker 1: But what about the format problem? Like what if a
Speaker 1: client gives you a VMware image a VMDK format but
Speaker 1: you only have Microsoft hyperv which uses VHD.
Speaker 2: That happens a lot. You can use conversion tools like
Speaker 2: the Starwin vtwov converter.
Speaker 1: Although the author notes of funny quirk about that.
Speaker 2: Oh yeah, He mentions that FreeBSD Systems old version nine
Speaker 2: point x usually just break during the.
Speaker 1: Conversion, just completely bricked.
Speaker 2: Yeah, totally unusable. But for modern Windows and Linux it
Speaker 2: works great.
Speaker 1: But the coolest thing in this whole section has to
Speaker 1: be P two V Physical to virtual.
Speaker 2: Oh absolutely, using tools like v center converter or even
Speaker 2: a feature built right into VMware workstation.
Speaker 1: So what does this all mean for the listener? I mean,
Speaker 1: imagine the power of this. You can literally take a chaotic,
Speaker 1: terrifyingly fragile server from a client's physical.
Speaker 2: Office like that's stock market server.
Speaker 1: Yes, you digitally clone it, trap it in your VMware matrix,
Speaker 1: and hit it with exploits all day long without ever
Speaker 1: risking their actual business.
Speaker 2: It is incredible. P TWOV is basically the ultimate bridge
Speaker 2: between theoretical lab practice and high stakes real world consulting.
Speaker 2: You are hacking an exact digital replica.
Speaker 1: It's just brilliant. So to recap our journey today, we
Speaker 1: went from understanding the true nature of the CIA triad
Speaker 1: and why confidentiality is so hard on the Internet, to
Speaker 1: breaking down the hacker's osent methodology.
Speaker 2: From passive reconnaissance to active exploitation.
Speaker 1: Right, and then we learn how to construct a multi
Speaker 1: switched virtual battleground and populate it with clone physical servers.
Speaker 2: It's an entire ecosystem for ethical hacking.
Speaker 1: It really is. But before we sign off, I want
Speaker 1: to leave you with a final thought. We talked early
Speaker 1: on about how Cardwell mentioned TCPIP being incredibly hard to
Speaker 1: secure because it was built in the nineteen seventies on
Speaker 1: inherent trust, right arpin net think about this. Yeah, all
Speaker 1: of this pen testing, all these complex virtual labs, this
Speaker 1: entire multi billion dollar cybersecurity industry, it all exists simply
Speaker 1: because we are trying to bolt security onto a foundation
Speaker 1: that was never meant to be secure.
Speaker 2: We're constantly patching a leaky ship exactly.
Speaker 1: So if the Internet eventually undergoes a foundational rewrite to
Speaker 1: replace TCPIP with a protocol built on zero trust by default,
Speaker 1: oh wow. Well, penetration testing as we know it simply
Speaker 1: cease to exist. Or will human error just find a
Speaker 1: brand new way to leave the virtual window open?
Speaker 2: That is a fascinating question, Tom.
Speaker 1: All Over, I think we all know the answer is
Speaker 1: usually human error. But anyway, thank you so much for
Speaker 1: taking this deep Doug with us. We'll catch you on
Speaker 1: the next one.