Teh Fizzgig!
News Archive
64-bit Info
How It Works
About fgdump
System Reqs


Windows 2000/XP/2003/Vista/2008 NTLM and LanMan Password Grabber
By fizzgig and the foofus.net Team

UPDATED 01/29/2009

New pwdump6 (version 2.0.0-beta) available!
What the heck are you using pwdump for? fgdump does *everything* pwdump does, only more! I highly recommend switching over as soon as possible. :)


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 accidentally introduced a bug in the DLL at the very last second before release. That should be fixed now. Sorry if I crashed your LSASS. :(

Oh, I see I was also writing out a temporary file from the service to c:\out.txt. Feel free to remove that from your targets. There is no sensitive data in there, but it's rather annoying.


OK, first off this is a BETA version. Do be careful. A lot of changes are in this version, and it's possible it may cause system crashes. While I have hopefully worked all that kind of stuff out, I can't guarantee it.

Here's what this newest version has:
  • Only need pwdump.exe now! No need to drag along those other DLLs and EXEs. :)
  • Support for Unicode usernames. I haven't done a TON of testing on different charsets, but it seems to work fine with my Japanese username here. Note that, if you run this on the command line, you may only get ?'s for the characters - I assume this is because the console does not properly display Unicode. If you write the output to a file using -o, it should look right.
  • More evasive with antivirus. I won't elaborate, since if the AV folks want to update their sigs, they should at least have to look at the source. :) Suffice it to say, it's something I've wanted to do for awhile.
  • Bug fix in how parameters are passed to the service prior to execution
If no major issues are reported in the next few weeks, I'll mark it stable. I will also roll it into fgdump 2.2.0, which also is about ready for release. It will not be using the new password dumping technique that I've discussed on its home page, but does have some new cool anti-AV things. Please report any problems you have to "fizzgig -PUT AT HERE- foofus.net".

Since I'm on the subject of submitting problems and such, I am normally happy to try to assist with any issues. Please, however, do me a favor if you need help:
  • Send me the FULL command line you used (user and password can be omitted)
  • Send me any output and other error messages (feel free to obscure hashes if you want to)
  • Provide a full description of the local host's OS and, if applicable, the remote OS. This includes OS, service pack level and 32/64-bittedness
  • Do not ask me to crack a password for you, unless I know you well. :) I will not be a party to doing whatever it is you're doing


Happy new year one and all! It's been a busy time in the Foofus labs, with various research projects and other fun things afoot. As a part of this, I have made some major changes to pwdump (which wil l become 2.0.0). These include:
  • Single executable - no need to drag 3 files around anymore!
  • Ability to handle Unicode usernames
  • A couple of minor bugfixes
  • Fun stuff that should make it a little harder to get picked off by AV. The current version I have avoids both of the "top 2" vendors' solutions as of now
I was hoping to post a beta last week, but I found that it's still causing a few problems on certain hosts, so I need to work those out first. The good news is that it shouldn't be long - I'm hoping a week o r so. Depends on the project load at any given time I'm afraid.

On a related note, I am experimenting with some new fgdump code, to be turned into fgdump 3.x. This code will not rely at all on DLL injection or other nefarious techniques - it's much more passive. The init ial volley of code is done, but I've got a long way to go. I do NOT anticipate migrating that code to pwdump - it will probably become the "future" of the foofus.net password dumpers and will therefore resul t in pwdump becoming a bit outdated. This is not necessarily bad. We've relied on the same basic method to dump passwords for years now - it's time to take the more complex but faster and safer approach. Det ails will be forthcoming in the next few months.


A couple more minor issues were reported with regards to 64-bit support (some multi-byte problems and a handle double close - thanks once again to Soaring Moe! for providing the diffs to correct the issues).


Once again, a user saves my bacon. :)

