fgdump News Archive

Sorry that the site was down last night - we had a hardware failure on our poor little web server. All should be well again, however.

I added a link to some usage examples - that's probably about as close as I will get to formal documentation at this point. :) I also put links to the standalone fgdump executables on the downloads page. Not only does this remove a bunch of cruft for folks who want to just use the thing, but it also makes it less likely to be noticed by AV when downloading.

Last but not least, happy birthday to my Keith Richards-impersonating brother-from-another-mother! A fine, fine excuse to spend a nice afternoon outside celebrating your 45th birthday. ;)

A few updates today. First, I'm in the process of reorganizing the site a bit as I continue to add more content to it - you'll note the Downloads link on the left side nav bar. Deep links to the files themselves should still work, though I can't guarantee that those won't move at some point. :)

Second, several folks have asked for additional documentation on using fgdump. I am working on that right now, and should have some stuff posted in the next few days. One gentleman asked for some pictures on using it, which I can't say I understand the need for given that it's a command line utility, but I will at least get some clear examples and explanations on how to use it.

Lastly, about Vista. I have to give Vista some credit - its new and improved LSASS sports some improved security definitely. On one hand, I can confirm that I can still dump passwords on the host (though it requires the Administrator account, Remote Registry enabled and file sharing turned on, all of which are disabled by default). So I suppose that's bad from their perspective, but on the plus side, the way they are dealing with cached credentials is tighter. So much so, in fact, that cachedump (which is used by fgdump) will not work on Vista. I spent some time recently doing some digging as to why, and found that the process itself is significantly different than in previous versions, and as such, the method currently used by cachedump to do its dirty work will not work.

Making it work goes quite beyond what I've done thus far, and will require time. My hope is that someone smarter than me will discover how LSA secrets are managed in Vista, which will open the door to restoring this functionality. :) Maybe I'll be lucky enough to figure it out on my own, but until one or the other happens, I'm afraid you won't be seeing cache dumps from Vista too soon. Sorry.

I'm researching this a lot right now, but I can't read everything on the Intertubes I suppose. As such, if you come across specific articles on reading LSA secrets in Vista, I'd love to hear about them. I'd rather hear about it 100 times than miss an important article or something.

Incorporates the new pwdump6 version (also 1.5.0) which is more evasive of antivirus. It should make a lot of peoples' lives much easier. Additionally, I've received some feedback both about Vista and 64-bit architectures. First of all, some of you have actually seen real Vista deployments outside of M$? :) Seriously, the reason I haven't put much effort into these realms is that we just haven't seen it yet, and my plate is full with many other projects. At some point, I'll have to bite the bullet I suppose, but for right now, I haven't put much time into verifying either of those two situations.

If, however, any of you folks have patches or anything that you've been using, I'd be more than happy to put them in and give you the appropriate credit.

The changes in this version were primarily driven by requests from the user community. Thanks for the feedback folks!

1.3.4 fixes a bunch of issues that have been out there for awhile, but tend to only manifest themselves when you're doing a bunch of hosts. The most important fix is that it incorporates version 1.4.2 of pwdump6, which fixes a problem where data would every once in awhile be returned corrupted. The total fix list is:

Version 1.3.3 of fgdump gets rid of the BETA tag (it seems to be pretty stable), and also incorporates the latest version of pwdump6 into it (version 1.4.1). It should be far more stable and less likely to leave a "stuck" LSAEXT.DLL file on a target.

My apologies - the ZIP archive for 1.3.2 was incomplete. Stupid -r flag. It should be correct now.

Defcon 14 was very fun, and foofus's presentation was well-received. Thanks to everyone there, especially the folks that make it happen (DT, the Goons, Priest, Winn, the whole lot of you). We may have gotten our asses kicked at Hacker Jeopardy, but in all fairness, we wouldn't have participated if we knew the beer rules had changed. We had expected to win by mass consumption of alcohol. Ah well, Bunnies For Priest shall live on, and we've got ears and shirts to show for it.

I also have to apologize for the liver damage I may have inflicted on others at DC14. Between Warp Cores and old fashioneds, I think I was at least in part responsible for dishing out a fair number of hangovers. I assure you, however, that both drinks will be making another appearance next year at the Party Pad.

