WEBVTT 1 00:00:00.120 --> 00:00:03.799 Welcome to the deep dive. You know, our networks, whether 2 00:00:03.839 --> 00:00:07.400 at home or in the enterprise, they can often feel 3 00:00:07.400 --> 00:00:10.880 like a digital wild West. It's this vast landscape and 4 00:00:10.960 --> 00:00:15.519 it's incredibly tough to know what's really happening, like are 5 00:00:15.519 --> 00:00:18.199 those devices running what they should be? Are there any 6 00:00:18.519 --> 00:00:20.320 you know, hidden doors no one's noticed. 7 00:00:20.480 --> 00:00:22.440 Yeah, that's a really good way to put it. Visibility 8 00:00:22.559 --> 00:00:24.039 is a huge challenge exactly. 9 00:00:24.640 --> 00:00:27.359 So today we're embarking on a deep dive to uncover 10 00:00:27.440 --> 00:00:30.039 some of those secrets. We're focusing on a tool that's 11 00:00:30.039 --> 00:00:34.840 often called the Sheriff's multi Tool for Network Reconnaissance ah MAP. 12 00:00:35.079 --> 00:00:38.640 You got it. We're diving into the secrets of network cartography. 13 00:00:38.920 --> 00:00:43.240 A comprehensive guide to endmap by the renowned James Professor Messer. 14 00:00:43.679 --> 00:00:46.719 Our mission, well, it's to unlock how endmap can give 15 00:00:46.759 --> 00:00:50.759 you really unparalleled insight into your network right quickly, thoroughly, 16 00:00:50.920 --> 00:00:53.439 and help you become truly well informed. Doesn't matter if 17 00:00:53.479 --> 00:00:56.240 you're just curious or you know, prepping for a critical meeting. 18 00:00:56.359 --> 00:00:58.840 And what's truly fascinating here, I think is how end 19 00:00:58.880 --> 00:01:02.520 map at its core, it leverages the fundamental design of 20 00:01:02.560 --> 00:01:06.359 TCPIP itself to reveal what's beneath the surface. It's not 21 00:01:06.439 --> 00:01:11.280 just about seeing what's obviously visible, but understanding those subtle behaviors, 22 00:01:11.280 --> 00:01:14.359 the digital fingerprints that tell a much bigger story about 23 00:01:14.400 --> 00:01:17.879 a device. You know, it's OS, the services it's running. Yeah, 24 00:01:18.079 --> 00:01:21.840 little clues exactly. We'll explore how this tool really empowers 25 00:01:21.840 --> 00:01:25.239 you to see your network with nuclarity. 26 00:01:25.120 --> 00:01:27.840 Precisely so to kick us off. Then, for those who 27 00:01:27.920 --> 00:01:32.200 might be newer to this, how would you best define 28 00:01:32.319 --> 00:01:35.439 end map? What's its core purpose in the cybersecurity world? 29 00:01:35.760 --> 00:01:39.959 Well, fundamentally, ENDMP is a powerful network exploration tool and 30 00:01:40.000 --> 00:01:43.560 a security scanner. Its main job is to discover hosts 31 00:01:43.560 --> 00:01:46.280 and services on a computer network. It does this by 32 00:01:46.280 --> 00:01:49.879 sending packets and then analyzing the responses it gets back. 33 00:01:50.359 --> 00:01:53.879 It was originally created by this brilliant individual known as Feudor, 34 00:01:54.439 --> 00:01:57.640 and it has truly become well a cornerstone in the 35 00:01:57.640 --> 00:02:02.120 cybersecurity landscape. Absolutely essential for anyone managing or securing networks. 36 00:02:02.159 --> 00:02:03.879 And it's not just for specialized roles, is it. I 37 00:02:03.879 --> 00:02:06.040 mean you might even have and Mac installed right now 38 00:02:06.079 --> 00:02:06.879 without realizing it. 39 00:02:07.079 --> 00:02:10.039 Oh. Absolutely, It comes bundled with many Linux and UNI 40 00:02:10.159 --> 00:02:14.120 i X distributions, and it runs pretty much everywhere Windows, Apple, 41 00:02:14.159 --> 00:02:19.479 Mac Os, various other operating systems. It's remarkably ubiquitous, it really. 42 00:02:19.280 --> 00:02:23.080 Is, which brings up an important question that Professor Messer 43 00:02:23.159 --> 00:02:25.400 tackles head on in his guide. 44 00:02:25.560 --> 00:02:26.919 Yeah, the good or evil question? 45 00:02:27.080 --> 00:02:30.199 Exactly? Is end map inherently good or evil? What's the 46 00:02:30.240 --> 00:02:30.680 take there? 47 00:02:30.960 --> 00:02:33.879 His distinction is vital. End map is just a tool, 48 00:02:34.400 --> 00:02:37.360 that's it. Think of it like this. If you're driving 49 00:02:37.400 --> 00:02:40.439 by a house and notice a door proped open, end 50 00:02:40.439 --> 00:02:43.080 map helps you see that open door. It doesn't, then, 51 00:02:43.199 --> 00:02:45.280 you know, prompt you to stop the car, walk in 52 00:02:45.360 --> 00:02:46.280 and steal the television. 53 00:02:46.360 --> 00:02:47.560 Right, it's just observation. 54 00:02:47.960 --> 00:02:52.280 It's about reconnaissance, gathering information. Now that info it can 55 00:02:52.319 --> 00:02:55.199 be used by good guys to make network safer, right, 56 00:02:55.439 --> 00:02:58.199 find vulnerabilities before the bad guys do. Or yeah, it 57 00:02:58.240 --> 00:03:00.520 can be used by bad guys looking for a weaknesses. 58 00:03:00.759 --> 00:03:04.680 The power of the tool brings significant responsibility. It's absolutely 59 00:03:04.800 --> 00:03:09.639 essential to use it with permission and strong ethical considerations. 60 00:03:10.199 --> 00:03:15.280 That analogy really highlights the responsibility involved. Okay, so let's 61 00:03:15.479 --> 00:03:17.560 pull back the curtain a bit and explore the nitty 62 00:03:17.560 --> 00:03:23.400 gritty how exactly does this powerful digital sheriff actually do 63 00:03:23.520 --> 00:03:27.280 its reconnaissance duties? You mentioned its primary interface is the 64 00:03:27.280 --> 00:03:28.120 command line. 65 00:03:28.520 --> 00:03:30.719 Yeah, that's right. The command line is definitely where end 66 00:03:30.719 --> 00:03:32.919 map shines. I mean there have been graphical front ends 67 00:03:32.960 --> 00:03:33.960 over the years, sure. 68 00:03:33.840 --> 00:03:35.800 Like in map bever MP WIN, though I think that 69 00:03:35.840 --> 00:03:36.520 was pretty old. 70 00:03:36.400 --> 00:03:39.319 Now, Yeah, exactly, But mastering the command line gives you 71 00:03:39.439 --> 00:03:43.000 such granular control over every single aspect of a scan, 72 00:03:43.319 --> 00:03:46.000 meaning meaning you're telling and Matt precisely what to do 73 00:03:46.120 --> 00:03:48.599 and how to do it, like what kind of packets 74 00:03:48.639 --> 00:03:52.319 to send, how quickly to send them, which hosts to target, everything, 75 00:03:52.560 --> 00:03:55.759 And that level of control is really key to its effectiveness. 76 00:03:55.840 --> 00:03:58.479 Okay, So if end map is sending and receiving packets 77 00:03:58.479 --> 00:04:01.840 to map a network, us rely heavily on well our 78 00:04:01.879 --> 00:04:03.240 old friend TCPIP. 79 00:04:03.479 --> 00:04:09.680 Oh absolutely, nmp's magic is entirely built upon understanding TCPIP fundamentals. 80 00:04:10.039 --> 00:04:11.840 Can you give us a quick refresher on the core 81 00:04:11.879 --> 00:04:12.960 protocols it leverages? 82 00:04:13.319 --> 00:04:17.360 Sure thing. So first, there's IP, the Internet protocol. Think 83 00:04:17.360 --> 00:04:19.480 of it as like the truck for hire that carries 84 00:04:19.560 --> 00:04:23.079 data shipments across the network roads. It's focused on getting 85 00:04:23.160 --> 00:04:25.560 data from point A to point B. Doesn't worry too 86 00:04:25.639 --> 00:04:29.120 much about what's inside the package. These IP trucks, they 87 00:04:29.199 --> 00:04:32.800 navigate routers and firewalls, which can either pass them along 88 00:04:32.959 --> 00:04:33.720 or just drop them. 89 00:04:33.839 --> 00:04:35.480 Got it, just delivery pretty much. 90 00:04:35.920 --> 00:04:40.319 Then you have TCP, the Transmission Control protocol. Now this 91 00:04:40.360 --> 00:04:44.720 one is very formal, very proper. Before any data is sent, 92 00:04:45.000 --> 00:04:48.959 TCP establishes a reliable connection. It uses what's known as 93 00:04:49.000 --> 00:04:52.199 the three way handshake. You send an sym packet, the 94 00:04:52.199 --> 00:04:55.519 other side responds with a sinak, and you finish with 95 00:04:55.560 --> 00:04:58.519 an ACK to confirm Okay, we're connected, now we can talk. 96 00:04:58.959 --> 00:05:02.639 This connection orient approach is something end map frequently exploits 97 00:05:02.680 --> 00:05:05.120 to figure out if ports are open on the other 98 00:05:05.160 --> 00:05:08.439 side of the coin. Is UDP, the User Datagram Protocol. 99 00:05:08.680 --> 00:05:13.560 It's TCP's polar opposite. So informal totally, it's connectionless. Yeah, 100 00:05:13.600 --> 00:05:15.720 a fire and forget kind of approach. It just sends 101 00:05:15.759 --> 00:05:17.279 the data, doesn't wait for confirmation. 102 00:05:17.519 --> 00:05:19.240 Why would you use that, Well, it's great for. 103 00:05:19.199 --> 00:05:22.120 Real time stuff like voice or video streaming, where speed 104 00:05:22.240 --> 00:05:25.759 is more important than catching every single dropped packet. Losing 105 00:05:25.839 --> 00:05:27.759 a tiny fraction of data isn't critical. 106 00:05:27.759 --> 00:05:29.680 There makes sense, and the last one. 107 00:05:29.920 --> 00:05:34.720 Ah, Yes, ICMP, the Internet Control Message Protocol. This one 108 00:05:34.759 --> 00:05:36.720 is really the tattletale of the network. 109 00:05:37.079 --> 00:05:37.360 Okay. 110 00:05:37.399 --> 00:05:40.439 If something goes wrong, like a port isn't reachable, or 111 00:05:40.480 --> 00:05:42.399 even if a host is just a live and kicking, 112 00:05:42.920 --> 00:05:46.439 ICMP messages often tell you about it. Think port unreachable 113 00:05:46.639 --> 00:05:49.600 errors or the echo replies you get when you ping a. 114 00:05:49.560 --> 00:05:51.680 Device right the classic ping exactly. 115 00:05:51.879 --> 00:05:54.519 En map uses ICMP a lot for figuring out if 116 00:05:54.560 --> 00:05:58.759 hosts are online, though many organizations do restrict ICMP in 117 00:05:58.800 --> 00:06:00.000 their firewalls these days. 118 00:06:00.120 --> 00:06:01.839 So NMAP has to be clever about that. 119 00:06:01.800 --> 00:06:04.959 Too, oh absolutely. And what's truly clever is how NMAP 120 00:06:05.040 --> 00:06:10.040 often exploits minor anomalies, tiny differences in how different operating 121 00:06:10.079 --> 00:06:14.879 systems implement these standard protocols to gather its incredibly detailed information. 122 00:06:15.000 --> 00:06:18.079 It's like reading between the lines of the network conversation. 123 00:06:18.560 --> 00:06:21.920 That's fascinating. That's the real intelligence behind it. Okay, So 124 00:06:21.959 --> 00:06:25.040 when enmap actually goes to work, what are the key 125 00:06:25.040 --> 00:06:28.079 steps it usually takes to build that initial picture of 126 00:06:28.120 --> 00:06:29.199 a network or a host. 127 00:06:29.800 --> 00:06:33.560 Well, it follows a pretty systematic process, usually four main steps. First, 128 00:06:33.560 --> 00:06:36.959 if you give it a host name like www. Dot 129 00:06:37.000 --> 00:06:40.560 example dot com. MP performs a DNS look up to 130 00:06:40.680 --> 00:06:44.480 resolve that name into an IP address. And remember this 131 00:06:44.560 --> 00:06:46.680 step can leave traces in DNS logs. 132 00:06:47.279 --> 00:06:49.879 Good points stealth consideration right there, what's next. 133 00:06:50.079 --> 00:06:53.279 Second, NMAP does some form of host discovery. It's often 134 00:06:53.319 --> 00:06:56.000 called a ping scan, but it's not always just a 135 00:06:56.040 --> 00:07:01.000 traditional icmpping. NMP has many sophisticated ways to confirm if 136 00:07:01.000 --> 00:07:03.279 the target host is actually active and online. 137 00:07:03.360 --> 00:07:05.720 Okay, so it checks that the lights are on basically exactly. 138 00:07:05.839 --> 00:07:08.199 Third, it often performs a reversity and S look up. 139 00:07:08.240 --> 00:07:10.199 It takes the IP address it found and tries to 140 00:07:10.199 --> 00:07:12.800 find the host name associated with it. This can sometimes 141 00:07:12.879 --> 00:07:15.120 reveal the canonical name, which might be different from what 142 00:07:15.160 --> 00:07:16.399 you initially typed in. 143 00:07:16.160 --> 00:07:17.759 Interesting, and the final step. 144 00:07:17.639 --> 00:07:22.920 Only after those first three preparatory steps, the reconnaissance, if 145 00:07:22.959 --> 00:07:24.879 you will, does it move to the fourth and final 146 00:07:24.879 --> 00:07:29.360 stage executing the actual scan. That's when it starts actively 147 00:07:29.560 --> 00:07:34.000 probing for open ports, trying to identify the operating system, 148 00:07:34.319 --> 00:07:35.920 detect software versions, and so on. 149 00:07:36.120 --> 00:07:38.279 I see, so it does its homework before the main event. 150 00:07:38.480 --> 00:07:41.120 And what's really interesting you mentioned is that you can 151 00:07:41.160 --> 00:07:43.800 control almost every one of these steps absolutely to fine 152 00:07:43.800 --> 00:07:47.240 tune your scan, making it as quiet or as loud 153 00:07:47.439 --> 00:07:48.920 as you needed to be exactly. 154 00:07:49.120 --> 00:07:52.040 That control is paramount. It lets you tailor your approach 155 00:07:52.120 --> 00:07:56.920 for different network environments, different security policies, or different levels 156 00:07:56.920 --> 00:07:57.839 of desired stealth. 157 00:07:58.000 --> 00:07:59.839 Right. So if we connect this to the bigger picture, 158 00:08:00.199 --> 00:08:02.759 ENDMAP isn't just blindly firing off packets. 159 00:08:02.839 --> 00:08:03.480 No, not at all. 160 00:08:03.519 --> 00:08:06.319 It's an intelligent system and it's backed by what you 161 00:08:06.399 --> 00:08:09.879 called a rich Intel briefing its support files. Yeah, can 162 00:08:09.920 --> 00:08:11.519 you tell us a bit about those? What kind of 163 00:08:11.519 --> 00:08:12.600 Intel is in there? Yeah? 164 00:08:12.639 --> 00:08:15.959 Absolutely. These files are crucial for enmap to provide its 165 00:08:16.000 --> 00:08:19.360 detailed insights. They act like its reference library. For instance, 166 00:08:19.399 --> 00:08:23.399 there's NMAP MAC prefixes. This file. Let's enmap identify the 167 00:08:23.439 --> 00:08:26.040 hardware manufacturer just from the first few bytes of a 168 00:08:26.120 --> 00:08:29.120 mass address. So if it sees a MAXC starting with 169 00:08:29.279 --> 00:08:31.680 say zero point one, one point four to three, it 170 00:08:31.720 --> 00:08:34.279 immediately knows, ah, that's likely Adell. 171 00:08:34.120 --> 00:08:35.559 Device handy for inventory. 172 00:08:35.919 --> 00:08:40.840 Very then you've got nmp OSDB and NMPOS fingerprints. These 173 00:08:40.879 --> 00:08:44.519 contain massive collections of unique responses those minor anomalies we 174 00:08:44.559 --> 00:08:47.879 talked about from different operating systems. That's how enmap makes 175 00:08:48.000 --> 00:08:51.200 educated guesses about whether a target is running Windows, Linux, 176 00:08:51.360 --> 00:08:54.120 macOS or something else entirely. 177 00:08:53.840 --> 00:08:55.799 The OS fingerprinting parts precisely. 178 00:08:55.960 --> 00:08:58.679 And then there's end map Service probes. This file houses 179 00:08:58.720 --> 00:09:01.759 application fingerprints. It helps end up figure out not just 180 00:09:01.799 --> 00:09:04.080 that something is running on a port, but what specific 181 00:09:04.120 --> 00:09:06.799 application and version it is, Like is it a patche 182 00:09:06.879 --> 00:09:09.480 version two point four point five to two or Microsoft 183 00:09:09.480 --> 00:09:10.639 ISA ten point zero. 184 00:09:10.799 --> 00:09:12.279 That's incredibly detailed it is. 185 00:09:12.360 --> 00:09:15.879 And there's even that memorable anecdote about TCP port ninety 186 00:09:15.960 --> 00:09:16.440 one hundred. 187 00:09:16.519 --> 00:09:18.399 Oh yeah, the printer story, Uh huh yeah. 188 00:09:18.679 --> 00:09:20.759 Enmap used to send probes to that port, which is 189 00:09:20.799 --> 00:09:23.639 often used by network printers, and sometimes it would cause 190 00:09:23.679 --> 00:09:26.159 the printers to just spew out pages and pages of 191 00:09:26.240 --> 00:09:29.279 raw scan data exactly. So now endmap has an option 192 00:09:29.480 --> 00:09:33.480 specifically to exclude that port by default, just to avoid 193 00:09:34.039 --> 00:09:37.000 surprising the office staff with unexpected print jobs. 194 00:09:37.320 --> 00:09:41.320 That printer story really illustrates the practical impact and maybe 195 00:09:41.320 --> 00:09:45.759 the occasional unintended consequence of end maps intelligence. But how 196 00:09:45.840 --> 00:09:49.039 does it actually gather that intelligence from live devices? That's 197 00:09:49.039 --> 00:09:52.480 where it's diverse scanning methods come in right spot on. 198 00:09:52.759 --> 00:09:56.159 Each method offers a unique way to peer into the network. 199 00:09:56.360 --> 00:10:02.159 Professor Messer mentions over fifteen different scanning method that's a lot. 200 00:10:02.960 --> 00:10:04.600 What are some of the most critical ones we should 201 00:10:04.600 --> 00:10:05.320 really understand? 202 00:10:05.559 --> 00:10:07.759 Yeah, there are quite a few, but a handful really 203 00:10:07.799 --> 00:10:10.720 stand out because they illustrate different approaches and trade offs. 204 00:10:11.200 --> 00:10:13.879 The first, and often the most preferred, especially if you 205 00:10:13.879 --> 00:10:17.279 have the right permissions, is the TCP syn scan. The 206 00:10:17.279 --> 00:10:19.000 command is nasha S. 207 00:10:19.080 --> 00:10:22.240 Nash ss okay. Why is it preferred, Well. 208 00:10:22.039 --> 00:10:25.799 It's generally the stealthiest option for users with privileged access, 209 00:10:25.840 --> 00:10:28.559 meaning you have administrator or route permissions on the system 210 00:10:28.600 --> 00:10:29.639 you're scanning from. 211 00:10:29.480 --> 00:10:30.919 Right, you need special rights. 212 00:10:31.120 --> 00:10:35.200 Yes, it's often called half open scanning. Here's why. N 213 00:10:35.240 --> 00:10:37.960 MAP sends an s yn packet just like starting a 214 00:10:37.960 --> 00:10:41.200 normal connection. If it gets a sign response back that 215 00:10:41.279 --> 00:10:44.159 indicates the port is open okay, But then instead of 216 00:10:44.200 --> 00:10:48.120 sending the final ACK to complete the connection, NMP immediately 217 00:10:48.159 --> 00:10:52.600 sends a RST or reset packet. It basically hangs up 218 00:10:52.759 --> 00:10:54.679 right after hearing the phone get picked up. 219 00:10:54.919 --> 00:10:56.799 Ah, So it never fully connects. 220 00:10:56.559 --> 00:10:59.960 Exactly, it never completes the full TCP three way handshake. 221 00:11:00.360 --> 00:11:02.759 Think of it like knocking on a door. Hearing someone 222 00:11:02.799 --> 00:11:06.039 say come in and then immediately backing away. So it's quiet, 223 00:11:06.320 --> 00:11:09.919 very quiet from the applications perspective. Since the connection isn't 224 00:11:09.960 --> 00:11:13.960 fully established, the target application often doesn't even log the attempt. 225 00:11:14.200 --> 00:11:16.559 Makes it very hard to detect on the server side 226 00:11:16.600 --> 00:11:17.519 through normal logs. 227 00:11:17.600 --> 00:11:20.960 Right nas SS the default for privileged users. What if 228 00:11:20.960 --> 00:11:22.080 you don't have those privileges. 229 00:11:22.200 --> 00:11:25.559 Right for non privileged users, or maybe when an syn 230 00:11:25.600 --> 00:11:28.679 scan just isn't feasible for some reason, there's the TCP 231 00:11:28.840 --> 00:11:33.320 connect scan. That's sast S connect scan yep. This scan 232 00:11:33.519 --> 00:11:36.720 uses the operating system's standard connect system call to try 233 00:11:36.720 --> 00:11:40.200 and establish a full connection. It performs the complete three 234 00:11:40.279 --> 00:11:43.600 way handshake, just like any normal application like your web 235 00:11:43.600 --> 00:11:45.200 browser connecting to a website. 236 00:11:45.320 --> 00:11:46.679 Okay, so it fully connects. 237 00:11:46.799 --> 00:11:49.759 What's the downside, Well, the downside is that it's much louder. 238 00:11:50.039 --> 00:11:53.360 Because it establishes a full connection, the target application will 239 00:11:53.360 --> 00:11:56.360 see it and will likely log it. So if stealth 240 00:11:56.440 --> 00:11:59.159 is a priority, this is often considered the scam of 241 00:11:59.240 --> 00:12:00.240 last resort. 242 00:12:00.120 --> 00:12:03.039 Makes sense louder but doesn't need special permissions. 243 00:12:03.039 --> 00:12:05.759 What else, then we have a really interesting family of scans, 244 00:12:05.799 --> 00:12:09.960 often just called stealth scans. These include the sin scan 245 00:12:10.120 --> 00:12:13.799 dash SF, the Xmas tree scan dash SX, and the 246 00:12:13.919 --> 00:12:15.000 null scans. 247 00:12:14.720 --> 00:12:17.120 Dashes N Xmas tree. That's a name, haha. 248 00:12:17.240 --> 00:12:19.399 Yeah, it gets its name because it sets a bunch 249 00:12:19.399 --> 00:12:23.600 of flags in the TCP header fin psh RG, lighting 250 00:12:23.600 --> 00:12:25.200 it up like a Christmas tree. Supposedly. 251 00:12:25.320 --> 00:12:26.600 Okay, so what do these do? 252 00:12:26.759 --> 00:12:30.240 These are incredibly quiet. They send these unusual TCP package 253 00:12:30.320 --> 00:12:33.240 just a FIN flag or just nothing null or the 254 00:12:33.360 --> 00:12:36.480 Xmas combo without any syn first, no handshake involved at all. 255 00:12:36.600 --> 00:12:38.240 And the idea is the. 256 00:12:38.320 --> 00:12:41.200 Idea based on the TCP standards, is that if a 257 00:12:41.240 --> 00:12:44.080 port is closed, the receiving system should respond with the 258 00:12:44.200 --> 00:12:47.399 RST packet. If the port is open, it should just 259 00:12:47.519 --> 00:12:50.679 drop the weird packet and send nothing back. So no 260 00:12:50.759 --> 00:12:54.440 response means potentially open. They're designed to fly under the radar, 261 00:12:54.720 --> 00:12:58.240 often won't trigger application logs because no connection is attempted. 262 00:12:58.360 --> 00:12:59.679 This sounds super stealthy. 263 00:13:00.120 --> 00:13:02.440 But there's a catch, right, There is a big catch, 264 00:13:02.480 --> 00:13:05.440 and this is where it gets really interesting. They are 265 00:13:05.679 --> 00:13:11.240 largely ineffective against Windows based systems. Why is that Microsoft 266 00:13:11.240 --> 00:13:14.279 decided way back not to implement that part of the 267 00:13:14.320 --> 00:13:17.559 TCP standards strictly so Window systems will typically send back 268 00:13:17.600 --> 00:13:21.000 a RST for all ports when scanned with these fan 269 00:13:21.240 --> 00:13:23.879 x MISS or null methods, regardless of whether the port 270 00:13:23.919 --> 00:13:25.240 is actually open or close. 271 00:13:25.559 --> 00:13:28.679 So scanning Windows with these just shows everything is closed. 272 00:13:28.360 --> 00:13:31.000 Pretty much, which means if you do run one of 273 00:13:31.039 --> 00:13:33.799 these scans and you actually see open ports reported h, 274 00:13:34.360 --> 00:13:34.639 then you. 275 00:13:34.639 --> 00:13:37.600 Can be freely certain the target is not Windows exactly. 276 00:13:37.639 --> 00:13:40.639 It becomes a sort of reverse OS finger printing technique, 277 00:13:40.840 --> 00:13:44.120 and like the syn scan, these also require privileged access 278 00:13:44.120 --> 00:13:45.559 to craft those custom packets. 279 00:13:45.879 --> 00:13:49.399 Fascinating. Okay, what about that really clever sounding one, the 280 00:13:49.559 --> 00:13:50.200 idle scan? 281 00:13:50.440 --> 00:13:55.360 Ah, Yes, Idle stan dash I. This one is truly ingenious. 282 00:13:55.519 --> 00:13:58.679 It lets you scan a remote target without sending any 283 00:13:58.759 --> 00:14:02.279 packets directly from your own IP address to that target. 284 00:14:02.360 --> 00:14:03.559 How's that even possible? 285 00:14:03.759 --> 00:14:07.799 It uses a zombie workstation, basically another machine on the Internet, 286 00:14:07.919 --> 00:14:10.799 ideally one that's not doing much traffic, hence idle. 287 00:14:10.919 --> 00:14:11.919 Okay, zombie. 288 00:14:12.039 --> 00:14:15.080 Your n map station sends packets to the zombie, but 289 00:14:15.240 --> 00:14:17.320 spoofs the source address so they look like they came 290 00:14:17.360 --> 00:14:20.559 from the target. Then n map observes how the zombie's 291 00:14:20.559 --> 00:14:24.799 IP identification number changes in response based on those subtle changes, 292 00:14:25.000 --> 00:14:27.679 en map can deduce whether the target machine responded to 293 00:14:27.759 --> 00:14:29.879 probes that were seemingly sent by the zombie. 294 00:14:30.159 --> 00:14:33.240 WHOA, okay, let me process that you bounce the scan 295 00:14:33.360 --> 00:14:35.399 off an intermediate idle machine. 296 00:14:35.559 --> 00:14:38.559 Essentially, yes, you're making it appear as if the scam 297 00:14:38.720 --> 00:14:43.159 originates entirely from the zombie, not from you. It's incredibly 298 00:14:43.200 --> 00:14:46.159 stealthy for hiding your end map station's IP address. What 299 00:14:46.200 --> 00:14:49.000 are the requirements, Well, the main one is finding a 300 00:14:49.080 --> 00:14:52.519 suitable zombie, a machine that's truly idle and has a 301 00:14:52.519 --> 00:14:57.039 predictable IPID sequence number generation. That can be tricky. And 302 00:14:57.120 --> 00:14:59.960 again you need privileged access for the IP spoofing part. 303 00:15:00.120 --> 00:15:04.480 Wow, that's some advanced stuff. One more, maybe the ACK. 304 00:15:04.200 --> 00:15:07.720 Scan right, the ACK scan desha This one is different again, 305 00:15:07.759 --> 00:15:09.039 it's like taking an X ray. 306 00:15:08.919 --> 00:15:10.279 Of a firewall MX ray. 307 00:15:10.399 --> 00:15:13.559 Yeah, it sends a TCP packet with only the ACK 308 00:15:13.679 --> 00:15:17.639 flag set. Now, according to TCP rules, an ACK packet 309 00:15:17.639 --> 00:15:20.360 should only be sent in response to an established connection, 310 00:15:20.519 --> 00:15:22.600 so sending one out of the blue is unusual. 311 00:15:22.840 --> 00:15:24.519 And how do systems react if the. 312 00:15:24.480 --> 00:15:27.120 Packet reaches the target host, meaning it wasn't blocked by 313 00:15:27.120 --> 00:15:30.320 a firewall. The host should respond with an RST packet 314 00:15:30.360 --> 00:15:33.679 because there's no actual connection corresponding to that ACK. If 315 00:15:33.679 --> 00:15:36.639 a firewall blocks the ACK packet, you'll get no response 316 00:15:36.679 --> 00:15:38.480 back or maybe an ICMP error. 317 00:15:38.559 --> 00:15:39.879 So it didn't tell you if the port is open 318 00:15:39.960 --> 00:15:40.399 or closed. 319 00:15:40.639 --> 00:15:44.120 Correct, it tells you if the port is filtered, blocked 320 00:15:44.120 --> 00:15:48.000 by a firewall, or unfiltered reachable by the ACK packet. 321 00:15:48.440 --> 00:15:52.000 It's fantastic for mapping out firewall rule sets, understanding what 322 00:15:52.080 --> 00:15:55.639 kind of traffic the firewall permits through without triggering any application. 323 00:15:55.759 --> 00:15:58.639 Logs on the actual target system behind the. 324 00:15:58.559 --> 00:16:04.039 Firewall useful for understanding defenses. And this needs privileged access to. 325 00:16:04.279 --> 00:16:07.240 Yes, it does to craft that specific ACK packet. 326 00:16:07.279 --> 00:16:10.240 Okay, So we have these different scan types, some stealthier 327 00:16:10.240 --> 00:16:12.639 than others. Now, if you want to become a true 328 00:16:12.679 --> 00:16:16.840 network ninja, you know, gathering intelligence without leaving footprints, and 329 00:16:17.039 --> 00:16:20.080 MAP offers this incredible array of options to control your 330 00:16:20.080 --> 00:16:23.320 scans behavior even further, How can we really minimize our 331 00:16:23.360 --> 00:16:24.120 presence expert? 332 00:16:24.279 --> 00:16:27.320 Right? This is where nmp's precision tuning comes in. There 333 00:16:27.360 --> 00:16:30.399 are several key tactics. First, remember those initial steps end 334 00:16:30.399 --> 00:16:34.799 map takes one was host discovery often a ping. By default, 335 00:16:35.080 --> 00:16:37.679 end map pings to confirm a host is alive before 336 00:16:37.759 --> 00:16:41.159 launching the main scan. But if stealth is your primary goal, 337 00:16:41.279 --> 00:16:43.360 or maybe you already know the host is up from 338 00:16:43.440 --> 00:16:46.639 priory come you skip the ping exactly. You can tell 339 00:16:46.759 --> 00:16:49.399 en map not to ping before scanning. The option is 340 00:16:49.440 --> 00:16:53.960 EEDP zero or edd b N. This removes that initial 341 00:16:54.000 --> 00:16:57.720 hello conversation, minimizes your network traffic right at the start. 342 00:16:58.120 --> 00:17:01.000 M potentially avoids detection by SISS that might be watching 343 00:17:01.039 --> 00:17:03.759 for pink sweeps. A good ninja, as the saying goes 344 00:17:04.119 --> 00:17:05.839 already did their homework makes sense. 345 00:17:06.079 --> 00:17:07.640 Less chatter is better. What else? 346 00:17:07.839 --> 00:17:12.240 Another tactic involves DNS. Remember n map often does reverse DNS. 347 00:17:12.000 --> 00:17:14.079 Lockups yeah to get host names from IPS. 348 00:17:14.240 --> 00:17:17.119 Well, those lookups can be slow, and more importantly, they 349 00:17:17.119 --> 00:17:20.400 get logged by the DNS servers being queried. So if 350 00:17:20.400 --> 00:17:22.720 you want to keep your activity off those DNS logs, 351 00:17:22.720 --> 00:17:26.480 you can use the nyn option to disable reverse DNS lockups. 352 00:17:26.160 --> 00:17:28.519 Entirely none for no name resolution. 353 00:17:28.200 --> 00:17:32.000 Precisely, or for the truly meticulous ninja, you might prepopulate 354 00:17:32.039 --> 00:17:34.839 your local hosts file with the target IPS and names. 355 00:17:35.160 --> 00:17:38.279 That way, the resolution happens entirely on your machine, completely 356 00:17:38.319 --> 00:17:39.039 off the network. 357 00:17:39.440 --> 00:17:42.519 Very stealthy. Okay, what about speed versus stealthy? 358 00:17:42.559 --> 00:17:45.759 Ah, that's where timing policies come in. NMP gives you 359 00:17:45.799 --> 00:17:48.839 amazing control over how fast or slow your scan runs 360 00:17:49.119 --> 00:17:51.720 using the NST option followed by a number from zero 361 00:17:51.759 --> 00:17:53.200 to five or a name like. 362 00:17:53.160 --> 00:17:55.960 The SC zero or an AST five exactly. 363 00:17:56.319 --> 00:18:00.839 Nakshi zero is paranoid. It's incredibly slow. End map inserts 364 00:18:00.880 --> 00:18:05.039 significant delays, sometimes up to five minutes between sending probes. 365 00:18:04.839 --> 00:18:07.039 Five minutes between packets. Wow. 366 00:18:07.279 --> 00:18:09.720 Yeah, it makes the scan take forever, but it's almost 367 00:18:09.839 --> 00:18:14.599 undetectable by rate based intrusion detection systems. On the other extreme, 368 00:18:14.759 --> 00:18:19.559 natchy st five is insane, lightening fast, very aggressive, sense 369 00:18:19.599 --> 00:18:20.680 packets as quickly as. 370 00:18:20.680 --> 00:18:22.839 Possible, which could easily trigger alarms. 371 00:18:22.960 --> 00:18:26.640 Oh definitely. But these timing policies are invaluable. You can 372 00:18:26.720 --> 00:18:29.680 use them to gently probe a network without causing disruption. 373 00:18:29.960 --> 00:18:33.000 Nashty two two or polite is off the good. Or 374 00:18:33.039 --> 00:18:35.680 you can use the faster modes to say, stress test 375 00:18:35.680 --> 00:18:39.119 an intrusion detection or prevention system IDSP and see at 376 00:18:39.160 --> 00:18:42.640 what point it actually triggers Understanding those thresholds. 377 00:18:42.079 --> 00:18:44.160 Is crucial, so you can dial the aggression up or down. 378 00:18:44.359 --> 00:18:47.000 Oh cool, I heard. You can also use decoys make 379 00:18:47.039 --> 00:18:48.799 it look like the scan is coming from somewhere else. 380 00:18:48.880 --> 00:18:52.200 Yes, that's the decoys option, Ashid. This is quite clever. 381 00:18:52.559 --> 00:18:54.680 You provide enmat with a list of IP addresses the 382 00:18:54.680 --> 00:18:57.359 decoys along with your own real IP, or you can 383 00:18:57.440 --> 00:19:00.599 use me to represent your IP NMP, then send scan 384 00:19:00.759 --> 00:19:04.359 packets seemingly originating from all those decoy addresses, mixed in 385 00:19:04.400 --> 00:19:07.119 with packets from your real address. The idea is to 386 00:19:07.160 --> 00:19:10.279 flood the logs with bogus source ips, making it much 387 00:19:10.319 --> 00:19:13.240 harder for network defenders to figure out where the actual 388 00:19:13.319 --> 00:19:14.519 scan originated. 389 00:19:14.680 --> 00:19:16.640 So you hide in the noise you create. 390 00:19:16.759 --> 00:19:19.480 Pretty much. You can even omit your real IP entirely, 391 00:19:19.599 --> 00:19:22.599 though that's obviously less useful if you need replies back. 392 00:19:23.119 --> 00:19:27.240 There's a caution here though, If you use decoyips that 393 00:19:27.279 --> 00:19:30.759 don't actually exist or belong to machines that aren't online, 394 00:19:30.839 --> 00:19:34.519 you could inadvertently cause a s yn flood on your target, 395 00:19:35.160 --> 00:19:38.359 because the target might try to send soyanac replies back 396 00:19:38.400 --> 00:19:41.039 to those non existent decoys using up its own resources 397 00:19:41.079 --> 00:19:44.319 waiting for ACKs that will never arrive. It could potentially 398 00:19:44.319 --> 00:19:48.440 disrupt the target's service, so use decoys responsibly. And yes, 399 00:19:48.519 --> 00:19:50.839 this needs privileged access for the IP spoofing. 400 00:19:50.920 --> 00:19:53.960 Good warning. Okay, what about hiding on the local network right? 401 00:19:54.079 --> 00:19:56.559