New Book

So, yeah...I'm working on another book (go figure, right?).  This one is different than the previous books I've written; rather than listing the various artifacts available within an acquired image, the purpose of this book is to provide a walk-through of the investigative process, illustrate how the various artifacts can be used to complete analysis, and more importantly, illustrate and describe the various decisions made throughout the course of the examination.  The focus of this book is the process, and all along the way, various "analysis decisions" will be highlighted and detailed.

The current table of contents, with a short description of each chapter, is as follows:

Chapter 1 - Introduction
Introduction to the core concepts that I'll be reinforcing throughout the remaining chapters of the book, including documentation (eeewww, I know, right?).

Chapter 2 - Malware Detection Scenarios
In Ch 2, there are two malware detection scenarios.  Again, these are detection scenarios, not analysis scenarios.  I will discuss somethings that an analyst can do in order to move the analysis along, documenting and confirming the malware that they found, but there are plenty of resources available that discuss malware analysis in much greater detail. One of the analysis scenarios that I've seen a great deal of during my time as a DFIR analyst has been, "...we don't for sure, but we think that this system may have malware on it..."; as such I thought that this would be a great scenario to present.

In this chapter, I will be walking through the analysis process for two scenarios, one using a WinXP image that's available online, the other using a Win7 image that's available online.  That way, when reading the book, you can download a copy of the image (if you choose to do so) and follow along with the analysis process.  However, the process will be detailed enough that you won't have to have the image available to follow along.

Chapter 3 - User Activity Scenarios
This chapter addresses tracking user activity during an examination, determining/following the actions that a user took while logged into the system.  Of course, a "user" can also be an intruder who has either compromised an account, or created one that they're now using.

As with chapter 2, I'll be walking through two scenarios, one using a WinXP image, the other using a Win7 image, both of which are available online.

The purpose of chapters 2 and 3 is to illustrate the end-to-end analysis process; its not about this tool or that tool, its about the overall process.  Throughout the scenarios, I will be presenting analysis decisions that are made, describing why I decided to go a certain direction, and illustrating what the various findings mean to the overall analysis.

Chapter 4 - Setting up and using a test environment
Many times, an analyst may need to test a hypothesis in order to confirm (or deny) the creation of an artifact or indicator.  Or, the analyst may opted to test malware or malicious documents to determine what occurred on the system, and to illustrate what the user saw, and what actions the user had to have taken.  In this chapter, we'll walk through setting up a virtual environment that would allow the analyst to test such things.

This may seem like a pretty obvious chapter to many...hey, this sort of thing is covered in a lot of other resources, right?  Well, something I see a great deal of, even today, is that these virtual testing environments are not instrumented in a way that provides sufficient detail to allow the analyst to then collect intelligence, or propagate protection mechanisms through their environment.

This chapter is not about booting an image.  There are plenty of resources out there that address this topic, covering a variety of formats (i.e., "...what if I have an *.E01 image, not a raw/dd image...?").

Chapter 5 - RTFM for DFIR
If you're familiar with the Red Team Field Manual, chapter 5 will be a DFIR version of this manual.  Like RTFM, there will not be detailed explanations of the various tools; the assumption is made that you (a) already know about the tool, or (b) will put in the effort to go find out about the tool.  In fact, (b) is relatively easy...sometimes just typing the name of the CLI tool at the prompt, or typing the name followed by "/?", "-h", or "--help" is all you really need to do to get a description of the tool, its syntax, and maybe even example command lines illustrating how to use the tool.

Okay, so, yeah...I know that this is a bit different from the way I've done things in the past...most often I've just posted that the book was available.  With my last book, I had a "contest" to get submissions for the book...ultimately, I just got one single submission.

The reason I am posting this is due to this post from the ThisWeekIn4n6 blog, specifically this statement...

My only comment on this article is that maybe he could be slightly more transparent with how he’s going in the book writing process. I recall seeing a couple of posts about the competition, and then the next one was that he had completed the book. Unfortunately I missed the boat in passing on some research into the SAM file (by several months) however Harlan posted about it here.
With that in mind, I imagine he will be working on an update to Windows Forensic Analysis to cover some additional Windows 10 artifacts (and potentially further updates to other versions). Maybe a call out (yes, I know these haven’t been super successful in the past; maybe a call out to specific people? Or universities?)....

With respect to the Windows Registry Forensics book, I thought I was entirely "transparent"...I asked for assistance, and in the course of time...not just to the "end" of the contest time limit, but throughout the rest of the time I was writing the book...I received a single submission.

The "Ask"
Throughout the entire time that I've written books, the one recurring question that comes up over and over again is, "...does it cover Windows ?"  Ever time the question is asked, I have the same answer...no, because I don't have access to that version of Windows.