I've been exceedingly busy and haven't been making many changes, since things seem to largely be working well. I will be releasing a non-beta version "soon" with any luck, but there should not be anything other than bug fixes in it.

I will be announcing shortly my new endeavor, which is essentially the next generation of fgdump, but with a LOT more power and features. I will announce this as I get a bit further along in the design process, but with being so busy, I haven't had much time to work on this soon.

Also, I've noted that pwdump6 downloads greatly outnumber fgdump ones (though both numbers are VERY respectable). This perplexes me, since fgdump does everything pwdump does and more. If you're using pwdump, might I humbly suggest stopping? :) Seriously, I think fgdump will work much better for you, and it really will do the exact same thing. Heck, fgdump *uses* pwdump6 under the hood! Tell your friends to stop using old stuff. :)

Greetings fellow Defcon enthusiasts. As hoped, I hereby announce...

Version 1.3.2 (BETA) is now available for download!

The biggest new features are multithreading and support for Windows Vista Beta (though this is highly experimental). You can now run a number of simultaneous threads and get the results back as they come in. There are a number of changes that were made to get all this to happen, and as such there may be bugs in the current version. As usual, please report any problems and I'll do my damndest to fix them quickly. Here's a complete list of what's in the new version:

A word to the wise - if your host machine (where you are launching fgdump from) has a copy of pwdump and lsaext.dll on it already, DELETE THESE. There is an incompatibility between the version in the new fgdump and these old versions. If, for some reason, it decides to use the old DLL, it may cause target systems to crash. Note that this implies pwdump6 has changed, which it has. I haven't had time to get the standalone version up to the site yet. Soon, I promise.

As I mentioned, this version also supports Windows Vista betas, though I cannot guarantee all versions will work. Also note that it's a LOT harder to have a working target out of the box as previous versions. The exterior is, at least for now, quite a bit harder to penetrate, though the inside is still the same crappy storage mechanism it seems. One thing I did notice is that I cannot, at least at present, obtain password histories. The API that supported it has gone missing. Interesting...

If you see me roaming around Defcon, I'm the (a?) guy with blue and black hair with the name 'fizzgig' on his badge. Unique, I know. Feel free to inquire about and request new features, bitch at me for crappy coding, buy me beer, whatever you wish (though I admit, I am partial to the latter option).

Version 1.3.0 is in the internal beta testing phases right now, and I'm pleased to report that the multithreaded stuff seems to be working well. There were some major changes, particularly to the logging mechanism, as well as isolating per-server activities in their own class and of course creating the whole thread pool thing. I anticipate testing will be done in a week or so, and the beta version will be available around that timeframe. Between then and Defcon 14, I hope to work out any major bugs and get a stable release out there.

Our good friend will be presenting at Defcon this year as well! /cheer! His presentation will focus on using readily available tools to draw some interesting conclusions about those networks which we are assessing, and fgdump is featured as an important part of the data gathering process. I highly recommend seeing his presentation if you are attending the Defcon this year. Here is a link to his presentation outline. Oh, and feel free to buy both Foofus and I beer. We like people who do that. :)

I've been quiet for a bit here, primarily because I haven't had a whole heck of a lot to do! :) Folks who are using fgdump seem to be having few problems with it, which is awesome. I've started work on getting multithreadedness worked in, with a goal of having this done in time for a DefCon 14 release, but as soon as I say something like that, I start getting slammed with other work and have no free time to do so. :) Hopefully that doesn't happen this time.

Anyway, keep your eyes open for another release in the next several weeks.

I'm working on an isolated incident that seems to be affecting certain Windows 2003 SP1 servers. Thus far, I've only personally seen the issue when those servers are running within VMWare GSX. The problem is that either the pwdump or cachedump phases hang, and even if they don't, neither one returns any data. The target does not crash, and I haven't found any useful data that indicates what the problem might be. If anyone has seen this or happens to be a VMWare expert and can shed some light on the situation, I'd be grateful, and can begin looking for a resolution.

