Links and Stuff

Once again, I present for your reading pleasure an odd mish-mash of links to information that defy categorization...

I no longer do PCI forensic audits, but I thought this one was interesting...the BreachSource site includes an interesting tool called BreachProbe, which takes a packet capture and can parse out credit card data. I can't say that I had access to very many packet captures during a breach investigation...most often we'd get a call after the "victim" organization had been notified by an external third party that they were a CPP, usually as a result of a fraud investigation. From there, there was even more time that went by before folks like me were called on-site. However, this does look like a useful tool for those who still do this kind of work.

I've been doing some research on various values and data within the Windows Registry, and part of that included settings for WZCSVC, largely for Windows XP. During my research, I ran across this Symantec web page, which includes a tool called wlan.exe. This looks like it's a great tool for collecting information and troubleshooting issues in a wireless environment. Based, in part, on this information and more about the WZC_WLAN_CONFIG structure, I updated the ssid.pl RegRipper plugin to parse the MAC address of the WAP out of the data. There's some additional work that needs to be done regarding control flags, but so far this has been some pretty interesting information. I originally started looking down this road based on something said in a post to the EnCase user forum, and started digging for some credible, solid information on which to base some Registry research. While the structure I found is specific to WinCE, it seems to apply very well to XP, as well. In my own testing, I pulled the MAC addresses for two SSIDs out of a hive file; the MAC address for the "tmobile" SSID pointed to (via OUI lookup) Cisco as the manufacturer, and the one for the "ender" SSID (my own WAP) pointed to Cisco-Linksys.

A recent post on one of the lists asked about locating indications of the use of the at.exe in the Task Scheduler log file. The at.exe command is used to schedule tasks, and on XP and above, you can also use schtasks.exe to create scheduled tasks. However, the schedlgu.txt file does not record the creation of scheduled tasks via either of these tools, but instead records Task Scheduler Service start/stop messages and scheduled task/job execution information. So this is something to keep in mind when conducting analysis and you find a Prefetch file for at.exe.

In a recent discussion regarding Windows trusted shells, someone sent in a link to a tool called "console", which appears to be a replacement to cmd.exe. It looks pretty interesting, and may be a great edition to your toolkit if you find the functionality useful.

A new post on the Hacking Exposed Computer Forensics blog continues the "what did they take when they left" series of posts, and also mentions RegRipper and RipXP. The post brings a lot of the thought processes that an analyst must use into play when trying to answer the question. Its easy to say, "there's more to it than that", and I'm sure that the author(s) would agree, but that's why there's a series of posts...putting it all in one post would simply make that post too long and too hard to digest. Also, I'd suggest that since part of the title of the series includes "when", suggesting a relation of events to time, that timeline creation and analysis might help to answer these questions. RegRipper doesn't have a plugin that parses all of the information mentioned in the blog post...yet.

On a side note, it looks as if HECF has a second edition on its way out. Nice! I still have the first edition posted prominently on my bookshelf, and it's nice to see a number of computer forensic books out there. As much of a niche as the topic of computer forensics is, its nice to see a choice of books that covers different aspects of the field.

The Virus Bulletin recently released their RAP index, illustrating the results of testing to determine an AV product's reactive and proactive detection capabilities. Kind of scary when you think about it, but then most folks are aware of this and know not to rely on AV as a be-all-end-all, silver bullet solution. I mean, what do you expect, with malware write-ups like this? I mean, seriously...

Finally, RipXP has been picked up in Spanish on the NeoSystemsForensics blog! Nice!