Soaring Moe! pointed out a line of code he was having trouble with, and after looking at it, I determined that it should have only been there for testing. It's the line that sets the service name to "servpw", which I do for testing purposes, but normally the service name should be random in order to reduce the risk of AV interference. Duh. OK, so I removed that line and restored random service naming back to its original glory. That's the only change in 1.7.1.

The side effect of this is that, if the service hangs (such as if you use -x incorrectly), you will NOT be able to simply do a "sc delete servpw." Instead, you need to find the service first. Actually, this is easier than it sounds - look for one that is in the form of a GUID (it will be surrounded by curly braces, such as "{AAAAAAAA-BBBB...}", etc. Look at the service name for that service, which will be a random series of letters, and delete that particular service. Sorry for the added pain, but the AV evasion is worth the price I think.

Also, we have created a moderated mailing list which I will be posting details for shortly. This list will be used not only for pwdump, but other foofus.net tools as well (we may break these out to separate lists if there is a lot of traffic, but I kind of doubt that). The goal is to provide usage information, exchange ideas, feature requests, post new revision/product announcements, that sort of thing. Stay tuned - info will be forthcoming soon. 


After numerous delays due to a far-busier-than-normal work schedule, I have finally had some time to spend updating tools.

The biggest request out there thus far has been for 64-bit target support and, I'm proud to announce, pwdump6 1.7.0 can now deliver that! By including a "-x" on the command line, you can tell pwdump that your target is 64-bit, and thus finally get hashes from those rather than simply having pwdump hang. I would very much like to thank Soaring Moe! for his work on helping me get 64-bit going - his patch to the source really helped finally get this done!

Target detection is not automatic, however, and if you do not correctly use that -x, it will still hang on you. To that end I've provided a separate page that discusses what -x is and how it works. Future versions of pwdump may automatically detect the target OS, though currently this feature is relegated to fgdump, which is a better overall choice anyway in my opinion.

I haven't tested a ton of 64-bit OSes yet, so if you run into problems, please let me know and I'll work them out. I tend to be pretty responsive to people in the field trying to get this to work.

Note that you'll need 5 files total (pwdump.exe, servpw.exe, servpw64.exe, lsremora.dll and lsremora64.dll) for a complete installation now. If you are certain you don't need the 64-bit stuff, just ignore the files with "64" in them, though I recommend keeping everything together to be on the safe side. 

You'll also probably notice, at least for a bit, that AV will be less likely to detect this version. That won't last long, as the signatures will catch up, but enjoy it while it lasts. :)

Lastly, the Visual Studio project has been updated to work with Visual Studio 2005. I have removed the files associated with Visual Studio 6.


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!


I've updated pwdump6 to be more evasive against current AV again. :) This will undoubtedly be an ongoing battle, but as I've mentioned before this is NOT a "hacking" tool per se. The vast majority of folks are using this in a responsible manner I think. Maybe it might be better to go after the trojans, worms, etc. that actually install this program, rather than the program itself.

But I digress. Thanks again to folks who have written me with issues and details on problems they encounter. It takes me awhile to get to them sometimes, but I do try. :) For example, I know there is still an issue with some Unicode- centric versions of XP (specifically, some Chinese language packs). I started working on this a bit, but have been wwwed. Hopefully I'll get some updates to this soon.

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.


I'm reorganizing the site a bit, so for downloads, please click the link on the left nav bar or you can click here. :) I will also be enhancing the usage documentation in the near future here.


1.5.0 changes a few of the file names and some internal error messages and such. The positive effect of this is that, at least as of today, AV should be a lot less likely to pick it up. Please keep in mind that this may very well change in the future. I also took the time to update the README file a bit with some specific usage examples for folks who needed help.

This seems like a good time for me to reiterate: this tool is targeted at the pen-testing community, and those folks who are performing lawful work. Don't email me asking how you can hack your brother's box with this or break into some system. Go somewhere else for that sort of advice. If, however, you need help using the tool in the manner for which it is intended, I am more than willing to provide guidance and troubleshooting. :)

