[foofus-tools] All in one (pwdump6, fgdump, medusa).

[jmk]

On Mon, 2009-03-23 at 12:11 -0500, Richard Miles wrote:
> It's my first e-mail to the list, I would like to thank you for the nice tools.

You're welcome. ;)


> Let's go to the point...
> 
> A - I don't know why, but I have a Windows 2003 SP2 machine, and
> fgdump.exe running locally ALWAYS fail (with admin credential OR
> SYSTEM).

I'll leave this one for Fizzgig...


> B - In this specific case, my output from pwdump6 do not have full
> hash, it's like this:
> 
> user:18298:NO PASSWORD*********************:AE9B66EA07C92E0DAE170D937CC57C4D:::
> 
> What type is the first half of hash missing? The question is, there is
> anyway to brute force it? Using rainbow tables?
> 
> Or how to use it in tools like Pass The Hash Toolkit.

A pwdump entry contains a number of fields: username, RID, LM hash and
the NTLM hash. In this case, the LM hash is blank (i.e. NO
PASSWORD****..."). This may be due to the user's password being longer
than 14 characters in length or the GPO being set to avoid setting the
LM hash value. In either case, only the NTLM hash is of use to you.

If you have access to NTLM rainbow tables, you may be able to crack it.
If the LM hash is missing because the password is >14 characters,
Rainbow is probably out of the question. I'd just use Samba with my
patches (http://www.foofus.net/jmk/passhash.html), but the Pass-The-Hash
Toolkit should also be fine.

> C - I believe everybody should ask about it. Most AV today detect
> pwdump6 and fgdump and make it a bit harder for use. Do you suggest me
> some link to learn how to effectively avoid them?

I'll leave for Fizzgig again...

> D - The last, but not less important, Medusa. I have compiled it in a
> RHE4 (CentOS 4 like). The point is that even with the glibc headers
> kernel headers if failed, configure pointed that was missing a
> com_err.h, which really do not exist, so I looked at internet and just
> grabbed a copy and it worked fine.

Is this Medusa version 1.5?


> What I'm noticing is that the Medusa work for some time (in average
> try from 450 until 1300 passwords) and it say that it couldn't connect
> anymore to the SQL Server.
> 
> I tried use option "-t 1" but did not solved.
> 
> A point is that the server continue up and running, if in the sequence
> of the error I telnet to it, I can connect successful.
> 
> Don't know if it make difference, but I'm brute-forcing without
> password list, so I use a long userlist and just test if for null
> password and username as password.
> 
> By what I understand, when Medusa get a connection failed like this,
> it should try more 3 times before fail and exit, right? But it do not
> happen, it exist at first connection exit.
> 
> A interesting note, is that when it fail, it give a message that I
> should enable pthread_cancel.

If I'm understanding the situation correctly, this is actually a known
problem in the core of Medusa. If you performed a SMBNT single password
brute against a single host with 1200+ users, you'd likely see the same
problem. 

Medusa (v1.5 and before) creates a new thread for each user being
tested. When you combine a large number of users with only a few
passwords with a relatively fast protocol like MS-SQL or SMB, the
system's ability to create/destroy threads appears to be unable to keep
up. 

The solution to this issue is to do away with the original design and
move to a proper thread pool within Medusa. This is actually done and
the problem no longer appears to exist. However, it'll probably be a few
months before I finish the other items I'm working and release the next
version. In the mean time, I'd recommend using a shorter user list (e.g.
<1200) or a longer password list.

Joe