Some WAY Cool Stuff
First...you've GOT to see this. Tell me that the main character doesn't look surprisingly like Marcus Ranum.
Second, a huge shout out to JT for her work on regslack.pl, which is available in the Downloads section of RegRipper.net. I was running a search across an image recently for some important data, and surprisingly, I got several hits in Registry hive files; specifically, the Software hive, a couple of NTUSER.DAT files, and even in some UsrClass.dat files. This was odd, so I opened up a couple of the hive files in UltraEdit to view the guts of the hive files and didn't see any key value structure information anywhere near the entries. To be sure, I ran JT's regslack.pl against the hive files...I had done so previously to check for some of the hive files for deleted keys...and was able to verify that the sensitive data was, in fact, part of the unallocated space within the hive file and NOT part of any Registry structures. If you've ever found hits for your keywords within Registry hive files, you'll know that having this kind of definitive information can make a HUGE difference!
Rich over at HBGary showed me a neat trick for tracking down data in memory dumps. In this same engagement, I had collected a memory dump from a Windows 2003 system using Fast Dump Pro, and had used some of the same tools I use to search images for sensitive data on the memory dump...and found stuff. Well, the next step was to nail this down to a specific process. Unfortunately, within Responder Field Edition, you can export the executable image for the process but not the memory pages it uses. That's where Rich came to the rescue...he told me to right-click on the imported memory snapshot, choose View Binary from the context menu, and after the binary contents of the memory dump appeared in the right-hand view pane, click on the binoculars at in the menu bar above the memory dump and enter my search terms. I did this, and based on the output, was able to determine that the data I was searching for was not associated with a specific process. Interestingly, the strings associated with the process itself had not contained the information I was looking for (based on my search terms) and that served to corroborate my findings. Thanks to Rich with for his helping hand in showing me how to ring just a little bit more out of Responder!
Second, a huge shout out to JT for her work on regslack.pl, which is available in the Downloads section of RegRipper.net. I was running a search across an image recently for some important data, and surprisingly, I got several hits in Registry hive files; specifically, the Software hive, a couple of NTUSER.DAT files, and even in some UsrClass.dat files. This was odd, so I opened up a couple of the hive files in UltraEdit to view the guts of the hive files and didn't see any key value structure information anywhere near the entries. To be sure, I ran JT's regslack.pl against the hive files...I had done so previously to check for some of the hive files for deleted keys...and was able to verify that the sensitive data was, in fact, part of the unallocated space within the hive file and NOT part of any Registry structures. If you've ever found hits for your keywords within Registry hive files, you'll know that having this kind of definitive information can make a HUGE difference!
Rich over at HBGary showed me a neat trick for tracking down data in memory dumps. In this same engagement, I had collected a memory dump from a Windows 2003 system using Fast Dump Pro, and had used some of the same tools I use to search images for sensitive data on the memory dump...and found stuff. Well, the next step was to nail this down to a specific process. Unfortunately, within Responder Field Edition, you can export the executable image for the process but not the memory pages it uses. That's where Rich came to the rescue...he told me to right-click on the imported memory snapshot, choose View Binary from the context menu, and after the binary contents of the memory dump appeared in the right-hand view pane, click on the binoculars at in the menu bar above the memory dump and enter my search terms. I did this, and based on the output, was able to determine that the data I was searching for was not associated with a specific process. Interestingly, the strings associated with the process itself had not contained the information I was looking for (based on my search terms) and that served to corroborate my findings. Thanks to Rich with for his helping hand in showing me how to ring just a little bit more out of Responder!