01/29/2009:

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.

01/19/2009:

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

01/05/2009:

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.

07/09/2008:

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

04/21/2008:

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. 

04/17/2008:

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.

07/25/2007:

06/21/2007:

05/30/2007:

03/26/2007:

03/20/2007:

12/11/2006:

10/12/2006:

10/04/2006:

09/22/2006:

09/21/2006:

03/23/2006:

03/22/2006:

03/17/2006:

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

*cough*

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.

Examples:

> 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' 10.1.1.1

Runs pwdump against 10.1.1.1 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 10.1.1.1

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

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

Dumps the host at 10.1.1.2 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 10.1.1.3

Runs pwdump against 10.1.1.3, where 10.1.1.3 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.

NOTE FOR 64-BIT USERS!!

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

 

WARNING TO ANTI-VIRUS USERS!! (Particularly McAfee)

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