Speaker 1: Have you ever wondered what truly goes on behind the
Speaker 1: digital curtain? How the very best defenders learn to think
Speaker 1: like whoa malicious actors all to keep our online world safer. Today,
Speaker 1: we're taking a deep dive into the fascinating realm of
Speaker 1: ethical hacking and penetration testing. Our mission to unpack the
Speaker 1: core concepts, the practical techniques, and the essential tools that
Speaker 1: empower individuals to understand and secure digital systems from the
Speaker 1: inside out.
Speaker 2: Really yeah, and our guide for this journey is the
Speaker 2: comprehensive book Learn Ethical Hacking from Scratch by Zaid Sabi.
Speaker 2: What's great is that this resource assumes no prior knowledge.
Speaker 2: It offers a truly ground up approach, which makes it
Speaker 2: perfect for our exploration today.
Speaker 1: Absolutely so, whether you're simply curious about cybersecurity, maybe looking
Speaker 1: to fortify your own digital defenses, or just love to
Speaker 1: understand how things work at the deepest level, this deep
Speaker 1: dive will give you a shortcut to being well informed
Speaker 1: and honestly with some truly surprising facts along the way.
Speaker 1: Get ready for some illuminating in sites, because we're about
Speaker 1: to unpack how ethical hackers learn to protect systems by
Speaker 1: understanding how to test their security just like well, real
Speaker 1: attackers do. Okay, So the term ethical hacking it almost
Speaker 1: sounds like an oxymoron to some people. Could you really
Speaker 1: break down for us how hacking can truly be ethical
Speaker 1: and what that critical distinction means, especially when we talk
Speaker 1: about black hat versus white hat hackers.
Speaker 2: Absolutely, it's a good question. At its core, ethical hacking
Speaker 2: is about learning to test the security of systems exactly
Speaker 2: as real attackers would. But and this is key, with
Speaker 2: explicit permission. Always it's all in the service of strengthening
Speaker 2: those systems, finding the holes before the bad guys do.
Speaker 2: To critical distinction, so we differentiate between black hat hackers
Speaker 2: who operate maliciously, you know, for criminal gain or disruption.
Speaker 2: Then there are gray hat hackers who kind of blur
Speaker 2: the lines, sometimes maybe finding a flaw and disclosing it,
Speaker 2: but maybe not always with permission first. And then white
Speaker 2: hat hackers, the ethical professionals we're focusing on today. Their
Speaker 2: intent is always to secure.
Speaker 1: Right, good guys using the same skills exactly.
Speaker 2: Yeah, and this raises an important question. Yeah, why should
Speaker 2: you listening right now learn about hacking even if you
Speaker 2: never intend to be a penetration tester. The fundamental reason
Speaker 2: is to truly understand vulnerabilities, you need to know how
Speaker 2: things break to build stronger, more resilient defenses. The book
Speaker 2: highlights a crucial point here. Any electronic device you interact with,
Speaker 2: your phone, your smart TV, your laptop, even web servers
Speaker 2: and routers, Yeah, they're all at their heart computers running
Speaker 2: operating systems and programs h as. The concepts we're discussing
Speaker 2: today are broadly applicable to pretty much anything in your
Speaker 2: digital life.
Speaker 1: One aspect that really opened my eyes when exploring this
Speaker 1: was the absolute necessity of a dedicated lab environment. You
Speaker 1: can't just go testing these techniques out on like your
Speaker 1: neighbor's WiFi.
Speaker 2: Right, Definitely not. That's illegal and unethical. This is where
Speaker 2: virtual box comes in. It's a program, it's free, and
Speaker 2: allows you to install virtual machines. Think of them as
Speaker 2: completely separate, isolated computers inside your main machine. This is
Speaker 2: incredibly important for penetration testing because well, first it avoids
Speaker 2: needing multiple physical computers, save space and money. And second,
Speaker 2: it completely isolates your hacking activities from your main system,
Speaker 2: so you can experiment break things, really push the limits.
Speaker 1: Without damaging your actual computer.
Speaker 2: Exactly, and then you can easily revert back if something
Speaker 2: goes wrong, no harm done to your primary setup.
Speaker 1: So what does this typical lab look like? What machines
Speaker 1: are we talking about?
Speaker 2: Yeah? In a typical setup, we work with three main
Speaker 2: virtual machines. First, our tacker machine. This usually runs Collie.
Speaker 1: Linux Collie, right, I've heard of that.
Speaker 2: Yeah. Collie is a specialized distribution of Linux based on Debian.
Speaker 2: It comes pre installed with i mean pretty much all
Speaker 2: the necessary penetration testing tools you'd need. Running it as
Speaker 2: a virtual machine is ideal for isolation, like we said,
Speaker 2: and makes it super easy to recover if things go sideways.
Speaker 1: Okay, attacker machine Collie. What else?
Speaker 2: Then we need victims. Our first victim is usually metasploid.
Speaker 2: It's another Linux machine. But here's the crucial detail. It's
Speaker 2: designed to be highly.
Speaker 1: Vulnerable, ah intentionally weak.
Speaker 2: Precisely, it's built specifically for learning penetration testing. It has
Speaker 2: numerous known weaknesses built right in for you to practice
Speaker 2: finding and exploiting.
Speaker 1: Got it, and the second victim.
Speaker 2: The second victim is usually a standard Windows machine, maybe
Speaker 2: Windows ten or something similar. This is used for scenarios
Speaker 2: that mimic a normal user browsing the internet, clicking links,
Speaker 2: opening files.
Speaker 1: Makes sense simulating a realistic target exactly.
Speaker 2: And Microsoft actually offers free virtual machine versions for developers
Speaker 2: and testers, which is really convenient for setting up these
Speaker 2: realistic attack simulations.
Speaker 1: Okay, attacker two victims. What about that recovery feature you
Speaker 1: mentioned right.
Speaker 2: That's snapshots a core feature of Virtual Box. It becomes
Speaker 2: absolutely invaluable. Think of snapshots like instant bookmarks for your
Speaker 2: virtual machine.
Speaker 1: State, like a safe point in a game, kind of
Speaker 1: like that.
Speaker 2: Yeah, they allow you to save the exact state of
Speaker 2: a virtual machine at any point in time. So let's
Speaker 2: say you're trying to exploit and you completely mess up
Speaker 2: the victim machine, maybe crash the operating system or something.
Speaker 2: If you took a snapshot beforehand, you can instantly revert
Speaker 2: right back to that previous working state.
Speaker 1: Wow, Okay, that sounds essential for learning It really is.
Speaker 2: A common practice is to take a fresh install snapshot
Speaker 2: right after setting everything up. Then if an update breaks
Speaker 2: something or an experiment goes totally wrong, boom, You're back
Speaker 2: to that clean slate in seconds, ready to try again,
Speaker 2: no reinstalling needed.
Speaker 1: Okay, that makes setting up a lab feel much less daunting. Now,
Speaker 1: Collie Linux, I know it has a graphical interface, but
Speaker 1: I hear you quickly move past that.
Speaker 2: Yeah, Collie has a nice graphical interface. GUI looks familiar
Speaker 2: like Windows or macOS. But you're right, you quickly pitt
Speaker 2: to the terminal the command line.
Speaker 1: Why is that? Why is the terminal so central?
Speaker 2: Well, the Linux terminal is just incredibly powerful. It lets
Speaker 2: users do far more than the GUI in many cases,
Speaker 2: and often it's much easier and quicker for specific tasks
Speaker 2: once you.
Speaker 1: Get the hang of it, faster than clicking around definitely
Speaker 1: for many things.
Speaker 2: But more importantly, in many real world penetration tests, you
Speaker 2: might only gain access via command prompt on the target,
Speaker 2: may through SSH or some other remote shell. If you
Speaker 2: don't know the commands, you can't do anything. So mastering
Speaker 2: the terminal is absolutely essential for controlling compromise systems effectively.
Speaker 1: Makes sense. So what are some basic commands people should know?
Speaker 2: Let's touch on a few foundational ones. The al's command,
Speaker 2: for instance, it lists files and.
Speaker 1: Directories like Dirt and Windows.
Speaker 2: Exactly like Dirt and Windows, and you can add options
Speaker 2: like ls L gives you a long listing with more detail, permissions, dates, file, sizes, etc.
Speaker 2: If you're ever unsure about any command, man which stands
Speaker 2: for manual, or just adding help or ad H after
Speaker 2: the command, those are your best friends.
Speaker 1: Ah built in help yep, they'll.
Speaker 2: Give you comprehensive information on how to use almost any command.
Speaker 2: It's a critical earning tool and a huge time saver.
Speaker 2: Almost a reflex for experienced users is the tab button
Speaker 2: for what for autocompletion? Start typing a command or a
Speaker 2: file name, Hit tab and the system will try to
Speaker 2: complete it for you or show you the possibilities if
Speaker 2: there's more than one.
Speaker 1: Oh. Nice safe typing and avoids typos.
Speaker 2: Huge time saver. Yeah, makes complex commands feel much more intuitive.
Speaker 2: Then there's CD for changing directories navigating around the filesystem,
Speaker 2: and PUD prints your current working directory so you know
Speaker 2: where you are. We also use app to get or
Speaker 2: just appt now. Usually that's for managing software, updating the
Speaker 2: list of available software, installing new programs, upgrading existing ones.
Speaker 2: Keeps your COLLY set.
Speaker 1: Up fresh, got it basics covered? Lab set up understood?
Speaker 1: Where do we go first?
Speaker 2: Okay, with our virtual lab ready, The first frontier and
Speaker 2: ethical hacker typically explores is the network itself. You know,
Speaker 2: the invisible pathways connecting all our devices. Network penetration testing
Speaker 2: could be broadly divided into let's say four main sections.
Speaker 2: There's pre connection stuff you do before even connecting, then
Speaker 2: gaining access, then post connection what you do once you
Speaker 2: are in, and finally detection and security aspects.
Speaker 1: Okay, logical steps, and we're starting with wireless.
Speaker 2: Yeah, let's focus on wireless networks initially. To start cracking
Speaker 2: Wi Fi, you'll first need to get your wireless adapter
Speaker 2: properly connected and configured inside your Colli Virtual Machine.
Speaker 1: How does that work? The VM is software, the adapter
Speaker 1: is hardware.
Speaker 2: Good point. This often requires installing the Virtual Box Extension
Speaker 2: pack first that enables better USB device support. Then you
Speaker 2: can essentially pass through your physical USB Wi Fi adapter
Speaker 2: to the COLLIVM so Collie can see it and control
Speaker 2: it directly. Not all adapters work well for this, mind you,
Speaker 2: some are better than others for hacking.
Speaker 1: Okay, so you need the right hardware and setup. Now.
Speaker 1: Something fundamental about networks is MSS addresses. You mentioned them earlier.
Speaker 1: Every network card has this unique physical static media access
Speaker 1: control address right assigned by the manufacturer. Why is the
Speaker 1: static identify or important?
Speaker 2: Here it's fundamental because MIC addresses are used for device
Speaker 2: identification and packet transfer at the very lowest level of
Speaker 2: the local network layer two for the technical folks. But
Speaker 2: here's the kicker, the surprising part for many. You can
Speaker 2: change your MSSEA.
Speaker 1: You can change a physical address.
Speaker 2: Well, you change what your operating system reports as your
Speaker 2: Mac address. It's called spoofing. This allows you to do
Speaker 2: a couple of things. You can avoid being easily traced
Speaker 2: while performing tests, making your activity less obvious. Or you
Speaker 2: could potentially impersonate a legitimate white listed device on a network,
Speaker 2: maybe a printer or an authorized laptop to bypass MAAC
Speaker 2: filtering security and gain access.
Speaker 1: Wow. Okay, so even fundamental identifiers aren't always fixed. That's insightful.
Speaker 2: It highlights that many things we assume are fixed in
Speaker 2: networking can actually be manipulated.
Speaker 1: Okay, so we understand how devices identify themselves and that
Speaker 1: we can even spoof that. What's the next step? Listening
Speaker 1: in exactly?
Speaker 2: The next logical step is to actually listen in on
Speaker 2: the digital conversations happening on the airwaves around you, even
Speaker 2: if you're not part of the chat. This is packets new.
Speaker 1: How do you do that with Wi Fi, you need
Speaker 1: to put.
Speaker 2: Your Wi Fi card into what's called monitor mode. Normal
Speaker 2: Wi Fi mode only pays attention to trafficman for your
Speaker 2: device or the network you're connected to. Monitor mode is different.
Speaker 2: It allows you to capture any compatible Wi Fi packet
Speaker 2: within your physical range, regardless of who it's for, even
Speaker 2: if you're not connected to any network at all, like.
Speaker 1: A radio scanner for Wi Fi signals.
Speaker 2: That's a great analogy. Yeah, And a powerful tool for
Speaker 2: this is aero dumping. It's part of the popular air
Speaker 2: cracking suite. You're run aero dumping and it starts capturing
Speaker 2: all the packets at seas, showing you all the Wi
Speaker 2: Fi networks around you, their names, esds, their hardware addresses, bssids,
Speaker 2: the channel thereon, the type of encryption they're using, lots
Speaker 2: of useful info.
Speaker 1: And what do you do with all those captured packets.
Speaker 2: Well, aero dumping captures them, often saving them to a file.
Speaker 2: Then you can use another tool like the incredibly powerful
Speaker 2: wire shark to open that file and analyze the packets
Speaker 2: in detail.
Speaker 1: Wire Shark that sounds familiar.
Speaker 2: It's a standard tool for a network analysis used by
Speaker 2: network admins. And security pros alike. It gives you a
Speaker 2: graphical view of every single packet, lets you filter, search,
Speaker 2: and dissect the traffic, even if the data payload is encrypted.
Speaker 2: Just seeing the patterns of communication can sometimes be revealing.
Speaker 1: So we can listen. Can we also actively disrupt things?
Speaker 1: I read about diuthentication attacks? What are those?
Speaker 2: Yes? Absolutely? De Authentication attacks are interesting. They allow you
Speaker 2: to selectively disconnect specific devices, or even all devices from
Speaker 2: a Wi Fi network. You do this by sending specially
Speaker 2: crafted authentication packets that look like they came from the
Speaker 2: access point. The router telling the target device you're no
Speaker 2: longer authorized, please.
Speaker 1: Disconnect, and the device just disconnects.
Speaker 2: Usually yes, it obeys the command. Now, this isn't about
Speaker 2: gaining access to the network's data yourself. It's purely about disruption.
Speaker 2: Or sometimes it's used tactically, as we'll see later.
Speaker 1: Okay, disruption. What about tricking people fake networks?
Speaker 2: Ah? Yes? Building on that, we learn about setting up
Speaker 2: fake access points, often called evil to wins. This involves
Speaker 2: creating a rogue Wi Fi network, maybe with the same
Speaker 2: name as a legitimate nearby network like airport free Wi
Speaker 2: Fi or coffee shop Guests.
Speaker 1: To lure people into connecting to your network instead of
Speaker 1: the real one.
Speaker 2: Precisely, you trick users into connecting, and when they do,
Speaker 2: all their Internet traffic flows directly through your Collie machine.
Speaker 2: You effectively become their router. Tools like the Manna toolkit
Speaker 2: used to be popular for automating this, making it easier
Speaker 2: to set up sophisticated fake aps.
Speaker 1: And once you're their router.
Speaker 2: Once you're the man in the metal, you can capture
Speaker 2: and analyze all their unencrypted traffic. Using wire Shark, you
Speaker 2: can see websites they visit, maybe capture credentials entered on
Speaker 2: insecure sites. It gives you a lot of visibility into
Speaker 2: their activity.
Speaker 1: That sounds incredibly powerful and quite scary from a user perspective.
Speaker 2: It is. It highlights the danger of connecting to unknown
Speaker 2: or unsecured Wi Fi networks.
Speaker 1: Okay, so disruption observation. Let's talk about actually gaining access
Speaker 1: to encrypted networks. Most networks today use WPA two, maybe
Speaker 1: WPA three. Now, how do you get the password right?
Speaker 2: Getting the key is the main goal for accessing recruited networks.
Speaker 2: The strategy depends on the encryption type. For the really
Speaker 2: old WBP encryption well, it's fundamental broken. There are attacks
Speaker 2: that can recover the wpke relatively quickly, sometimes even if
Speaker 2: no one is actively using the network. It's just not
Speaker 2: secure at all anymore.
Speaker 1: So avoid WEP at all costs.
Speaker 2: Absolutely. WPA and especially WPA TOWPA three are much stronger.
Speaker 2: The evolution from wp wasn't just about better encryption algorithms.
Speaker 2: It was about fixing fundamental flaws in the connection process.
Speaker 2: But even WPA two isn't impenetrable yet. These techniques expose
Speaker 2: is that even robust encryption can sometimes be bypassed by
Speaker 2: exploiting the connection process itself, not necessarily the encryption algorithm directly.
Speaker 2: How So, for WPPA two, the main attack focuses on
Speaker 2: capturing the handshake. This is a crucial four way exchange
Speaker 2: of cryptographic messages that happens only when a device connects
Speaker 2: or reconnects to the network.
Speaker 1: The handshake contains information related to the passwords exactly.
Speaker 2: It doesn't contain the password directly, but it contains information
Speaker 2: derived from the password that can be used to verify
Speaker 2: if a guest password is correct. So the goal is
Speaker 2: to capture that handshake. You just wait for someone to
Speaker 2: connect naturally or you can use those do authentication attacks.
Speaker 1: We talked about, AH force someone to disconnect.
Speaker 2: So they automatically try to reconnect moments later, allowing you
Speaker 2: to reliably capture that handshake as they do. It's a
Speaker 2: tactical use of the death attack.
Speaker 1: Okay, clever, So you've captured the handshake file. Now what
Speaker 1: how do you get the actual password?
Speaker 2: Now comes the cracking part. The handshake itself doesn't give
Speaker 2: you the password. You need to perform an offline brute
Speaker 2: force or dictionary attack against the captured handshake data. This
Speaker 2: is where tools that generate password possibilities come in, like
Speaker 2: crunch Crunch.
Speaker 1: What does it do?
Speaker 2: Crunch is a flexible tool for creating custom word lists.
Speaker 2: You don't just have to use pre made dictionaries of
Speaker 2: common passwords. You can tell Crunch, for instance, generate all
Speaker 2: possible passwords between eight and ten characters long using only
Speaker 2: lowercase letters and the numbers one, two, three, or define
Speaker 2: more complex patterns.
Speaker 1: So you create massive lists of potential.
Speaker 2: Password potentially massive yes. Then you take the captured handshake
Speaker 2: file and you feed it, along with your generated word
Speaker 2: list or a banner dictionary file into a cracking tool
Speaker 2: like air cracking. Air cracking down then tries each password
Speaker 2: from the list against the handshake data. If it finds
Speaker 2: a password that successfully validates the handshake, you found.
Speaker 1: The network key, which really just highlights the importance of
Speaker 1: having a strong, complex Wi Fi password absolutely.
Speaker 2: The difficulty of cracking depends entirely on the strength and
Speaker 2: length of the password. A shirt simple password might be
Speaker 2: cracked in minutes or hours, A long, complex, random one
Speaker 2: could take years, decades, or even centuries with current technology.
Speaker 1: Okay, so that covers gaining access. Now let's talk about
Speaker 1: what happens after you're connected to a network. Man in
Speaker 1: the middle attacks. You mentioned them with fake aps, but
Speaker 1: they apply once you're on a legitimate network too, right.
Speaker 2: Yes, Man in the middle or mitm IT attacks are
Speaker 2: incredibly powerful. Once you're on the same local network as
Speaker 2: your target, maybe you crack the Wi Fi or you
Speaker 2: plugged into the same wired network, you can potentially redirect
Speaker 2: their traffic through your machine.
Speaker 1: So you sit between the target user and the router.
Speaker 2: Essentially, yes, you become the invisible intermediary. This allows you
Speaker 2: to read, modify, or even drop their network packets, and crucially,
Speaker 2: it often allows you to capture sensitive information like usernames
Speaker 2: and passwords entered on websites.
Speaker 1: How does that redirection actually work? Technically? How do you
Speaker 1: trick their computer into sending traffic to you instead of
Speaker 1: the real router.
Speaker 2: What's fascinating and maybe a bit alarming, is how this
Speaker 2: often works due to the inherent simplicity and trust built
Speaker 2: into a fundamental network protocol called ARP, the Address Resolution
Speaker 2: Protocol ARP.
Speaker 1: What's its job?
Speaker 2: Think of ARP as the network's local address book. On
Speaker 2: local network devices use IP addresses ninety two point one
Speaker 2: sixty eight point one one zero zero to talk to
Speaker 2: each other, but the actual data transfer at the lowest
Speaker 2: level uses those physical MQ addresses we discussed. AARP's job
Speaker 2: is simply to ask, hey, who has IP address one
Speaker 2: ninety two point one sixty eight point one one zero zero,
Speaker 2: Tell me your AMC address, and the device with that
Speaker 2: IP responds with its MK. It's designed for efficiency.
Speaker 1: But that simplicity makes it vulnerable.
Speaker 2: Exactly, It's largely based on trust. There's no built in verification,
Speaker 2: so using a technique called ARP spoofing or AIRP poisoning,
Speaker 2: your attacking machine can send out unsolicited ARP replies. You
Speaker 2: basically tell the target computer, hey, the router's IP address
Speaker 2: like one hint two point one six eight point one
Speaker 2: point one, that's my MSA address now, and simultaneously you
Speaker 2: tell the router, hey, the target's IP address one ninety
Speaker 2: two point one six eight point one one zero zero,
Speaker 2: that's my MAAC address.
Speaker 1: So you trick both of them into sending traffic meant
Speaker 1: for each other to you instead.
Speaker 2: Precisely you insert yourself into the conversation. Tools like the
Speaker 2: MTMF the Man in the Middle framework automate this whole
Speaker 2: process beautifully. MITMS performs the AARP poisoning to redirect trap,
Speaker 2: and automatically starts various sniffing and attack plugins for you.
Speaker 2: The book provides a compelling example using MITMF to capture
Speaker 2: usernames and passwords submitted to plane HTTP websites like a
Speaker 2: test site called hack dot me. Just by being the
Speaker 2: MITM the credentials pop right up on your screen as
Speaker 2: the victim logs.
Speaker 1: In plan HTTP. That's the key there, right. What about
Speaker 1: secure sites HTTPS?
Speaker 2: Ah? Yes, that's the big hurdle HTTPS. When you try
Speaker 2: an MITM attack on a site using HTTPS, the encryption
Speaker 2: kicks in the browser. Expect the valid digital certificate from
Speaker 2: the website signed by a trusted authority. Your MITM tool
Speaker 2: can't provide that genuine certificate.
Speaker 1: So the browser throws up a warning.
Speaker 2: Exactly, the user gets a big, scary warning message saying
Speaker 2: that connection is in private, the certificate is invalid. Most
Speaker 2: users hopefully would back away.
Speaker 1: At that point, so HTTTS works. But is there a
Speaker 1: way around that warning?
Speaker 2: Well, this is where a clever tool called SSL strip
Speaker 2: comes in and understanding this is a truly illuminating insight
Speaker 2: into how some attacks work. SSL strip works during the
Speaker 2: initial connection attempt. If a user types, say example, dot
Speaker 2: Com into their browser, the browser might first try to
Speaker 2: connect via HTTP before being redirected to the HTTPS. SSL strip,
Speaker 2: running on the MITM machine, intercepts that initial HTDP request.
Speaker 2: It then connects to the real server over eahttps itself,
Speaker 2: but it presents the website back to the victim over PLANEAHTTP.
Speaker 1: It strips away the SSLTLS layer.
Speaker 2: Effectively yes for the connection between the victim and the attacker.
Speaker 2: The victims browser thinks it's talcking HGTP, so it doesn't
Speaker 2: expect a certificate and therefore no warning appears, but the
Speaker 2: attacker is still getting the data securely from the real
Speaker 2: server and decrypting it or passing it along.
Speaker 1: Wow, so it downgrades the connection silently.
Speaker 2: Yes, it makes sniffing the traffic trivial again, even if
Speaker 2: the original site uses HTTPS. Interestingly, MITMF often starts sslstrip
Speaker 2: or its successor SSL strip plus for you automatically when
Speaker 2: you run it.
Speaker 1: That sounds like a huge security hole. Is there a
Speaker 1: defense against SSL strip?
Speaker 2: Yes, thankfully, there's a crucial limitation that highlights the ongoing
Speaker 2: security evolution HSTS, which stends for HTTP strict transport security.
Speaker 2: Websites like Google, Facebook, Banks, etc. Use HSTS. They send
Speaker 2: a special header to your browser the first time you
Speaker 2: connect securely. This header tells you browser, for the next
Speaker 2: x months only ever connect to me using HTTPS, never
Speaker 2: even try HTTP.
Speaker 1: So the browser doesn't even make that initial insecure request
Speaker 1: that SSL strip relies on exactly.
Speaker 2: The browser has HSTS rules pre loaded for major sites,
Speaker 2: and it remembers the HSTS policy for others after the
Speaker 2: first visit. This means that on modern browsers, visiting sites
Speaker 2: that use HSTS properly, SSL strip is largely ineffective. It's
Speaker 2: a great example of security measures evolving to counter new attacks.
Speaker 1: Okay, that's reassuring, But what if the target isn't typing
Speaker 1: a password. Say they logged into a site yesterday and
Speaker 1: click remember Me. They're authenticated by cookies then, right, not passwords.
Speaker 2: That's a very important point. Yes, users are often authenticated
Speaker 2: for ongoing sessions using cookies, not by re entering their
Speaker 2: password every time they click a link, and these cookies
Speaker 2: can also be captured during an MITM attack, even over
Speaker 2: eahttps if SSL strip is working or if the cookie
Speaker 2: wasn't properly secured by the website.
Speaker 1: So you grab their session cookie exactly.
Speaker 2: The technique is to sniff out those session cookies using
Speaker 2: your MITM tools. Then you can take that cookie value
Speaker 2: and inject it into your own browser's cookie storage for
Speaker 2: that website. If you then visit the website, the server
Speaker 2: sees the valid session cookie and thinks you are the
Speaker 2: already authenticated.
Speaker 1: User, so you can bypass the login process entirely and
Speaker 1: just hijack their existing session.
Speaker 2: Precisely, you log into their account without ever needing their password.
Speaker 2: It's a powerful demonstration of how seemingly innocuous pieces of
Speaker 2: data like cookies can hold the keys to a user's
Speaker 2: online identity. If not handled securely.
Speaker 1: Okay, this MITM stuff is powerful. You mentioned wire Shark
Speaker 1: earlier for analyzing captured packets. How does it fit into
Speaker 1: this MITM scenario? Is it just for Wi Fi sniffing?
Speaker 2: Oh? No, wire shark is essential throughout well. Tools like
Speaker 2: MITMF might show you the important stuff like castured passwords automatically.
Speaker 2: Wireshort gives you the full raw picture of everything going
Speaker 2: through your network interface during the MITM attack. Everything everything,
Speaker 2: every DNS request, every HTTP request and response, every weird
Speaker 2: protocol you didn't know was running. You select your network
Speaker 2: interface in wire shark, the one MITMF is using to
Speaker 2: pass traffic, and it logs all the traffic flowing through it.
Speaker 2: Then you can use its powerful graphical interface and filtering
Speaker 2: capabilities to dissect that traffic. You can filter specifically for
Speaker 2: HTTP traffic, or look for packets containing HTTP dot cookie,
Speaker 2: or filter for PUST requests which often carry log inform
Speaker 2: data so.
Speaker 1: You can find credentials or cookies that maybe in my
Speaker 1: TMF didn't automatically flag exactly.
Speaker 2: Or you can analyze other protocols, troubleshoot why something isn't working,
Speaker 2: or just get a much deeper understanding of what's happening
Speaker 2: under the hood. It captures everything flowing through that interface,
Speaker 2: giving you a comprehensive view, not just the highlights. It's
Speaker 2: an indispensable tool for both offense and defense.
Speaker 1: Right it seems like understanding these tools is crucial for
Speaker 1: anyone serious about security. Okay, let's shift gears a bit.
Speaker 1: We've been talking a lot about network level attacks. Let's
Speaker 1: move towards gaining direct access to the computer devices themselves.
Speaker 1: The book details two main approaches here, server side attacks
Speaker 1: versus client side attacks. What's the fundamental difference between those?
Speaker 2: Good transition The core difference lies in whether user interaction
Speaker 2: is required. Server side attacks target vulnerabilities and software running
Speaker 2: on the remote server, the operating system itself or services
Speaker 2: like web server, database server, FTP server, etc. The key
Speaker 2: here is no user interaction is needed on the target's part.
Speaker 1: You just attack the service directly exactly.
Speaker 2: You find a flaw, maybe a known vulnerability and an
Speaker 2: outdated piece of software, a default password that was never changed,
Speaker 2: a misconfiguration, or complex flaws like SQL injection or buffer
Speaker 2: overflows will discuss later, and you exploit it directly over
Speaker 2: the network, for example, using a framework like metasploit. You
Speaker 2: might explore a known backdoor in an old version of
Speaker 2: an FTP server like vsftpd to gain full control.
Speaker 1: Okay, so that's server side. What about client side?
Speaker 2: Client side attacks, on the other hand, do require some
Speaker 2: form of user interaction. The vulnerability isn't necessarily on a
Speaker 2: server waiting to be attacked. It's often exploited when the
Speaker 2: user performs an action like clicking a link exactly like
Speaker 2: clicking a malicious link, opening an infected email attachment, installing
Speaker 2: a fake software update, maybe even just visiting a compromise
Speaker 2: website that exploits a browser vulnerability. Because of this human element,
Speaker 2: information gathering about the person, their habits, their interests, the
Speaker 2: software they use becomes incredibly important for crafting a successful
Speaker 2: client side attack. This is where social engineering really comes
Speaker 2: into play.
Speaker 1: Okay, service side targets the machine software. Client side often
Speaker 1: targets the user's actions. You mentioned metasploit again, it sounds
Speaker 1: like a key tool. Can you elaborate on it.
Speaker 2: Metasplate is huge. It's arguably the most widely used framework
Speaker 2: for penetration testing and exploit development. Think of it as
Speaker 2: a massive toolkit and database for finding, crafting, and launching exploits.
Speaker 1: How is it structured.
Speaker 2: It's organized into various components or modules. You have exploits,
Speaker 2: which are the actual pieces of code that take advantage
Speaker 2: of a specific vulnerability in a system or application. There
Speaker 2: are thousands of exploits in metasploit for all sorts of software. Then,
Speaker 2: once an exploit successfully breaches a system, it typically delivers
Speaker 2: a payload.
Speaker 1: Payloads What are they?
Speaker 2: Payloads are the small pieces of malicious code that actually
Speaker 2: execute on the target after the vulnerability has been exploited.
Speaker 2: They define what you want to do once you get in.
Speaker 2: Do you want a simple command show? Do you want
Speaker 2: a more advanced remote control agent? That's what the payload determines.
Speaker 1: Are there different tins of payloads?
Speaker 2: Yes. Broadly speaking, there are two main types, based on
Speaker 2: how the connection is established. Bind payloads. These open a
Speaker 2: specific network port on the target machine, listening for an
Speaker 2: incoming connection. The attack then connects to the compromise target.
Speaker 1: Okay, the target listens, the attacker connects.
Speaker 2: Right, but that often gets blocked by firewalls protecting the
Speaker 2: target machine because figure walls are usually configured to block
Speaker 2: unexpected incoming connections. So the other type is often more
Speaker 2: effective reverse.
Speaker 1: Payloads reverse, so the target connects back to the attacker exactly.
Speaker 2: The payload on the target machine initiates an outgoing connection
Speaker 2: back to a listening port on the attacker's machine.
Speaker 1: Why is that more powerful.
Speaker 2: Because firewalls are typically much more permissive at allowing outgoing
Speaker 2: connections from the machines they protect. People need to browse
Speaker 2: the web, check email, et cetera. So an outgoing connection
Speaker 2: from the target back to the attacker often bypasses firewall rules.
Speaker 1: Clever sneaking out instead of breaking in precisely.
Speaker 2: For example, using a payload like Windows mitrepre reverse TTP,
Speaker 2: or reverse TTPs is very common. These make the backdoor
Speaker 2: connection look like standard web traffic using ports eighty or
Speaker 2: four to forty three, making it even harder to detect
Speaker 2: amongst legitimate web browsing.
Speaker 1: Interpreter is that a specific type of payload.
Speaker 2: Yes, Interpreter is an advanced payload within metasploit. Instead of
Speaker 2: just giving you a basic command shell, it provides a
Speaker 2: powerful extensible command and control agent with lots of built
Speaker 2: in capabilities for post exploitation, which we'll get to later.
Speaker 1: Okay, metasploit sounds critical Before you can exploit though you
Speaker 1: need to find vulnerabalities, how do ethical hackers scan for weaknesses?
Speaker 2: Right? Reconnaissance and scanning are crucial first steps. You need
Speaker 2: to know what doors are open before you try to
Speaker 2: pick the locks. There are various tools. One approach integrated
Speaker 2: with metaploit itself is using MSFC, the Metaploit Community Interface
Speaker 2: or similar commercial versions. This provides a web based UI
Speaker 2: for metaploit. You can point it at a target IP
Speaker 2: address or range and it will perform scans to discover
Speaker 2: open ports, identify the services running on those ports like
Speaker 2: web server, FTP, SSH, and often even identify the specific
Speaker 2: software versions.
Speaker 1: And it links those findings to exploits.
Speaker 2: Yes, that's the really useful part. It often maps the
Speaker 2: discovered services and versions directly to known exploits available within
Speaker 2: the metasploid framework. In some cases, for well known vulnerabilities
Speaker 2: on unpatched systems like our Metasploitable Victim machine, it might
Speaker 2: even allow for one click exploitation directly from the web interface.
Speaker 1: Makes it sound easy.
Speaker 2: For known simple vulnerabilities, it can be, but real world
Speaker 2: systems are often more complex and patched. That's where more
Speaker 2: advanced scanners come in. Like Nextpose from rapid seven, who
Speaker 2: also manage metasploit or nessis from tenable.
Speaker 1: How is next pose different?
Speaker 2: Nextpose is a more comprehensive vulnerability management framework. It goes
Speaker 2: beyond just finding open ports and services. It performs deeper scans,
Speaker 2: identifies vulnerabilities with associated risk scores, and crucially, it often
Speaker 2: attempts to enumerate all installed software on the target system,
Speaker 2: not just network services.
Speaker 1: Why is knowing all installed software.
Speaker 2: Important because sometimes the initial exploit only gives you limited access.
Speaker 2: Knowing about other software installed on the machine might reveal
Speaker 2: opportunities for local privilege escalation, using a flaw in a
Speaker 2: locally installed program to gain higher administrative rights after you've
Speaker 2: already got a foothold. Nexpose also generates much more detailed
Speaker 2: and professional reports, which are essential for documenting findings in
Speaker 2: a professional penetration test.
Speaker 1: Okay, so scanning finds potential entry points. But what if
Speaker 1: the target is well protected no obvious server side flaws.
Speaker 1: That's when client side attacks and social engineering come back in.
Speaker 2: Exactly when direct server side attacks fail, or maybe the
Speaker 2: target isn't even directly reachable on the network behind multiple
Speaker 2: layers of firewalls, client side attacks become the primary vector,
Speaker 2: and these almost always involve some element of social engineering
Speaker 2: manipulating the human user.
Speaker 1: How do you make malware that works for this? Doesn't
Speaker 1: antivirus catch most things?
Speaker 2: Antivirus is a challenge, definitely. That's where tools like Veil Evasion,
Speaker 2: now part of the larger Veil framework, become relevant. Veil
Speaker 2: was specifically designed to generate payloads metasploit payloads in ways
Speaker 2: that attempt to evade detection by common antivirus solutions. It
Speaker 2: uses various techniques like encryption, code obfuscation, and different programming
Speaker 2: language wrappers.
Speaker 1: So you use VEIL to create an undetectable backdoor.
Speaker 2: That's the goal. Yes, you use VEIL to generate a
Speaker 2: malicious executable file, maybe backdoor, dot exe or something more
Speaker 2: convincingly named. This file contains your chosen payload, like a
Speaker 2: reverse interpreter shell. Then you need to get the user
Speaker 2: to run that file. While Veil tries to handle the
Speaker 2: antivirus evation, you still need the social engineering part, and
Speaker 2: on your end you set up metasploits multi handler exploit
Speaker 2: multi handler to listen for the incoming connection from that
Speaker 2: back door. Once the victim runs.
Speaker 1: It, right, the social engineering part how deep does that go?
Speaker 2: It can go very deep. At its heart, social engineering
Speaker 2: is the art or maybe science, of manipulating people to
Speaker 2: perform actions they shouldn't or divulge confidential information. This is
Speaker 2: where detailed information gathering about the person or the organization
Speaker 2: it really shines. You need to understand your target to
Speaker 2: craft a believable pretext.
Speaker 1: What tools help with gathering info on people?
Speaker 2: Maltago is a classic and incredibly powerful tool for open
Speaker 2: source intelligence gathering oh SINT. You start with a piece
Speaker 2: of information, maybe a Poston's name and email address, a
Speaker 2: company name, a website, and Maultago automatically queries numerous public
Speaker 2: data sources, search engines, social media, DNS records, whose databases, etc.
Speaker 2: To find related information. It then visually maps out the
Speaker 2: connections between people, websites, companies, email addresses, phone numbers, social
Speaker 2: media profiles like Twitter, LinkedIn Facebook documents they've shared. It
Speaker 2: can build a very detailed picture from publicly available data.
Speaker 1: So you use Multago to find out about your target,
Speaker 1: then what then you use.
Speaker 2: That information to build a plausible attack strategy or pretext.
Speaker 2: For example, if Maltago shows your target works at company
Speaker 2: X and frequently uses say WordPress. You might craft an
Speaker 2: attack pretending to be from WordPress support, offering them a
Speaker 2: link to download a new beta security plug in, which
Speaker 2: is actually your veil generated.
Speaker 1: Back door ah, making it relevant and seem legitimate exactly.
Speaker 2: The more tailored and believable the pretext, the higher the
Speaker 2: chance of success. Other practical techniques include things like changing
Speaker 2: the icon of your back door executable to make it
Speaker 2: look like a harmless file like a PDF or an image.
Speaker 2: Tools like auto it can help compile scripts that drop
Speaker 2: and run the real back door while maybe displaying a
Speaker 2: decoy document so.
Speaker 1: It looks like they opened a picture, but malware runs
Speaker 1: in the background precisely.
Speaker 2: There's even a trick. Using a special Unicode character called
Speaker 2: the right to left override RL character, you can name
Speaker 2: a file something like report augustrlo cod dot ex in
Speaker 2: Windows Explore. The ROL character reverses the order of the
Speaker 2: characters that follow it, so the file name might appear
Speaker 2: as report agustext dot dios hiding thereal dot ex extension
Speaker 2: can fool less cautious users.
Speaker 1: Wow, that's sneaky, it is.
Speaker 2: And another potent technique is email spoofing, sending an email
Speaker 2: that appears to come from someone the target nos and
Speaker 2: trust their boss, a colleague, a friend. If the email
Speaker 2: looks legitimate and comes from a trusted source, the target
Speaker 2: is far more likely to click a link or open
Speaker 2: an attachment containing your back door.
Speaker 1: It really underscores how much trust we place in digital
Speaker 1: communications and how that trust can be exploited.
Speaker 2: Absolutely, the human element is often the weakest link in
Speaker 2: the security chain.
Speaker 1: Okay, let's explore another angle of client side attacks. What
Speaker 1: if the target doesn't download or run anything, but simply
Speaker 1: browses a webpage you control or have compromised. Can you
Speaker 1: attack them through their browser?
Speaker 2: Yes? Definitely. This is where the BEEF tool comes in.
Speaker 2: BEEF stands for the Browser Exploitation Framework Browser exploitation.
Speaker 1: How does that work?
Speaker 2: BEEF allows you to hook a target's web browser and
Speaker 2: then run various commands and attacks directly within their browser context,
Speaker 2: often without them noticing immediately.
Speaker 1: How do you hook their browser?
Speaker 2: A target browser becomes hooked when it executes a small
Speaker 2: piece of JavaScript code provided by BEEF. You can achieve
Speaker 2: this in several ways. You could embed this JavaScript hook
Speaker 2: into a web page you control, maybe even a blank page.
Speaker 2: Then you use social engineering. Heycheck out this cool site
Speaker 2: or perhaps DNS spoofing during an MITM attack to redirect
Speaker 2: the victim to your page containing the hook. Or if
Speaker 2: you find a cross site scripting EXSS vulnerability on a
Speaker 2: legitimate website. We'll talk more about XSS later, you could
Speaker 2: inject the beef hook script there, hooking anyone who visits
Speaker 2: the compromise legitimate page.
Speaker 1: Okay, so their browser runs your JavaScript hook. What can
Speaker 1: you do then? Via beef?
Speaker 2: Once a browser is hooked, Beef offers a surprisingly vast
Speaker 2: array of commands and modules, all controlled from your attack
Speaker 2: or interface. You can gather information what browser and version
Speaker 2: are they using, what plugins are installed like Flash, Java
Speaker 2: often vulnerable. What's the internal IP address of their computer?
Speaker 2: What other websites do they have open in other tabs?
Speaker 2: Can you grab cookies for the current site.
Speaker 1: Just from them visiting a page if it's.
Speaker 2: Hooked, Yes, and then you can launch browser based attacks.
Speaker 2: You can display fake notification pop ups you do install
Speaker 2: this update, you can execute arbitrary JavaScript in their browser.
Speaker 2: You can attempt to redirect their browser to other malicious
Speaker 2: sites or fake login pages. There's a particularly nasty module
Speaker 2: called pretty theft. It can display very convincing fake login
Speaker 2: pop ups that float over the current page asking for
Speaker 2: credentials for sites like Facebook, LinkedIn, Gmail, generic webmail, hoping
Speaker 2: the user will type their password into your fake box.
Speaker 1: Wow, that's purely social engineering within.
Speaker 2: The browser exactly. But BEEF can go even further. It
Speaker 2: can act as a stepping stone to gain full system access.
Speaker 2: There are modules designed to, for example, display a fake
Speaker 2: notification bar at the top of the browser window, maybe
Speaker 2: mimicking a flash update or a browser plugin update. If
Speaker 2: the user clicks install update.
Speaker 1: It downloads and runs your back door.
Speaker 2: Precisely, BEEF can serve up your veil generated executable, tricking
Speaker 2: the user into installing it, and if they do, boom,
Speaker 2: you get a full mature procession back give you complete
Speaker 2: control over their computer, not just their browser.
Speaker 1: It's truly by opening how a simple web browser, something
Speaker 1: we use constantly can become such a powerful attack factor.
Speaker 2: It really is browser security. Keeping it updated and being
Speaker 2: cautious about what you click are incredibly important.
Speaker 1: Okay, this is all fascinating, but so far everything we've discussed,
Speaker 1: the lab set up, the network attacks, the client side
Speaker 1: stuff seems to assume everything is happening within your own
Speaker 1: local network inside that virtual box. Environment. How do you
Speaker 1: take these attacks out into the real world. How do
Speaker 1: you attack a target that's somewhere else entirely on the
Speaker 1: Internet outside your local network.
Speaker 2: That's a critical question for simulating realistic scenarios. You're right.
Speaker 2: Your virtual machines usually have local IP addresses like one
Speaker 2: ninety two point one, six eight dot x or ten
Speaker 2: dot xixodx that are directly reachable from the public Internet.
Speaker 2: The key technology here is port forwarding on your Internet router,
Speaker 2: the box your ISP gives you that connects your home
Speaker 2: network to the wider Internet.
Speaker 1: Port forwarding. How does that work?
Speaker 2: First, you need to know your network's public IP address.
Speaker 2: This is the address the rest of the Internet sees
Speaker 2: for your entire home network. You can usually find it
Speaker 2: easily by just searching what is my IP on Google
Speaker 2: from a computer on your network. Then you log into
Speaker 2: your router's administration interface. Somewhere in the settings there will
Speaker 2: be a section for port forwarding, or sometimes called virtual
Speaker 2: servers or application forwarding. Here you create rules. You tell
Speaker 2: a router, hey, if any traffic comes in from the
Speaker 2: Internet directed at my public IP address on a specific
Speaker 2: port number, say port eighty eighty, please forward that traffic
Speaker 2: inward to the local IP address of my Collie Linux
Speaker 2: virtual machine on that same port or a different one.
Speaker 1: So the router acts like a receptionist, directing incoming calls
Speaker 1: to the right internal extension.
Speaker 2: Perfect analogy. Yes, you're mapping an external port on your
Speaker 2: public IP to an internal port on your specific Callie
Speaker 2: machines local IP. You'd set up different rules for different
Speaker 2: services you want to expose. Maybe port eighty eighty for
Speaker 2: your backdoor listener port eighty if you're hosting a malicious
Speaker 2: website on Collie, Port three thousand for the beef UI
Speaker 2: if you want to hook external browsers.
Speaker 1: Okay, So forwarding makes your internal Collie services reachable via
Speaker 1: your public IP. How does that apply to backdoors?
Speaker 2: Right, let's talk about external backdoors. When you create your
Speaker 2: back door using a tool like veil evasion, you need
Speaker 2: to configure the payload. Specifically, you set the l host option.
Speaker 2: LOS tells the back door where to connect back to.
Speaker 2: For internal attacks within your lab, you set LOS to
Speaker 2: your Collie machine's local IP, but for an external attack,
Speaker 2: you set l host to your network's public IP address.
Speaker 1: Ah, so the backdoor tries to connect to your public
Speaker 1: IP from outside.
Speaker 2: Exactly the back door running on a victim machine somewhere
Speaker 2: else on the Internet attempts to initiate that reverse connection
Speaker 2: back to your public IP address on the port you
Speaker 2: specified Tree eighty eighty. Your router sees this incoming traffic
Speaker 2: on Court eighty eighty, your port forwarding rule kicks in
Speaker 2: the router force that connection inward to your Collie machine's
Speaker 2: local IP address, where your metasploit multi handler is listening,
Speaker 2: and you.
Speaker 1: Get the shell connecting the dots from external target through
Speaker 1: the Internet, through your router to your COLLIVM.
Speaker 2: Precisely, as an alternative to setting up individual port forwarding rules,
Speaker 2: some routers support putting a specific internal IP address into
Speaker 2: the DMZ or demilitarized zone. Putting your Collie machine's IP
Speaker 2: in the DMZ essentially forwards all incoming ports from the
Speaker 2: public IP directly to that internal machine. It's simply to
Speaker 2: set up, but less secure as exposes all of Collie's ports.
Speaker 2: Port Forwarding specific ports is generally safer.
Speaker 1: Okay, that makes sense, and seeing it work must be
Speaker 1: quite the moment.
Speaker 2: It really is, the truly insightful moment. The real aha
Speaker 2: comes when you demonstrate this end to end. Imagine you
Speaker 2: set up port forwarding from port eighty to your Collie machine,
Speaker 2: which is running a web server hosting your backdoor dot ex.
Speaker 2: Then you go to a completely separate computer on a
Speaker 2: totally different network, maybe using your phone's hotspot or at
Speaker 2: friend's house, open a browser typing your home network's public
Speaker 2: IP address, and download backdoor dot ex from your Collie
Speaker 2: web server. You run the back door on that external
Speaker 2: Windows machine and back on you your calling machine. You
Speaker 2: see the interpreter session open up, showing the connection coming
Speaker 2: from that truly external public IP address. That's when you
Speaker 2: really grasp how these attacks bridge the gap from the
Speaker 2: local lab to the global internet.
Speaker 1: That definitely paints a clear picture. Okay, so let's assume
Speaker 1: you've succeeded. You've used an exploit, maybe delivered a payload
Speaker 1: bypass the fire wall with a reverse connection. You've gained
Speaker 1: initial access to a system. What's next? What happens in
Speaker 1: the post exploitation phase.
Speaker 2: Right Getting access is often just the beginning. Post exploitation
Speaker 2: is all about what you do after you compromise a system.
Speaker 2: The main goals are usually to understand the system better,
Speaker 2: escalate your privileges if needed. Maintain your access persistently and
Speaker 2: potentially use this machine to attack others.
Speaker 1: Let's start with understanding the system you mentioned Interpreter earlier.
Speaker 2: Yes, if your payload was Interpreter, you get a very
Speaker 2: powerful interactive shell. It has lots of built in commands,
Speaker 2: specifically for post exploitation. You can run basic commands like
Speaker 2: sits info to get detailed information about the operating system, hardware,
Speaker 2: et cetera. PS lists all the running processes pwdn LS
Speaker 2: or durrors on Windows. Targets let you navigate the filesystem
Speaker 2: just like a local command prompt. You start exploring.
Speaker 1: What about making your access more stable?
Speaker 2: That's crucial process migration. Your initial access might have come
Speaker 2: through exploiting a vulnerability and say a user's web browser
Speaker 2: or a specific application. If the user closes that browser application,
Speaker 2: your interpreter session dies.
Speaker 1: With it, so you lose access exactly.
Speaker 2: Process migration involves injecting your materpreter agent from that initial
Speaker 2: unscable process into a different, more stable, long running process
Speaker 2: on the system. On Windows, migrating into something like Explorer
Speaker 2: dot exx, which handles the desktop or services dot ex
Speaker 2: is common. These processes almost never close while the system
Speaker 2: is running. This makes your access much more persistent for
Speaker 2: your current session.
Speaker 1: Okay, stable access, what else? Getting data definitely?
Speaker 2: Interpreter makes it easy to upload and download files between
Speaker 2: your Collie machine and the compromised target. You might want
Speaker 2: to download sensitive documents you find, or upload additional tools,
Speaker 2: maybe a.
Speaker 1: Keylogger, keyloggers to capture typing.
Speaker 2: Yes, Materpreter has modules to deploy keyloggers that capture every
Speaker 2: single keystroke the user types on their keyboard, passwords, emails,
Speaker 2: chat messages, documents, everything. It's incredibly invasive.
Speaker 1: And keeping access long term even after they reboot.
Speaker 2: Right. That's maintaining access or persistence. Just migrating processes keeps
Speaker 2: you alive for the current session, but if the computer reboots,
Speaker 2: you lose access again. Persistence techniques aim to ensure your
Speaker 2: backdoor runs automatically every time the system starts up. There
Speaker 2: are simpler methods. You could use valvation again to generate
Speaker 2: a backdoor designed to install itself as a system service.
Speaker 2: Materpreter itself also has persistent scripts or modules that try
Speaker 2: to set up basic startup entries in the registry or scheduled.
Speaker 1: Tasks, but those might get caught.
Speaker 2: They often do yes. These simpler methods can be detectable
Speaker 2: by anti virus or endpoint security software. The book hints
Speaker 2: a more advanced, robust methods for each ving persistence, often
Speaker 2: involving combining multiple techniques or using more sophisticated evasion tactics
Speaker 2: to ensure the back door remains active and hidden even
Speaker 2: after reboots without being easily detected. These often require a
Speaker 2: deeper understanding of the OS internals.
Speaker 1: Okay, persistence is key. What about attacking other computers from
Speaker 1: the one you just hacked?
Speaker 2: Ah, that's pivoting. This is a really important concept in
Speaker 2: penetration testing. Often the first machine you compromise might just
Speaker 2: be a regular user's workstation or a less critical server,
Speaker 2: but that machine might have access to other internal networks
Speaker 2: or servers that are not directly reachable by your calling
Speaker 2: machine from the outside.
Speaker 1: Like deeper inside their network exactly.
Speaker 2: Pivoting involves using the compromised computer as a stamping stone
Speaker 2: or a pivot to route your attack traffic through it
Speaker 2: to reach those other internal targets. For example, you might
Speaker 2: hack a Windows machine in their main office network, say
Speaker 2: one ninety two point one six eight point one point
Speaker 2: one zero. Then you discover, maybe through network scan from
Speaker 2: that Windows machine, that there's a separate internal server network,
Speaker 2: say ten point zero point zero point zero two four,
Speaker 2: that holds critical data, but your callie machine can't see
Speaker 2: it directly. You use the compromise Windows machine as a gateway.
Speaker 2: Metasploit has modules like run auto route that automatically add
Speaker 2: network routes through your materpreter session on the Windows box.
Speaker 2: The sales metasploit. Hey, if you want to talk to
Speaker 2: any machine on the ten point zero point one to network,
Speaker 2: send the traffic via the interpreter session running on one
Speaker 2: ninety two point one sixty eight point one point one
Speaker 2: towards zero.
Speaker 1: So you can then launch exploits from your callie machine
Speaker 1: against those internal servers, tunneling through the first victim.
Speaker 2: Precisely, it allows you to burrow deeper into a target network,
Speaker 2: moving laterally from system to system, starting from just one
Speaker 2: initial point of compromise. It's a fundamental technique for mapping
Speaker 2: out and compromising larger networks.
Speaker 1: Post exploitation seems just as complex, if not more so,
Speaker 1: than getting initial access.
Speaker 2: It often is. It requires a different set of skills.
Speaker 2: Understanding the target os, knowing how to move quietly and
Speaker 2: achieving specific without getting caught.
Speaker 1: Okay, we've covered networks devices, client side, server side. Let's
Speaker 1: transition now to website penetration testing, shifting focus from the
Speaker 1: underlying infrastructure to the web applications themselves. First off, what
Speaker 1: exactly is a website from an ethical hackers perspective? And
Speaker 1: how do you start gathering information specifically about a website target?
Speaker 2: Good question from our perspective. A website is essentially a
Speaker 2: web application, a collection of files and code installed on
Speaker 2: a web server, and that web server is just another
Speaker 2: computer running an OS with an IP address made accessible
Speaker 2: usually via a domain name like www dot example dot com.
Speaker 2: For example, that Metasploitable virtual machine we talked about. It
Speaker 2: runs a web server and it has website files like index,
Speaker 2: dot php, images, etc. In a specific directory. You can
Speaker 2: access its simple website just by typing Metasploitable's IP address
Speaker 2: into a browser on your Collie machine.
Speaker 1: Okay, so it's software on a server. How do you
Speaker 1: gather info on it? Is it like the osin tweeted
Speaker 1: for people?
Speaker 2: It's similar in principle, but focused on web technologies and infrastructure.
Speaker 2: Information gathering is just as critical for web targets. You
Speaker 2: start with things like a who's look up for the
Speaker 2: domain name. This can give you information about who registered
Speaker 2: the domain, the company name and address if they did
Speaker 2: use a privacy service, the domain name servers, which hinsit,
Speaker 2: their hosting provider, and sometimes technical contact email addresses.
Speaker 1: What else, what about the tech running the site?
Speaker 2: For that, tools and services like Netcraft are excellent. You
Speaker 2: can enter a website URL into Netcraft's site report tool
Speaker 2: and it will try to identify the technology as the
Speaker 2: website is using. Things like what web server software are
Speaker 2: they running? Apache injincs, Microsoft ISA, What server side programming
Speaker 2: languages are they using? Php? Java, dot Net, Python? Will
Speaker 2: client side JavaScript libraries jQuery React? Crucially, Netcraft can often
Speaker 2: identify specific web applications being used, like wordcres, Jumladruple, Magento.
Speaker 2: Knowing they're using say WordPress version xy immediately tell you
Speaker 2: to go research known vulnerabilities for that specific version ah.
Speaker 1: Finding known weaknesses in the software they use, mark exactly.
Speaker 2: Robtex is another useful service that provides a lot of
Speaker 2: related network information for a given domain or ip address,
Speaker 2: things like historical DNS records or related domains IPA, just neighbors.
Speaker 1: IP addressed neighbors. Why does that matter?
Speaker 2: This relates to the idea of websites on the same server.
Speaker 2: It's very common for web hosting companies to put multiple
Speaker 2: websites belonging to different customers, all in the same physical
Speaker 2: server sharing the same IP address. So if your target
Speaker 2: website seems really secure and you can't find any vulnerabilities
Speaker 2: on it directly, you can check what other websites are
Speaker 2: hosted on that same IP address. If you can find
Speaker 2: and exploit a vulnerability on one of those other, potentially
Speaker 2: less secure websites on the same server, gaining access to
Speaker 2: that site often means you gain access to the underlying
Speaker 2: server itself, and from there you can usually access the
Speaker 2: files and databases of your original target website.
Speaker 1: As well hack the neighbor to get into the target's house. Essentially,
Speaker 1: that's a.
Speaker 2: Good way to put it. It's a common technique. Another
Speaker 2: thing to look for is subdomains. Companies often have subdomains
Speaker 2: that aren't widely advertised, like dev dot example dot com,
Speaker 2: staging dot Example dot com, Beta dot example dot com,
Speaker 2: or maybe even admin dot example dot com. These subdomains
Speaker 2: might host experimental features, older versions of the application, or
Speaker 2: internal administrative interfaces that are often less secured or patched
Speaker 2: than the main public facing website. Finding improbing these hidden
Speaker 2: subdomains can be very fruitful.
Speaker 1: How do you find them if they're not advertised?
Speaker 2: There are tools that perform subdomain enumeration using various techniques
Speaker 2: like checking common names, admin, test, dev, etc. Querying DNS records,
Speaker 2: using search engines, creatively or even brute forcing potential subdomain names. Finally,
Speaker 2: information gathering also involves looking for sensitive files and directories
Speaker 2: directly on the web server that might have been left exposed.
Speaker 2: Maybe developers left behind configuration files canfig dot php, dot BAK,
Speaker 2: backup archives, website dot zip, debugging scripts, PHPNFO dot php
Speaker 2: which reveals tons about the PHP setup, or even files
Speaker 2: containing credentials passwords dot txt.
Speaker 1: People actually leave password files accessible.
Speaker 2: You'd be surprised how often misconfigurations happen. Tools like derb
Speaker 2: or go buster help automate the process of finding these
Speaker 2: hidden files and directories by rapidly trying thousands of common
Speaker 2: names based on dictionary lists.
Speaker 1: Okay, that's a lot of ground to cover just in
Speaker 1: information gathering for websites. Now let's get into the actual
Speaker 1: vulnerabilities what are some of the most common ways ethical
Speaker 1: hackers find and exploit weaknesses in web applications themselves.
Speaker 2: Right, let's dive into the nitty gritty of common webflaws.
Speaker 2: One conceptually straightforward vulnerability is related to file uploads. Many
Speaker 2: websites allow users to upload files, profile, pictures, documents, etc.
Speaker 2: If the website doesn't properly validate what kind of file
Speaker 2: is being uploaded, an attacker might be able to upload
Speaker 2: a malicious script file instead of say a GPEG.
Speaker 1: Image, like uploading code instead of data exactly.
Speaker 2: If the web servers configure to execute phpe scripts, for example,
Speaker 2: and you can upload a file ending in dot php
Speaker 2: containing malicious PHP code, often called a webshell, then simply
Speaker 2: browsing to the URL of that uploaded file could give
Speaker 2: you full command execution capabilities on the.
Speaker 1: Server, so you upload your own command prompt essentially.
Speaker 2: Yes, Tools like Weaveley are specifically designed to generate compact
Speaker 2: and often stealthy PHP webshells that give you a nice
Speaker 2: interactive terminal to control the server. This all comes down
Speaker 2: to the critical principle of input validation. The website must
Speaker 2: strictly check file types and not trust user supplied file names.
Speaker 1: Okay, insecure file uploads? What else?
Speaker 2: Next up are code execution vulnerabilities. These are flaws where
Speaker 2: user input is directly used or embedded into a command
Speaker 2: that gets executed by the server's operating system. Imagine a
Speaker 2: website feature that lets you ping another machine and you
Speaker 2: provide the IP address. If the website just takes your
Speaker 2: input and sticks it into a pin your input command
Speaker 2: without cleaning it.
Speaker 1: First, you could add other commands precisely.
Speaker 2: You could potentially inject os command separators like or and inmplinix,
Speaker 2: followed by your own commands like rm rf don't do that,
Speaker 2: or something more useful like ncee binch r cali.
Speaker 1: Port ncee What's that?
Speaker 2: That's a classic NETCIT command to create a reverse show.
Speaker 2: It tells the server to execute binch a command prompt
Speaker 2: and connect it to input and output back to a
Speaker 2: listing port on your CALLAI machine. Instant command line access,
Speaker 2: often bypassing firewalls. Again, the fix is rigorous input sanitization.
Speaker 1: Okay, file uploads, code execution? What about accessing files on
Speaker 1: the server?
Speaker 2: That brings us to file inclusion vulnerabilities. There are two
Speaker 2: main types, local and remote. Local file inclusion LiFi allows
Speaker 2: an attacker to trick the web application into including and
Speaker 2: displaying the contents of arbitrary files from the server's filesystem,
Speaker 2: files that were never intended to be accessed via the web.
Speaker 2: This often happens when a script uses user input to
Speaker 2: determine which file to include. GT pages PHP. If you
Speaker 2: can manipulate the page parameter in the URL, maybe using
Speaker 2: directory curricial sequences like LETT, you could potentially read files
Speaker 2: outside the normal web rout.
Speaker 1: Like system file exactly yeah.
Speaker 2: A classic LiFi demonstration is reading etcter password on a
Speaker 2: Linux server to get a list of system users, or
Speaker 2: reading application source code or configuration files that might contain
Speaker 2: database passwords or other secrets.
Speaker 1: And remote file inclusion.
Speaker 2: Remote file inclusion RFI is generally much more dangerous, though
Speaker 2: less common nowadays due to better default server configurations. RTIFI
Speaker 2: occurs when the application allows you to include a file
Speaker 2: not just from the local server, but from a completely
Speaker 2: different server over the network using a URL, so.
Speaker 1: You can make the target website include and execute a
Speaker 1: script file hosted on your calling machine precisely.
Speaker 2: If RFI is possible, you can usually just point it
Speaker 2: to a URL hosting your malicious PHP shell script and
Speaker 2: the target server will download and execute it, giving you
Speaker 2: immediate code execution. RFI typically requires specific insecure PHP settings
Speaker 2: to be enabled, like allowll include and alourel fopen, which
Speaker 2: thankfully are often disabled by default.
Speaker 1: Now LiFi reads local files, RFI executes remote code. What
Speaker 1: about databases? Websites use databases all the time.
Speaker 2: Ah. Yes, That leads us to one of the most
Speaker 2: widespread and impactful categories of web vulnerabilities. Sql injection scoot
Speaker 2: a lie cedicle. Vulnerabilities occur when user supplied input is
Speaker 2: incorporated into a database query in an unsafe way, allowing
Speaker 2: the attacker to manipulate the structure of the SQL query itself.
Speaker 1: So you inject SQL commands through a web form.
Speaker 2: Essentially yes, or through parameters in the URL. You discover
Speaker 2: potential SQL points, often by injecting special characters like a
Speaker 2: single quote or sequel fragments like AD one to on
Speaker 2: or AD one zero into input fields or URL parameters.
Speaker 2: If the application is vulnerable, these injections will often cause
Speaker 2: database errors to be displayed or change the content returned
Speaker 2: by the page in predictable ways, confirming that your input
Speaker 2: is affecting the SQL query.
Speaker 1: What can you do with SQL injection.
Speaker 2: Once you find it a lot, It ranges from simple
Speaker 2: checks to full database takeover. You can perform authorization bypass
Speaker 2: crafting an injection like ar one one was one into
Speaker 2: a username or password field might trick the log in
Speaker 2: query into always evaluating to true, letting you log in
Speaker 2: as an administrator or another user without knowing their actual password.
Speaker 1: Log in as admin just like.
Speaker 2: That in corely coded applications. Yes. Then you can start
Speaker 2: extracting data using SQL union operators. You can combine the
Speaker 2: applications intended query with your own select statements. You first
Speaker 2: figure out the number of columns the original querer returns.
Speaker 2: Then you can inject queries like union select one database
Speaker 2: user version five, assuming five columns to retrieve the current
Speaker 2: database name, the database username, the application is running as,
Speaker 2: and the database software version.
Speaker 1: Finding out details about the database itself right.
Speaker 2: Knowing the database type and version helps tailor further attacks.
Speaker 2: Then you can query the database's internal metadata tables like
Speaker 2: information Schema in mysequel to discover the names of all
Speaker 2: the tables and columns in the application's database. You might
Speaker 2: find tables named users, accounts, credit cards, and then you
Speaker 2: can query those tables directly to extract sensitive data like usernames,
Speaker 2: hash passwords, which you might be able to crack offline
Speaker 2: email addresses, personal details, etc.
Speaker 1: Extracting the entire user database through a web form.
Speaker 2: It's possible if the vulnerability is severe and not properly mitigated.
Speaker 2: In some database configurations, SQL injection can even be used
Speaker 2: to read arbitrary files from the server's file system, using
Speaker 2: functions like load file, effectively turning in simply flaw into
Speaker 2: an LFI flaw, or sometimes even write files leading to
Speaker 2: code execution.
Speaker 1: This sounds complex to do manually, it.
Speaker 2: Can be tedious, yes, That's why there are powerful automated
Speaker 2: tools like schoolmap. Schoole Map is an open source penetration
Speaker 2: testing tool that automates the process of detecting and exploiting
Speaker 2: SQL injection vulnerabilities. You just point it at a suspect
Speaker 2: URL and it will automatically test various injection techniques for
Speaker 2: different database types MYQL, postgrasschool, MSQL, Oracle, etc. If it
Speaker 2: finds an injection point, it can automatically enumerate databases, tables, columns,
Speaker 2: extract data, read files, and sometimes even give you an
Speaker 2: OS level command show all through the SQL injection vulnerability.
Speaker 2: It's an incredibly effective tool.
Speaker 1: Wow, SQL injection seems devastating. It really drives home a
Speaker 1: point you made earlier.
Speaker 2: What all these web vulnerabilities, especially SQL injection and code execution,
Speaker 2: fundamentally reveal is that critical principle never trust user input.
Speaker 1: Right.
Speaker 2: Every single piece of data coming from a user, whether
Speaker 2: it's in a URL, a form field, an HTTP head,
Speaker 2: or a cookie, must be rigorously validated and sanitized before
Speaker 2: it's used by the application, especially before it's included in
Speaker 2: a database query, an OS command, or a filepath. Otherwise,
Speaker 2: what looks like a benign comment or search query can
Speaker 2: become a direct command to your database or server.
Speaker 1: Okay, one more major web vulnerability type, cross site SCRIPTINGXSS.
Speaker 1: How is this different from things like SQL injection?
Speaker 2: XSS is fundamentally different because the injected code, which is
Speaker 2: usually JavaScript, executes in the victim user's browser, not on
Speaker 2: the server itself.
Speaker 1: A client side code injection, not server side exactly.
Speaker 2: SCORED affection affects the server's database. Code execution affects the servers.
Speaker 2: OS XSS affects the users visiting the vulnerable web page.
Speaker 2: There are three main types of XSS. Stored persistent EXSS.
Speaker 2: The attacker injects malicious JavaScript code and the web application
Speaker 2: stores it in this database VHG product review, a form,
Speaker 2: post a user profile. When other users view that stored content,
Speaker 2: the malicious script executes in their browsers.
Speaker 1: So one injection hits many users.
Speaker 2: Potentially Yes, That's why it's often considered the most dangerous type.
Speaker 2: Reflected EXSS. The malicious script is injected into the URL
Speaker 2: or a form submission, and the server reflects that script
Speaker 2: back in the immediate response page. It only executes if
Speaker 2: the user clicks on a specifically crafted malicious link, for example,
Speaker 2: sent via email or chat.
Speaker 1: Only affects users who click the bad link right.
Speaker 2: It requires more social engineering to get the victim to
Speaker 2: the malicious URL. DOM based XSS. This is a more
Speaker 2: subtle variant, where the vulnerability exists entirely in the client
Speaker 2: side JavaScript code running on the page. The server might
Speaker 2: not even see the malicious script, as the injection and
Speaker 2: execution happen purely within the browser's Document Object Model DOM.
Speaker 2: These can be harder to detect with server side standers.
Speaker 1: What can an attacker do with XSS if it just
Speaker 1: runs in the browser.
Speaker 2: JavaScript running in a browser context can still do a
Speaker 2: lot of damage. It can steal the user session cookies
Speaker 2: for that website, allowing the attacker to hijack their logged
Speaker 2: in session. It can rewrite parts of the current web
Speaker 2: page to display fake log informs or misleading information. It
Speaker 2: can redirect the user to malicious websites. It can perform
Speaker 2: actions on the website as the logged in user without
Speaker 2: their knowledge, eg change their passwords, send messages, transfer funds
Speaker 2: if it's a banking site.
Speaker 1: Wow. All from injecting script into a page.
Speaker 2: And remember BEEF. The Browser Exploitation Framework EXSS is the
Speaker 2: perfect way to deliver the BEEF hook. If you find
Speaker 2: a stored XSS vulnerability on a popular website, you can
Speaker 2: inject the beef hookscript as your PAYOEAD. Then every user
Speaker 2: who visits that compromised page gets automatically hooked into your
Speaker 2: BEEF console, giving your remote control over the browser session
Speaker 2: through all the module's BEEF offers.
Speaker 1: That connects the dots nicely. XSS delivers the hook for BEEF.
Speaker 2: It's a very common and powerful combination.
Speaker 1: So how do websites protect against EXSS?
Speaker 2: Again comes down to handling user inputs securely. The main
Speaker 2: defense is output encoding or escaping. Whenever usery supplied data
Speaker 2: is displayed back on a web page, the application should
Speaker 2: escape potentially dangerous HTML characters. For example, the character should
Speaker 2: be converted to NELT to NGS to end quote. This
Speaker 2: ensures that even if the user injects script exss script,
Speaker 2: the browser literally displays that text on the page instead
Speaker 2: of interpreting it as executable script tags. Content Security policy
Speaker 2: CSP headers are also a powerful defense mechanism, and user
Speaker 2: vigilance helps to being wary of suspicious links, checking for HTTPS,
Speaker 2: not installing untrusted browser extensions.
Speaker 1: Okay, that's an incredible overview of major web bloeulnerabilities. It
Speaker 1: seems like finding these manually requires a lot of skill
Speaker 1: and patients. Are there tools to help automate the discovery,
Speaker 1: similar to squamap for Sooley.
Speaker 2: Yes, while manual testing is crucial for understanding and finding
Speaker 2: complex flaws, there are automated web vulnerability scanners. A very
Speaker 2: popular open source one is OSPZP, which stands for the
Speaker 2: z Attack Proxy OSPZP.
Speaker 1: How does it work?
Speaker 2: ZAP typically runs as a proxy server on your local machine.
Speaker 2: You can figure your web browser to send all its
Speaker 2: traffic through the ZA proxy as you browse the target website. Normally,
Speaker 2: ZAP passively observes all the requests and responses. It can
Speaker 2: also actively spider the website to discover all its pages
Speaker 2: and links. Then you can tell ZAP to actively scan
Speaker 2: the discovered pages for common vulnerabilities like SQL injection, cross
Speaker 2: site scripting, file inclusion insecure configurations, and many others.
Speaker 1: So it acts like an automated ethical hacker trying common.
Speaker 2: Attacks in a way. Yes, it sends crafted requests with
Speaker 2: attack payloads and analyzes the responses to see if the
Speaker 2: application behaves in a vulnerable way. ZAP can generate detailed
Speaker 2: reports outlining the potential risks it found, categorizing them by severity,
Speaker 2: and often providing the specific URL and parameter that appears
Speaker 2: to be vulnerable, giving you a great starting point for
Speaker 2: manual verification and deeper exploitation.
Speaker 1: So it's a good backup or starting point, but maybe
Speaker 1: doesn't replace manual testing entirely exactly.
Speaker 2: Automated scanners like ZAP are excellent for finding low hanging
Speaker 2: fruit and ensuring broad coverage, but they can miss more
Speaker 2: complex logic based vulnerabilities that require human understanding of the
Speaker 2: application's context. They also sometimes produce false positives, so they
Speaker 2: are best used in conjunction with manual testing, not as
Speaker 2: a complete replacement.
Speaker 1: Makes sense. Wow, We have covered a staggering amount of
Speaker 1: ground in this deep dive. I mean, from setting up
Speaker 1: virtual hacking labs, understanding the nuances of network attacks like
Speaker 1: MI spoofing and MITM, the psychology of social engineering client
Speaker 1: side versus server side exploits, post exploisation, pivoting, and now
Speaker 1: this whole world of web application vulnerabilities like SEQL and EXSS.
Speaker 2: It's a lot, definitely, But what I hope stands out
Speaker 2: to you, the listener, is that ethical hacking isn't just
Speaker 2: about breaking in for the sake of it. It's really
Speaker 2: about deeply understanding how these complex systems are built, how
Speaker 2: the interact, and crucially, how they can fail or be manipulated. Also,
Speaker 2: they can ultimately be made more resilient and secure.
Speaker 1: That core lesson seems clear. Knowledge is power, not just
Speaker 1: for offense, but critically for defense.
Speaker 2: Precisely understanding the attacker's mindset, tools and techniques is arguably
Speaker 2: the best way to build effective defenses against them.
Speaker 1: We explored some incredibly sophisticated tools today metasploit, veil, multigo,
Speaker 1: beef wireshark, squall, map zap, each one revealing a different
Speaker 1: facet of this complex digital security landscape. It's honestly a
Speaker 1: profound reminder that our everyday online interactions, things we take
Speaker 1: for granted, like browsing a website or logging into an account,
Speaker 1: involve these intricate layers of technolog layers that can be misunderstood, misconfigured,
Speaker 1: or actively exploited.
Speaker 2: And that naturally leads to an important question. I think,
Speaker 2: considering how deeply interconnected our digital lives are now and
Speaker 2: seeing how these vulnerabilities work, how might a deeper understanding
Speaker 2: of these threats encourage you personally or professionally to approach
Speaker 2: your own cybersecurity differently, maybe moving beyond just the basic
Speaker 2: precautions like using strong passwords towards a more informed, maybe
Speaker 2: more proactive stance. Something to think about.
Speaker 1: Ah, that's a perfect closing thought, A challenge really for
Speaker 1: all of us. Thanks for diving deep with us today
Speaker 1: into the world of ethical hacking. It's been truly enlightening.
Speaker 1: Until next time, stay curious, stay informed, and most importantly,
Speaker 1: stay secure.