Pages

Friday, September 14, 2012

Network Forensics Books


-VS-


Recently, I picked up a copy of both "Network Forensics: Tracking Hackers Through Cyberspace" by Sherri Davidoff and Jonathan Ham and "Mastering Windows Network Forensics and Investigation 2e" (MWNFI) by Steve Anson, Steve Bunting, Ryan Johnson and Scott Pearson.  Coming off of host-based forensic stint for the first half of the year I was looking to advance some skills and pick up some more knowledge on network forensics.  Both these books came out this year and have some good offerings.  

I first read MWNFI and thought it was pretty good.  It was a quicker read for me as I felt a lot of it rehashed a lot of Harlan Carvey's Windows Forensic books.  So if you've read those this is a good refresher.  If not it's a good way to start learning digital forensic knowledge.  The book has a good layout and explained things clearly with scenarios and example data.  I feel the book really gave me the most value in its chapters and references for Windows event logs.  It provides a great reference for various Windows event logs to check for and variations in codes that may appear in that log.  It also does a decent job on touching how to present some of the investigation data.  However, I would say this book is better at explaining Windows forensics than it is in net forensics.  So, I found it disappointing in that regard.

Network Forensics, on the other hand, was exactly what I wanted.  This book covers network forensics superbly!  The authors break down each facet of network investigations from covering the fundamentals and then diving into the technical aspects of the investigation process from devices you may encounter to protocols.  You will learn how to go from capturing evidence, to analyzing the data and finally how to interpret it and place it in context for your needs.  Every chapter provides a lot of knowledge and you can tell the authors have a lot of practical knowledge that bleed into the text.  They provide analysis examples with a Case Study at the end the chapters.  Which was a great way to summarize the chapters in my opinion.  It was fun because you're tracking malicious activity while you're reading and they break it down in a technical matter that is easy to follow.

I would say MWNFI is a good reference to have; but if you're already up on recent Windows forensics you won't find a lot of value in the book.  I honestly keep it because of the event log reference.  Network Forensics, to me, is a must for anyone.  It's an invaluable reference source for the topic.  I will probably end up going back to it throughout the years as it covers a lot of stuff I have not seen yet, it's incredibly technical and easy to follow.  I have faith you will not regret the decision to buy the book.


Thursday, August 2, 2012

Customizing AlienVault's OSSIM Plugins


So, I have been playing a lot with the Open Source SIEM product known as OSSIM, from AlienVault.  I have been using it from version 2, mainly with version 3, and now up to the newest version 4.  In that time I have gone through a lot of frustrations, but I have come to start really enjoy the product.  I should state that I just finished my training in San Francisco and will shortly be certified as an AlienVault Certified Security Analyst and Engineer, so this post may be slightly biased as I just learned fully how the product works and interacts and I am still really excited about it all.  To this date I would say one of OSSIM’s greatest strengths is it customization and features.  I really enjoy the fact that at its heart it is a lot of open source tools pieced together interacting in harmony to give you essential visibility in your network.  I will say its weakness, if you consider it that, is the difficulty in the configuration (something I know they are focused on resolving as 4.0 is a big step in the right direction).  However, I feel the difficulty in configuration is somewhat of a strength for implementation.  It forces to the administrator to become intimately knowledgeable with the SIEM and customize it for their environment; something I feel any security professional would admit is essential for a SIEM.  The downside to this is that it takes a lot of time and man hours to implement a system like this on a very large network, which is why I originally state it’s a weakness but it’s all perspective.

Architecture


A bit of a background on how OSSIM is going to work, it essentially consists of four main components:  sensor, database, framework and server.  There is also a logger portion that is provided in the professional version, it’s optimized for long term storage on an indexed database; however, I will not be talking about it (but it’s very cool I suggest you check it out).  The sensors are going to be placed closest to devices you want to monitor; these are going to handle the inputs sent from devices, mostly logs, as well as provide you with tools to use like snort and OpenVAS.  The database is going to be the central storage of these events, which allows for a lot of the cool features you’ll see from the server.  The server is essentially the engine behind a lot of the action going on.  It handles the vulnerability assessments and correlation of the events in the database.  The framework is to tie everything together in your mostly easy to use web-interface. 

So for an example you have a LAN segment you need to monitor.  You would send your firewall/switch logs to OSSIM via syslog most likely and mirror or tap traffic to send to a second network interface to be assessed by snort.  This is handled by the sensor; you would specify the logs to go into a separate log file and have plugin to monitor that log file continuously.  Snort is assessing the interface you selected to be in promiscuous mode and analyzes traffic as, I am assuming, you’re familiar with.  Now the plugin catches events either pre-defined in provided plugins by OSSIM or however you specify in a custom plugin as I will show later.  These events and events generated by snort are then entered into the database.  The server is connected to the database and then will start correlating these events, again on either predefined specifications defined by AlienVault or by you.  So to put it programmatically: 

If Event(A) = Outcome(A)      
Then Search For Event(B) Until Outcome(B) Or Timeout
            If Outcome(A) + Outcome(B) = Risk(High) Then GenerateAlert(e-mail|ticket) Else ExitLoop

Now correlation can go on for several events matching a chain of I think up to 10 events.  However, that complexity is kind of overkill and would be looking for events on par with something like APT most likely.  That is the main point of the server.  The framework is going to tie all these pieces and provide you with Web-Interface to utilize and search all this information.

Now the great thing about this architecture is distribution.  You can place sensors all over your environment and have those reporting to the other pieces as needed.  By default OSSIM will come in an all-in-one fashion which is a lot easier to set up and work with; but will only work for really small environments.  But, the ability for distribution really allows you implement on the larger scale.  One limitation of OSSIM is it cannot handle a lot of events per second, that is one of the perks of their professional version; however if you distribute it over a lot of machines you may be able to work around that limitation (do not recommend it though).

