Help keep this project alive!
|
|
Download the latest version of pwdump by Clicking Here
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.
|