Interestingly enough, I found last week that the new Nessus 4.2.0 works by default as a web interface. Gone are the days of using the NessusClient and connecting to TCP port 1241 and using it to connect to the nessusd. Connecting to local TCP port 8834 (https://localhost:8834) brings you to a web interface that you can use to connect to the new Nessus daemon. The nesssusd listener does not even listen on port 1241 by default.
I’ll shortly get used to it but I know the transition would be slow for me …. after it takes getting used to when you completely change the architecture after maintaining it for at least a good 7 years or so!

In a pen test, it’s always the race to the finish. Either you get to the domain admin or r00t or you die tryin’! 🙂 But thanks to some real l33t fu by Hernan Ochoa this has only been made easy for you.
The key to pass-the-hash attacks is that Windows NTLM authentication relies on the passing of the right hash to identify you. As long as the right hash is stored in the authenticated session you are who you say you are.
Hernan Ochoa’s Pass-the-hash toolkit (http://oss.coresecurity.com/projects/pshtoolkit.htm) is precisely the tool for that. Once you gain local admin rights on a box, just run the whosthere.exe utility on the box. Mind you, in differing versions of Windows you need some right addresses to pass as parameters. So the first thing to do is goto C:\WINDOWS\system32 and copy the lsasrv.dll file onto your local machine. The pass-the-hash src tar ball, has an IDA Pro script passthehash.idc that you need to run after opening the file in IDA Pro. This will give you the right addresses to pass to whosthere.exe:
whosthere.exe -a -o outputfile.txt

Once you have the hash you could either use iam.exe or winexe (http://eol.ovh.org/winexe/) with pass-the-hash patch from jo-mo-kun (http://www.foofus.net/jmk/tools/winexe), or samba with jomo kun’s pass the hash patch.
Just set the Environment variable SMBHASH to the hash value such as

export SMBHASH="92D887C9910492C3254E2DF489A880E4:7A2EDE4F51B94203984C6BA21239CF63"

Then run winexe as

./winexe -U "Domain\\Username" //192.168.0.1 "cmd.exe"

Of course, you can also expend some time in cracking the LM hashes to get the actual passwords but it isn’t really necessary.

I was just browsing away when I stumbled upon Johnny Long’s GooScan. He says that this is a Linux only tool but it seems to compile (not without problems though) on cygwin.
I kept getting the following errors:

L:\tools\gooscan-v1.0.9>gcc gooscan.c
gooscan.c: In function `inet_send':
gooscan.c:575: error: `MSG_WAITALL' undeclared (first 
                       use in this function)
gooscan.c:575: error: (Each undeclared identifier is 
                       reported only once
gooscan.c:575: error: for each function it appears in.)

Then I read somewhere that MSG_WAITALL is not defined for Cygwin and that instead of that zero would work. There are many neater solutions to this…but I’m a hacker and I’ll do the stuff that’s easiest and hassle-free.
Some people say that the following will work:
#ifdef __CYGWIN__
#define MSG_WAITALL 0

So in order to compile this bad boy, you need to goto line 574 in your favorite editor.
It looks like this:
recv(sock, recvbuf, sizeof(recvbuf), MSG_WAITALL);

You need to make it look like this:
recv(sock, recvbuf, sizeof(recvbuf), 0);//MSG_WAITALL);

You are all set:
gcc gooscan.c -o gooscan.exe

Compilation works! But then I observed that the results were not coming well. However, if you run it through a local proxy such as burp it still works…I bet it has something to do with socket establishment and receiving and being incompatible with the MSG_WAITALL flag.
But as long as you can get the results … who cares? If someone figures out exactly how to make this work, please post it as a comment.

It can get interesting to test the security of thick client applications. If you start debugging you could end up losing a lot of time with not too many results. Of course, time is always at a premium when you pen testing in a week long gig. There are a couple of tools that can really help you to gain insight into a thick client (i.e., an application written in a binary format such as an executable, ActiveX control, flash object, etc.) and communicating to a server using the client/server model.
The need for a proxy to hook into the communications is a prime need and EchoMirage can do a great job of hooking into function calls related to win32 sockets, openssl functions. You have to select an active process for Echomirage to inject into or you can even spawn a process from the menu options in EchoMirage itself. It’s a great tool with a built-in editor so you can edit the traffic. However, sometimes you have to be careful because it’s binary data that you are editing so while editing it is easy to mess up a few flags, etc.
Another great tool is actually a plugin for OllyDbg called UHooker that can let you specify which functions you want to place a hook into. You have to configure a binary editor of your choosing and the functions to be hooked into in a .cfg file. The documentation for Uhooker is located here.

Installing Firewalk turned out to be more complicated than I thought it would be. There were some compilation issues and some library errors.
The chief amongst them was:

checking for arp_get in -ldnet... no
configure: error: No libdnet?  http://libdnet.sourceforge.net.

I did install libdnet using aptitude but it did not do the trick. Thereafer, searching a few forums got me this information. The “Libdnet” that Firewalk looks for is libdumbnet1 in the ubuntu language.
So I got the Debian packages from the following links:
libdnet1
libdnet-dev
I continued to get that error and no wonder because there was nothing in /usr/lib.
So I executed the following commands :

$ cd /usr/lib
$ sudo ln -s libdumbnet.so libdnet.so
$ cd /usr/include
$ sudo ln -s dumbnet.h dnet.h

Then there was a compilation error:

firewalk.c: In function ‘firewalk’:
firewalk.c:193: error: label at end of compound statement
make[1]: *** [firewalk.o] Error 1
make[1]: Leaving directory `/home/trance/Desktop/Firewalk/src'
make: *** [all-recursive] Error 1

So then opening the firewalk.c file in vim (and following up on line 193) showed that the “break;” statement was missing after default: switch statement.
So then I added the the following characters (without quotes) “break;” at a line above the comment as shown below:

                    default:
                        break;
                        /* empty */

$ ./configure
$ make
$ sudo make install
$ sudo cp man/firewalk.8 /usr/local/man/man8

Now firewalk was installed and ready to use!