Customizing Plugins


The greatest thing I love about OSSIM is, once you get how it works, it’s pretty easy to customize how it works and customize it to your needs.  I will show the simplicity by providing my own experience and example.  I have been working with Cisco ASA’s for a while now and have been centralizing logs for some time.  I wanted a better way to interpret this data in an easier fashion then pouring through 1000s of logs a day, as I am sure many of you are familiar with.  This is when I found OSSIM, which has its own ASA plugin already available; but it didn’t provide a format I liked personally.  The message they provided for type of event was difficult to differentiate on the fly and did not anticipate for non-IPs in the logs, as in the ASA you can give IPs a hostname to easily sort through all the IPs you’ll see often with connection logs.  However, as I would soon find out, the destination and source IP fields can only populate an IPv4 address at this time; something I greatly hope they can alter and kind of expect to see with IPv6 support coming from what I’ve read on their forums.  So, if you want to see an easier to read name for an IP you have to disable the naming feature in the ASA, and then define that IP in your SIEM in the assets portion of the system.  So, lets dive into building a custom plugin for an ASA, but the methodology will translate to any log format you can populate. 

First you’ll need to configure your source to send logs to an OSSIM server, where they have syslog already listening for events by default.  However when we do that it’s just going to append that message to  /var/log/syslog which can create a lot of messages, so it would be ideal to separate logs from syslog and place them in their own file.  We can do this by creating a configuration file in /etc/rsyslog.d  so we can do this:
  • vi /etc/rsyslog.d/asa.con
  • Insert Line 1:  if $fromhost-ip == 192.168.9.101 then -/var/log/cisco-asa.log
  • Insert Line 2:  if $fromhost-ip == 192.168.9.101 then ~


Now, what this does is create a configuration file for your ASA, which rsyslog is configured in OSSIM to utilize any *.conf file you have created in that folder.  The first line says if the log comes from 192.168.9.101 (our ASA IP) then place that log in cisco-asa.log.  Line two matches the IP as well, but then states place that IP in only cisco-asa.log and not syslog as well.  Now you’re almost set here and have logs coming in, but first you’ll want to configure log rotation at /etc/logrotate.d/  Now for this plugin since it’s a standard syslog, I simply added the log file to the rsyslog rotation already enabled.  This is setup for rotating the log on a daily basis so your storage is maximized.

Now that you a defined log source, you can now build your plugin around that information.  Plugins are all stored in a central location at:  /etc/ossim/agent/plugins/  Here I will create a file called custom-asa.cfg   Take a look at the beginning portion of this configuration file:

;; custom-asa
;; plugin_id: 9010
;;
;; $Id: *-asa.cfg,v 0.2 2012/7/29 Mike Ahrendt
;;
;; The order rules are defined matters.
;;

[DEFAULT]
plugin_id=9010

[config]
type=detector
enable=yes

source=log
location=/var/log/cisco-asa.log
create_file=yes

process=
start=no
stop=no
startup=
shutdown=

This is a pretty straight forward implementation, you have a plugin ID of 9010 (all plugins 9000+ are saved for custom plugins).  Then you simply have that this is a detector plugin that is enabled.  Next we define that our source file is a log that is in the location we created earlier, and if necessary can create the file.  The next portion is not really relevant to our purpose, but is utilized by plugins for tools that are incorporated in OSSIM.  For instance the OSSEC plugin has processes tied to it, so when the plugin is ran it can start the OSSEC process via the plugin automatically.  Again, this is not needed for us.  Also note that ;; is a form of commenting your plugins and not necessary just kind of helpful.

Now, for the really fun part of the plugin creation process, REGULAR EXPRESSION!!!!  Admittedly, I knew nothing about regular expression and after learning to build these plugins I have learned what I am really missing.  If you’re not already familiar with regular expression you should keep a cheat sheet available (I recommend this one: http://www.cheatography.com/davechild/cheat-sheets/regular-expressions/).  The next part of the plugin is reliant upon building regular expression around common format log files.  So looking at this log we would see something like this:

            Jul  2 10:23:00 192.168.9.101 %ASA-0-106100: access-list 129-network_access_in denied tcp 129-network/198.110.72.148(61388) -> Secure-135/ DB-136(1521) hit-cnt 1 first hit [0xbbdcff06, 0x0]

Now we need to build a regular expression to match this input for all logs.  Starting with the date, it is pretty easy.  We have Jul 2 10:23:00 so our regular expression looks like this \D{3,4} (not a number for 3 or 4 characters) \s (space) \d\d (two digits) : \d\d : \d\d put together we have, with the defined variable the AlienVault plugin:

            (?P<date>\D{3,4}\s\d\d:\d\d:\d\d)

Now for the IP Sensor IP of 192.168.9.101, we build \d{1,3} (digit of 1 to 3 digits in length) . \d{1,3} . \d{1,3} . \d{1,3}   Adding to the plugin now:

            (?P<date>\D{3,4}\s\d\d:\d\d:\d\d)\s(?P<sensor>\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})

