Speaker 1: Welcome to the deep dive. We're here to unpack the
Speaker 1: most vital insights from a stack of sources. Just for you.
Speaker 1: Think about the digital world we live in every single day.
Speaker 1: It's huge, complex, It feels like a fortress sometimes right,
Speaker 1: but well, sometimes a door just swings open if you
Speaker 1: know where to look. That is, today we're stepping through
Speaker 1: one of those doors. We're exploring the art and maybe
Speaker 1: the science of ethical hacking, or the more formal term
Speaker 1: penetration testing.
Speaker 2: Yeah, and this deep dive it's really your shortcut to
Speaker 2: understanding this whole fascinating field. We're pulling our insights today
Speaker 2: from a really practical guide, Penetration Testing step by step Guide,
Speaker 2: the second edition by Roddy Chataub. And it's not just theory,
Speaker 2: you know, it's very hands on. It explores the actual
Speaker 2: techniques the tools that hackers use, but for good reasons
Speaker 2: for defense exactly.
Speaker 1: So our goal for you today it's pretty simple. We
Speaker 1: want you to walk away understanding not just what system
Speaker 1: vulnerabilities are or even how they get attacked, but crucially
Speaker 1: how to defend against them. So, whether you're maybe new
Speaker 1: to information security, or perhaps you're a manager who needs
Speaker 1: to get a handle on modern threats. This deep dive,
Speaker 1: it's really designed to give you those aha moments, yeah,
Speaker 1: you know, without just drowning you in information.
Speaker 2: Absolutely, and before we jump right in, there's a really
Speaker 2: critical point we need to make everything we talk about today,
Speaker 2: it's all framed within the ethics of being a white
Speaker 2: hat hacker, an ethical hacker. All these techniques they're meant
Speaker 2: for authorized testing. You need explicit permission. The goal is
Speaker 2: always to find vulnerabilities and report them, not for anything
Speaker 2: malicious or illegal. It's really about building stronger defenses because
Speaker 2: you understand.
Speaker 1: The offense right makes sense. So, okay, we've had a
Speaker 1: little glimpse into this digital underworld. Let's get to the
Speaker 1: heart of it. How do the good guys actually fight back?
Speaker 1: What is penetration testing really and how does this proactive
Speaker 1: defense work for businesses?
Speaker 2: Well, think of it like this penetration testing. It's like
Speaker 2: hiring a professional burglar to test your home security system. Seriously,
Speaker 2: you give them permission right to try and break into
Speaker 2: your networks, your systems, your applications, specifically to find those
Speaker 2: weak spots, the vulnerabilities that a malicious hacker, a black
Speaker 2: hat might use to get in and cause real damage.
Speaker 2: It's proactive. You're trying to find those holes and patch
Speaker 2: them before the bad guys do beat them to the punch.
Speaker 1: Okay, and why is this so critical for businesses these days?
Speaker 1: Is it just, you know, a good practice or is
Speaker 1: there something more driving it?
Speaker 2: Oh, it's way beyond just a good idea. Often it's
Speaker 2: actually a necessity or requirement. Many businesses, especially if they
Speaker 2: handle payments, they're requiring to do regular pen tests to
Speaker 2: meet security standards like the Payment Card Industry Data Security
Speaker 2: Standard PCIDSS that requires a yearly pen test for certification.
Speaker 2: And because of things like that, the demand for skilled
Speaker 2: pen testers is just huge, it's booming. So understanding this
Speaker 2: stuff is really valuable.
Speaker 1: Okay, So who's this deep dive really for them? Who
Speaker 1: benefits most from digging into this book's insights with us?
Speaker 2: Well, I think it's perfect for anyone who wants to
Speaker 2: understand the mechanic of ethical hacking. Maybe you're just starting
Speaker 2: out in cybersecurity, or maybe you're an IT manager an
Speaker 2: INFOSEC manager, and you need practical insights. You want to
Speaker 2: understand the threats, the tools attackers use, and importantly, the
Speaker 2: protective measures you need. To put in place. Is designed
Speaker 2: to be really practical, you know, not get bogged down
Speaker 2: in just academic theory.
Speaker 1: Gotcha, and the book we're using. It breaks the whole
Speaker 1: process down into five core phases for a pen test.
Speaker 1: Can you give us a quick roadmap?
Speaker 2: Yeah, it's a pretty logical flow. Think of it like steps. First,
Speaker 2: there's reconnaissance that's just gathering info about your target, like
Speaker 2: detective work, finding out everything you can. Then comes scanning.
Speaker 2: That's when you actively probe the target looking for actual vulnerabilities.
Speaker 2: After that, the goal is gaining access, the actual exploitation part,
Speaker 2: getting in. Once you're in, it's about maintaining access, making
Speaker 2: sure you can stay in or get back in later,
Speaker 2: and finally covering tracks, hiding the evidence that you were
Speaker 2: ever there.
Speaker 1: Okay, reconnaissance, scanning, gaining access, maining covering tracks. Got it.
Speaker 1: Let's dive into the first big area then, Wi Fi vulnerabilities.
Speaker 1: Wireless is huge, right, It's often that first digital connection
Speaker 1: when you walk into a place.
Speaker 2: Oh, absolutely critical because a compromised Wi Fi network that
Speaker 2: isn't just a small problem. It puts your entire internal
Speaker 2: network at risk. For companies, insecure Wi Fi is often Honestly,
Speaker 2: the path of least resistance for an attacker makes it
Speaker 2: a prime target.
Speaker 1: And thinking about vulnerabilities, I remember WEP encryption from wayback.
Speaker 1: Is that still a thing we need to worry about?
Speaker 1: It seems ancient.
Speaker 2: We'd be surprised WEP is old. It is weak, but yeah,
Speaker 2: you still find it out there. Sometimes it uses this
Speaker 2: algorithm RC four. And here's the problem. Each packet is
Speaker 2: encrypted using a key stream generated partly by something called
Speaker 2: an initializing factor or five E. It's only twenty four
Speaker 2: bits long. And the real killer is this IV is
Speaker 2: sent in plain text right there in the packet, plaintext.
Speaker 1: Okay, that sounds like a huge red flag immediately, Yeah,
Speaker 1: the IV is just out there. How to attackers actual
Speaker 1: use that flaw? How do they crack the key?
Speaker 2: Right? That's the fundamental flaw Because that twenty four bit
Speaker 2: IV is so short, and it's sent unencrypted, it has
Speaker 2: to repeat eventually, especially on a busy network. So a
Speaker 2: tool like air cracking it doesn't even need the password itself.
Speaker 2: It just listens. It collects enough of these packets, enough
Speaker 2: of these repeating ivs, and by doing statistical analysis on
Speaker 2: how those ivs repeat, it can literally figure out the
Speaker 2: entire WEP key. It's not magic, just math exploiting that weakness.
Speaker 2: It can crack it surprisingly quickly, and attackers can even
Speaker 2: speed it up using things like a fake authentication procedure
Speaker 2: to inject packets.
Speaker 1: Okay, that makes total sense. Why WEP is considered broken. Yeah,
Speaker 1: so then WPA and WPA two came along to fix
Speaker 1: all that. They sound much more secure, unique keys, this
Speaker 1: four way handshake. But you know in hacking there's always
Speaker 1: a butt, isn't There are there still ways attackers get
Speaker 1: around WPA two.
Speaker 2: You hit it right on the head. There's always a butt.
Speaker 2: WPA and WPA two definitely a massive improvement over WEP,
Speaker 2: fix that exposed IVP problem. They use unique temporary keys
Speaker 2: for every packet and this robust four way handshake. Think
Speaker 2: of the handshake like a secret conversation. Your device and
Speaker 2: the router securely agree on unique keys. There's the pairwise
Speaker 2: master key, the PMK, and the paralyzed transient KEYPTK. They're
Speaker 2: derived from your WiFi password, the pre shared key or PSK.
Speaker 2: It means the encryption is constantly changing.
Speaker 1: Much harder to crack, okay, much harder, but not impossible.
Speaker 1: So even with those upgrades, how do attackers actually bypass
Speaker 1: WPA two. What are the main approaches?
Speaker 2: Yeah, still not impossible. There are really two main ways
Speaker 2: attackers go after w POPA two. First, exploiting the WPS
Speaker 2: feature Wi Fi protected setup. Remember that button on routers
Speaker 2: or at the PN. It was meant for convenience, you know,
Speaker 2: easily connecting printers and stuff, but it turned into a
Speaker 2: huge security hole. That eight digit PN. A tool called
Speaker 2: Reaver can basically brute force it. It attacks it in two halves,
Speaker 2: the first four digits, then the next four. So even
Speaker 2: with a super complex WPA two password, Reaver can often
Speaker 2: crack that eight digit PN in maybe ten hours or so.
Speaker 2: Get your password?
Speaker 1: Wow? Okay, so a convenience feature became a major vulnerability.
Speaker 1: What's the second method?
Speaker 2: Then? The second way involves capturing that four way handshake directly.
Speaker 2: An attacker can actually force the connected device like your laptop,
Speaker 2: to disconnect from the Wi Fi. It's called a de
Speaker 2: authentication attack. Then, when your laptop automatically tries to reconnect,
Speaker 2: that four way handshake happens again. The attacker listens and
Speaker 2: captures it. Once they have that captured handshake, they use
Speaker 2: tools like air cracking again, but this time they need
Speaker 2: a huge list of possible passwords, a word list. They
Speaker 2: might generate one with a tool like crunch, or download
Speaker 2: massive lists from places like seek lists online. Then they
Speaker 2: just try every password in the list against the handshake.
Speaker 2: If your password is in that list, they've got it.
Speaker 2: If not, this method.
Speaker 1: Fails, right the dictionary attack. That makes sense. Okay, that
Speaker 1: brings us to another really sneaky tactic, one that plays
Speaker 1: on our desire for free stuff. Fake access points classic lure,
Speaker 1: isn't it?
Speaker 2: Oh? Absolutely classic and effective. Hackers set up fake Wi
Speaker 2: Fi hotspots often give them ten names like free coffee
Speaker 2: shop WiFi or airport guest, especially in public places. You
Speaker 2: connect thinking it's legitimate, but now all your unencrypted traffic
Speaker 2: it's flowing right through the attacker's computer. They can see
Speaker 2: websites you visit, maybe present fake logging pages to seal
Speaker 2: your passwords, re emails if they're not encrypted, and tools
Speaker 2: like WiFi Pumpkin three makes setting these up surprisingly easy
Speaker 2: for an attacker.
Speaker 1: Okay, So, hearing all this, what's the bottom line for
Speaker 1: securing our own wireless networks? What are the absolute must dos?
Speaker 2: The takeaways are pretty clear. Yeah. First, never ever use
Speaker 2: wp just don't. It's completely broken. Second, always use WPA
Speaker 2: two and use a really strong complex password, think long passphrase,
Speaker 2: mix of uppercase, lowercase symbols. Numbers don't make it easy
Speaker 2: to guess. For businesses, integrating Wi Fi access with something
Speaker 2: like active directory is great. Avoids shared passwords, and for
Speaker 2: everyone that WPS feature we talked about, if your router
Speaker 2: has it, disable it, turn it off. That convenience just
Speaker 2: isn't worth the security.
Speaker 1: Risk disabled WPS got it? Okay? So let's say a
Speaker 1: hacker has gotten onto the network, maybe through weak Wi Fi.
Speaker 1: What's next? Our next deep dive is into post connection attacks,
Speaker 1: particularly this man in the middle stuff. Once they have
Speaker 1: that foothold, what's the first move right?
Speaker 2: Once they're inside, The very next step is discovery, like
Speaker 2: mapping out the territory. You need to figure out what
Speaker 2: else is on this network, what other devices are connected,
Speaker 2: what are their IP addresses. Tools like net discover or
Speaker 2: ARP scan are good for quickly finding other machines. But
Speaker 2: then the real workhorse is en map or its graphical version,
Speaker 2: zen map. N map is incredibly powerful. It scans targets
Speaker 2: and gives you detailed info, open ports, operating systems, what
Speaker 2: services are running that detailed scan. That's really the starting
Speaker 2: point for finding specific exploitable vulnerabilities on those machines, and.
Speaker 1: That leads us right into a man in the middle attacks.
Speaker 1: Then TM sounds kind of spy like, how do you
Speaker 1: define that?
Speaker 2: It pretty much is like spy stuff. A man in
Speaker 2: the middle attack or NATM is when an attacker secretly
Speaker 2: positions themselves between two communicating parties. Imagine you're talking to
Speaker 2: your bank online. The attacker gets in the middle. They
Speaker 2: intercept your messages to the bank and the bank's messages
Speaker 2: back to you. Both sides think they're talking directly, but
Speaker 2: they're actually talking through the attacker. It's like sophisticated eavesdropping,
Speaker 2: but worse because the attacker can potentially change the messages.
Speaker 2: Not just listen, they control the conversation. They might capture logins,
Speaker 2: manipulate transactions. It's really dangerous. Modern encryption like TLS tries
Speaker 2: to stop this, but attackers find ways around it sometimes.
Speaker 1: Okay, that's pretty scary. What are some common types of
Speaker 1: these my TM attacks?
Speaker 2: Well, the book mentions several key ones, things like ARP spoofing,
Speaker 2: DNS poofing, STP mangling, DHGP, spuefing, ICMP redirection. They all
Speaker 2: work slightly differently to trick network devices.
Speaker 1: Let's dig into ARP spoofing. How does that one exploit
Speaker 1: trust on a network? Why is it so effective?
Speaker 2: Okay? ARP Address resolution protocol. It's fundamental for local networks.
Speaker 2: Basically how your computer finds the physical MC address of
Speaker 2: another when it only knows the IP address, like asking
Speaker 2: who has this IP? The massive problem ARP is built
Speaker 2: on trust. It's incredibly insecure by design. Any computer on
Speaker 2: the network can just accept an ARP reply, even if
Speaker 2: it's fake. So arpspoof exploits this perfectly. It sends out
Speaker 2: fake AIRP messages. It tells your computer, hey, I'm the router,
Speaker 2: and it tells the router, hey I'm your computer. Suddenly,
Speaker 2: all the traffic between you and the router flows through
Speaker 2: the attacker's machine. For this to work seamlessly, the attacker
Speaker 2: needs to enable IP four in on their machine, so
Speaker 2: the traffic just passes through. Once that's set up, tools
Speaker 2: like wireshark running on the attacker's machine can see everything, logins, browsing,
Speaker 2: you name it. If it's unencrypted. It's disturbingly simple. Wow.
Speaker 1: Yeah, disturbingly simple, is right, just exploiting that basic trust.
Speaker 1: But what if the attacker wants to do more than
Speaker 1: just listen? What if they want to actively mess with
Speaker 1: the traffic. That's where tools like better cap come in. Right,
Speaker 1: What makes it such a powerful network tool?
Speaker 2: Exactly? Better Cap is like a Swiss army knife for
Speaker 2: network attacks, especially my TM. It's incredibly powerful and versatile.
Speaker 2: It lets an attacker manipulate HTTP, HTTPS, sometimes and TCP
Speaker 2: traffic in real time, sniff credentials, inject code, modify pages
Speaker 2: on the fly, for instance, using its arc dot spoof
Speaker 2: module to become the man in the middle and then
Speaker 2: dot sniff to capture data. It can easily grab unencrypted
Speaker 2: HTTP log in, say from a test website, and a
Speaker 2: really powerful feature caplets. These are like scripts for better Cap.
Speaker 2: Automating sequences of commands makes complex attacks much easier to execute.
Speaker 1: Okay, but what about ng GTPs. We always here look
Speaker 1: for the lock. HTTPS is secure? How does something like
Speaker 1: SSL stripping try to defeat that?
Speaker 2: Right? HTTPS is much more secure. SSL stripping is a
Speaker 2: technique attackers used to try and downgrade that security. The
Speaker 2: attacker acts as a proxy during the initial connection When
Speaker 2: your browser tries to connect via HTTPS, the attacker intercepts
Speaker 2: it talks HGTPS to the real server, but talks plane
Speaker 2: unencrypted HTTP back to your browser. So you think you
Speaker 2: might be secure, or maybe you don't notice THES is missing,
Speaker 2: but your connection is actually in the clear. But there's
Speaker 2: a crucial defense HSTS HTTP strict transport security. It's a
Speaker 2: header a website sends that tells your browser, Hey, for
Speaker 2: this site, only ever use HTTPS, no exceptions, so that
Speaker 2: parameters like maxage how long the browser should remember this
Speaker 2: rule include subdomains and preload.
Speaker 1: HSTS sounds like a solid defense, but you mentioned dynamic
Speaker 1: versus static HSTS. Does that distinction matter much?
Speaker 2: Oh? It matters hugely for security. Dynamic HSTS is where
Speaker 2: your browser learns about HSTS after the very first time
Speaker 2: it visits the site it gets the header. Then that
Speaker 2: leaves a tiny window on that very first connection where
Speaker 2: an SSL stripping attack could potentially work before the browser
Speaker 2: knows it must use HTPS. Static HSTS closes that gap.
Speaker 2: Websites can submit themselves to be included in a preload
Speaker 2: list that's built right into browsers like Chrome, Firefox, etc.
Speaker 2: So if a site is on that pre load list.
Speaker 2: Your browser already knows it must use HTTPS, even if
Speaker 2: you've never visited it before. That makes us a CEL
Speaker 2: stripping completely and effective. Against those sites the browser just
Speaker 2: won't connect insecurely.
Speaker 1: Got it. Preloading is key and DNS spoofing is another mitmtrick,
Speaker 1: basically lying about website.
Speaker 2: Addresses exactly your computer uses DNS, the domain name system
Speaker 2: to turn website names like www dot Google dot com
Speaker 2: into IP addresses. In DNS spoofing, the ITM attacker runs
Speaker 2: their own fake DNS server on the local network. When
Speaker 2: your computer asks what's the IP for www dot my
Speaker 2: bank dot com, The attacker's fakeserver answers with an IP
Speaker 2: address they control, maybe a phishing site that looks real,
Speaker 2: so you get redirected to the wrong place. But again,
Speaker 2: like s is all stripping, this generally doesn't work against
Speaker 2: sites using HTTPS. With HSTS enabled and preloaded, the browser
Speaker 2: will refuse to connect to a fake HTTP version. You
Speaker 2: can demo this with tools like an apatche webserver for
Speaker 2: the fake site and BETTERCAPS. DNS dot spoof module.
Speaker 1: And BETTERCAP can even inject code like JavaScript into the
Speaker 1: websites you're visiting.
Speaker 2: That's right. If the connection is HTTP or HTT without
Speaker 2: strong hsts, better cap can inject custom JavaScript into the
Speaker 2: pages as they pass through. This is incredibly dangerous. JavaScript
Speaker 2: running in your browser can do a lot of malicious
Speaker 2: things steal cookies, lug keystrokes, redirect you, pop up fake logins,
Speaker 2: all controlled by the attacker.
Speaker 1: Okay, so, after hearing about ARP spoofing, dnspoofing, SSL stripping,
Speaker 1: how do we actually detect and more importantly, prevent ARP
Speaker 1: poisoning which seems to underpin a lot of this.
Speaker 2: Detecting it tools like wireshark are invaluable. It can spot
Speaker 2: unusual network chatter like an ARP storm tons of AIRP
Speaker 2: requests which might indicate a scan or attack. Wireshot can
Speaker 2: even directly flag potential MITM attacks if it sees duplicate
Speaker 2: IP addresses claiming the same ASC or vice versa. For prevention,
Speaker 2: things like intrusion detection systems or intrusion prevention systems idscs
Speaker 2: are important. Also, modern layer two switches can be configured
Speaker 2: with features like dynamic AARP inspection or the AMSC address
Speaker 2: tracking to block spoofed packets. There are also client side
Speaker 2: tools like ZARP that monitor for suspicious ARP activity. Interestingly,
Speaker 2: while we focus on the bad stuff, airpeacepoofing can be
Speaker 2: used for legitimate reasons, like on public Wi Fi redirecting
Speaker 2: users who haven't logged in yet to a sign up page.
Speaker 1: Right, legitimate uses too, Okay, So moving on. After all
Speaker 1: that scanning and maybe MYTM setup, the real goal for
Speaker 1: an attacker is often gaining access, getting control of devices.
Speaker 1: Let's talk server side attacks first. These are direct assaults,
Speaker 1: right exactly.
Speaker 2: Server side attacks target vulnerabilities directly on the server itself.
Speaker 2: They don't need the user to click anything or run anything.
Speaker 2: You just need the server's ike address and an exploitable
Speaker 2: service running zenmap or nmap is key here for that
Speaker 2: initial info gathering, finding open ports identifying services like FTP,
Speaker 2: RSH remote shell or Samba Windows file sharing, so you're.
Speaker 1: Looking for known flaws in those.
Speaker 2: Specific services precisely. Sometimes it's about finding older, unpatched versions
Speaker 2: with well known vulnerabilities. For example, there's a specific version
Speaker 2: of VSFTPD and FTPC version two point three point four
Speaker 2: that famously had a back door baked into it. If
Speaker 2: you find that running boom root access. Another example is
Speaker 2: netkit RSH. If that remote shell service is enabled and
Speaker 2: misconfigured on a Linux box, you might be able to
Speaker 2: execute commands remotely.
Speaker 1: And beyond those simpler known flaws, there are more complex
Speaker 1: code execution vulnerabilities. Tell us about those and this concept
Speaker 1: of a reverse connection that sounds clever.
Speaker 2: Yeah, code execution vulnerabilities exploit flaws maybe in web applications
Speaker 2: or services like Zomba that let an attacker run their
Speaker 2: own commands on the server. Now the reverse connection. This
Speaker 2: is a really smart way to bypass firewalls. See, most
Speaker 2: firewalls are configured to block incoming connections initiated from the
Speaker 2: outside like a castle wall. Or reverse connection flips that
Speaker 2: the attacker sets up a listener on their machine. Then
Speaker 2: the exploit makes the victim's server initiate an outgoing connection
Speaker 2: back to the attacker. Since the connection started from inside
Speaker 2: the network, the firewall often lets it pass right through.
Speaker 2: It's like the victim opens a secret door outwards. The
Speaker 2: metasplit framework is the go to tool for this. It
Speaker 2: has tons of exploits and payloads. A common payload is
Speaker 2: something like cmdo nix reverse netcat. You just tell it
Speaker 2: your attacker ipe LHST and the port you're listening on
Speaker 2: lpr ort, run the exploit and hope the victim connects back.
Speaker 1: That is clever. Okay. So besides trying these exploits manually,
Speaker 1: there's automated vulnerability scanning. What's the main goal.
Speaker 2: There, right? Automated scanning is about efficiency and coverage. Its
Speaker 2: purpose is to systematically check computers, servers, whole networks for
Speaker 2: known weaknesses. These scanners look for outdated software, misconfigurations, missing patches,
Speaker 2: things that match entries in huge vulnerability databases. Think of
Speaker 2: databases like OSVDB Open Source Vulnerability Database, the NIST, MVD
Speaker 2: National Vulnerability Database, or CVE Common Vulnerabilities and Exposures. The
Speaker 2: scanner basically compares what it finds on your systems against
Speaker 2: these lists of known problems. It's like an automated security audit.
Speaker 1: Some of the big names in scanning software, well.
Speaker 2: There are several well known ones. You've got nessis Qualities,
Speaker 2: open vas which is open source, but a really prominent
Speaker 2: commercial one, especially one that integrates well with exploitation tools,
Speaker 2: is rapid seven.
Speaker 1: Nextpos xsoz so it integrates with metasploit. You said, what's
Speaker 1: its role in the bigger picture? The whole vulnerability management
Speaker 1: process and any practical tips for using it.
Speaker 2: Yeah, nexpos integrates tightly with metasploit. You can find a
Speaker 2: vulnerability in expos and often directly launch and exploit for
Speaker 2: it in metasploit. Its role covers the entire vulnerability management
Speaker 2: life cycle. Discovery, finding assets on your network, detection, finding
Speaker 2: the weaknesses, verification, checking if they're actually exploitable, risk classification, reporting,
Speaker 2: and even helping prioritize fixing things the mitigation part. Practically speaking,
Speaker 2: it's a powerful tool, very comprehensive, but be aware it
Speaker 2: can be a bit of a beast resource wise, needs
Speaker 2: decent RAM like eight GB good disk space, especially in
Speaker 2: a VM, and the first time you start it up
Speaker 2: it might take like thirty minutes to updates data bit.
Speaker 2: Once it's running, it's great. You create sites for your
Speaker 2: scan targets at IP addresses, run the scans, and then
Speaker 2: you get these really detailed reports, audit reports, executive summaries,
Speaker 2: even just the top ten worst vulnerabilities. Very useful.
Speaker 1: Okay, so those are server side attacks, that's direct, But
Speaker 1: client side attacks they feel different, more personal, maybe because
Speaker 1: they involve the human element.
Speaker 2: Absolutely. Client side attacks nearly always need the user to
Speaker 2: do something click a link, open a file, install an app,
Speaker 2: and because of that, they rely heavily on social engineering
Speaker 2: tricking the user. Honestly, it's often much much easier to
Speaker 2: exploit human trust or curiosity than it is to find
Speaker 2: a purely technical flaw. In well maintained software, you can
Speaker 2: have the best firewall, the best anti virus, that if
Speaker 2: you trick someone into letting you in the door, none
Speaker 2: of that matters. The human is often the weakest link.
Speaker 1: It really is amazing how effective that can be. I
Speaker 1: remember getting a phishing email once. It looked so real SII.
Speaker 1: So there's a tool called the veiled Evasion framework that
Speaker 1: helps create malware that gets past security.
Speaker 2: That's exactly what veil evasion is designed for. It helps
Speaker 2: generate backdoors, malicious payloads that are specifically crafted to try
Speaker 2: and bypass common antivirus software. It often uses something called
Speaker 2: Interpreter payloads from Metasplay. Interpreter is really advanced. Instead of
Speaker 2: just dropping a simple executable file, it often works by
Speaker 2: injecting itself directly into the memory of another process using
Speaker 2: DLL injection. This makes it much harder to detect because
Speaker 2: there might not be a malicious file sitting on the
Speaker 2: hard drive. It runs in memory and gives the attacker
Speaker 2: incredible control keylogger, screen capture, filesystem access, pivoting, all without
Speaker 2: easily being traced on the disc at least until a reboot.
Speaker 1: Wow, running in memory. That's sneaky. So how does anti
Speaker 1: malware software even try to catch threads like that? What
Speaker 1: are the main methods?
Speaker 2: Anti malware uses a few main strategies. The classic one
Speaker 2: is signatures, basically a database of known malware fingerprints. If
Speaker 2: a file matches a known signature, it's flagged. Then there's heuristics.
Speaker 2: This is more behavior based. It looks for suspicious actions
Speaker 2: or characteristics even if the file doesn't match a known signature.
Speaker 2: This can catch new threats, but it can also sometimes
Speaker 2: lead to false positives, flagging legitimate software by mistake. Third,
Speaker 2: sandboxing running a suspicious program in a safe, isolated environment
Speaker 2: to see what it does without letting it harm the
Speaker 2: main system. An interesting detail here. Some sophisticated malware can
Speaker 2: actually detect when it's running in a sandbox, and if
Speaker 2: detects that, it might just sit there and do nothing,
Speaker 2: only activating its malicious code when it thinks it's on
Speaker 2: a real user's machine. And finally, if malware is detected,
Speaker 2: the usual action is removal, deleting it or quarantining it,
Speaker 2: moving it to a safe place where it can't run.
Speaker 1: Okay, so veil creates the evasive malware, then the attacker
Speaker 1: needs to set up a way to listen for that
Speaker 1: malware calling home right correct.
Speaker 2: That's where the metaspolate handler comes in. It's essentially the listener.
Speaker 2: You can figure it to expect a connection from the
Speaker 2: specific type of backdoor you created on a specific port.
Speaker 2: It just sits there waiting. The common headache when setting
Speaker 2: this up is the port might already be in use
Speaker 2: by another application on your attacker machine. You can use
Speaker 2: commands like netstat a or LSoft in Linux to check
Speaker 2: which process is using the port, and then you might
Speaker 2: need to kill that process. So the handley combined to
Speaker 2: the port.
Speaker 1: Right, gotta free up the port so the listener is ready.
Speaker 1: How does the malware actually get to the victim? What
Speaker 1: are the common delivery methods?
Speaker 2: Well, the simplest way is just putting the malicious file
Speaker 2: on a web server, maybe your Collie Linux machine running
Speaker 2: apatche too, and tricking the user into downloading and running it. Directly,
Speaker 2: but more common and often more effective are things like
Speaker 2: phishing emails, emails with malicious links or attachments. A really
Speaker 2: effective and quite devious method is embedding the malware inside
Speaker 2: a seemingly harmless file like a PDF or a JPG.
Speaker 2: You can use SFX archives, which are self extracting archives
Speaker 2: created with tools like wind raar. The victim thinks they're
Speaker 2: just opening a document or a picture, clicks it, the
Speaker 2: document opens, but silently in the background. The malware also
Speaker 2: extremes and executes very sneaky, and attackers often set at
Speaker 2: persistence too, configuring the malware so it automatically starts up
Speaker 2: again if the victim reboots their computer, maybe by inchecking
Speaker 2: it as a Windows service or adding a registry key
Speaker 2: to run a script on startup.
Speaker 1: And there's a tool called Cage to help manage all
Speaker 1: these compromised machines.
Speaker 2: Yeah, Cage is basically a graphical front end for managing
Speaker 2: metasplit sessions. If an attacker has multiple compromise machines connecting
Speaker 2: back via interpreter, Cage provides a guy to easily interact
Speaker 2: with them, run commands, take screenshots, organize the sessions. Makes
Speaker 2: managing multiple victims simpler.
Speaker 1: So with all these clever delivery methods, especially the ones
Speaker 1: embedding malware, what are the best ways to protect ourselves?
Speaker 2: Good question. There are a few key layers of defense. First,
Speaker 2: man in the middle prevention. Be careful about the networks
Speaker 2: you connect to. Use trusted networks, maybe a VPN on
Speaker 2: public Wi Fi. Tools like ZARP can also help detect
Speaker 2: AARP poisoning attempts on your local network. Second, always look
Speaker 2: for HTTPS connections. Encrypted traffic is much hard for an
Speaker 2: attacker to tamper with or inject things into. Use browser
Speaker 2: extensions like HTTPS everywhere. Third hashing. This is really important
Speaker 2: for downloads. If a software publisher provides a hash like
Speaker 2: MT five or SAHA two five six for their file,
Speaker 2: you can calculate the hash of the file you downloaded.
Speaker 2: If the hash is match, the file is almost certainly
Speaker 2: authentic and hasn't been tampered with. If they don't match,
Speaker 2: don't want it okay.
Speaker 1: Hashing is a good practical tip. So let's say the
Speaker 1: attacker is successful. They've gained access, the work isn't over.
Speaker 1: Our next deem dive is post exploitation and social engineering tactics.
Speaker 1: What exactly happens in post exploitation. What's the goal?
Speaker 2: Post exploitation is everything that happens after you've successfully compromised
Speaker 2: a system. Gaining that initial access is just the first step.
Speaker 2: The goal now is to maximize your control, gather valuable information,
Speaker 2: potentially move laterally to other systems on the network, and
Speaker 2: ensure you can maintain access persistently. The metasploit Interpreter shell
Speaker 2: is packed with post exploitation commands, shows you everything you
Speaker 2: can do. Background lets you hide the session but keep
Speaker 2: it active. Sessions list all your active connections. Since info
Speaker 2: gives you basic info about the victims OS.
Speaker 1: And the book mentions something intriguing. Process impersonation. How does
Speaker 1: that work? Why is it useful for an attacker?
Speaker 2: Ah? Yeah, process migration or impersonation. It's a stealth technique.
Speaker 2: Materpreter allows you to take your malicious process and migrate
Speaker 2: it so it runs inside a legitimate common Windows process
Speaker 2: like explore dot exx, or maybe a browser process like
Speaker 2: Microsoft Edge. Why because if someone opens task Manager and
Speaker 2: looks at the running processes, they're less likely to spot
Speaker 2: explore dot ex as being suspicious compared to some weirdly
Speaker 2: named malware dot ex It helps the back door blend
Speaker 2: in making it harder to detect and.
Speaker 1: Kill blend in dot clever. And once you have that
Speaker 1: materpreter session, you basically have full control over the victims
Speaker 1: files pretty much.
Speaker 2: Yeah, you have full control over their filesystem. You can
Speaker 2: browse directories ALSPWDCD, download files from the victim machine, download
Speaker 2: upload file to upload, delete files, even modify them. You
Speaker 2: can also drop into a standard Windows command shell through
Speaker 2: the interpreter session for even more direct control. It's like
Speaker 2: sitting at their computer remotely.
Speaker 1: But that connection might die if they reboot. Right, how
Speaker 1: do attackers achieve persistence? Making sure they can get back
Speaker 1: in after a restart right?
Speaker 2: Persistence is key for long term access. A simple interpreter
Speaker 2: session in memory usually dies on reboot, so post exploitation
Speaker 2: often involves setting up persistence mechanisms. The book talks about
Speaker 2: methods like injecting the back door as a Windows service
Speaker 2: that starts automatically, or creating Windows Registry keys that tell
Speaker 2: the system to run a script, maybe a Visual Basic
Speaker 2: Script jvbscript as mentioned. When the user logs in or
Speaker 2: the system boots up, that script then connects back to
Speaker 2: the attackers listener re establishing the connection automatically, and.
Speaker 1: Maybe the most chilling part, keyloggers and screenshots. That's actual
Speaker 1: real time spying.
Speaker 2: It is Interpreter has modules for both. You can start
Speaker 2: a keylogger that captures every single keystroke the victim type, passwords, emails,
Speaker 2: chat messages, everything. You can also take screenshots at their
Speaker 2: desktop in real time, seeing exactly what they're doing. It
Speaker 2: gives the attacker complete invasive visibility into the victims' activities
Speaker 2: on the compromised machine.
Speaker 1: Okay, shifting from the purely technical, let's talk social engineering.
Speaker 1: The book says it's often easier to exploit human trust
Speaker 1: than hack software. Why is that still so true with
Speaker 1: all our tech?
Speaker 2: It boils down to psychology. Really, security fundamentally relies on
Speaker 2: knowing who and what to trust. Social engineers exploit our
Speaker 2: basic human nature, our desire to be helpful, our curiosity,
Speaker 2: our fear, sometimes just being busy or distracted. It's often
Speaker 2: far less work to craft a convincing email that tricks
Speaker 2: someone into clicking a link or giving up a password
Speaker 2: than it is to find and exploit a zero day
Speaker 2: vulnerability in software. Technology can build high walls, but social
Speaker 2: engineer and just walks up to the gate and asks
Speaker 2: to be let in, often successfully. The human is the variable.
Speaker 1: Yeah, that makes sense. It targets our instincts. So, like
Speaker 1: any attack, social engineering starts with information gathering. What tools
Speaker 1: help with that?
Speaker 2: Absolutely? Good recon is crucial for effective social engineering. You
Speaker 2: need to know your target. Tools like Google dorcs are
Speaker 2: surprisingly powerful for finding publicly exposed information online. Recon is
Speaker 2: a great framework specifically for open source intelligence gathering. And
Speaker 2: while Tago is really interesting, it's a visual tool. It
Speaker 2: helps map out relationships between different pieces of information people,
Speaker 2: email addresses, companies, websites, network infrastructure. It pulls data from
Speaker 2: tons of public sources and creates these visual link analysis charts.
Speaker 2: Helps an attacker build a really detailed picture of their
Speaker 2: target and potential attacking.
Speaker 1: In the classic delivery email spoofing, how do attackers make
Speaker 1: fake emails look real enough to bypass spam filters.
Speaker 2: Email spoofing is definitely the most common way to deliver
Speaker 2: social engineering attacks like phishing links or malware attachments. The
Speaker 2: challenge for attackers is that modern spam blockers are pretty
Speaker 2: good at spotting emails sent from dodgy free spoofing services.
Speaker 2: They often end up in junk folds. So attackers get smarter,
Speaker 2: they might use reputable SMTP relay servers. These are legitimate
Speaker 2: email sending services like send and Blue is mentioned as
Speaker 2: an example. Using those can help bypass some filters. Or
Speaker 2: they might set up their own customer email servers, or
Speaker 2: compromise existing ones, or even just create very convincing fake
Speaker 2: accounts on real services. But even then you might see
Speaker 2: clues like the email landing in your promotions tab or
Speaker 2: seeing a via sendeblue dot com tag in the sender details.
Speaker 2: Those are potential red flags to watch for.
Speaker 1: Okay, let's move into our fift deep dive web and
Speaker 1: mobile application penetration testing. Starting with web browsers, there's a
Speaker 1: tool called BEEF. What's special about it?
Speaker 2: Right? BEEF the Browser Exploitation framework. What makes it unique
Speaker 2: is it's laser focus on the web browser itself as
Speaker 2: the attack platform. Most tools target the network or the
Speaker 2: servers OS or the client OS. BEEF says, forget that
Speaker 2: for a minute. Let's attack the user directly through their browser.
Speaker 1: It hooks the browser, hooks the browser. How does that work?
Speaker 1: How does it actually gain control?
Speaker 2: It works by general creating a small piece of JavaScript
Speaker 2: code called the hook. The attacker needs to get this
Speaker 2: hook code to run in the victim's browser. This usually
Speaker 2: happens if the attacker can inject it into a website
Speaker 2: the victim visits, maybe a site the attacker controls or
Speaker 2: a legitimate site they've compromised with the vulnerability. When the
Speaker 2: victim's browser loads the page with the hook, that JavaScript
Speaker 2: runs and makes the browser secretly connect back to the
Speaker 2: attacker's beef server. Once that connection is made, the browser
Speaker 2: is hooked and the attacker can send commands to it
Speaker 2: through the beef interface.
Speaker 1: Okay, so getting that hook onto a website sounds like
Speaker 1: it involves cross site SCRIPTINGXSS. What exactly is XSS and
Speaker 1: how does it enable beef?
Speaker 2: Yeah, XSS is a very common way to deliver the beefook.
Speaker 2: Cross site scripting is a type of injection attack. Basically,
Speaker 2: the attacker manages to inject malicious JavaScript code into a
Speaker 2: website that other users trust. When another user visits that page,
Speaker 2: their browser executes the attacker's script because it thinks the
Speaker 2: script is part of the legitimate website, like a trojan
Speaker 2: horse delivered by the website itself. There are a few
Speaker 2: main types stored XSS or persistent, where the malicious script
Speaker 2: is saved permanently on the website, maybe in a comment field,
Speaker 2: and affects everyone who've used it. Reflected EXSS, where the
Speaker 2: script is part of a link the attacker tricks the
Speaker 2: victim into clicking it, reflects off the web server and
Speaker 2: runs in the victim's browser just that one time, and
Speaker 2: DOM based EXSS, which is a bit trickier exploiting how
Speaker 2: the browser itself processes data on the client side, sometimes
Speaker 2: without even talking to the server.
Speaker 1: How would a pen tester even find an EXSS vulnerability
Speaker 1: and then use it to inject that beef hook.
Speaker 2: Finding EXSS often starts by looking for places on a
Speaker 2: website where user input is displayed back on the page.
Speaker 2: Think search results, comment sections, user profiles. You try injecting
Speaker 2: simple test scripts like script alert excess script. If you
Speaker 2: see that alert box pop up when the page loads BINGO,
Speaker 2: you've likely found an EXSS flaw. Once you find one,
Speaker 2: especially a stored EXSS vulnerability, you can then inject the
Speaker 2: beef hook script instead of just the alert. Because it's stored,
Speaker 2: every user who visits that compromise page from then on
Speaker 2: will automatically get hooked by BEEF, connecting their browser back
Speaker 2: to the attacker.
Speaker 1: And once a browser is hooked with BEEF, you can
Speaker 1: actually use that to hack the underlying machine like Windows
Speaker 1: or even mobile phones.
Speaker 2: Yes, that's where BEEF gets really powerful. It's not just
Speaker 2: about controlling the browser. It's a launch pad. From the
Speaker 2: BEEF control panel, the attacker can send commands to the
Speaker 2: hooked browser. One common tactic is using social engineering modules,
Speaker 2: for example, sending a fake update notification that looks like
Speaker 2: it's from Firefox or Adobe Flash Player. If the victim
Speaker 2: clicks install update, what they actually download and run could
Speaker 2: be a metaspoint interpreter back door generated by the attacker.
Speaker 2: If they run it, boom, the attacker gets a full
Speaker 2: remote control session on their Windows machine and worryingly, yes,
Speaker 2: BEEF works just fine on mobile browsers too, Android iOS
Speaker 2: hooking the mobile browser can lead to similar kinds of attacks.
Speaker 1: Okay, that's concerning. So what are the best defenses against
Speaker 1: excess is? How do websites prevent this?
Speaker 2: Preventing XSS requires dillas from web developers. Key techniques include
Speaker 2: escaping user input. This means converting potentially harmful characters like
Speaker 2: anelo into safe entities like NELT and ENEGEL, so the
Speaker 2: browser treats them as text, not code, validating input being
Speaker 2: very strict about what kind of data is allowed in
Speaker 2: different fields. If a field should only contain numbers, don't
Speaker 2: allow letters or symbols. Using whitelists is better than blacklists,
Speaker 2: sanitizing user input, actively removing or cleaning up any potentially
Speaker 2: dangerous HTML or script tags from user submissions, and on
Speaker 2: top of that, using a Web application firewall. Wf ws
Speaker 2: sit in front of the web server and inspect incoming traffic,
Speaker 2: trying to detect and block EXSS attacks and other common
Speaker 2: web threats before they even reach the application code.
Speaker 1: Right defense and depth. Okay, Moving beyond browser exploits, let's
Speaker 1: talk general website penetration testing. What's the typical stack of components?
Speaker 2: A tester looks at sure, A typical web application has
Speaker 2: multiple layers. There's the server hardware itself or VM, the
Speaker 2: operating system running on it, the web server software like
Speaker 2: Apatchee or Microsoft ISA, the database backing the application, maybe Myschool, Postgress,
Speaker 2: wiel Segle server, and then the actual web application code
Speaker 2: written in languages like PHP, Python, Java, NOJS, etc. The
Speaker 2: first step in testing is always information gathering, figuring out
Speaker 2: as much as possible about each of these components.
Speaker 1: What are some good tools for that initial information gathering
Speaker 1: phase on websites to understand that stack?
Speaker 2: There are lots of great tools whose lookups give you
Speaker 2: domain registration details. Netcraft provides incredibly detailed reports on websites.
Speaker 2: The technologies they use, webserver os, frameworks, hosting provider known history,
Speaker 2: sometimes even vulnerabilities. It's amazing what you can find there.
Speaker 2: Robtext is good for DNS information finding related domains, seeing
Speaker 2: what other sites might be hosted on the same server.
Speaker 2: Knock Pi or similar tools helps discover hidden subdomains associated
Speaker 2: with a main domain which might host less secure applications,
Speaker 2: and DRB or tools like gobuster or a fun uf
Speaker 2: are essential. They brute force common directory and file names
Speaker 2: using word lists. You'd be surprised how often they uncover
Speaker 2: sensitive files left accessible, like configuration files, backup files, or
Speaker 2: even things like robots dot txt or maybe an accounts
Speaker 2: dot txt file that shouldn't be there.
Speaker 1: Finding lift or files, Yeah, it happens more than you'd think.
Speaker 1: What about file upload vulnerabilities? How are those exploited?
Speaker 2: File upload features are a common source of vulnerabilities. If
Speaker 2: a site lets you upload, say a profile picture, it
Speaker 2: needs to strictly check that the uploaded file actually is
Speaker 2: an image. If the checks are weak rejeff only looking
Speaker 2: at the filename extension, an attacker might try uploading something
Speaker 2: malicious instead. A common attack is uploading a PHP webshell.
Speaker 2: This is a small script, often created with a tool
Speaker 2: like Weaveley, that gives the attacker command execution on the server.
Speaker 2: If the server accepts the upload and the attacker can
Speaker 2: then access that uploaded file via their browser, the PHP
Speaker 2: code executes, and the attacker effectively gets a remote shell
Speaker 2: on the web server. Full control.
Speaker 1: Okay, webshells are bad. What about direct code execution vulnerabilities
Speaker 1: in the web app itself.
Speaker 2: These happen when the web application takes input from the
Speaker 2: user and improperly uses it as part of a command
Speaker 2: that gets executed on the server's operating system. A classic
Speaker 2: example is a website feature that lets you say ping
Speaker 2: and IP address to test connectivity. If the website just
Speaker 2: takes the IP address you provide and plugs it directly
Speaker 2: into a system ping command without cleaning it first sanitizing it,
Speaker 2: an attacker could inject extra commands instead of just an IP.
Speaker 2: They might enter something like eight eight point eight point
Speaker 2: eight and ce binge attacker IP attach report. The semicolon
Speaker 2: separates commands and Linux umix, so the server ping's eight
Speaker 2: point eight point eight point eight, and then it executes
Speaker 2: the netcat command, which launches a reverse shell connecting back
Speaker 2: to the attacker's machine.
Speaker 1: Game over combining comm the panston infony. Then there are
Speaker 1: file inclusion vulnerabilities LFI and RFI. What's the difference in
Speaker 1: How do they work?
Speaker 2: Right? LFI and RFI. Local file inclusion LiFi exploits flaws
Speaker 2: where a web application includes files based on user input
Speaker 2: but doesn't properly restrict which files can be included. An
Speaker 2: attacker might manipulate a URL parameter like dot page dot
Speaker 2: et setsia passwd the dot traverss directories upwards. If the
Speaker 2: app is vulnerable, it might actually include and display the
Speaker 2: contents of the stead of pass weed file, which contains
Speaker 2: user account info. On Linux, let's then read arbitrary files
Speaker 2: on the server. Remote file inclusion RFI is similar, but
Speaker 2: potentially even more dangerous. It occurs that the application can
Speaker 2: be tricked into including a file from a remote URL
Speaker 2: one controlled by the attacker. This usually requires a specific
Speaker 2: PHP configuration setting allow er and clude to be enabled.
Speaker 2: It's off by default now, thankfully. If RFI is possible,
Speaker 2: the attacker can host a malicious script like a webshell
Speaker 2: on their own server and trick the victim server into
Speaker 2: downloading and executing it instant backdoor.
Speaker 1: Okay, so LiFi reads local files, RFI executes for remote files.
Speaker 1: What are the key ways to prevent all these webvolms? Uploads?
Speaker 1: Code execution, file inclusion.
Speaker 2: Several key defenses for file uploads. Implement strict checks on
Speaker 2: file types, not just based on the filename extension, but
Speaker 2: by inspecting the file content mime type match bytes. Also
Speaker 2: store uploaded files outside the webroot if possible, or in
Speaker 2: a location where they cannot be executed for code execution.
Speaker 2: Rigorously sanitize all user input. Never ever trust user input.
Speaker 2: Use built in language functions designed for safe command execution
Speaker 2: if you absolutely must, but avoid it if possible. Whitelist
Speaker 2: allowed inputs for file inclusion. Disable dangerous PHP settings like
Speaker 2: allowal fopen and allower include in PHP dot e ne
Speaker 2: avoid including files based directly on user input. Use hard
Speaker 2: coded pads or map user input to safe allowed filepads
Speaker 2: and generally across the board. A well configured web application
Speaker 2: firewall WAF acts as an essential safety net catching many
Speaker 2: of these attack patterns.
Speaker 1: Yes, wfs are important, and let's tackle a huge one.
Speaker 1: SQL injection. This sounds incredibly powerful because it targets the
Speaker 1: database directly.
Speaker 2: It absolutely is powerful. SQL injection or SQL involves injecting
Speaker 2: malicious SEQL structured query language code into input fields on
Speaker 2: a web page like login forms, search boxes, even URL parameters.
Speaker 2: The goal is to manipulate the SQL queries that the
Speaker 2: web application sends to its back end database, essentially tricking
Speaker 2: the application into running the attacker's SQL code.
Speaker 1: And why is SQL considered so critical so powerful compared
Speaker 1: to some other web.
Speaker 2: Attacks because it gives the attacker a direct line to
Speaker 2: the database, and the database is usually where the crown
Speaker 2: jewels are kept user credentials, user names, hashed passwords, personal information,
Speaker 2: financial records, sensitive company data, everything. A successful sequel attack
Speaker 2: can allow an attacker to bypass authentication, entirely read sensitive
Speaker 2: data they shouldn't see, modify or delete data, and sometimes
Speaker 2: even execute operating system commands on the database server itself,
Speaker 2: leading to full server compromise. It cuts right to the core.
Speaker 1: How does a pintester even find out if a site
Speaker 1: is vulnerable? What's the first step?
Speaker 2: It often starts very simply, just trying to input special
Speaker 2: characters into web forms, especially the single quote, which is
Speaker 2: used to denote strings in SQL. If inputting a single
Speaker 2: quote causes the website to throw a weird error message,
Speaker 2: maybe revealing parts of in SQL query or database information,
Speaker 2: that's a huge red flag. It suggests the application isn't
Speaker 2: handling the input properly and is vulnerable. Once a potential
Speaker 2: vulnerability is found, attackers try injecting actual SQL code. Common
Speaker 2: payloads like or are one year one or or one
Speaker 2: one can sometimes bypass log informs entirely because one a
Speaker 2: U one is always true. If the input is in
Speaker 2: the URL HGPGT request. They need to remember to URL
Speaker 2: and code special characters like space becomes per twenty, single
Speaker 2: quote becomes per twenty seven, And they.
Speaker 1: Can actually pull data out of the database using these injections.
Speaker 1: How does that work?
Speaker 2: Yes, extracting data is a primary goal. Once they confirm
Speaker 2: a vulnerability, they use various techniques. They might use order
Speaker 2: by clauses, injecting order by one, order by two, et cetera,
Speaker 2: and watching when the page breaks to figure out how
Speaker 2: many columns the original query returns. Then they use union select.
Speaker 2: This lets them combine the results of the original query
Speaker 2: with the results of a new query they inject. Using
Speaker 2: union select, they can start a extracting information the database version,
Speaker 2: the current database, user names of other databases. Information schema
Speaker 2: is key here. It's a database about databases, table names,
Speaker 2: column names, and eventually dump the contents of sensitive tables
Speaker 2: like the users or accounts table containing usernames and passwords.
Speaker 2: In some database configurations, they might even be able to
Speaker 2: read files from the server using functions like load file
Speaker 2: it sets the road, or write files to the server
Speaker 2: using into out file if the database process has sufficient permissions.
Speaker 1: That sounds incredibly complex and manual. Is there an automated
Speaker 1: way to perform SQL injection attacks?
Speaker 2: Oh? Definitely, Manually exploiting SQL it can be tedious and complex.
Speaker 2: That's where school map comes in. Stormap is a fantastic
Speaker 2: open source penetration testing tool that completely automates the process
Speaker 2: of detecting and exploiting SQL injection vulnerabilities. You just pointed
Speaker 2: at a potentially vulnerable URL, and it does the rest.
Speaker 2: It can identify the database type myceql, Oracle, etc. Figure
Speaker 2: out the injection techniques, fetch data, dump entire databases or
Speaker 2: specific tables, access the underlying files, stem, and even try
Speaker 2: to execute operating system commands through the database connection. Practical
Speaker 2: commands are simple like sqollmap atch uhtpt dot test, dot com,
Speaker 2: school end, dot, php, dot id one, DBS to list databases,
Speaker 2: or dump dash you user's dashd web acdb to dump
Speaker 2: the user's table from the web ATPDB database. It makes
Speaker 2: complex attacks much easier.
Speaker 1: Okay, school map sounds powerful. So what is the best
Speaker 1: defense against SQL injection? What's the most crucial thing developers
Speaker 1: need to do.
Speaker 2: The single most important defense, hands down is using prepared statements,
Speaker 2: also often called parameterized queries. Think of it this way.
Speaker 2: Instead of building a SQL query by just sticking user
Speaker 2: input directly into the SQL string, you create the SQL
Speaker 2: query with placeholders like dot or dot user name. Then
Speaker 2: you separately provide the user's input values, and the database
Speaker 2: driver handles safely inserting those values into the placeholders. This
Speaker 2: fundamentally separates the SQL code logic from the data. The
Speaker 2: user's input is always treated as data, never is executable code,
Speaker 2: making injection possible for that query. It's the gold standard.
Speaker 2: Other important layers include using least privileged database accounts the
Speaker 2: Web Applications database users should only have the absolute minimum
Speaker 2: permissions needed to function, definitely not admin rights, using multiple
Speaker 2: dB users if you have multiple applications, using the same
Speaker 2: database server to keep them isolated, and again, deploying a
Speaker 2: Web application firewall WAF can catch many common SQL.
Speaker 1: Patterns prepared statements, got it And speaking of automated tools,
Speaker 1: OASPZ is another big one for web testing.
Speaker 2: Absolutely ZACE the z attack proxy is extremely popular. It's free,
Speaker 2: open source and maintained by OAS Open Web Application Security Project.
Speaker 2: It acts as a proxy between your browser and the website,
Speaker 2: and it can automatically scan the website for a wide
Speaker 2: range of vulnerabilities as you browse, or you can launch
Speaker 2: active scans. It finds things like exss skewqlay insecure configurations,
Speaker 2: information leaks, and it categorizes the findings by severity high, medium, low,
Speaker 2: often shown with red orange yellow flags. It gives detailed
Speaker 2: alerts and suggests remediation steps. Great tool for both beginners
Speaker 2: and experts.
Speaker 1: Okay, let's shift gears for our final deep dives mobile
Speaker 1: phone penetration testing.
Speaker 2: The number of mobile devices out there is just mind boggling.
Speaker 1: It really is staggering. They're talking billions and billions globally,
Speaker 1: something like fourteen billion now, heading towards maybe seventeen billion soon.
Speaker 1: And because we do so much on our phones, banking, communications,
Speaker 1: storing photos, accessing work data, mobile security has become this
Speaker 1: massive new frontline for cyber attacks. These devices are treasure
Speaker 1: troves of data.
Speaker 2: So what are the main ways attackers try to get
Speaker 2: into phones? The main attack factors? Well, there are several
Speaker 2: common vectors for mobile Physical access is one, if someone
Speaker 2: gets hold of your unlocked phone. Malware is huge. Malicious
Speaker 2: apps often disguised as games or utilities, downloaded from unofficial stores,
Speaker 2: or even sometimes sneaking into official ones. Network attacks exploiting
Speaker 2: insecure Wi Fi is just as relevant for phones as
Speaker 2: for laptops. Social engineering is very effective on mobile phishing, tearmishing,
Speaker 2: fake log imprompts, insecure applications themselves, apps that handle data poorly,
Speaker 2: don't encrypt traffic, store passwords insecurely, and of course vulnerabilities
Speaker 2: in the mobiles itself, though those are rarer for attackers
Speaker 2: to exploit widely without zero days. Often it still comes
Speaker 2: down to tricking the user, and if.
Speaker 1: An attacker does get in, what can they actually do?
Speaker 1: What are the outcomes?
Speaker 2: The consequences can be really severe. Data loss is a
Speaker 2: big one. Contact stolen private messages, read sensitive photos or
Speaker 2: documents exfiltrated. Attackers might use your phone's resources silently, using
Speaker 2: its processing power for crypto mining, or making it part
Speaker 2: of a botnet for dedas attacks. There's reputation loss if
Speaker 2: they hijack your social media or email accounts, and the
Speaker 2: worst case is often identity theft, grabbing enough personal information
Speaker 2: and credentials to impersonate you, open fraudulent accounts, et cetera.
Speaker 1: So is there a typical life cycle for a mobile attack?
Speaker 2: Yeah, it usually fallows a pattern. First, the vice infection.
Speaker 2: This often involves tricking the victim. For Android, that might
Speaker 2: mean downloading a malicious apka file from a third party source.
Speaker 2: For iOS, it's harder, often requiring physical access, exploiting a
Speaker 2: rare zero day, or maybe targeting jail broken devices. Second,
Speaker 2: backdoor installation. Once the malware is on the device, it
Speaker 2: often needs higher privileges. For Android, this might involve trying
Speaker 2: to gain root access. For iOS, the device is jailbroken,
Speaker 2: the malware has more freedom. Third data exultration. The malware
Speaker 2: or backdoor then communicates back to the attacker server, sending
Speaker 2: collected data, contacts, SMS messages, location data, photos, banking logins,
Speaker 2: whatever it was designed to steal.
Speaker 1: What about the official app stores Google Play, Apple App Store?
Speaker 1: Are they generally safe or do malicious apps slip through?
Speaker 2: Generally? Yes, the official stores Google Play Store, Apple App
Speaker 2: Store are much safer than the alternatives. They have vetting processes,
Speaker 2: automated scanning, and manual reviews designed to catch malware. However,
Speaker 2: they're not perfect. Cleverly disguised malware does occasionally slip through
Speaker 2: the cracks. The real danger often comes from third party
Speaker 2: app stores or just downloading APK files directly from websites.
Speaker 2: Attackers love to take legitimate apps, inject malware into them, repackaging,
Speaker 2: and then offer them for free. On these alternative stores,
Speaker 2: users download the trojanized version thinking they're getting a deal,
Speaker 2: but they're actually installing spyware.
Speaker 1: Right stick to official stores where possible. Okay, let's look
Speaker 1: at androids specifically. What are the security basics of the
Speaker 1: Android OS.
Speaker 2: Androids built on Linux, and a key security concept is
Speaker 2: the sandbox. Every app runs in its own isolated environment,
Speaker 2: its own sandbox. Each app gets a unique user id
Speaker 2: ued and the Linux kernel enforces separation. An app basically
Speaker 2: can't directly access another app's private data or interfere with
Speaker 2: the core system unless specific permissions are granted. Those permissions
Speaker 2: are crucial things like accessing contacts, location, camera, Internet. They're
Speaker 2: defined in the app's Android manifest dotxml file and the
Speaker 2: user typically has to approve them. Android also has built
Speaker 2: in features like Google play Protect, which scans apps for
Speaker 2: malware and by default it blocked installation from unknown sources
Speaker 2: outside the Play Store, though users can disable that protection.
Speaker 2: For authentication, you have screen locks, pattern pian password biometrics,
Speaker 2: and importantly, offline brute force attacks against the lock screen
Speaker 2: are generally infeasible too many failed attempts conrigger a data way.
Speaker 2: Plus there's the fine my device feature for remote location
Speaker 2: and wiping.
Speaker 1: And how does Apple's iOS compare the walled garden approach?
Speaker 2: Yeah?
Speaker 1: What are its security fundamentals?
Speaker 2: iOS is known for its tight control. It's a proprietary
Speaker 2: OS and apps primarily come from the heavily vetted app store.
Speaker 2: Installing unofficial apps via IPA files is possible, but more restricted,
Speaker 2: often requiring developer accounts or enterprise certificates. The iOS sandbox
Speaker 2: is generally considered even stricter than androids by default. Jail
Speaker 2: braking is the process of removing these restrictions on iOS,
Speaker 2: similar to rooting on Android. It allows installing third party
Speaker 2: apps and gives root access, but it also significantly weakened security,
Speaker 2: voids the warranty and makes the device much more vulnerable
Speaker 2: to malware. For authentication, iosu us as passcodes for six
Speaker 2: digits face ID or touch ID. The passcode is cryptographically
Speaker 2: tied to the device's unique device id UID to protect
Speaker 2: data encryption keys like Android ten, failed passcode attempts usually
Speaker 2: trigger a data wipe, and in corporate environments, mobile device
Speaker 2: management MDM software is widely used to enforce security policies,
Speaker 2: distribute apps, and remotely manage iPhones and iPads.
Speaker 1: Okay, so both have sandboxes and protections. When pen testing
Speaker 1: mobile apps? What are the key risks testers look for?
Speaker 1: You mentioned in O Waspy Mobile top ten. Yes.
Speaker 2: Similar to the web version, the O was bobol Top
Speaker 2: ten lists the most critical security risks specifically for mobile applications.
Speaker 2: Instead of just listening them all, let's highlight one that's
Speaker 2: really common and dangerous. Insecure data storage. This happens when
Speaker 2: an app stores sensitive information, maybe your logging credentials, session tokens,
Speaker 2: personal details, even credit card numbers, directly on the phone's
Speaker 2: storage without proper encryption or protection. It might store it
Speaker 2: in plain text files, easily accessible databases, or preference file.
Speaker 2: If an attacker gains even limited access to the device's
Speaker 2: file system, maybe via malware or physical access, or even
Speaker 2: just another robe app, if permissions are weak, they can
Speaker 2: often just read this stored data directly, huge risk. Other
Speaker 2: major risks include things like improper platform usage, misusing OS features,
Speaker 2: insecure communication, not using HGTPS properly, code tampering, and reverse engineering.
Speaker 1: The app into your data storage. Sounds bad, Let's look
Speaker 1: at some practical Android hacking examples from the book.
Speaker 2: How do you set up a test environment for testing
Speaker 2: Android apps? You typically use Android's studio, which includes emulators
Speaker 2: virtual Android devices. You also need the Android SDK Software
Speaker 2: Development Kit, which contains essential tools like the Android debug
Speaker 2: Bridge ADB, ADB is the crucial command line tool for
Speaker 2: communicating with both emulators and physical Android devices connected via
Speaker 2: USB with debugging enabled. Common ADB commands include ad devices
Speaker 2: to see connected device emulators, ad shell to get a
Speaker 2: command line shell directly on the device, adbed pull to
Speaker 2: download files from the phone to your computer, and add
Speaker 2: push to upload files to the phone. Pen Testers often
Speaker 2: install deliberately vulnerable apps like Diva, Damn insecure vulnerable application
Speaker 2: onto an emulator or test device to practice finding and
Speaker 2: exploiting common flaws in a safe environment, and how might.
Speaker 1: An attacker actually grab credentials using ADB leveraging that insecure
Speaker 1: storage issue right.
Speaker 2: This is where insecure storage becomes a real problem. If
Speaker 2: an app foolishly stores, say, the user's log in details
Speaker 2: in its shared preferences file, a common way Android apps
Speaker 2: store simple settings in plain text. An attacker with ADB
Speaker 2: access ABS shell can often navigate to the app's data
Speaker 2: directory data Data app package, NAM shared prefs and just
Speaker 2: use cat to print the contents of the XML preferences file.
Speaker 2: If the username and password are in there unencrypted, they're
Speaker 2: immediately exposed like catjackcar dot sem dot, Diva preferences dot
Speaker 2: XML might just split up a log in details super simple,
Speaker 2: super bad. And mobile apps can have SQL injection flaws too.
Speaker 2: How does that work on a phone?
Speaker 1: Yeah? Absolutely. Many Android apps use local Squad databases to
Speaker 1: store data. The app takes user input, like from a
Speaker 1: search bar, and puts it dirictly into a SQL query
Speaker 1: for that local database without proper sanitization SQL as possible.
Speaker 2: An attacker might use ad blogcat to watch the apps
Speaker 2: logs and see the SQL queries being made in real time.
Speaker 2: Then they could try injecting classic sequel payloads like R
Speaker 2: one one into an input field within the app. If
Speaker 2: the app is vulnerable, this might trick the query into
Speaker 2: returning all records from a table, potentially revealing all stored
Speaker 2: user names, passwords, credit card details, et cetera, right within
Speaker 2: the app's interface. Alternatively, with ADB access, you can often
Speaker 2: just add pull the entire squide database file eg. Squad
Speaker 2: dot dB from the app's data directory onto your computer.
Speaker 2: Then you can open it with a standard squite three
Speaker 2: tool and browse all the tables and data offline at
Speaker 2: your leisure.
Speaker 1: Wow. Okay, so pulling the whole database and what about
Speaker 1: hacking a real Android phone not just an emulator getting
Speaker 1: that remote control.
Speaker 2: That's the more realistic attack scenario. It usually involves creating
Speaker 2: a malicious APK file. First, you'd use a tool like
Speaker 2: msfinom part of metasploit, to generate an APK payload, often
Speaker 2: a reverse blate payload, which will connect back to the
Speaker 2: t attacker. You might even try to bin in this
Speaker 2: payload to a legitimate looking app to disguise it. Then
Speaker 2: you need a way for the victim's phone to connect
Speaker 2: back to you, since you're likely behind routers and firewalls.
Speaker 2: You typically set up a cloud server like a cheap
Speaker 2: Google Cloud or AWS instance running a Buntu. You'd host
Speaker 2: the malicious ABK on a web server on that cloud
Speaker 2: instance for the victim to download, and you'd run your
Speaker 2: metasplit listener on that same cloud server, waiting for the
Speaker 2: connection on its public IP address. The hardest part is
Speaker 2: social engineering convincing the victim to download and install that APK.
Speaker 2: They'd likely have to disable the install Unknown Apps security
Speaker 2: setting on their phone first, which is a hurdle, but
Speaker 2: if they do install it and run it, the payload
Speaker 2: connects back to your listener, giving you a interpreter session.
Speaker 2: From there, you have significant control SEMPS info check root,
Speaker 2: see if the phone is rooted, geolocate, get GPS coordinated
Speaker 2: it's dump contacts, dump SEMs, take pictures with the camera,
Speaker 2: record audio, lots of possibilities. Tools like evil droid are
Speaker 2: also popular for generating these malicious APKs, sometimes offering more
Speaker 2: evasion features or easier ways to inject backdoors into existing
Speaker 2: legitimate APKs.
Speaker 1: Okay, so connecting all this back, We've talked a lot
Speaker 1: about labs and testing. What's the main practical difference when
Speaker 1: trying to gain access in a real network like out
Speaker 1: in the wild compared to a controlled lab environment.
Speaker 2: The biggest practical difference, especially when you need the victim
Speaker 2: machine to connect back to you, like with reverse shells,
Speaker 2: interpreter listeners b fooks, is dealing with network address translation,
Speaker 2: net and firewalls. In a lab, your attacker machine and
Speaker 2: victim machine might be on the same simple network easy
Speaker 2: In the real world, your attacker machine, say your Collie
Speaker 2: box at home or on that cloud server, is behind
Speaker 2: a router. The victim is somewhere else, also behind a router.
Speaker 2: For that victim machine to connect back to your listener,
Speaker 2: you need to configure port forwarding on your router or
Speaker 2: the cloud server's firewall. I need to tell your router, hey,
Speaker 2: any incoming connection attempt on port, say forty four four
Speaker 2: to four should be forwarded to the internal IP address
Speaker 2: of my Collie machine. Without port forwarding, your router would
Speaker 2: just block those incoming connection attempts and your listener would
Speaker 2: never receive the connection from the victim. It's a crucial
Speaker 2: step for making reverse connections work across the Internet.
Speaker 1: Port forwarding right, That makes sense. What we have certainly
Speaker 1: covered a lot of ground today, an incredible journey through
Speaker 1: the intricate world of penetration testing. We went from cracking
Speaker 1: Wi Fi doing those sneaky man in the middle attacks
Speaker 1: all the way to exploiting servers clients using social engineering
Speaker 1: and digging into web and mobile security.
Speaker 2: Yeah, it's a broad field, but hopefully by understanding these techniques,
Speaker 2: you're not just learning how the bad guys operate. You're
Speaker 2: really gaining that critical insight you need to build better
Speaker 2: defenses to spot weaknesses and the systems you use or manage.
Speaker 2: It's about turning that curiosity about how things break into
Speaker 2: a real capability to make things strong. That's the power here.
Speaker 1: Absolutely, So the final question for you listening in this
Speaker 1: world is just increasingly connected, relying on all these systems,
Speaker 1: What hidden vulnerabilities might be lurking in the digital services
Speaker 1: use every single day, and maybe, just maybe, how could
Speaker 1: you potentially contribute ethically, of course, to finding them and
Speaker 1: making our shared digital world just a little bit safer.
Speaker 2: Keep asking questions, keep learning, keep exploring, and just remember
Speaker 2: that real, true security, it starts with really understanding how
Speaker 2: things work and how they can be broken