Monday, March 10, 2014

2014 SANS DFIR Summit

Can't wait to be back at the DFIR Summit!

Wednesday, May 15, 2013

The White "X"

New blog post this morning on SpiderLabs Anterior!

Five Ways to Protect Your E-Commerce Site

Great blog post by fellow Spider Grayson Lenik (@handlefree)!

Friday, December 21, 2012

How Do I Get There From Here - Part 2

So, I have had more folks ask me about a career in Incident Response and Computer Forensics lately, so I thought I would expound a bit on my original post, How Do I Get There From Here.

I think it's worth mentioning again, that the thing that will propel you in your career, regardless of what that may be, is sheer desire.  Getting up everyday, and thinking that you are not going to work because you have to, but rather that you get to go work doing something you love, makes a huge difference.  I cannot stress that be a really good investigator, there is no other way.

Something else that I have recently discovered (thanks to some great Detectives) is a great skill to have is the ability to spot patterns and anomalies.  So much of what we do in solving cases begins with finding something that just doesn't look right.  You don't have to know exactly what it is, but you know something is just off will lead you down the path of taking a deep dive into that, "thing" which will either prove or disprove your hypothesis.  Then, Sniper Forensics baby, you either use that finding to guide your investigation further, or you step back, formulate a new hypotheses, and drive on.  But that initial "hrm...what are you" moment, is something you should experience throughout your investigations.

I spoke about this at a conference once, and I was asked, "How do I learn how to spot anomalies "  Which is a valid which I answered, "By knowing what "normal" looks like".  You need to put in the chair time.  You need to know what processes should be running, from where, what is common, why - basically what makes a normal system look normal.  I was a sysadmin for many years before I ever moved into security, which helped me tremendously once I moved into the DFIR world.  If you don't have that background, then virtualization is a great thing.  Fire up some VMs of different operating systems and just look at it.  It sounds boring...but you know...wax on wax off...

Spotting patterns is a bit different.  It requires you to be able to look at data elements and find similarities in them that could be anomalous.  The best example I can think of is reviewing web logs for IOCs of SQL Injection or RFI.  If you have ever seen these attacks in logs before, you know what I am referring to.  You can actually see patterns of the attacker walking the database structure.  If he's using an automated tool to do this, you can spot it a mile away - if you scroll through the logs, it looks like a series of shark fins.  The same holds true for RFI can spot the pattern of the attacker trying to get the system to upload his file.  This is also the case for several different kids of attacks...they have visible patterns that after you put in some chair time, you can spot.  Again, even if you don't know exactly what you're looking at just that it's unique when compared to it surroundings.

OK Chris...that's all well and good in theory, but that does not help me find a DFIR job.  Do you have any recommendations that will help me actually get in the door?  Great question...and Yes...yes I do.

OK...Bit of history...when I was a sysadmin at American Express in Phoenix, I used to admin both Windows  and *nix servers (Solaris, AIX, and Linux).  It was pretty cool, but kind of boring as it didn't present anything in the way of challenges (at least for offence to Sysadmins...that's my roots!).  So, I started looking into this whole security thing (this was about 2001).  Pentest looked kewl to me.  I knew how to make stuff work...let's see if I can learn how to break into those same systems.  Since I didn't actually have a security job, I couldn't actually DO anything security related at work.  So, I bought a copy of VMware, and started playing with tools.  What was Metasploit and what did it do?  What is ARP spoofing...can I do that at home?  Basic research in my home lab.  So, when I finally found an opening and got an interview, I was able to tell the hiring manager that all I have is what I found in the open source community, and my home lab, but I practice and research at home.  I read books, blogs, and whitepapers trying to get as much knowledge as I could without actually doing the job.  Well, I got the job for that very reason.

All of that to that.  If you want a job in DFIR and you are not currently working in DFIR, then research in your home lab.  Take images of your systems, your ipod, your buddies laptops...whatever and start to play with the tools of the trade.  Learn how to mount images, create timelines, parse data on the command line, learn how to use grep, gawk, and cut, use RegRipper to inspect registry hives...etc.  Knowing which tool to use, when and why is critical!  Remember, I rarely ever use commercial forensics tools.  You can conduct comprehensive investigations without ever spending a dime!

So, if when somebody interviews you, and you tell them...I don't do this for a living but I want to and here is what I am doing to prepare myself for that, that should speak volumes about the type of employee you would be.  I know for me, you would certainly shoot to the top of my list.

I hope that helps clarify things a bit for those of you that are seeking careers in DFIR.  If there is something you would like me to expand on, please let me know!  Or, if there is something I mentioned that you would like me to dig deeper into, please let me know.  I am more than happy to help!  After all, I may be interviewing you someday.  It would be great to hear that you read my blog posts and so you did X.

Best of luck to you!

Wednesday, December 12, 2012

A Changing of the Guard