Adding the ASA Syslog ID we input \s (space) exact %ASA- \d (one digit) - \d+ (digits until there is no longer a number) . (any character) \s  now our expression becomes:

            (?P<date>\D{3,4}\s\d\d:\d\d:\d\d)\s(?P<sensor>\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\s%ASA-\d-\d+.\s

Now for the non-standard stuff with variables for OSSIM, I matched access-list exactly then using \S+ (all non-whitespace until a space) for a variable. Now for these logs you will next see permitted or denied.  So I assign the next portion to a variable and we’ll see why that’s important in a bit.  Next you’ll see the defined protocol in a variable.  Then the network on which the transmission occurred, which I define as the interface in OSSIM.  Next I define the source IP and Port then destination IP and port.  All coming together as: 

            "(?P<date>\D{3,4}\s\d{1,2}\s\d\d:\d\d:\d\d)\s
             (P<sensor>\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\s%\D\D\D-\d+-\d+.\saccess-list\s
             (?P<msg>\S+)\s(?P<sid>\w+)\s(?P<proto>\w+)\s(?P<iface>\S+)\/(?P<src>\S+)\
             ((?P<sport>\d+)\)\s..\s\S+\/(?P<dst>\S+)\((?P<dport>\d+)\)"

In the plugin we will assign this to a rule like so:

[AAAA - Access List]
regexp="(?P<date>\D{3,4}\s\d{1,2}\s\d\d:\d\d:\d\d)\s(?P<sensor>\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\s%\D\D\D-\d+-\d+.\saccess-list\s(?P<msg>\S+)\s(?P<sid>\w+)\s(?P<proto>\w+)\s(?P<iface>\S+)\/(?P<src>\S+)\((?P<sport>\d+)\)\s..\s\S+\/(?P<dst>\S+)\((?P<dport>\d+)\)"
event_type=event
date={normalize_date($date)}
sensor={resolv($sensor)}
plugin_sid={tranlate($sid)}
src_ip={$src}
src_port={$sport}
dst_ip={$dst}
dst_port={$dport}
interface={$iface}
userdata1={$msg}

Now you may notice some interesting things in this plugin.  First note that I start the rule with AAAA, however you’ll need to assign plugin SIDs in numbers, the engine parses these rules alphabetically and using numbers makes for a difficult experience in processing your rules in the order you desire.  Therefore, I suggest you use letters to assign your rule names for the engine.  We also see that there are functions before some variables.  These are built into OSSIM and are a part of /usr/share/ossim-agent/ossim_agent/ParserUtil.py  There are several functions but the major ones are in this plugin.  Normalize_date is self-explanatory I believe.  Resolv will simply parse the IP and normalize it.  Translate is great if you have similar log messages.  If you’ll recall this log varies in the fact it varies at permitted or denied.  So with translate we take the $sid variable and it will read that variable and then translate it to something else via the translation portion of the plugin which looks like this:

[translation]
permitted =600
denied = 601
inbound = 603
outbound = 604

So you’ll see that the plugin will translate the word to either 600 or 601 which we will then use for the rule identifier.    Now this is just one rule of the plugin I wrote.  I have built a plugin to match 19 of the most common logs I have found so far.  Looking through ASA documentation, the ASA-\d-\d\d\d\d\d\d format is unique to each log type.  Specifically the first three digits in the 6 digit number are semi-generic to various types of events.  Example, if we see %ASA-6-212\d\d\d we will know that the plugin has something to do with SNMP.  So it would be possible to build events around those specifications, which is what I did for some rules but they were events that are non-standard for my environment.  So, I am seeing the events I just don’t get the granularity in the OSSIM interface as I do for the events that I really want to see.
Now that there is a plugin configuration created with all our rules, we almost have a working plugin.  Now we need to build a SQL file so that the database knows what the plugins are and will generate the event up a match.  Fairly simple, lets take a look at the SQL:

-- GRCC ASA Plugin
-- plugin_id: 9010

DELETE FROM plugin WHERE id = "9010";
DELETE FROM plugin_sid WHERE plugin_id = "9010";

INSERT IGNORE INTO plugin (id, type, name, description) VALUES (9010, 1, 'custom-asa', 'Custom ASA plugin');

INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, reliability, priority, name) VALUES (9010, 600, NULL, NULL, 2, 2, 'Access List Permitted');
INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, reliability, priority, name) VALUES (9010, 601, NULL, NULL, 2, 4, 'Access List Denied');

The first two lines are simple comments, and not required for the SQL file.  The next two lines are to delete possible redundancies from the database.  Next we insert the plugin ID to the database.  Now come all of our rules, we simply give it the database fields of plugin_id (which we assigned 9010), then the rule ID you want (from the translation table you’ll remember I assign these rules to 600 and 601), then you insert a category_id and class_id (not necessary so I’ve assigned them as NULL).  Now reliability and priority are pretty important.  This is how OSSIM will assess the risk posed by these events.  Something like a permit, not necessarily something to freak out about so I assign its priority to 2.  A deny however is more important to me so I assigned it a 4, as I want those to stand out more.  The name is self-explanatory, just a description of what the rule is.  We then create a custom-asa.sql file at /usr/share/doc/ossim-mysql/contrib/plugins/   Now all that is left is entering the SQL into the DB with a command, which there are a few options to execute from the sql plugin directory mentioned prior:
  • cat custom-asa.sql | ossim-db
  •  ossim-db < custom-asa.sql

Either command should work; I favor the latter form personally.  I did notice in version 3 sometimes it would take a few times before I would see the plugin come up in the setup interface.  However, in 4 it worked first time around with no problem.  We can verify that the plugin injected into the database properly by logging into the web interface.  Going to Configuration > Collection > Data Sources where we can then search for ID 9010.  It will look like this: 




There we have it!  Our plugin is registered within the database and recognizing the right rules.  We also will see in the console setup, by logging into OSSIM’s terminal and entering “ossim-setup” into our command line, then selecting “Change Sensor Settings” followed by “enable/disable detector plugins” we should see an option for “custom-asa” as well:


Now you simply add the check mark to the plugin and then hit OK and then you'll reconfigure the server through "ossim-setup".  And voila! We have what should be a working plugin.  But, how can we verify this you ask?