This time, in an attempt to head off those questions, I'm putting out a request to the DFIR community at large.  Specifically, if you have access to an image of a Windows 10 system (or to an image of any of the server versions of Windows after 2003) that have been compromised in some manner (i.e., malware, unauthorized access, etc.), and are worth of investigation, can you share them?  The images I'm using in this book are already available online, and I'm not asking that these images also be available online; if you don't mind sharing a copy of the images with me, I will walk through the analysis and include it in the book, and I will destroy/return the images after I'm done with them, whichever you would like.  

Anyone who shares an image of a Windows server version beyond (not including) Windows 2003, or an image of a Windows 10 system, for which I can include the analysis of that image in my book will receive a free, signed (yes, by me...) copy of the book once it comes out.

Addendum: Something that I wanted to add for clarity...I do not have, nor do I have access to, any system (or an image thereof) running Cortana, or anything special.  The laptop that I write the books (and blog posts) from is a Dell Latitude E6510.  My point is that if you have questions such as, "what are the artifacts of someone using Cortana?" or of any other application specific to Windows 10, please understand that I do not have unlimited access to all types of equipment.  This is why I made the request I did in this blog post.

Updates

Data Hiding Techniques
Something I caught over on Weare4n6 recently was that there's a new book on it's way out, due to be available in Oct, 2016, entitled, "Data Hiding Techniques in Windows OS".  The description of the book on the blog is kind of vague, with references to steganography, but I'm hoping that it will also include discussions of things like ADSs, and using Unicode to "hide" files and Registry keys/values in plain sight.

My initial reaction to the book, however, had to do with the cover.  To the right is a copy of the cover of my latest book, Windows Registry Forensics.  Compare that to the book cover at the web site.  In short, it looks as if Elsevier is doing it again...previous editions of my books not only had the same color scheme amongst the books, but shared that color scheme with books from other authors.  This led to massive confusion; I once received a box of books just before I left for a conference, and I took a couple of copies to give away while I was there.  When I tried to give the books away, people told me that they "...already had the book...", which I thought was odd because I had just received the box.  It turned out that they were looking at the color scheme and not actually reading the title of the book.

Right now I have nine books on my shelf that have the same or very similar color schemes...black and green.  I am the sole author, or co-author, of four of them.  The other five have an identical color scheme...a slightly different shade of green...but I am the author of only one of them.

Imaging
Mari's got another great post up, this one about using a Linux distro to image a Mac.  Yeah, I know, this blog isn't about Macs, but this same method could potentially be used to image a Windows server that you're having trouble with.  Further, Mari is one of the very few people within the community who develops and shares original material, something the community needs to encourage with more analysts.

Carberp Updates
A couple of articles appeared recently regarding changes to Carberp (PaloAltoNetworks, TrendMicro), specifically with respect to the persistence mechanism.  The PAN article mentions that this may be used to make sandbox analysis much more difficult, in that it requires user interaction to launch the malware.

The PAN article ends with a bunch of "indicators", which consist of file hashes and domain names.  I'd monitor for the creation of the key/value instead.

Some online research indicated that this persistence mechanism had been discussed on the Hexacorn blog over 2 years ago.  According to the blog post, the persistence mechanism causes the malware to be launched when the user launches an Office application, or IE with Office plugins installed.  This can make IIV determination difficult if the analyst isn't aware of it.

I updated the malware.pl RegRipper plugin accordingly.

Updates

RegRipper Plugin Updates

