1

Like this question nmap is showing unknown IPs from 192.168.2.* in my home network which has an IP range of 192.168.1.*.

Unlike the above question, every single IP appears to be completely locked down, including blocking of ping attempts. For all of the IPs (about 70 between 192.168.2.0 and 192.168.2.143), executing nmap -A -Pn results in:

PS C:\Users\Matthew> nmap -A -Pn 192.168.2.137

Starting Nmap 7.01 ( https://nmap.org ) at 2016-01-18 12:14 Central Standard Time
Nmap scan report for 192.168.2.137
Host is up (0.0021s latency).
All 1000 scanned ports on 192.168.2.137 are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

TRACEROUTE (using port 6788/tcp)
HOP RTT      ADDRESS
1   16.00 ms 192.168.2.137

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Based on the comment by AddisonWIlson below i executed the following.

nmap -T4 -A -v -Pn

PS C:\Users\Matthew> nmap -T4 -A -v -Pn 192.168.2.137
Starting Nmap 7.01 ( https://nmap.org ) at 2016-01-18 13:18 Central Standard Time
NSE: Loaded 132 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 13:18
Completed NSE at 13:18, 0.00s elapsed
Initiating NSE at 13:18
Completed NSE at 13:18, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 13:18
Completed Parallel DNS resolution of 1 host. at 13:18, 0.01s elapsed
Initiating SYN Stealth Scan at 13:18
Scanning 192.168.2.137 [1000 ports]
SYN Stealth Scan Timing: About 29.55% done; ETC: 13:20 (0:01:14 remaining)
Increasing send delay for 192.168.2.137 from 0 to 5 due to 65 out of 162 dropped probes since last increase.
Completed SYN Stealth Scan at 13:19, 43.95s elapsed (1000 total ports)
Initiating Service scan at 13:19
Initiating OS detection (try #1) against 192.168.2.137
Initiating Traceroute at 13:19
Completed Traceroute at 13:19, 0.02s elapsed
Initiating Parallel DNS resolution of 1 host. at 13:19
Completed Parallel DNS resolution of 1 host. at 13:19, 5.52s elapsed
NSE: Script scanning 192.168.2.137.
Initiating NSE at 13:19
Completed NSE at 13:19, 0.00s elapsed
Initiating NSE at 13:19
Completed NSE at 13:19, 0.00s elapsed
Nmap scan report for 192.168.2.137
Host is up (0.000077s latency).
All 1000 scanned ports on 192.168.2.137 are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

TRACEROUTE (using port 4998/tcp)
HOP RTT     ADDRESS
1   0.00 ms 192.168.2.137

NSE: Script Post-scanning.
Initiating NSE at 13:19
Completed NSE at 13:19, 0.00s elapsed
Initiating NSE at 13:19
Completed NSE at 13:19, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 54.65 seconds
       Raw packets sent: 1828 (82.664KB) | Rcvd: 1010 (40.400KB)

Called my ISP based on the question linked above, and they said it was not their equipment.

I am new to network admin but have developed software for 20 years, so I am technically inclined. Not sure if any of the following could be the cause.

  • VMWare installed years ago, but never really used.
  • MS HyperV with a virtual switch, however everything on that switch is 192.168.1.*

Anyone have any ideas?

  • I would recommend you do either an "Intense scan," nmap -T4 -A -v, and/or a "Slow comprehensive scan," nmap -sS -sU -T4 -A -v -PE -PP -PS80,443 -PA3389 -PU40125 -PY -g 53 --script "default or (discovery and safe)", to do additional fingerprinting of the target host. – Allison Wilson Jan 18 '16 at 19:10
  • @AddisonWilson I ran the first command line and will update my question. The 2nd command line is executing and looks like it will take an hour. – user41813 Jan 18 '16 at 19:28
  • 1
    I would bet it is your vmware, and you configured it to use NAT instead of bridging. Having an HOP 1 strongly suggests you are in the same network. If you do not use it, deinstall both it and the vmware drivers – Rui F Ribeiro Jan 18 '16 at 20:23
  • Sorry, because my reputation less than 50, I cannot use the comment section. Have you check the VMware IP? I assume that VMware was create his own segment, 192.168.2.*. You doing scan inside your host? Then nmap detect another segment inside your host, is that correct? I thought it was vmware, because it use to communicate your host-os between your guest-os. To verify this, check your firewall. – RizGuard Jan 19 '16 at 12:28
  • I agree with Rui, it is most likely your VMWare. If there is not any OS actively running in VMWare, it would be dropping all the probes like crazy, as there are no services running to receive any traffic. I did not catch the insanely low latency when I saw this the first time, which as others have pointed out, further points to this being VMWare. – Allison Wilson Jan 20 '16 at 14:22
3

Pay attention to the clues you see in the output and start eliminating possibilities.

The latency to this target is 0.000077s, or 77 microseconds. I observe my wireless gateway to have a latency of 0.013s to 0.10s, 3 to 4 orders of magnitude slower. A localhost scan shows something like what you got: 0.000065s to 0.00018s. So this IP is likely running on your own system somewhere, perhaps virtualized.

Change the state of your network and see how the target responds. Unplug your network cable and/or disconnect from your wireless network. Does the IP still respond?

How is the packet getting to the target? Examine your routing tables (netstat -rn or route -n) or ask Nmap what it is doing: nmap --route-dst 192.168.2.137. Is it using a gateway address? Do you have a 192.168.2.0/24 address configured on your system?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.