True to form, I am sitting the airport in Tulsa headed to Seattle for Blue Hat, and writing another blog post.  A lot of has gone on over the past couple of months, so let me bring you up to speed and make a bit of an "announcement".

First, and most important (as it sets the stage for my "announcement") I was recently promoted from Managing Consultant of the US DFIR team to Director of the DFIR practice at Trustwave.  I had a great boss in Colin Sheppard who was preparing me for the role, and once he left Trustwave, opened the door and made the recommendation for me to take on his role.  I am truly excited about the opportunity and look forward to the new challenges it brings.

So, that brings me to my "announcement"...I will no longer be posting strictly technical content to The Digital Standard.  I have truly enjoyed blogging about my work over the past few years and have even had the pleasure of meeting some of my readers.  However, since my role has changed significantly, and I won't be working many cases going forward, I simply won't have the content to be able to write as many technical posts that I think would actually be worth reading.

Now, part two of the announcement is that I will be changing the focus of The Digital Standard from in the trenches DFIR work to DFIR Leadership and security management.  Some of you may or may not know, but before I ever became technical, I was a business manager.  I actually have my Bachelor's degree in Business Management.  Additionally, I attended the US Army Warrant Officer Academy.  As those of you who have attended military officer producing schools know, there is a heavy focus on situational leadership (AKA being skull drug) - a skill you either develop or you wash out (for the most part).  That all to say, I actually have some experience in leadership, and feel that I have something of value to share.
Like all of my previous posts, I will intentionally be leaving out certain pieces of information.  Not only do I have NDAs to adhere to, but I have to respect the anonymity of the people I am working with and that work with me.  

For those of you that continue to read my sporadic posts, I hope you find value in my writing.  Working in the DFIR community presents some of the most unique leadership challenges anywhere in the professional world.  We joke with our clients, but it's so true, "Your worst day, in my every day".  Living in someone else's nightmare certainly helps to hone your leadership and problem solving skills!

Also, if there is something that you would like me to research and/or write about, please let me know. 
Also, Also - I am hopeful that my new position will permit me the time to do something I have been wanting to do for a couple of years now, write a Sniper Forensics book!  No promises, but it's high on the "To Do" list for 2013.  I have wanted to do it for many years, and due to the amount of case work I have been doing, I simply did not have the time.  Now that I am not actively working cases, I may actually be able to write for a couple of hours every day.  If any of you have any topics you FOR SURE would like to see covered in the book, please let me know.  I am writing it for you all...I have the information in my head already.  It wouldn't do me any good to write on something I think should be in there, if there are other things that you as the read (and purchaser) of the book would prefer to see.

Here is where I normally say, "Happy Hunting"....but considering the circumstances, I will have to work on something else to end my posts with...hrmmmmmmmm

Sunday, June 24, 2012

DFIR 2012

The SANS DFIR Summit is this Tuesday.  This is by far, one of my favorite events of the year.  I will be making the US debut of Sniper Foreniscs: 3.0 - Hunt.

Hope to see you there!

Wednesday, May 23, 2012


And here I sit at another airport, Dallas-Ft. Worth this time, writing another blog post.  And yet again, I am reminded by an issue that continues to plague my forensic brethren.  The heavy reliance on tools.

I am a member of several forensic/IR mailing lists, I read the blogosphere, and I try to keep up with many of you on twitter.  In addition, I have a strong relationship and presence with many law enforcement agencies (local, state, federal and foreign) and the officers assigned to perform DF and IR.  I intentionally don't comment very much, mostly because I don't think very many people would like my answers, but I help out when and where I can.

So to get right down to it, I still see a strong reliance on tools to solve cases for you.  I have also seen a number of posts and tweets recently where investigators are trying to make certain tools do certain things they are either not well suited to do, or where a much better solution exists.  To all this, I say, "stop"!

Stop stop stop stop it!  

Relying on tools to solve your case for you in like relying on a pile of wood and a nail gun to build your house.  It doesn't work.  It's never going to work.  The sooner you come to that conclusion, the better off you will be.  Instead of simply ranting about tool reliance, allow me to explain myself.

All of our investigations are made up of data elements.  Some have evidentiary value, while others do not, but it's all there...plain ole data.  Just sitting there waiting to have something done with it.  The question investigators SHOULD BE ASKING FIRST is what question am I trying to answer, not what tool do I need to use!  How in the world could you possibly know what tool to use before you know what you are going to do, and why?  You can't!

Now, I understand that in some cases there are just "goto" tools.  For example, I use fls in each and every case to create a timeline, I use Log2timeline or regtime to add registry hives into my timeline, I use Reg Ripper to parse my registry hives into human readable text, I always dump log files into flat text with DumpEl, and I always use pstools to dump running process information.  So I get that you have to use certain tools by default to get you to a good starting point...I do the same thing.  But that's about where it ends for me.