Oh, I also attached MD5 sums for the "official" archives now. If you are so inclined, feel free to verify those to make sure the contents are intact. Hopefully I didn't do something stupid when I computed them - they should be accurate. :)


No new release quite yet, though 1.5.0 is being tested internally. Without giving away the whole surprise, users who encounter antivirus should be quite pleased with the new release. :) I anticipate having this available within about a week.


Not much has changed with this version, though you do now have the -n option which skips password history dumps. Again, if you are looking for more functionality, I highly recommend checking out fgdump :).


Finally! One of the more annoying-to-reproduce bugs out there has, at last, been solved (I hope anyway)! 1.4.2 is strictly a bug fix version, though I will have another bug fix version in the not-so-distant future.

Data should no longer show up as binary garbage. There is actually a bug buried deep in the Blowfish encryption algorithm that causes the whole thing to fail if the key contains a "00" value. Since I have not had an opportunity to properly address it (but it needs immediate fixing), the workaround is that all "00" values in the key are replaced by a different value. This reduces the effective keyspace to 255 ^ 16 (previously 256 ^ 16), but I'm ok with that. :) Note that the failure rate was approximately 1 out of every 16 runs, so that's why the hacky fix for now.

For those people already cringing, keep in mind that this is NOT intended to be a secure encryption implementation. It is designed to avoid casual snooping as well as evading certain IDS signatures.


One of the problems I had noticed was that, under rare occasions, it was possible for LSAEXT.DLL to get "permanently" attached to LSASS. This is problematic on boxen like DCs, where rebooting is not an option. I think I found the cause for this, so if you were getting errors about not being able to write to LSAEXT.DLL or were getting "named pipe in use" errors, this might fix it for you. Please let me know if you see other similar problems.


I actually found some time to do an update, so I have to take advantage of that! :) That may be the fastest version update I've ever done.

This version has 3 major changes to it:

  • When using pwdump against a target of "localhost" or "", it will no longer do any networking stuff. This should alleviate problems when networking is not available, and also makes it run a lot faster on local boxen.
  • Fixed a bug in the named pipe code that was causing a race condition. If you've ever had LSAEXT.DLL hang on the remote target, this may solve that problem for you.
  • Added the -n option, which allows you to skip password history dumps. This feature was added by request.

Enjoy, let me know if you find any bugs.


Alright, so it took me a very long time to get this version out (it's been done since July actually), but as the fgdump page says, I've been crazy busy. My apologies, and I'll try not to take so long next time. :)

I have a couple more features I'll be adding to pwdump6 in the not-too-distant future, but nothing earth shattering. This version is really more bug fix version than anything, though you can now specify the -s parameter to specify a share to use, rather than searching for one. That might be helpful in some scenarios, and was needed for fgdump functionality.

Oh, and thanks for the continued use of this program - August was a record month for downloads (I think partially due to Defcon), and while I won't talk about the actual numbers, let's just say it was FAR higher than I ever thought it would be. :) 


My friends who prompted the selectable share functionality discovered some problems with it. I hate having to release code without much testing, especially when it has bugs but hey, that's what beta versions are for, right? :)

Anyway, the problem revealed another subtle bug that has been around for quite some time. If you've received error code 5 or 1326 during share enumeration, try this latest version out. I was not establishing a trusted connection prior to share enumeration, which caused failures in certain instances. The selectable share function just brought this into the light, but the problem should now (hopefully) be fixed in both selectable shares and found shares.

I apologize in advance, this version also doesn't have a whole lot of testing in it, but I want to get the folks who need this feature up and running, and I've got a plane to catch soon. :)


Another user-requested update today. Someone had asked if a specific share could be specified (pwdump4 apparently has this ability), as pwdump6 was not always picking up every share. This seemed like a good idea, so I've released pwdump 1.2.1 (which is still a beta technically). The share can be specified by passing a -s parameter (see the usage for more information).

