Enter your search terms Submit search form
	Web www.foofus.net

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!

09/18/2008:

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.

05/07/2008:

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.

04/25/2008:

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 changed:

• 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):

1. Host IP/name
2. Windows error number (e.g. 5 for access denied)
3. 1 if processes are still (possibly) running on the target, 0 if everything should be cleaned up
4. 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!

09/16/2007:

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. :)

07/25/2007:

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 case. :)

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 foofus.

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:

1. Bind to a remote machine (or a list of machines) using IPC$
2. Stop AV, if it is installed
3. Locate file shares exposed on that machine
4. Find a writable share from the above list, bind it to a local drive
5. Upload fgexec (used for remote command execution), cachedump
6. Run pwdump (with password history dump as well)
7. Run cachedump
8. Run pstgdump
9. Delete uploaded files from the file share
10. Unbind the remote file share
11. Restart AV if it was running
12. 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 available parameters.

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 at off-by-one.net. 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 here. 
• pstgdump: A protected storage dumper. This can reveal some VERY interesting information, including saved IE and Outlook Express passwords.

KNOWN ISSUES:

• None that I am aware of at this time

NOTES:

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. :)

COMPILING:

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 box. :)

DISCLAIMER:

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 me. :)

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 File Sharing