I don't always pull web history, I don't always scan an image with AV, I don't always extract the $MFT, and I rarely use EnCase.  Why?  Because I don't always have to!  

For example, when I know malware has been deployed on a Point of Sale (POS) system by RDP, why would I need to pull web logs?  Answer...I don't.  We browser history has nothing to do with my case.  BUT, if I see that malware may have been downloaded...let's say by reviewing ntuser.dat hives from admin users, or from evidence I find in my timeline, then OK, I will grab web history to see if I can find an additional data point that would indicate that my malware was downloaded via the makes sense in that case to do so.

I don't always scan an image with AV.  Why would I?  For those of us that pretty much live and breathe malware,  we know that scanning with AV is only going to be marginally useful, if at all.  It's going to point out known samples or common variants, and that's about it.  If the malware is custom, or is a new variant the scans will be of no value.  You are FAR better off identifying the running processes and looking for common IOCs and APIs used by the different types of malware depending on functionality.  BUT, if I am asked to find all occurrences of malware on a specific system, regardless of what it is or what it does, sure...I will scan it...because that's what I was asked to do.

I don't always extract the $MFT...b/c I don't always have to.  Since a timeline is generated from the Standard Information ($SI) attribute anyway, I already have half of the $MFT don't I?  The only time I would extract and parse the $MFT...which Harlan's is awesome when I suspect chronological (aka timestopming) modification has taken place.  HOW do I know that timestomping has taken place if I don't first parse the $MFT and compare the $SI to the File Name ($FN) attribute?  I have seen it before, and I know what the IOCs are.  I know what signs to look for that would lead me to believe that some kind of modification has taken place.  Things like pre-fetch files that are identical to creation times save for the year, the mili-seconds field being set to all zeros, and files located with other files I know to be components of the malware, with different creation times. 

So OK Chris...what's your point here?  To simply berate us for using and relying to tools to give us information?  We NEED that information to solve the heck else are we suppose to do our jobs?

GREAT point!  So let me answer...USAGE of tools is OK, and like you said, you cannot do your job without them!  Neither can I.  RELIANCE on tools to do the work for you is not OK...and as Cory would say, "it is the suck".

Step back for a moment and breathe in...and breathe out.  Clear your head and just think.  What are you doing?  What question are you trying to answer?  Why?  What information do you need to answer that question?  What does the data tell you?  These questions are the essence of the Sniper Forensics methodology.  I (among others) have been talking about this philosophical shift for four years and yet there is still considerable resistance in the community, which I really don't understand.

The best tool in your toolbox is your brain.  What Harlan has dubbed, "Wetware".  Think through your cases.  Ask a LOT of questions.  Actually take the time to answers your questions.  Let the data guide your theory.  It's really not that complicated when you break it down into smaller, more manageable components.

I will close this post with a short story.  I was recently asked to assist a LE Officer with a case he had been working on for a month.  I started by asking him a lot of questions...what are you trying to do?  What was the crime?  What information are you hoping to identify?  How will that information help your case if we find it?  How will it change your investigation if the data is not there?  What is the timeframe of the incident?  How do you know that was the timeframe?  What supporting evidence do you have that indicates that timeframe is accurate?  After listening carefully to his answers and writing them down in my case notes, I knew exactly what to do. 

I created my investigation plan.  Indicated what I was looking for and why.  I took notes on where I would likely find that data, what it would generally look like, and what I would do if I found it, as well as what I would do if I didn't find it.  In total, about 30 minutes of pre-work...maybe 45 since I was drinking a cup of coffee and typing at the same time.

When I actually put fingers to keyboard I found what the officer was looking for, and helped him solve the case in...wait for it...waaaaaaiiiittt for it....15 minutes.  He had been haphazardly looking for "bad stuff" for a full month...four weeks...30 days.  It took me longer to write my notes and drink my coffee than it did to find the evidence he was looking for.  Why you ask?  Because I took the time to use my Wetware!  I actually THOUGHT about what I was going to do, why, and what I was looking for before I ever put my hands on the keyboard, mounted an image, or touched any piece of data.

OK show's ONE case.  You got lucky.  My cases are's simply not that simple for me!

Good point...and maybe you are correct.  BUT, I have been using this methodology for four years, in each and every case.  For us in the SpiderLabs, that equates to just under 1000 cases (yes, we keep track).  So my team, in almost 1000 cases have seen this methodology work each and every time.  Without fail, and without exception.  Small cases with a single piece of evidence (like an SD card) to huge cases with hundreds of systems.  It just plain works.

So, for all you naysayers out there, for the skeptics and the old school "pull-the-pluggers", I say,  "try it".  Try doing it my way.  What do you have to lose?  Certainly not more time!  What do you have to gain?  How about solving your cases in a fraction of the time you currently solve them in?  How about clearing your ever increasing backlog?  Sounds like a pretty safe trade to me.

Happy Hunting.