A Smackrel of Forensics Honey…

I’m baiting this pot of honey with a reflective post by John Sawyer, All Forensic Investigators Are Not Created Equal at the Evil Bytes Blog.

There are forensic "experts" who have a narrow specialization in investigating individuals. Some examples off the top of my head are law enforcement forensic examiners looking at a computer to see if it was used to send threatening e-mails, search for information on making bombs, or view child pornography. The primary, and often only, source of evidence is the suspect's computer that is sometimes accompanied with some corroborating information from the suspect's ISP or a Web/mail hosting provider.

On the extreme opposite end of the spectrum, you have those who work on a much larger scale, taking into consideration many sources of information. I'm not sure there's a good term for them -- security investigator or enterprise incident responder or similar title -- but they go far beyond looking at just one system. Logs from routers, firewalls, and a numerous other types of systems all come into play in order for the investigator to crack the case.

I can’t consider myself really in the same class as true/certified “forensics” specialists.  If I had to place myself somewhere, I guess it would be with those in the second paragraph; one of those “enterprise incident responders.”  I have to know enough about Windows systems, typical/non-typical user behaviors, network elements, and hardware stuff.  Then I have to be able to successfully integrate all those elements together when I approach and analyze a system.  Is it harmless? It is potentially criminal? I have to get hard-data to come to a supportable conclusion, then present that material in a manner that is clear, logical, and fair; often to folks who are not technical in their knowledge base.

Since I don’t have any “formal” forensics training, I have to rely of the stream of material from the real experts and apply that information to our operational environments.  We have a limited budget and a growing workload.  Luckily I’ve been able to thrive with many freeware/Open Source tools shared kindly with the community by the developers bringing them to life.  I’m very grateful for both the knowledge-sharing and the tool-sharing.  That alone helps encourage and drive me to blog so tirelessly.  It’s a way of paying it forward.

In John’s post, he references this Infosecurity (UK) - The black art of digital forensics post by Steve Gold. Steve starts out with dissecting issues of timeline building and the conflicts that can arise when dates are disparate.  Then he moves on to the new “GUI-based” (by that I think he is referring to all-in-one commercial forensic suites) that help “aid” the investigator by parsing out volumes of system data and auto-magically sorting it out (bow optional) for the investigator. He then counterpoints the benefits of such applications with leaving the investigator in a possibly weakened position if confronted by a skilled trial-lawyer who may bring doubt in if the investigation doesn’t know how the software arrived at the data. Finally he concludes with observing that many forensics experts have had to learn on their own how the systems are working, so they can parse out the data needed, interpret it accurately, and wrap it up.

After the IPSEC steps, he claims, it’s usually a simple matter to classify the data collated and then analyze it fully.

Good digital forensics, he says, is not rocket science, but it does take a lot of thought to be able to complete an investigation and research all the relevant angles thoroughly.

“The bottom line with good IT forensic analysis is that you need to think about what data you have and how you can use it to your best advantage”, he says.

I’m not sure about that last point “…you need to think about what data you have and how you can use it to your best advantage.”  In my possibly naive way of looking at things, you need to understand what data you have, and work with what it tells you.”  Depending on your collection skills and knowledge base, that may be very little or almost the whole story.

To me, the successful analyst/forensic expert, whatever their hat may be, must be first and foremost a successful knowledge integrator.  They have to understand what tools they have at their disposal, what data the system is/is-not capable of providing, and apply the first to the second to extract the key and correct data needed.  Only then can they tease out the story it tells.  And in many ways, a successful analyst/forensic expert isn’t just a technical expert, they must excel at being an accurate storyteller, spinning the truth and reassembling the plot from the pages of a book come unbound.