We troubleshoot our OSSIM  plugin with some ease.  You will need a few things:  a few consoles open (I suggest using PuTTY), a sample of the logs you are trying to parse, and some time.  First, you’ll want to open up three terminals.  I like to make it look something similar to this:


This will give you two streams of information to follow when you inject the sample log into the monitored log.  The agent.log will display messages regarding the plugin parsing and server.log will notify about added database messages.  Now we need to start injecting the sample into the cisco-asa.log.  Because the plugin monitors in real-time, you can’t simply throw a log in and parse it from the beginning you have to inject it into the process.  This is easily done, I recommend taking a sample from your already collected logs and perform a copy and name it something simple (in the screen above you may see I named my copy INJECTABLE).  Now once we have a copy we simply perform this command:  cat /var/log/INJECTABLE >> /var/log/custom-asa.log   When this is complete you will see that the agent log will start parsing all of the events and then the server log will show all the events that were added to the database.

So now we’ve gone through and turned those horrible logs we’ve seen earlier into this (sanitized) view:



As you'll see we have the a list with the signature we've created, the time, the sensor is the IP of the actual ASA, your source IP and Port with country if an external IP, destination IP and ports as well, your asset values and your associated risk.  The 0.0.0.0 is what occurs because I use non-standard IPs in my ASA configuration.  It converts the host name to 0.0.0.0; however, if you click into the event it will show the whole log with the proper information.  This is the point I wish OSSIM would change, but it's only for my own personal preference.  As I said, you can turn it off in the ASA and then assign the IPs you gave host names to an asset tag that will give you an even easier to read event in the SIEM.


As you can see OSSIM is pretty powerful.  I highly recommend you give a look, as I think it will be improving a lot in a short period.  You can go to the community AlienVault site, where OSSIM is hosted at:  http://communities.alienvault.com/community/.  You can find their documentation on building a plugin here:  http://www.alienvault.com/docs/AlienVault%20Building%20Collector%20Plugins.pdf.   Also, if you check out OSSIM and want to try my plugins you can download my current implemented SQL and configuration files.  I think they're pretty good, I have to update it a little bit to cover all the ASA log types and I also want to build more defined rules (but this is a a start to get you going and customizing for your own needs).  Also, now that I have more defined rules I will be able to build correlation rules for them; but more on that later.




Monday, July 2, 2012

DFIR SUMMIT 2012: A Look Back


     Last week was the SANS Digital Forensics and Incident Response Summit in Austin, Texas.  I have to say the summit was probably my favorite conference experience I have had thus far.  It was a great mix of networking and content.  Your days are filled with spectacular information and you are still provided with a lot of opportunity to meet new people and discuss.  Plus, if you're active in the #DFIR twitter space, then it was an excellent opportunity to actually meet many of the people who use it.  I would highly suggest that, if you the ability to attend the summit.  I hope to be back in the coming years.

     As I mentioned, days at the summit are filled with a lot of great content from the speakers at the conference.  I have to say my favorite presentation, personally, was When Macs Get Hacked from Sarah Edwards.  This was simply because it was something I have yet to really see or research and provided a great baseline of knowledge where to look for information and various tools to utilize.  This presentation went very well with Andrew Cases's talk on Mac Memory Analysis with Volatility.

     Nick Harbour gave an EXCELLENT talk on Anti-Incident Response, that I really enjoyed a lot.  His talk was pretty technical and provided a lot of insight into the mind of an attacker.  Jeff Hamm's presentation on Carve for Records Not Files provided a lot of good information that should be considered in an investigation.  Event records very well may be much easier to carve for than an entire event log file.  Where a file is likely to miss all the information, carving for a fragment of that information is a lot simpler and may be just as useful.

     Cindy Murphy, this years Forensic 4Cast Examiner of the Year,  gave an amazing keynote to open the summit.  I thought it was very interesting and insightful.  If nothing else, I think a lot of people left the talk inspired and proud to be a part of this community.  Mike Viscuso's ending talk on Security Cameras - The Corporate DFIR Tool of the Future was also very interesting and, at least personally, gave a lot to think about the future of investigations and what that brings with big data.

     This is just a small sample of what the Summit offered, after all there were two tracks going the whole time (I couldn't make it to everything).  The presentations are posted already on SANS website here:  http://computer-forensics.sans.org/community/summits.  I highly recommend that you go through and take a look for yourself.  I really enjoyed the Summit, meeting everyone was awesome and it was nice to be around people that share the same passion (it's reinvigorating).

Friday, April 27, 2012

My Education in Digital Forensics

     I have been in school awhile now, and was lucky enough to have a few classes with Mark McKinnon.  Mark, was kind enough to share his passion for the digital forensics field with not only me, but the hundreds of students who've attended his courses at Davenport University here in West Michigan over the last few years.  In many ways my many thanks go to him and everything he's been willing to share, and much of this post will kind of stem from his knowledge and suggestions he provided me with progressing into this field.  This will be a recap of how I went about learning about digital forensics, mostly pertaining to analysis of Microsoft Windows computers and, eventually, was lucky enough to get certified.  Also, I'm writing towards  the digital forensic interested people, not those in the field (although I would love to hear comments or suggestions for alterations to my following suggestions in the comments).

Disclaimer:
     First, there is a lot of great material available on digital forensics but you have to realize reading this books do not make you an expert.  That being said, I highly recommend getting as much hands on experience as you possibly can.  Many of the books I will be suggesting contain a list of tools they use or show output from tools. It's highly advantageous to download these tools and execute the same commands to analyze more practically what you're reading about.  Be prepared to get hands on with a lot of different software, and be prepared for mistakes and know that making a mistake is OK as it's all a learning experience.  Also, I'm not an expert!  Take my advice with a grain of salt.  I am just beginning in this field and want to share what I can.

