Scanning Windows XP with NMAP

Could someone tell me why is it possible that I can run using that last specific NMAP command shows a good result, and other NMAP commands shows that the host is down?

Perhaps you could say what you expect to happen? Not just 'it should work', but what kind of packets you expect nmap to send to the target?

When I see '-sn' and '-Pn' together, I'm never really sure that they'll accomplish anything useful. To start with, -sn says that there will be no port scan, only a ping scan. Next, -Pn says that host discovery should be skipped and all hosts should be assumed to be online.

To me, that doesn't make a lot of sense. -sn, with one of the -PS/-PA/-PP/… options, OK. And -Pn with one of the -sS/-sT/-sA/… options, OK – particularly when you don't trust the hosts to send ICMP replies. But together … it looks very much like they will assume everything is online without actually doing anything. That's just what you're seeing nmap reports that the host is up, because you've specified it should not do *anything* else.

Have you checked if any packets were sent from nmap to the target system, and if so, if any packets were send in response?

It's easy – just add '–packet-trace', and you'll get SENT and RCVD (and NSOCK) lines.

A couple of tests tend to confirm my idea I see no logged packets at all with '-sn -Pn'. But I'm testing another type of network, so I suggest you make your own tests on yours.

Thanks alot for your reply.

Just running NMAP with -sn -PR on another Virtual Maching (Using Linux Fedora this time) I got a better result showing that the host is up, along with it's MAC address. So that is completely OK, and that WinXP is responding back to NMAP requests.

And back to my Windows 7 host, I ran the same command but with the –packet-trace switch and still determines that WinXP is down

SENT (5.6180s) ARP who-has 192.168.1.14 tell 192.168.1.1
SENT (5.7200s) ARP who-has 192.168.1.14 tell 192.168.1.1
Note Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done 1 IP address (0 hosts up) scanned in 5.83 seconds

(192.168.1.14 is WinXP)
(192.168.1.1 is Win7 host)

So it seems that WinXP replies back to Fedora that the host is up, but not Windows 7? Maybe Windows is not a relieble OS for troubleshooting with NMAP?

Unless I use -Sv -Pn to list ports open, it seems OK.

Its very strange

Thanks

And back to my Windows 7 host, I ran the same command but with the –packet-trace switch and still determines that WinXP is down

SENT (5.6180s) ARP who-has 192.168.1.14 tell 192.168.1.1
SENT (5.7200s) ARP who-has 192.168.1.14 tell 192.168.1.1

So it seems that WinXP replies back to Fedora that the host is up, but not Windows 7? Maybe Windows is not a relieble OS for troubleshooting with NMAP?

You don't know yet (?) that the packets arrive at the host – do they? It could easily be some network problem that prevents them from arriving. For example, you have ensured that the VMWare client network is correctly configured, I hope. And, in extreme cases, it could even be that the host receives the ARP packets, and sends replies, but it is the replies that don't make it back. All you can see from the packet trace is that packets are sent. You can't decide where they are lost. That's the next step.

If I understand your setup, you can send from VM client Fedora to VM client Win7 (on the same network), but not host to VM client Win7. How about host to VMClient Fedora – does that work? If it does, I'd guess it's som Win7 configuration. But if it doesn't work, I'd guess there's something in the virtual network configuration.

Thanks again.

That's true, I have not looked into the received packets.

No my actual setup is, the physical host is Win7, and the two VM clients are Fedora and WinXP. The two VM's are bridged to the local network (having their own 192.168.1.X IP addresses). They can all ping each other. The Fedora VM client can get an NMAP response (host is up) from the other WinXP VM client, but the Win7 host cannot get a good response (host is up) from the WinXP VM client ?

So maybe it is the fact that my Windows 7 host cannot get a reply back from the requested NMAP packet from the WinXP VM client? then it must be my host's local firewall blocking the reply?

Could that be possible?

Thanks

run wireshark and find out =)

So maybe it is the fact that my Windows 7 host cannot get a reply back from the requested NMAP packet from the WinXP VM client? then it must be my host's local firewall blocking the reply?

Could that be possible?

It's possible, but I don't see that you can state that 'it must be my host's firewall'. It appears – at least from my point of view – equally likely that the transition from the virtual network to your Win7 host could be faulty.

At least not until you have verified that the packet actually arrive correctly at the Win7 end. If they don't, the problem is at a lower level in the network.

Does the same scan of the Fedora system work? If it does, the network is probably not to blame.

And besides … does the firewall block ARP or ping requests? My understanding is that firewall works on the port level, i.e. TCP/UDP. ARP is below IP, and ICMP is at the same level as IP, so my gut feeling is that the firewall is not involved.
(Test disable it temporarily, and see if that changes anything.)

(I'm also assuming you're not on a system connected to a domain – GPOs can do a lot, too.)

When I do this kind of experiment, I use only virtual computers, all connected to the same virtual network (VMnetX or other custom network or special LAN segment). The VMware host is not involved in any way, mainly because I don't want to modify its network configuration, or install unusual software being tested. It also helps me ensure that I'm testing on a default system configuration.

I’m probably barking up the wrong tree here but if I’m right you are trying to run a TCP Null (-sn) scan against the Windows XP VM? In that case it might be a case of Windows XP not answering to the scan as it should by RFC. The TCP NULL scan works by sending malformed packets to the target and according to RFC an open port should discard the packets while a closed port should return a RST to the source. At least some Microsoft OS returns RST to all malformed packets rendering TCP NULL scan useless. Perhaps your Linux machine has a newer version of NMAP that has found a way to handle this problem? Or then again perhaps I’m all wrong, after all I’ve just started in this world of forensics D

Thanks for your replies guys.

Accordingly from Wireshark no packets are being received to the Fedora VM Client from the Win7 host. (Possibly as you said it's probably a 'host to virtual client' network fault)

And yes the scan for the Fedora client from the Win7 host is not a good result (host is down).
But a scan from the Fedora client VM can successfully identify the Win7 host (host is up).

If the network could be the problem, then how come all VM's can ping each other including the Win7 Host, and vice versa Wind7 host to VM clients? (Also keeping in mind that the VM clients are bridged to the network).

And yes I turned off the host's firewall and still gives me the same result.

If I was to conclude the whole thing, maybe I'd say that the Virtualbox hypervisor could be causing problems to the Win7 host, and that the two VM's can scan each other using NMAP successfully. (Again a scan from the Fedora VM can scan the Win7 Host).

And yes I guess it is a NULL scan…Which is a basic ping to test if the client is alive…but with an ARP packet. Accordingly to the description, using -sn is a hybrid scan with ARP, ICMP and TCP packets. And they are the same version.

Thanks again