DIY port scanner for windows sysadmins 

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.

Crack .NET assemblies on the fly

Hi, I recently have been into a DEFCON 1 situation and I want to share with you my experience.

Basically imagine a production .net assembly that does the job quietly for 5-6 years and one day it decides to stop working ,this means that an entire segment of the business of a large enterprise is completely blocked…

To this add that developer of that assembly no longer works in the company, nobody knows where the source code can be and actually there is no  documentation.

So they call me and I felt like this:

So downloaded ILSpy and I started looking into the code while gathering the logs and checking the exceptions.

Thanks to some very lucky combo of checks I was able to figure out where the problem was in a couple of hours (windows update I hate you), but in the mean time the pressure bar was rising and the client was just going crazy. So I remembered that one time I used a tool called reflexil to fix on the fly an assembly, but later I figured out that it works nice with reflector but not with IlSpy…

However thanks to this post I was able to download a version of reflexil that was compatible with IlSpy and problem solved!

Here is a screenshot of the two working together :

ILSpyReflexil

It’s actually a great combo and I can’t wait to have the final bits.

PS : The code that you see it’s not the client’s code of course 🙂