Mentors and Involved Community
     That being said, let me get into it.  As I mentioned, I started my interest in digital forensics (DF) in seat at Davenport University in their IAAS 421 course, taught by Mark McKinnon.  This was an invaluable introduction to a lot of topics involved in DF from file systems, to registry and memory analysis.  If you are unsure about DF as a possible career, I highly recommend trying to find an intro course.  After taking the course I went from thinking as forensics as an interest to I wanted it to be my career.  Another reason I suggest taking a course is with the right teacher you can use them as a springboard into the field.  I quickly found Mark as a forensic guru who could point me in the right direction, and if he didn't know an answer he probably knew someone who he could get it from.  Too me, I think finding people you can bounce ideas off of is a great way to advance in this field.  I quickly got involved on twitter and started following people in the industry and began to frequent #DFIR searches.  This was a great way to figure out what was happening in the community and proved to link to a lot of great resources and blogs that I could reference for other things.

Books
     I started diving deep into forensics books, and per suggestion, I started with Brian Carrier's File System Forensic Analysis.  As you may have guessed this book is pretty much regarded as the holy grail of forensic analysis of file systems.  This book is highly technical, and for me at the time, was somewhat dry.  However, this book provides knowledge that will be called upon by almost every other book I'll suggest (most in fact reference it).  Therefore, I suggest you start here as it's an essential forensic knowledge foundation.

     Next, I picked up a copy of Handbook of Digital Forensics and Investigation.  This would be the first of Eoghan Casey's books that I read.  This book was recommended to me by Eric Huber on Twitter.  This book was a great reference and was a lot broader than Carrier's book, but it allows you better insight as to how the field is and what sort of artifacts to look for throughout an investigation.

     This is not how I read the following, but how I would now recommend reading these books as it will flow much better.  After finishing Casey's book, Mark McKinnon introduced me to the writing styles of one Harlan Carvey.  I started with Windows Forensic Analysis Second Edition (WFA2E) which is a great resource on Windows forensic artifacts.  I would then suggest reading Windows Registry Forensics as it'll delve deeper into the registry, where WFA2E will act as a great precursor for.  You'll learn more about the Windows registry than you probably think may be possible.  The next book I suggest is Windows Forensic Analysis Third Edition, as this will progress even further your understanding of Windows operating systems and will move into the more modern Windows versions, including Windows 7.  However, I will say before reading those three texts.  Start by reading Digital Forensics with Open Source Tools authored by Cory Altheide and Harlan Carvey.  I say this because it goes over a lot of artifacts for every system, but I suggest it more so because it goes over how to set up a lab machine and provides a great list of tools to utilize and install on your system that will allow you to do analysis without purchasing the more expensive software.

     I next chose to read Digital Evidence and Computer Crime, Third Edition: Forensic Science, Computers, and the Internet again by Eoghan Casey.  I chose this book for one distinct reason, as all of the other books were valuable in learning about the forensic artifacts available in an environment, as is this text, but Casey provides two chapters on the legal side of forensics.  These chapters provide a lot of great information on legal side of forensics in both the United States and European nations.  Another interesting aspect of the text is more of the psychological end of how a criminal acts when using digital devices.

Challenges
     Hopefully, while you're reading those texts you're following along with them and performing a bit of hands on work with each book.  Getting familiar with all of the different tools and how they work is one of the more fun things you get to do in forensic investigations.  Also, application testing and verification is a big part of the industry, so it's a good idea to get used to it from the beginning.  Two of the best things I have found to play with tools are the SIFT forensic workstation, this was made available from SANS and DEFT which are both free live Linux distributions which include tons of tools to play with and get familiar with.
 
     Once you've gotten used to your tools and read a bit, I suggest looking for forensic challenges.  You can find them from several area's, i started out with a few of my mates from college and we did the DC3 Cyber Crime Challenge, which is an annual competition put on by the Department of Defense.  Even if you don't want to submit challenges this is a great way to get some hand-on  work done, as you're often given an artifact to analyze and you have to give information regarding that artifact.  Challenges vary and can take a lot of time, but they are well worth it I feel if you're new to the field.

     Back to being involved with the community, there are many forums and mailing lists you can become a part of.  I suggest going out and once you have your feet wet with forensics a bit and become involved with them.  You can quickly learn the types of issues you can face on a daily basis within the forensic community. Sometimes you'll find a challenge presented there, I was lucky enough to win a SANS Lethal Forensicator Coin this way.

Development
     When I started my capstone for my bachelors degree, I was having a tough time to come up with what I wanted to do.  If you're not familiar a capstone, it is essentially a big project (150+) where you come up with some sort of product (paper/software/whatever) and then present that topic to a group.  Once again I leaned on Mark McKinnon, and he basically convinced me to make my own forensic analysis machine and software for quick triage of system.  Seemed like a lot of work and a big challenge, and it was; but it was worth it.

     Creating my own machine and triage script forced me to recall everything I had learned.  I had to know what tools to use and then validate those tools.  For the triage script, I had to know what artifacts are more relevant to an investigation and can provide actionable intel through quick analysis.  It also, got me into the world of computer programming, something I had never attempted before.  After my capstone project I turned the triage script into a pretty neat tool that I released as open-source, it's still in it's infancy but it's progressing nicely.

