A Tool For Mass Password Auditing of Windows Systems
Version 2.1.0 of fgdump is now available!
We now have a mailing list for all of our foofus.net tools! If you'd like to join, please see the
mailman page at
http://lists.foofus.net/listinfo.cgi/foofus-tools-foofus.net. This is a great way to get
help on using the tools, report bugs, make feature requests and find out about new releases first!
I've been researching Vista/2008 compatibility, and it appears the password dumping portion
works just fine. Cachedump has been problematic, but checking out some posts at oxid.it and
a few other locations have given me the drive to get that updated and working for Vista/2008.
I am hoping to have that available quite soon.
Also, I'm hoping to eventually get rid of the "dependence" on pwdump and cachedump executables.
This will necessitate me changing how fgexec (the service that carries out remote execution)
works, but I think it will simplify things quite a bit in the long term. I'm going to finalize
Vista/2008 support first, but expect another major revision soon as well that severs ties
with the old pwdump6/cachedump code base.
Found a couple issues with fgdump, not the least of which is that the remote 64-bit detection
was far from perfect. It's still not perfect, but it IS better. Here's the notes for the release:
- Better 32/64 bit detection. This is not as easy as it sounds, at least not remotely!
If someone has a sure-fire way for 100% reliably detecting the target OS, please let me know.
In the mean time, if fgdump is unsure, it will report it and default to 32-bit.
- The -O [32|64] flag will manually override the target OS architecture. So, for example
if fgdump is reporting a host as 32-bit and you KNOW it is 64-bit, you can use -O 64 (or
vice-versa, of course). Note that this flag will apply to ALL hosts you are dumping!
You might want to single out any hosts you need to override.
- cachedump64.exe was not being deleted from 64-bit targets, which should be fixed now.
I love having time to update tools.
I got around to adding 64-bit support to pwdump (1.7.0) and cachedump (technically
referring to it as 2.0), which means I needed to build a new version of fgdump.
At the same time, I rolled out a few new features which I've either been sitting
on, or have been talking about for awhile. And of course, as is typical with new
releases, most AV is blind at least for a bit. :) Here's a list of things that have
- fgdump will now detect 64-bit targets and report them as such
- 64-bit pwdump and cachedump will be used when the target is detected as 64-bit
- Fixed a problem when connecting to some Samba servers where RegQueryValueEx would not behave as expected
- fgdump will now generate a session ID during each run - used to correlate failed logs and regular logs
- Added command line to log file
- Added session ID to log file
- Created a new file with the format (session-id).failed which contains greppable data on failed hosts
- A log file is always generated of the format (session-id).fgdump-log
- -l will now override the default log name (see above)
- Added -a option to prevent tampering with AV. This is useful if you know AV is not picking it up,
you want to tamper with the target as little as possible
A couple of notes about the log files. First off, a log file will ALWAYS be generated
now, and will contain the date and time of the run. You can override this using
-l if you want it to be named something specific. fgdump will now also generate
a .failed file, which will contain a list of hosts that were unsuccessful. This
file contains greppable records so you can quickly identify what hosts failed, why,
and if there are still processes running on the host. This should help during the
cleanup phase. The fields in this file are as follows (all separated by "|" characters):
- Host IP/name
- Windows error number (e.g. 5 for access denied)
- 1 if processes are still (possibly) running on the target, 0 if everything should be cleaned up
- Text of the error, if available
Additionally, the command line used to invoke fgdump is stored in the log file now.
This means, if you pass the password on the command line, IT WILL BE RECORDED IN
THE LOG FILE! If this bothers you, please omit the -p parameter and simply provide
the password when fgdump asks for it. Please also note that this version has quite a number of changes in it and, while
I'm releasing it as non-beta, there is a higher-than-normal chance for bugginess.
As usual, please report any issues you find.
It's interesting to me that bugs seem to come in batches. Take, for
example, the main bug that prompted the release of 1.7.0 - I received
several emails back to back all asking about the same issue, whereas I
had not seen that particular problem ever brought up before. As it turns
out, the bug had been in the code since day 1, it's just no one had
reported it until now. Or I missed their email, which happens periodically.
So 1.7.0 addresses this latest bug, namely error messages of the form
something like "Could not connect to \\and\ipc$: Error XX." This was
a result of not putting quotation marks around a portion of the pwdump
command line, and thus getting weird results from that program. Also
in this release is a first pass at disabling Sophos AV, since we actually
ran into this at a customer site. Someone sent me a great link to an
AV service list, so when I get time, I'll be expanding the program to
work with those vendors as well.
Also in this release is a new version of cachedump (dubbed 1.3), with
changes submitted by Richie B. The changes cover a larger buffer size
(20k instead of 4k, should be useful in big domain environments) as
well as adding quotes around the service name, which fixes issues
when the service got installed into a path with a space in it.
Many thanks to him and other folks who have contributed code, bug
reports and feature requests!
The short news is that fgdump 1.6.1 is out. It's a minor revision, and
addresses issues when running locally (namely "could not connect" types
of errors). I also found a printf bug which has been appropriately
taken care of.
I haven't had the chance to comment on Defcon yet, but I have to say, I
was pretty impressed this year. As usual, I learned a bit, drank way too
much and met some cool people. It was great to meet everyone, feel free
to stop by and drink our beer anytime. :)
We've been having a problem since we moved the site, such that certain links
would be broken, images wouldn't show up, that kind of thing. Until we get
this resolved permanently, I've made some changes to the URIs to avoid the
problem. For those of you direct-linking to the site, you can solve this as
well by changing 'www.foofus.net' to 'www.foofus.net'. As I said, I hope this
is temporary, but drop me a line if you have questions.
See you all at Defcon next week!
As promised (though a bit later than I would have liked), I am providing an updated
fgdump which is again a bit more evasive with AV (for now, I'm sure that will change).
This version also resolves a long-standing problem when running against a local box
which would result in an "error 2" for pwdump data. That should no longer be the
I would really like to thank Neil for helping me work through some fgdump
issues - he has been exceptionally helpful in providing detailed error messages,
platform information and doing some testing to squash these most recent bugs. Those
who have offered help, I cannot possibly thank you enough.
As is the usual case, foofus.net will be in full force at Defcon come the beginning
of August. Feel free to drop me a line if you're going as well and would like to
chat about the project, make suggestions, etc. I've also been told I make a mean
brandy old-fashioned, which is a cocktail for those not familiar with it. :)
Also, there have been a few people
who have honestly asked me about donating money to the project (!!!). I don't have anything
official set up, but you can always PayPal money to 'fizzgig -AT- foofus -DOT- net'.
Anything donated goes to the general foofus.net beer fund.
So it seems our friends at McAfee have updated their AV signatures and are once
again detecting pwdump. Now there are a couple of ways I can get around this
certainly, but one stands out as being an easy, quick solution for now. I should
have a new release shortly for those who are running into problems with it.
Thanks to Vitaly for pointing this one out to me - I hadn't seen the updated
defs yet! Also, to the folks at McAfee and other AV vendors: while I understand
you seeing the risks associated with this program, please understand that the
majority of usage is by law-abiding folks trying to perform assessments and the
like, without any ill intention. Yes, there are a few knobs out there probably
attaching it to their trojan/rootkit or whatever, but it seems to me that it's
the larger malicious program you should be going after, not this particular
utility. The reason I am going to such lengths to avoid AV is not out of
a desire to sneak bad programs in, nor to make your life harder. It's simply
so that we can continue to do our legitimate job without wrecking servers
and making people call us bad names. Just my two cents.
** fgdump - A utility for dumping passwords on Windows NT/2000/XP/2003 machines
Written by fizzgig (fizzgig "AT" foofus "DOT" net)
Greets to all my fellow Foofites: j0m0-Kun (who is the inspiration for this
program), phenfen, omi, fade, pmonkey, grunch and of course our namesake
Many thanks to the awesome folks who created cachedump and pwdump3e as well!
Please let me know if this is useful to you, and I welcome (constructive)
comments and suggestions at fizzgig "AT" foofus "DOT" net.
fgdump was born out of frustration with current antivirus (AV) vendors who only
partially handled execution of programs like pwdump. Certain vendors' solutions
would sometimes allow pwdump to run, sometimes not, and sometimes lock up the
box. As such, we as security engineers had to remember to shut off antivirus
before running pwdump and similar utilities like cachedump. Needless to say,
we're forgetful sometimes...
So fgdump started as simply a wrapper around things we had to do to make pwdump
work effectively. Later, cachedump was added to the mix, as were a couple other
variations of AV. Over time it has grown, and continues to grow, to support our
assessments and other projects. We are beginning to use it extensively within
Windows domains for broad password auditing, and in conjunction with other
tools (ownr and pwdumpToMatrix.pl) for discovering implied trust relationships.
fgdump is targetted at the security auditing community, and is designed to be
used for good, not evil. :) Note that, in order to effectively use fgdump,
you're going to need high-power credentials (Administrator or Domain
Administrator, in most cases), thus limiting its usefulness as a hacking tool.
However, hopefully some of you other security folks will find this helpful.
In quick summary, the main code execution path of fgdump is as follows:
Bind to a remote machine (or a list of machines) using IPC$
Stop AV, if it is installed
Locate file shares exposed on that machine
Find a writable share from the above list, bind it to a local drive
Upload fgexec (used for remote command execution), cachedump
Run pwdump (with password history dump as well)
Delete uploaded files from the file share
Unbind the remote file share
Restart AV if it was running
Unbind from IPC$
Many of the parameters associated with these operations are tweakable via the
command line. Run fgdump with no parameters to get the current list of
fgdump embeds several programs within its resource tree. This means you only
need a single executable rather than dragging out a bunch of them. Of important
note are the following:
cachedump: This is the popular cached credential program created by the folks
Currently, the executable is included verbatim.
pwdump6: A heavily modified version of pwdump3e. See the
pwdump6 home page for more information on what it does. Basically, it
includes password history dumping (per some clever guy's post out on teh
Intarweb, and it's less crashy on newer systems.
The source for both of these programs is included in the fgdump source tree, as
mandated by the GPL. If you modify fgdump and still use these programs, please
continue to distribute the source code for these fine programs.
Also in the source tree:
fgexec: A simple service that can be remotely installed that will run a remote
executable. Its very similar in function to psservice or sc, just more limited.
pwdump6: An updated version of pwdump3e. See its web page
pstgdump: A protected storage dumper. This can reveal some VERY interesting
information, including saved IE and Outlook Express passwords.
None that I am aware of at this time
I removed lsadump2 from fgdump. There were a number of issues that were
problematic and, at the end of the day, the amount of useful output it produced
just did not justify adding it at this time.
If you have suggestions on terminating a program on a remote machine that
DOESN'T INVOLVE INSTALLING A NEW SERVICE (like fgexec or psexec do), let me
know. If I can do that, I have a M$AS terminator, but right now I can't execute
it, so I have not yet included it with fgdump. This is a work in progress, and
the subject of furious research. :)
The code was all compiled using Visual Studio .NET 2003, and solution/project
files for it have been included. Ideally, everything should compile out of the
Neither I, nor foofus.net, can take any responsibility for misuse of this
program, nor can I guarantee that it will not have adverse affects on certain
hosts. By using this program, you assume any and all risk associated with the
execution of the program, including but not limited to damage to a system or
data loss. In other words,if you break someone's stuff, don't come crying to
Windows 2000, XP or 2003
Administrative Credentials on Target Systems
Windows 2000, XP or 2003, Vista
Vista cannot currently do cachedumps, and requires enabling Remote Registry and