BUG: nmap -sT scan hangs

[0xdf-0xdf]

Describe the bug and expected behavior When I run nmap with -sT flag, it hangs. It may only occur with the -p- option. Looking in wireshark, I see it making connections to the same port over and over again. The port seems to change on each run, but always an open port. I've tried on multiple hosts, both windows and linux targets.

To Reproduce Steps to reproduce the behavior:

1. open cmder
2. open wireshark and start capture on appropriate interface
3. run nmap -sT -p- --min-rate 10000 [ip with a couple ports open]
4. look at statistics -> conversations in wireshark and see one port getting connected to over and over.

Example Without -sT, finishes all ports in 32 seconds. With it, it's 2.5 minutes in, with 2.5 hours remaining.

Z:\+
λ nmap -p- --min-rate 10000 10.10.10.131
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:11 GMT Daylight Time
Warning: 10.10.10.131 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.10.10.131
Host is up (0.064s latency).
Not shown: 64681 closed ports, 850 filtered ports
PORT    STATE SERVICE
21/tcp  open  ftp
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 32.12 seconds

Z:\+
λ nmap -sT -p- --min-rate 10000 10.10.10.131
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:12 GMT Daylight Time
Stats: 0:02:24 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 1.58% done; ETC: 00:43 (2:28:54 remaining)

If I look in wireshark, I have about 100 conversations with port 21 already (Linux target).

Second target, Windows host:

Z:\+
λ nmap -p- --min-rate 10000 10.10.10.132
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:18 GMT Daylight Time
Nmap scan report for 10.10.10.132
Host is up (0.041s latency).
Not shown: 65530 filtered ports
PORT      STATE SERVICE
135/tcp   open  msrpc
445/tcp   open  microsoft-ds
5985/tcp  open  wsman
8080/tcp  open  http-proxy
49667/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 14.00 seconds

Z:\+
λ nmap -sT -p- --min-rate 10000 10.10.10.132
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:18 GMT Daylight Time
Stats: 0:00:49 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 1.73% done; ETC: 23:06 (0:46:27 remaining)

Wireshark shows this one gets stuck on 8080 (managed engine servicedesk plus).

Third example, edge router x in local network:

Z:\+
λ nmap -p- --min-rate 10000 10.1.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:20 GMT Daylight Time
Nmap scan report for 10.1.1.1
Host is up (0.00s latency).
Not shown: 65530 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
53/tcp    open  domain
80/tcp    open  http
443/tcp   open  https
10001/tcp open  scp-config
MAC Address: 80:2A:A8:DE:99:EF (Ubiquiti Networks)

Nmap done: 1 IP address (1 host up) scanned in 4.11 seconds

Z:\+
λ nmap -sT -p- --min-rate 10000 10.1.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-09 22:20 GMT Daylight Time
Stats: 0:00:40 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 1.39% done; ETC: 23:07 (0:46:13 remaining)

Repeated scans to 443, https.

Version

• OS: Windows 10

Additional context First two hosts are over VPN to Hackthebox.eu targets. Third example is in local network.

[day1player]

@0xdf-0xdf Thanks for the issue submission, I just want to let you know were still looking into this. Chances are it has to do with the actual software itself, and not Commando. Will keep you posted :-)

[day1player]

@0xdf-0xdf Are you still having this issue?

I just ran some scans to test again, it appears I am having the same issue, however, my scan did eventually finish.. I was able to scan a host with no flags in 123 seconds, however when adding the -sT flag it ended up taking 47 minutes.. My bet is that its a performance issue with Windows.

C:\Users\kevin>nmap -p- 192.168.38.102
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-10 11:33 Pacific Daylight Time
Nmap scan report for dc.windomain.local (192.168.38.102)
Host is up (0.0065s latency).
Not shown: 65514 filtered ports
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5985/tcp  open  wsman
9389/tcp  open  adws
49666/tcp open  unknown
49667/tcp open  unknown
49677/tcp open  unknown
49678/tcp open  unknown
49680/tcp open  unknown
49695/tcp open  unknown
49711/tcp open  unknown
MAC Address: 00:0C:29:A2:8E:4A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 123.64 seconds

COMMANDO Fri 05/10/2019 11:35:39.61
C:\Users\kevin>nmap -sT -p- 192.168.38.102
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-10 11:35 Pacific Daylight Time
Nmap scan report for dc.windomain.local (192.168.38.102)
Host is up (0.00097s latency).
Not shown: 65514 filtered ports
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5985/tcp  open  wsman
9389/tcp  open  adws
49666/tcp open  unknown
49667/tcp open  unknown
49677/tcp open  unknown
49678/tcp open  unknown
49680/tcp open  unknown
49695/tcp open  unknown
49711/tcp open  unknown
MAC Address: 00:0C:29:A2:8E:4A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 2830.08 seconds

[0xdf-0xdf]

Yes, I'm still having the same issue. I think you are right, that it eventually finishes. That's just so weird as to why?

On Fri, May 10, 2019 at 8:33 PM day1player notifications@github.com wrote:

@0xdf-0xdf https://github.com/0xdf-0xdf Are you still having this issue?

I just ran some scans to test again, it appears I am having the same issue, however, my scan did eventually finish.. I was able to scan a host with no flags in 123 seconds, however when adding the -sT flag it ended up taking 47 minutes.. My bet is that its a performance issue with Windows.

C:\Users\kevin>nmap -p- 192.168.38.102 Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-10 11:33 Pacific Daylight Time Nmap scan report for dc.windomain.local (192.168.38.102) Host is up (0.0065s latency). Not shown: 65514 filtered ports PORT STATE SERVICE 53/tcp open domain 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3389/tcp open ms-wbt-server 5985/tcp open wsman 9389/tcp open adws 49666/tcp open unknown 49667/tcp open unknown 49677/tcp open unknown 49678/tcp open unknown 49680/tcp open unknown 49695/tcp open unknown 49711/tcp open unknown MAC Address: 00:0C:29:A2:8E:4A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 123.64 seconds

COMMANDO Fri 05/10/2019 11:35:39.61 C:\Users\kevin>nmap -sT -p- 192.168.38.102 Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-10 11:35 Pacific Daylight Time Nmap scan report for dc.windomain.local (192.168.38.102) Host is up (0.00097s latency). Not shown: 65514 filtered ports PORT STATE SERVICE 53/tcp open domain 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3389/tcp open ms-wbt-server 5985/tcp open wsman 9389/tcp open adws 49666/tcp open unknown 49667/tcp open unknown 49677/tcp open unknown 49678/tcp open unknown 49680/tcp open unknown 49695/tcp open unknown 49711/tcp open unknown MAC Address: 00:0C:29:A2:8E:4A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 2830.08 seconds

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fireeye/commando-vm/issues/37#issuecomment-491405515, or mute the thread https://github.com/notifications/unsubscribe-auth/ACG3U7QTBSMJHPMAVJUQBPDPUXEW3ANCNFSM4HEWUHGA .

[day1player]

@0xdf-0xdf it seems like this is an issue with running nmap on Windows, and there doesn't appear to be anything we can do to fix it. I am going to close this issue as an upstream issue. Thank you for all of your feedback, please let us know if you have any other suggestions.

[0xdf-0xdf]

Thanks for following up. I suspected that would be an issue with nmap.