A while back, I sent a signed copy of IWS to someone who was willing to write a review, and they've gone about trying to post their review with some difficulty, albeit not for a lack of trying on their part.  I greatly appreciate the effort, not just in reading and engaging with the book, and writing a review, but also trying to get it posted and shared!  So much so, in fact, that I offered to host the review here. 

While the book hasn't been out for a full year yet, I'm still just as nervous as I was the first day, regarding how the book will be viewed by the community.  This book is a pretty radical departure from my previous books, as well as from any other DFIR book I could find.  As such, with something this new (I had pretty much the same feelings regarding Windows Registry Forensics...), I greatly appreciate hearing how folks found the book, as well as if they were able to get anything from it...did it provide value?

Thanks, Dmitri, for taking the time read the book, and for putting in the additional effort to write down and share your thoughts! 

So...a review, by Dmitri...

Investigating Windows Systems - Review

I've read several books by Harlan, and I've never been disappointed. I love his direct way of writing. IWS is thinner and smaller than his other books but no less important, on the contrary.

Harlan writes that IWS is not for beginners, I still see myself as a beginner and should contradict Harlan here, also IWS is a book that is important, or may be, for any beginner, although some pieces in the book are not so easy with an effort of the reader and a search on the Internet everything becomes understandable.

The book is well organized. It teaches you from the beginning that a good analysis plan is important. It teaches you to focus between 'nice to know' and 'need to know'.

The book is divided into several cases (finding malware, user activity, web server compromise). Harlan explains to you how he would deal with these cases himself, and then teaches you how to make a self-reflection. What did you learn from your case, and how would you tackle it next time?

The book is not about the analysis of images themselves, nor about which tools you should use, but about how you should do the analysis, what plan you make. He teaches you to make the difference between a targeted approach and an automated approach.

In the last part, Harlan will teach you how to set up a testing environment, and convince you that testing changes in the file system yourself by deleting files, installing programs, …,  is often more instructive than just asking for help on the net.

I really enjoyed the book.

Dimitri Deryckere
1st Inspector 
Computer Crime Unit – Pz Regio Tielt - Belgium

A New Blogger
I ran across a fascinating blog post during my Sunday morning reading, one that was interesting in a number of ways.  First off, this is apparently Charity's first blog post...so, congrats!  Thank you for stepping up and sharing your insight. It is refreshing and oh-so-important for those newer to the field to speak up and share their perspective, as those who've been around for a while may find this perspective valuable; I know I do.

I don't know Charity, we've never met.  I simply ran across a tweet announcing her first blog post, and thought, cool...I'll take a look.  I like to see what folks are bringing to the table, in particular due to the fact that when I was in college and 'coming up' in my career, there were no resources such as college programs for infosec or "the cybers".  It's been fascinating to watch the evolution of the field over time, and to see folks like Charity bring a new perspective to the field.

I took martial arts training for a bit while I was in junior high school, and then again during my first deployment to Okinawa.  In both instances, sparring was involved...when I was studying shorin ryu, a good bit of the sparring came during testing before the grandmaster.  One of the take-aways for me from that sparring was that while there are rules for such things, they only apply to those who follow them.  Admittedly, I did learn this truism while playing soccer and wrestling in high school, but I think it really became a bit more obvious while I was sparring.  For example, we didn't wear head gear during the sparring, because one of the rules was that the head was not a target.  I seem to remember that this was a test of your understanding and use of the technique, as well as self-control, under controlled circumstances. During my training sessions prior to testing, everyone adhered to that rule...likely because we were all from the same unit.  However, during the testing, there were athletes from different locations on the island, and as such, you never knew how they trained.  During one sparring session, the first shot my opponent took was directly to my head.

The point is that as an IR consultant, you may find yourself sparring not only with the threat actor with whom you are engaged, but also with the culture of the folks you are assisting.  Agreed upon rules, such as not forcing the password change until everyone is ready, only works if everyone who agrees to them actually adheres to and follows them.

To one of Charity's points, during IR engagements, I also got to see how those I was working with reacted to stress, and very often, my first goal was to bring down that stress level so that we could move and respond in more of a coordinated fashion, and less based on adrenaline. During one IR engagement, I arrived on-site at 10:30pm on a Friday night, knowing that the team had already been working 20+ hr days for the last 10 days or so.  My first action was to get everyone to go home; it took some time, but we got the last person out the door by 11:30pm.  Even the following day, within the first few hours, some of the folks at the site were having trouble typing commands, and would click the wrong buttons in a UI.  Too many mistakes were being made, making simple actions take far too long to accomplish.  Having everyone get some rest, and then focusing their efforts once we were back in the fight got us to the point where we were making some headway, and once we were able to build up some forward momentum, the stress levels started to come down.

Also, it makes me wonder if Charity and Lesley or Richard have had a chance to meet yet.

Roll-Ups
Roll-ups are a great way to get an overview of what happened during a given week or month, and to maybe see something that you might have missed.  ThisWeekIn4n6 is a great resource for just this purpose, but like other such roll-ups and consolidations, the descriptions of various articles or events can sometimes fall short of the mark.

