I have recently been involved in a work of security assessment on multiple servers hosted in the same data center but in different vlans. One requirement that I had to respect it is that the port scan procedure on all these servers (all windows 2008 servers) should be fast and not require additional software to buy . Unluckily the tool that was used was a simple netstat command to be issued manually on each server.
Now this has the advantage of being fast (netstat gives you the overall situation in a fraction of second) but has at least two major limitations : no indication of the process running on the port (only the PID) and most of all is completely manual.
First thing I tried was to leverage powershell commands , specifically this great resource that basically gives already the right process name and other useful info on the processes running on each port with all the required network statistics. Theoretically this should work also remotely but I never managed to make it work successfully (several times crashing because of the need of writing on the remote system a file). So I thought that netstat and a good combination of great Mark Russinovich PSTools (psexec to execute netstat remotely and pslist to retrive the processes remotely) could solve the problem. In theory yes, in practice I had to fight a bit with c# to obtain the desired result.
Here the recipe:
First go here to see how to launch PSTools from c# and parse the output coming from netstat. Be aware that this does not work on the local computer but you have to issue the netstat without psexec.
Second apply the same trick to pslist and parse the results (this works also on the local computer).
Third now that you have this just put the data inside some structures (I used DataTables) and with a simple Linq query you will join network statistics and processes running.
The only thing to check is that PsTools works requiring that Ports 135 and 445 (TCP) need to be open and Admin$ and IPC$ shares enabled, so in my case I had to run my console program on each segregated VLAN and in some cases on some servers alone, but finally I managed to cut the manual operations from 75 manual runs to 8 and it’s already a good result.