 I think I have one of the more hardcore of DEF CON crowds here today. So many people come on the weekends, but you guys manage to convince your bosses to let you skip a day at work, fly to Las Vegas, and attend this great hacker party. So congratulations on that. I was going to just come here and party as well and not even speak. But then I saw this network reconnaissance track. And that got my attention as it's a subject that is very near and dear to my heart, as I'm the author and maintainer of a security scanner called NMAP that you can use for these sorts of techniques. I'm also going to discuss, sorry, I don't know if I can make it much louder, but I'll try my best. All right, I'm also going to discuss other great open source network security tools such as the Venerable H-Ping 2. Just so I can get an idea of the audience and how much introductory NMAP material I have to cover, could I get a show of hands for anyone here who has ever used NMAP? OK, that's pretty much all of you, which is great because I wrote far too much to fit in 50 minutes, but I'm going to do my best. So if I look rushed, that's why. We'll start with the disclaimers, of course. First of all, you'll notice, as opposed to many other presentations, we're using real host names and IP addresses here. Frankly, I sometimes get sick of seeing slide after slide of example.org, and this is a mock-up of a 192.168 network and so forth. Plus, I trust all you guys. You're not going to abuse the information. But more importantly, even if I didn't, this is really just public information scanning we're doing. It's called network reconnaissance, and that's all we're doing. We're not going to be exploiting any hosts. We're not going to be getting root. We're just going to be rattling some door knobs, maybe peeking in a window or two. Also, I'm going to start with the basics as the foundation for some of the more advanced stuff. So five minutes from now, you're saying, oh, man, I was doing this stuff back in eighth grade. Well, hopefully, it'll get better. So let's just start from the beginning here. Our first step is going to be taking our target company or whatever. I don't remember if I mentioned that this talk is gained mostly to pen testers and such. So if you got your client, the first thing you want to do is you might want to try DNS. That's pretty obvious, right? Its whole point is to change names to IP numbers. So first, we'll grab just the low-hanging fruit, just the information that companies have to give us in order for their mail and such to work. So we use the dig command to grab basic information from at stake. And you see name server records, MX records, and the corresponding A records. They also have this bonus text record where security and business intersect. And I think they're one of the few companies where they get so many probes that it makes sense to put advertisements in their DNS zone information. So what do we do next? Well, let's try a zone transfer. Why not? It may not always work. But when it does, you get a huge list of host names, IP address. You can get ideas of the functions of the hosts from their names, from their C names. Poorly configured servers will give you vanity names that their systeming uses, far flung. Sometimes you even get internal network names, which is really bad, but that certainly doesn't mean it doesn't happen. And popular name servers such as Bind make this information available by default. So yes, a lot of people turn it off. But when it's on by default, we all know that at least half of them leave it as it is. So here's just an example where we grab the security focus zone. And you see a bunch of hosts here, which I've cut off due to space. To their credit, they didn't have those problems like internal DNS or far flung vanity names, but it still gives you a lot of IPs to start with in your reconnaissance. Another thing you want to try, of course, is the version number. And that's for one basic reason. As you all know, Bind has a long and sorted history of remotely exploitable security holes. So if they're running an insecure version, you can skip the rest of this reconnaissance stuff and go straight to owning their name server. The Bind people also have a useful page. Most of you have probably seen that lists all the different security holes and the different versions of Bind that you can cross reference to. When I tried a lot of popular companies, I got some interesting flippant responses for a few. Playboy's version number is move on. I'm already patched. K, thanks, bye. Philip Morris' parent, Altria. You are not cleared for that information. And Sands informed me that all accesses are logged. Damn. So I actually thought that these might be some good companies to take a further look at. Because A, they're large companies. They can afford security staff. B, they've obviously made at least some attempts at securing in that they rejected the zone transfers. They put flippant remarks in their version numbers and so forth. So I thought that would be more interesting then. If we scan a totally open network, well, duh, that's easy. So let's go ahead, at other ways. I'm not going to talk much about netcraft, but just to mention that that's sometimes underutilized in gathering more information on the company. You can find domain names that are similar to the company names used similar. They took away that? Bastards. But there's still plenty of great features that you can use, such as you can detail down on each one. And I'll talk to netcraft. Narrow down on each one to get the uptime graphs, to get the hosting history, and all sorts of goodies. And the great thing is that here you're totally anonymous since it's the netcraft server you're querying, and most of these are in their cache. The geographical IP registries are another place to start. Erin, Ripe, Appnic, find the contact information, emails, phone numbers, et cetera, et cetera. And you can basically take the seed numbers that you got from the previous stuff, look up what networks they belong to, who administers them, what else that person administers, and keep cycling in this loop as you gain more and more IP addresses. Here's an example. We do a who is on Erin with the string at microsoft.com. And again, we see pages and pages. This only goes up to H of contacts there, who we can not only find out what networks they run to find IPs, but we can save that information for further social engineering, drill down on each one for their address, and so forth. Here's another example. We're gonna do Erin, and here we give the query and look for net blocks with the name Playboy in it. And indeed, we get a whole bunch of responses. Now, obviously, companies can have similar names, so you wanna go through and make sure, look up each record, check the address, make sure it corresponds, in this case, it does. So, obviously, this part can't be comprehensive because there's any number of ways that you can find such thing. One of the more fun ones, though, are the public route servers I've been looking at lately, such as traceroute.org gives you a list of Cisco boxes that have you're publicly able to connect to them and get full PGP routing information, so you can look up the AS numbers and so forth of the companies that you're interested in. And many more techniques that I won't cover, but the point of that was just so that we can get the IP addresses that we're interested in doing for the reconnaissance on. So, using some of those techniques, I culled a bunch of networks from Playboy to use them as an example. Now, I did exclude certain net blocks, such as some of the gaming sites, because if I can't see no, it was to catch you scanning them. They're liable to break your kneecaps. So, be careful with that. You can see here that these aren't kind of CIDR notations, so you have a slash 20 here, that's 4,000 hosts, a slash 24, all the way down to here is just dot 101 through 105, so that's only what six hosts or five. But Nmap takes it in this convenient format so we can feed that in directly. So, what are we gonna start out with? Well, we don't wanna start out with ringing all the bells and whistles and IDSes and so forth, so we're gonna start simple with the cautious approach, which in Nmap I call the list scan. So, we're going to say hyphen SL, do a list scan, output to a file, and I give it all these addresses that we just looked at. And here basically all it's doing is going through each one and doing a reverse DNS lookup on it so we can kind of see what we're after. And this is important for a lot of reasons. For example, verification, just because they own the IP blocks doesn't for sure mean that they're using them. They could be subletting to some other company, some of the IPs they could be sharing with some other company in the basement. And so this at least we can look up the names and make sure that there's nothing too out of whack. Also, sometimes from the names you can figure out what specific machines you might wanna dig into for more information if you don't wanna go after all of them for reasons of subtlety. So the next step once we've done that is the ping scan. We wanna know which of these hosts are up and available. And so here I did the same thing and a lot of people don't recognize how much more powerful the ping scanning techniques of Nmap have gotten recently. You know, there was a day on the internet where you could just send an ICMP you know, I go request ping packet and pretty much most of the machines that were up would respond happily. Nowadays with so many filters and paranoia and such you have to sometimes go a little bit further in probing the machines looking for any sort of response. So here we're saying do a ping scan SP. Use SIN probes against port 22, 25, 53, 80, 113 and 31, 338. I just picked a big one because sometimes firewalls only deal with the lower ports. And that'll send a SIN request to each of those and expect a response pack. Similarly, we do an AC scan to a number of ports expecting a reset pack. And a relatively new feature is hyphen PU which sends a UDP packet to the ports that we specify and expects an ICMP port unreachable back. If it gets that then it knows that they're up. So you can specify pretty much an arbitrary combination of all these different ways to try and elicit some sort of response from the hosts so that we can narrow it down from the more than 4,000 that we had listed before. It also has PE which is the traditional ping packet and PM which is an ICMP net mask request. And just for kicks we set the source address on all the TCP and UDP probes to 53 because we've all seen once in a while some firewall admin will set up his new firewall, inexperienced firewall admin and say, uh-oh, nothing's working. DNS responses aren't coming back. Well, there are right ways to fix it and then there are easy ways to fix it. And a lot of people pick the, well, we'll just allow source port 53. No one's gonna notice that. What are the chances the probes will come from there? So we put it there just in case it might work. Other popular choices would be TCP port 20 because you have the same case with TCP, FTP connections coming back. And so we run that command and it completes and it said that of those 4,393 IP addresses, there are 950 of them up. I just showed a few examples here. But with any tool, even Nmap, you wanna make sure that you verify your results. Go through and look at the output file and make sure that everything makes sense. So here, I look at the machine readable output, which is what we see in front of us. And I see hundreds of machines consecutive that all look like they're up. And that's a little bit suspicious because you would think if they were real machines, you would see a gap in somewhere. I mean, yeah, and they don't even have reverse DNS. So yeah, it could be a cluster of machines that's very thick, but you kinda wanna look into it more to make sure you don't waste too much time on machines that aren't really reachable. One way to figure that out is say, well, which of these PING probes were those alleged up hosts responding to? And so Nmap has a feature, not added a totoo long ago, hyphen hyphen packet trace, which will show you all the packets Nmap sends and receives. So we do a command just like the one before, but instead we just pick one of those possibly phantom hosts to look at and see what it's really responding to. So we see the PING request, the UDP request, the TCP sends, TCP acts, and then down at the bottom here, you see this receive line saying that it's receiving a TCP reset from port 113 from the host. Now, those of you again who do firewalls know that 113 or the identity port is also an annoying one. You set up your firewall to block incoming connections, and then one of your users connects to a mail server or an IRC server and it tries to connect right back to 113 to figure out what user is owning that connection. And if your firewall is blocking it, that can take a long time to time out and frustrate your users. And again, that leaves the admin with several possible options and they don't always choose the right one. Sometimes they say, well, you know, we'll allow 113, it's only IDent D, you know, what harm can it be? And that way it'll actually work. With newer firewalls, most of the modern ones, you can say spoof a reset so that it looks like the machine is there and listening and just stopping the port 113 without having a long time out. And so that leaves us in a quandary. We don't really know, you know, is the firewall here blocking the port and spoofing this packet allegedly from 140.226 or did we find a hole that allows us to reach the machine behind it? And so you might wanna think a little bit about if you were doing this scan, you know, what methods would you use to determine what's really going on there? And I'll demonstrate a couple ideas and then maybe you'll have some of your own ideas afterward. So one thing we could try is the IP ID. As most of you know, every IP packet in the header has an ID flag that's used for a fragmentation reassembly so it can figure out what IP packet a fragment belongs to. And so one thing with IP ID though is that implementers have a lot of leeway in how they implement it. So they generally do the easy approach of just using a counter that goes from zero to 65, 535 and then back to zero again with each packet they send they increment it by one. Other, a few other hosts use different techniques. So we're gonna use the great HP utility which you probably all have and if not I stuck it on the DEF CON CD to do a probe to port 113, a SIN probe on that machine. And we look at the responses with a particular emphasis on the IP ID that's in red. So for this first host we see it's 4,700, 57,900, 9,400. It's a pretty random looking distribution. And then we try another one of these hosts and we look again and shucks. It's another random looking distribution. If we had seen that this one was incrementing from 4793 to 4794 to 4795 and this one was like 5,3009, 5,30010, we would know that they were probably different machines because they're both incrementing but they're on a totally different phase there. In the same way you could send a bunch of packets to one and see if it increments the IP ID of the other or if this one was random and this one was sequential again we'd see that it was something different. But unfortunately this hasn't fully worked for us because they're both random and that tells us that it's probably a firewall since they're the ones that usually do that but systems like OpenBSD will do it too. So this leads credence to the idea that the firewall is sending the packet back but it could be a cluster of OpenBSD machines behind there. You never know. So let's try something else then. Maybe trace route will help us. So we do a trace route to their mail server mx.shai.playboy.com and using the normal trace route command and we see that it goes from San Jose to Chicago to the Playboy network and then it stops at this f0-0 and it's filtered and so we're not able to see the destination host at all. So 10 hops really isn't a lot. We would like to get all the way to the destination host. So instead we're gonna do a more custom trace route against the machine. Using HPING 2 again it's trace route mode. We do a trace route to port 25 because this is a mail server so that instead of using the default UDP probe that gets filtered, hopefully the SIN packet to port 25 will make it all the way to the server so that mailers can make connections. And here we see it gets to 10, 11 no response but 12 all of a sudden we get a TTL from this fw.shai.playboy.com. I have to thank them for the great naming. It's really helpful. Their firewall is fw, it's in Chicago. Their mail server is mx.shai. That's really convenient and I do appreciate it. But then we get a response from the actual host, 13 hops away. So that tells us that we know that the end host is apparently 13 hosts away and we can get the response by going to port 25. So now we'll try port 113, which is the port that was giving us trouble against the same host. And here we get to 10 like usual, 11 gives us nothing but this time we're getting the response from the host at hop number 12. Whereas last time that's where the firewall it was and the real host was on 13. So this pretty here gives us enough evidence to close the deal that it's really the firewall that's at hop 12 but it's just spoofing the packet to make it look like it's coming from 143.2 and it's sending a reset. And so that means we probably can't reach the machines at all. Does anyone have other ideas? Suppose this hadn't worked and the IP ID failed as it did and the trace route had failed too. What other techniques do you think we could have used to try and determine whether the host is spoofing the packet is alive or whether it's a firewall spoofing? ISN prober? Okay, that's great. He's suggesting a good tool called ISN prober which I haven't personally used but instead of checking the IP ID sequences, they would have checked the TCP ISN sequences. And so if it was like a 64K rule or Windows time dependent or such, we could see that they're on totally different phases or use different algorithms. What other techniques do you think you could use? Sure. Time to lift, yeah, kind of like, you mean like we were doing here? Right, yeah, I think that's what we're doing here where we see that since it's 12, we know that it's spoofing it on the TTL and since it's 13, we know that it's not. Anyone have other ideas? NBT stat? Okay, yeah, so if it's like a Windows host and it had those ports open, you could try that. Hopefully they wouldn't put their mail server on there but some people do. Okay, that's another great idea. See, there are a lot of ways to do it. His suggestion for people who didn't hear was to do an OS fingerprint such as nmap-o and see if they match. Another technique for anyone who's read frack 60, someone wrote a real good paper on bad checksums. They found that many firewalls configured this way to respond to packets, wouldn't even look at the checksum and would respond regardless of whether the checksum is valid. Whereas any decent end host, even a Windows host, is gonna just drop that packet on the floor. So if we had sent our SIN packets from a, if we had sent it with a bad checksum and didn't get a response, there's a good chance that the host was receiving it. Whereas if we got a response to a bad checksum, we'd be pretty certain that it's the firewall since no host would do that. So that's just an example of how there are a lot of means in your pen testing to achieve the same ends and sometimes you'll get frustrated by the first couple tries. But if you think about it, you can often find ways to get around these problems. A side note on host names real quick. We noticed that mx.chi and fw.chi were well named. Security focus wasn't quite as kind. I was looking through the zone transfer and saw a bugzilla and I thought, hey, I know that bug tracking system. I know an exploit for that. And so I tell them it in and instead I get this Raptor secure firewall gateway and so forth. So you can't always assume that it's gonna be exactly as they say. Host names go out of date. They may be trying to trick you or for whatever other reason. So now the whole point of that exercise of finding out the one, one, three thing is that now we can redo our ping scan and this time one, one, three is out of the picture because we know that it's giving us unreliable results. And this time we only see 71 hosts up as opposed to the 950 that we got before. And so that's a much more manageable number for us to deal with. So I just use a quick easy command to grab all the IP addresses from our Nmap log and put them in a file. And I also added that fw.chai because the filtering on that was good enough that it didn't respond to any of our ping probes. However, thanks to the little expedition we did we found it via the custom trace route. And so of course we wanna scan it too. So now I'm gonna move to a slightly different tangent. We'll go back to those later. Sometimes what you really wanna do is do a fast single service sweep. So hypothetically suppose there was a huge Windows RPC DCOM exploit on the loose and you wanted to scan all your systems really fast before the attackers do for port 135. Of course it can potentially be exploited on other ports but that's the main one. And so Nmap has what I call a turbo mode that supports that to make it really fast. Now for Playboy I'm not gonna scan 135. Given the nature of their sites I decided I wanted to find web servers. And so here we're say do a SYN probe to port 80. Do a SYN scan and we wanna scan for port 80. And Nmap will be smart enough to say, hey, the ping probe is already sending a SYN packet and getting a reset or a SYN act. So let's skip the whole port scan and just use the ping probe results to give you what you need. And so this was able to scan those 4,397 hosts in just a little under a minute which can be handy. Sometimes I get emails from people saying, dude Nmap is so slow I wrote my own scanner and it can scan a class B in 10 seconds and it's only 20 lines of code. It's just a for loop that goes through and send, send, send, send, send. But the problem of course is it can scan really fast but the results aren't gonna be accurate at all. Nmap has to be very careful about remembering all the probes it has sent, retransmitting if it doesn't get a response, detecting dropped packets, looking at latency, adjusting the parallelism accordingly. Whereas if you just have a for loop that just scans real quick, it's liable to be all dropped 90% of your packets at the first bottleneck router on the route between the machines. One thing that just slightly modifies from that is if you wanna do an internet wide ping sweep. So here we're using a feature of Nmap called IR, input from random which just, and it now takes an argument. It used to just go forever. However, sometimes that makes it easy to start it up going and then forget about it and then it'll scan for good and you'll get up the next morning with angry messages from your ISP or so I hear. So after that happened, I added a feature that lets you limit it to in this case, 10,000 hosts. So here we're saying pick hosts at random, do this fast since sweep for web servers. So you can use this as an alternative browsing approach. Instead of search engines, you can just find your web servers randomly and see what you get. They just pop up one after another for us, you would have to be pretty bored to do that, but if you wanted to, it's there. And it kinda looks like sort of a script kitty feature, but actually I can find it quite useful in a number of cases. If you wanna do surveys of certain ports, see how many people are running whatever, you can get a lot of good information just by doing a random scan. Okay, so now we're gonna get more intense with these Playboy IPs that we've found. So here we're gonna say Nmap, don't bother peeing it because we already know that they're up. Do a SIN scan, an OS scan. We give it this OS scan underscore guest, which wasn't documented until recently. And basically the problem we encounter when I did normal OS detection is that those 113 ports that were coming back, the resets, those weren't from the machines at all, those were from the firewall forging them. And so Nmap got a little bit confused because those resets didn't match what it would have expected from the true destination host. However, this OS scan guest will say, hey, even if you don't have a perfect match, just give the closest match, and that's usually pretty effective. T4 is a timing option we'll talk about later. We wanna scan all of the ports, and I mean all of them. Nmap used to just do one through 65, 535, but this year I added the port zero support, which is pretty bogus port, but some people wanted to scan it, so why not? We give it the list of IPs, tell it to log to a file, and we're off. So let's just take a look and try and analyze some of the results. Let's take a look. One thing, we have this router here. It looks like it's a Cisco. It's got all the ports, and this is a line that a lot of people don't pay enough attention to. Here we see that the ports that were scanned but not shown are in state closed, meaning there's not really much of a firewall protecting them, so if the ports were open, they would be available to users as opposed to a more proper default deny stance where they say only allow the ports that I specifically want to be allowed. So for example, they probably didn't have a real great reason for having finger open. It's probably not necessary on the router for external internet users, but because they have this default allow policy, it was up and available. Whereas at this host, we see that the default is filtered, and so hopefully they only have ports open that they have a good reason for. Let's take a look at another one. This one's bigip2chi.playboy.com, and one thing I found really interesting on this guy is that the OS guest said that it's an F5Labs big IP load balancer, which is probably true given the name of the host, and what's interesting is that I certainly don't have one of those in my lab to add that fingerprint, and so a feature that has turned out really useful on Nmap is that if it doesn't detect an OS, it gives you a fingerprint and a webpage where you can submit it, and a lot of really helpful users have submitted thousands of these fingerprints, and so that the database now includes everything from Xboxes running Linux to Amiga's to VoIPones, PBXs, and F5Labs big IP load balancers. Has anyone here ever submitted a fingerprint? Okay, mad props to you guys because that's what's helped it to be so up to date. When people submit one, then everyone can benefit if they ever do see that weird type of machine somewhere. Let's look at a couple more examples. Here's one, it looks like it's an ad server in Chicago, and their default state is filtered, good, not many ports open. The fact that they have Oracle open is kind of questionable. Just because Larry Ellison says it's unbreakable doesn't necessarily mean that it's a good idea to leave it open flapping in the wind. But at least you can see they made some efforts here in terms of the default filtered, and you can see the OS guess says that it's Solaris 26 or seven and that they've specifically changed the TCP strong ISS variable to give them stronger initial sequence number generation to make it hard to do TCP spoofing attacks. Here's another machine that's on kind of the same class C where they haven't taken as much care. The default state is closed, it's got more host open, and it has my SQL, which is just as bad. So now we're gonna move to a few other tricks that can be handy. First, let's look at IPv6 scanning, which NMAP now supports. So I take a machine, I use www.came.net just because they have some good IPv6 network so I knew they supported it. And I do a scan of them, and we see a number of open ports, but we also see all these filtered ports here that we're not able to get to because of some filtering system. Well, let's take exactly the same command, but add hyphen six so that it scans the IPv6 version instead. Here you see that suddenly there are no open, no filtered ports, and this port 113 that was filtered in the previous one is now open. So you could take your IPv6-enabled RPC info and interrogate the ports further. So that's something that can sometimes be useful to try, and it's gonna become more useful if and when IPv6 starts seeing more usage. Another thing that people are often interested in is how to get the timing right. NMAP offers a lot of options, max parallelism, min parallelism, min RTT timeout, max RTT timeout, initial RTT timeout, a host timeout, a scan delay. So if you wanna get your scans faster, all you really have to do is pick the exact right values for each of these variables, and everything will be set. Fortunately, there's a better way, and that are these canned timing levels I added, which tries to do the smart things, but lets you configure how aggressive it wants to be. It can be everything from paranoid, which does only one probe every five minutes. So yes, you're gonna stay under the IDS port scan detection thresholds, but you're gonna be old and gray by the time any scan actually finishes, unless it's a real small, very limited scan. Sneaky is kind of the same, except it's 15 seconds, and you can use numbers here from zero to five instead of the names if you want. Polite, normal mode, which is kind of the default. And then there's aggressive mode, which is something I've worked a bit on. By default, I think NMAP needs to err on the side of being conservative with how fast it does its scan, because it doesn't really know for sure about all the network infrastructure in between. For all it knows, you could be on a 300 bot slip link to Pakistan or something, and so it has to be safe so that I would rather have it be slower in the case where you're on a faster network than if you're on a slow network and get wrong results. However, with this aggressive mode, I've tried to make it so that if you're on at least a somewhat reasonable network, if you're on an Ethernet or even a broadband connection, or possibly even a modem, although I don't know, this will be much more aggressive in its timing while still providing accurate results, assuming the latency and such and packet loss aren't horrible on that network. So let's look at ways that you can speed your scan and some of the things that I've been adding lately. Here we do a scan with an older version, 3.15 beta three against insecure.org. See, I actually scan my own system sometimes too. It's not only other people. And here it scans the 1600 default ports in a little less than 10 minutes, which isn't a disaster, but it still will take a long time if you have a lot of hosts, which are firewalled in this sort of way. So I made a bunch of changes to the timing algorithm, which in the next version of Nmap was able to do the same thing in two 28 seconds, which, hey, you saved half your time. But even better is if you add the T4 option, you know all the sudden it only takes 41 seconds. And so if you're doing big scans, if you're doing scans against heavily firewalled hosts and you're on a decent network, you know that's something that you might want to consider using on a more regular basis. Now let's look on a different track, avoiding the IDSs. There are a few different ways that you can do this. One of them is the scan flags option, which lets you specify different flags for a certain scan you want to do. For example, one fact that seems to be little known by certain IDS vendors is that you can do a SIN scan. You know, it doesn't have to be just SIN. You know, a SIN FIN, for example, will often do the same thing. And so with scan flags, you can say do a SIN scan, but instead of using the default flags, use these TCP flags instead. And here's an example. The same thing with like the FIN scan. You know, a lot of other combinations will work, such as push urge. And another approach, instead of avoiding the IDS entirely, is you can try and overload the IDS using decoy scanning. So here we're gonna say for every packet Nmap sends, and this is a feature it has had for a long time, for every packet Nmap sends, spoof a packet from all these IP addresses that we've specified, so that when the target gets it, their IDS report will look like that. And they'll see the intruder as being all these IP addresses, and they won't really know where to go after. A couple of caveats with this technique, because I see people use it wrongly sometimes, and think they're more anonymous than they are. For one thing, more and more ISPs are starting to implement egress filtering. And so if your ISP is implementing that, you might wanna check because otherwise it might block at your ISPs router all the spoof source addresses, and so the attacker will just see you, and you won't feel quite so clever. Another thing that very inexperienced Nmap users tend to do on occasion is they'll say, well, what host should I use for the decoys? Well, what host do I know? And so they'll put down some popular hosts they think of off the top of their head, and then the admin on the other side says, okay, we've been scanned by yahoo.com, whitehouse.gov, AOL, and ppp478.earthlink.net. I wonder who's really behind this. And so you have to be careful with that. Now if you wanna get the ultimate stealth scan, I think you wanna look at the idle scan technique. Due to time limitations, I can't discuss it all in depth, but it's a really neat technique that allows you to scan a machine without sending any packets at all to that target machine from your own IP address, because you're basically using a zombie machine that you pick from the internet to sort of proxy that scan using an interesting usage of the IP ID field. And I put a paper about that. I wrote, I have it at this URL, and I also stuck it on the DEF CON CD. And so another thing that users ask me a lot is what's that map gonna look like in three to five years from now? And that, I don't have a good answer because I try and follow the evolution of networks and the way they're used, and you never really know, for sure you can't predict where that's gonna go. However, what I often do know is what's the next big feature that I think's cool that's gonna be coming next. And in this case, I think that's gonna be service inversion detection. There are a few reasons that I think that this can be particularly useful and is becoming more and more useful as time goes on. One are the unknown ports you see. You might have saw some of those examples in the Playboy host we looked at where they would have port 21,147 open. Well, that doesn't tell you a lot. You immediately wanna know, well, what's listening on that port? What is it? Can I exploit it? And so with the probing and map will interrogate all the open and closed ports, UDP and TCP, to try and determine what type of service it is that's listening there. And ideally, what's the application name and version number that it's running. This is also helpful for coping with, we've seen more firewall evasion port selection now. Instead of saying, I'm gonna run it on the normal port, that's a well-known port. They say, well, I need to run it on this port because that's the one allowed by the firewall. I had a friend, a not particularly security conscious friend, who said, dang it, my ISP blocked port 23 because Telnet's so insecure. So of course he moves Telnet to port 22 and Telnet's to the SSH port, which shows the kind of level of effort people will go to to avoid even very sensible security mechanisms. But, and also a lot of times people will put stuff on port 80. They'll say, hey, you know, the only thing that gets through is port 80. So we'll just put whatever application on there so that people will be able to get to it and kind of defeat the point of whatever the firewalling was. And so when M-Map by default right now scans them, it'll say, okay, port 80, and it'll put HTTP because that's what the table says. But it would be much better and less misleading if it would actually look and determine what's really listening. And a third reason is to counter UDP filtering. In fact, many years ago, when I would wrote the initial UDP scanner, there was a lot less of the UDP filtering. So you could kind of, when you would send a UDP packet to a wrong port, you had a much higher chance of getting an actual ICMP port unreachable back. Now this filtering is so pervasive that those of you who scan big networks over the internet often find that you see lots of allegedly open ports because they're not really open, but they're being filtered. And so it looks to end map like they're open. And that makes it very hard to figure out which ones are really there and would it be a waste of time to brute force the SNMP community strings if it's really probably just filtered. And so with the version detection, that offers a way to somewhat counter that because if we send a DNS server status probe and get a response back, we know that A is DNS and B that it actually is open. And for the other ports, I can put some sort of open slash filtered state for that. Now this isn't entirely vaporware. In fact, I spent a lot of July working on an implementation of that, the service inversion detection. And so let me just give a quick demonstration. We wanna do an end map and we wanna do, let's do a SIN scan. We'll do a UDP scan. We want it to be verbose about it. We'll do OS detection just for fun and we'll do this about on local host. And so here it goes. It's scanning the default 1600 TCP ports. Now it's scanning the default 1400 UDP ports. Now it's starting the new service scan against the services that it's located. Now it's doing RPC grinding to find the RPC numbers by brute force of the RPC services. Then it did OS detection and now here it gave us the results. And for those of you who are used to seeing end map output, you see the difference here is in this section. First of all, these services here, instead of just coming from a table, these were detected through the interrogation techniques. And if it hadn't been able to find them, it would have put like a question mark after the service name. And also there's this brand new version table which tells us not only that it's SSH, but it's open SSH 351 patch one protocol 199. The RPC bind is version two and here's the RPC program number. The internet printing protocol server is Cups 1.1 and X11 is X386 and then it's open. Only open to 127.0.0.1 mind you, so don't get any ideas. And so that's basically how that's gonna work. And I think the implementation, hopefully it'll be a relatively good one. It's doing it, it's all in parallel, multiple ports at the same time as well as being able to do multiple machines at the same time. A TCP, UDP, IPv6 is the TCP and UDP work now, IPv6 I'm still adding. One thing I'm excited about is just like with OS detection, when it detects a service it doesn't know, but it gets some responses to any of its probes. It gives you a nice fingerprint that you can submit. And so hopefully that will help me build a very large comprehensive database that'll give us good results against most of the machines we scan. So far the database isn't so big, but I just last week did scans against hundreds of thousands of machines to get all these service numbers. I had to stop because of ISP complaints, but I did get a lot of stuff there. And so I wish I could give you this releases today right now with an URL, but it's not quite polished enough for the final release, but I'm hoping to have it in the next two weeks. I figure I'll take next week recovering from DEF CON and then work hard the week after that and then release it. But for those of you who are kind of real good testers and saying good test reports and are really interested in trying the bleeding edge, if you catch me around the CON sometime, I can give you an URL for this version if you want to try it out. And so that's basically the material that I had. Is there anybody who has questions about network reconnaissance, NMAP or anything else security related? Go ahead. Yeah, the windows don't make the best idle host zombies because they're always spewing that crap all over the network. So, but fortunately, there's plenty of machines on the internet, printers, hosts that aren't doing much, that it's usually not hard to find them. And you can use any of the idle hosts you have to scan any of the other machines. And so find a good one and stick with that. In one of my example paper, I used a host on the Adobe because I was kind of mad about the Dmitri thing at the time. It was kiosk.adobe.com. And within like a day, I noticed kiosk, the name had been removed, but all they did is remove the DNS name whereas the IP address was still there. So that's kind of an example of what I was talking about where the admins sometimes take the easy approach and say, well, we'll just remove the name and no one will find it as opposed to fixing the actual problem. Any other questions? Back there. I can't hear you at all. Okay. Okay, I mean, I've looked at Packet Koretsu a little, but I may not have looked at his newest stuff. Any others? Okay, way back there. Oh, sorry, that's just my warning to five minutes. I have to get the hell out of here. Okay, yeah, he mentioned Jay Freeman, a Zurich who may be here today. Also has a version and service detection patch for NMAP that's been around for a few years. And he's one of the people that I've been talking to. I looked at a lot of the other version service detection things out there. AMAP, Nessus has a very simple one implemented, an NMAP plus V, and I got a group of about 30 of kind of the top NMAP contributors together. And so we've been doing these private releases. And Jay Zurich is one of the ones who's provided valuable insight into improving this implementation here. Although it's a completely different implementation. One last question, go ahead. Yes, I don't think you can fake the root dance. You can only do it when you get root or if a hot babe in the movies uses your product. But thanks a lot, you've been a great audience.