I recently released some updates to RegRipper plugins, fixing code (IAW Eric's recent post) and releasing a couple of new plugins.  As such, I thought it might be helpful to share a bit about how the plugins might be used during an exam.

lastloggedon.pl - honestly, I'm not entirely sure how I'd use this plugin during analysis, beyond using it to document basic information about the system.

shimcache.pl - I can see using this plugin for just about any engagement where the program execution category of artifacts is of interest.  Remember the blog post about creating an analysis matrix?  If not, think malware detection, data exfil, etc.  As Eric mentioned in his recent webcast, you could use indicators you find in the ShimCache data to pivot to other data sources, such as the AmCache.hve file, Prefetch files, Windows Event Log records with sources such as "Service Control Manager" in a timeline, etc.  However, the important thing to keep in mind is the context of the time stamps associated with each file entry...follow the data, don't force it to fit your theory.

Specific things I'd look for when parsing the ShimCache data include entries in the root of the Recycle Bin, the root of the user's profile, the root of the user's AppData/Roaming and Desktop folders, in C:\ProgramData, and with a UNC path (i.e., UNC\\tsclient\...).  Clearly, that's not all I'd look for, but those are definitely things I'd look for and be very interested in.  At one point, I'd included "alerts" in the output of some plugins that would automatically look for this sort of thing and alert the analyst to their presence, but there didn't seem to be a great deal of interest in this sort of thing. 

Win10 Notification DB

During his recent webcast regarding the AmCache.hve file, Eric mentioned the SwiftForensics site a couple of times.  Well, it turns out that Yogesh has been on to other things since he posted about the AmCache.hve file...he recently posted a structure description for the Windows 10 Notification database.  Yogesh also included a Python script for parsing the notification database...if you're examining Windows 10 systems, you might want to check it out.

I don't have enough experience yet examining Windows 10 systems to know what sorts of things would be of value, but I can imagine that there would be considerable value in this data, in a case where the user claimed to not have received an email, only to have an examiner pull a snippet of that email from the notification database, for example.

AmCache.hve
Speaking of Yogesh's comments regarding the AmCache.hve file, one of his posts indicates that it would be a goldmine for malware hunters.  As I mentioned in my previous post on the subject, in the past two months, I've examined two Windows 7 systems that were known to be infected with malware, and while I found references to the malware files in the AppCompatCache, I did not find references to the files in the AmCache.hve file.

To be clear, I'm not saying that either Yogesh's or Eric's comments are incorrect...not at all.  I'm not saying that, suggesting that, or trying to imply that.  What I am saying is that I haven't seen it yet...but also like I said before, that doesn't mean that I'm going to stop looking.

Prefetch
I haven't mentioned Prefetch artifacts in this blog for a while, as I really haven't had any reason to do so.  However, I recently ran across Luis Rocha's Prefetch Artifacts post over on the CountUponSecurity blog, and I found it to be a pretty valuable reference.  

Wait...There's More...

Tools
Mari posted to her blog again not long ago, this time sharing a description of a Mac artifact, as well as a Python script that implements her research and findings, and puts what she discussed in the hands of anyone using it.

Yes, Mari talks about a Mac artifact, and this is a Windows-based blog...but the point is that Mari is one of the very few members of the DFIR community who does something like this; identifies an artifact, provides (or links to) a clear description of that artifact and how it can be used during an examination, and then provides an easy-to-use tool that puts that capability in the hands of every analyst.  While Mari shared that she based the script off of something someone else shared, she found value in what she read and then extended the research by producing a script.

Speaking of tools, Pasquale recently posted to the SANS ISC Handler's Blog regarding something they'd seen in the Registry; it's a pretty fascinating read.

Report Writing
I recently ran across James' blog post on writing reports...it's always interesting to hear others thoughts on this particular aspect of the industry.  Like everyone else who attended public school in the US, I never much liked writing...never really got into it.  But then, much like the justifications we try to use with math ("I'll never use this..."), I found that I ended up using it all the time, particularly after I got out of college.  In the military, I wrote JAGMAN investigations, fitness reports (I still have copies of every fitrep I wrote), and a master's thesis.

Writing is such an important aspect of what we do that I included a chapter on the topic in Windows Forensic Analysis 4/e; Mari included a mention of the report writing chapter in her review of the book.  After all, you can be the smartest, best analyst to ever walk the halls of #DFIR but if you can't share your findings with other analysts, or (more importantly) with your clients, what's your real value?

As James mentioned in his blog post, we write reports in order to communicate our findings.  That's exactly why I described the process that I did in the book, in order to make it easier for folks to write clear, concise reports.  I think that one of the biggest impediments to report writing right now is social media...those who should be writing reports are too impatient to do so because they're minds are geared to immediate gratification of clicking "Like" or retweeting a link.  We spend so much time during the day feeling as if we've contributed something because we've forwarded an email, clicked "Like" on something, or retweeted it that our ability to actually communicate with others has suffered. We may even get frustrated with others who don't "get it", without realizing that by forcing ourselves into a limitation of 140 characters, we've prevented ourselves from communicating clearly.
Think about it.  Which would you rather do?  Document your findings in a clear concise report to a client, or simply tweet, "U R p0wned", and know that they read it when they click "Like"?

Look, I get that writing is hard, and most folks simply do not like to do it.  It usually takes longer that we thought, or longer than we think it needs to, and it's not the fun, sexy part of DFIR.  Agreed.  However, it is essential.  When we write the report, we build a picture of what we did and what we found, with the thought process being to illustrate to the client that we took an extremely comprehensive approach to our analysis and did everything that we could have done to address their issue.

Remember that ultimately, the picture that we paint for the client will be used to as the basis for making critical business decisions.  Yes, you're right...we're not always going to see that.  More often than not, once we send in our report to a client, that's it...that's the final contact we have with them.  But regardless of what actually happens, we have to write the report from the point of view that someone is going to use our findings and our words as the basis for a critical business decision.

Another aspect of report writing that James brought up is documenting what we did and found, for our own consumption later.  How many times have we seen something during an examination, and thought, "oh, wait...this is familiar?"  How many times have we been at a conference and heard someone mention something that rang a bell with us?  Documentation is the first step to developing single data points into indicators and threat intelligence that we use in future analysis.

WRF 2e Reviews
Speaking of books, it looks like Brett's written a review of Windows Registry Forensics 2/e up on Amazon.  Thanks, Brett, for taking the time to put your thoughts down...I greatly appreciate it.

Updates

RegRipper Plugins
I recently created a new RegRipper plugin named lastloggedon.pl, which accesses the Authentication\LogonUI key in the Software hive and extracts the LastLoggedOnUser and LastLoggedOnSAMUser values.

I wrote this one as a result of research I'd conducted based on a question a friend had asked me, specifically regarding the LastUserUsername value beneath the WinLogon key.  As it turned out, I wasn't able to locate any information about this value, nor was I able to get any additional context, such as the version of Windows on which this value might be found, etc.  I found one reference that came close to the value name, but nothing much beyond that.

Keep in mind that this plugin will simply get the two listed values.  In order to determine users that had logged in previously, you should consider running this plugin against the Software hives found in the RegBack folder, as well as within VSCs, and those extracted from memory dumps or hibernation files.

Another means of determining previously logged in users is to move out of the Registry and parse Windows Event Log records.  However, you can still use information within available Registry hives by mapping user activity (UserAssist, RecentDocs, shellbags, etc.) in a timeline.

Note that in order to retrieve values beneath the WinLogon key, you can simply use the winlogon.pl plugin.

AmCache.hve
Eric Zimmerman recently conducted a SANS webcast, during which he discussed the AmCache.hve file, a file on Windows systems that replaces/supersedes the Recentfilecache.bcf file, and the contents of which are formatted in the same manner as Registry hive files (the AmCache.hve file is NOT part of the Registry).

I enjoyed the webcast, as it was very informative.  However, I have to say that I haven't had a great deal of luck with the information available in the file, particularly when pivoting off of ShimCache data during an exam.  For example, while analyzing one image, I extracted the below two entries from the ShimCache data, both of which had the "Executed" flag set:

C:\Users\user\AppData\Local\Temp\Rar$EXa0.965\HandyDave.exe  
C:\Users\user\AppData\Local\Temp\110327027.t.exe

Parsing the AmCache.hve file from the same system, I found two entries for "HandyDave.exe", neither of which was in the same path as what was seen in the ShimCache.  I found NO references to the second ShimCache entry in the AmCache.hve file.

How did I parse the AmCache.hve file, you ask?  I used the RegRipper amcache.pl plugin.  While AmCache.hve is NOT a "Registry file" (that is, it's not part of the Registry), the file format is identical to that of Registry hive files and as such, viewing and parsing tools used on Registry hive files will work equally well on this file.

I found a lot of what Eric said in the webcast to be very informative and useful.  Just because I've struck out on a handful of exams so far doesn't mean I'm going to stop including parsing the AmCache.hve file for indications of malicious activity.  All I'm saying is that while conducting analysis of systems known to have been infected with something malicious, and on which an AmCache.hve file has been found, I have yet to find an instance where the malicious executable appears listed in the AmCache.hve file.

AppCompatCache
Speaking of Eric and his BinForay site, I've also been taking a look at what he shared with his recent AppCompatCacheParser post.  I have taken some steps to address some of the issues with the shimcache.pl plugin that Eric described and have included an updated script in the RegRipper repository.  There's still one issue I'm tracking down.

I also wanted to address a couple of comments that were made...in his post, Eric documented some tool testing he'd conducted, and shared the following:

appcompatcache.pl extracted 79 rows of data and in reviewing the data it looks like it picked up the entries missed by the Mandiant script from ControlSet01 but did not include any entries from ControlSet02:

That's due to the design...from the very beginning, all of the RR plugins that check values in the System have first determined which ControlSet was marked "current", and then retrieved data from that ControlSet, and just that ControlSet.  Here's one example, from 2009, where that was stated right here in this blog.

Eric had also said:

In my testing, entries were found in one ControlSet that were not present in the other ControlSet. 

I've also found this, as well.  However, about as often, I've seen where both ControlSets have contained identical information, which was further supported by the fact that the keys containing the data had the same LastWrite times (as evidenced by examination, as well as inclusion in a timeline).

Addendum: A short note to add after publishing this post earlier this morning; I believe I may have figured out the issue with the appcompatcache.pl and shimcache.pl plugins not displaying all of the entries, as Eric described in his post.  In short, it is most likely due to the use of a Perl hash, with the file name as the key.  What happens is that the manner in which I had implemented the hash has the effect of de-duplicating the entries prior to parsing the hash for display.

Addendum #2: Okay, so it turns out I was right about the above issue...thanks to Eric for taking the time to identify the issue and point it out.  I've not only updated the appcompatcache.pl,  appcompatcache_tln.pl, and shimcache.pl plugins, I've also created a shimcache_tln.pl plugin, as well.  I hope that someone finds them useful.