I thought I would give everyone a quick heads-up on current fgdump development, and what you can hope to see in the near future. Since I'm updating the pwdump home page, this seemed like a good time to work on my l33t HTML sk1llz0rz.

The major feature in the works right now with fgdump is true multithreadedness. This is not really a small undertaking: pwdump, cachedump and fgexec all use a specific named pipe to exchange data. Running multiple instances of the same named pipe doesn't work too well. So step one is to fix up that problem, which is pretty much complete. Internal test versions of pwdump and cachedump (the new fgdump will use 1.2) work with GUID-based unique pipe names, thus alleviating the problem. fgexec is a bit of a bigger pain, but I have a strategy for this. The next step will be creating a thread pool to spawn and manage concurrent instances of the utilities. The time to actually do this, however, is in relatively short supply.

One other thing that will be added will be support for stopping TrendMicro ServerProtect (I think that's what it's called), much like McAfee and Symantec. We did notice a couple of boxes that were running this that went TU the other day, a problem we attribute to this software. The data has been gathered, it's just a matter of adding the feature, then testing it.

Last but not least, I have been in negotiations with foofus to incorporate fgdump into his awesome OWNR product (and by negotiations, I mean that I went to his cube and we said "that would be cool"). OWNR and fgdump have a lot in common, and our ultimate goal is to provide a single tool which can do all the neat account and password reconnaisance needed on a Windows network. This, coupled with his trust graph code, can paint a very nice picture of the hosts, where they live, and how they are related to each other. I have taken it upon myself to start maintaining OWNR, and thus I am also working on steps needed to bring this whole huge project to a successful conclusion.

Just because I love you all so much, I'm providing a new version of fgdump, version 1.2.0.

What's in it, you may ask?

Well, for starters, all of the goodness from 1.1.0-BETA. 1.1.0 turned out to be remarkably stable, but rather than simply removing the BETA tag and releasing it again, I added a few features and bumped the minor rev. Forget about 1.1.0. 1.1.0 is SOOOOOOO yesterday. 1.2.0 is where it's at!

The '-s' option should actually, like, work now. Grats me fat-fingering a '2' as 's'
Reports the OS version for a particular host, assuming it can connect to the remote registry. This should be helpful for obvious reasons.
You can now use the '-H filename' parameter and give it a file containing lines of 'host:username:password'. Handy for doing per-host authentication, in addition to being more useful when you're going after protected storage credentials.
A couple other insignificant tweaks

Note also that, while I thought this would all work on NT 4, it in fact does not. I have pondered whether to fix this or not, and right now it seems to be a pretty arduous task for a relatively few number of hosts. If you are absolutely dying for NT 4 support, drop me an email and I'll see what I can do. It will, however, find NT 4 hosts and report back their version, prior to complaining about the remote registry not running. Sorry about the inconvenience, but suggest to your customer, etc. that they upgrade to an OS created in this millenium. :)

The beta version of fgdump has one major new feature, and a couple of minor fixes/enhancements. Check the README file for full details. I will get a web page set up for pstgdump ASAP as well as getting a separate link up here, but thus far I have not had time. Hopefully I will have this done early next week.

Removal of lsadump2 stuff. I was having too many problems with it, and there was little useful information being gathered, so I opted to remove it in favor of other functionality.
Incorporation of pstgdump into the mix (supressible with -s). This option dumps the protected storage contents for a particular user on the target host. There can be some really interesting information in there, including IE-saved passwords and fields, Outlook Express account information and other useful tidbits.
Added more details when the remote registry connection fails. One of fgdump's users (thanks John!) found that you may need "Log On as Batch Job" permission in some cases. Fortunately, we haven't had too many dumps fail in this manner, at least not yet.
A few other minor tweaks and fixes.

I made a minor enhancement to the error reporting when fgdump cannot log on to the system. Now, instead of reporting things like error 1326, it should actually tell you something like "Unknown user name or bad password". FYI if any Microsoft people are reading this...could one of you PLEASE make the error number to message API less painful to use? It sucks that I have to write a function to wrap what should be a trivial call. Then again, I suppose you'll get on that about as quickly as the WMF exploit patch... :)

After some more testing and soul-searching, I've decided to slap a 1.0.0 tag on fgdump (and pwdump6) and call them official releases - just in time for Christmas!

