WEBVTT 1 00:00:00.160 --> 00:00:03.439 Welcome to the deep dive. Today we're plunging into the 2 00:00:03.480 --> 00:00:08.160 intricate world of ethical hacking and penetration testing. You've shared 3 00:00:08.199 --> 00:00:10.880 a comprehensive guide on this, and our mission really is 4 00:00:10.919 --> 00:00:14.839 to unpack cybersecurity, but from the perspective of the good guys, 5 00:00:15.240 --> 00:00:17.480 you know, the ethical hackers. We're going to try and 6 00:00:17.519 --> 00:00:20.640 extract the most important nuggets, give you a shortcut to 7 00:00:20.719 --> 00:00:23.719 truly understanding what it takes to secure our digital spaces. 8 00:00:24.120 --> 00:00:26.800 That's exactly right. Our guide for this journey is the 9 00:00:26.839 --> 00:00:30.640 Ethical Hacking and Penetration Testing Guide by rayfae Block. And 10 00:00:30.679 --> 00:00:34.479 like you said, this isn't just about listing tools or techniques. 11 00:00:34.520 --> 00:00:38.079 It's really about grasping the mindset, the methodologies, and just 12 00:00:38.159 --> 00:00:41.679 how critical these roles are in protecting well everything digital. 13 00:00:41.719 --> 00:00:44.560 Now we'll explore it all from the basic definitions right 14 00:00:44.640 --> 00:00:47.039 up to some pretty advanced attack factors. The goal is 15 00:00:47.079 --> 00:00:50.399 a clear, actionable understanding, hopefully without getting bogged down and 16 00:00:50.399 --> 00:00:51.119 too much jargon. 17 00:00:51.200 --> 00:00:54.280 Okay, great, let's unpack this then, because when we hear hacker, 18 00:00:55.119 --> 00:00:58.240 it often brings up those movie images, doesn't it, The 19 00:00:58.240 --> 00:01:01.439 person and the dark hoodie. But what's the real difference 20 00:01:01.520 --> 00:01:06.280 between someone doing that maliciously and someone practicing ethical hacking. 21 00:01:06.319 --> 00:01:08.959 It feels like one word for two very different things. 22 00:01:09.159 --> 00:01:12.439 Yeah, that's the perfect place to start. The terminology itself 23 00:01:12.920 --> 00:01:15.439 carries a lot of meaning. The guide clearly breaks down 24 00:01:15.480 --> 00:01:18.719 different types for security pros. The key term is white 25 00:01:18.719 --> 00:01:23.000 hat hacker. These are security researchers, maybe professionals, employed by 26 00:01:23.000 --> 00:01:26.560 an organization, and crucially, they have permission to attack that 27 00:01:26.640 --> 00:01:30.840 specific organization. Why to find the vulnerabilities before the bad 28 00:01:30.879 --> 00:01:32.760 guys do. Then you've got the other end, Like the 29 00:01:32.799 --> 00:01:36.079 script kitty, they often lack deep knowledge. They just use 30 00:01:36.120 --> 00:01:38.719 tools someone else build, can't really debug them, don't fully 31 00:01:38.799 --> 00:01:42.040 grasp how the exploit works. What's fascinating here is how 32 00:01:42.079 --> 00:01:46.120 the language immediately sets the stage. It highlights the responsibility, 33 00:01:46.120 --> 00:01:48.159 the ethical conducts required in this field. 34 00:01:48.400 --> 00:01:52.480 Right, So it's really about permission and purpose, authorization and intent. 35 00:01:53.120 --> 00:01:57.719 The book also introduces threats and exploits. How do these 36 00:01:57.719 --> 00:02:01.599 fundamental concepts fit into the big picture for an ethical hacker? 37 00:02:01.879 --> 00:02:05.480 They're foundational. They give it like a chain reaction. Almost. 38 00:02:05.760 --> 00:02:09.319 A threat is any possible danger to a system, something 39 00:02:09.400 --> 00:02:11.719 the organization absolutely doesn't want to happen, Right, Yeah, like 40 00:02:11.759 --> 00:02:15.439 a malicious hacker getting unauthorized access. That's a threat. An 41 00:02:15.479 --> 00:02:18.719 exploit is the actual message or piece of code that 42 00:02:18.759 --> 00:02:22.680 takes advantage of a specific weakness of vulnerability. It allows 43 00:02:22.680 --> 00:02:25.240 an attacker to make the system do something unintended, like 44 00:02:25.240 --> 00:02:27.400 giving them access to data. So you have the vulnerability, 45 00:02:27.400 --> 00:02:30.639 the weakness, the exploit leverages it, and that creates the threat, 46 00:02:30.919 --> 00:02:33.120 which you know immediately brings up the question how do 47 00:02:33.240 --> 00:02:35.879 organizations tackle both the potential dangers and the specific ways 48 00:02:35.919 --> 00:02:37.159 those dangers can be realized? 49 00:02:37.280 --> 00:02:40.680 Okay, that clarifies the chain. And there's another common point 50 00:02:40.680 --> 00:02:44.120 of confusion, isn't there? I hear vulnerability assessment and penetration 51 00:02:44.240 --> 00:02:47.759 tests thrown around almost interchangeably sometimes, but you're saying they're 52 00:02:47.840 --> 00:02:51.240 quite different. Can you break down what each one actually involves? 53 00:02:51.240 --> 00:02:52.919 Why does that difference matter so much? 54 00:02:53.719 --> 00:02:58.080 Absolutely? Yes, they are fundamentally different, and confusing them can 55 00:02:58.159 --> 00:03:01.080 lead to well a false sensus security. Think of a 56 00:03:01.159 --> 00:03:04.319 vulnerability assessment like this. Yeah, it's a broad health check. 57 00:03:04.960 --> 00:03:06.719 The goal is just to find and list all the 58 00:03:06.800 --> 00:03:09.840 vulnerabilities in an asset. It's like getting a report listing 59 00:03:09.919 --> 00:03:14.439 every possible weak point. Comprehensive, but passive, a penetration test, 60 00:03:14.479 --> 00:03:18.280 though that's much more active. You're actually simulating a real attacker. 61 00:03:18.560 --> 00:03:21.000 You try to exploit the vulnerabilities you find to see 62 00:03:21.039 --> 00:03:23.400 if you can actually get in or achieve a specific goal. 63 00:03:23.879 --> 00:03:26.039 So it's about proving the weakness can be leveraged, not 64 00:03:26.159 --> 00:03:29.479 just listing it. You document the ones you successfully exploited, 65 00:03:29.800 --> 00:03:30.919 showing the real impact. 66 00:03:31.199 --> 00:03:34.000 Got it. So the assessment finds the holes, the pen 67 00:03:34.039 --> 00:03:36.680 test tries to walk through them. Before any of that 68 00:03:36.719 --> 00:03:40.400 testing happens, though, there's this really crucial pre engagement phase. 69 00:03:40.840 --> 00:03:45.840 What absolutely has to happen here, especially around permissions and liabilities. 70 00:03:46.080 --> 00:03:47.400 You can't just start poking. 71 00:03:47.080 --> 00:03:51.800 Around, absolutely not. That's the bedrock the legal and ethical foundation. 72 00:03:52.479 --> 00:03:56.159 Without clear rules of engagement, the ROE in ethical hack 73 00:03:56.280 --> 00:04:01.080 becomes well, just hacking, illegal hacking is non negotiable. You 74 00:04:01.159 --> 00:04:05.560 need at minimum assigned permission to hack, document explicit consent, 75 00:04:05.840 --> 00:04:09.199 and usually a non disclosure agreement and NDA, but goes further. 76 00:04:09.560 --> 00:04:12.120 The ROE has to clearly define the scope what exactly 77 00:04:12.159 --> 00:04:14.879 are you testing, which systems, which networks. It also needs 78 00:04:14.879 --> 00:04:17.279 to cover the project duration, the methodology you'll use, the 79 00:04:17.279 --> 00:04:20.680 test subjectives, and critically outline what techniques are allowed and 80 00:04:20.680 --> 00:04:23.800 what's off limits, for instance, denial of service testing. Okay, 81 00:04:24.000 --> 00:04:26.319 usually not, but it needs to be stated, and finally 82 00:04:26.399 --> 00:04:30.680 clarifies liabilities and responsibilities for everyone involved. Setting those boundaries 83 00:04:30.720 --> 00:04:31.680 upfront is vital. 84 00:04:31.839 --> 00:04:35.279 Okay, that makes total sense, setting the ground rules before 85 00:04:35.360 --> 00:04:38.560 the game starts. Now, thinking about the game itself, The 86 00:04:38.600 --> 00:04:42.120 guide mentions different categories of tests based on how much 87 00:04:42.160 --> 00:04:45.160 info the tester gets up front. Black box, white box, 88 00:04:45.399 --> 00:04:49.040 gray box. What do these mean for how the ethical 89 00:04:49.040 --> 00:04:51.720 hacker actually approaches the test? Right? 90 00:04:51.800 --> 00:04:56.199 The starting info dramatically shapes the approach. It simulates different 91 00:04:56.199 --> 00:04:59.759 attacker scenarios. So black box you get very little in 92 00:04:59.759 --> 00:05:02.920 from maybe just IP ranges for a network test, or 93 00:05:03.000 --> 00:05:05.240 just the URL for a web app. No source code. 94 00:05:05.639 --> 00:05:07.439 It's like trying to crack a safe just by looking 95 00:05:07.439 --> 00:05:09.399 at the outside. You have no idea what's inside. Yeah, 96 00:05:09.480 --> 00:05:12.839 very common for external tests, mimicking an outside attacker. 97 00:05:12.920 --> 00:05:14.920 Okay, so that's the outsider of you exactly. 98 00:05:14.959 --> 00:05:16.759 Then you have white box. This is the opposite end. 99 00:05:16.759 --> 00:05:21.120 You get pretty much everything, application versions, OS details, network diagrams, 100 00:05:21.399 --> 00:05:24.079 maybe even source code for web apps. You basically have 101 00:05:24.120 --> 00:05:28.000 the blueprints. This allows for really deep, thorough analysis. Like 102 00:05:28.040 --> 00:05:32.079 static or dynamic code reviews common for internal tests trying 103 00:05:32.079 --> 00:05:32.360 to be. 104 00:05:32.360 --> 00:05:35.279 Exhaustive, like having an insider's knowledge. 105 00:05:34.879 --> 00:05:38.199 Precisely, and gray box is well, it's in the middle 106 00:05:38.319 --> 00:05:41.319 a blend. You might get some information maybe app names 107 00:05:41.360 --> 00:05:44.399 but not versions, or perhaps user credentials for a test 108 00:05:44.439 --> 00:05:46.920 account on a web app, but not the source code. 109 00:05:48.000 --> 00:05:50.639 This often mirrors a real world scenario where an attacker 110 00:05:50.720 --> 00:05:53.639 might have some partial knowledge, maybe from social engineering or 111 00:05:53.639 --> 00:05:56.360 a previous breach, but not the full picture. 112 00:05:57.079 --> 00:05:59.839 That breakdown is really helpful simulating different levels of at 113 00:05:59.879 --> 00:06:03.439 time hacker knowledge. Beyond those information levels, the guide also 114 00:06:03.439 --> 00:06:07.399 talks about different types of pen tests, focusing on specific areas. 115 00:06:08.040 --> 00:06:10.920 What are some examples that go beyond just looking at software? 116 00:06:11.040 --> 00:06:14.279 Yeah, it really broadens the scope. It highlights that security 117 00:06:14.360 --> 00:06:17.439 isn't just about code. For example, there's the social engineering 118 00:06:17.519 --> 00:06:20.519 penetration test. This focus is entirely on the human element. 119 00:06:20.800 --> 00:06:23.879 You're attacking users directly through things like spear phishing emails, 120 00:06:23.879 --> 00:06:27.079 maybe fake websites, trying to trick them into giving up credentials, 121 00:06:27.199 --> 00:06:28.879 or running malicious. 122 00:06:28.399 --> 00:06:32.040 Code, testing the people, not just the machines exactly. 123 00:06:32.199 --> 00:06:35.319 And then there's the physical penetration test. This is about 124 00:06:35.319 --> 00:06:38.959 testing physical security controls. Can you tailgate into a building? 125 00:06:39.279 --> 00:06:43.519 Can you bypass locks or RFID card readers? It involves 126 00:06:43.519 --> 00:06:46.959 physically attempting to breach the premises. It really shows how 127 00:06:47.000 --> 00:06:51.279 comprehensive security needs to be. Technology, people and physical barriers 128 00:06:51.319 --> 00:06:52.160 all working together. 129 00:06:52.439 --> 00:06:55.720 Wow. Okay, so it really covers all the bases. Now, 130 00:06:56.079 --> 00:06:59.399 once all this testing is done, digital, physical, social, the 131 00:06:59.480 --> 00:07:03.600 report is obviously key. The guide emphasizes tailoring it. Who 132 00:07:03.639 --> 00:07:07.360 are the different audiences these classes of readers and what 133 00:07:07.519 --> 00:07:08.680 do they each need to see? 134 00:07:08.800 --> 00:07:10.920 Yeah, one size fits all reports just doesn't work. You 135 00:07:10.959 --> 00:07:12.639 have to speak the right language to the right people. 136 00:07:12.920 --> 00:07:16.040 The guide points out three main classes. First, the executive class, 137 00:07:16.360 --> 00:07:19.199 I think CEO CIOs. They need the big picture. They 138 00:07:19.240 --> 00:07:22.800 read the executive summary. It covers overall results, major weaknesses found, 139 00:07:23.000 --> 00:07:25.879 the overall risk level determined, and crucially, how much that 140 00:07:26.000 --> 00:07:29.839 risk could be reduced by implementing the suggested countermeasures. They're 141 00:07:29.839 --> 00:07:32.920 generally not interested in the nitty gritty technical details of 142 00:07:32.959 --> 00:07:34.240 the exploits, just. 143 00:07:34.199 --> 00:07:36.160 The bottom line, the business impact. 144 00:07:36.560 --> 00:07:39.959 Right. Then there's the management class. These folks might be technical, 145 00:07:40.120 --> 00:07:43.199 might not be. They're primarily focused on the remediation report. 146 00:07:43.759 --> 00:07:47.839 This outlines the practical recommendations to boost security, things like 147 00:07:48.120 --> 00:07:51.839 implements a secure software development life cycle, or deploy these 148 00:07:51.839 --> 00:07:55.199 specific types of firewalls, actionable steps. 149 00:07:55.079 --> 00:07:56.360 More about the how to fix it. 150 00:07:56.360 --> 00:08:01.279 Plan exactly, and finally, the technical class secure tardy managers, developers, 151 00:08:01.480 --> 00:08:05.360 system admins. They do deep into the detailed findings. They 152 00:08:05.360 --> 00:08:08.199 need to know precisely how the vulnerabilities were exploited, the 153 00:08:08.240 --> 00:08:12.199 steps to reproduce them, and most importantly, the specific technical 154 00:08:12.199 --> 00:08:15.879 steps required to patch those weaknesses and verify the fixes. 155 00:08:16.319 --> 00:08:19.759 The guide also stresses using visual aids like charts showing 156 00:08:19.839 --> 00:08:23.079 vulnerabilities by severity or type that helps everyone understand the 157 00:08:23.079 --> 00:08:23.680 findings better. 158 00:08:23.800 --> 00:08:26.439 That makes sense, tailor the message don't give the CEO 159 00:08:26.480 --> 00:08:28.879 code snippets, don't give the developer just a high level 160 00:08:28.920 --> 00:08:33.720 risk score. Okay, so we've covered planning, types of tests, reporting. 161 00:08:34.360 --> 00:08:36.960 Now for the really interesting part, the tools and techniques. 162 00:08:37.360 --> 00:08:40.399 The guide mentions backtrack Linux a lot or its successor 163 00:08:40.639 --> 00:08:44.960 calli Linux, what makes this specific distribution so central and 164 00:08:45.000 --> 00:08:47.320 what are some basic things you'd do with it right away? 165 00:08:47.639 --> 00:08:51.080 Right? Backtrack Collie is basically the ethical Hackers specialized operating 166 00:08:51.120 --> 00:08:54.639 system it's Linux, but it comes preloaded with hundreds of 167 00:08:54.639 --> 00:08:59.080 tools specifically for security testing. While the exact tools change 168 00:08:59.080 --> 00:09:02.320 slightly with versions, the core structure the categories of tools 169 00:09:02.360 --> 00:09:05.519 remain pretty consistent. You typically run it in virtualization software 170 00:09:05.639 --> 00:09:09.519 like virtual box or VMware, keeps things isolated and safe. 171 00:09:09.639 --> 00:09:12.440 As for first steps, you'd use standard Linux commands. You know, 172 00:09:12.440 --> 00:09:15.240 password to change passwords, clear the screen, These calgacy what 173 00:09:15.279 --> 00:09:18.159 files are there, could configure to check your network settings, 174 00:09:18.200 --> 00:09:20.600 maybe declient to get an IP address, and you start 175 00:09:20.679 --> 00:09:24.200 necessary services, perhaps a database like myseql or postgres school 176 00:09:24.279 --> 00:09:27.200 or SSHD for remote access. It's essentially setting up your 177 00:09:27.200 --> 00:09:27.879 work brunch. 178 00:09:27.919 --> 00:09:30.759 A pre build work bench ready for action. So with 179 00:09:30.840 --> 00:09:34.000 that ready, information gathering is obviously step one. The book 180 00:09:34.080 --> 00:09:37.480 splits this into active and passive gathering. Can you give 181 00:09:37.519 --> 00:09:40.639 us some examples, maybe some surprising ones for each, Yeah. 182 00:09:40.440 --> 00:09:44.200 The distinction is important. Passive means gathering info without directly 183 00:09:44.240 --> 00:09:47.360 interacting with the target systems you're trying to be invisible. 184 00:09:47.720 --> 00:09:51.200 Examples include using whose databases you can find owner emails, 185 00:09:51.679 --> 00:09:54.960 name servers for a domain. Simple pin commands tell you 186 00:09:54.960 --> 00:09:57.240 if a host is up in its IP, TRUP trace 187 00:09:57.279 --> 00:10:00.720 red is fascinating. It maps the network passa to a target, 188 00:10:00.840 --> 00:10:03.879 showing routers maybe firewalls along the way, just by seeing 189 00:10:03.919 --> 00:10:07.240 how packets with increasing time to live values respond. There 190 00:10:07.240 --> 00:10:10.919 are GOI tools too, like neotrace. Netcraft is a huge 191 00:10:10.960 --> 00:10:14.279 online database for checking website tech, server types. 192 00:10:14.320 --> 00:10:17.120 So all public information basically mostly. 193 00:10:16.840 --> 00:10:21.320 Yes or information gathered indirectly. Google hacking is a really 194 00:10:21.399 --> 00:10:26.360 powerful passive technique. Using specific Google search operators dorks like 195 00:10:26.440 --> 00:10:29.840 site or file type dot com, you can find sensitive documents, 196 00:10:30.000 --> 00:10:34.360 login pages, configuration files accidentally exposed online. There are whole 197 00:10:34.399 --> 00:10:37.279 databases of these dorks. You can use tools like FOCA 198 00:10:37.279 --> 00:10:40.799 to analyze metadata in files found online without even downloading them, 199 00:10:41.200 --> 00:10:43.720 or use the harvester to scrape search engines in public 200 00:10:43.759 --> 00:10:47.480 records for email addresses associated with the domain, then search 201 00:10:47.519 --> 00:10:50.159 those emails on sites like people dot com. You can 202 00:10:50.200 --> 00:10:53.480 even generate potential password lists using seal by scraping words 203 00:10:53.519 --> 00:10:56.519 from the target's own website. All passive, you haven't touched 204 00:10:56.559 --> 00:10:57.320 their servers yet. 205 00:10:57.360 --> 00:11:00.399 It's amazing what you can find without alerting anyone. 206 00:11:00.600 --> 00:11:03.840 Then you have active information gathering. This does involve interacting 207 00:11:03.879 --> 00:11:06.720 with a target. A good example is what web It's 208 00:11:06.759 --> 00:11:09.159 like an all one scanner from backtrack Collie with hundreds 209 00:11:09.200 --> 00:11:12.320 of plugins. It actively probes the web server to identify 210 00:11:12.360 --> 00:11:15.279 its version, maybe find email addresses in the Paie source, 211 00:11:15.600 --> 00:11:18.559 detect SQL errors. You start a knock on the door now. 212 00:11:18.639 --> 00:11:22.639 Right, shifting from observation to interaction. The guide also gets 213 00:11:22.679 --> 00:11:27.240 into DNS enumeration. Sounds technical, but you mentioned it can 214 00:11:27.360 --> 00:11:31.440 reveal a lot. Is there one particularly insightful or maybe 215 00:11:31.639 --> 00:11:33.840 less common DNS technique? Ah? 216 00:11:33.919 --> 00:11:36.879 Yes, one that's quite neat, and, as the guide says, 217 00:11:36.919 --> 00:11:41.159 surprisingly effective is DNS cash snooping. Very few people seem 218 00:11:41.200 --> 00:11:44.159 to know about it. The idea is you query a 219 00:11:44.240 --> 00:11:48.000 target organization's DNS server, but not to ask for an address. 220 00:11:48.240 --> 00:11:50.559 You ask if it already has a specific record cached. 221 00:11:50.879 --> 00:11:54.080 Why If a record for say Facebook dot com is cashed, 222 00:11:54.279 --> 00:11:57.320 it means someone inside that network probably visited Facebook recently. 223 00:11:57.720 --> 00:12:00.679 You can do this using tools like dig with specif options, 224 00:12:00.799 --> 00:12:02.840 either non recursively or recursively, so you. 225 00:12:02.759 --> 00:12:05.000 Can figure out what websites the employees are visiting. 226 00:12:05.120 --> 00:12:07.720 Potentially Yes, and if you connect that to the bigger picture, 227 00:12:07.960 --> 00:12:10.679 think about targeted attacks. If you discover they heavily use 228 00:12:10.679 --> 00:12:13.679 a specific cloud service or social media site. You can 229 00:12:13.720 --> 00:12:17.159 craft much more convincing phishing emails or targeted exploits related 230 00:12:17.200 --> 00:12:20.039 to that service. It gives you intel on user behavior. 231 00:12:19.799 --> 00:12:23.759 That's incredibly sneaky. Okay, So moving from finding info about 232 00:12:23.759 --> 00:12:27.919 the target to actually scanning them. Target enumeration and port 233 00:12:27.960 --> 00:12:31.559 scanning one of the most common ways ethical hackers find 234 00:12:31.600 --> 00:12:35.200 those open ports, identify services and how do firewalls try 235 00:12:35.200 --> 00:12:35.759 to stop this? 236 00:12:36.279 --> 00:12:39.240 The absolute go to tool here is enmap. It's the standard. 237 00:12:39.519 --> 00:12:42.120 A basic scan is just end map target IP. It 238 00:12:42.120 --> 00:12:44.960 can scan single ips or whole ranges or different scan types. 239 00:12:45.320 --> 00:12:48.519 The default and usually fastest is the TCP syn scan. 240 00:12:49.080 --> 00:12:52.279 It sends just the initial syn packet of the TCP handshake. 241 00:12:52.639 --> 00:12:55.000 If it gets a SINAC back, the port's open. If 242 00:12:55.039 --> 00:12:57.559 it gets an RST, it's closed. It's efficient because it 243 00:12:57.559 --> 00:12:59.759 doesn't complete the connection. Then you have with a guide 244 00:12:59.759 --> 00:13:04.799 called anonymous scan types nll spn xmass scans. These manipulate 245 00:13:04.840 --> 00:13:07.799 TCQ flags, sending packets with weird or no flag set, 246 00:13:08.080 --> 00:13:11.600 hoping to confuse basic firewalls or stateless packet filters. They're 247 00:13:11.679 --> 00:13:14.360 less reliable, especially against Windows, but sometimes work. 248 00:13:14.480 --> 00:13:16.279 And what do the results look like what does nmap 249 00:13:16.360 --> 00:13:16.720 tell you. 250 00:13:16.960 --> 00:13:20.120 It gives you the port status. Open means something's listening. 251 00:13:20.559 --> 00:13:24.960 Closed means reachable but nothing's listening. Filtered means enmap thinks 252 00:13:24.960 --> 00:13:28.399 a firewall is blocking the probes. Unfiltered means the port 253 00:13:28.440 --> 00:13:31.440 is reachable, but endmap couldn't determine if it's open or closed. 254 00:13:31.840 --> 00:13:34.080 But just knowing a port is open isn't enough. The 255 00:13:34.120 --> 00:13:37.679 crucial next steps are service version detection using natches, v 256 00:13:37.720 --> 00:13:42.639 flag and OS fingerprinting. NMAP has huge databases. It analyzes 257 00:13:42.639 --> 00:13:45.519 the responses from open ports to guess the exact software 258 00:13:45.519 --> 00:13:48.679 and version running, and even the underline operating system. That's 259 00:13:48.720 --> 00:13:52.159 the key info you need to find relevant vulnerabilities and exploits. 260 00:13:52.360 --> 00:13:54.960 Right, knowing its port eighty isn't as useful as knowing 261 00:13:55.000 --> 00:13:57.600 it's APATCHE version two point four, but something with a 262 00:13:57.639 --> 00:14:01.559 known flaw? And how do firewalls an intrusion detection systems 263 00:14:01.600 --> 00:14:03.879 IDs fight back against end map scans. 264 00:14:04.240 --> 00:14:07.159 It's that constant cat and mouse game. Scanners try to 265 00:14:07.200 --> 00:14:10.320 be stealthy, defenses try to detect them. En map has 266 00:14:10.320 --> 00:14:14.240 built in techniques. Timing templates natogy zero to nantgy five 267 00:14:14.519 --> 00:14:17.840 control how fast packets are sent T zero paranoid and 268 00:14:17.879 --> 00:14:21.759 T one sneaky are extremely slow, trying to slip inner 269 00:14:21.799 --> 00:14:27.000 IDs thresholds fragmented packets. Nastulists splits the probe packets into 270 00:14:27.000 --> 00:14:30.360 tiny pieces, hoping the firewall or IDs can't reassemble them 271 00:14:30.360 --> 00:14:33.200 properly to see the scan attempt. You can also try 272 00:14:33.240 --> 00:14:37.120 source port specification source port sending traffic from common ports 273 00:14:37.120 --> 00:14:40.320 like fifty three DNS or eighty HTTP, trying to make 274 00:14:40.360 --> 00:14:43.879 it look like legitimate reply traffic. Other tricks include specifying 275 00:14:43.879 --> 00:14:47.440 a small MTU maximum transmission unit, or even sending packets 276 00:14:47.440 --> 00:14:50.679 with deliberately bad checksums trying to confuse less robust systems. 277 00:14:50.759 --> 00:14:54.840 It's a fascinating technical duel. Okay, So reconnaissance done, Target scanned. 278 00:14:55.240 --> 00:14:58.919 Next up, vulnerability assessment. The guide talks about automated scanners here, 279 00:14:58.960 --> 00:15:01.679 like NESSUS or open v. You mentioned the pros and 280 00:15:01.720 --> 00:15:04.720 con speed versus stealth and accuracy. What's the critical takeaway 281 00:15:04.759 --> 00:15:06.519 for an ethical hacker using these tools? 282 00:15:06.759 --> 00:15:11.120 The main pro is clearly task. Automation scanners like NESSUS 283 00:15:11.120 --> 00:15:14.759 are incredibly fasted, checking for thousands of known vulnerabilities across 284 00:15:14.759 --> 00:15:18.240 many hosts, way faster than doing it manually. They handle 285 00:15:18.320 --> 00:15:22.399 the port scanning, service detection, and vulnerability checking steps automatically. 286 00:15:22.840 --> 00:15:26.320 NESSUS in particular is noted as being very capable, but 287 00:15:26.360 --> 00:15:29.320 the cons are significant. First, they are very loud. Their 288 00:15:29.399 --> 00:15:32.159 scanning generates a lot of network traffic that's easily detected 289 00:15:32.200 --> 00:15:36.440 by idsmp TO systems, not good for stealthy tests. Second, 290 00:15:36.679 --> 00:15:39.759 they can generate lots of false positives, reporting of vulnerability 291 00:15:39.759 --> 00:15:43.399 that isn't actually there, and potentially worse false negatives completely 292 00:15:43.480 --> 00:15:46.840 missing a vulnerability that does exist. So the takeaway is 293 00:15:47.159 --> 00:15:50.679 they're powerful aids, especially for broad coverage, but you absolutely 294 00:15:50.720 --> 00:15:53.639 cannot rely on them blindly. You need manual verification. The 295 00:15:53.720 --> 00:15:57.519 guide also mentions integrating NESSUS with metasploit, which is powerful 296 00:15:57.519 --> 00:15:59.960 scan for vulnerability and then immediately try to exploit it 297 00:16:00.120 --> 00:16:00.919 from one interface. 298 00:16:01.240 --> 00:16:04.960 Right, use the tool, but trust your own expertise to verify. Okay. 299 00:16:05.039 --> 00:16:09.080 The guide then gets into exploitation proper, starting with network sniffing. 300 00:16:09.480 --> 00:16:12.320 This always sounds very cloak and dagger. How do slippers 301 00:16:12.360 --> 00:16:14.919 work and what's this promiscuous mode about. 302 00:16:15.000 --> 00:16:18.679 Yeah, sniffing is basically eavesdropping on network traffic. The ease 303 00:16:18.720 --> 00:16:21.519 of doing it depends on the network setup. Old network 304 00:16:21.600 --> 00:16:24.919 hubs just repeated all traffic to every port on a hub, 305 00:16:25.039 --> 00:16:29.200 sniffing was trivial. Anyone could see everything. Modern switches are smarter. 306 00:16:29.559 --> 00:16:32.320 They learn which MPs I address lives on which port 307 00:16:32.559 --> 00:16:34.960 and only send traffic where it needs to go. This 308 00:16:35.039 --> 00:16:39.279 makes sniffing harder, but promiscuous mode is the key. Normally, 309 00:16:39.360 --> 00:16:42.559 your network card ignores traffic not addressed to it. In 310 00:16:42.639 --> 00:16:45.840 promiscuous mode, you tell the card capture everything you see 311 00:16:45.879 --> 00:16:48.799 on the wire, regardless of the destination address. If you 312 00:16:48.840 --> 00:16:51.039 can force traffic your way, you can then capture. 313 00:16:51.279 --> 00:16:53.879 Okay, so you need promiscuous mode to capture everything. How 314 00:16:53.879 --> 00:16:56.799 does an ARP spoofing attack then create that man in 315 00:16:56.840 --> 00:17:00.559 the middle MITM situation you mentioned, letting you actually intercept 316 00:17:00.559 --> 00:17:01.919 traffic uh. 317 00:17:02.159 --> 00:17:06.279 ARP spoofing or AARP poisoning. It exploits a fundamental trust 318 00:17:06.319 --> 00:17:10.119 in the ARP protocol. AIRP maps IP addresses logical to 319 00:17:10.319 --> 00:17:15.119 MSS addresses physical. The problem is AARP generally trusts replies 320 00:17:15.359 --> 00:17:19.680 without much verification, so an attacker sends out fake ARP replies. 321 00:17:20.079 --> 00:17:22.319 They might tell computer A that the router's IP address 322 00:17:22.319 --> 00:17:25.079 now belongs to the attackers m address and they tell 323 00:17:25.119 --> 00:17:28.279 the router that computer ASIP address belongs to the attackers MS. 324 00:17:29.039 --> 00:17:32.039 Both devices update their AARP caches with this false information, 325 00:17:32.119 --> 00:17:35.240 their caches are poisoned. Now all traffic between computer A 326 00:17:35.319 --> 00:17:37.720 and the router flows through the attackers machine. They're in 327 00:17:37.759 --> 00:17:40.960 the middle. Tools in the d sniff suite like arpspoof 328 00:17:41.000 --> 00:17:43.720 automate this and tools like wire shark are then used 329 00:17:43.720 --> 00:17:47.240 to analyze the captured traffic. May be filtering for httppos 330 00:17:47.240 --> 00:17:49.960 t request to grab usernames and passwords sent in clear text. 331 00:17:50.079 --> 00:17:52.680 Wow, so you trick the devices into sending their traffic 332 00:17:52.799 --> 00:17:55.960 straight to you? Can This MITM position also be used 333 00:17:55.960 --> 00:17:58.200 to hijack someone's active session even if you don't get 334 00:17:58.240 --> 00:18:00.400 their password, like take over their logedown accounts. 335 00:18:00.640 --> 00:18:04.720 Absolutely, that's session hijacking. If you're intercepting traffic, you can 336 00:18:04.759 --> 00:18:07.880 potentially steal the session cookie or token that a website 337 00:18:07.920 --> 00:18:10.440 gives a user after they log in. This cookie is 338 00:18:10.480 --> 00:18:12.720 what keeps them logged in as they browse different pages. 339 00:18:13.240 --> 00:18:15.799 If the attacker steals that cookie, they can often present 340 00:18:15.799 --> 00:18:18.519 it to the website themselves and gain access to the 341 00:18:18.599 --> 00:18:23.279 user's account, effectively impersonating them without needing the password. The 342 00:18:23.279 --> 00:18:26.799 big caveat here, though, is encryption. This primarily works if 343 00:18:26.799 --> 00:18:30.640 the communication is happening over unencrypted HTTP. If the site 344 00:18:30.720 --> 00:18:34.759 uses HTTPS properly, the traffic, including the session cookie, should 345 00:18:34.759 --> 00:18:38.720 be encrypted and protected from sniffing. Tools like SSL strip 346 00:18:38.920 --> 00:18:41.920 try to force connections down from HTTPS to HTTP to 347 00:18:42.000 --> 00:18:45.480 enable sniffing, but it's not always successful against well configured sites. 348 00:18:45.680 --> 00:18:49.519 Another strong vote for HTTPS everywhere. What about other network 349 00:18:49.559 --> 00:18:52.599 manipulation tricks like DHDP spoofing? How does that work? 350 00:18:52.960 --> 00:18:56.200 DHCP is how devices automatically get an IP address when 351 00:18:56.200 --> 00:19:01.000 they join a network. They broadcast a DACP request DACPE spoofing. 352 00:19:01.160 --> 00:19:03.759 The attacker tries to apply to that broadcast request faster 353 00:19:03.839 --> 00:19:07.279 than the legitimate DHCP server. If they succeed, they can 354 00:19:07.319 --> 00:19:10.720 provide the victim with malicious network configuration details. They could 355 00:19:10.720 --> 00:19:13.440 set the victim's default gateway to a non existent IP 356 00:19:13.759 --> 00:19:17.200 causing a denial of service, or more cleverly, they set 357 00:19:17.200 --> 00:19:20.200 the victim's default gateway to the attacker's own IP address. 358 00:19:20.640 --> 00:19:22.720 Now again, the attacker is the man in the middle 359 00:19:22.759 --> 00:19:25.279 for all the victims outbound traffic. They can also assign 360 00:19:25.279 --> 00:19:27.559 a malicious DNS server to redirect traffic. 361 00:19:28.039 --> 00:19:30.880 Very sneaky ways to intercept or disrupt traffic. Okay, let's 362 00:19:30.880 --> 00:19:34.759 shift focus a bit to remote exploitation. The guide talks 363 00:19:34.759 --> 00:19:39.319 about attacking services like FTP, SSHRDP, often by cracking passwords. 364 00:19:39.519 --> 00:19:40.880 What are the main strategies here? 365 00:19:41.079 --> 00:19:44.559 Password cracking against remote services usually falls into two cams 366 00:19:45.039 --> 00:19:51.039 brute force attack, trying every single possible combination of letters, numbers, symbols, 367 00:19:51.440 --> 00:19:56.000 exhaustive but incredibly slow and noisy dictionary attacks. This is 368 00:19:56.039 --> 00:19:59.960 usually preferred I penetration tests. You use precompiled lists, dictionary 369 00:20:00.160 --> 00:20:04.079 of common passwords, leaks passwords, words related to the company, usernames, etc. 370 00:20:04.640 --> 00:20:08.440 It's much faster because you're only trying plausible passwords, and 371 00:20:08.480 --> 00:20:12.640 depressingly often simpler default passwords are still in use. It 372 00:20:12.680 --> 00:20:15.640 really highlights that human element again. Tools like Hydra of 373 00:20:15.720 --> 00:20:18.480 Medusa and encrack are built for this. They can rapidly 374 00:20:18.480 --> 00:20:22.200 try dictionary words against various services like ssh, FTP, RDP 375 00:20:22.400 --> 00:20:23.079 and many others. 376 00:20:23.440 --> 00:20:25.839 It's always surprising how often the simple things work. And 377 00:20:26.200 --> 00:20:30.279 where does the famous metasplit framework fit into this exploitation phase. 378 00:20:30.359 --> 00:20:32.160 You called it the Swiss army knife earlier. 379 00:20:32.480 --> 00:20:36.000 It really is Central Metasplit is a huge framework containing 380 00:20:36.039 --> 00:20:39.480 not just exploits, but also tools for reconnaissance, payload generation, 381 00:20:39.759 --> 00:20:43.480 and post exploitation. It has auxiliary modules for things like 382 00:20:43.519 --> 00:20:47.759 scanning or fingerprinting, services like finding database versions, and then 383 00:20:47.839 --> 00:20:51.400 has thousands of exploit modules. Each targeting is specific known 384 00:20:51.519 --> 00:20:55.480 vulnerability in software or operating systems. For example, the classic 385 00:20:55.799 --> 00:20:59.200 MS zero eight zero six seven NETAPI exploit against older 386 00:20:59.240 --> 00:21:02.000 window systems is in there. When you run an exploit, 387 00:21:02.039 --> 00:21:04.319 you typically pair it with a payload. The most powerful 388 00:21:04.319 --> 00:21:07.279 one is often Materpreter. Interpreter gives you an advanced shell 389 00:21:07.359 --> 00:21:10.359 on the compromise system, allowing you to run commands, upload 390 00:21:10.400 --> 00:21:15.200 download files, escalate privileges, take screenshots, log keystrokes, pivot to 391 00:21:15.240 --> 00:21:20.079 other systems. It's incredibly versatile. GUIs like Armitage make managing 392 00:21:20.079 --> 00:21:23.920 metasploit easier too. It basically streamlines the entire process from 393 00:21:23.920 --> 00:21:25.880 finding a flaw to gaining deep control. 394 00:21:26.319 --> 00:21:30.759 Okay, so metaspoint automates enhances the whole exploit process, now 395 00:21:30.839 --> 00:21:34.160 shifting from servers back to user's client side exploitation. This 396 00:21:34.279 --> 00:21:37.759 targets us the end users, right. What are common scenarios, 397 00:21:37.880 --> 00:21:40.839 especially if the user is behind firewalls exactly. 398 00:21:41.359 --> 00:21:45.480 Client side attacks are potent because they bypass perimeter defenses 399 00:21:45.920 --> 00:21:48.960 by targeting the user inside the network. As the guide 400 00:21:49.000 --> 00:21:51.880 bluntly puts it, there is no patch to human stupidity. 401 00:21:52.480 --> 00:21:54.880