Okay, before we go any further, I am not knocking the effort that goes into producing a roll-up like this every week, along with a monthly overview.  Not at all.  It's a lot of work and greatly appreciated, as I know I've seen things in the weekly roll-up that I would not have seen otherwise.  As such, I do not expect a full-blown review of each of the resources listed; however, I will say that I'm no different from anyone else, in that I may not look at something that contains some real solid information, based on the description.

One example is Ali's recent blog post titled Creating a Hidden Prefetch File to Bypass Normal Forensic Analysis. Ali addresses what happens on a system when an executable is launched from within an ADS, and the effect that may have on "normal" DF analysis. I was interested in the article because (a) Ali is a friend, and (b) I've been interested in ADSs since about 1998.  As such, I was enticed to read the full content of the article, and I found value in it.

In the roll-up description, there is the statement, "This prefetch file was not detected by forensic tools". Should it have been?  Most tools, particularly the commercial ones, present data on which the examiner then needs to perform analysis; however, is it incumbent upon a tool to 'detect' this sort of thing?

As another example, a co-worker and I had a blog post published on our corporate web site recently; the roll-up description simply states that we "looked at increased TrickBot activity from GRIM SPIDER.".  Really, it is SO much more than that! The purpose of the article that Eric and I worked on (Eric did the lion's share of the work) was to stand on the shoulders of the CS Intel team and illustrate what was seen "on the ground" across a number of IR engagements.  Yes, the article started out mentioning the described increase in activity, in order to tie it to the previous blog post from our Intel team.  However, it then extended that information by incorporating what was observed through incident response, given the aperture and collection bias of the IR team. Not only was this deep dive discussed in the article, but we wanted to make it easier to digest by presenting a table of observables (table 1 in the article) by mapping MITRE ATT&CK tactics and techniques to the actual data from the engagement, to illustrate what the technique "looks like".

My point is simply this...sometimes the description of an article isn't inline with the content, and sometimes it isn't even enticing.  However, there is a lot of great content out there, content that shouldn't be passed over because of a synopsis that perhaps doesn't generate interest.

LNK Files
Huntress Labs recently posted an article regarding an LNK file they'd seen, and the deep dive that they took into the LNK file and the PowerShell that it launched. While the article includes 'deep dive' in the title, there is no mention of LNK file metadata.  Now, this may be due to the fact that the LNK file was created on, rather than sent to, the target system, but there isn't enough detail within the article for a reader to know.

The technique described, while very interesting, is not new.  I mentioned Felix's post regarding booby-trapped LNK files.  It is fascinating to see other examples of how this technique is used, and it would be very interesting to see some of the other TTPs surrounding this particular use of the technique, for context.  Also, it would be very interesting to see what this 'looks like' with respect to EDR tooling...I suspect that the parent process would be the Windows Explorer shell, shown launching PowerShell, with a child process of mshta.exe; however, there doesn't seem to be any information regarding where the file was found with in the file system, how it is launched, etc.

I think that this was a great dive into the technique used, and I enjoy reading technical analyses such as this, as they show the lengths that an adversary will go to in order to avoid detection, as well as buy themselves some time as these things are unraveled.  However, in this particular case, there's a good bit that isn't said; for example, if the LNK file was created on the system where it was found, then one can assume that there was a bit of a 'noisy' process to create it.  After all, this isn't something that you can create directly via the API.  Yes, you can get it started via the API, but additional tooling is required to append data to the end of the LNK file AND include a command in the LNK file to read that data; this isn't 'normal'.  Yes, it can be accomplished via scripting, but that script would have had to have been copied over and executed, TTPs which can be detected.  If the LNK file was created on another system, such as the bad guy's system, then there is likely metadata in the file that can tell us about that system, as well as toolmarks that can tell us something about how the LNK file was created.

The folks at Huntress Labs did a great job of unraveling the LNK file, but for whatever reason, a great deal was left unsaid.  I, for one, would be very interested in knowing more about the file, as there is undoubtedly valuable information that can be used to develop threat intelligence.

Speaking of unraveling LNK files, the folks at JPCERT/CC recently blogged about weaponized LNK files being used against targets.  This one is interesting due to the fact that targeted users receive an email that contains a link to the weaponized LNK file, which is hosted in a cloud service.  As such, the LNK file is not an attachment to the email, nor is it in a zipped archive that is attached to the email; it's downloaded to the target system and executed after the user clicks a link.

Unfortunately, the article only gives an overview of the LNK file; there are some aspects of this issue that bear closer examination.  I understand that some things may have been presented from a high-level view due to the sensitivity of the case being worked, translating to English, etc.  However, based on prior experience, there may be go deal of intelligence that can be gleaned from the samples.

I did a search for several (albeit not all) of the hashes listed, and could not find samples. I think that there may be something interesting there, if we're able to look at the full metadata of the LNK files, especially if it's plotted across time (when the phishing emails were sent) or campaigns.  I'd like to see more, in part because I think that there's more to see...