Updates

IWS
Folks have started receiving the copies of IWS they ordered, and folks like Joey and Mary Ellen have already posted reviews!  Mary Ellen has also gone so far as to post her review the Amazon page for the book!

Some have also pointed out that the XP image from Lance's practical is no longer available.  Sorry about that but I was using the image, and don't have access to, nor control over the site itself.  However, the focus of the book is the process, and choosing to use available images, I thought, would provide more value, as readers could follow along.

Addendum, 7 Oct: Thanks to the wonderful folks from the TwitterVerse who pointed out archive.org as a resource, the XP image can be found here!

Speaking of images, I got an interesting tweet the other day, asking why Windows 10 wasn't mentioned in ch. 2 of the book.  The short answer is two-fold; one, because it wasn't used/addressed.  For the second part of the answer, I'd refer back to a blog post I'd written two years ago when I started writing IWS, specifically the section of the post entitled "The "Ask"".  Okay, I know that there's a lot going on in the TwitterVerse, and that two year is multiple lifetimes in Internet time.  And I know that not everyone sees nor ingests everything, and for those who do see things or tweets, if they have no relevance at the time, then "meh".  I get it.  I'm subject to it myself.

Okay, so, just to be clear...I'm not addressing that tweet in order to call someone out for not paying attention, or missing something.  Not at all.  I felt that this was a very good opportunity to provide clarity around and set expectations regarding the book, now that it's out. The longer response to the tweet question, the one that doesn't fit neatly into a tweet, is also two-fold; one, I could not find a Windows 10 image online that would have fit that into that chapter.  The idea at the core of writing the book was to provide a view into the analysis process, so that analysts could have something with which they could follow along.

The second part of the answer is that it's about the process; the analysis process should hold regardless of the version of Windows examined.  Yes, the technical and tactical mechanics may change, but the process itself holds, or should hold.  So, rather than focusing on, "wow, there's a whole section that addresses Windows XP...WTF??", I'd ask that the focus should be on documenting an analysis plan, documenting case notes, and documenting what was learned from the analysis, and then rolling that right back into the analysis process.  After all, the goal of the book is NOT to state that this is THE way to analyze a Windows system for malware, but to show the value of having a living, breathing, growing, documented, repeatable analysis process.

Also, I was engaged in analyzing systems impacted by NotPetya during the early summer of 2017.  Another analyst on our team received several images from an impacted client, all of which were XP and 2003.  So, yes, those systems are still out there and still actively being used by clients.

Books
One of the challenges of writing books is keeping people informed as to what's coming, and giving them the opportunity to have input.  For example, after IWS was published, someone who follows me on social media said that they had no idea that there was a new book coming out.  I wanted to take the opportunity (again) to let others know what was coming, what I'm working on, in an effort to not just set expectations, but to see if anyone has any thoughts or comments that might drive the content itself.

This new book is titled Practical Windows Investigations, and the current chapters are:

1. Core Concepts
2. How to analyze Windows Event Logs
3. How to get the most out of RegRipper
4. Malware Detection
5. How to determine data exfiltration
6. File (LNK, DOCX/DOC, PDF) Analysis
7. How to investigate lateral movement
8. How to investigate program execution
9. How to investigate user activity
10. How to correlate/associate a device with a user (USB, Bluetooth)
11. How to detect/analyze the use of anti-forensics
12. Making use of VSCs

PWI differs from the current IWS in that it's about halfway between my previous books and IWS.  What I mean by that is my previous books listed artifacts, how to parse them, their potential value during an investigation, but left it to the analyst to stitch the analysis together.  IWS was more of a cradle-to-grave approach to an investigation, relying on publicly available images so that a reader could follow along, if they chose to do so.  As such, IWS was somewhat restricted to what was available; PWI is intended to address some of those things that weren't available through the images used in IWS.

I'm going to leave that right there...

RegRipper Plugins
I recently released a couple of new plugins.  One is "appkeys.pl", which offers an interesting persistence mechanism, based on Adam's blog post.  Oh, and there's the fact that it's been seen in the wild, too...so, yeah.

The other is "slack.pl", which extracts slack space from Registry cells, and parses the retrieved data for keys and values.  In my own testing, I've got it parsing keys and values, but just the data from those cell types.  As of yet, I haven't seen a value cell, for example, that included the value data, just the name.  It's there if you need it, and I hope folks find value in it.

