fgdump is a pretty easy tool to use, but there are a number of options which you can use to make it even easier. Let's start by looking at the command line parameter help, which is accessible by running "fgdump -?"

fgdump [-?][-t][-c][-w][-s][-r][-v][-k][-o][-a][-l logfile][-T threads] [{{-h Host | -f filename} -u Username -p Password | -H filename}]
where Username and Password have administrator credentials

-? displays help (you're looking at it!)
-t will test for the presence of antivirus without actually running the password dumps
-c skips the cache dump
-w skips the password dump
-s performs the protected storage dump
-r forgets about existing pwdump/cachedump files. The default behavior is to skip a host if these files already exist.
-v makes output more verbose. Use twice for greater effect
-k keeps the pwdump/cachedump going even if antivirus is in an unknown state
-l logs all output to logfile
-T runs fgdump with the specified number of parallel threads
-h is the name of the single host to perform the dumps against
-f reads hosts from a line-separated file
-H reads host:username:password from a line-separated file (per-host cr edentials)
-o skips pwdump history dumps
-a will not attempt to detect or stop antivirus, even if it is present

** As of version 1.4.0, you can run fgdump with no parameters to dump the local box (no impersonation or binding)

Now that we've got that out of the way, let's look at some common usage examples. Output from fgdump.exe is stored in files of the format host.pwdump, host.cachedump and host.protectedstorage, where host is the particular host that was dumped. These will be found in the same folder in which fgdump is executing. There are also log files generated of the format session-id.fgdump-log (unless you override the name) and session-id.failed, which contain detailed logs and greppable information on failed hosts, respectively.

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

Dumping a Local Machine Using the Current User

fgdump.exe

Simple enough. Uses the currently logged in user and password to do the dumping (this person obviously must be an administrator).

 

Dumping the Local Machine Using a Different Account

fgdump.exe -h 127.0.0.1 -u AnAdministrativeUser

AnAdministrativeUser's account will be used to perform the password dump against the local machine. You will be prompted for the password when fgdump starts executing.

 

Dumping a Remote Machine (192.168.0.10) Using a Specified User (1)

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser

Here, AnAdministrativeUser's account will be used to perform the password dump. Keep in mind that any user used to perform password dumps needs administrative credentials. In this scenario, you will be prompted for the password before the password dump starts.

 

Dumping a Remote Machine (192.168.0.10) Using a Specified User (2)

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -p l4mep4ssw0rd

The same as the previous example, only the password is specified on the command line. This is obviously bad if someone is shoulder-surfing, but makes scripting fgdump a lot easier.

 

Dumping Many Remote Machines, All With the Same Password

fgdump.exe -f hostfile.txt -u AnAdministrativeUser

In this case, hostfile.txt contains one host per line in a text file. Each host will be dumped using the credentials of AnAdministrativeUser. You will be prompted for the password during the dump run, but you can specify a password using -p as above of course.

 

Dumping Many Remote Machines, Each With Its Own Username and Password

fgdump.exe -H combofile.txt

combofile.txt should contain line separated files of the form host:user:password where host is the individual host to be dumped, user is the username for that host and password is, obviously, the password. Lines which do not follow this format will be ignored

 

Dumping Many Remote Machines More Efficiently

fgdump.exe -f hostfile.txt -u AnAdministrativeUser -T 10

The form of this command is similar to the other multi-machine dumps, and in fact, this form can be used with any multiple machine dump. The "-T 10" parameter specifies that 10 concurrent threads should be used. This means, effectively, that 10 hosts will be dumped at the same time. If the -T is not used, hosts will be dumped sequentially one at a time, which is very slow for large numbers of hosts.

Keep in mind that there is a point of diminishing returns with the threads, that is, using a number like 100 will cause too much thrash to be of any use. I personally like values of 5 to 10, though some of my cohorts crank this number up as high as 20. If performance seems really bad, try turning down the number of threads.

 

Dumping Hosts and Logging Output

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -l myoutput.log

Any output from the password dump run will be simultaneously written to myoutput.log. This does not include actual password hashes, but rather any status and error messages. This is particularly useful when you need to grep out failed hosts, or when used in conjunction with verbose output, as shown below.

 

Dumping Hosts, Logging Output and Viewing Verbose Messages

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -l myoutput.log -v -v

This is the same as before, but you'll get many more messages. You can use a single -v to get a bit less output if you desire, but since this option is really meant for debugging, it's often best to just use -v -v. Logging output is recommended, too. If you need to send me an error report, this is what I'd ideally like to see to help discover the problem.

 

Dumping a Host Without Password Histories

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -o

You can use this option if you are not interested in dumping password histories. Histories are useful if you want to spot trends in passwords, such as "spring07" changed to "summer07" 90 days later. Incidentally, you are currently unable to obtain password histories from Vista, though fgdump should inform you of this in the output.

 

Dumping a Host Without Cachedump or Pwdump Output

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -c (or -w for skipping pwdump)

If you don't want a specific type of output (cached credentials or password dumps), you can invoke the appropriate flag above to ignore them. Ignoring cached creds on Vista is somewhat necessary right now, as cachedump does not currently work against Vista.

 

Dumping Protected Storage

fgdump.exe -h 192.168.0.10 -u AnAdministrativeUser -s

Protected storage can contain interesting secrets, including passwords for IE and Outlook if a user opted to have those programs remember passwords.

 

A few other options exist, but they are pretty rarely used, and the help should probably provide sufficient information on their usage. As always, if there are questions, feel free to drop me a line at fizzgig -AT- foofus -DOT- net.