• RegRipper Wishlist – Harlan Carvey is taking suggestions for improvements to his RegRipper tool.  I’ve recently got to “live-fire” deploy it and found it incredibly useful for helping me go from a global-view of the system down to the specific areas I needed to focus on.  While it didn’t produce a smoking-gun by itself, it highlighted all the shell-casings (if you will) that moved the search along quickly.
• Stuff – Windows Incident Blog then focuses on highlighting some useful source material, tips, and technical papers.  Good reading material abounds.
• Tools for mounting images – Harlan then moves on to showcasing a list of (mostly) free tools that can be used to mount drive image files.  ImDisk is fitting my systems analysis needs quite nicely as I generally work with raw IMG format files, though a rare .dd image file still is captured from time to time.
• Thoughts on Tool Verification – Harlan then moves on to touch on one of the issues that Steve Gold pointed out earlier…that investigators don’t always know exactly what and how the tool they are using is working under the hood.  He has helped that process a bit by seeding output of RegRipper with some basic tips/guides in some key areas.  That’s a nice touch and certainly helps keep folks on track understanding what they are (or actually are not) seeing in the data.
• Mo’ Stuff  -- And Harlan teases me about my blogging output!.  He’s able to find time to post regularly during the week.  I have to save it up for the weekend!  In this post, among the many great tool finds, timeline incongruities and the NtfsDisableLastAccessUpdate value, as well as Mark Woan’s tools (more on that in a moment).  Back to timelines…on a system I was dissecting, I had observed two different login events that the timelines just didn’t make any sense on.  Instead of chalking it up as “just one of those things” I made note and set it aside.  Eventually, after additional analysis work and data collection I finally was able to realize that the event element wasn’t “wrong”, but that I had made the initial mistake of placing in the timeline where I expected it to normally be, rather than where in the timeline activity sequence it really happened at. Once I did that, I was back on the right track and a whole new door of system activity became clear and fell into place.  Data and the elements that lead to timelines can be manipulated, destroyed, or “spoofed” by skilled folks, but doing so globally is very challenging.  In the absence of evidence casting doubt on the validity of that data, sometimes you have to accept (with a grain of salt) what it is telling you and trust it to clear things up down the road if you are faithful to it.
• USB Key Analysis vs. USB Drive Enclosure Analysis and Updated: Computer Forensic Guide To Profiling USB Thumbdrives on Win7, Vista, and XP – two great posts on the SANS Computer Forensics, Investigation, and Response blog.  With the proliferation of portable storage devices, this is one area incident responders need to be familiar with.  BTW, many locations that deploy “whole disk encryption” may also be able to set policies to force encryption of attached USB storage devices.  I point that out because if the encryption policy is set with a remote server, that server may also contain log data of portable USB device usage on the local system.  That could be valuable “witness” information to corroborate findings on the local system. Regripper will provide great registry information on connected devices as will Nir Sofer’s free USBDeview utility.
• woanware – Amazing toolset collection – As mentioned earlier, via Harlan’s post, I tripped over to Mark Woan’s incredible collection of utilities.  Way too much to mention in this post.  However, I really have been focused on both RegExtract which contains at least 65 plugins to query a Windows Registry for “key” data as well as gmailparser to look for browser cache remnants of Gmail usage, and ChromeForensics for parsing data out of Google Chrome/Chromium usage.  The micro csv2html tool is one of those brilliant tools that simply does what it does (turn a CVS formatted file into HTML table format) very well. ipsorter, NetCalc, and NoteTaker might appeal to the broader sysadmin audiences as well. Hop over there and make Mark proud.
• ChromeAnalysis - Google Chrome Forensics from forensic-software.co.uk (and FoxAnalysis) could be useful in a pinch.  I always like having more than one tool that does the same thing so I can get a “second-opinion” if I’m not 100% sure about the validity of what I am capturing.  It also goes without saying that Nir Sofer’s collection of Browser Tools must be in your toolbox by this point.
• I’ve been banging my head on my cubicle desk lately as I’ve been having to process a disk IMG file or two and a few of the Nir tools (and others) that I have been needing to use are “verboten” by our Symantec AV solution.  I guess I could make a whole nother physical system sans Symantec but it’s a lot of work transferring my otherwise stocked utility kit to that system.  But executing, even in memory, any of those tools sets off a slew of “infection” alerts.  I finally arrived at a clever (to me) workaround.  As I am mounting the Image files (read-only mode) to my system, they then become visible as a drive letter.  So I created a Windows Virtual PC system, left off SAV, and configured it to attach (share) the same drive letter as my image file is using proper.  Then I can download/execute the particularly offensive system utilities safely and easily within the VM and point them to the “mounted” source image as needed. No alerts and I am able to use the tools.  It’s not elegant but it does the work in a pinch.
• Matthieu Suiche has put out a Call for Beta-Testers :: windd utility RC2 (32-bits & 64-bits). If testing out a memory-imaging tool is your thing, drop Matthieu a line. He specifically is looking for folks that have more than 4GB system RAM to test it with.  See also his Windd Windows Physical Memory Imaging Utility info page as well as his direct link to windd RC2.
• Decrypting a PointSec Encrypted Drive Using Live View, VMWare, and Helix -- SANS Computer Forensics, Investigation, and Response blog.  It’s a lot of work but it is in process a bit similar to what I have to do using my Custom Win PE Boot Disk geared for PGP WDE systems.  You can either decrypt the entire drive (long and time consuming), or you can boot with a PGP driver-injected PE disk, pass off the encryption authentication token/passphrase, and then rip an image (through the PGP driver) of the “unencrypted” physical drive at the sector level.  I’ve done a few and it works like a champ.
• Welcome to the Rule 26 Blog – interesting IT/forensics blog from the legal-eagle perspective.  IAMAL so a few of these sites go a long way to helping me appreciate the issues (and procedures) needed to keep on the good side of incident-response legal issues.  They also have some nice forensics-response material (tips) as well.  .
• EDD Update: The Death of Imaging – Eric Blank seems to be--what we as kids would say—hard at work  “…poking at a fire-ant bed with a stick too-short”.  That said he does make a few interesting observations, including the storage-space race to the 1TB level and beyond.  As these capacities become more and more common-place, the thought of taking a forensic image becomes more daunting.  Not impossible, but challenging; particularly when actually filled with that much data.  Instead Eric seems to prognosticate that “Live file extraction will become the de facto method of gathering ESI.”  In fairness, Eric does clearly acknowledge the value of bit-based imaging and the data it provides.  However he seems to suggest that live-file extraction (only those visible to the system) and not in the unallocated spaces will the the way to go.  Then drop down to the comments as Wayne Kerr reminds Eric that he is not addressing “live-image” forensic imaging software and methods.  I would add that I didn’t see forensic live memory captures or network forensic captures mentioned in the post either. Both provide critical additional data to understanding a suspect system that is volatile and when not captured, may vanish for good if not captured.  Eric’s response to Mr. Kerr was telling, “Live forensic imaging (as described in your comment) is an invitation to disaster and spoliation. … Live imaging exposes electronic data to inadvertent destruction and alteration.”  Eric does (point agreed) that network based live-imaging can be very slow as well.  However, in some cases, this might be the best and least intrusive manner to capture critical data that would otherwise be lost and destroyed…which is where the casenotes and detailed documentation comes into play.  And while by nature, executing code on a suspect system (memory image capture or “remote” disk-image sector capture) impacts it, if done correctly it could be minimized and the benefit might outweigh the “spoliation”.  Kudos to Eric for bringing the discussion to the table.
• Finally for all you Google Trends voyeurs watchers and Google search addicts, two posts from McAfee Avert Labs blog were a bit interesting from the security-watch front this past week:  Searching for Malware Data Likely to Lead to More Malware and Google Trends Suffering Abuse Today.  Bottom line is that rogue A/V makers are seeding Google with linkage back to their sites so that unwary users looking for solutions to malware, trojans, viruses may be tricked into visiting their sites looking for relieve but instead find themselves hammered with more virus/malware headaches than they had to begin with.  Sad.  Likewise, they also seem to be keeping an eye on hot Google Trends and seeding sites of their own creation in a way to also appear in the top of ‘hot search’ result pages as well.  Check those search-links carefully before you click that link!  Know where you are going and avoid those darker alleyways unless you really know what you are doing and are well shielded.
• Alex Eckelberry’s Sunbelt Blog has been an excellent digest of malware-related issues and topics.  It has traditionally been the place to go for information on emergent rogue anti-malware products plaguing users.  However, in case you missed the link in the item above, Sunbelt Software is now also hosting the Rogue Antispyware blog which provides a constant stream of current information regarding this particular “class” of malware infections.  Malwarebytes blog also identifies many of these rogues and provides removal tools and tips as well in most all of their “rouge” posts. Finally the Microsoft Malware Protection Center also details updates to their handy MSRT (Malicious Software Removal Tool) as well as providing interesting rogue/malware analysis details from time to time.  (Sadly, even the official MSRT tool isn’t immune from being spoofed by its own rogue version: Different Strategies of Win32/FakeAV - CA Security Advisor Research Blog).

In the wise words of HP world Auror Alastor Moody: “Constant Vigilance!”

Claus V.