The standard caveats of "use caution" still apply of course, and there may still be (read: are likely to be) some bugs in there. Drop me a line at fizzgig -AT- foofus -DOT- net if you need help, have comments, found a bug, etc. Feature requests are always welcome too.

Note that the lsadump2 functionality is not turned on yet, but it's easier to leave it in and disabled than yank it out. Just don't expect anything from it yet! (That's my next major fgdump project)

The source archive was missing a few files that caused compilation problems (the Subversion repository was out of date, sorry). It has to do with LSADump functionality, which I have started on but not yet finished. The archive should now appropriately contain the files needed to build this.

Also, I removed the BETA tag from the archive, because it's silly. It is still in beta, however, as the executable's banner indicates.

Unbeknownst to me, I still had pwdump6 beta 2 linked into fgdump 0.7.1. This causes a couple of problems, the most notable of which is that the password history stuff is broken in beta 2. 0.7.2 correctly links against beta 3 of pwdump6, which allows password histories to work.

Oh, and grats me page redesign.

I've received word from several folks who have used the new version, and the results have been good! Apparently, machines that crashed with old versions of pwdump DO NOT CRASH with pwdump6! Of course, that's no guarantee that the problem is 100% fixed, but I'm very encouraged by that news. Long story short: if you had problems with old versions of pwdump, I highly recommend trying fgdump (which has pwdump6) or pwdump6 on its own. Very big thanks to folks who have sent me notes about how this is working for them, I really appreciate it!

I am considering releasing the software to pentest or security-focus at this point and let the chips fall where they may. It certainly would attract a lot larger audience to the software and get me additional feedback, and of course there's always the ego factor involved too. :) In the mean time, my good friend Peyton Engel will be presenting his implied trust presentation at LISA this week, in which fgdump has a small mention. :)

We did some testing with fgdump 0.7.0, which contains pwdump6. As expected, there were a number of bugs, many of which I hopefully have resolved now. It does not appear we've gotten to the root of the LSASS crash problem, however. Machines that were vulnerable with the old pwdump still appear to be vulnerable with pwdump6. /sigh I made one recent change which *might* help, but I have not yet tested it against a known bad machine.

Thus, I am releasing fgdump 0.7.1 for folks, but be aware it is likely to still be unstable. It should not crash any more hosts than the previous version, but I make no guarantees. :) Please send me any feedback on your use of this.

** If you have a VMWare machine that crashes LSASS and don't mind me getting a copy of it, that will go a LONG way toward an eventual (hopefully) permanent fix. Our efforts right now have been hampered by the fact that we have not been able to reproduce the crash in-house, only at customer sites. **

I finally got around to rewriting pwdump, which I have named pwdump6. This version gets rid of the dependency on the CryptoAPI and uses a named pipe instead of the registry to do its IPC. So far, it seems to be working fine, but I'm going to turn it loose on some of our internal assessments to test its stability before releasing it to the world. I also want to see if it corrects the problem where some XP-SP2 boxen were crashing LSASS (someone emailed me and noted that he had some problems on a 2003 server as well). This testing should occur next week, and if all is well, I will upload it the following week for folks to use.
As usual, comments and feedback are welcome at fizzgig-AT-foofus-DOT-net (remove dashes and substitute symbols appropriately).

After some testing at a site where we could reliably chain-crash lsass.exe, I think we're getting closer to the answer. I do not have a fix yet, but I hope to work on this some in the next couple of weeks. Based on some of our findings, it seems the problem may lie in a CryptoAPI call that's failing because we're running as SYSTEM (this is within the LsaExt.dll DLL that gets mapped into LSASS. The CryptoAPI is used, it seems, to encrypt data stored in a registry key that pwdump.exe then extracts the resulting data from. Probably a good idea, but this method of interprocess communication seems a little shaky to me, not to mention that the CAPI calls may be having a problem. I'm looking at rewriting major portions of pwdump to address some of these issues, and eliminate the CryptoAPI altogether. Should this be successful and useful to the public, I will ultimately release it as pwdump5 (since 4 is already taken). Stay tuned.