Speaker 1: Welcome to the Deep Dive, the show where we cut
Speaker 1: through the noise to get you truly well informed on
Speaker 1: fascinating topics.
Speaker 2: Great to be digging into another one.
Speaker 1: So, you know, in our increasingly digital world, there's this constant,
Speaker 1: often hidden battle being waged. It's not just against external threats,
Speaker 1: but right within the very systems we rely on every
Speaker 1: single day. Right, Think of it like well, a digital
Speaker 1: fortress and understanding its weaknesses, you know, the chinks in
Speaker 1: the armor is just as crucial as actually building the
Speaker 1: walls themselves.
Speaker 2: Absolutely, for a long long time, the security mindset was
Speaker 2: almost entirely focused just on network perimeters, right, the outer
Speaker 2: walls exactly. Companies poured money into firewalls, network defenses, which,
Speaker 2: honestly it kind of fostered a full sense of security
Speaker 2: in some ways. How so well, because then our reliance
Speaker 2: on web technologies just exploded, you know, public websites, internal apps,
Speaker 2: everything moved online.
Speaker 1: Ah okay, And that's where the whole game changed, isn't it.
Speaker 2: Precisely because suddenly web applications became just as vulnerable to attack,
Speaker 2: maybe even more so than those traditional networks and operating systems.
Speaker 1: Yeah, we've all seen the headlines.
Speaker 2: Unfortunately, absolutely recent years, I mean, we've seen just spectacular
Speaker 2: data leaks, breaches affecting millions of records.
Speaker 1: Yeah, everything from credit cards, health histories.
Speaker 2: Social security numbers, you name it. And so often these
Speaker 2: really devastating attacks they didn't start with breaking through the.
Speaker 1: Network firewall, no where.
Speaker 2: Then they often started with a vulnerability or maybe a
Speaker 2: simple design flawed directly within a web application itself.
Speaker 1: Okay, so the industry had to react to that. It did.
Speaker 2: We saw this rapid rise in defensive tech, things like
Speaker 2: web application firewalls wfs and run time applications self protection
Speaker 2: are asp plus you know, sophisticated web vulnerability scanners, source
Speaker 2: code scanners became standard. Companies finally started realizing the immense
Speaker 2: value of testing applications before they go.
Speaker 1: Live, which leads us perfectly in today's deep dive topic
Speaker 1: penetration testing exactly. Think of this as your shortcut to
Speaker 1: understanding how ethical hackers, well if they act like controlled adversaries, right.
Speaker 2: Mm hmm, meticulously identifying and exploiting vulnerabilities, especially in those
Speaker 2: really critical web applications.
Speaker 1: So today we're going to unpack the skills, the surprising facts,
Speaker 1: the powerful tools that help strengthen our digital defenses. And
Speaker 1: we're drawing insights from a really comprehensive source called improving
Speaker 1: your penetration testing Skills. Yeah, it's a great resource, So
Speaker 1: get ready to see the world of digital security from
Speaker 1: the attacker's perspective.
Speaker 2: But you know, for good, that's the key. At its core,
Speaker 2: penetration testing is well, it's the art of making a
Speaker 2: computer system or an application do things it was never
Speaker 2: designed to do.
Speaker 1: But ethically.
Speaker 2: But ethically, yes, the goal is always to discover flaws
Speaker 2: before the malicious actors do and then provide you know,
Speaker 2: actionable advice on how to fix them.
Speaker 1: So it helps everyone really, company, hospitals.
Speaker 2: Schools, government agencies, helping them secure their vital applications and
Speaker 2: of course their data.
Speaker 1: So it's like a controlled strategic attack to find the
Speaker 1: weak spots before the actual bad guys do. How do
Speaker 1: these engagements usually work? Does the testing team always get
Speaker 1: all the info upfront?
Speaker 2: Well, it varies quite a bit, actually depends on the
Speaker 2: type of engagement you've got. Black box testing.
Speaker 1: Okay, black box.
Speaker 2: This simulates an external attacker who's completely uninformed. The pen
Speaker 2: tester starts with well zero knowledge, just like a real
Speaker 2: world hacker might trying to map the network discover defenses
Speaker 2: all from scratch, but you know, for internal applications, this
Speaker 2: might sometimes be a less efficient way to go. Why
Speaker 2: is that because a real attacker might easily gather public info,
Speaker 2: or frankly, they might be a disgruntled insider who already
Speaker 2: knows a lot, So the black box test might miss
Speaker 2: things an insider threat wouldn't.
Speaker 1: Okay, So it's like trying to break into a house
Speaker 1: without knowing where the doors or windows are, versus say,
Speaker 1: having some basic.
Speaker 2: Blueprints exactly that. Then on the other end of the
Speaker 2: spectrum you have white box testing total opposite, I'm guessing
Speaker 2: complete opposite. The testing team gets full information, source code, architecture, diagrams,
Speaker 2: you name it. It's extremely thorough. And in the middle
Speaker 2: that's grey box testing, an intermediate approach. Some info is provided,
Speaker 2: but not everything. This often simulates, say an insider threat,
Speaker 2: or maybe what someone could do with a compromised user account.
Speaker 1: What's really interesting, though, is that even with these structured approaches,
Speaker 1: pen testing still has limits. Right, It's not like a
Speaker 1: magic wand.
Speaker 2: You wave, oh, absolutely not. That's a crucial point to understand. First,
Speaker 2: there's the limitation of skills, meaning well, it's incredibly tough
Speaker 2: to find one person who's equally skilled across all the
Speaker 2: major areas network system and web application Penetration testing expertise
Speaker 2: is often really specialized, right.
Speaker 1: Someone might be brilliant with apatche servers but know nothing
Speaker 1: about ISO.
Speaker 2: For example, exactly and figuring out how a seemingly low
Speaker 2: risk vulnerability could actually so is a high threat to
Speaker 2: a specific system that often comes only with you know,
Speaker 2: deep experience and I bet.
Speaker 1: Time is always a massive factor, especially compared to a
Speaker 1: real attacker.
Speaker 2: Always. Penetration testing is almost always a short, pre defined project.
Speaker 2: Testers have a limited window, maybe a week or two
Speaker 2: to find vulnerabilities and produce results.
Speaker 1: Whereas a malicious attacker.
Speaker 2: They have unlimited time days, weeks, months, plus. The pen
Speaker 2: tester has the added burden of writing these incredibly detailed,
Speaker 2: defensible reports with screenshots and explanations. An attacker doesn't worry
Speaker 2: about that.
Speaker 1: So they can't just throw everything they have at a target,
Speaker 1: even if they technically.
Speaker 2: Could not always know in really secure environments, standard frameworks
Speaker 2: or automated tools might just bounce off. They might be.
Speaker 1: Useless, So they have to get creative.
Speaker 2: Yeah, forcing the team to create custom exploits or manually
Speaker 2: write scripts to test specific things, and that's incredibly time consuming.
Speaker 2: It directly impacts the project's budget and timeline. Okay, Another
Speaker 2: common limitation is deliberately avoiding denial of service or DOS attacks.
Speaker 1: Why avoid those seems like something you'd want to test.
Speaker 2: Well, many testers intentionally avoid them because they don't want
Speaker 2: to inadvertently cause client downtime. It's a business risk.
Speaker 1: Ah, makes sense.
Speaker 2: But the downside is this inadvertently leaves systems potentially open
Speaker 2: to well script kitties, less sophisticated attackers who just want
Speaker 2: notoriety by taking systems offline. So it's really vital to
Speaker 2: educate clients upfront about the pros and cons of doing
Speaker 2: this kinds of test.
Speaker 1: That's a really good point. And what about the tools themselves?
Speaker 1: Are they always reliable?
Speaker 2: That's another limitation The tools used, No single tool, free
Speaker 2: or commercial, is perfect. They all have blind spots, so.
Speaker 1: The tester needs to know more than just how to
Speaker 1: run the tool exactly.
Speaker 2: The testing team needs to be knowledgeable enough to adapt,
Speaker 2: understand the tool's limitations, and find alternatives when you know
Speaker 2: its features just aren't cutting it for a specific scenario.
Speaker 1: All this makes me think about where a pen tester
Speaker 1: actually practice this stuff. You can't just go poking around
Speaker 1: random websites on.
Speaker 2: The internet, right, illegal? You're absolutely right. It is illegal
Speaker 2: in most countries to scan, test, or exploit vulnerabilities on
Speaker 2: the Internet without explicit written authorization from the owner.
Speaker 1: So how do they learn?
Speaker 2: That's why having a controlled, owned and isolated lab environment
Speaker 2: is just paramount, absolutely essential. It's the only place you
Speaker 2: can freely practice and develop your skills without any legal worries.
Speaker 1: And there are specific vulnerable environments for that.
Speaker 2: Yes, things like oh washbroken web applications or hackers on
Speaker 2: which we'll definitely talk more about. They're perfect for this
Speaker 2: kind of safe practice.
Speaker 1: Okay, so setting up this ethical hacking lab, what's the
Speaker 1: go to operating system? I always hear Klie Linux.
Speaker 2: Ah, Collie Linux. Yes, it really is kind of the
Speaker 2: ethical hackers dream toolkit.
Speaker 1: Why is that? What's the big deal?
Speaker 2: Its main value is just how much it simplifies the setup.
Speaker 2: It comes with pretty much whch all the major hacking
Speaker 2: tools pre installed along with all their dependencies. Oh nice,
Speaker 2: So it means you can focus immediately on learning and
Speaker 2: actually doing the attacks, rather than wasting hours just installing
Speaker 2: and configuring individual tools and offensive security. The folks behind
Speaker 2: Collie they keep these tools frequently updated, so you're always
Speaker 2: working with the latest stuff.
Speaker 1: So it's like a constantly updated, pre assembled workshop for
Speaker 1: digital security. That's incredibly useful.
Speaker 2: It really is, and it's remarkably versatile too. Collie runs
Speaker 2: on various hardware Google, Chromebooks, Raspberry.
Speaker 1: Pie, Raspberry Pie Wow.
Speaker 2: There's even net Hunter, which is a version specifically designed
Speaker 2: for mobile devices.
Speaker 1: Now, a lot of people, myself included, tend to use
Speaker 1: virtualization running it in a VM. What are the pros
Speaker 1: and cons of that versus installing Collie directly on say,
Speaker 1: a dedicated laptop. What's the real trade off there?
Speaker 2: Virtualization is definitely an attractive option. It's cost effective, flexible,
Speaker 2: You can easily clone virtual machines if you need multiple
Speaker 2: testing copies, and the revert to snapshot feature is invaluable.
Speaker 2: If you mess up your testing machine break something poof,
Speaker 2: you just restore clean slate. Instantly modifying resources like RAM
Speaker 2: or CPU is also super easy.
Speaker 1: Okay, sounds great. What's the catch?
Speaker 2: The major drawback comes with processor intensive tasks think password cracking.
Speaker 2: Those tasks are significantly slower because of the virtualization overhead,
Speaker 2: and you simply can't fully leverage a dedicated GPU a
Speaker 2: graphics card for that kind of raw processing power inside
Speaker 2: a standard VM setup.
Speaker 1: So for serious number crunching, physical hardware still wins. But
Speaker 1: for most day to day practice and exploration, virtualization is
Speaker 1: probably fine.
Speaker 2: Absolutely for most tasks it's the way to go.
Speaker 1: Okay, So what are some of the essential tools packed
Speaker 1: into Collie that a pentester would use regularly?
Speaker 2: Right, let's touch on a few key categories. For content
Speaker 2: management systems, you know CMSs, like WordPress or joom Law,
Speaker 2: there are specialized scanners like what well, wp scan is
Speaker 2: a really fast WordPress vulnerability scanner. It's surprising how often
Speaker 2: organizations just leave default plugins and themes exposed. WP scan
Speaker 2: finds those instantly.
Speaker 1: Broadcasting their weak points essentially.
Speaker 2: Pretty much similarly, jim scan does the same thing for gymlesites.
Speaker 1: Got it? What about finding hidden files and directories? That
Speaker 1: seems like a really critical first step for.
Speaker 2: An attacker, definitely for that. Dirb is a command line tool.
Speaker 2: It uses dictionary files to discover hidden files and directories.
Speaker 2: Maybe old admin panels, backup files, things that shouldn't.
Speaker 1: Be accessible in Nikto, I've heard that name.
Speaker 2: Nikto is a longtime favorite. It's a really feature rich
Speaker 2: web server scanner. Checks for thousands of outdated software components,
Speaker 2: common configuration errors. It's like giving the web server a
Speaker 2: thorough digital health check.
Speaker 1: Okay, And for broader network scanning, maybe looking beyond just
Speaker 1: the web applications themselves, for.
Speaker 2: That network wide view. OpenVAS the Open Vulnerability Assessment Scanner
Speaker 2: is a powerful tool in Collinge.
Speaker 1: Right that used to be or part of it.
Speaker 2: Yeah, it's a free fork of what was once nessus.
Speaker 2: It's excellent for identifying a wide range of network side vulnerabilities,
Speaker 2: giving you that bigger picture of potential entry points. And
Speaker 2: these are just a few examples. The Colleague toolkit is vast.
Speaker 1: So speaking of practice, you mentioned those vulnerable environments for
Speaker 1: safe learning. Which ones are commonly used for training new pendesters? Yeah?
Speaker 2: Absolutely. The a wasp p Broken Web Applications Project or
Speaker 2: BWA is really crucial. It's a collection of intentionally vulnerable
Speaker 2: web applications all packaged up as a single virtual machine.
Speaker 2: Easy to set up them super easy, and it's perfect
Speaker 2: for hands on learning. It includes apps like Wacko, Pico
Speaker 2: and the Bodget Store, which simulate real world apps but
Speaker 2: with less obvious flaws, so they really force you to
Speaker 2: think like an attacker.
Speaker 1: Okay, any others?
Speaker 2: Another excellent one is hackazon. It's from Rapid seven, the
Speaker 2: folks who make metasploit.
Speaker 1: Okay.
Speaker 2: It simulates a modern online store using technologies like ajax
Speaker 2: and web services, and it has several security problems deliberately
Speaker 2: built right in great practice ground.
Speaker 1: So you've got your lab set up, your Collie machine ready,
Speaker 1: a safe environment to practice in. What's the very first
Speaker 1: thing an ethical hacker does when they start looking at
Speaker 1: a target.
Speaker 2: That brings us squarely into the art of gathering intel.
Speaker 2: We often call it reconnaissance or recon Now, while a
Speaker 2: malicious attacker might be chaotic, maybe opportunistic, a professional penetration
Speaker 2: tester always follows a structured approach.
Speaker 1: Right, there's a method, definitely.
Speaker 2: The typical sequence is meticulous information gathering first, then identification
Speaker 2: of vulnerabilities, often through scanning, and then finally exploitation. This
Speaker 2: structured way helps you find as many bugs as you
Speaker 2: can and importantly prepares you to write those valuable, comprehensive
Speaker 2: reports for the client.
Speaker 1: So reconnaissance is the foundation. What kind of information are
Speaker 1: they trying to dig up in this phase? What are
Speaker 1: the goals?
Speaker 2: The aims are pretty broad, actually identifying it addresses, domains,
Speaker 2: subdomains using tools like whois and DNS lookups, okay, gathering
Speaker 2: public information from regular search engines like Google and bing,
Speaker 2: but also specialized ones like Showdowan or even archives like
Speaker 2: the Internet Archive.
Speaker 1: Looking for clues anywhere they can find.
Speaker 2: Them exactly, Identifying key personnel maybe through LinkedIn using tools
Speaker 2: like Maltago. Even figuring out the physical location of servers
Speaker 2: using GOIP databases can be part of it.
Speaker 1: Gay, Let's unpack some of that you mentioned who is,
Speaker 1: How does looking up domain records actually give an attacker
Speaker 1: and edge seems pretty basic?
Speaker 2: Who is records are public databases. They reveal domain owner details, names, addresses,
Speaker 2: phone numbers, emails, the DNS servers being used. An attacker
Speaker 2: can use this info for highly targeted social engineering attacks
Speaker 2: or even for war driving driving around the registered address
Speaker 2: looking for unsecured Wi Fi.
Speaker 1: Wow.
Speaker 2: And a really striking real world example was the New
Speaker 2: York Times attack back in twenty thirteen. Their DNS records
Speaker 2: were altered after a successful phishing attack against their domain reseller.
Speaker 2: It shows how powerful this seemingly mundane data can be.
Speaker 1: It really drives it home. Okay, what about DNS enumeration.
Speaker 1: How do they leverage that?
Speaker 2: Well? DNS servers often use something called zone transfer to
Speaker 2: sync their databases. Okay, if that's misconfigured, which happens, it
Speaker 2: can expose a complete list of IP host name pairs
Speaker 2: within a network, basically gives the attacker a map of
Speaker 2: the internal network structure.
Speaker 1: How do they try that?
Speaker 2: Tools like dig can be used to attempt a zone transfer.
Speaker 2: Other tools like dnascinum automate finding basic DNS records MX
Speaker 2: for mail, NS for name servers, A records for IPS,
Speaker 2: and can perform reverse lookups even brute force subdomains to
Speaker 2: reveal more of the target's infrastructure.
Speaker 1: So they're using search engines too, but not just for
Speaker 1: finding web pages, right, They're digging deeper exactly.
Speaker 2: General search engines like Google, Bing, Duck, dot coo. They
Speaker 2: allow these advanced search filters. People call them Google dorks.
Speaker 1: Google dorks. Yeah.
Speaker 2: They let an attacker find specific file types, maybe error
Speaker 2: messages containing sensitive info or specific text in URLs that
Speaker 2: might reveal misconfigurations. Offensive Security actually maintains a public Google
Speaker 2: hacking database full of these techniques.
Speaker 1: Okay, but then there's Showdan that sounds completely different, almost
Speaker 1: like sci fi.
Speaker 2: Showdan really is a different kind of search engine. It
Speaker 2: doesn't look for web content. It searches for devices connected
Speaker 2: to the Internet, devices like what like everything, industrial control systems,
Speaker 2: running power grids, CCTV cameras, baby monitors, routers, servers, you
Speaker 2: name it. And what's truly surprising, maybe shocking, is the
Speaker 2: sheer volume of unsecured devices it finds, often left with
Speaker 2: default passwords. It's like finding the digital blueprint of a city,
Speaker 2: including all its unlocked back doors, with just a search query.
Speaker 1: That's kind of terrifying. Are there tools that help automate
Speaker 1: gathering info from all these different sources? Yeah.
Speaker 2: The Harvester is a Collie tool that acts as a rapper.
Speaker 2: It queries various search engines to pull together emails, subdomains,
Speaker 2: virtual hosts, open ports related to a target, sort of
Speaker 2: aggregator exactly. And another powerful frame work is recon. It
Speaker 2: consolidates lots of information gathering modules like it can look
Speaker 2: up multiple domains hosted on a single SSL certificate or
Speaker 2: enumerate LinkedIn contacts associated with a target company.
Speaker 1: Okay, so once they'd gathered all this initial intelligence, the
Speaker 1: next phase is usually scanning, right actively probing the target
Speaker 1: to see what's actually running and where the potential doors are. Correct.
Speaker 2: The scanning phase is about identifying the operating system, the
Speaker 2: web server version, the underlying infrastructure, specific applications.
Speaker 1: Running, starting with open ports.
Speaker 2: Usually yes, finding open ports beyond the standard eighty for
Speaker 2: HTTP and four forty three for hdtps because other services
Speaker 2: might be exposed.
Speaker 1: And for port scanning, the most famous tool is probably
Speaker 1: end map.
Speaker 2: It's legendary enmap network map er. Yes, it's absolutely the
Speaker 2: most widely known port scanner and a cornerstone of reconnaissance
Speaker 2: and scanning. It's incredibly effective at finding open TCP and
Speaker 2: UDP ports, and it's constantly updated. By default, it just
Speaker 2: checks the top one thousand most common ports to speed
Speaker 2: things up.
Speaker 1: How does it actually figure out if a port is open?
Speaker 1: Are there different ways it connects? Maybe some sneakier than others.
Speaker 2: Yeah, there are different scan types. The most straightforward is
Speaker 2: the TCP connect scan. Using the NZST flag, it performs
Speaker 2: a full three way TCP handshake.
Speaker 1: Like a normal connection exactly.
Speaker 2: It's accurate, but it's also more likely to be logged
Speaker 2: at the target machine and slower.
Speaker 1: Okay, what's the stealthier option.
Speaker 2: That's the syn scan using SSS, often called a half
Speaker 2: open scan. It starts the handshake but does not complete
Speaker 2: the handshake.
Speaker 1: Ah, so it doesn't fully connect right.
Speaker 2: This makes it less likely to be logged by basic firewalls,
Speaker 2: but those initial syn packets can still definitely alert more
Speaker 2: advanced intrusion detection or prevention systems in IPS or IDs.
Speaker 1: And you mentioned saving results before, Why is that so
Speaker 1: critical for a pent tester?
Speaker 2: Oh, in a pentest, saving results is absolutely vital for organization,
Speaker 2: for building that final report and honestly as a backup
Speaker 2: if something goes wrong or a scan gets interrupted. And
Speaker 2: map lets use save results in different formats XML its
Speaker 2: own format, agrippable text format so you can easily parse
Speaker 2: and reuse that data later.
Speaker 1: So beyond just finding open ports, they're profiling the whole
Speaker 1: server setup. What kind of details that they're looking for?
Speaker 2: Then, yeah, exactly. Once you know the OS and the
Speaker 2: open ports, the next step is identifying the exact applications
Speaker 2: running is it apatche icojinc Serving web pages what web
Speaker 2: application frameworks are they using, PHP, dot Net, Java? What
Speaker 2: databases are behind it? Are there load balancers involved? Getting
Speaker 2: this level of detail is critical for picking the right
Speaker 2: potential exploits later on.
Speaker 1: How do they deal with situations where maybe multiple websites
Speaker 1: are sharing the same server. That seems like it could
Speaker 1: be confusing.
Speaker 2: Yeah, that's common. Many websites use name based virtual hosting,
Speaker 2: sharing one physical server and IP address. They're distinguished by
Speaker 2: the host header in the HTTP request that tells the
Speaker 2: server which specific site you're trying to reach.
Speaker 1: So how do they figure out what else is on
Speaker 1: that server?
Speaker 2: There are online tools like HTTP dot ipnables is one
Speaker 2: example that can help identify other websites hosted on the
Speaker 2: same IP. It helps reveal more of a target's overall
Speaker 2: digital footprint.
Speaker 1: And load balancers you mentioned them? Can those sometimes give
Speaker 1: away useful information too?
Speaker 2: They absolutely can. High traffic sites use load balancers to
Speaker 2: distribute requests and keep things available. Some cookie based load
Speaker 2: balancers put a cookie in your browser to keep you
Speaker 2: stuck to one specific back end server. Okay, Sometimes these
Speaker 2: cookies accidentally reveal critical server details, maybe encoded pool names
Speaker 2: or even internal IP addresses and ports of the back
Speaker 2: end servers things they really should not be doing. It's
Speaker 2: an often overlooked reconnaissance.
Speaker 1: Source fascinating little leaks of information. So what about figuring
Speaker 1: out the actual web application frameworks being used? Is that
Speaker 1: just guesswork? Oh?
Speaker 2: No, not at all. There are several clues pen testers
Speaker 2: look for. HTTP headers like the server header or maybe
Speaker 2: an xass net version header can directly reveal the tech stack. Okay,
Speaker 2: custom cookie set by frameworks like asp not netw or
Speaker 2: JSESSIOND for Java apps can also be giveaways. Even seemingly
Speaker 2: harmless comments left in the HTML source code can sometimes
Speaker 2: contain hints about the framework or libraries being used.
Speaker 1: And for automating the identification of these technologies, is there
Speaker 1: a quick Collie tool for that? What?
Speaker 2: Web scanner in Collie is excellent for this. It has
Speaker 2: over nine hundred plug ins to identify all sorts of
Speaker 2: web technologies, CMS platforms, analytics packages, javscript libraries, server versions.
Speaker 2: It gives you a quick, high level overview of the
Speaker 2: tech stact.
Speaker 1: Okay, so they've profiled the server, the frameworks. Now they
Speaker 1: start actively looking for misconfigurations and specific vulnerabilities.
Speaker 2: Yes, that's the next logical step analyzing the software and
Speaker 2: its configuration. Default settings are often a gold mine for vulnerabilities.
Speaker 2: Scanning tools help by crawling the entire website looking for
Speaker 2: interesting files, folders, configuration settings that might point to a weakness.
Speaker 1: How do they check things like what HTTP methods of
Speaker 1: server supports? Like can it accept a delete request when
Speaker 1: it really should?
Speaker 2: They can use tools like netcat with the options method
Speaker 2: to directly ask the server what methods it supports. Nmap
Speaker 2: can do this too. Beyond that, Metasplait has some really
Speaker 2: useful auxiliary modules like darlisting checks if directory browsing is enabled.
Speaker 2: Der Scanner looks for interesting directories or inm wayback queries
Speaker 2: the Internet archive for old regions of pages that might
Speaker 2: contain now on linked content or comments. These can reveal
Speaker 2: forgotten dev folders or old vulnerable scripts.
Speaker 1: Okay, let's shift focus slightly to HTTPS configuration obviously critical
Speaker 1: for protecting sensitive data.
Speaker 2: And transit absolutely critical. HTTP started as clear text right
Speaker 2: everything sent and ENCRYPTEDHGTPS HTTP over SSLTLS adds that encrypted channel. Now,
Speaker 2: technically SSL is deprecated and TLS currently TLS one point
Speaker 2: two or one point three is the standard, but many
Speaker 2: sites still support older weaker versions for backward compatibility, which
Speaker 2: can be a problem.
Speaker 1: And TLS provides that CIA triad right confidentiality.
Speaker 2: Confidentiality, integrity, and availability, yes, the core pillars of infosect.
Speaker 2: It also provides non repudiation through TLS certificates signed by
Speaker 2: certificate authorities or CAAs, meaning you can generally trust the
Speaker 2: identity of the survey you're talking to and they can't
Speaker 2: easily deny the communication happen. It builds trust.
Speaker 1: But I've heard about NL cipher's being a massive flaw here.
Speaker 1: That sounds like an oxymoron. An NL cipher in a
Speaker 1: secure connection.
Speaker 2: It's a really insidious flaw. If NL ciphers are enabled
Speaker 2: on the server and get chosen during the connection negotiation,
Speaker 2: your browser might still show that reassuring padlock icon, but
Speaker 2: the HDP data will actually be transmitted in cleartext, completely unencrypted.
Speaker 2: It's a total false sense of security leaving sensitive info
Speaker 2: wide open.
Speaker 1: Wow. So it's not just about having HTTPS, but having
Speaker 1: it configured correctly precisely.
Speaker 2: Tools like the open SSL command line utility ss scan,
Speaker 2: which can show the ciphers and certificate details, and sslies
Speaker 2: are essential for testing these configurations. N MAP also has
Speaker 2: scripts like SSL inomsideiers to identify supported cipher suites and
Speaker 2: flag known vulnerabilities like crime or poodle associated with weak configurations.
Speaker 1: Okay, what about spidering web applications? That's about mapping out
Speaker 1: the whole site structure exactly.
Speaker 2: Trying to do that manually, especially on a complex site,
Speaker 2: is just time consuming and prone to emissions. It's really inefficient.
Speaker 1: So automation definitely.
Speaker 2: College provides tools for this. BURP Spider, which is part
Speaker 2: of the popular burp suite, is well known and very effective.
Speaker 2: It automates mapping the entire application, and it can even
Speaker 2: handle login authentication to map out areas hidden behind a
Speaker 2: login page that a public spider would miss.
Speaker 1: And then there's directory brute forcing or forced brows. What's
Speaker 1: the idea there?
Speaker 2: That's about requesting files and directories that aren't directly linked
Speaker 2: anywhere in the application. You basically guess common names from.
Speaker 1: A dictionary file. Why do that?
Speaker 2: Because it can uncover hidden test environments, forgotten backup files,
Speaker 2: administrative pages, configuration files, things that were never meant to
Speaker 2: be public but might still be accessible if you guess
Speaker 2: the url DIRB and COLLI is a prime tool for this,
Speaker 2: it can scan recursively and even use session cookies if
Speaker 2: you need to be authenticated.
Speaker 1: Okay, we've covered the meticulous reconnaissance in scanning. Let's really
Speaker 1: unpack the actual vulnerabilities attackers exploit, starting with authentication and
Speaker 1: session management flaws. Why are these so incredibly common?
Speaker 2: Well, the core problem really lies in HTTP's statelessness. It's
Speaker 2: what now statelessness? Think of it like a forgetful waiter.
Speaker 2: Every time you make a request to a web server,
Speaker 2: it treats it as a brand new interaction, completely unrelated to.
Speaker 1: The last one.
Speaker 2: Ah, okay, no memory exactly. So this means we need
Speaker 2: session management mechanisms to track user activity, like knowing you're
Speaker 2: logged in without forcing you to reauthenticate with every single click.
Speaker 1: Right, So how does that work?
Speaker 2: Usually through things like unique session identifiers, maybe inactivity timeouts,
Speaker 2: session expiration times, and making sure sessions are invalidated when
Speaker 2: you explicitly log out.
Speaker 1: And what kinds of authentication methods are pen testers usually
Speaker 1: looking at? Well.
Speaker 2: While HTTP supports older methods like basic digest and NTLM,
Speaker 2: which are ways for browsers to send credentials, honestly, form
Speaker 2: based authentication is by far the most interesting for pen testers.
Speaker 1: Why that one?
Speaker 2: Because it's custom built for pretty much every application. There's
Speaker 2: no single standard. That means there are way more opportunities
Speaker 2: for developers to make mistakes leading to flawed implementations.
Speaker 1: Makes sense, more custom cold, more potential bugs exactly.
Speaker 2: Though increasingly you see things like two factor authentication MFA
Speaker 2: adding an extra layer of security and ooh for letting
Speaker 2: third party apps access resources without you actually sharing your
Speaker 2: password with them.
Speaker 1: So what are some of the most common flaws pen
Speaker 1: testers find in these authentication and session management processes? Where
Speaker 1: do things go wrong? Oh?
Speaker 2: A big one is username enumeration.
Speaker 1: What's that?
Speaker 2: This happens when an application gives away excessive information. Maybe
Speaker 2: it shows a different error message if you enter a
Speaker 2: valid user name with the wrong password compared to an
Speaker 2: invalid username.
Speaker 1: Ah, so the attacker can tell which user names are
Speaker 1: real just by the error message. Exactly.
Speaker 2: It allows an attacker to methodically build a list of
Speaker 2: valid usernames. We can see this demonstrated really effectively using
Speaker 2: tools like burp Suite against vulnerable practice apps like a wasp,
Speaker 2: plub cooat and.
Speaker 1: Weak passwords still a massive issue, I imagine.
Speaker 2: Oh, absolutely sadly, yes, the prevalence of weak passwords that
Speaker 2: you have things from those most used passwords lists like one, two, three, four, five, six,
Speaker 2: or password or quarity. It remains a huge problem.
Speaker 1: So how do pangesters approach testing that without getting locked out?
Speaker 2: Well? A good approach for conducting online attacks is to
Speaker 2: try maybe just a few common passwords per username, then pause,
Speaker 2: wait a bit, and try a few more. This helps
Speaker 2: avoid triggering account lockout mechanisms.
Speaker 1: What about password reset or recovery functions? Those often feel
Speaker 1: like a potential weak link.
Speaker 2: You're right, they often are. There's an important difference between
Speaker 2: recovery where you somehow get your old password back, which
Speaker 2: usually implies a major security flaw like storing it in.
Speaker 1: Clear text, which should never happen never.
Speaker 2: And reset where you set a new one. But the
Speaker 2: risks in reset functions include things like maybe being able
Speaker 2: to spoof the email or phone number where the reset
Speaker 2: link is sent, or finding predictable reset links that include
Speaker 2: something easily guessable or exploitable like a user ID.
Speaker 1: And predictable session IDs. How does an attacker leverage that?
Speaker 1: I assume they should be random.
Speaker 2: They absolutely need to be random and unpredictable if they aren't.
Speaker 2: Maybe they're based on sequential numbers or the time, or
Speaker 2: something easily guessable. An attacker can potentially hijack a valid
Speaker 2: user session just by predicting a valid ID. Tools like
Speaker 2: burp sequencer can analyze session IDs and show how easily
Speaker 2: a weak one like a cookie named wicked based on
Speaker 2: sequential numbers can be predicted.
Speaker 1: So how do we prevent all these issues you mentioned earlier?
Speaker 1: There's no single universal solution, no.
Speaker 2: No universal solution has been found, unfortunately, but there are
Speaker 2: key preventions. Enforcing strong password policies is fundamental, length, mixed
Speaker 2: case special characters, blocking common patterns or sequences always using
Speaker 2: TLS for login pages is non negotiable. To protect credentials
Speaker 2: in transit. Using generic error messages during login is crucial
Speaker 2: to prevent that user name enumeration. We talked about implementing
Speaker 2: brute force lockouts like maybe five failed attempts triggers A
Speaker 2: twenty thirty minute lockout helps slow down automated attacks. For
Speaker 2: password resets, sending one time expiring links to the user's
Speaker 2: registered email or SMS is best practice.
Speaker 1: And those session cookies themselves, how can they be hardened?
Speaker 2: Making sure all the security flags are set on session
Speaker 2: cookies is vital. The secure flag ensures the cookie is
Speaker 2: only ever sent over an HTTPS connection. HTTP only is critical.
Speaker 2: It prevents client side JavaScript from accessing the cookie. This
Speaker 2: massively mitigates the impact if an attacker does find an
Speaker 2: excess vulnerability, because they can't easily steal the session cookie.
Speaker 2: Point setting cookies as non persistent so they expire when
Speaker 2: the browser closes. Using expires or maxage attributes, restricting the
Speaker 2: path attributes so the cookies only sent where needed and
Speaker 2: using the same site attribute provides extra protection against cross
Speaker 2: site request forgery CSRF.
Speaker 1: Okay, let's move on to injection based flaws. This sounds
Speaker 1: like we're an attacker actively shoves malicious data into the application.
Speaker 2: That's the core idea. Yeah, the attacker finds an input field,
Speaker 2: search box, log in form, urlo, parameter, whatever, and injects
Speaker 2: malicious data. The goal is to trick the application into
Speaker 2: sending that bad data to some underlying component like a
Speaker 2: database or the command line or an XMEL parser, and
Speaker 2: make that component execute unintended actions.
Speaker 1: Can you give me an example. What's command injection?
Speaker 2: Okay? Command injection? Imagine a web page that lets you
Speaker 2: ping an IP address you enter one twenty seven dot
Speaker 2: zero zero dot one. But what if you enter one
Speaker 2: seven dot zero dot zero dot zero one hone email Anyway,
Speaker 2: that's a Linux command to show system information. If the
Speaker 2: application doesn't properly validate the input and just blindly passes
Speaker 2: it to the server's command line, it runs the extra
Speaker 2: command exactly. It executes NIEMA on the server. You might
Speaker 2: get a non interactive shell. You can run commands, see
Speaker 2: the output, but can't interact further. Or sometimes it's blind
Speaker 2: command injection where you don't see any output, so you
Speaker 2: have to rely on side effects like making the server
Speaker 2: pin your machine to confirm the injection work. The famous
Speaker 2: shell shock vulnerability a few years back was a huge
Speaker 2: example of this, where the bash shell itself.
Speaker 1: Was vulnerable right and SQL injection scooply. That's probably the
Speaker 1: most famous injection flaw. Hasn't it been around forever?
Speaker 2: Yes, Sequel injection squall is incredibly common and has certainly
Speaker 2: stood the test of time. The vulnerability happens when user
Speaker 2: input is concatenated directly into a SQL query without being
Speaker 2: properly validated or sanitized first.
Speaker 1: So the attacker's input becomes part of the database command precisely.
Speaker 2: This allows them to execute malicious SEQUL commands directly against
Speaker 2: the database, and it's crucial to remember the flaw is
Speaker 2: almost always in the web applications code that handles the input,
Speaker 2: not usually in the database server itself.
Speaker 1: How do pen testers actually test for that? How they
Speaker 1: poke it an input field to see if it's vulnerable.
Speaker 2: They often start by injecting characters like a single quote
Speaker 2: to see if it breaks the query and causes an error.
Speaker 2: Then they'll try injecting modified select statements, often using union queries.
Speaker 1: Yeah.
Speaker 2: Union lets you combine the results of two select queries,
Speaker 2: so an attacker can craft a query that returns the
Speaker 2: normal application data plus extra data they want, like database names,
Speaker 2: table names, column names, often by queering system tables like
Speaker 2: information schema in myseql or postgress. Wooll.
Speaker 1: What if the server doesn't conveniently spit back the data
Speaker 1: in an error message or on the page. Is that
Speaker 1: where blind cooming comes in again?
Speaker 2: Exactly? That's blind seql injection. Since the server doesn't directly
Speaker 2: reveal information, detection relies on observing more subtle responses. It
Speaker 2: could be booling based asking true false questions via injected
Speaker 2: query and seeing if the page content or response code
Speaker 2: changes slightly, like does the admin user name start with A?
Speaker 2: If yes, maybe the page looks normal. If no, maybe an.
Speaker 1: Error page loads.
Speaker 2: Okay, so it's inference right, Or it could be time
Speaker 2: based injection. You inject a command that tells the database
Speaker 2: to pause for say five seconds. If the web page
Speaker 2: takes five seconds longer to load than usual, you know
Speaker 2: your injection worked. It's much slower and more methodical, but
Speaker 2: still very effective.
Speaker 1: Are there tools to automate finding SQL because that sounds tedious? Oh?
Speaker 2: Absolutely. While there are specific tools like school Ninja for
Speaker 2: targeting Microsoft SQL server, often aiming for shell access, the
Speaker 2: undisputed champion is school Map.
Speaker 1: School Map heard of it.
Speaker 2: It's an incredible automatic sequel injection tool. It can detect
Speaker 2: the vulnerability, figure out the database type, exploit it to
Speaker 2: dump data, and in many cases even reader write files
Speaker 2: directly on the database server's operating system, or even gain
Speaker 2: a command shell. It's extremely powerful.
Speaker 1: Wow. Okay, what about other types of injections you mentioned?
Speaker 1: XMLI right?
Speaker 2: XML based injections often called XXe for XML External entity
Speaker 2: injection attackers manipulate XML's tag based structure. They can define
Speaker 2: these external entities that when the server processes the XML,
Speaker 2: cause it to fetch and include external resources.
Speaker 1: Like what kind of resources like.
Speaker 2: Local files on the server such as etcter passed on Linux,
Speaker 2: which contains user account info. Or they can make the
Speaker 2: server make outbound network connections, potentially hitting internal systems. It
Speaker 2: all depends on how the server's XML parser is configured.
Speaker 1: And now that no seple databases like Mongo dB are
Speaker 1: so popular, are there injection risks there too?
Speaker 2: Yes, definitely no SQL injections because no circle databases often
Speaker 2: use flexible query structures, sometimes based on JSON. Attackers can
Speaker 2: potentially bypass authentication checks or retrieve unauthorized data by manipulating
Speaker 2: the structure of the JSON request formats, leveraging how the
Speaker 2: database processes queries differently from traditional SQL.
Speaker 1: So it seems like the defense against all these different
Speaker 1: injections types comes back to the same core principle handling
Speaker 1: user inputs safely.
Speaker 2: You've absolutely hit the nail on the head. The primary
Speaker 2: defense is robust input validation and ideally using a whitelist
Speaker 2: as lightless meaning meaning you define exactly which characters are
Speaker 2: allowed for a given input field and you reject everything
Speaker 2: else by default. It's much safer than trying to guess
Speaker 2: all the.
Speaker 1: Bad characters blacklisting. Okay.
Speaker 2: Then there's sanitization, which involves carefully removing or modifying any
Speaker 2: potentially dangerous characters, and encoding, which converts special characters into
Speaker 2: their save representations, like converting into ANELT, so the browser
Speaker 2: just displays it instead of interpreting it as HTML.
Speaker 1: Where does this need to happen? Browser side? Server side?
Speaker 2: The absolutely crucial part is these processes must be done
Speaker 2: on both the client side and the server side. Client
Speaker 2: side validation is good for user experience quick feedback, but
Speaker 2: it can always be bypassed by an attacker. Server side
Speaker 2: validation is where the real security happens. You need both.
Speaker 1: Got it? Okay? Moving on to another huge category, site
Speaker 1: scripting or XSS. What is XSS exactly and why is
Speaker 1: it seemingly everywhere?
Speaker 2: XSS is a type of code injection where malicious script
Speaker 2: usually JavaScript, gets injected into a website, typically through user input,
Speaker 2: and is then executed by the victim's web browser.
Speaker 1: So the malicious code runs in my browser, not on
Speaker 1: the server exactly.
Speaker 2: It exploits the trust your browser has on the website
Speaker 2: you're visiting. It makes the web page load and execute
Speaker 2: scripts it wasn't supposed to all within the context of
Speaker 2: your session on that trusted site. That's why it's so
Speaker 2: pervasive and dangerous.
Speaker 1: How does an attack typically work? What's the flow?
Speaker 2: Okay, the typical workflow. An attacker finds a vulnerable parameter
Speaker 2: on a website, maybe a search query or a comment field.
Speaker 2: They craft a malicious URL or piece of content containing JavaScript.
Speaker 2: Then they trick a victim into clicking that URL or viewing.
Speaker 1: That content, often through phishing, I guess, very.
Speaker 2: Often through targeted fishing emails.
Speaker 1: Yeah.
Speaker 2: When the victim clicks their browser requests the page, the
Speaker 2: vulnerable application includes the attacker script in the response, and
Speaker 2: the victim's browser executes it thinking it's legitimate code from
Speaker 2: the website. Attackers often use URL shortening services to hide
Speaker 2: the long, odd looking script and make the link look
Speaker 2: less suspicious.
Speaker 1: You mentioned different types reflected stored, dom based. Yeah, what's
Speaker 1: the key difference between them? Good question.
Speaker 2: Reflected exss is where the injected script is immediately reflected
Speaker 2: back to the user from the server, maybe in a
Speaker 2: search result page or an error message. It only affects
Speaker 2: the user who clicks the specific malicious link stored persistent
Speaker 2: EXSS is generally considered more dangerous. Here, the malicious script
Speaker 2: is actually stored in the server's database, maybe in a
Speaker 2: forum post, a product review, a user profile.
Speaker 1: Ah So anyone who've used that page gets hit exactly.
Speaker 2: It affects a large number of users automatically, without needing
Speaker 2: to target each one individually. This is often how website
Speaker 2: defacement happens via EXSS.
Speaker 1: And DOM based. That sounds different.
Speaker 2: Dom based EXSS is unique because the vulnerability isn't really
Speaker 2: on the server side. The malicious script gets executed purely
Speaker 2: because of how legitimate client side code JavaScript already on
Speaker 2: the page handles user supplied input, often from a URL
Speaker 2: fragment hashtag, and uses it to dynamically update the web
Speaker 2: page's document object model or DOM. The server might never
Speaker 2: even see the malicious script.
Speaker 1: Can excess has happen with post requests too, not just
Speaker 1: get requests where the script is in the URL.
Speaker 2: Yes, absolutely, XSS via post method is possible. The script
Speaker 2: would be in the body of the post request. It's
Speaker 2: a bit harder for the attacker to deliver, usually requiring
Speaker 2: them to get the victim to visit a malicious page
Speaker 2: that automatically submits the harmful post request to the vulnerable site.
Speaker 1: So, once an attacker successfully triggers an EXSS vulnerability, what
Speaker 1: can they actually do with it? What's the impact?
Speaker 2: The possibilities are pretty alarming because the script runs with
Speaker 2: the permissions of the website and the victim's browser. They
Speaker 2: can perform cookie stealing, reading the victim's session cookies and
Speaker 2: sending them to the attack.
Speaker 1: If they're not HGTP only right.
Speaker 2: Exactly If the hpp only flag isn't set on the cookie,
Speaker 2: JavaScript can read it. If it is set, This attack
Speaker 2: is much harder, though not always impossible.
Speaker 1: Depending on other factors. What else?
Speaker 2: They can turn the victim's browser into a key logger,
Speaker 2: capturing everything they type into forms on that page, passwords,
Speaker 2: credit card numbers. They can use frameworks like the Browser
Speaker 2: Exploitation framework beef.
Speaker 1: Yeah.
Speaker 2: Beef lets an attacker hook a victims browser. Once hooked,
Speaker 2: they have a command and control channel to the browser,
Speaker 2: allowing them to launch further attacks, use it as a proxy,
Speaker 2: explore the internal network. It's incredibly powerful, and of course,
Speaker 2: simpler things like defacement just visually altering the web page content.
Speaker 1: Is there an automated tool specifically for finding XSS flaws?
Speaker 2: Yes, xsor is a well known automatic EXSS scanner in
Speaker 2: Collie that can help identify potential EXSS points by injecting
Speaker 2: various payloads and analyzing the server's responses.
Speaker 1: So, given how versatile XSS is, how do we prevent
Speaker 1: it effectively?
Speaker 2: Again, it comes back to handling user inputs securely. Input
Speaker 2: validation is the first line of defense. Sanitization, removing dangerous
Speaker 2: characters and output encoding converting special characters before displaying them
Speaker 2: back to the user are absolutely key aspects.
Speaker 1: Encoding on output that's important.
Speaker 2: Critically important. You encode data right before it gets inserted
Speaker 2: into the htmnel page. And to reiterate that crucial point, validations, sanitization,
Speaker 2: and encoding processes must be done on both the client
Speaker 2: side and the server side. Relying only on client side
Speaker 2: checks is insecure.
Speaker 1: Okay, Let's move to cross site request forgery or CSRF.
Speaker 1: This one always sounds particularly sneaky because it involves someone
Speaker 1: who's already logged in.
Speaker 2: It is sneaky. CSRF is about forcing an authenticated, logged
Speaker 2: in user to submit a malicious request without their knowledge
Speaker 2: or consent. The attacker crafts a request, maybe embedded in
Speaker 2: an image pack or a link, that performs an action
Speaker 2: on a site where the user is logged in, like
Speaker 2: changing their email address, transferring funds a message.
Speaker 1: How does that work?
Speaker 2: The attacker leverages the fact that the user's browser will
Speaker 2: automatically include any relevant session cookies when making a request
Speaker 2: to that site. So if you're logged into your bank
Speaker 2: and you unknowingly trigger a malicious request crafted by an attacker,
Speaker 2: maybe by visiting their dodgy website, your browser sends the
Speaker 2: request with your valid banking session cookie and the bank
Speaker 2: thinks you initiated the action.
Speaker 1: Yikes. How do you identify if an application is vulnerable
Speaker 1: to CSRF? What's the telltale sign?
Speaker 2: You look for? State changing actions like submitting a form,
Speaker 2: clicking a button that does something that don't include any
Speaker 2: special header or form parameter that's unique and unpredictable for
Speaker 2: that specific user session. If the request relies only on
Speaker 2: the session cookie for authentication and authorization, it's likely vulnerable.
Speaker 2: The Perugia vulnerable app example where submitting a comment only
Speaker 2: needed the session cookie is a classic case.
Speaker 1: And how is it exploited? Is it easier with geet
Speaker 1: you requests like in a URL or post requests like
Speaker 1: form data.
Speaker 2: Exploiting it with geek requests is often simpler. Just embedding
Speaker 2: the malicious URL in an image tag mmgsrc, on another side,
Speaker 2: is enough. For post requests, it's a bit more involved.
Speaker 2: The attacker usually needs to create a hidden HTML form
Speaker 2: on their malicious page that automatically submits the harmful data
Speaker 2: to the target site when the victim visits.
Speaker 1: Now, can an EXSS vulnerability be used to bypass CSRF protections?
Speaker 1: That sounds like a nasty combination.
Speaker 2: Yes, it's a very common and dangerous scenario. If an
Speaker 2: application uses anti CSRF tokens unique secret values in forms
Speaker 2: to prevent CSRF, but is also vulnerable to EXSS.
Speaker 1: The attacker can use EXSS to steal the token exactly.
Speaker 2: The attacker uses the EXSS vulnerability to run JavaScript that
Speaker 2: reads the anti CSRF token from the page's form, and
Speaker 2: then they can craft a valid request with the stolen
Speaker 2: token completely bypassing the CSRF protection. It shows how vulnerabilities
Speaker 2: often chain together.
Speaker 1: So what's the prevention for CSRF? How do you start it?
Speaker 2: The primary defense is implementing anti CSRF tokens These are unique,
Speaker 2: unpredictable secret values generated by the so for each user
Speaker 2: session and embedded informs. The server validates this token on
Speaker 2: every state changing request. The same site cookie attribute, especially
Speaker 2: set to strict or lacks, provides significant protection by controlling
Speaker 2: when cookies are sent with cross origin requests, though browser
Speaker 2: support and implementation details matter. Requiring user interaction for sensitive
Speaker 2: actions like entering a captcha or reauthenticating with a password
Speaker 2: is also effective, and properly configured cross origin resource sharing
Speaker 2: CRS policies on the server can help restrict how JavaScript
Speaker 2: from other origins interacts with the site.
Speaker 1: All right, onto our last major vulnerability category, attacking flaws
Speaker 1: and cryptographic implementations. This sounds really complex, like breaking codes.
Speaker 2: It definitely sounds that way. The goal of cryptography here is,
Speaker 2: of course, protecting data confidentiality and integrity, But for pentesters
Speaker 2: the focus usually isn't on trying to break strong established
Speaker 2: cryptographic algorithms like AES or SAHA two fifty six. That's
Speaker 2: generally mathematically infeasible with current tech.
Speaker 1: So what are they looking for?
Speaker 2: They're looking for implementation failures using the right algorithm but
Speaker 2: in the wrong way, and perhaps more commonly seriously flawed
Speaker 2: custom implementations. Developers sometimes think they can invent their own secure.
Speaker 1: Encryption, which is a bad idea, a.
Speaker 2: Really bad idea. Strong algorithms are designed and rigorously tested
Speaker 2: by highly specialized teams of mathematicians and computer scientists. It's
Speaker 2: not something you should roll your own unless you are
Speaker 2: one of those experts.
Speaker 1: What are the basics of encryption we need to grasp here?
Speaker 2: Okay, briefly. With symmetric algorithms, the same secret key is
Speaker 2: used for both encryption and decryption. You have stream ciphers,
Speaker 2: which encrypt data bit by bit or byte by byte.
Speaker 2: Good for streaming ciphertext is the same size as the
Speaker 2: clear text, and block ciphers, which encrypt fixed sized blocks
Speaker 2: of data that the ciphertext is usually a multiple.
Speaker 1: Of the block size. Right and hash.
Speaker 2: Hashing functions take an input of any size and produce
Speaker 2: a fixed length value the hash er digest. Their main
Speaker 2: purpose is ensuring the integrity of the message. Any tiny
Speaker 2: change in the input results in a drastically different hash.
Speaker 2: They should also be non reversible. You can't get the
Speaker 2: original input back from the hash, and it should be
Speaker 2: computationally impossible to find two different inputs that produce the
Speaker 2: same hash a collision.
Speaker 1: And thels SSL in web apps brings us all together
Speaker 1: pretty much.
Speaker 2: Https is the everyday application of TLSSSL to secure client
Speaker 2: server communication. As we said, TLS provides that CIA triad confidentiality, integrity, availability,
Speaker 2: plus non repudiation via certificate signed by CAAs verifying the
Speaker 2: server's identity. The actual process cleverly combines both asymmetric public
Speaker 2: private key encryption for the initial secure key exchange and
Speaker 2: then faster symmetric encryption using that exchange key for the
Speaker 2: bulk data transfer.
Speaker 1: And that critical flaw the nl cipher pops up here again,
Speaker 1: that false sense of security.
Speaker 2: Yes, it's worth repeating. If n CEL ciphers are enabled
Speaker 2: and get negotiated, the browser might show the padlock, but
Speaker 2: HTTP data will actually be transmitted in cleartext. Looks secure,
Speaker 2: but isn't like a locked door made of glass.
Speaker 1: What tools help pentesters scrutinize these ssltls configurations.
Speaker 2: The open SSL command line tool is fundamental for manual checks.
Speaker 2: SSL scan is great. It can show cipher's certificate details
Speaker 2: and crucially it helps you watch out when NSL is
Speaker 2: pointed out in the cipher list. Sslies is another powerful
Speaker 2: dedicated SSLTLS scanner, and NMP again has scripts like SSL
Speaker 2: enom ciphers to identify cipher suites, rate their strength, and
Speaker 2: flag specific protocol vulnerabilities like crime or poodle.
Speaker 1: Speaking of those, what about exploiting well known crypto flaws
Speaker 1: like heart bleed or poodle that caused such panics?
Speaker 2: Yeah, those were big ones. Heart Bleed back in April
Speaker 2: twenty fourteen, was a devastating buffer over red situation in
Speaker 2: the open SSL TLS implementation. Basically due to a missing
Speaker 2: bounds check in the heartbeat extension, an attacker could request
Speaker 2: more data back from the server than they sent, and
Speaker 2: the server would accidentally return extra chunks of its own.
Speaker 1: Memory, including potentially sensitive data.
Speaker 2: Including potentially sensitive data like private keys, session cookies, passwords,
Speaker 2: all in clear text read directly from the server's memory
Speaker 2: without needing to decrypt anything. Metasploit quickly got an.
Speaker 1: Explorit module for it and poodle.
Speaker 2: Poodle padding oracle On downgraded legacy encryption specifically exploited a
Speaker 2: weakness in how SSLv three handled blocks cipher padding, combined
Speaker 2: with the fact that browsers could be tricked into downgrading
Speaker 2: the connection from TLS to the much older, insecure SSLv three.
Speaker 2: If a server still allowed SSLv three connections, it was vulnerable.
Speaker 2: In practice, executing the full poodle attack was complex, but
Speaker 2: simply allowing SSLv three was a bad sign. Attackers often
Speaker 2: found it easier just to use SSL stripping to force
Speaker 2: plan HTTP.
Speaker 1: Anyway, you mentioned developers rolling their own crypto being a
Speaker 1: huge risk. Why is that so dangerous?
Speaker 2: It's dangerous because custom encryption protocols are almost invariably weak.
Speaker 2: Developers might think, oh, only I know the algorithm, so
Speaker 2: it must be secure. That security through obscurity, and it
Speaker 2: never works.
Speaker 1: Long term because real crypto is.
Speaker 2: Hard, incredibly hard. Common mistakes involve simple techniques like basic
Speaker 2: xor operations, simple character substitution, or just scrambling the data order.
Speaker 2: All of these are easily breakable with standard cryptanalysis techniques
Speaker 2: taught in introductory courses.
Speaker 1: And where the keys are stored must be another massive failure. Points.
Speaker 2: Huge one key storage flaws are rife encryption keys stored
Speaker 2: in totally unsafe places, maybe in downloadable configuration files, hard
Speaker 2: coded directly in application source code, or even embedded in
Speaker 2: client side jobscript where anyone can see them.
Speaker 1: Yikes.
Speaker 2: Also just using outdated algorithms things like DEES encryption or
Speaker 2: using MBFI for password hashing, especially for passwords under sy
Speaker 2: ten characters. Modern CPUs and especially GPUs can crack these
Speaker 2: relatively easily, sometimes in minutes or hours, using readily available tools.
Speaker 1: So if a pin tester finds some data that looks
Speaker 1: encrypted or hashed, how do they figure out what it
Speaker 1: is and maybe try to break it?
Speaker 2: Well, if the out put is always the same fixed
Speaker 2: length regardless of the input size, it's almost certainly a hash.
Speaker 2: There's a Collie tool called hash identifier that can help
Speaker 2: guess the hash type based on common patterns and links.
Speaker 1: Okay, what about telling encrypted data apart from just say
Speaker 1: random binary data?
Speaker 2: Frequency analysis is a very useful way to tell if
Speaker 2: a set of data is encrypted, encoded, or obfuscated. Properly,
Speaker 2: encrypted data should have a very similar frequency for every
Speaker 2: character from zero to two fifty five. The byte distribution
Speaker 2: looks almost random, very flat. Clear text, on the other hand,
Speaker 2: has very uneven distributions. Think how often E appears in
Speaker 2: English text compared to Z. Entropy analysis also helps it
Speaker 2: measures randomness. Ideally, a strong encryption algorithm should produce ciphertext
Speaker 2: with entropy values very close to eight for eight bits
Speaker 2: per bitte, indicating high randomness. Lower entropy might suggest weak
Speaker 2: encryption or just obfuscation.
Speaker 1: And if they identify a hash, what tools do they
Speaker 1: use to try and crack it offline back on their
Speaker 1: own machine.
Speaker 2: Two mainstays and Collie are John the Ripper and Hashcat.
Speaker 2: John jtr is pre installed, it's a classic. It can
Speaker 2: often auto detect hash types, run powerful dictionary attacks using
Speaker 2: massive word lists like the famous Rocky list compiled from
Speaker 2: real world breaches, apply mangling rules to dictionary words, and
Speaker 2: perform brute force.
Speaker 1: Attacks in hashcat.
Speaker 2: Hashcat is a more modern, highly optimized cracking tool designed
Speaker 2: to leverage the power of GPUs graphics cards as well
Speaker 2: as CPUs for brute forcing or complex dictionary attacks. It
Speaker 2: can be orders of magnitude faster than a CPU only
Speaker 2: tool like John, assuming you have a decent GPU.
Speaker 1: So bottom line, how do we prevent these cryptographic flaws
Speaker 1: in our applications?
Speaker 2: First, always use secure standard protocols like TLS and configure
Speaker 2: them correctly. Use things like HTTP Strict Transport Security HSTS
Speaker 2: headers to tell browsers to only connect via htps, preventing
Speaker 2: SSL strip.
Speaker 1: Attacks and password storage.
Speaker 2: Passwords must never be stored in clear text. Ever, use
Speaker 2: modern one way salted hash fundnctions. Good choices currently include
Speaker 2: PBKDF two be crypt or script, often combined with a
Speaker 2: strong hash like SAHA five twelve. The salting part adding
Speaker 2: a unique random value to each password before hashing, is
Speaker 2: critical to defeat rainbow table attacks. Using older hashes like
Speaker 2: MD five or SAJA one for passwords is now strongly
Speaker 2: discouraged due to known weaknesses and collision vulnerabilities.
Speaker 1: Okay, we've covered a ton on finding vulnerabilities. Now let's
Speaker 1: shift to the hacker's arsenal, starting with automated scanners in practice.
Speaker 1: What's their real role in a pen test? Are they
Speaker 1: the magic bullet?
Speaker 2: Automated scanners definitely have a role. They're good for quick scans,
Speaker 2: for finding that low hanging fruit, the obvious common vulnerabilities,
Speaker 2: but they are absolutely not a magic bullet, far from it.
Speaker 1: What are the big caveats?
Speaker 2: Several critical considerations. First, always always check the scope and
Speaker 2: project documentation to make sure you even have permission to
Speaker 2: use automated scanners. Some clients forbid them or restrict their use. Second,
Speaker 2: ideally test only in a QA development or testing environment.
Speaker 2: Never run an aggressive automated scanner against a live production
Speaker 2: system without explicit written consent, because there's an inherent risk
Speaker 2: of damaging the data or causing downtime.
Speaker 1: Makes sense anything else.
Speaker 2: Keep the scanners, plugins and vulnerability definitions updated, Configure it
Speaker 2: for the maximum level of logging so you have evidence,
Speaker 2: and critically, do not leave the scanner unattended. You need
Speaker 2: to monitor what it's doing.
Speaker 1: And the most important thing to remember about relying.
Speaker 2: On them, the absolute most important thing is do not
Speaker 2: rely on a single tool. Use multiple scanners if possible,
Speaker 2: but most importantly, always manually validate findings. Automated scans are
Speaker 2: notorious for false positives, and they often fail to provide
Speaker 2: any value without that crucial manual verification and interpretation by
Speaker 2: an experienced.
Speaker 1: Tester, which CALI. Linux scanners are commonly used for web applications.
Speaker 1: Besides nikto which we mentioned well.
Speaker 2: There's skipfish, which is known for being fast and generating
Speaker 2: nice HTML reports that categorize vulnerabilities by risk level. Where
Speaker 2: PD is another command line scanner that detects variety of
Speaker 2: flies like xss, uculi, file inclusions, etc. And the WASP
Speaker 2: d app proxy includes an active vulnerability scanner component that
Speaker 2: sends specifically crafted requests to probe for vulnerabilities.
Speaker 1: Whatout fuzzing. That sounds a bit like just throwing random
Speaker 1: stuff at an application.
Speaker 2: It is essentially, but in a structured way. Fuzzing involves
Speaker 2: sending large amounts of unexpected, malformed or semi malformed data
Speaker 2: to an application's inputs to see if you can trigger crashes, errors,
Speaker 2: or uncover hidden vulnerabilities.
Speaker 1: How do tools help with that?
Speaker 2: Tools like the o waspps app fuzzer let you select
Speaker 2: specific insertion points in an HTTP request parts you want
Speaker 2: to replace with fuzzed data, like from a list of
Speaker 2: common attack strings or just random data. Then you analyze
Speaker 2: the responses, maybe looking for error messages or specific keywords
Speaker 2: like reflected, which might indicate potential EXSS. Burb Intruder is
Speaker 2: also extremely powerful for fuzzing and dictionary attacks, trying thousands
Speaker 2: of usernames and passwords on a login page, or testing
Speaker 2: for SQL injection by setting up rules repmatch to flag
Speaker 2: interesting server responses.
Speaker 1: Okay, now for the really big gun, the Metasplit framework.
Speaker 1: It is often called the pintester's Swiss army knife. Right.
Speaker 2: It absolutely is metasplit is huge. Its power comes from
Speaker 2: its modular architecture. Everything exploits payloads and coders, auxiliary modules
Speaker 2: for scanning or reconnaissance. They're all individual modules. This makes
Speaker 2: it incredibly flexible and easy to extend with new capabilities.
Speaker 1: How easy is set up in calling very easy.
Speaker 2: It's usually pre installed or a quick install. The important
Speaker 2: setup step is initializing its postgresscool database. Metasploit uses this
Speaker 2: database to store all the information you gather about hosts, services, vulnerabilities, credentials.
Speaker 2: Using workspaces within the database is also key for staying organized.
Speaker 2: It lets use separate data sets for different penetration tests
Speaker 2: or different parts of a network.
Speaker 1: And how does it integrate with the scanning and info
Speaker 1: gathering we already talked to.
Speaker 2: Metasploid itself has a vast array of auxiliary modules for
Speaker 2: information gathering and scanning. For passive recon there are modules
Speaker 2: to query dns, scrape subdomains from search engines like Yahoo
Speaker 2: and bing search, showdan if you have an apikey to
Speaker 2: find devices and open ports, or collect email addresses associated
Speaker 2: with a domain from search engines.
Speaker 1: So it could do its own recon yes and.
Speaker 2: For active scanning, it has its own TCP port scanner
Speaker 2: and syn port scanner modules. But even better, it integrates
Speaker 2: directly with nmap. You can run enmap scans using the
Speaker 2: dbn met command and the results are automatically imported and
Speaker 2: stored right in metasploids database. This is incredibly useful. You
Speaker 2: can leverage enmap's powerful enmap scripting engine NSC scripts maybe
Speaker 2: to find specific HTTP vulnerabilities like servers allowing dangerous methods
Speaker 2: UQT delete trace, and have all that data ready in
Speaker 2: metasploit for the next steps.
Speaker 1: So it's not just a collection of exploits, but a
Speaker 1: full framework that manages the whole process, including the data.
Speaker 1: What about discovering hosts and services beyond web stuff?
Speaker 2: Definitely? Metasploit has modules like ARP sweep to find live
Speaker 2: hosts on the local network segment a UDP service. Sweeper
Speaker 2: can probe for common UDP services like net biosportmap, SMMP,
Speaker 2: DNS for SMB server, message block and numeration on Windows networks.
Speaker 2: It's very powerful. Modules like seminom shares find accessible network shares,
Speaker 2: spend and aversion gets detailed OS info Somedenom users can
Speaker 2: sometimes list local users via the SAM RPC interface. That's
Speaker 2: the Security Account Manager database where Windows keeps user credentials.
Speaker 1: Can it brute force logins.
Speaker 2: Yep, some log in can brute force SMB passwords and crucially,
Speaker 2: as we mentioned, the summess WEE TA ten module can
Speaker 2: detect the critical Eternal Blue vulnerability and check for the
Speaker 2: double Pulsar back door without needing any valid credentials.
Speaker 1: That was huge massive. What about SNMP The Network Management
Speaker 1: Protocol For.
Speaker 2: SNMP Simple Network Management Protocol Enumeration metasploid has some log
Speaker 2: in to try common default community strings like passwords for SMMP.
Speaker 2: If successful, sempenem can gather a wealth of information system details,
Speaker 2: network interfaces, running processes, open ports, installed software depending on
Speaker 2: how the devices configured.
Speaker 1: Okay, and other protocols.
Speaker 2: It also has modules for scanning things like HTTT services
Speaker 2: for example Jenkin sentum to check genkin ci service status
Speaker 2: or Windows Remote Management when RM using win RMCMD and
Speaker 2: importantly metasplit can directly integrate with and import scan results
Speaker 2: from commercial vulnerability scanners like nessis or nexpos, as well
Speaker 2: as the open source open bas This lets you consolidate
Speaker 2: all your vulnerability data in one place.
Speaker 1: Okay, so you've gatted all this information identified potential vulnerabilities.
Speaker 1: The next big leap is server side exploitation. This is
Speaker 1: where the actual hacking part happens, right. That's right.
Speaker 2: After meticulously gathering intel about the target OS, the running services,
Speaker 2: and potential vulnerabilities, the next step is finding a suitable
Speaker 2: exploit module in metasploit and the launching it.
Speaker 1: Can you walk us through an example? Maybe on Linux? Sure?
Speaker 2: A classic example often used on the Metasploitable two vulnerable
Speaker 2: practice VM, involves exploiting the Samba service. There is a
Speaker 2: specific metasport module exploit multi sambasser mapscript. This exploit cleverly
Speaker 2: leverages a flaw in how Samba handled usernames, allowing for
Speaker 2: remote command execution without any authentication.
Speaker 1: No password needed, none at all.
Speaker 2: You just point the exploit at the target, run it,
Speaker 2: and if successful, metasploit connects back, giving you a command
Speaker 2: shell on the Linux server. You can then verify access
Speaker 2: by running simple commands like host name or ID to
Speaker 2: see who you are on the compromised machine.
Speaker 1: You keep mentioning payloads when you talk about exploits, What
Speaker 1: exactly is the payload?
Speaker 2: The payload is the piece of code that the exploit
Speaker 2: delivers to the target machine after the vulnerability has been
Speaker 2: successfully exploited, it's what actually gives you control. For example,
Speaker 2: after using the Samba exploit, you might choose a payload
Speaker 2: like cimnikus reverse netcat or more commonly Linux eighty six
Speaker 2: Mesori reverse x. This payload connects back from the victim
Speaker 2: machine to your metasplay listener, establishing that remote access session.
Speaker 1: Okay. And Windows server exploitation similar.
Speaker 2: Ideas, similar concepts yes on the metasploitable three VM which
Speaker 2: runs Windows. Examples might include exploiting vulnerabilities in jenkin Ci
Speaker 2: if it's running, or using the sexc module if you
Speaker 2: somehow manage to obtain valid administrator credentials.
Speaker 1: But the really big one for Windows was Eternal.
Speaker 2: Blue, absolutely the MS seventeen zero ten Eternal Blue SMB
Speaker 2: Remote Windows Kernel pool corruption vulnerability. This was a critical
Speaker 2: buffer overflow flaw in the Windows SMB one server. It
Speaker 2: was allegedly developed by the NSA's Equation group, leaked by
Speaker 2: the Shadow Brokers group, and then infamously use as the
Speaker 2: primary spreading mechanism for the global Wanacry ransomware attack in
Speaker 2: twenty seventeen it allowed unauthenticated remote code execution on a
Speaker 2: massive scale.
Speaker 1: Just devastating. And once an attacker gets in, how they
Speaker 1: make sure they can get back in later.
Speaker 2: A key post exploitation step is installing backdoors or setting
Speaker 2: up other persistence mechanisms. This ensures they can maintain access
Speaker 2: even if the initial vulnerability it gets patched or the
Speaker 2: system reboots, and.
Speaker 1: They also just try to break things. Yeah, denial of service.
Speaker 2: Yes, they can perform denial of service. Thus attacks this
Speaker 2: might involve flooding a service with traffic to overload it,
Speaker 2: or exploiting a specific vulnerability that causes the service or
Speaker 2: the entire system to crash or become unresponsive. An example
Speaker 2: mentioned in the source is Smblorus, a remote and uncredential
Speaker 2: doss attack against Microsoft Windows that exploited a flaw in
Speaker 2: the SMB protocol to consume excessive memory, potentially crashing the system.
Speaker 1: Okay, now let's talk about Interpreter. This always comes up
Speaker 1: when talking about Metasploid. It's described as the post exploitation powerhouse.
Speaker 1: What makes it so special.
Speaker 2: Interpreter is essentially Metasploid's advanced feature rich payload. It gets
Speaker 2: loaded into the memory of the compromise machine and provides
Speaker 2: an incredibly flexible and extensible command shell, allowing automation of
Speaker 2: many post exploitation tasks. It's largely replaced older, less dynamic methods.
Speaker 2: Its real power is its ability to run into hirely
Speaker 2: in memory, often avoiding writing files to disc making it stealthier.
Speaker 1: Give me some examples. What kind of things can you
Speaker 1: do once you have a interpreter session? Oh a lot.
Speaker 2: It has a whole suite of built in commands. Basic
Speaker 2: system commands like get tuids see what user you're running as,
Speaker 2: get tupid, get the process id PS, list running processes,
Speaker 2: sink and FOE, get OS details alls some stuff. Full
Speaker 2: filesystem commands dot, LCDPWD like Linux upload download files between
Speaker 2: your machine and the victim, edit files directly, cat file contents.
Speaker 2: You have extensive control.
Speaker 1: Can it interact with the user's desktop or peripherals.
Speaker 2: Yes, that's where it gets really powerful for surveillance. UI
Speaker 2: interaction commands like screenshot to grab the desktop, keyscan start,
Speaker 2: keyscan stop keyscin dump for keylog and capturing keystrokes. Even
Speaker 2: webcam snap to take pictures from the webcam if available.
Speaker 1: WHOA, What about escalating privileges or dumping credentials.
Speaker 2: Absolutely key tasks for privileged escalation and data dumping. Interpreter
Speaker 2: has the get system command, which tries various techniques to
Speaker 2: escalate to the system user on Windows highest privileged level.
Speaker 2: Hash dump attempts to extract the password hashes from the
Speaker 2: SAM database and crucially, it integrates mimicat's functionality.
Speaker 1: Mimicats is famous for credential dumping right exactly.
Speaker 2: A materpreter can load mimicats directly into memory to extract plaintext, passwords,
Speaker 2: corberos tickets, and password hashes directly from the memory of
Speaker 2: processes like LSAs dot ex. It often needs to migrate
Speaker 2: into that lsaas dot ex process first. It can also
Speaker 2: try to bypasswhack user account control on Windows.
Speaker 1: And maintaining persistence getting back in later.
Speaker 2: Interpreters can help with persistence. Commands like get gee can
Speaker 2: enable remote desktop access. There are also specific metasplit post
Speaker 2: exploitation modules for setting up more robust backdoors like installment
Speaker 2: MIC backdoor.
Speaker 1: What about networking from the compromise machine.
Speaker 2: Crucial for moving laterally. Networking commands like ipconfig and route
Speaker 2: help you understand the victim machines network configuration date allows
Speaker 2: you to set up port forwarding, relaying traffic through the
Speaker 2: victim machine. This is essential for pivoting.
Speaker 1: Pivoting.
Speaker 2: Pivoting is using the initially compromised machine as a foothold
Speaker 2: to attack other machines on the same internal network that
Speaker 2: you can't root directly. Interpreter is excellent for this, allowing
Speaker 2: you to add routes so you can scan and attack
Speaker 2: internal systems through your Materpreter session.
Speaker 1: Can it sniff network traffic passing through the compromised host.
Speaker 2: Yes, it has packet sniffing capabilities, sniffer interfaces, lists network interfaces,
Speaker 2: sniffer start, sniffer stops, sniffer dump let you capture traffic
Speaker 2: on the victim machine and save it as a pcap
Speaker 2: file for later analysis with tools like wireshark or TCP dump.
Speaker 1: Credential harvesting too, Yes, there.
Speaker 2: Are modules like post Windows gatherfish Windows credentials that can
Speaker 2: pop up fake login prompts to try and trick users
Speaker 2: into entering their credentials.
Speaker 1: Wow, and just general enumeration. Once you're insight.
Speaker 2: Lots of that. Post exploitation modules like wineum can gather
Speaker 2: huge amounts of information installed applications, network shares, user accounts policies.
Speaker 2: The Gathering Suite module can scan the local network for
Speaker 2: other live hosts.
Speaker 1: You mentioned routing traffic through this session for pivoting. How
Speaker 1: did that work with other tools?
Speaker 2: Materpreter's post multimanage out or root module automatically adds the
Speaker 2: necessary routes in metasplit. Then you can use Metasplate's auxiliary
Speaker 2: service SoCs for a module to set up metasplate itself
Speaker 2: as a soocks proxy server. Now you can configure other
Speaker 2: tools on your own attack machine, like enmap or a
Speaker 2: web browser to use this proxy, often via a tool
Speaker 2: called proxy chains. This routes their traffic through the Materpreter session,
Speaker 2: allowing you scan and interact with the victim's internal network
Speaker 2: as if you were sitting on the compromise machine.
Speaker 1: That's incredibly powerful. Can you automate some of these post
Speaker 1: exploitation steps.
Speaker 2: Yes, you can use the autoorunscript option in metasploit to
Speaker 2: automatically run a Materpreter script like scraper, dot orb or
Speaker 2: winum as soon as a session is established, automating that
Speaker 2: initial information gathering.
Speaker 1: And how does materpreter try to keep its connection alive.
Speaker 1: If say the network drops.
Speaker 2: Briefly it uses transports, you can add backup transports using
Speaker 2: transport ad maybe setting up a reverse TTP or reverse
Speaker 2: TTPs transport alongside the initial TCP connection. These use standard
Speaker 2: webports and protocols, which are often less likely to be
Speaker 2: blocked by firewalls and can help maintain the session if
Speaker 2: the primary connection fails.
Speaker 1: Okay. One last tool in the metasploit arsenal MSF venom.
Speaker 1: What's his specific job?
Speaker 2: Msf venom is Metasploit's standalone payload generator and encoder. Its
Speaker 2: job is to create the actual malicious files or scripts
Speaker 2: that you'll deliver to the victim, perhaps via exploit or
Speaker 2: maybe through social engineering.
Speaker 1: She used to build the interpreter payload.
Speaker 2: For example, exactly use msfvenom to generate payloads for various
Speaker 2: operating systems Windows, Linux, Android, mac os architectures by eighty six,
Speaker 2: by sixty four ARM and formats ex files, DLLs, shell
Speaker 2: code scripts. It also incorporates powerful encoders.
Speaker 1: Wiringcoder is so important.
Speaker 2: Encoders are crucial for evading antivirus software where and bypassing
Speaker 2: and organization's defenses. They work by obfuscating the payloads code,
Speaker 2: changing its signature so that basic anti virus scanners might
Speaker 2: not recognize it as malicious. Metasploit includes several enquoders, like
Speaker 2: the polymorphic chicatagan i encoder. However, av products are constantly updated,
Speaker 2: so standard encoders often get detected quickly. Pen testers frequently
Speaker 2: need to use custom encoding techniques or combiningcoders to improve evasion.
Speaker 1: Okay, so we've spent a lot of time on server
Speaker 1: side exploits and the powerful tools used there. But you
Speaker 1: mentioned earlier that the landscape is shifting and often the
Speaker 1: most successful attacks now target the human element and client
Speaker 1: side systems. Why is that becoming the new frontier?
Speaker 2: Well, partly because server side security has gotten better. Generally speaking,
Speaker 2: companies spend more on securing servers, but endpoints laptops, desktops,
Speaker 2: mobile devices, they're often less consistently patched, running more diverse software,
Speaker 2: and critically, they're operated by humans who can be tricked.
Speaker 1: So the user is the weak link.
Speaker 2: Yes, this makes client machines a softer target. Attackers realize
Speaker 2: that tricking a user into running malware can often bypass
Speaker 2: even sophisticated network perameter defenses entirely, the most successful attacks
Speaker 2: target endpoints.
Speaker 1: How does reconnaissance work when you're targeting clients specifically? How
Speaker 1: do attackers' profile potential victims?
Speaker 2: Metasploit has modules for this too, like Auxiliary Gather Browser info.
Speaker 2: If an attacker can get a user to visit a
Speaker 2: web page they control, this module can fingerprint the victim's
Speaker 2: browser OS, install plugins like flash, Java, and check JavaScript support.
Speaker 2: This intel helps them choose the most effective client site exploit.
Speaker 1: And bypassing antivirus on the client machine, how do they
Speaker 1: get their malicious payloads past endpoint security?
Speaker 2: Again, this often comes down to antivirus idea of sifts
Speaker 2: bypass using custom payloads and encoders generated with MSF, Venom
Speaker 2: or other tools. Standard, well known payloads generated by metasploit
Speaker 2: are likely to get caught by modern av so attackers
Speaker 2: need to modify them, you sophisticated and curing or packing techniques,
Speaker 2: or even write completely custom malware to evade detection. It's
Speaker 2: that constant cat and mouse game.
Speaker 1: What are some specific client side attack techniques that really
Speaker 1: leverage this human element or software flaws on the client?
Speaker 2: Oh, there are many metasploit macro exploits are common malicious
Speaker 2: VBA macros embedded in office documents, word excel. If the
Speaker 2: victim enables macros enable content, the macro executes and can
Speaker 2: download and run a payload.
Speaker 1: Right those scary yellow warning bars and office exactly.
Speaker 2: Then there are human interface device HID attacks. These use
Speaker 2: USB devices like the keen c Usb hid or similar
Speaker 2: tools that pretend to be a keyboard or mouse when
Speaker 2: plugged in.
Speaker 1: So the computer just trusts it.
Speaker 2: Yeah. The device can then rapidly type commands to download
Speaker 2: and execute malware, often faster than a human could react,
Speaker 2: completely bypassing software based security controls because it looks like
Speaker 2: legitimate user input.
Speaker 1: Wow, what else?
Speaker 2: The HTML application HTA attack is quite effective against Windows users.
Speaker 2: Dot HGA files are basically HTML files that run with
Speaker 2: higher privileges capable of executing scripting languages like VBScript or JScript. Metasploits.
Speaker 2: HTA webserver module hosts some malicious HTA file. If an
Speaker 2: attacker tricks a user into downloading and running it, it
Speaker 2: will prompt the user for confirmation. But because the underlying
Speaker 2: MGAHG process is a legitimate sign Microsoft Windows application, many
Speaker 2: users will trust it and will allow it to run,
Speaker 2: giving the attacker code execution.
Speaker 1: That's incredibly deceptive, playing on trust in legitimate Windows components.
Speaker 1: What about backdooring legitimate software as someone downloads it.
Speaker 2: That's possible via Man in the middle MIKM attacks often
Speaker 2: on insecure networks like public Wi Fi. Using frameworks like
Speaker 2: MITMF man in the middle framework, which often requires ARP
Speaker 2: poisoning to intercept traffic, an attacker can intercept unencrypted downloads.
Speaker 2: They can then patch some executables like maybe notepad, dot
Speaker 2: exc or putty dot ex on the fly as the
Speaker 2: victim downloads them.
Speaker 1: So the victim gets a file that looks and maybe
Speaker 1: even works like the real.
Speaker 2: Thing exactly, but it's been secretly backdoored in transit to
Speaker 2: include the attacker's payload. They run the seemingly legitimate program
Speaker 2: and the backdoor executes. Attackers can also craft mobile exploits,
Speaker 2: using m's venom to create malicious Linux trojans or Android
Speaker 2: backdoors packaged as dot appk files usually delivered via social engineering.
Speaker 2: For example, fake app stores phishing links.
Speaker 1: So it really seems like many, if not most, of
Speaker 1: these successful client side attacks ultimately rely on exploiting human
Speaker 1: trust or maybe just a lack of awareness, which brings
Speaker 1: us to the Social Engineer Toolkit s set.
Speaker 2: You're absolutely right, the human element is often the easiest
Speaker 2: path in the Social Engineer Toolkit. SSET, created by Dave Kennedy,
Speaker 2: is an incredibly powerful open source penetration testing framework specifically
Speaker 2: designed to perform advanced attacks against the human element. It's
Speaker 2: a standard tool for simulating sophisticated phishing and other social
Speaker 2: engineering campaigns during a pen test.
Speaker 1: What kinds of attack vectors does set automate or make easier?
Speaker 2: It streamlines several key social engineering attacks. It's great for
Speaker 2: spearfishing campaigns, sending highly malicious emails to target specific users,
Speaker 2: often with options to spoof the sender's email address to
Speaker 2: make it look legitimate. Its web attack vectors are very popular.
Speaker 2: For instance, the HTA attack method within set can automatically
Speaker 2: clone a legitimate website like a company portal or a
Speaker 2: popular service to create a more credible pretext for delivering
Speaker 2: a malicious payload when the user interacts with the fake.
Speaker 1: Site, combining website cloning with payload delivery clever very.
Speaker 2: It also offers a multi attack web method that combines
Speaker 2: several different browser exploits and attack techniques under a single
Speaker 2: malicious link when the victim clicks set tries them one
Speaker 2: by one unless a successful attack is launched, increasing the
Speaker 2: chances of compromising different browser or plug in versions. It
Speaker 2: also includes an infectious media generator for creating malicious USB
Speaker 2: drives or other files designed to execute payloads when open.
Speaker 1: Wow. Okay, we have taking an absolute whirlwind tour through
Speaker 1: the complex world of penetration testing.
Speaker 2: We certainly have from understanding why it's so fundamentally crucial
Speaker 2: in our web centric world to really digging into the
Speaker 2: sophisticated tools and techniques that ethical hackers employ.
Speaker 1: Yeah, we explored setting up your own practice lab with
Speaker 1: Collie Linux, the meticulous art of gathering intelligence, the nitty
Speaker 1: gritty of exploiting all sorts of vulnerabilities.
Speaker 2: Right from sequel injections and cross sites scripting right up
Speaker 2: to exploiting major flaws like eternal blue, and then even
Speaker 2: how attackers manipulate that human element with social engineering.
Speaker 1: This deep dive. The aim was really to give you
Speaker 1: a shortcut to being truly well informed on this topic,
Speaker 1: packed with hopefully some surprising facts and practical insights that
Speaker 1: go way beyond the typical headlines.
Speaker 2: Absolutely, it's a complex field, but understanding the attackers' perspective
Speaker 2: is key to building better defenses.
Speaker 1: So here's a final thought. As digital defenses continue to evolve,
Speaker 1: and they are evolving rapidly, that human element often remains
Speaker 1: the weakest link. Considering everything we've unpacked today, all the techniques,
Speaker 1: the psychology, what surprising ways might you personally be susceptible
Speaker 1: to the very techniques designed to test these systems. Something
Speaker 1: to mull over until our next deep dive.