LNK Parsing
While doing some research into LNK 'hotkeys' recently, I ran across Adam's blog post regarding the use of the AppKey subkeys in the Registry.  I found this pretty fascinating, even though I do not have media keys on my keyboard, and as such, I wrote a plugin (aptly named "appkeys.pl") to pull this information from the Registry.  I also created "appkeys_tln.pl" to extract those subkeys with "ShellExecute" values, and send the info to STDOUT in TLN format.

Adam also pointed out in his post that this isn't something that was entirely theoretical; it's been seen in the wild.  As such, something like this takes on even greater significance.

Adam also provided a link to MS's keyboard mappings.  By default, the subkey numbered "17" points to a CLSID, which translates to "My Computer".

Fun with Flags
There was a really interesting Twitter thread recently regarding a BSides Perth talk on APT LNK files.  During the thread, Nick Carr pointed out MS had recently updated their LNK format specification documentation.  During the discussion, Silas mentioned the LinkFlags field, and I thought, oh, here's a great opportunity to write another blog post, and work in a "The Big Bang Theory" reference.  More to the point, however, I thought that by parsing the LinkFlags field, there might be an opportunity to identify toolmarks from whatever tool or process was used to create the LNK file.  As such, I set about updating my parser to not only look for those documented flags that are set, but to also check the unused flags.  I should also note that Silas recently updated his Python-based LNK parser, as well.

During a follow-on exchange on Twitter on the topic, @Malwageddon pointed me to this sample, and I downloaded a copy, naming it simply "iris" on my analysis system.  I had to disable Windows Defender on my system, as downloading it or accessing it in any way, even via one of my tools, causes the file to be quarantined.

Doing a Google search for "dikona", I found this ISC handler post, authored by Didier Stevens. Didier's explanation is very thorough.

In order to do some additional testing, I used the VBS code available from Adam's blog post to create a LNK file that includes a "hotkey" field.  In Adam's example, he uses a hotkey that isn't covered in the MS documentation, and illustrates that other hotkeys can be used, particularly for malicious purposes.  For example, I modified Adam's example LNK file to launch the Calculator when the "Caps Lock" key was hit; it worked like a champ, even when I hit the "Caps Lock" key a second time to turn off the functionality on my keyboard.  Now, image making that LNK file hidden from view on the Desktop...it does make a very interesting malware persistence method.

Additional Stuff:
Values associated with the ShowWindow function - the LNK file documentation describes a 4 byte ShowCommand value, and only includes 3 values with their descriptions in the specification; however, there are other values, as demonstrated in Adam's post.

Support in the Industry
On 4 July, Alexis tweeted regarding the core reasons that should be behind our motivation for giving back to the community.  Yes, I get that this tweet was directed at content producers, as well as those who might be thinking about producing content.  His statement about the community not owing us engagement or feedback is absolutely correct, however disheartening I might have found that statement, and the realization, to be.  But like I said, he's right.  So, if you're going to share something, first look at why you're sharing.  If you're doing it to get feedback (like I very often do...), then you have to accept that you're likely not going to get it.  If you're okay with that, cool...fire away.  This is something I've had to come to grips with, and doing so has changed the way (and what) I share.  I think that it also predicates how others share, as well.  What I mean is, why put in the effort of a thorough write-up in a blog post or an article, publishing it somewhere, when it's so much easier to just put it into a tweet (or two, or twelve...).  In fact, by tweeting it, you'll likely get much more feedback (in likes and RTs) than you would otherwise, even though stuff tweeted has a lifespan comparable to a fruit fly.

More recently, Alexis shared this blog post.  I thought that this was a very interesting perspective to take, given that when I've engaged with others specifically about just offering a "thank you", I've gotten back some pretty extreme, absolutist comments in return.  For example, when I suggested that if someone shares a program or script that you find useful, one should say, "thank you", one tweeter responded that he's not going to say "thank you" every time he uses the script.  That's a little extreme, not what I intended, and not what I was suggesting at all. But I do support Alexis' statement; if you find value in something that someone else put out there, express your gratitude in some manner.  Say "thank you", write a review of the tool, comment on the blog post, whatever.  While the imposter syndrome appears to be something that an individual needs to deal with, I think as a community, we can all help others overcome their own imposter syndrome by providing some sort of feedback.

As a side note, the imposter syndrome is not something isolated to the DFIR community...not at all.  I've talked to a number of folks in other communities (threat intel, etc.) who have expressed realization of their own imposter syndrome.

Alexis also shared some additional means by which the community can support efforts in the field, and one that comes to mind is the request made by the good folks at Arsenal Recon.  Their image mounter, called "AIM", provides a great capability, one that they're willing to improve with support from the community.