By my own admission, I have not tested this version a ton (I've got a lot going on right now!), but I believe it should work as advertised. If you're nervous about the previous statement, please use 1.2.0 for now. :) If you're all about the bleeding-edge, use 1.2.1. Of course, let me know if you have any problems with either version.


I've decided that encryption is a pain, and that no one should use it.

All kidding aside, version 1.2 of pwdump6 (technically a beta) is now available. The major feature here is that it uses Blowfish encryption to secure data going across the named pipe. I originally was going to stick with the encryption used within pwdump3e, but I don't entirely trust the CryptoAPI as it relates to that program. Not only that, I friggin HATE the CryptoAPI. To me, it's the end result of making something so flexible (which it is) to the point of making it overly difficult to use.

So I used Blowfish, which is quite the nice (and IMHO, underutilized) algorithm. I feel the need to point out that my implementation of encryption is NOT what I would call bulletproof. It does not use a public/private key set, and relies on a rather crappy 96-bit key generation scheme that conceivably could be intercepted if one decided to put some effort into it. My feeling, however, is that someone willing to go to those lengths probably can do far worse than sniffing traffic that they can undoubtedly get themselves. See the README for more details on this. Regardless, data cannot be easily sniffed anymore, and as a result, this will evade simple IDS signatures simply looking for things like "Administrator:500" going over the wire.

NOTE: Depending on your country's encryption restrictions, there may be legal ramifications to you running this software with the encryption. It is your responsibility to make certain that you are not violating any laws. Neither I nor foofus.net can be held responsible for misuse of the software.

About pwdump6

A significantly modified version of pwdump3e, this program is able to extract NTLM and LanMan hashes from a Windows target, regardless of whether Syskey is enabled. It is also capable of displaying password histories if they are available. It outputs the data in L0phtcrack-compatible form, and can write to an output file.

For folks who have experienced the "LSASS crash" syndrome (where a target goes belly-up and reboots due to LSASS dying), this program WILL likely be of assistance.

Why does LSASS reboot the box (and what the hell *is* LSASS anyway)?

LSASS is an important, if not annoying, beast. Think of it as the gatekeeper for Windows security: if you want to perform a task, you need a token. This is (obviously) related to your username and password but for good reason, Windows doesn't shovel this information around. Instead, you are issued a token, which lets Windows know that you have permission to perform that task. LSASS is responsible for such matters. As such, it must know user names and password *hashes* (not the clear-text password which would, again, be stupid). Windows tries very hard to protect those hashes, to the point that only the System account has access to them (and moreover, pretty much only LSASS running as System). So, if we want to get our hands on those hashes, we need to enlist the help of LSASS to do so.

Fortunately for us, Windows provides a very useful (some would argue dangerous) API to use to accomplish this: CreateRemoteThread. CreateRemoteThread allows an external process to start a thread within the context of another process. This allows us to do exactly what we're after - call a couple of "mystery" LSA functions and bam, we have the hashes.

Unfortunately, when a remote thread crashes, its surrogate process crashes too, in this case, LSASS. The net effect is that Windows is no longer able to manage security, since it can no longer perform its token and credential lookup functions. Its only option at that point, is a reboot.

Nice long rambling discussion. Can we get back to the point?

Patience, grasshopper. The above is crucial to understanding the nature of the "bug". It turns out that later OS's (XP SP 2, 2003) have the ability to do something called "data execution prevention", or DEP. Ostensibly, this feature "prevents" stack-based overflow attacks (which is a total myth, but I digress). The method that programs like pwdump and cachedump use to do their dirty work involves writing to the memory of another process, at which point DEP steps in and shakes its finger at us. Well, kind of. What actually happens is that our happy remote thread dies, taking LSASS with it. Bummer.

In yet another awesome bit of luck for us, this problem is fixed by...get ready...setting a flag. Yes, it seems that, as long as you mark the memory as "executable", DEP allows it to occur and everyone is happy. It's a good thing no attackers would EVER set that flag...


