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 enough...to 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 questions...to 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 attacks...you 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 me...no 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 say...do 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!
Showing posts sorted by relevance for query how do I get there. Sort by date Show all posts
Showing posts sorted by relevance for query how do I get there. Sort by date Show all posts
Friday, December 21, 2012
Monday, July 18, 2011
How Do I Get There From Here?
I have had several people ask me lately, "How do I get there from here"? Not referring to the Country song by Deana Carter, but referring to how to get a job as a forensic investigator/incident responder. So, after thinking about it, here are some ideas that I outlined that help me get to where I am today. Hopefully, you will find them helpful as well.
First of all, you need a good attitude. You need to leave your ego or any overinflated sense of superiority at the door. Some of the absolute BEST people in this industry...guys like Harlan Carvey, Rob Lee, Ovie Carroll, Cory Altheide, Hal Pomeranz, Chad Tilbury, Lenny Seltzer, Jesse Kornblum, Colin Sheppard, Chris Hague, Jibran Ilyas, Grayson Lenik and Eric Huber all share a common trait...Humility. I bet if you asked any one of them if they were good at what they do, you would likely get some variant of the response, "I sure try, but there is always so much to learn!"
They know they do not know everything, and work hard keep current on emerging concepts and technologies . I have met them all, and there is absolutely NO pretense in any of these industry giants. Also, they are passionate about their work, and love what they do. They are the best because they work the hardest. Period.
You also need to be flexible. The slogan of this industry is "semper gumby" - always flexible. You need to be able to adapt to constantly changing situations, emerging evidence, difficult customers, challenging time tables, and extensive travel. Don't be too rigid, or get frustrated when things either change unexpectedly, or don't turn out as planned.
And Travel...loooooots of travel. As an example, I am writing this in the airport during week three of a seven week travel spree. You will travel...a LOT...so get used to it.
Second, you have to be wired for this kind of work. By, "wired", I mean you just have to "get" technology. You have to have a knack for computers beyond the skills and abilities of what would commonly be referred to as a "normal" end user. You cannot be scared by the command line, Linux, Mater Boot Records, Master File Tables, the Windows Registry, the OSI model, Perl, Ruby, and/or Python (just to name a few). You need to be able to read, comprehend, and figure stuff out. You should know what you are looking at, why, and be able to explain it to anyone. In short, you need to be either inherently smart, or prepared to work really hard (I fall into the latter category - not the smartest dood in the room, but I think I work as hard as, or harder than just about anyone). In my opinion, having a concrete foundational knowledge is essential for the job, and is really the difference maker between someone who is OK at the job, and someone who is really good. So never stop learning!
Remember, knowing how to use a tool (any tool) no more makes you an investigator, than knowing how to use MS Word makes you Stephen King. It's a tool that does something...NOTHING more. It's the expert set of eyes on the screen and the expert fingers on the keyboard that make up the expert.
Third, you need a desire to find the truth. The evidence is there (usually), and it's up to you to find it, and interpret it properly. Also, there is a famous quotes by Dr. Carl Sagan who stated, "The absence of evidence is not the evidence of absence". Remember, it is the job of the investigator to identify and properly interpret the evidence.
These are the precepts you should hang your "hat" on. Find the truth. Dig it out of every registry hive, file system, unallocated cluster, slack space, and network capture you can find.
Along those lines, Harlan and I were recently having a discussion over breakfast about context. The basic results were that many investigators will jump to conclusions based on a single data point without building appropriate context around that data point. Why is it there? What does it mean? Am I drawing conclusions based on theory or fact? Are there other data points that all indicate the same "thing" took place. For us, best practice is to identify at least three data points that all point in the same direction. This will give the investigator confidence in what they found (that it is indeed accurate), and give weighting to the evidence.
This is something I touch on in Sniper Forensics. NEVER EVER form your opinion about what happened and try to make the data fit your theory. Let the data formulate your theory, and allow your investigation to flow with the evidence. You may change directions numerous times. Doing so doesn't mean you are wrong, or a bad investigator. It means you know enough to allow the evidence to guide the investigation. It's a complex, fluid combination of art and science, and if it were easy, everybody would do it and be good at it.
OK...so now that we have covered some of the basics regarding attitude, and some philosophical essentials, let's talk about education. You need it. Personally, I am not a huge fan of the forensic degree programs currently be taught at many universities. From what I have seen, they teach tool use, and maybe a little theory. Which is good, but not something that is going to equip an investigator for a successful career in the field. I would LOVE to see them teach the history of forensic science, logic, investigative methodology, technical writing, research methodologies, public speaking, conflict resolution, and systems administration. These are the key proponents of a solid investigator...not knowing how to use a tool! If you have the opportunity to take any class that covers these topics, I would HIGHLY recommend doing so. You would be amazed if I told you how relevant my Pre-Socratic Philosophy class is to my job! Or how much better my reports are after taking a technical writing course. The independent research I have done on expert witness testimony has made me better prepared to speak on the stand. Taking a class that certifies you in how to use a certain tool...ya...not gonna teach you ANY of those things...I'm juuuuuuuuuuuust sayin...
In my opinion, if you are looking into a degree program, take something that is going to teach you what "normal" looks like. Get a general IT degree that is well rounded with courses in Windows, Linux, networking, midrange, and emerging technologies. You can learn the tools later, knowing the basics will serve you far better in the field.
I am a fan of technical certifications...sort of. I have several, and I feel like I got something out of studying for, taking, and passing the requisite examinations. I think the subject matter is relatively small (compared to the larger IT world), focused, and can help to contribute to your subject matter expertise in a specific area.
Now, I am only partially a fan of certifications for a couple of reasons. I know several people who have multiple certifications, and are crummy investigators. Alternatively, I know several people who have few or no technical certifications, who are fantastic investigators. Again, those little letters after your name don't make you a good investigator. They mean you paid some money, sat in a class, and passed an exam. Nothing more. If you have multiple certs...good for you...don't get a big head about it. If you don't have any...don't let it discourage you. They are what they are...indicators that you took a class and passed a test.
Don't get me wrong, from a business perspective, technical certifications go a long way in establishing you as a subject matter expert (some contracts I have worked on even required them). Also, they can show prospective employers that you are serious about your trade, and have taken steps to set yourself apart from other applicants. But don't ever think that just because you have a cert and someone else doesn't that you are "better" than they are. It's simply not the case...ever...and it's just going to make you look like a jerk. I recommend taking the approach that you love the trade and want to learn as much as you can about it. You are fortunate enough to have the resources necessary to attend the class and take the exam. It was a great experience, and you feel that you have benefitted from the knowledge you gained. BUT, you realize that the forensics/IR world is a big place with a LOT to learn, and you are eager to be engaged in any way you can (recognize your efforts without breaking your arm patting yourself on the back...good skill to have). If you are good at what you do, your actions will speak far louder than any certifications ever could.
Next, know that you are going to have to interact with customers....a lot. You are going to have to explain some very technical concepts to non-technical people - not stupid, just not technical. You are going to have to deal with angry lawyers, crying business owners, demands, fear, and uncertainty. Basically, every new case, is everyone's worst day. You need to become skilled in situational analysis, leadership, public speaking, and incident management. You will have to learn how to walk the line (a very fine line sometimes) between confidence and arrogance. This is a difficult concept to learn, and honestly after studying it in both my undergrad and graduate degree programs, at Warrant Officer Candidate School, and reading books about it...it's something you are going to have to experience to get good at. At least by doing to research on it, you can better prepare yourself, and decrease the time it's going to take you to become proficient.
I also recommend reading Dale Carnegie's, How to Win Friends and Influence People at least once per year. Take good notes, and use them. It has a wealth of information and has been THE standard for interpersonal business relationships for almost 100 years. Also, realize that at the end of your contract is a person...a human being. This is their business, or their company...their livelihood. This is how they put a roof over their head, food on their table, and their kids through school. Be cognizant of that, and empathetic to their situation.
Finally, I will share some personal details about how I broke into the industry. When I was a sysadmin I got bored. You can only makes things work so well, and know how to troubleshoot so much, before it becomes mundane. That was the case with me...I was a Solaris and Windows admin at a decently sized IT shop and I was pretty good. My systems ran well, I could troubleshoot quickly and efficiently...and I was bored to tears. So, I searched internally for openings doing something different and I came across a posting for the Ethical Hacking Team. I had all of the required skills (networking, Linux, Windows), no different than any of the other applicants. But, what I had that they did not was raw desire. I wanted this job more than anything. I read anything I could get my hands on that dealt with the subject, spent my own money setting up a makeshift lab to play with tools, and perform experiments. I ooozed enthusiasm. I ended up getting the job. After I was hired, I asked my new manager what was it about me that ended up landing me the job? She told me something I have never forgotten to this day...
"Chris, I can teach you how to use the tools. The other folks on the team can teach you how to go after certain targets, what to look for, and how to run exploits. What I can't teach is enthusiasm. I know that you will be one of my best pentesters in a year simply because you want to be. I firmly believe you wanted the job more than anyone else."
So, while being passionate may not land you the job, it will set you apart from other applicants. Read, research, study, conduct experiments. Learn something new every day. Learn how to use open source tools (which is like 99% of what I use). Learn about forensic theory, investigative methodology, and logic. Learn how to write reports, how to deal with difficult situations and difficult people, and how to LISTEN! Most of all, love the work!
I hope you find this information helpful. If you have any specific questions, please feel free to email me at any time. I am always willing to help!
Happy Hunting!
First of all, you need a good attitude. You need to leave your ego or any overinflated sense of superiority at the door. Some of the absolute BEST people in this industry...guys like Harlan Carvey, Rob Lee, Ovie Carroll, Cory Altheide, Hal Pomeranz, Chad Tilbury, Lenny Seltzer, Jesse Kornblum, Colin Sheppard, Chris Hague, Jibran Ilyas, Grayson Lenik and Eric Huber all share a common trait...Humility. I bet if you asked any one of them if they were good at what they do, you would likely get some variant of the response, "I sure try, but there is always so much to learn!"
They know they do not know everything, and work hard keep current on emerging concepts and technologies . I have met them all, and there is absolutely NO pretense in any of these industry giants. Also, they are passionate about their work, and love what they do. They are the best because they work the hardest. Period.
You also need to be flexible. The slogan of this industry is "semper gumby" - always flexible. You need to be able to adapt to constantly changing situations, emerging evidence, difficult customers, challenging time tables, and extensive travel. Don't be too rigid, or get frustrated when things either change unexpectedly, or don't turn out as planned.
And Travel...loooooots of travel. As an example, I am writing this in the airport during week three of a seven week travel spree. You will travel...a LOT...so get used to it.
Second, you have to be wired for this kind of work. By, "wired", I mean you just have to "get" technology. You have to have a knack for computers beyond the skills and abilities of what would commonly be referred to as a "normal" end user. You cannot be scared by the command line, Linux, Mater Boot Records, Master File Tables, the Windows Registry, the OSI model, Perl, Ruby, and/or Python (just to name a few). You need to be able to read, comprehend, and figure stuff out. You should know what you are looking at, why, and be able to explain it to anyone. In short, you need to be either inherently smart, or prepared to work really hard (I fall into the latter category - not the smartest dood in the room, but I think I work as hard as, or harder than just about anyone). In my opinion, having a concrete foundational knowledge is essential for the job, and is really the difference maker between someone who is OK at the job, and someone who is really good. So never stop learning!
Remember, knowing how to use a tool (any tool) no more makes you an investigator, than knowing how to use MS Word makes you Stephen King. It's a tool that does something...NOTHING more. It's the expert set of eyes on the screen and the expert fingers on the keyboard that make up the expert.
Third, you need a desire to find the truth. The evidence is there (usually), and it's up to you to find it, and interpret it properly. Also, there is a famous quotes by Dr. Carl Sagan who stated, "The absence of evidence is not the evidence of absence". Remember, it is the job of the investigator to identify and properly interpret the evidence.
These are the precepts you should hang your "hat" on. Find the truth. Dig it out of every registry hive, file system, unallocated cluster, slack space, and network capture you can find.
Along those lines, Harlan and I were recently having a discussion over breakfast about context. The basic results were that many investigators will jump to conclusions based on a single data point without building appropriate context around that data point. Why is it there? What does it mean? Am I drawing conclusions based on theory or fact? Are there other data points that all indicate the same "thing" took place. For us, best practice is to identify at least three data points that all point in the same direction. This will give the investigator confidence in what they found (that it is indeed accurate), and give weighting to the evidence.
This is something I touch on in Sniper Forensics. NEVER EVER form your opinion about what happened and try to make the data fit your theory. Let the data formulate your theory, and allow your investigation to flow with the evidence. You may change directions numerous times. Doing so doesn't mean you are wrong, or a bad investigator. It means you know enough to allow the evidence to guide the investigation. It's a complex, fluid combination of art and science, and if it were easy, everybody would do it and be good at it.
OK...so now that we have covered some of the basics regarding attitude, and some philosophical essentials, let's talk about education. You need it. Personally, I am not a huge fan of the forensic degree programs currently be taught at many universities. From what I have seen, they teach tool use, and maybe a little theory. Which is good, but not something that is going to equip an investigator for a successful career in the field. I would LOVE to see them teach the history of forensic science, logic, investigative methodology, technical writing, research methodologies, public speaking, conflict resolution, and systems administration. These are the key proponents of a solid investigator...not knowing how to use a tool! If you have the opportunity to take any class that covers these topics, I would HIGHLY recommend doing so. You would be amazed if I told you how relevant my Pre-Socratic Philosophy class is to my job! Or how much better my reports are after taking a technical writing course. The independent research I have done on expert witness testimony has made me better prepared to speak on the stand. Taking a class that certifies you in how to use a certain tool...ya...not gonna teach you ANY of those things...I'm juuuuuuuuuuuust sayin...
In my opinion, if you are looking into a degree program, take something that is going to teach you what "normal" looks like. Get a general IT degree that is well rounded with courses in Windows, Linux, networking, midrange, and emerging technologies. You can learn the tools later, knowing the basics will serve you far better in the field.
I am a fan of technical certifications...sort of. I have several, and I feel like I got something out of studying for, taking, and passing the requisite examinations. I think the subject matter is relatively small (compared to the larger IT world), focused, and can help to contribute to your subject matter expertise in a specific area.
Now, I am only partially a fan of certifications for a couple of reasons. I know several people who have multiple certifications, and are crummy investigators. Alternatively, I know several people who have few or no technical certifications, who are fantastic investigators. Again, those little letters after your name don't make you a good investigator. They mean you paid some money, sat in a class, and passed an exam. Nothing more. If you have multiple certs...good for you...don't get a big head about it. If you don't have any...don't let it discourage you. They are what they are...indicators that you took a class and passed a test.
Don't get me wrong, from a business perspective, technical certifications go a long way in establishing you as a subject matter expert (some contracts I have worked on even required them). Also, they can show prospective employers that you are serious about your trade, and have taken steps to set yourself apart from other applicants. But don't ever think that just because you have a cert and someone else doesn't that you are "better" than they are. It's simply not the case...ever...and it's just going to make you look like a jerk. I recommend taking the approach that you love the trade and want to learn as much as you can about it. You are fortunate enough to have the resources necessary to attend the class and take the exam. It was a great experience, and you feel that you have benefitted from the knowledge you gained. BUT, you realize that the forensics/IR world is a big place with a LOT to learn, and you are eager to be engaged in any way you can (recognize your efforts without breaking your arm patting yourself on the back...good skill to have). If you are good at what you do, your actions will speak far louder than any certifications ever could.
Next, know that you are going to have to interact with customers....a lot. You are going to have to explain some very technical concepts to non-technical people - not stupid, just not technical. You are going to have to deal with angry lawyers, crying business owners, demands, fear, and uncertainty. Basically, every new case, is everyone's worst day. You need to become skilled in situational analysis, leadership, public speaking, and incident management. You will have to learn how to walk the line (a very fine line sometimes) between confidence and arrogance. This is a difficult concept to learn, and honestly after studying it in both my undergrad and graduate degree programs, at Warrant Officer Candidate School, and reading books about it...it's something you are going to have to experience to get good at. At least by doing to research on it, you can better prepare yourself, and decrease the time it's going to take you to become proficient.
I also recommend reading Dale Carnegie's, How to Win Friends and Influence People at least once per year. Take good notes, and use them. It has a wealth of information and has been THE standard for interpersonal business relationships for almost 100 years. Also, realize that at the end of your contract is a person...a human being. This is their business, or their company...their livelihood. This is how they put a roof over their head, food on their table, and their kids through school. Be cognizant of that, and empathetic to their situation.
Finally, I will share some personal details about how I broke into the industry. When I was a sysadmin I got bored. You can only makes things work so well, and know how to troubleshoot so much, before it becomes mundane. That was the case with me...I was a Solaris and Windows admin at a decently sized IT shop and I was pretty good. My systems ran well, I could troubleshoot quickly and efficiently...and I was bored to tears. So, I searched internally for openings doing something different and I came across a posting for the Ethical Hacking Team. I had all of the required skills (networking, Linux, Windows), no different than any of the other applicants. But, what I had that they did not was raw desire. I wanted this job more than anything. I read anything I could get my hands on that dealt with the subject, spent my own money setting up a makeshift lab to play with tools, and perform experiments. I ooozed enthusiasm. I ended up getting the job. After I was hired, I asked my new manager what was it about me that ended up landing me the job? She told me something I have never forgotten to this day...
"Chris, I can teach you how to use the tools. The other folks on the team can teach you how to go after certain targets, what to look for, and how to run exploits. What I can't teach is enthusiasm. I know that you will be one of my best pentesters in a year simply because you want to be. I firmly believe you wanted the job more than anyone else."
So, while being passionate may not land you the job, it will set you apart from other applicants. Read, research, study, conduct experiments. Learn something new every day. Learn how to use open source tools (which is like 99% of what I use). Learn about forensic theory, investigative methodology, and logic. Learn how to write reports, how to deal with difficult situations and difficult people, and how to LISTEN! Most of all, love the work!
I hope you find this information helpful. If you have any specific questions, please feel free to email me at any time. I am always willing to help!
Happy Hunting!
Wednesday, May 23, 2012
Wetware
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 web...it 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 MFT.pl is awesome for...is 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 cases...how 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 Chris...whatever...you show off...it's ONE case. You got lucky. My cases are complicated...it'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.
Monday, June 29, 2009
Y the 101?
As some of you have noticed, the first few posts on TheDigitalStandard are centered around foundational principles of investigation. I did this intentionally because I believe whole heartedly that without integrating these critical building blocks of investigative theory into your personal methodology, you will not - and I really mean this - WILL NOT be anything more than an average investigator.
I started with "Semper Gumby" where I wrote about being flexible and allowing the evidence guide you rather than your theories dictate what the evidence said. I followed up with, "Trust" where I wrote about trusting your instincts, and never being satisfied with simply doing the minimum, but allowing yourself to be woken up at zero-dark-thirty to work on a case. I finished up with "The Alexiou Principle" in which I wrote about having clearly defined expectations, you establish an investigation plan, and you follow through with the plan by asking and answering quantifiable questions.
Now, I realize that this may sound rather harsh, so please let me assure you - I intended it to be. I assume that if you are taking the time to read this blog, you are trying to improve your forensic and incident response skills. It was not too long ago, that I was where you most likely are now...interested, overwhelmed, inundated. Interested in this line of work...how to break into the field, where to begin, who to contact, who will give you a chance? Overwhelmed with tools, techniques, terms like MD5, non-repudiation, analysis, and file carving. Inundated with tools, EnCase, FTK, TSK, Helix, SMART, F-Response, and MFL (just to name a very few).
So you being where you are, I would also assume that you want to get better. You want to HAVE these tools, and more importantly you want to know how to USE these tools! How do you parse a registry? What is file carving anyway? How do I use a regex to find credit card data? What does all of this look like? AHHHHHHH!!! There is TOO MUCH!
Let me assure you, you are correct - there is too much for an one person to know. Be very very wary of anyone who tells you the contrary. I don't care they've "been doing this for 20 years". They don't know everything. None of us do. So what? Are we doomed? Are we all bound to mediocracy? The answer is a resounding, "No"...no you are not...IF and only IF you have a solid foundation of understanding upon which to build.
Build your foundation on critical concepts like "Locard's Exchange Principle", "Occam's Razor", "The Alexiou Principle". Use critical tools like organization, clear concise questions, and sound logic. Develop useful habits like taking good notes, using a buddy to discuss your case work, and remaining mentally pliable.
Listen, I have heard it said that the Peace Corps is the toughest job you'll ever love. I think that is crap. Being a Computer Forensic Investigator is BY FAR the toughest job you'll ever love. So if you are like me, and you really love this line of work, then why not be the best at it? Be the best there is! To do that, you have to develop the core skills necessary for greatness. Look at some greats in the world of sports...Tiger Woods, Curt Schilling, Walter Payton, Michael Jordan...they were/are the best at their particular sport because they worked hard. Harder than anyone else. They were the first on the field, and the last to go home. They hit just one more putt, reached for one last yard, and threw just one more batter. They were anything but average and each of them shared one thing in common - mastery of the basics that made up the game.
The core message here is that if you are going to do this job, don't be average. Master the basics...get SO good at those that you could do them in your sleep. Then, you will be ready to truly be great! It's a long journey which I have yet to complete. I work hard everyday to get better, learn more...get that one last regex working before calling it quits.
Master the basics, and be great! I hope to be there someday too!
I started with "Semper Gumby" where I wrote about being flexible and allowing the evidence guide you rather than your theories dictate what the evidence said. I followed up with, "Trust" where I wrote about trusting your instincts, and never being satisfied with simply doing the minimum, but allowing yourself to be woken up at zero-dark-thirty to work on a case. I finished up with "The Alexiou Principle" in which I wrote about having clearly defined expectations, you establish an investigation plan, and you follow through with the plan by asking and answering quantifiable questions.
Now, I realize that this may sound rather harsh, so please let me assure you - I intended it to be. I assume that if you are taking the time to read this blog, you are trying to improve your forensic and incident response skills. It was not too long ago, that I was where you most likely are now...interested, overwhelmed, inundated. Interested in this line of work...how to break into the field, where to begin, who to contact, who will give you a chance? Overwhelmed with tools, techniques, terms like MD5, non-repudiation, analysis, and file carving. Inundated with tools, EnCase, FTK, TSK, Helix, SMART, F-Response, and MFL (just to name a very few).
So you being where you are, I would also assume that you want to get better. You want to HAVE these tools, and more importantly you want to know how to USE these tools! How do you parse a registry? What is file carving anyway? How do I use a regex to find credit card data? What does all of this look like? AHHHHHHH!!! There is TOO MUCH!
Let me assure you, you are correct - there is too much for an one person to know. Be very very wary of anyone who tells you the contrary. I don't care they've "been doing this for 20 years". They don't know everything. None of us do. So what? Are we doomed? Are we all bound to mediocracy? The answer is a resounding, "No"...no you are not...IF and only IF you have a solid foundation of understanding upon which to build.
Build your foundation on critical concepts like "Locard's Exchange Principle", "Occam's Razor", "The Alexiou Principle". Use critical tools like organization, clear concise questions, and sound logic. Develop useful habits like taking good notes, using a buddy to discuss your case work, and remaining mentally pliable.
Listen, I have heard it said that the Peace Corps is the toughest job you'll ever love. I think that is crap. Being a Computer Forensic Investigator is BY FAR the toughest job you'll ever love. So if you are like me, and you really love this line of work, then why not be the best at it? Be the best there is! To do that, you have to develop the core skills necessary for greatness. Look at some greats in the world of sports...Tiger Woods, Curt Schilling, Walter Payton, Michael Jordan...they were/are the best at their particular sport because they worked hard. Harder than anyone else. They were the first on the field, and the last to go home. They hit just one more putt, reached for one last yard, and threw just one more batter. They were anything but average and each of them shared one thing in common - mastery of the basics that made up the game.
The core message here is that if you are going to do this job, don't be average. Master the basics...get SO good at those that you could do them in your sleep. Then, you will be ready to truly be great! It's a long journey which I have yet to complete. I work hard everyday to get better, learn more...get that one last regex working before calling it quits.
Master the basics, and be great! I hope to be there someday too!
Monday, April 23, 2012
The Core Duo
"The Core Duo"
Once again I am sitting in an airport (LaGuardia this time)
writing another blog post. The good
news, is that it looks like my life is taking back on some semblance of
normalcy, and I can start writing again.
Since my promotion to Managing Consultant, in conjunction with the
release the Trustwave Global Security Report, I have been swamped. But, that's all I have to say about that.
So I have recently been doing a lot of speaking and
teaching, and came to an interesting conclusion about what are the core (an in
my opinion, critical) skills of our trade, which I have affectingly dubbed,
"The Core Duo".
When I really started to think about it, what we do
(Forensics and Incident Response) really boils down to only two things.
1. Spotting Patterns
2. Spotting Anomalies
Now, I know this sounds really simple...maybe too simple,
but let me explain. First of all,
simplicity is something that I think is frequently minimized as being
undesirable. I think there are a lot of folks who think something to the effect of, "If something can be
explained in simple, easy to understand terms, it must not be very
complex". I challenge that this is not
the case. I think, that even the most
complex situations (which we all know, cyber investigations are among the most
technical and convoluted anywhere) is made up of components that can be broken
down and simplified. Being able to do this is a critical element in actually understanding what you are doing and why you are doing it. That in turn leads to be successful at what you are doing. Which finally, leads to you solving the case, and potentially, some bad guy going to jail.
Ok...so think about your "typical" case. You have stuff (technical term)...RAM dumps,
volatile data, forensic images, maybe some log files. You are asked to find something (again,
technical term) within that stuff. What
are you asked to find will depend on the case, but the theme is the
same...go find something specific. Now
the fun begins as far as I am concerned...how do you find the something within
the stuff?
Well, there are these things we commonly refer to as,
"Indicators of Compromise" or IOCs.
They are data points that indicate the presence of something within the
stuff. So I was thinking, "What
makes one data point an IOC and another data point not an IOC?" I argue that it's because that something has
to fall into one of two categories. It
is either an anomaly, or a pattern.
Let's first explore what I mean by using the term,
"Anomaly". It just means that
the something is different than all of the other somethings. There is something about THIS something that
makes it different. WHAT is different is,
why it's anomalous, what does the anomaly mean, etc...that's the easy
part. Binaries can be extracted, log
files can be parsed, ripped reg hives can be clearly read and compared with
forensic timelines...all the things we normally do in a case. BUT (and this is a pretty big but) ALL of
that...all of the tools that exist, all of the book and blog posts that have
been written, all of the conferences we attend, and all of the money we spend
on training...they all hinge on this one thing...can we spot the anomaly. Can we find the one or the two (or whatever)
files, amongst the tens or hundreds of thousands that are like the kids on
Sesame Street, doing their own thing?
THIS is the first core of our trade.
The second core item of the "Duo" is the ability
to spot patterns. In my opinion, this
applies more to incident response than it does to forensics, although by no
means exclusively. Think about a case in
which all you have are log files. This
is common in my world in E-Commerce cases involving things like SQL Injection,
Remote File Inclusion, and Web Shells.
Some of these cases literally involve millions of lines of log files
that at first glance, all look more or less the same. Anyone who has worked on an E-Comm case knows
what I am referring to. Line after line
after line after line of logs...and you are thinking to yourself, "What
the heck am I even looking for?" Me? I am looking to identify the first sign of an anomaly,
then for a pattern of those anomalies.
Some of the logs entries will have something different about
them...it's WHAT is different, and HOW we spot them that is the real meat of the analysis. Then, once
you spot the anomaly, you would look for a pattern of that anomaly. Does it occur at regular increments? Does it originate from the same
location? Does the access show the same
thing or things being accessed over and over...can you spot the pattern?
So what does all this mean.
OK Chris, we agree with you, to be good at Forensics and/or IR you have
to be good at spotting anomalies and patterns.
So what? What does that mean to
me? Well, I am glad you asked! A couple of things.
1. It gives you an area of focus. Still, one of the most common issues I see
while training investigators is analysis paralysis. Simply freezing when confronted with so much data...what do I
do...where do I go...how do I even begin?
How do I go from gathering data to actually starting to solve
cases.
I think that by knowing, that in
every case, regardless of what the case may be, you are either looking for an
anomaly or a pattern can help you focus on the task at hand, and get down to
making progress (not just throwing tools at data and expecting it to solve the case for you. FORENSIC HINT: THAT will NEVER happen .
2. It helps you as you try to tie your data points
together. In an "average"
case, we may have data points in our timeline, registry hives, RAM, system event
logs, and from binary analysis. We have a
lot of data points that all indicate that a breach took place, data was accessed, malware was installed, basically tell the
story of what happened during that breach.
By understanding that what you are looking at are a series of anomalies
that form a pattern. This pattern is the
backdrop against which you will formulate the rest of your investigation.
So, in conclusion, I know it may sound simple, but what I
have named, "The Core Duo" of forensics/IR is the ability to spot
Anomalies or Patterns. Knowing and
understanding this concept can help investigators (both new and seasoned) begin
difficult investigations with a better idea of what something they are trying
to find within the stuff.
On a side note, since I have begun using this concept, the
students that I have taught (and those in the audience at the conferences I
have spoken at) have really liked the idea, and have indicated that it really
does work. Once gentleman recently told
me that he wrote them down on a sticky note, and attached the note to his
monitor.
It very simply stated.
1. What is the anomaly?
2. Can you spot the pattern?
I think that's a great idea!
While I don't have sticky notes on my monitor, I DO have Case Notes, and
in my notes, I now have an entry under my "Misc" tab that indicates
the same thing. I urge you to give it a
try and let me know how it goes.
Happy Hunting!
Saturday, June 27, 2009
The Alexiou Principle
One of the most common mistakes I see made by computer forensic investigators of all levels of experience, Law Enforcement, and Corporate, is the lack of a clear direction. They know there is "bad guy" stuff out there somewhere, so they go attack it without first establishing an investigation plan. In my experience, this methodology NEVER yields solid results, and ALWAYS leads to confusion, wasted time, and questions going unanswered. As forensic investigators using such absolute terms like "never", and "always" is a NOGO, but in this case I find that it's true. Please comment you have experienced the contrary.
In the spirit of coming to you with solutions and not problems, I would like to share the investigative theory that I use and that have been proven to work EVERY time..."The Alexiou Principle". Named after its creator Mike Alexiou, the Alexiou Principle states four questions for the investigator to answer:
1. What question are you trying to answer?
2. What data do you need to answer that question?
3. How do you extract that data?
4. What does that data tell you?
Every case has a question - in fact most cases have multiple questions. Regardless of what the circumstances are, there is something you are trying to answer. I encourage my team to make sure these questions are clear with their customers to ensure that expectations have been set appropriately on both sides. Few things are worse than coming to what you believe to be the conclusion of an investigation and have the customer ask you, "What about X"? and you're all, "What? We never discussed X"! To avoid this hammer out the questions the client wants to have answered and review it with them! That way, they know what you are going to do, and more importantly, YOU know what the expectations on you are! I also encourage my team to log their questions in their Case Notes. Doing this not only helps them to keep track of what it is exactly that they are doing (preventing scope creep and analysis paralysis), but it also allows them to track what the answers to those questions are and how they came about finding those answers (making the writing of their final reports SOOOOOO much easier).
Once you have established what it is that you are trying to answer, it's time to figure out what data is going to give you the answers you are looking for. Depending on the question and the operating system there are likely several places that you will need to look. The key here is being able to phrase precisely and clearly what it is that you are looking for. For example, I have worked several cases involving AS/400s. Now although my first job out of the Army was as an AS/400 administrator, that was more than 10 years ago and I was only in that role for about six months. So any knowledge I had about the AS/400 or Z/OS is totally gone (probably replaced by important facts like which restaurants have the best bread pudding, and how to help my daughter hold a "proper" tea party)! But who cares!? Not me IF I can either ask the customer's admin, or I have Internet access. Say for instance I wanted to know user activity on an AS/400. A quick search on the web showed me that I would need to check the DSPSECAUD to see if security auditing was activated, and then I could display the audit journals by running DSPJRN JRN(QAUDJRN). I know that is kind of an obscure example, but you get the idea.
Once you have identified your data, you need to extract it. How you do this is really up to you and will depend greatly on your case, the evidence you have on hand, the data you have already collected, and the tools in your toolbox. I won't go much more into this question, because I think it's pretty self explanatory. The one thing I will say is that you should treat this question like a when we did math problems in like 5th grade. SHOW YOUR WORK. State in your notes and in the final report that you extracted data X, Y, and Z for the purposes of BLAH.
Finally, and most importantly (in my opinion) is what the data tells you. Some common mistakes investigators (including myself!) make are jumping to conclusions about the data, misinterpreting the data, or forcing the data to fit into their theories. When you are looking at your data and think you have an answer, go back to your notes and outline the process you just took to get there. Seriously, this takes all of 3 minutes, but will prove to be invaluable to your case. I will state my question, indicate where the data exists, indicate how I extracted that data to include the tool(s) and version(s), and what I believe that data is telling me. Once I have all of that information written down, I will read it over a few times to make sure it says what I want it to say (as opposed to simply being the first thing I wrote down - which is often nothing more than a series of jumbled thoughts and comments). Then I show it to a buddy and ask him if it makes sense. A peer review of your conclusions is a great tool you can use to ensure you are not making incorrect assumptions, or misinterpreting data. Then you would repeat this process for every question you have been asked to answer by your customer.
If this seems really easy to you, that's because it is. Too many investigators introduce unneeded complexity into their investigations by not focusing and having a clear investigation plan. Maybe these people think they need to make things seem complex so that they appear to be smart, or like "real" pros...seasoned and hard core? I don't know, in my opinion having an attitude like that is counter productive and a huge waste of time.
Being a good investigator has nothing to do with how many $5 words you can throw out, or how many years of experience you have! It's about figuring out what happened! I promise you, if you apply the Alexiou Principle and go into your cases with a PLAN, you will be a better investigator, regardless if this is your first case or your 500th.
In the spirit of coming to you with solutions and not problems, I would like to share the investigative theory that I use and that have been proven to work EVERY time..."The Alexiou Principle". Named after its creator Mike Alexiou, the Alexiou Principle states four questions for the investigator to answer:
1. What question are you trying to answer?
2. What data do you need to answer that question?
3. How do you extract that data?
4. What does that data tell you?
Every case has a question - in fact most cases have multiple questions. Regardless of what the circumstances are, there is something you are trying to answer. I encourage my team to make sure these questions are clear with their customers to ensure that expectations have been set appropriately on both sides. Few things are worse than coming to what you believe to be the conclusion of an investigation and have the customer ask you, "What about X"? and you're all, "What? We never discussed X"! To avoid this hammer out the questions the client wants to have answered and review it with them! That way, they know what you are going to do, and more importantly, YOU know what the expectations on you are! I also encourage my team to log their questions in their Case Notes. Doing this not only helps them to keep track of what it is exactly that they are doing (preventing scope creep and analysis paralysis), but it also allows them to track what the answers to those questions are and how they came about finding those answers (making the writing of their final reports SOOOOOO much easier).
Once you have established what it is that you are trying to answer, it's time to figure out what data is going to give you the answers you are looking for. Depending on the question and the operating system there are likely several places that you will need to look. The key here is being able to phrase precisely and clearly what it is that you are looking for. For example, I have worked several cases involving AS/400s. Now although my first job out of the Army was as an AS/400 administrator, that was more than 10 years ago and I was only in that role for about six months. So any knowledge I had about the AS/400 or Z/OS is totally gone (probably replaced by important facts like which restaurants have the best bread pudding, and how to help my daughter hold a "proper" tea party)! But who cares!? Not me IF I can either ask the customer's admin, or I have Internet access. Say for instance I wanted to know user activity on an AS/400. A quick search on the web showed me that I would need to check the DSPSECAUD to see if security auditing was activated, and then I could display the audit journals by running DSPJRN JRN(QAUDJRN). I know that is kind of an obscure example, but you get the idea.
Once you have identified your data, you need to extract it. How you do this is really up to you and will depend greatly on your case, the evidence you have on hand, the data you have already collected, and the tools in your toolbox. I won't go much more into this question, because I think it's pretty self explanatory. The one thing I will say is that you should treat this question like a when we did math problems in like 5th grade. SHOW YOUR WORK. State in your notes and in the final report that you extracted data X, Y, and Z for the purposes of BLAH.
Finally, and most importantly (in my opinion) is what the data tells you. Some common mistakes investigators (including myself!) make are jumping to conclusions about the data, misinterpreting the data, or forcing the data to fit into their theories. When you are looking at your data and think you have an answer, go back to your notes and outline the process you just took to get there. Seriously, this takes all of 3 minutes, but will prove to be invaluable to your case. I will state my question, indicate where the data exists, indicate how I extracted that data to include the tool(s) and version(s), and what I believe that data is telling me. Once I have all of that information written down, I will read it over a few times to make sure it says what I want it to say (as opposed to simply being the first thing I wrote down - which is often nothing more than a series of jumbled thoughts and comments). Then I show it to a buddy and ask him if it makes sense. A peer review of your conclusions is a great tool you can use to ensure you are not making incorrect assumptions, or misinterpreting data. Then you would repeat this process for every question you have been asked to answer by your customer.
If this seems really easy to you, that's because it is. Too many investigators introduce unneeded complexity into their investigations by not focusing and having a clear investigation plan. Maybe these people think they need to make things seem complex so that they appear to be smart, or like "real" pros...seasoned and hard core? I don't know, in my opinion having an attitude like that is counter productive and a huge waste of time.
Being a good investigator has nothing to do with how many $5 words you can throw out, or how many years of experience you have! It's about figuring out what happened! I promise you, if you apply the Alexiou Principle and go into your cases with a PLAN, you will be a better investigator, regardless if this is your first case or your 500th.
Wednesday, September 9, 2009
Autopilot?
A recent post on Forensic Focus got me thinking. Basically, someone asked if there was another tool like Harlan Carvey's RegRipper that could be used to validate their findings. After talking with Harlan at some length about this, we pretty much came to the same conclusion that there are a lot of folks out there who are stuck in the old school, running on auto pilot.
Let's get something straight from the get go here, I am totally for output validation when and where necessary. Since certain tools do things in certain ways, it may be important to use another tool that comes to that same result in a different way to validate that the first tool is not doing something jankity.
Case in point was the gig I had in which I was asked to determine if some office documents had been tampered with. Some tools use metadata to display chronological information while others use the OLE data. Some tools can extract chronological data without having to mount the image, others require the image to be mounted. The point here is that the tools do things in a slightly different way.
RegRipper parses registry hives. There was a funny post where a chap stated that RegRipper is not a registry viewer, so you can't mount the hives and have a "look around". While this is a true statement, I thought it was indicative of the "old school" of forensics. What are you going to look around for? Are you going to perform "Registry Analysis" with NO IDEA what you are looking for, why, or which keys do what? This is where the term "Auto Pilot" comes in. So many folks simply have blind reliance on their tools to do the work for them. They have no idea what the tool does, how it does it, and where the output in generated from. They just load, fire, and report...this tool did this...how many other tools can I get to do the same thing? Maybe by using 17 tools to take an MD5 hash, people will think I am really smart and KNOW that my MD5 hash is a good and proper MD5 hash!
What I am getting at here is that you should have a basic understanding of what the tools you are using actually do, and how they actually do that thing. I am no coder, so I could not pull apart regripper and tell you which lines to what, but I CAN read. Harlan has done a great job with documenting how regripper works and even allows you to write your own plugins! If you took about 30 mins and reviewed the documentation, you would know that regripper simply parses the data from the registry hives in a readable format. It takes the more complex keys (like those that are Rot13'd) and translates them into plain english. That's it...no smoke, no mirrors, no voodoo magic. If you want to validate your findings, get a hex editor and do it by hand.
There are a couple of takeaways here. First, understand your tools. Have at least a basic understanding of what they do and how they do it. Then you can make an educated decision if you need another tool to validate your findings. Second, don't be on auto pilot. Don't simply run a tool and then state in your report that 'Tool BLAH showed me BLAH." Instead, state what you are looking for, why you are looking for it, and THEN state what the findings were.
Remember YOU are the subject matter expert. Your case findings should be repeatable if another investigator took the same data and used the same tools. If you document your goals clearly, and the steps you took which brought you to your conclusions, you should never have a need to defend your tools.
Let's get something straight from the get go here, I am totally for output validation when and where necessary. Since certain tools do things in certain ways, it may be important to use another tool that comes to that same result in a different way to validate that the first tool is not doing something jankity.
Case in point was the gig I had in which I was asked to determine if some office documents had been tampered with. Some tools use metadata to display chronological information while others use the OLE data. Some tools can extract chronological data without having to mount the image, others require the image to be mounted. The point here is that the tools do things in a slightly different way.
RegRipper parses registry hives. There was a funny post where a chap stated that RegRipper is not a registry viewer, so you can't mount the hives and have a "look around". While this is a true statement, I thought it was indicative of the "old school" of forensics. What are you going to look around for? Are you going to perform "Registry Analysis" with NO IDEA what you are looking for, why, or which keys do what? This is where the term "Auto Pilot" comes in. So many folks simply have blind reliance on their tools to do the work for them. They have no idea what the tool does, how it does it, and where the output in generated from. They just load, fire, and report...this tool did this...how many other tools can I get to do the same thing? Maybe by using 17 tools to take an MD5 hash, people will think I am really smart and KNOW that my MD5 hash is a good and proper MD5 hash!
What I am getting at here is that you should have a basic understanding of what the tools you are using actually do, and how they actually do that thing. I am no coder, so I could not pull apart regripper and tell you which lines to what, but I CAN read. Harlan has done a great job with documenting how regripper works and even allows you to write your own plugins! If you took about 30 mins and reviewed the documentation, you would know that regripper simply parses the data from the registry hives in a readable format. It takes the more complex keys (like those that are Rot13'd) and translates them into plain english. That's it...no smoke, no mirrors, no voodoo magic. If you want to validate your findings, get a hex editor and do it by hand.
There are a couple of takeaways here. First, understand your tools. Have at least a basic understanding of what they do and how they do it. Then you can make an educated decision if you need another tool to validate your findings. Second, don't be on auto pilot. Don't simply run a tool and then state in your report that 'Tool BLAH showed me BLAH." Instead, state what you are looking for, why you are looking for it, and THEN state what the findings were.
Remember YOU are the subject matter expert. Your case findings should be repeatable if another investigator took the same data and used the same tools. If you document your goals clearly, and the steps you took which brought you to your conclusions, you should never have a need to defend your tools.
Tuesday, September 1, 2009
Plan the Work, Work the Plan
I have heard of investigators (and unfortunately, witnessed a few myself) that will simply go into a case without really knowing what they are looking for. They don't clarify expectations with the customer, don't think about what it is that they are trying to find, and end up just "looking for bad guy stuff". Can I just share with you what a monumentally horrible idea that is? If you don't know what it is that you are looking for, how will you ever known when you find it? This is why it is so critical to create an investigation plan BEFORE you start poking around in your data.
Creating an investigation plan is one of, if not the most important steps an investigator can take in preparation for a new case. It allows you to clearly outline what your objectives are and provides a framework for the direction of the entire case. All too often this critical step is skipped in the interest of time. What some folks don't realize is that by not having a comprehensive investigation plan, they are actually increasing the amount of time their case is likely to take.
The first question that needs to be asked at the onset of any case is, "what are my objectives". What are the goals of the case? What information does the customer want? What questions do they want answered? Once you have the specific items the customer wants to have addressed, reiterate them to ensure that there has not been a breakdown in communication somewhere.
"I am hearing that you want me to try and determine, X, Y, and Z. Is that correct?"
I know it may sound a bit juvenile, but really, everything hinges off the customer's expectations. So at the risk of misinterpreting those expectations, and failing to deliver what the customer has paid for, it is a necessary step. Ensure that both parties are "on the same sheet of music", so that when you deliver your final report you can state, "Hey...you asked me to find A, B, and C....HERE is A, B, and C".
This is where corporate investigators differ from our brethren in the law enforcement community...to a certain extent. We have a clear set of goals that our customers have paid for. They have the expectation that they will get answers to those questions. The SOW is signed, and we get to work and get them their answers in the time allotted by the contract.
In the law enforcement world, there are no timeframes and often no clear direction of what the goals are. Recently, I learned that most local, state, and federal agencies that deal with cyber-crimes are pushing out cases in anywhere from six months to three years! In that time, they may stumble upon three or four criminal activities perpetrated by the owner of the suspect system. They look under every rock, they search every crevice. They have the luxury of time (for the most part)...we do not.
Once the goals for our investigations have been established, we can apply the Alexiou Principle to further clarify our actions.
The Alexiou Principle states:
1. What question are you trying to answer?
2. What data do you need to answer that question?
3. How do you extract that data?
4. What does that data tell you?
Your questions need to be as specific as possible. You cannot simply say things like, "I want to find all signs of bad guy stuff", or "I want to find everything that this guy did wrong." Some good examples of well worded questions are:
1. How did the intruder gain access to the customer's network
2. What mechanism did the intruder use to gather customer data
3. How did the intruder get the stolen data off the customer's network
These can be answered clearly in with one sentence each.
1. The intruder gained access to the customer system by using a weak pcAnywhere password.
2. The intruder used a packet sniffer to detect and compile track data in transit.
3. The intruder used FTP to send files containing the stolen track data to his server.
There will obviously be much greater detail surrounding each question, however this is a good example of how you can be very precise in your answers. Don't take two paragraphs to say what you can say just as well in two sentences. Most customer's are not interested in verbosity, they just want to know what happened, and how.
Once you have your questions outlined, you can begin to search for the data that will provide you the answers. For example, if one of your questions is, "How did the intruder gain access to the customer's network" you are going to look in places that contain data about system access. You are NOT going to scan the machine for viruses, look for pornography, or check for rootkits. Why not? Because they have nothing to do with system access. You WOULD check in event logs, application logs (like pcAnywhere, or LogMeIn), firewall logs, ntuser.dat files, and the system and software registry hives.
With as much data that is in volatile memory, RAM dumps, and on system images, it's very easy to get overwhelmed - something referred to as "analysis paralysis". You have theories buzzing around in your head, "What if the attacker did this? What if he did that"? Don't fall victim to that kind thinking. Keep your hypothesis tied to the data. Let the data guide the direction of your case. Don't try to force the data to fit your ideas about the case.
We only have a limited time to deliver our final reports that clearly and concisely meet the customer's expectations. We do not have the luxury of time, and cannot possibly find everything that may be "wrong" with customer systems. We have been hired to answer questions...that's it. So answer them thoroughly, and in a manner that the customer can easily understand. If you stumble across something they have not asked (or paid for) then bonus...include it in the report as an additional finding, but don't go looking for them.
I have heard customers at the conclusion of a case state, "Why did you do X? I didn't ask you to do X. I asked you to do Y and Z! I want all of the money I spent on you finding X refunded to me. It was not in the contract, and I am not paying for it!" Also, I have been on the other side of that conversation in which a customer told me, "Why didn't you find Z? I wanted you to figure out Z!". To which I replied, "Hey...remember the SOW conversation we had, we outlined the goals of the investigation? Remember and you agreed to all of those items, and we put them in a contract...that you signed? You asked me to figure out A, B, and C...which I did...very clearly. If you want Z, that's fine...I will find Z, but we will need to add hours to the SOW." They didn't have any rebuttal because I MADE SURE to cover the expectations before sending over the SOW.
Develop your investigation plan based on what the customer wants. Restate their goals to them to ensure there have not been any miscommunications. Apply the Alexiou Principle to each of the goals, and get working - the clock is ticking.
Thursday, April 22, 2010
Command Line Goodness Part II
OK...so fortunately for me (and you), I am working a case right now that will help me to illustrate my point about using the command line perfectly. Now, let me preface these next few posts, and simply state that this is MY way of using the command line to parse data. There are SO many tools, and SO many different command switches, that you could literally skin the proverbial cat a dozen different ways. My way works for my purposes. If you have a command syntax that is more efficient, please let us know! I'm all about getting better!
Now, In this case, I have six images from a Point of sale (POS) network. My first goal is to find if I have track data in the clear on any of the images. Since this the fraud in this case is "card present", meaning that the bad guys jacked track data and used it to create new cards, I am anticipating finding some. For the purposes of data reduction, I JUST want to work with the systems with clear text track. So...I mount my images read only with ImDisk (This is pretty basic, so I am not going to cover how to do this in this post. Basically, you just need a single raw image, since ImDisk will not work with split images.) Once mounted, I use this command:
z:\>egrep -r "\;?[0-9]{12,19}[\=][0-9]{12,32}\.?" * > c:\cases\track2hits
This regex will provide me with all of the matches, along with their full paths. Now, I anticipate finding data in log files, or backup files. However, what I am looking for is a totally abnormal location. For example, in this case, I found a file we'll call "winprc.dll". Now, dll files should NOT contain track data...at least none that I have ever seen, so this is automatically extremely suspect and likely a dump file for a credit card sniffing malware. How do I know this?
Well...think about it for a second. You have track data...in a dll...which should absolutely not be there. Something put it there...it had to to get there in the first place. So, in less than 30 minutes, I know can make the logical ju mp to the fact that I have an intruder, I have malware (since I have a dump file), and I will logically have to have an exfiltration point....bad guy has to get his goodies off the network so he can make his counterfeit cards right? All this from a single regex...pretty kewl huh.
Now, I can start creating my "dirty word list" or set of keywords to search on later. The name of this dll is now at the top of my list.
OK...so next, I am interested in who connected to this box. So, I export my event logs in hopes of finding some IP addresses. Once I export them, I convert them into flat text files with Event Log Explorer and stick in them my working case directory.
Now, I JUST want the IPs from the log s...nothing else. Now, since I am working with customer data, I am not going to show the actual event logs, but here is a screenshot of the event logs from my local machine.
OK...a quick check with word count and I see that I have 2394 lines in JUST this one log. (cat filename | wc -l). Now, I could export the logs to a csv and go through it in a spreadsheet, but that would require me to manually pick out IPs. WAY too time consuming. I want answers now. So...back to my regexes. I can use the regex for IP addresses and let's see how much smaller we can make this sample.
egrep -o "\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b" | sort | uniq
SO...this regex pulls out anything that matches an IP address, the "-o" option shows me ONLY the hits for the regex (as opposed to the entire matching line), "sort" puts them in numerical order, and uniq removes the duplicates. Leaving me with this...
0.0.0.0
10.32.8.162
10.96.33.21
10.96.33.23
192.168.40.2
2.6.1.62
255.255.255.0
5.3.1.0
82.0.174.0
82.0.188.0
A whopping 10 IP addresses...or at least what appear to be IP addresses, but that' for me to figure out. Now again, this is not the data from the images, but from my local machine, but it clearly illustrates my point. I went from over 2000 lines of log files, to 10 in a few seconds by using the command line. Now, if you want to get a count say of the number of time each IP appears, simply add the -c (for count) option. In this example, my results looked like this...
12 0.0.0.0
2 10.32.8.162
3 10.96.33.21
2 10.96.33.23
6 192.168.40.2
3 2.6.1.62
6 255.255.255.0
1 5.3.1.0
1 82.0.174.0
1 82.0.188.0
The number off to the left shows the number of times each IP appears in the log. Pretty slick.
Now, you can use these commands to parse anything...not just IPs! In my current case, working with these two commands gave me an idea of what was going on, and which IPs may have interacted with this system, all in under 30 minutes. Not going to solve the case by any stretch, but as you can see I can perform significant data reduction using these methods.
In my next post I will cove how to use cut and awk to carve more complex log files to extract JUST the data you want.
Now, In this case, I have six images from a Point of sale (POS) network. My first goal is to find if I have track data in the clear on any of the images. Since this the fraud in this case is "card present", meaning that the bad guys jacked track data and used it to create new cards, I am anticipating finding some. For the purposes of data reduction, I JUST want to work with the systems with clear text track. So...I mount my images read only with ImDisk (This is pretty basic, so I am not going to cover how to do this in this post. Basically, you just need a single raw image, since ImDisk will not work with split images.) Once mounted, I use this command:
z:\>egrep -r "\;?[0-9]{12,19}[\=][0-9]{12,32}\.?" * > c:\cases\
This regex will provide me with all of the matches, along with their full paths. Now, I anticipate finding data in log files, or backup files. However, what I am looking for is a totally abnormal location. For example, in this case, I found a file we'll call "winprc.dll". Now, dll files should NOT contain track data...at least none that I have ever seen, so this is automatically extremely suspect and likely a dump file for a credit card sniffing malware. How do I know this?
Well...think about it for a second. You have track data...in a dll...which should absolutely not be there. Something put it there...it had to to get there in the first place. So, in less than 30 minutes, I know can make the logical ju
Now, I can start creating my "dirty word list"
OK...so next, I am interested in who connected to this box. So, I export my event logs in hopes of finding some IP addresses. Once I export them, I convert them into flat text files with Event Log Explorer and stick in them my working case directory.
Now, I JUST want the IPs from the log
OK...a quick check with word count and I see that I have 2394 lines in JUST this one log. (cat filename
egrep -o "\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b"
SO...this regex pulls out anything that matches an IP address, the "-o" option shows me ONLY the hits for the regex (as opposed to the entire matching line), "sort" puts them in numerical order, and uniq removes the duplicates. Leaving me with this...
0.0.0.0
10.32.8.162
10.96.33.21
10.96.33.23
192.168.40.2
2.6.1.62
255.255.255.0
5.3.1.0
82.0.174.0
82.0.188.0
A whopping 10 IP addresses...or at least what appear to be IP addresses, but that' for me to figure out. Now again, this is not the data from the images, but from my local machine, but it clearly illustrates my point. I went from over 2000 lines of log files, to 10 in a few seconds by using the command line. Now, if you want to get a count say of the number of time each IP appears, simply add the -c (for count) option. In this example, my results looked like this...
12 0.0.0.0
2 10.32.8.162
3 10.96.33.21
2 10.96.33.23
6 192.168.40.2
3 2.6.1.62
6 255.255.255.0
1 5.3.1.0
1 82.0.174.0
1 82.0.188.0
The number off to the left shows the number of times each IP appears in the log. Pretty slick.
Now, you can use these commands to parse anything...not just IPs! In my current case, working with these two commands gave me an idea of what was going on, and which IPs may have interacted with this system, all in under 30 minutes. Not going to solve the case by any stretch, but as you can see I can perform significant data reduction using these methods.
In my next post I will cove how to use cut and awk to carve more complex log files to extract JUST the data you want.
Tuesday, June 23, 2009
Trust
So, as you are probably aware, I am working on a case right now that has an interesting pair of malicious binaries. In a previous post, I stated that I was not able to get one of the binaries working either in a VM or on my dirty box. Well, after re-reading that post, and sleeping on it (or at least trying to), I couldn't stop thinking about it...something was not sitting well.
My instincts told me that I was missing something. So rather than simply dismissing it, or chalking it up to indigestion (which I hear Peanut Butter Cup cereal will do to you), I got out of bed at 0400, started the coffee pot, and decided to trust my instincts.
After trying to run the malware again unsuccessfully, I realized that I had not "Googled" the error message. That is something I usually would not have forgotten, but for whatever reason, I had. So I did...and what came back had something to do with the Microsoft .Net framework. I then found the download page from MSDN (which if you don't have bookmarked, you REALLY should) and grabbed "dotnetfx.exe" - let's remember that name for later (in a post I am working on for tomorrow)! So, I ran the executable, installed .Net v2, and kicked off the malware again. This time NO ERROR! While I was not sure what it was doing that this point, I was confident it was doing something as the error message that I had become so accustomed to was no longer plaguing me! The point here is that I trusted my gut...something was not sitting right and I was determined to find out what...which I did! And THAT ended up being HUGE in this case!
Next, I fired up Process Explorer and restarted the malware. It appeared for like a second...maybe two, then disappeared. Well, I had already opened the binary in both a hex editor and PEDump without any interesting results. I had to get at the process as it ran! I tried to dump RAM, but I couldn't do it quickly enough to catch the process as it ran. After about 45 minutes of launching the binary (which I could do from the cmd line) and trying to click on the process when it popped up in Process Explorer, I got it! What I saw in the strings as the process ran in memory was that it was trying to open and FTP connection to a remote IP address...AND...it gave me something that looked a whole lot like a username and password. Again, by trusting my instincts, I not only got the malware working, but I got an IP, a username, and password (later validated by the USSS...so I can state with confidence that I got it!)
So as I sat on my back porch celebrating, my neighbor (Glen Painter) came over. As I talked to him about my victory, I told him I still had one question. The malware definitely FTP'd the customer data off the network, but how did it get it in the first place? Well, my neighbor happens to be a very good .Net Developer. So we downloaded the free version of Red Gate's .Net Reflector and decompiled the binary into C#. By taking this last step, I was able to see that the malware was listening on the TCP port that the Point of Sale (POS) software used to transmit credit card numbers from the POS terminals to the back of house (BOH) server. As it listened, it created a file that contained the results of the traffic sniffing! This file format was the exact same as the format of the files on my forensic image that I suspected were being exported! By trusting my friend, I was able to learn something new, put a new tool in my arsenal, and really bust this case wide open. Thank you GLEN!
In this particular situation, the technology was not my obstacle...it rarely ever is. Truth be told, I hit a rut. I thought what I had done was good enough, and I was prepared to go on. So that made me wonder...how many other investigators do the same thing? Get stuck on something, but instead of waking up at 0Dark30 and knocking it out, they slap whatever they have into their report and call it a day.
I also have to give credit to Harlan. He was up around 0500, and I was able to bounce some ideas off of him. This brings me to my last point...trust your friends (#2). Look, we have a tough job. Every case I get is difficult in some way, but that's what makes it fun. It's a challenge! The key is to look that challenge straight in the eye, and kick it in the teeth...not fold at the first sign of adversity. Having a trusted friend that you can bounce your thoughts off of is a great tool. You need someone you can talk candidly to, who will tell you when you are way off, and who you won't lose any face with when you make mistakes.
Since Harlan and I don't work together anymore, we obviously don't share customer data, so we just stick to the forensics. After about 30 minutes of taking to him, feeling a bit sheepish a time or five, and gathering my thoughts, I was back on track, and able to find what I was looking for and then some.
Look, if you don't get woken up in the middle of the night thinking about case work, I will go out on a limb and say you may be in the wrong line of work. I have solved many many cases between the hours of midnight and 0600 when something was bothering me so much that I couldn't sleep...I HAD to figure it out. I'm sure there are investigators out there, who can be in the middle of difficult case, have some unresolved issues...throw some hash sets around hoping for a hit, and when they don't get anything they go to bed and sleep like babies. I am just not one of them.
Trust your instincts, Trust your friends, and Trust your abilities. Trust really is one of the best tools in your toolbox!
My instincts told me that I was missing something. So rather than simply dismissing it, or chalking it up to indigestion (which I hear Peanut Butter Cup cereal will do to you), I got out of bed at 0400, started the coffee pot, and decided to trust my instincts.
After trying to run the malware again unsuccessfully, I realized that I had not "Googled" the error message. That is something I usually would not have forgotten, but for whatever reason, I had. So I did...and what came back had something to do with the Microsoft .Net framework. I then found the download page from MSDN (which if you don't have bookmarked, you REALLY should) and grabbed "dotnetfx.exe" - let's remember that name for later (in a post I am working on for tomorrow)! So, I ran the executable, installed .Net v2, and kicked off the malware again. This time NO ERROR! While I was not sure what it was doing that this point, I was confident it was doing something as the error message that I had become so accustomed to was no longer plaguing me! The point here is that I trusted my gut...something was not sitting right and I was determined to find out what...which I did! And THAT ended up being HUGE in this case!
Next, I fired up Process Explorer and restarted the malware. It appeared for like a second...maybe two, then disappeared. Well, I had already opened the binary in both a hex editor and PEDump without any interesting results. I had to get at the process as it ran! I tried to dump RAM, but I couldn't do it quickly enough to catch the process as it ran. After about 45 minutes of launching the binary (which I could do from the cmd line) and trying to click on the process when it popped up in Process Explorer, I got it! What I saw in the strings as the process ran in memory was that it was trying to open and FTP connection to a remote IP address...AND...it gave me something that looked a whole lot like a username and password. Again, by trusting my instincts, I not only got the malware working, but I got an IP, a username, and password (later validated by the USSS...so I can state with confidence that I got it!)
So as I sat on my back porch celebrating, my neighbor (Glen Painter) came over. As I talked to him about my victory, I told him I still had one question. The malware definitely FTP'd the customer data off the network, but how did it get it in the first place? Well, my neighbor happens to be a very good .Net Developer. So we downloaded the free version of Red Gate's .Net Reflector and decompiled the binary into C#. By taking this last step, I was able to see that the malware was listening on the TCP port that the Point of Sale (POS) software used to transmit credit card numbers from the POS terminals to the back of house (BOH) server. As it listened, it created a file that contained the results of the traffic sniffing! This file format was the exact same as the format of the files on my forensic image that I suspected were being exported! By trusting my friend, I was able to learn something new, put a new tool in my arsenal, and really bust this case wide open. Thank you GLEN!
In this particular situation, the technology was not my obstacle...it rarely ever is. Truth be told, I hit a rut. I thought what I had done was good enough, and I was prepared to go on. So that made me wonder...how many other investigators do the same thing? Get stuck on something, but instead of waking up at 0Dark30 and knocking it out, they slap whatever they have into their report and call it a day.
I also have to give credit to Harlan. He was up around 0500, and I was able to bounce some ideas off of him. This brings me to my last point...trust your friends (#2). Look, we have a tough job. Every case I get is difficult in some way, but that's what makes it fun. It's a challenge! The key is to look that challenge straight in the eye, and kick it in the teeth...not fold at the first sign of adversity. Having a trusted friend that you can bounce your thoughts off of is a great tool. You need someone you can talk candidly to, who will tell you when you are way off, and who you won't lose any face with when you make mistakes.
Since Harlan and I don't work together anymore, we obviously don't share customer data, so we just stick to the forensics. After about 30 minutes of taking to him, feeling a bit sheepish a time or five, and gathering my thoughts, I was back on track, and able to find what I was looking for and then some.
Look, if you don't get woken up in the middle of the night thinking about case work, I will go out on a limb and say you may be in the wrong line of work. I have solved many many cases between the hours of midnight and 0600 when something was bothering me so much that I couldn't sleep...I HAD to figure it out. I'm sure there are investigators out there, who can be in the middle of difficult case, have some unresolved issues...throw some hash sets around hoping for a hit, and when they don't get anything they go to bed and sleep like babies. I am just not one of them.
Trust your instincts, Trust your friends, and Trust your abilities. Trust really is one of the best tools in your toolbox!
Tuesday, March 30, 2010
Timeline Analysis Part 4 : Timescanner
In our last episode of Timeline Analysis, we covered the magic that is “log2timeline”…thank you Kristinn! The question I left y’all with (remember, I do live in Oklahoma) is, “How great would be if we had a tool that would leverage the log2timeline-y goodness, but not require you to feed it the local system logs”? I told you such a tool existed, and told you it was called, “Timescanner”. In this post, we will cover this tool.
Timescanner is another tool written by Kristinn, and does exactly what we talked about…it searches the target (either live file system, or mounted forensic image) and searches for the types of log files supported by log2timeline. It then parses those files and add them into the body file, which we would ultimately use to generate our timeline. Let’s take a look at how the tool works.
Again, this is a Perl script written natively in Linux. Getting it working on my Windows XP box with Active Perl 5.10.1 was no proverbial walk in the park. It only took me a few hours of updating perl modules (.pm)s and various other dlls. One thing you will absolutely need to install in “WinPCAP”. Before even starting to try to get all of the pms for Timescanner, go grab it and install it. It will save you some headaches in the long run.
Recall from my last post, that whenever you run a Perl script for the first time, it’s a good idea to determine which modules you may need to load. So to do this…you might try something like this…
C:\tools\log2timeline> more timescanner (If you prefer, can you just open the script with any text editor)
This will give you a full text listing of the Perl script, but the section we are really interested in is this…
Now, this is not to say that these are ALL of the .pms you will need, but making sure these are installed properly will minimize the amount of tweaking you will have to do to get the scrip working.
Once you have your .pms loaded, you care ready to kickoff Timescanner.
The syntax is pretty basic and will look like this…
C:\tools\log2timeline> perl timescanner –d C:\
I skipped the –z option for timeZone, since I am in the central time zone, and I don’t need to make any modifications. However, if you are working a case in one timezone, and your evidence is from a different timezone, this will be a useful option. To see which timezones are supported, simply use this command…
C:\tools\log2timeline> perl log2timeline –z list
OK…so really…all you have to do it run this command…
C:\tools\log2timeline> perl timescanner –d C:\ > bodyfile4
..and timescanner will do the rest! Then, you simply use mactime again to generate the timeline and you will have added to your timeline, all supported log file types from the target drive/image!
Here is a snippet of my timeline…
Here you can clearly see my actions for the day! From what news I was reading from the BBC to creating the file I am using to write this blog entry…all right there!
So, what’s even cooler is that I now have a file that is also fully searchable!
Let’s say I wanted to see the activity from May 11th, or May 10th? Or what about hits for certain keywords like “pinball” or “DEFCON”? Well, just use grep and you can find them right away! Like so…
Now, the screenshot I provided above from MS Excel has been slightly modified to enable you to see the full paths of what Timescanner will report on. I simply highlighted the fields I did not want to see, right clicked on them, and selected “hide”. To get them back, just right click and select “unhide”.
So now, all you would have to do to create a Super Timeline is to simply use the same bodyfile as your output for each of the tools, then use that bodyfile as the input for mactime. It should be noted that this entire process, from the first time you run FLS, to the final compilation of the timeline with mactime, should take less than an hour. So as an investigator, what is that worth to you in terms of how quickly you can generate a full timeline of your suspect system and how much data is actually available to you? My answer is, “a whole freaking lot”!
If you are one of those investigators who are constantly on the search for a “silver bullet”, then I am sorry to disappoint you, but this is not it. There is not “Forensicator Pro” (hehe….thanks for the good joke though Ovie/Brett), there is no “Find All Evidence” button, and “X” never ever marks the spot. What this WILL do for you is give you a clear snapshot of the status of the system at any given, and stored, point in time. It is a tool for generating data points by which you can build your theory of the incident based on the available evidence. Tools should never replace sound logic, forensic methodology, and due diligence.
In addition to my instructions provided on my blog, these tools (and many others) are precompiled and freely available in the SIFT Workstation v2.0. It is a FREE VM image that can be downloaded from the SANS website that I’m certain you will find very very useful. A word of warning though, this image is Linux based, so if you are not comfortable using the command line…well…you need to get that way. May of the more powerful tools out there do not have GUIs, and for good reason. There is no joy or glory is being a “push button Monkey”…and frankly, you can be a very thorough investigator if all you know how to do is click on buttons predefined by somebody else. No offence to anyone, but if you truly want to get better at being a forensic investigator, you really need to become comfortable with the command line.
Hmmmm….sounds like another idea for a blog series?!?!?!
Subscribe to:
Posts (Atom)