Stay Involved
     The biggest suggestion I can make?  Get involved and join the conversation!  It doesn't take a lot to get out and provide feedback or commentary.  If you look at my blog I post about once a month and probably on average about 5 times a week on twitter, something that takes maybe 3 hours of my time a month.  If you're out testing tools, provide feedback (things you like, didn't work or things you'd like to see).  They may not be seen by many but providing back to the community is a great way to stay involved and keeps you dedicated.  A great reason to stay involved, also, is because this industry especially evolves quickly with new applications that could produce a relevant artifact released almost daily.  Staying up-to-date on that stuff can mean a lot to an investigation, so it's important to at least keep a rough idea of what's going on in the wild; you shouldn't just stop your education.

     Also, if you're researching something interesting and come across an interesting artifact take a quick minute to share it.  Start a blog or something and share experiences!  If you look at my blog, I don't think I have put up a lot of stuff, but I like to think it's valuable at least to someone.  If you can share your failures along with your successes, as we can all learn together.

     Conferences are a great way to stay involved as well.  You can also meet a lot of great people this way.  I have only had the opportunity to sit in at a few conferences, but they've always been a blast.  Sometimes they can be expensive; however, you can think of them as an investment often times as networking within the industry is a great way of possibly getting jobs.  In my job now, I'm more likely to look at someone for an internship or whatever if I know they're keeping up and possibly have seen them at conferences or meetings I attend.  Often time you can find meetings for cheap, I am lucky enough to have several free meetings around me locally, even though they're not dedicated to forensics it's in the general realm of information security.  And if nothing else, you can sign on once a month and check out Mike Wilkinson's awesome idea of a monthly forensic meetup online known as DFIRonline.

How I Used This All
     From the time I sat in my first digital forensics course to today it's been about 18 months.  It was a long and a very fun process of learning all of this stuff.  During that time, while pursuing my bachelors degree I was lucky enough to get an internship in an information security office and then able to turn that opportunity into an analyst position where PART of my duties include forensics.  But, I was able to get sent to Florida for SANS 2012 where I took Forensics 408 or Computer Forensic Investigations - Windows In-Depth with Ovie Carroll and Lee Whitfield.  This opportunity was amazing!  The course covers in 6 days what I learned over the course of a year and a half and then some.  After reading all those texts and keeping up with events, I had learned a foundation to where everything was familiar.  However, the course will put it into context for you on how you'll use the information you used put it into an investigation and then report it properly.  If you get the opportunity, I highly suggest taking it.  After taking the course, I went over the text material they provide to you for a couple of weeks and took the exam weeks after the course.  After 18 months I went from an interested party to now a GIAC Certified Forensic Examiner.  It took a lot of time and dedication, but it has been a lot of fun and I can't wait to continue (NEXT is SANS FOR 508 and the GCFA! since they re-wrote it).  Also, I want to thank all the people who helped me get where I'm at, including all the previously mentioned authors, the great people on the #DFIR twitter realm, the people at SANS and especially Mark McKinnon.

     That's about all I have to say and share on the subject.  I hope you enjoyed reading, and I would love to hear other people's takes on this topic about what they did to get where they're at, as I'm not done with my journey and would like to learn from someone smarter than me.  :)

Tuesday, April 10, 2012

Review of Windows Forensic Analysis and Windows Registry Forensics

  

     Both "Windows Forensic Analysis (Third Edition)" and "Windows Registry Forensics" are authored by Harlan Carvey and he is the author of a few other books regarding digital forensics.  This will be a short review of both books.  I really enjoyed both of these books.  If you've ever read anything from Harlan, his writing style is very easy to follow and understand.  Each book is laid out in a manner that makes sense as far as being applied practically.

     Windows Forensic Analysis is the third installment to Harlan's Windows forensics books; however, as he says in the intro you should think of it as a companion to the second edition rather than a re-write replacement. This book includes all the latest and greatest information from the latest Windows 7 release.  Things like volume shadow copies, application analysis, and a summary of registry analysis provide great insight on Windows Artifacts.  Chapters on malware detection and timeline analysis are especially exceptionable.

      Windows Registry Forensics, I like to think of it, is an extension to Windows Forensic Analysis books.  The Windows registry is a treasure trove of evidence for analysis.  Registry forensics does an excellent job of not only outlining most of the artifacts that are known about, but gives you a background on available tools that can be used to analyze these artifacts.  The case studies are especially helpful in relating the discussed artifacts to practical experience.

      Both books are fantastic, and I would highly suggest adding them to your digital forensics library and put them next to at least the second edition of Windows Forensic Analysis.  Honestly, I feel like all three books should be considered one big compendium on Windows digital forensics.  I would also say that, at this point, there isn't a better collection of material on the subject of Windows analysis.  If possible, I would recommend setting up a lab with various Windows machines so you can test and play with all of the artifacts you will learn about.  Also, that will give you a chance to install the various tools mentioned in the text and test them out for yourself.

Thursday, March 1, 2012

File Tags and Digital Forensics


                So I was bored one day and decided that with school and work, I just wasn’t busy enough and I needed a new project.  I wanted to do some research, preferably in the realm of digital forensics.  I started talking to my buddy Rob Marmo (@robmarmo) and the idea of looking how Windows utilizes the tag properties within certain files came up.  Eventually, after some thought and consideration we decided that it would make for an extremely fun project that would make for a great booster for our experience.  As it ends up it was a great learning experience in doing research and developing a way to utilize the information.


Background

                If you are not familiar, Windows introduced the ability to “tag” files in Windows Vista.  This feature allows the user to add a desired keyword to certain file types so they could easily be categorized and searched within the Search function they included within Vista as well.  Here is an example of how you can tag your files:


Your other option for tagging your file is via the file properties option for the file.  If the file format supports tagging you will see the option available within the “Details” tab, like so: 


These file tags are a great way to organize information in a user customized way.  To me, that is why file tags are quite interesting from a forensic point of view, as these tags are inputted manually via the user’s input.  So it’s quite possible to say that if a file is tagged with a certain keyword it may provide that file with an added value of interest to an investigation.


