Links and Stuff

Registry Goodness
I recently wrote a RegRipper plugin, based on this KB article; on 26 May, I committed it to the plugin repository.  I had tweeted to ask the DFIR community if this information was relevant to their investigations, and there was not a great deal of response on the topic...although there was apparently some confusion.  I hope that folks take the time to try it, and I hope it's of some use to the DFIR community.  I don't often (scratch that...in 15+ years of doing DFIR work, I've never...) need to determine the history of GPOs assigned to a system.

Speaking of RegRipper plugins, Dan posted recently about how he completed the SANS CEIC 2015 Challenge.  While he completed the challenge using Eric Zimmerman's Registry Explorer tool, he did state toward the end of the post that he could've used RegRipper to complete the challenge, as well.

From the recent CEIC Conference, you can see David Dym's slides for his Improving Windows External Device Investigations presentation.  I know that no matter how many times this subject is addressed and discussed, there will always be confusion as to what resources are available on Windows systems if you are conducting one of these investigations.  I think it's great that we've got others talking about this topic, particularly because there seems to be so much confusion in this area.  Cory Altheide and I published the initial research into this topic in 2005 (there's a link here), and as new versions of Windows have come out, more information has become available regarding not only which devices were connected to systems, but also which user may have accessed the device.

Speaking of the Registry, Eric Zimmerman recently released a command line tool for interacting with (including searching) a Registry hive file for specific items.  Be sure to get version 0.6 of the tool.  Eric's been doing a lot of work in creating freeware tools for accessing the Registry, so be sure to check out his other offerings.

AutoStart
Not related to Registry analysis, but TrendMicro recently had a blog post about what they seem to be presenting as a variation in autostarting malware.  More than anything else, the post left me more than a little confused...it says that the intruders found an application that was set to run when the system started, and then modified the application's import table by adding a reference to a malicious DLL.  It was the next sentence that left me confused:

It is almost impossible to find differences between the original version and the modified ones, as even their file sizes are almost identical.

The post then goes on to say that 4 of the 5 infected applications were discovered as the modified versions weren't signed.  However, there still seems to be more going on here, because adding a DLL to the import table of a .exe file, and then referencing the malicious function should make something of an impact on the size of the application, as well as other aspects of the system itself (MFT, USN change journal, etc.).

Processes
Speaking of stuff starting, Corey posted recently regarding some testing he'd done with an MSWord document that would launch an executable.

Something I really like about Corey's post is that there's enough detail in the way he presented the material to not only replicate what he did (if you can or want to get a copy of the file he used...).  Also, there's enough information in the post to create things like searches for the pattern after running LogParser against the Sysmon Event Log file, as well as to write Carbon Black watchlist queries.