Speaker 1: Welcome to the deep dive. You know, our networks, whether
Speaker 1: at home or in the enterprise, they can often feel
Speaker 1: like a digital wild West. It's this vast landscape and
Speaker 1: it's incredibly tough to know what's really happening, like are
Speaker 1: those devices running what they should be? Are there any
Speaker 1: you know, hidden doors no one's noticed.
Speaker 2: Yeah, that's a really good way to put it. Visibility
Speaker 2: is a huge challenge exactly.
Speaker 1: So today we're embarking on a deep dive to uncover
Speaker 1: some of those secrets. We're focusing on a tool that's
Speaker 1: often called the Sheriff's multi Tool for Network Reconnaissance ah MAP.
Speaker 1: You got it. We're diving into the secrets of network cartography.
Speaker 1: A comprehensive guide to endmap by the renowned James Professor Messer.
Speaker 1: Our mission, well, it's to unlock how endmap can give
Speaker 1: you really unparalleled insight into your network right quickly, thoroughly,
Speaker 1: and help you become truly well informed. Doesn't matter if
Speaker 1: you're just curious or you know, prepping for a critical meeting.
Speaker 2: And what's truly fascinating here, I think is how end
Speaker 2: map at its core, it leverages the fundamental design of
Speaker 2: TCPIP itself to reveal what's beneath the surface. It's not
Speaker 2: just about seeing what's obviously visible, but understanding those subtle behaviors,
Speaker 2: the digital fingerprints that tell a much bigger story about
Speaker 2: a device. You know, it's OS, the services it's running. Yeah,
Speaker 2: little clues exactly. We'll explore how this tool really empowers
Speaker 2: you to see your network with nuclarity.
Speaker 1: Precisely so to kick us off. Then, for those who
Speaker 1: might be newer to this, how would you best define
Speaker 1: end map? What's its core purpose in the cybersecurity world?
Speaker 2: Well, fundamentally, ENDMP is a powerful network exploration tool and
Speaker 2: a security scanner. Its main job is to discover hosts
Speaker 2: and services on a computer network. It does this by
Speaker 2: sending packets and then analyzing the responses it gets back.
Speaker 2: It was originally created by this brilliant individual known as Feudor,
Speaker 2: and it has truly become well a cornerstone in the
Speaker 2: cybersecurity landscape. Absolutely essential for anyone managing or securing networks.
Speaker 1: And it's not just for specialized roles, is it. I
Speaker 1: mean you might even have and Mac installed right now
Speaker 1: without realizing it.
Speaker 2: Oh. Absolutely, It comes bundled with many Linux and UNI
Speaker 2: i X distributions, and it runs pretty much everywhere Windows, Apple,
Speaker 2: Mac Os, various other operating systems. It's remarkably ubiquitous, it really.
Speaker 1: Is, which brings up an important question that Professor Messer
Speaker 1: tackles head on in his guide.
Speaker 2: Yeah, the good or evil question?
Speaker 1: Exactly? Is end map inherently good or evil? What's the
Speaker 1: take there?
Speaker 2: His distinction is vital. End map is just a tool,
Speaker 2: that's it. Think of it like this. If you're driving
Speaker 2: by a house and notice a door proped open, end
Speaker 2: map helps you see that open door. It doesn't, then,
Speaker 2: you know, prompt you to stop the car, walk in
Speaker 2: and steal the television.
Speaker 1: Right, it's just observation.
Speaker 2: It's about reconnaissance, gathering information. Now that info it can
Speaker 2: be used by good guys to make network safer, right,
Speaker 2: find vulnerabilities before the bad guys do. Or yeah, it
Speaker 2: can be used by bad guys looking for a weaknesses.
Speaker 2: The power of the tool brings significant responsibility. It's absolutely
Speaker 2: essential to use it with permission and strong ethical considerations.
Speaker 1: That analogy really highlights the responsibility involved. Okay, so let's
Speaker 1: pull back the curtain a bit and explore the nitty
Speaker 1: gritty how exactly does this powerful digital sheriff actually do
Speaker 1: its reconnaissance duties? You mentioned its primary interface is the
Speaker 1: command line.
Speaker 2: Yeah, that's right. The command line is definitely where end
Speaker 2: map shines. I mean there have been graphical front ends
Speaker 2: over the years, sure.
Speaker 1: Like in map bever MP WIN, though I think that
Speaker 1: was pretty old.
Speaker 2: Now, Yeah, exactly, But mastering the command line gives you
Speaker 2: such granular control over every single aspect of a scan,
Speaker 2: meaning meaning you're telling and Matt precisely what to do
Speaker 2: and how to do it, like what kind of packets
Speaker 2: to send, how quickly to send them, which hosts to target, everything,
Speaker 2: And that level of control is really key to its effectiveness.
Speaker 1: Okay, So if end map is sending and receiving packets
Speaker 1: to map a network, us rely heavily on well our
Speaker 1: old friend TCPIP.
Speaker 2: Oh absolutely, nmp's magic is entirely built upon understanding TCPIP fundamentals.
Speaker 1: Can you give us a quick refresher on the core
Speaker 1: protocols it leverages?
Speaker 2: Sure thing. So first, there's IP, the Internet protocol. Think
Speaker 2: of it as like the truck for hire that carries
Speaker 2: data shipments across the network roads. It's focused on getting
Speaker 2: data from point A to point B. Doesn't worry too
Speaker 2: much about what's inside the package. These IP trucks, they
Speaker 2: navigate routers and firewalls, which can either pass them along
Speaker 2: or just drop them.
Speaker 1: Got it, just delivery pretty much.
Speaker 2: Then you have TCP, the Transmission Control protocol. Now this
Speaker 2: one is very formal, very proper. Before any data is sent,
Speaker 2: TCP establishes a reliable connection. It uses what's known as
Speaker 2: the three way handshake. You send an sym packet, the
Speaker 2: other side responds with a sinak, and you finish with
Speaker 2: an ACK to confirm Okay, we're connected, now we can talk.
Speaker 2: This connection orient approach is something end map frequently exploits
Speaker 2: to figure out if ports are open on the other
Speaker 2: side of the coin. Is UDP, the User Datagram Protocol.
Speaker 2: It's TCP's polar opposite. So informal totally, it's connectionless. Yeah,
Speaker 2: a fire and forget kind of approach. It just sends
Speaker 2: the data, doesn't wait for confirmation.
Speaker 1: Why would you use that, Well, it's great for.
Speaker 2: Real time stuff like voice or video streaming, where speed
Speaker 2: is more important than catching every single dropped packet. Losing
Speaker 2: a tiny fraction of data isn't critical.
Speaker 1: There makes sense, and the last one.
Speaker 2: Ah, Yes, ICMP, the Internet Control Message Protocol. This one
Speaker 2: is really the tattletale of the network.
Speaker 1: Okay.
Speaker 2: If something goes wrong, like a port isn't reachable, or
Speaker 2: even if a host is just a live and kicking,
Speaker 2: ICMP messages often tell you about it. Think port unreachable
Speaker 2: errors or the echo replies you get when you ping a.
Speaker 1: Device right the classic ping exactly.
Speaker 2: En map uses ICMP a lot for figuring out if
Speaker 2: hosts are online, though many organizations do restrict ICMP in
Speaker 2: their firewalls these days.
Speaker 1: So NMAP has to be clever about that.
Speaker 2: Too, oh absolutely. And what's truly clever is how NMAP
Speaker 2: often exploits minor anomalies, tiny differences in how different operating
Speaker 2: systems implement these standard protocols to gather its incredibly detailed information.
Speaker 2: It's like reading between the lines of the network conversation.
Speaker 1: That's fascinating. That's the real intelligence behind it. Okay, So
Speaker 1: when enmap actually goes to work, what are the key
Speaker 1: steps it usually takes to build that initial picture of
Speaker 1: a network or a host.
Speaker 2: Well, it follows a pretty systematic process, usually four main steps. First,
Speaker 2: if you give it a host name like www. Dot
Speaker 2: example dot com. MP performs a DNS look up to
Speaker 2: resolve that name into an IP address. And remember this
Speaker 2: step can leave traces in DNS logs.
Speaker 1: Good points stealth consideration right there, what's next.
Speaker 2: Second, NMAP does some form of host discovery. It's often
Speaker 2: called a ping scan, but it's not always just a
Speaker 2: traditional icmpping. NMP has many sophisticated ways to confirm if
Speaker 2: the target host is actually active and online.
Speaker 1: Okay, so it checks that the lights are on basically exactly.
Speaker 2: Third, it often performs a reversity and S look up.
Speaker 2: It takes the IP address it found and tries to
Speaker 2: find the host name associated with it. This can sometimes
Speaker 2: reveal the canonical name, which might be different from what
Speaker 2: you initially typed in.
Speaker 1: Interesting, and the final step.
Speaker 2: Only after those first three preparatory steps, the reconnaissance, if
Speaker 2: you will, does it move to the fourth and final
Speaker 2: stage executing the actual scan. That's when it starts actively
Speaker 2: probing for open ports, trying to identify the operating system,
Speaker 2: detect software versions, and so on.
Speaker 1: I see, so it does its homework before the main event.
Speaker 1: And what's really interesting you mentioned is that you can
Speaker 1: control almost every one of these steps absolutely to fine
Speaker 1: tune your scan, making it as quiet or as loud
Speaker 1: as you needed to be exactly.
Speaker 2: That control is paramount. It lets you tailor your approach
Speaker 2: for different network environments, different security policies, or different levels
Speaker 2: of desired stealth.
Speaker 1: Right. So if we connect this to the bigger picture,
Speaker 1: ENDMAP isn't just blindly firing off packets.
Speaker 2: No, not at all.
Speaker 1: It's an intelligent system and it's backed by what you
Speaker 1: called a rich Intel briefing its support files. Yeah, can
Speaker 1: you tell us a bit about those? What kind of
Speaker 1: Intel is in there? Yeah?
Speaker 2: Absolutely. These files are crucial for enmap to provide its
Speaker 2: detailed insights. They act like its reference library. For instance,
Speaker 2: there's NMAP MAC prefixes. This file. Let's enmap identify the
Speaker 2: hardware manufacturer just from the first few bytes of a
Speaker 2: mass address. So if it sees a MAXC starting with
Speaker 2: say zero point one, one point four to three, it
Speaker 2: immediately knows, ah, that's likely Adell.
Speaker 1: Device handy for inventory.
Speaker 2: Very then you've got nmp OSDB and NMPOS fingerprints. These
Speaker 2: contain massive collections of unique responses those minor anomalies we
Speaker 2: talked about from different operating systems. That's how enmap makes
Speaker 2: educated guesses about whether a target is running Windows, Linux,
Speaker 2: macOS or something else entirely.
Speaker 1: The OS fingerprinting parts precisely.
Speaker 2: And then there's end map Service probes. This file houses
Speaker 2: application fingerprints. It helps end up figure out not just
Speaker 2: that something is running on a port, but what specific
Speaker 2: application and version it is, Like is it a patche
Speaker 2: version two point four point five to two or Microsoft
Speaker 2: ISA ten point zero.
Speaker 1: That's incredibly detailed it is.
Speaker 2: And there's even that memorable anecdote about TCP port ninety
Speaker 2: one hundred.
Speaker 1: Oh yeah, the printer story, Uh huh yeah.
Speaker 2: Enmap used to send probes to that port, which is
Speaker 2: often used by network printers, and sometimes it would cause
Speaker 2: the printers to just spew out pages and pages of
Speaker 2: raw scan data exactly. So now endmap has an option
Speaker 2: specifically to exclude that port by default, just to avoid
Speaker 2: surprising the office staff with unexpected print jobs.
Speaker 1: That printer story really illustrates the practical impact and maybe
Speaker 1: the occasional unintended consequence of end maps intelligence. But how
Speaker 1: does it actually gather that intelligence from live devices? That's
Speaker 1: where it's diverse scanning methods come in right spot on.
Speaker 2: Each method offers a unique way to peer into the network.
Speaker 1: Professor Messer mentions over fifteen different scanning method that's a lot.
Speaker 1: What are some of the most critical ones we should
Speaker 1: really understand?
Speaker 2: Yeah, there are quite a few, but a handful really
Speaker 2: stand out because they illustrate different approaches and trade offs.
Speaker 2: The first, and often the most preferred, especially if you
Speaker 2: have the right permissions, is the TCP syn scan. The
Speaker 2: command is nasha S.
Speaker 1: Nash ss okay. Why is it preferred, Well.
Speaker 2: It's generally the stealthiest option for users with privileged access,
Speaker 2: meaning you have administrator or route permissions on the system
Speaker 2: you're scanning from.
Speaker 1: Right, you need special rights.
Speaker 2: Yes, it's often called half open scanning. Here's why. N
Speaker 2: MAP sends an s yn packet just like starting a
Speaker 2: normal connection. If it gets a sign response back that
Speaker 2: indicates the port is open okay, But then instead of
Speaker 2: sending the final ACK to complete the connection, NMP immediately
Speaker 2: sends a RST or reset packet. It basically hangs up
Speaker 2: right after hearing the phone get picked up.
Speaker 1: Ah, So it never fully connects.
Speaker 2: Exactly, it never completes the full TCP three way handshake.
Speaker 2: Think of it like knocking on a door. Hearing someone
Speaker 2: say come in and then immediately backing away. So it's quiet,
Speaker 2: very quiet from the applications perspective. Since the connection isn't
Speaker 2: fully established, the target application often doesn't even log the attempt.
Speaker 2: Makes it very hard to detect on the server side
Speaker 2: through normal logs.
Speaker 1: Right nas SS the default for privileged users. What if
Speaker 1: you don't have those privileges.
Speaker 2: Right for non privileged users, or maybe when an syn
Speaker 2: scan just isn't feasible for some reason, there's the TCP
Speaker 2: connect scan. That's sast S connect scan yep. This scan
Speaker 2: uses the operating system's standard connect system call to try
Speaker 2: and establish a full connection. It performs the complete three
Speaker 2: way handshake, just like any normal application like your web
Speaker 2: browser connecting to a website.
Speaker 1: Okay, so it fully connects.
Speaker 2: What's the downside, Well, the downside is that it's much louder.
Speaker 2: Because it establishes a full connection, the target application will
Speaker 2: see it and will likely log it. So if stealth
Speaker 2: is a priority, this is often considered the scam of
Speaker 2: last resort.
Speaker 1: Makes sense louder but doesn't need special permissions.
Speaker 2: What else, then we have a really interesting family of scans,
Speaker 2: often just called stealth scans. These include the sin scan
Speaker 2: dash SF, the Xmas tree scan dash SX, and the
Speaker 2: null scans.
Speaker 1: Dashes N Xmas tree. That's a name, haha.
Speaker 2: Yeah, it gets its name because it sets a bunch
Speaker 2: of flags in the TCP header fin psh RG, lighting
Speaker 2: it up like a Christmas tree. Supposedly.
Speaker 1: Okay, so what do these do?
Speaker 2: These are incredibly quiet. They send these unusual TCP package
Speaker 2: just a FIN flag or just nothing null or the
Speaker 2: Xmas combo without any syn first, no handshake involved at all.
Speaker 1: And the idea is the.
Speaker 2: Idea based on the TCP standards, is that if a
Speaker 2: port is closed, the receiving system should respond with the
Speaker 2: RST packet. If the port is open, it should just
Speaker 2: drop the weird packet and send nothing back. So no
Speaker 2: response means potentially open. They're designed to fly under the radar,
Speaker 2: often won't trigger application logs because no connection is attempted.
Speaker 1: This sounds super stealthy.
Speaker 2: But there's a catch, right, There is a big catch,
Speaker 2: and this is where it gets really interesting. They are
Speaker 2: largely ineffective against Windows based systems. Why is that Microsoft
Speaker 2: decided way back not to implement that part of the
Speaker 2: TCP standards strictly so Window systems will typically send back
Speaker 2: a RST for all ports when scanned with these fan
Speaker 2: x MISS or null methods, regardless of whether the port
Speaker 2: is actually open or close.
Speaker 1: So scanning Windows with these just shows everything is closed.
Speaker 2: Pretty much, which means if you do run one of
Speaker 2: these scans and you actually see open ports reported h,
Speaker 2: then you.
Speaker 1: Can be freely certain the target is not Windows exactly.
Speaker 2: It becomes a sort of reverse OS finger printing technique,
Speaker 2: and like the syn scan, these also require privileged access
Speaker 2: to craft those custom packets.
Speaker 1: Fascinating. Okay, what about that really clever sounding one, the
Speaker 1: idle scan?
Speaker 2: Ah, Yes, Idle stan dash I. This one is truly ingenious.
Speaker 2: It lets you scan a remote target without sending any
Speaker 2: packets directly from your own IP address to that target.
Speaker 1: How's that even possible?
Speaker 2: It uses a zombie workstation, basically another machine on the Internet,
Speaker 2: ideally one that's not doing much traffic, hence idle.
Speaker 1: Okay, zombie.
Speaker 2: Your n map station sends packets to the zombie, but
Speaker 2: spoofs the source address so they look like they came
Speaker 2: from the target. Then n map observes how the zombie's
Speaker 2: IP identification number changes in response based on those subtle changes,
Speaker 2: en map can deduce whether the target machine responded to
Speaker 2: probes that were seemingly sent by the zombie.
Speaker 1: WHOA, okay, let me process that you bounce the scan
Speaker 1: off an intermediate idle machine.
Speaker 2: Essentially, yes, you're making it appear as if the scam
Speaker 2: originates entirely from the zombie, not from you. It's incredibly
Speaker 2: stealthy for hiding your end map station's IP address. What
Speaker 2: are the requirements, Well, the main one is finding a
Speaker 2: suitable zombie, a machine that's truly idle and has a
Speaker 2: predictable IPID sequence number generation. That can be tricky. And
Speaker 2: again you need privileged access for the IP spoofing part.
Speaker 1: Wow, that's some advanced stuff. One more, maybe the ACK.
Speaker 2: Scan right, the ACK scan desha This one is different again,
Speaker 2: it's like taking an X ray.
Speaker 1: Of a firewall MX ray.
Speaker 2: Yeah, it sends a TCP packet with only the ACK
Speaker 2: flag set. Now, according to TCP rules, an ACK packet
Speaker 2: should only be sent in response to an established connection,
Speaker 2: so sending one out of the blue is unusual.
Speaker 1: And how do systems react if the.
Speaker 2: Packet reaches the target host, meaning it wasn't blocked by
Speaker 2: a firewall. The host should respond with an RST packet
Speaker 2: because there's no actual connection corresponding to that ACK. If
Speaker 2: a firewall blocks the ACK packet, you'll get no response
Speaker 2: back or maybe an ICMP error.
Speaker 1: So it didn't tell you if the port is open
Speaker 1: or closed.
Speaker 2: Correct, it tells you if the port is filtered, blocked
Speaker 2: by a firewall, or unfiltered reachable by the ACK packet.
Speaker 2: It's fantastic for mapping out firewall rule sets, understanding what
Speaker 2: kind of traffic the firewall permits through without triggering any application.
Speaker 2: Logs on the actual target system behind the.
Speaker 1: Firewall useful for understanding defenses. And this needs privileged access to.
Speaker 2: Yes, it does to craft that specific ACK packet.
Speaker 1: Okay, So we have these different scan types, some stealthier
Speaker 1: than others. Now, if you want to become a true
Speaker 1: network ninja, you know, gathering intelligence without leaving footprints, and
Speaker 1: MAP offers this incredible array of options to control your
Speaker 1: scans behavior even further, How can we really minimize our
Speaker 1: presence expert?
Speaker 2: Right? This is where nmp's precision tuning comes in. There
Speaker 2: are several key tactics. First, remember those initial steps end
Speaker 2: map takes one was host discovery often a ping. By default,
Speaker 2: end map pings to confirm a host is alive before
Speaker 2: launching the main scan. But if stealth is your primary goal,
Speaker 2: or maybe you already know the host is up from
Speaker 2: priory come you skip the ping exactly. You can tell
Speaker 2: en map not to ping before scanning. The option is
Speaker 2: EEDP zero or edd b N. This removes that initial
Speaker 2: hello conversation, minimizes your network traffic right at the start.
Speaker 2: M potentially avoids detection by SISS that might be watching
Speaker 2: for pink sweeps. A good ninja, as the saying goes
Speaker 2: already did their homework makes sense.
Speaker 1: Less chatter is better. What else?
Speaker 2: Another tactic involves DNS. Remember n map often does reverse DNS.
Speaker 1: Lockups yeah to get host names from IPS.
Speaker 2: Well, those lookups can be slow, and more importantly, they
Speaker 2: get logged by the DNS servers being queried. So if
Speaker 2: you want to keep your activity off those DNS logs,
Speaker 2: you can use the nyn option to disable reverse DNS lockups.
Speaker 1: Entirely none for no name resolution.
Speaker 2: Precisely, or for the truly meticulous ninja, you might prepopulate
Speaker 2: your local hosts file with the target IPS and names.
Speaker 2: That way, the resolution happens entirely on your machine, completely
Speaker 2: off the network.
Speaker 1: Very stealthy. Okay, what about speed versus stealthy?
Speaker 2: Ah, that's where timing policies come in. NMP gives you
Speaker 2: amazing control over how fast or slow your scan runs
Speaker 2: using the NST option followed by a number from zero
Speaker 2: to five or a name like.
Speaker 1: The SC zero or an AST five exactly.
Speaker 2: Nakshi zero is paranoid. It's incredibly slow. End map inserts
Speaker 2: significant delays, sometimes up to five minutes between sending probes.
Speaker 1: Five minutes between packets. Wow.
Speaker 2: Yeah, it makes the scan take forever, but it's almost
Speaker 2: undetectable by rate based intrusion detection systems. On the other extreme,
Speaker 2: natchy st five is insane, lightening fast, very aggressive, sense
Speaker 2: packets as quickly as.
Speaker 1: Possible, which could easily trigger alarms.
Speaker 2: Oh definitely. But these timing policies are invaluable. You can
Speaker 2: use them to gently probe a network without causing disruption.
Speaker 2: Nashty two two or polite is off the good. Or
Speaker 2: you can use the faster modes to say, stress test
Speaker 2: an intrusion detection or prevention system IDSP and see at
Speaker 2: what point it actually triggers Understanding those thresholds.
Speaker 1: Is crucial, so you can dial the aggression up or down.
Speaker 1: Oh cool, I heard. You can also use decoys make
Speaker 1: it look like the scan is coming from somewhere else.
Speaker 2: Yes, that's the decoys option, Ashid. This is quite clever.
Speaker 2: You provide enmat with a list of IP addresses the
Speaker 2: decoys along with your own real IP, or you can
Speaker 2: use me to represent your IP NMP, then send scan
Speaker 2: packets seemingly originating from all those decoy addresses, mixed in
Speaker 2: with packets from your real address. The idea is to
Speaker 2: flood the logs with bogus source ips, making it much
Speaker 2: harder for network defenders to figure out where the actual
Speaker 2: scan originated.
Speaker 1: So you hide in the noise you create.
Speaker 2: Pretty much. You can even omit your real IP entirely,
Speaker 2: though that's obviously less useful if you need replies back.
Speaker 2: There's a caution here though, If you use decoyips that
Speaker 2: don't actually exist or belong to machines that aren't online,
Speaker 2: you could inadvertently cause a s yn flood on your target,
Speaker 2: because the target might try to send soyanac replies back
Speaker 2: to those non existent decoys using up its own resources
Speaker 2: waiting for ACKs that will never arrive. It could potentially
Speaker 2: disrupt the target's service, so use decoys responsibly. And yes,
Speaker 2: this needs privileged access for the IP spoofing.
Speaker 1: Good warning. Okay, what about hiding on the local network right?
Speaker 2: For local network steff Within the same subnet, you can
Speaker 2: spoof your MME address using.
Speaker 1: Spoofback your hardware address.
Speaker 2: Yep, you can tell n map to use a completely
Speaker 2: random MC address or even mimic the MSS address of
Speaker 2: a specific vendor, like making your laptop look like a
Speaker 2: Cisco router on the wire. Why only local because MC
Speaker 2: addresses are generally only relevant on the local network segment.
Speaker 2: When packets go through a router to another network, the
Speaker 2: router usually strips off the original MC and puts its
Speaker 2: none on, So spoofing your MC won't help hike you
Speaker 2: once your traffic leaves your local subnet. And again privileged
Speaker 2: access is needed as this involves sending raw ethernet frames directly.
Speaker 1: Got it local effect only any other subtle tricks?
Speaker 2: Yeah, A couple more quick ones. You can use fragmented
Speaker 2: IP packets dash FF or FF or M two. This
Speaker 2: breaks your probe packets into smaller pieces, sometimes very simple
Speaker 2: packet filters or firewalls might only inspect the first fragment
Speaker 2: and miss the real intent if it's split across multiple parts.
Speaker 2: It's an older trick, less effective now but still available.
Speaker 1: Trying to sneak past simple guards sort of.
Speaker 2: And you can also set a custom time to live
Speaker 2: TTL for your packets using Chittle. The TTL value basically
Speaker 2: determines how many router hawks a packet is allowed to
Speaker 2: take before it's discarded.
Speaker 1: Okay.
Speaker 2: By setting a low TTL, you can ensure your scan
Speaker 2: probes don't travel too far. For instance, you could limit
Speaker 2: them so they don't leave your local network or don't
Speaker 2: cross a specific WAN link. It's a way to keep
Speaker 2: your scan localized.
Speaker 1: Subtle controls for scope in evasion. It's quite an arsenal,
Speaker 1: it really is. Now. It's probably worth noting just quickly
Speaker 1: that NMAP, while it works incredibly well on Windows, does
Speaker 1: face some maybe minor limitations there compared to Linux or macOS.
Speaker 2: That's fair to say. Historically, things like the raw socket
Speaker 2: implementation on Windows meant certain scan types, particularly the TCP
Speaker 2: connect scan, were a bit slower than their counterparts on
Speaker 2: PO six systems like Linux and some advanced features like
Speaker 2: SSL version detection might not have been available or as
Speaker 2: robust initially.
Speaker 1: But it still works very well.
Speaker 2: Oh absolutely. It's truly a testament to Feodor and the
Speaker 2: en map development community that it works as well as
Speaker 2: it does across such a wide range of platforms, including Windows.
Speaker 2: They've done a remarkable job.
Speaker 1: Agreed. So okay, we've covered the tool, the techniques, the scalf.
Speaker 1: What does this all mean for you, the listener, the
Speaker 1: learner out in the real world. Endmap isn't just for
Speaker 1: theoretical hacking exercises, right, not at all.
Speaker 2: It's an indispensable day to day tool for network administrators, security, professional,
Speaker 2: system engineers, really anyone responsible for understanding and securing a network.
Speaker 2: It has countless practical, legitimate uses.
Speaker 1: Let's run through a few compelling use cases. Then. How
Speaker 1: would you use end map at a real world scenario?
Speaker 1: For instance, maybe identifying virus or spyware remnants?
Speaker 2: Okay, yeah, good one. Let's say you suspect some machines
Speaker 2: might be infected with malware, maybe something older like my
Speaker 2: Doom or netbus, which were known to open specific ports.
Speaker 2: You could use end map to scan your network specifically
Speaker 2: for those ports. You'd likely combine a stealthy TCP syn scans,
Speaker 2: maybe a UDP scan at Dutch SU. The malware use
Speaker 2: that focusing just on the suspect ports DUSHPT dot port
Speaker 2: one doutch SV. You probably want host discovery Dutch PE
Speaker 2: for ICMT echo could work, and crucially you'd add version
Speaker 2: detection Dutch SV.
Speaker 1: Why version detection there.
Speaker 2: Because dashesv could help pinpoint the exact malicious application listening
Speaker 2: on that port, even if it's trying to disguise itself.
Speaker 2: It helps confirm its malware and not some legitimate unexpected service.
Speaker 2: Then you can quickly isolate those machines.
Speaker 1: Nice, Okay, how about vulnerability assessments checking for known weaknesses?
Speaker 2: Definitely, say there's a known vulnerability in a specific version
Speaker 2: of Microsoft SQL server, maybe related to its discovery service
Speaker 2: on UDP port fourteen thirty four. Version detection dashes V
Speaker 2: is absolutely key y Here, you'd craft an NMP command
Speaker 2: to scan a list of your servers dashisl input dot
Speaker 2: LST maybe excluding known good ones, exclude bashviileband dot LSD,
Speaker 2: specifically probing UDP port fourteen three four DASH and you
Speaker 2: bought one four three four, you'd probably disabled DNS lorge
Speaker 2: N for speed and stealth. Maybe add verbosity dash VV
Speaker 2: and ensure host discovery DASHIL. The command might look something
Speaker 2: like n map dosh vvvsh SZ input dot LSD, exclude
Speaker 2: file band dot l stgu dot one four three four
Speaker 2: dash NA s qu l s v r SSV, and
Speaker 2: the nashes.
Speaker 1: Fee gives you the precise version info exactly.
Speaker 2: It tells you which servers are running that potentially vulnerable version,
Speaker 2: allowing you to prioritize patching. It's like finding all the
Speaker 2: houses on your block with a specific model of old
Speaker 2: easily picked block.
Speaker 1: Great analogy. What about security policy compliance testing? Making sure
Speaker 1: only approved stuff is running?
Speaker 2: Another big one. You need to ensure only approved operating
Speaker 2: systems and software versions are present on your network.
Speaker 1: How does en map help there?
Speaker 2: You'd combine several things, maybe multiple ping types to maximize
Speaker 2: host discovery dash PA eighty, SHP DASH twenty three, a
Speaker 2: broad PCP s y N scan dash SS to find
Speaker 2: open ports and crucially OS fingerprinting too to identify the
Speaker 2: operating system right and for large networks, Professor Messer suggests
Speaker 2: using a scan limit. This tells to only attempt the
Speaker 2: more intensive OS finger printing on hosts that look promising,
Speaker 2: specifically hosts that show at least one open and one
Speaker 2: closed TCP port. This improves the accuracy of the guests
Speaker 2: without scanning every single device quite as intensely smart optimization.
Speaker 1: Yeah, okay, what if you need to manage assets across
Speaker 1: slow links like a remote office connected via.
Speaker 2: One, Yeah, you need in inventory devices there, but you
Speaker 2: can't just blast the network. It'll kill the link or
Speaker 2: set off alarms, So be gentle, exactly. You'd use a
Speaker 2: very gentle approach, maybe just a ping scan just misspe
Speaker 2: to see what's alive, or a very slow tcpsyn scan dashass.
Speaker 2: Combine it with OS fingerprinting to get basic device info,
Speaker 2: and definitely use a slow, non aggressive timing policy like
Speaker 2: Polite Dataity Polite or even nash T two. It'll work
Speaker 2: slowly passively in the background, collecting valuable asset data over
Speaker 2: that WAN link without disrupting normal traffic.
Speaker 1: Patient and passive. Good for remote sites. How about checking
Speaker 1: the firewall itself?
Speaker 2: Firewall auditing essential task. You need to understand what your
Speaker 2: firewall truly allows from an external perspective, not just what
Speaker 2: the config file says it allows.
Speaker 1: So test it live.
Speaker 2: Yep, use the ack scan dashi taissa. Remember this tells
Speaker 2: you filtered versus unfiltered ports that directly maps to the
Speaker 2: firewalls rules. You'd likely disable the initial ping dashes misero
Speaker 2: or dash PN because you want to hit the firewall directly.
Speaker 2: And maybe if you're trying to analyze the traffic later
Speaker 2: with something like wireshark, you'd tell end map not to
Speaker 2: randomize the source ports so the connections are easier to
Speaker 2: follow in the packet capture.
Speaker 1: Uh are for easier debugging later. Clever okay. Last one
Speaker 1: perpetual network auditing, like continuously monitoring for changes.
Speaker 2: Yeah, this is about ongoing vigilance. Setting up a recurring
Speaker 2: end map scan to keep an eye on your network
Speaker 2: over time, looking for new devices popping up or services
Speaker 2: changing unexpectedly.
Speaker 1: How would you configure that.
Speaker 2: You'd want it to be very low impact, so probably
Speaker 2: a TCP syn scan dash SS. Definitely include OS fingerprinting
Speaker 2: to track device types, use a polite timing policy nash
Speaker 2: is T two again, and maybe use randomized hosts to
Speaker 2: scan the targets in a random order each time. This
Speaker 2: keeps the stand passive, spreads the load out and gathers
Speaker 2: information over days or weeks, without any single burst of
Speaker 2: activity that might cause disruption or look suspicious. It becomes
Speaker 2: part of the background noise.
Speaker 1: Wow, what an incredible journey into the world of endmap. Yeah,
Speaker 1: we've really seen how this one tool acts as your
Speaker 1: network's eyes and ears, from silently mapping out devices to
Speaker 1: precisely identifying software versions and operating systems.
Speaker 2: It really does.
Speaker 1: It's truly a cornerstone, isn't it for network pros, security folks,
Speaker 1: anyone wanting to truly understand their digital environment.
Speaker 2: Indeed, and I think end Map's real power lies in
Speaker 2: its adaptability, its flexibility, and fundamentally its ability to turn
Speaker 2: those subtle network behaviors the way a system responds to
Speaker 2: a weird packet, the tiny timing differences into profound insights. Yeah,
Speaker 2: it really encourages you, forces you almost to think critically
Speaker 2: about how information flows online and how even the smallest details,
Speaker 2: the slightest variations from the stand can reveal crucial vulnerabilities
Speaker 2: or compliance issues. It's a constant reminder that understanding the
Speaker 2: underlying protocols is absolutely paramount to true network security.
Speaker 1: Absolutely, And as we said earlier, with great power comes
Speaker 1: great responsibility. Using end map wisely ethically, it can transform
Speaker 1: you into a true network cartographer, making your digital world
Speaker 1: safer and definitely more transparent.
Speaker 2: And maybe here's a provocative thought for you, the listener,
Speaker 2: to consider as we wrap up. If nmap, this tool
Speaker 2: we've been talking about, can uncover so much detailed information
Speaker 2: about a system, it's OS, its services, its potential weaknesses
Speaker 2: without ever needing to log in, without needing any credentials.
Speaker 2: What does that tell you about the fundamental transparency and
Speaker 2: maybe the potential fragility of pretty much every single device
Speaker 2: connected to the Internet today.
Speaker 1: That is something to think about, the inherent visibility of
Speaker 1: being online. Great point, something to mull over indeed. Yeah, well,
Speaker 1: until next time, keep exploring, keep questioning, and stay well informed.