How It Works

                After a lot of looking and failed avenues, I was finally able to get a handle on how Windows implements the ability to File Tag.  First, you may have noticed that I said only certain file types can be tagged.  I don’t deliberately state the files that are tagged because it is a variable.  When you begin the tagging process, simply put, the tags are inserted into an XML that is then inserted into the file.  How this is handled varies on the file type.  This determination is handled by reading the registry.  If you look at HKEY_CLASSES_ROOT\SystemFileAssociations in the registry, you will find a list of various file types registered within the operating system.  Each file type has two keys of interest for our purposes the “FullDetails” and the “PreviewDetails”.  Within these keys are several values, and the one for file tags is “System.Keywords”.  This value says there is a way for Windows to store the tags within the file.  The actual injection of the XML is done via a property handler that is based on the file type, often done via a DLL. 
            There is another part the file tagging system, beyond simply adding the keywords to a file.  As you recall, I mention that this implementation was intended to allow for quick searching of files by these keywords via the Windows Search function.  This plays an interesting point with the file tagging system.  As you enter in these keywords this creates an interaction with the Windows Search Index.  I created a quick animation GIF to show how the Search Index works as I understand it:

As you can see, the search index works with a data store.  Those data stores work with the Search function and filters, as well as a notification system.  If certain parameters are met they are then gathered and sent to the System Index, which is actually a database locally stored on the system at: 

C:\ProgramData\Microsoft\Search\Data\Application\Windows\Windows.edb *
*It should be noted that this  location can be altered via the Index Options in the Advanced options.

This is a interesting database and seems to be proprietary to the Microsoft Operating System and is utilized by a few of their applications.  If you’re interested in taking a look at the database, I was able to by doing the following:
  • Turn off Windows Search Service (This essentially unlocks the DB so you can use it)
  • Navigate to the Index location
  • Make a copy of the index EDB file
  • You can turn back on Windows Search Service
  • Download and install an EDB Viewer (I suggest EseDB Viewer from Woanware)
  • Open your copied EDB file in the viewer

Viewing the Search Index provides an interesting look at all the information that your Windows systems can analyze in a short amount of time.  As best as I can tell the Search Index database is utilized by the tagging system for the preview generation.  While you’re inputting a tag, often time you will find that upon entry once you type in a letter you will be given option of tags.  These are tags that have previously been applied to files, and from what I can tell these are pulled from the Search Index database.  The “PreviewDetail” key discussed earlier is how the registry knows you can get these tags via preview and then the property handler works with the index. 


Interest in Recovery

                Again, each file type handles tag in a different way; it is dependent upon the property handler assigned to it.  How these handlers deal with the data and inject it into the files is different, and through my testing of various files types and how they dealt with the file tags I came across an interesting discovery.  Some of file types store tag data not only within the file XML but also in various parts throughout the file.  In testing I was able to see when tags were added or modified, and even if the file tags have been deleted (or not viewable by the OS as Windows will only read tags from the XML), they are still located within the file and viewable within the hex.  Now, this only occurs in certain file types with, dare I say, inefficient property handlers.  Looking at the new Office formats like .docx it handles XML with a higher proficiency it writes most all its properties to XML and then archives it and then is read via Word or whatever.  To me that makes for much more efficient way to deal with files.  However, when we look at something like a .jpeg, it writes the tags to the file in different locations based upon the interaction.  Forensically, this provides an investigator with an added way to look at a file.  My thought was if you have a file that has a MAC timestamp of all the same times exactly, but you see that within the file that it has indications that tags were added or modified it may indicate that the file timestamps may have been altered.


Future

                I am still in the research phase with this information, but this is everything I have gathered thus far.  I have developed a proof of concept application that is working and pulling files that have been tagged and readable by the OS.  It’s still in development, and I plan and getting it out to the community eventually once I have it optimized and have added all the features I wish to include.  Also, you may be wondering how I came to acquire this information, so I am planning on posting a research and implementation article as well that will describe the research I did in a fair amount of detail with pertinent examples and such.  It may also include how I learned to program the tool I am developing as well.  I think explaining the thought process behind research and development may be beneficial to the community and hopefully inspire others to do the same by providing some background and basic thought process.


Hope you enjoyed this, and if you have any thoughts on the implications of file tags and how they can be utilized in an investigation I would love to hear them.  Leave a comment or e-mail me at:  michael.ahrendt@gmail.com

Wednesday, February 15, 2012

Review of Digital Evidence and Computer Crime


            Just finished “Digital Evidence and Computer Crime:  Forensic Science, Computers and the Internet” by Eoghan Casey and featuring other contributing authors, and it’s quite good.  I bought this book because I wanted an all-encompassing book that provided insight on the various aspects of an investigation, especially the legal portion.  And in this aspect the book does an excellent job, and is in-depth in area’s I have yet to see in other books.  The book is divided into five portions digital forensics, digital investigations, apprehending offenders, computers and network forensics.  For me the book was worth it for the first three portions; however, the computers and network portions, while a good start, there are more in-depth books that provide better insight. 

            Part I: Digital Forensics, was one of my favorite parts of the book.  It provides the reader with a good background on where digital forensics comes from and how it has evolved.  It details the role of the investigator in a case and the complications with digital evidence (the portion applying to levels of certainty was very enlightening).  I really enjoyed the portions of the book relating to both US and European law.  This was an aspect I was looking to learn more about and the book provides a great overview while outlining the specific important parts of popular cyber law. 

            Part II:  Digital Investigions, is all about the process.  Casey does a good job of applying the tradition scientific method to the digital forefront.  Applying it in this way it provides an easy to apply method to the investigative process.  Not focusing on the specifics but more the outline of the thought process, which allows you to go beyond knowing the specifics.  Methods for conducting investigations, handling crime scenes and reconstruction are discussed, as well as, going into motives.

            Part III:  Apprehending Offenders, was rather unexpected when I looked through the table of contents and even more so when I read the chapters.  However, in this case unexpected was excellent.  Various scenarios of need of investigation are discussed like cyber stalking and computer intrusions, and then delve into the victimology of the scenarios.  This was really interesting to me, as it provides a psychological aspect to the investigative process; something I then realized can really help with an investigation.

            Part IV and V:  Computers and Networking are pretty much what I expected.  The computer portion really does give a great foundation of knowledge, and if this is one of your beginning journeys it’s a great place to start.  It does go over the background of important artifact information like file system structure, basics of file recovery, browser artifacts, and the registry.  It also provides good info on Unix and Mac systems.  The network portion is quite detailed describing the various layers of the network topology. There is a lot of great information in these chapters that was a great review of knowledge. 

            Overall, the book was enjoyable from start to finish and I would recommend it to anyone looking for a great overview of digital forensic investigation process from start to finish.   I am happy to add this book to my growing reference library.  


