Links
First off, thanks to David Cowen for taking the time to address a question regarding the use of the SvcHost key in the Software hive as a persistence mechanism.
It all started with a response to one of David's Sunday Funday challenges, where the SvcHost key was held out as a persistence mechanism in and of itself. This got me to thinking because it wasn't something I was familiar with, based on my own research...so I wanted to know more and posted a question. David took it on as an exercise for himself, and posted his findings. Thanks to Dave to doing the work and sharing his findings with the community.
The purpose of this isn't to prove someone wrong...not at all. Rather, it is to challenge popularly-held beliefs about DFIR artifacts and ask, is this correct? Very often, something we've read or heard persists (no pun intended) long enough that it becomes accepted as fact. One example that I see time and time again is malware that creates persistence in the HKCU\..\Run key, and the report stating that the malware does this to start again when the system boots. This simply isn't the case, but it's stated on the Microsoft MMPC site, as well as by other malware analysts, often enough that it's simply accepted as "fact".
Interesting Reading
I saw that Corey Harrell linked to a couple of interesting articles on Twitter, one being a report indicating that security professionals in enterprise environments lack malware detection skills. If you follow the links to the report, you'll see that its based on a survey; even so, I think that as a responder, it correlates pretty closely to my experience, as well as that of others who've responded to incidents such as these, either as a consultant or as an FTE. The report lists three "root causes for the "darkness"", but I would suggest that they missed the most important one...management. Folks in the IT industry focus on where their management tells them to focus, and well as what management supports. If management focus is to keep email up and running, that's where IT will focus. If management sends IT staff off to training, but there's no requirement to use any of that training when they return, the new skills atrophy.
I have a couple of posts that may be of use to folks, most of which are linked via this one. Also, WFA 3/e (and the upcoming 4/e) has an entire chapter that covers this material, as well. Also, be sure to read Corey's blog post on malware root cause analysis, which provides a great deal of valuable information, as well as his Triaging Malware Incidents post.
The other article points to a new post-exploitation wiki that is available from the folks at the NoVA InfoSec group. This effort appears to be getting up and running, but it is a pretty cool idea to take a great deal of the knowledge and experience in responder's heads and post it in a way that it can be shared with others. This is definitely a site to keep an eye on.
Malware Persistence
While we're on the topic of malware, I ran across this very interesting write-up on the Terminator RAT. What I found most fascinating about the malware is the persistence mechanism; specifically, the malware 'sits' in a user's Startup folder, but can modify the Registry to redirect where that Startup folder is within the file system. That is, it can "tell" the OS to use another folder besides the user's Start Menu\Programs\StartUp folder. After reading this write-up, it took me only about 6 minutes to write a RegRipper plugin to extract this information, so now I can automatically search for this item. It didn't take too much more to add a check to the plugin, so that if the path is anything other than what is expected, the plugin will flag it for me. Interestingly, this is one of the suggested locations to look based on Symantec's list of common Registry key locations used by malware.
That's not the only interesting persistence mechanism I've seen recently; I ran across a description of Win32/KanKan not too long ago and wrote up a RegRipper plugin to help detect anomalies in under 20 minutes.
Tools
Lance recently posted on tools he uses during exams; it's a great list, and probably indicative of what many DFIR folks use. I hadn't really thought about it before.
I don't have the tier 1 tools that Lance has, so my list is a bit different. More often than not, I've found that the tiers of tools that I use depends heavily on the goals of the examination...I base my analysis process on what I'm asked to show, demonstrate or discover. For example, I've had analysis engagements where the goal was to answer questions based on the Windows XP/2003 Event Logs, which had been cleared. As such, my tier 1 tools become mmls.exe and blkls.exe from the TSK tools, strings from MS, and Perl. In one case, I was able to retrieve over 330 event records, to include the "smoking gun", but in another case, I found over 73K valid event records, none of which was the one I was looking for (parsing the Security hive with the RegRipper auditpol.pl plugin showed me why this was the case).
In a more general sense, I usually start off using FTK Imager for image verification. Like Lance, I use LogParser, great tool from MS for extracting records from Windows Event Logs, and it's useful for a number of other things, as well.
Also like Lance, I write a lot of my own tools and utilities in Perl, or add to ones that I already have (RegRipper, etc.). Some of the code that I use isn't so much full tools but subroutines and functions that I can cut-and-paste into other tools, such as a function that I have for dumping binary data in hex editor-format.
Windows 8 Forensics
I've been working on updating WFA to the fourth edition, and as such, I've been attempting to address for DFIR analysts the recurring question of "...what's new that we need to know in Windows ___?" (insert whichever version, starting with XP...). I thought I'd post a bunch of the links I've found to be very useful in helping to answer that question. Here are the links I've found recently:
Amanda Thompson's Windows 8 Forensic Guide
Ken Johnson's SANS DFIR Summit 2012 presentation: Windows 8 Recovery Forensics
ForensicsWiki: Prefetch - the page links to research conducted by Jared Atkinson and Yogesh Kahtri, both of whom have documented changes in the Windows 8 .pf file format.
Digital Forensics Stream: Windows 8 and 8.1 Search Charm History
Windows 8 Forensics: Recycle Bin
CyberArms: Windows 8 Forensics: Internet History Cache; also, David Cowen posted the answer to his blog challenge regarding how to analyze the IE10 web history database.