Anyway, pwdump6's main difference in this regard is that it sidesteps DEP by marking the memory correctly. Hence, your days of crashing LSASS (at least for now) should be gone.

pwdump [-h][-o][-u][-p][-s][-n][-x] machineName
where -h prints the usage message and exits
where -o specifies a file to which to write the output
where -u specifies the user name used to connect to the target
where -p specifies the password used to connect to the target
where -s specifies the share to be used on the target, rather than searching for one
where -n skips password histories
where -x targets a 64-bit host

Install the executable files (pwdump.exe, lsaext.dll, and pwservice.exe) in a single directory. Running pwdump with no parameters causes the usage information to be displayed. The target machine name is the only required parameter.

-o specifies a file to which hash data should be written. Messages will still be written to the console.

-u/-p specifies the user name and password used to establish a connection with the target. This is necessary if you haven't already established the connection via, say, an IPC$ bind. The credentials used MUST have administrator-level privileges. If no password is specified with -p, the program will prompt for the password at the console.

-s specifies a share name to use, rather than searching for an available one.

-n instructs pwdump to not dump the password histories (if available)

-x indicates the target of the dump is a 64-bit OS (Win 2K3 64-bit or Windows XP 64-bit). Note that it *does not matter* what type of host you're running pwdump.exe on, only the *target*. Also, IF YOU ARE TESTING LOCALLY AND ARE 64-BIT, YOU MUST USE -x!

Keep in mind that you must be admin, system or some other highly privileged account to run pwdump6.


> pwdump localhost

Runs pwdump on the local machine using the credentials of the currently logged in user

> pwdump -o mytarget.log -u MYDOMAIN\someuser -p 'lamepassword'

Runs pwdump against using the 'someuser' account in the MYDOMAIN domain with a password of 'lamepassword'. Output will be logged to mytarget.log.

> pwdump -o mytarget.log -u MYDOMAIN\someuser

Same as above, only pwdump prompts you for the password before running

> pwdump -n -s 'MyOpenShare' -u someuser

Dumps the host at using the 'someuser' account (you will be prompted for a password). Uses the share 'MyOpenShare' to upload files and skips dumping password histories.

> pwdump -x localhost

Runs pwdump locally against a 64-bit host.

> pwdump -u myuser -p mypassword -x

Runs pwdump against, where is running a 64-bit OS.

Running pwdump against target machines with many user accounts takes time. We have measured approximately ten minutes for 20,000 user accounts. Please be patient and let the program terminate itself.


Please, please, read and understand this. If you send me email because you are doing it wrong, it will just piss me off and I'll end up making fun of you for not R'ing TFM.

You MUST use -x if your target is a 64-bit OS. It DOES NOT MATTER what type of OS you are running FROM, only what your TARGET is! pwdump.exe itself is a 32-bit executable, and runs the same from any OS. The service and DLL are different depending on 32/64-bit. Let's see some examples:

Running from Windows XP, targeting Windows XP: NO -x needed Running from Windows XP, targeting Windows XP 64: -x IS needed Running from Windows XP 64, targeting Windows XP: NO -x is needed Running from Windows XP 64, targeting Windows XP 64: -x IS needed

Obviously, this holds true of other 32/64-bit OS's as well.

** What if I don't use -x correctly? **

In most cases, pwdump will simply hang. Fortunately, this is relatively easy to fix. Just Control-C out of pwdump, and go to the target and delete the pwdump service (you should be able to identify it by having a goofy-looking GUID for a name, such as "{AAAAAAAA-BBBB...}", etc). The service name will be random, and should stick out to anyone actually looking for it. If you want to do this remotely (this only works from XP/2003/Vista):

  1. net use \\your-host\ipc$ /u:your-admin-user (hit return and enter pwd)
  2. sc \\your-host query (locate the service name that will be a series of random letters)
  3. sc \\your-host delete (service name identified in step 2) 
  4. net use \\your-host\ipc$ /del