Coming Up:

So, I have a lot going on.  I have the following books to read (expect reviews):

  • Windows Forensic Analysis 3rd Edition
  • Practical Malware Analysis
  • Digital Triage Forensics
  • Windows Internals 6th Edition
I also have some research that I wish to share regarding File Tagging, with maybe a tool to follow eventually.  So look for that as well.  

Monday, January 16, 2012

Automated Triage Utility

A New Utility
      Well, it has been awhile since my last post.  I have been busy finishing up Capstone course work at Davenport University.  For my Capstone project I selected to focus on digital forensics and created a workstation for evidence examination with a Windows 7 host.  On top of that, I elected to create a script that would perform basic triage functions with known commands and utilities.  I developed the script with the AutoIt language based on a recommendation from a friend.  The course allowed me to develop a proof-of-concept application that did quite a bit, but it did it very poorly.  So a few long nights later, I re-did it all and made it work a bit better and do a few more interesting things, discussed later.  After reading Corey Harrell's recent blog post about his new script, I decided I would share my tool as well since it's a small way I can contribute to the community I love.

I've posted the project on Google Code here:  http://code.google.com/p/triage-ir/

The Requirements
     As I mentioned previously, the script I created utilizes other applications to function.  First off, it utilizes your standard 'cmd.exe' from the Windows system (found at C:\Windows\System32).  Eventually, I hope to make it so it doesn't need a copy of the command prompt in the folder but the syntax in the script does not seem to be working properly at this point.So the application folder will look something like this:


You will notice that there is also a tools folder.  This, obviously, will be where I have the tools required for the script stored.  Unfortunately for licensing reasons, I do not include the tools needed.  The tools are free, so you can download them as follows:
This is the structure of the Tool folder as it should be seen, or at least similar:



The Function
     The script is designed to perform basic triage commands, as well as acquire evidence automatically on the system.  I designed the script to be ran from a flash drive, but you can really run it from anywhere.  All reports and evidence will be collected in the script directory under a Incident folder with a time stamp ("mm-dd-yy Incident").  The tool should perform the following functions:
  • Gather Information on
    • System Information
    • Running Processes
    • Services Information
    • NTFS Information
    • Mounted Disks
    • Directory Structure
    • Scheduled Tasks
    • AutoRun 
    • Account Settings
    • Logged in Users
    • IP Configuration
    • Routes
    • Active Connections
    • ARP
    • DNS
    • NETBIOS
    • Network Shares
    • Shared Files
    • Connected Sessions
    • Workgroup PCs
  • Capture Evidence
    • Prefetch
    • Recent Folder
    • Jump Lists (Windows 7)
    • SYSTEM hive
    • SECURITY hive
    • SAM hive
    • SOFTWARE hive
    • Current User NTUSER.DAT
    • All user's NTUSER.DAT
    • Random Access Memory
  • Preserve Data
    • MD5 Hashing
    • SHA1 Hashing
All of this contained in a simplified graphical user interface.  Many of the commands are modular so you can choose what commands and what items you wish to run or capture, with a simple check box.  When you run the script you should get to see something like this:



The Results
     Once you've selected your choice of modules you simply hit run and then you will see a new folder created in the script folder named "mm-dd-yy Incident".  This folder if you run everything you will see something like this:


You'll get a lot of information regarding the PC you run the tool on.  All of it sectional going to its own report.  This was the easiest way for me to setup reporting.  My hope is to someday create a centralized html file for easy access to all of the information in an easily navigated web page.  The evidence folder is where you'll find all of your stored data.  It will look a little like this:


You should find copies (used robocopy to retain metadata settings, I hope) of the Recent Folder, Prefetch Folder, and Jump List folders if you are in Windows 7.  You will also notice it can rip all of your registry hives for quick analysis with your favorite tool.  Considering adding a Reg Ripper module so you can get quicker reports from extracted registry data.  

Future
     Full disclosure, this script is a work in progress at the moment.  I can't promise it will work for everyone.  I'm hoping some of you will be kind enough to test it out and send me your feedback and errors so I can hopefully ensure reliability of it.  Also, if you have ideas that you would like to see implemented within the script just let me know and I will try to implement them properly.  As of right now, I am simply continuing to work on getting the script to run without the copied command prompt and adjusting the tool to a better order of volatility when executing the commands.  Also I need to add some sort of progress monitoring and clean up execution windows a bit.  Any and all suggestions are welcomed!  You may contact me at:  michael.ahrendt@gmail.com

Again, you may download the script here.  You can choose to just use the executable or, if you have AutoIt, you can run from the source code of the same name.

Hope you enjoy.