PortQry and PortQryUI

I was aware of PortQry but didn’t know it has a GUI counterpart too PortQryUI. For a quick read on PortQry check out this link, if you have more time and interest check out this KB article. PortQry/ PortQryUI can be used to check the status of TCP and UDP ports on a remote computer. For TCP ports I usually do a telnet to the port (by habit) but didn’t have any equivalent tool for UDP ports. 

Important PortQry switches (as a reference to myself) are:

• -n -> specifies the server name/ IP address to target
• -p -> specifies the protocol to test (options are tcp or udp or both; default is tcp)
• -e -> specifies the port(s) to test (default is port 80)
  • note: it is possible to specify a single port (e.g. -e 81), ports (e.g. -e 80,81) or a range (e.g. -e 80-1024)
  • note: the ports must be in the range 1-65535
• instead of -e you can use either of the following too:
  • -r -> specifies a port range (e.g. –r 80:90)
  • -o -> specifies a comma-separated list of ports to check in order (e.g. -o 80,443,139)

Some other switches are:

• -nr -> stops PortQry from resolving an IP address to a name
• -sl -> waits longer for replies from UDP systems (sl == slow link)
• -l -> specifies a log file to output to
  • -y -> will over-write the log file if it exists, without prompting

While writing this post I learnt that PortQry can also enumerate the local ports. Nice!

• The -local switch will list all active TCP/UDP ports on the local system. (Think of it as netstat -a but without any details of the remote end).
• The -wport (port number) switch will watch a specified port’s state and report when it changes
  • This didn’t work for me, got an error “Port to process mapping is not supported on this system”.
• The -wpid (PID) switch will watch a specified process ID (PID) and reports when its state changes
  • This too didn’t work for me, same error as above.

A good thing about PortQry is that it can also query protocols that it’s aware of. Thus, for instance, if you query port 53/ UDP (DNS) and something’s listening at the remote end, PortQry can send an additional DNS query to that port. 

This is useful in AD troubleshooting too. For instance, to check whether port 389 of a DC has an LDAP server listening as it should be:

Similarly, RPC:

In the output above, for instance, I query port 135/ TCP which is where the RPC end-mapper service listens. After querying this port and getting a response, PortQry asks it to enumerate the listening services. Of these UUID 12345887-... is what the netlogon service registers under, which as we can see from the above output is listening on ports 49155 (via TCP), 49158 (via TCP), and 49157 (via HTTP). (Netlogon registers with RPC and uses dynamic ports as we saw above, so querying the RPC end-mapper service is the only way to find what ports Netlogon is listening on). 

In contrast to PortQry, PortQryUI has options to query for the services it is aware of. So, for instance, one can use it to query the “Domains and Trusts” service on a DC and it will do PortQry queries to port 135/TCP, port 389/BOTH, port 445/TCP, port 137/UDP, and a few other AD related ports and emit the output in a window (you can see part of the output in the screenshot below).