WindowsIR 2017

I thought that for my final post of 2017, I'd pull together some loose ends and tie off some threads from throughout the year, and to do that, I figured I'd just go through the draft blog posts I have sitting around, pull out the content, and put it all into one final blog post for the year.

Investigating Windows Systems
Writing for my next book, Investigating Windows Systems, is going well.  I've got one more chapter to get completed and in to my tech reviewer, and the final manuscript is due in April, 2018.  The writing is coming along really well, particularly given everything that's gone on this year.

IWS is a departure from my previous books, in that instead of walking through artifacts one after another, this book walks through the process of analysis, using currently available CTF and forensic challenges posted online, and specifically calling out analysis decisions along the way.  For example, at one point in the analysis, why did I opt to take this action, rather than that one?  Why did I choose to pivot on this IP address, rather than run a scan?

IWS is not a book about the basics.  From the beginning, I start from the point that whomever is reading the book knows about the MFT, understands what a "timeline" is, etc.  Images and analysis scenarios are somewhat limited, given that I'm using what's already available online, but the available images do range from Windows XP, through Windows 10.  In several instances in the book, I mention creating a timeline, but do not include the exact process in the text of the book, for a couple of reasons.  One is that I've already covered the process.  The other is that this is the process I use; I don't require anyone to use the exact same process, step by step.  I will include information such as the list of commands used in online resources in support of the book, but the reader can create a timeline using any method of their choosing.  Or not.

Why Windows XP?  Well, this past summer (July, 2017), I was assisting with some analysis work for NotPetya, and WinXP and 2003 systems were involved.  Also, the book is about the analysis process, not about tools.  My goal is, in part, to illustrate the need for analysts to choose a particular tool based their understanding of the image(s) being analyzed and the goals of the analysis.  Too many times, I've heard, "...we aren't finished because vendor tool X kept crashing, and we kept restarting it...", without that same analyst having a reasoned decision behind running that tool in the first place.

Building a Personal Brand in InfoSec
I've blogged a couple of times this year (here, and here) on the topic of "getting started" in the cyber security field.  In some cases, thoughts along these lines are initiated by a series of questions in online forums, or some other event.  I recently read this AlienVault blog post on the topic, and I thought I'd share my thoughts on the topic, with respect to the contents of the article itself.  The author makes some very good points, and I saw an opportunity to tie their comments in with my own.

- Blogging is a good way to showcase your knowledge
Most definitely.  Not only that, a blog post is a great way to showcase your ability to write a coherent sentence.  Sound harsh?  Maybe it is.  I've been in the infosec/cybersecurity industry for about 20 yrs, and my blog goes back 13+ yrs.  This isn't me bragging, just stating a fact. When I look at a blog article from someone, anyone...new to the industry, been in the industry for a while, or returning to blogging after being away for a while...the first thing that stands out in my mind isn't the content as much as it the author's ability to communicate.  This is something that is not unique to me; I've read about this in books such as "The Articulate Executive in Action", and it's all about that initial, emotional, visceral response.

There are a LOT of things you can use as a basis for writing a blog post.  The first step is understanding that you do not have to come up with original or innovative content.  Not at all.  This is probably the single most difficult obstacle to blogging for most folks.  From my experience working on several consulting teams over two decades, it's the single most used excuse for not sharing information amongst the team itself, and I've also seen/heard it used as a reason for not blogging.

You can take a new (to you) look at a topic that's been discussed.  One of the biggest misconceptions (or maybe the biggest excuse) for folks is that they have nothing to share that's of any significance or value, and that simply is not the case at all.  Even if something you may write about has been seen before, the simple fact that others are still seeing it, or others are seeing it again after an apparent absence, is pretty significant.  Maybe others aren't seeing it due to some change in the delivery mechanism; for example, early in 2016, there was a lot of talk about ransomware, and most of the media articles indicated that ransomware is email-borne.  What if you see some ransomware that was, in fact, email-borne but bypassed protection/detection mechanisms due to some variation in the delivery?  Blah blah ransomware blah blah email blah user clicked on it blah.  Whether you know it or not, there's a significant story there.  Or, maybe I should say, whether you're willing to admit it to yourself or not, there's a significant story there.

Don't feel that you can create your own content?  You can write book reviews, or reviews of individual chapters of books.  I would caution you, however...a "book review" that consists of "...chapter 1 covers blah, chapter 2 covers blah..." is NOT a review at all.  It's the table of contents.  Even when reviewing a single chapter, there's so much to be said...what was it that the author said, or was it how they said it?  How did what you read in the pages impact you, or your daily SOP?  Too many times I've seen reviews consist of little more than a table of contents, and not be abundantly helpful.

- Conferences are an absolute goldmine for knowledge...
They definitely are, and the author makes a point of discussing what can be the real value of conferences, which is the networking aspect. 