** This sucks, why do I have to figure out the target manually? **

Because I've been busy. :) Users have been clammoring for this function, and having a manual switch is the easiest solution for now. I will not rule out automatic detection in the future, but really this sort of advanced feature is typically left for fgdump (http://www.foofus.net/fizzgig/fgdump).



Certain AV programs, notably McAfee, react poorly to pwdump. McAfee in particular has a nasty habit of consuming 100% of the CPU when pwdump is run sometimes. Therefore, it is HIGHLY recommended you stop any AV on the target before pwdump'ing it. If not, you might need to reboot it, which will be bad if you are working remotely. You have been warned.

If remembering to do this escapes you (I forget frequently), I would suggest looking at fgdump. It is, among other things, a wrapper around pwdump and will take care of stopping and starting AV control as needed.

(This is partly from the original pwdump3e README)

Remote access to a machine is accomplished be by running the hash extraction program as a service, because Windows NT-ish OSes allow services to be installed and started remotely. pwdump6 first connects to an available, writable share and copies the service executable files there. It then requests the Service Control Manager to install and then run the service program. The extracted hash data is then sent to the client via a named pipe. Cleanup consists of uninstalling the service, and deleting the executable files from the remote machine.

Once the service is running, it follows the methodology used by Todd Sabin in his pwdump2 program to access the password hashes. The idea is to use Windows internal function calls to fetch the data. Since these functions require privileged access, it is first necessary to gain the appropriate access priveleges. The Local Security Authority Subsystem (LSASS) runs with the necessary access privilege, so pwdump6 uses a technique known as DLL injection to run under the LSASS process, and thereby attain privileged access to the hash information.

DLL injection involves running a thread under an external process. The thread runs with all the access privileges of that process. The thread's executable code must first be copied to the address space of the external process. The pwservice program, running on the remote machine with administrative rights, adjusts its access privilege to Debug level. This allows it to open and write to the memory space of the LSASS process. It copies a simple thread function into the LSASS address space, and then runs the thread under the external process. The thread loads the lsaext.dll DLL and runs a function that performs the privileged hash extraction routine. This routine uses undocumented, internal Windows function calls to enumerate the users on the system and obtain the password hashes in unencrypted form for each user.

The hash information must be made available to the machine from which pwdump6 is running. This is accomplished by shipping data over a named pipe back to the client (the LSASS process acts as the named pipe server).

As of version 1.2, data is encrypted as it is sent over the pipe. This is *not* what most purists would consider strong encryption. The encryption itself is sound - it uses the Blowfish algorithm, but the key generation and transmission is not completely secure.

Before you panic, let me explain the design goals here. The goals are really two-fold:

  • Prevent simple unauthorized sniffing of traffic
  • Evade simple IDS/IPS signatures

As such, the encryption is really more of an obfuscation layer. The key is generated using successive calls to rand(), while reseeding after each byte using the contents of a performance counter. The total key length resulting from this operation is 96 bits. The key is sent as a remote command-line parameter to the pwservice.exe service when it starts, which in turn relays the key to lsaext.dll as it is injected into LSASS.exe. Given this, if a person were able to intercept this key, the resulting data streams could be decoded and decrypted.

The goal is not to provide world-class security, only to reduce the risk of casual eavesdropping. Lets face it - if someone really goes to all the trouble of locating the key and decrypting the stream by hand, they can probably run the tool themselves. :)

Of important note here as well is that I am not using Microsoft's CryptoAPI, which I loathe almost as much as clowns. The Blowfish implementation is readily available on a number of websites, and has been used successfully in other commercial tools.

Source code and Visual Studio 2005 project and workspace files are included. 

Windows 2000, XP or 2003
Administrative Credentials on Target Systems

Windows 2000, XP, 2003, Vista
Vista requires the Administrator account, Remote Registry and file sharing enabled