Updates

Book Discount
While I was attending OSDFCon, I had a chance to (finally!) meet and speak with Jessica Hyde, a very smart and knowledgeable person, former Marine, and an all-around very nice lady.  As part of the conversation, she shared with me some of her thoughts regarding IWS, which is something I sincerely hope she shares with the community.  One of her comments regarding the book was that the price point put it out of reach for many of her students; I shared that with the publisher, and received the following as a response:

I’m happy to pass on a discount code that Jessica and her students, and anyone else you run across, can use on our website (www.elsevier.com) for a 30% discount AND we always offer free shipping. The discount code is: FOREN318.

What this demonstrates is that if you have a question, thought, or comment, share it. If action needs to or can be taken, someone will do so. In this case, my concern is the value of the book content to the community, and Jessica graciously shared her thoughts with me, and as a result, I did what I could to try and bring the book closer to where others might have an easier time purchasing it.

So how can you share your thoughts?  Write a blog post or an email.  Write a review of the book, and specify what you'd like to see.  What did you find good, useful or valuable about the book content, and what didn't you like?  Write a review and post it to the Amazon page for the book, or to the Elsevier page; both pages provide a facility for posting a review.

Artifacts of Program Execution
Adam recently posted a very comprehensive list of artifacts indicative of program execution, in a manner similar to many other blogs and even books, including my own.  A couple of take-aways from this list include:

- Things keep changing with Windows systems.  Even as far back as Windows XP, there were differences in artifacts, depending upon the Service Pack.  In the case of the Shim Cache data, there were differences in data available on 32-bit and 64-bit systems.  More recently, artifacts have changed between updates to Windows 10.

- While Adam did a great job of listing the artifacts, something analysts need to consider is the context available from viewing multiple artifacts together, as a cluster, as you would in a timeline.  For example, let's say there's an issue where when and how Defrag was executed is critical; creating a timeline using the user's UserAssist entries, the timestamps available in the Application Prefetch file, and the contents of the Task Scheduler Event Log can provide a great deal of context to the analyst.  Do not view the artifacts in isolation; seek to use an analysis methodology that allows you to see the artifacts in clusters, for context.  This also helps in spotting attempts by an adversary to impede analysis.

So, take-aways...know the version of Windows you're working with because it is important, particularly when you ask questions, or seek assistance.  Also, seek assistance.  And don't view artifacts in isolation. 

Artifacts and Evidence
A while back (6 1/2 yrs ago), I wrote about indirect and secondary artifacts, and included a discussion of the subject in WFA 3/e.

Chris Sanders recently posted some thoughts regarding evidence intention, which seemed to me to be along the same thought process.  Chris differentiates intentional evidence (i.e., evidence generated to attest to an event) from unintentional evidence (i.e., evidence created as a byproduct of some non-attestation function).

Towards the end of the blog post, Chris lists six characteristics of unintentional evidence, all of which are true.  To his point, not only may some unintentional evidence have multiple names, it may be called different things by the uninitiated, or those who (for whatever reason) choose to not follow convention or common practice.  Consider NTFS alternate data streams, as an example.  In my early days of researching this topic, I found that MS themselves referred to this artifact as both "alternate" and "multiple" data streams.

Some other things to consider, as well...yes, unintentional evidence artifacts often are quirky and have exceptions, which means they are very often misunderstood and misinterpreted.  Consider the example of Shim Cache entry from Chris's blog post; in my experience, this is perhaps the most commonly misinterpreted artifact to date, for the simple fact that the time stamps are commonly referred to as the "date of execution".  Another aspect of this artifact is that it's taken as standalone, and should not be...there may be evidence of time stomping occurring prior to the file being included as a Shim Cache record.

Finally, Chris is absolutely correct that many of these artifacts have poor documentation, if they have any at all.  I see this as a short-coming of the community, not of the vendor.  The simple fact is that, as a community, we're so busy pushing ahead that we aren't stopping to consider the value to the community as a whole that we're leaving behind.  Yes, the vendor may poorly document an artifact, or the documentation may simply be part of the source code that we cannot see, but what we're not doing as a community is documenting and sharing our findings.  There've been too many instances during my years doing DFIR work that I would share something with someone who would respond with, "oh, yeah...we've seen that before" only to have no documentation, not even a Notepad document or something scribbled on a napkin to which they can refer me.  This is a loss for everyone.