A long time ago, I found that I was attending conference presentations, and found that it felt like the first day of high school.  I'd confidently walk into a room, take my seat, and within a few minutes of the presenter starting to speak, start to wonder if I was in the correct room.  It often turned out that either the presentation title was a place holder, or that I had completely misinterpreted the content from the 5 words used in the title.  Okay, shame on me.  Often times, however, presenters don't dig into the detail that I would've hoped for; on the other hand, when I've presented on what something look like (i.e., lateral movement, etc.), I've received a great deal of feedback.  When I've seen such presentations, I've had a great deal of feedback (and questions) myself.  Often a lot of the detail...what did you see, what did it look like, why did you decide to go left instead of right...comes from the networking aspect of conferences.

- Certifications are a hot topic in the tech industry, and they are HR’s best friend for screening applicants.
True, very true.  But this goes back to the blogging discussed above...I'm not so much interested in the certifications one has, as much as I'm interested in how the knowledge and skills are used and applied.  Case in point, I once worked with someone (several years ago) who went off to a week-long training course in digital forensics, and within 6 weeks of the end of the course, wrote a report to a client in which they demonstrated their lack of understanding of the MFT.  In a report.  To a client.

So, yes, certifications are viewed as providing an objective measure of an applicant's potential abilities, but the most important question to ask is, when someone is sent off to training, does anyone hold them accountable for what they learned?  When they come back from the training, do they have new tools, processes, and techniques that they then employ, and you can see the result of this in their work?  Or, is there little difference between the "before" and "after"?

On Writing
I mentioned above that I'm working on completing a book, and over the last couple of weeks/months, I've run across some excellent advice for folks who want to write books that cover 'cyber' topic.  Ed Amoroso shared some great Advice For Cyber Authors, and Brett Shavers shared a tip for those thinking of writing a DFIR book.

Fast Times at DFIR High
One of the draft posts I'd started earlier this year had been one in which I would recount the "funny" things that I'd seen go on over the past 20 years in infosec (what we used to call "cybersecurity"), and specifically within DFIR consulting work.  I'm sure that a great deal of what I could recount would ring true for many, and that many would also have their own stories, or their own twists on similar stories.  I'd had vignettes in the draft written down, things like a client calling late at night to declare an emergency and demand that someone be sent on-site before they provided any information about the incident at all, only to have someone show up and be told that they could go home (after arriving at the airport and traveling on-site, of course). Or things like a client sending password-enabled archives containing "information you'll want", but no other description...requiring that they all be opened and examined, questions asked as to their context, etc.

I opted to not continue with the blog article, and I deleted it, because it occurred to me that it wasn't quite as humorous as I would have hoped.  The simple fact is that the types of actions I experienced in, say, 2000, are still being seen by active IR consultants today.  I know because I've talked to some IR folks who've experienced them.  Further, it really came down to a "...cast the first stone..." issue; who are we (DFIR folks, responders, etc.) to chide clients for their actions (how inappropriate or misguided that we see them...) when our own actions are not pristine?  Largely, as a community (and I'm not including specific individuals in this...), we don't share experiences, general findings, etc., with each other.  Some do, most don't...and life goes on.

Final Thought for 2017
EDR. Endpoint visibility is going to become an even more important issue in the coming year.  Yes, I've refrained from making predictions, and I'm not making one right now...I'm simply saying that the past decade has shown the power of early detection, and the differences in outcomes when an organization understands that a breach has likely already occurred, and actively prepares for it.  Just this year, we've seen a number of very significant breaches make it into the mainstream media, with several others being mentioned but not making, say, the national news.  Even more (many, many more) breaches occur without ever being publicly announced in any manner.

Equifax is one of the breaches that we (apparently) know the most about, and given what's appeared in the public eye, EDR would've played a significant role in avoiding the issue overall.  Given what's been shared publicly, someone monitoring the systems would've seen something suspicious launched as a child process of the web server (such filters or alerts should be common place) and been able to initiate investigative actions immediately.

EDR gives visibility into endpoints, and yes, there is a great deal of data headed your way; however, there are ways to manage this volume of data.  Employ threat intelligence to alert you to those actions and events that require your attention, and have a plan in place for how to quickly investigate and address them.  The military refers to this as "immediate actions", things that you learn in a "safe" environment and that you practice in adverse environments, so that you can effectively employ them when required.  Ensure that you cover blind spots; not just OS variants, but also, what happens when the adversary moves from command line access (via a Trojan or web shell) to GUI shell (Windows Explorer) access?  If your EDR solution stops providing visibility when the adversary logs in via RDP and opens any graphical application on the desktop, you have a blind spot.

Effective use of EDR solutions can significantly reduce costs associated with the current "state of the breach"; that is, getting notified by an external third party that you've suffered a breach, weeks or months after the initial compromise occurred.  With more immediate detection and response, your requirement to notify (based on state laws, regulatory bodies, etc.) will be obviated.  Which would you rather be...the next Equifax, or, because you budgeted for a solution, you can go to regulatory bodies and state, yes, we were breached, but no critical/sensitive data was accessed?