I have supported security incidents, legal discovery and corporate investigations with digital forensics analysis. But more recently, my focus has been only on corporate investigations. Let me explain the difference. Security incidents are events that comprise network or computer intrusions, malware analysis, forensic deep-dives, root cause analysis, incident triage and damage assessment. Each sub-component of a security incident requires a unique approach to digital forensic analysis. For example, a triage typically requires assessing a large range of computing devices for evidence of compromise by analyzing registry indicators or file system indicators. Whereas a forensic deep-dive analyzes a specific device, already known to be compromised, in almost exhaustive detail: for example, to find evidence of exfiltration or to develop a complete timeline of the compromise. The work product of these analyses are formalized in a written report – the flavor, configuration, look-and-feel, whatever you want to call it is very different to the type of report I would write, say,  in support of a legal discovery or corporate investigation.

Corporate investigations are conducted by corporate officers (human resources, industrial security etc.) in to the allegation of policy violation by an employee. A digital forensics analyst is engaged to support this investigation specifically to retrieve electronic data that may substantiate the allegation (and yes, we do look for exculpatory evidence also). The work product of this analysis is the final report; the narrative that discusses these findings. The format of this report is different from one I’d write about a security incident. The consumer of this report is typically non-technical, the authors, the digital forensics analysts, may have differing technical skills and rhetorical skills and the technical data itself has changed over time.

Non-technical customers– when I talk about internet history and cache, one customer may understand the concept completely, another may not, so you write your report to the lowest common denominator.  For example, a common misunderstanding about technical data is why none of it contains any information about the ‘duration’ of an activity:  an employee visiting www[.]ebay.com is not important, but an employee spending 4 hours a day is, and yet internet history doesn’t provide this data.

Technical data changing over time – storage of email in PSTs is a common issue. Employees store lots of email, so when providing 800Mb of email to a customer, how do you present that effectively, analyze it, and provide an easy way for the customer to also interact with that data?

Because of these factors, it is important that a consistent approach to report writing be adopted by a digital forensics analysis group. This consistent approach should include standard formatting, approved language and a common look and feel for various report elements. But before you can address these consistency items you should develop goals to be met by an effective report. Here are some suggestions:

Accurately reflect the technical investigation process.

While it is important that the analyst understand the allegation and take appropriate steps to discover technical data that may become evidence, documenting these steps in the final report is more critical. That way the customer can understand where you found data, why you went ‘there’ looking for data, and can compare these approaches with past investigations. This provides a teaching opportunity to our customers; they become more aware of our capabilities and limitations, but also ensures that forensic analyst follows consistent technical practices when analyzing data.

Understandable to decision makers

As I said earlier, there are few 100% conclusive statements that can be made in a report, the rest may have some degree of uncertainty. And that’s okay, the point of being understandable to decision makers is to make clear the reason for that uncertainty: clarify why or why not a particular set of electronic evidence may or may not substantiate an allegation.

Withstand a barrage of employee objections

Your analysis is complete, the report is written and handed off and you move on to the next investigation. In the meantime your customer is interviewing the employee. The employee raises all sorts of objections to the technical data provided in the report. The customer, being non-technical, does not know how to rebut. Over the years I’ve heard many excuses for various technical evidence. For example, “Oh I take my laptop home over the weekend, and that was my teenage son who used it to visit inappropriate websites.” Many of these excuses can be anticipated and specifically commented on within the final report. To continue the example, I could highlight specific inappropriate websites that were visited not only on the weekend but also during work hours when badge records indicated that the employee was in the facility. This is a simple example, but it helps to tie together two different pieces of electronic data that help to address an anticipated employee objection.

Structured and easily referenced

This goes to the look and feel – if our customers receive reports from our analysts and they all ‘look’ the same, the customer learns to bypass the structure of the report and instead focus on and more easily consume the content of that report. Have you ever seen a complicated slide deck or spreadsheet and find yourself spending most of the time trying to figure out where data is? The same goes with technical reports for digital forensics. The technical content is hard enough to understand, don’t let your report structure get in the way of it.

Offer opinions and recommendations

This may be controversial to some of you, but in the world of corporate investigations it is most welcomed. The dialogue between a customer and forensic analyst isn’t just through a written report, there are many phone calls in which various technical concepts can be discussed: for example the significance of why a piece of data substantiates an allegation. Once the phone call is over, these conclusions and explanations will be forgotten. Writing them down as part of the final report will help the customer remember that conversation.

When you write a report, ask yourself if that report meets your established criteria for effectiveness. Peer review is key here, because after all, if another forensic analyst can make neither head nor tail of your report, a non-technical customer has no chance.

I have not yet worked with an operational v7 public release – Guidance is having difficulties licensing the forensic version to those of us with EE only dongles. *sigh*. But I do believe that the underlying capability of file system parsing is still intact. I tested out EXT/4 for example and found it to parse properly. So Encase, used as a file system browsing tool appears to behave as v6 currently does, and that is to present an accurate representation of the file system for manual review. What concerns  me however is that this core functionality has now been wrapped by a large number of new interface features, requiring a major relearn of the product, but more importantly, requiring considerable new testing on the part of the buyer before they feel that both v6 and v7 generate the same results.

I strongly recommend that no one use this for current production case load without submitting v7 to a rigorous internal testing plan. I only hope that we do not find something that is ‘not a bug’ but in fact a correct interpretation of filesystem/artifact data, and renders all previous v6 case work invalid because v6 did ‘it wrong all along’.

I have become aware that v6 owners, who wish to buy ‘modules’ for their v6 product (for example VFS) can no longer do so and must buy v7 instead. This is bad form Guidance considering the current state of v7.

He indicated several locations that exhibit temporal anomalies should the clock in fact get changed. For example, thumbs.db (thumbnail databases in folders with images) stores thumbnail data sequentially – changes in the timestamps of those thumbnails may indicate time change.

He was asked, what are the Top3 places to look for for evidence of clock changes, and as #1 he mentioned Event Logs. But I don’t think for the reason why it is #1. He mentioned one event for XP and a couple of events for Vista/7 that show the clock being changed that get recorded in the event log. This is good of course, but I believe the real deal with event logs is just as with thumbs.db. Data is written to the event log sequentially – it is not ordered chronologically.

Talking Windows OS and NTFS.

Again: event logs are written to the NTFS file system, and then individual events appended to the log. If the clock changes, new events are appended to the log with these new timestamps. This is where reliance on tools such as Encase/FTK to perl scripts, to Event Log explorers, even log2timeline, that may auto-sort events for us chronologically for presentation, or at the least, our first step is to sort output chronologically. If we manually inspect the contents of the event log file with a hex editor (i.e. a raw view), and do some decoding ourselves, we can see the jump in time/anomaly clearly.

Of course what is ‘clear’ is subjective – but this is a good example of where manual review of data structures may in fact save the day rather than relying on our tools. Manual review of data sources may only be appropriate for certain scenarios, and I’m not recommending it as a daily approach; but it is something to be mindful of when trying to prove a point.

1. The ability to utilize your own evidence and expanded device functionality.
2. New Email formatting.
3. New Bookmark functionality.
4. New Report Templates.
5. New Modules under Evidence Processor.

I’m going to take a look at #5 first. I believe the Evidence Processor will be one of the key features in forensic analysis for those shops that have large amounts of data to analyze and would welcome a lot of preprocessing to be accomplished prior to actual analysis.

Recall that with Encase v6, you can do a Keyword Search, Hash and signature analysis after you finish the acquisition; even without a dongle attached. The Evidence Processor in Encase v7 appears to be just that, but a lot more. It might be considered generous of Guidance to allow so much ‘stuff’ to be accomplished right up front, but I believe it falls in line with the 21st century approach to large data sets: pre-process as much as you can before the ‘human’ has to sit down and start analyzing.

Here’s a screenshot of the Evidence Processor:

For each evidence item added to your case you can acquire and/or process that evidence. If you want to process, the options in the lower window become available.

Each option is either enabled/disabled, and some of the options come with sub-dialogues. For example, Find Internet Artifacts allows you to search Unallocated or not to the more complicated sub-dialogues of the three newly added modules.

All of this pre-processing is stored in the custom database format that makes Encase v7 so different from previous versions. Once the processing is complete, the case folder structure can be copied to your analysis machine, or given to your level-3 forensic analyst, for actual analysis. It’s a neat method of operation, and remember, when you load the case, there is little lag for case open: you do not have to parse all of this pre-processed data prior to commencing actual analysis. It is all stored in database files.

If adding to the ‘Modules’ section becomes a future feature available to Enscript writers, then we have a real winner. Just imagine the numerous custom modules you would like to run against a target evidence set. Triage comes to mind as a great example of where adding modules to this Evidence Processor will deliver great benefits. Encase Enterprise? Even better. But EE is at least a year away.

Here are the sub-dialogues of the IM Parser and System Info Parser. They should be familiar to you.

The File Carver module makes use of the File Types global folder (which actually combines File Types and File Signatures in v7). Most of the ‘file types’ are listed solely by file extension, but for those that have headers, and the few that have footers, they become available in the new File Carver module dialogue to be carved during Evidence Processing.

I haven’t found any details on how HTML or Webmail files are carved. I will be testing that.

After clicking Next, you are presented with the Export File dialogue screen where you can specify file sizes for when the headers are found.

And finally – in case you were wondering. You can add Raw Images with this preview. And here’s what a lot of you have been waiting for. I will testing this out for sure.

First a screen shot:

These are the four tags that come by default with the Encase v7 preview. Behind the Tag Manager pane you will see that I have tagged the RECYCLER entry with all four tags. I expanded the column for you to see the content of the tag, but by default the tag column is small, you wont see the text, but the colors should mean something to you. Furthermore, where you click within the tag cell will determine which tag is applied.

Where you click is defined by the order of the tags in the tag manager. The tags/ordering is saved with the case, and Case Templates (another cool feature) can be created that incorporate your own custom tagging. The new Conditions (which appear to run against the entire case) work well here: search for Tag contains “Review” and get a listing of all files that need to be Reviewed by your reviewer.

I believe this is a great step forward in providing ways to include junior level forensic analysts with senior level analysts all working on the same case. Remember “Evidence Caches” can be copied so that analysts can have their own working copies. I am not sure if a single copy can simply be shared; at this time Encase v7 is constantly reading/writing from the HDD of your examiner, so while theoretically the cache files should remain static, I don’t know enough about the inner workings to be sure. And with only a single dongle for testing, that will have to wait until later.

The v7 preview that we have comes with zero conditions and filters; so I decided to create one. The following screen shows the test:

I then created a quick condition to display only those files with an extension of .JPG:

In Encase v6, executing this condition on the above Table Pane (i.e. those 11 files) would reduce the Table Pane down to five entries. In Encase v7, things are a little different:

We get a whole new tab displayed called “Results”, and in this tab is listed all files across all evidence sources that meet the condition. This is very FTK-like. I like the functionality, it will certainly come in handy, but I also want the old functionality to allow me to slice-and-dice the Table Pane. So far I haven’t discovered if that is possible.

Look and Feel
The evidence navigation (tree pane, table pane, detail pane) is still there, but can be viewed in four different modes by using the “Split Mode” option on the interface:

The option we are used to is “Tree-Table” – I wont show that. But Table, Tree, and a new funky “Treable” I will show.

Table removes the tree navigation pane from the display. This frees up real-estate of course, but other than that I’m not sure of the purpose. Perhaps reading email or other large data groups in which the tree content doesn’t change very often.

Tree removes the detail pane completely, leaving you with a Windows Explorer look and feel. Or so it seems. Actually what it has done is remove the Table Pane and moved the Detail Pane from the bottom to the right hand side. This is definitely new. Here’s another screenshot:

Here you will notice that both files and folders are now included in the tree pane on the left. Unlikely I will be using this view mode all that much; I spend a lot of time analyzing my evidence in groups, looking at timestamps etc in large chunks in the Table Pane. This view mode displays one file at a time.

And finally:

Traeble! Good lord, so not to be outdone by OMG, LOL and Muffin Top, I think Guidance Software is looking to add their own word to the Oxford English Dictionary. Thing is though, I sort of like this view mode. Sort of. As you can see in this screenshot it smushes the tree pane navigation in to the NAME column.

It will be interesting to see if Enscripts/Conditions can manipulate that column based on Split Mode type. For example, regular Tree-Table mode (the original view), the files under sub-folders are not visible unless you click the Select-All icon for the folder. Whereas the files really are there in Treable mode, just not made visible by the navigation marks unless you expand them.

Pick any one of the screenshots with a Detail Pane and you’ll notice a new default sub-pane called “Fields”. This lists, in key-value pair mode, the contents of the Details Pane’s various columns (such as Logical Size, File Created etc). One feature request I can already here is this: In the Details Pane you can drag columns left and right to customize the Detail Pane anyway you want – unfortunately the Fields Sub-pane does not update with the ordering of those columns.

More to come.

Update: Treable prevents you from sorting by column – which makes sense since it preserves a tree structure in the NAME field.

VDL Slack in NTFS – David G Ferguson
This talk drew attention to the problem of the slack space of a file whose current file size was different to the logical file size reserved for it. The problem exists within the various 4n6 tools available to us in that they appear to handle searches within that space differently.

I also learnt that the volume shadow service deliberately sets the VDL size of VSCs to 0 (zero) – this renders the VSC invisible to the normal Windows backup processes, and so the VSC is not backed up.

Advanced C2 Channels – Adam Meyers and Neal Keating
Some of the new channels being detected today.

1. Twitter C2 – A twitter account is created and C2 is posted to that account, read by controllers and bots. Base64 content.
2. Facebook C2 – data posted to the Notes section of a facebook account using english words as codewords.
3. Gmail – SSL is allowed to gmail (and now facebook). C2 is communicated over draft email with hex codes.
4. RSS feeds – malware drops javascript, the JS engine is instantiated, which requests an XML feed from a website. That feed contains the C2.

These guys didn’t like the term APT. But they did like to say reminent instead of remnant.

Windows 7 Artifacts – Rob Attoe
Hey, a fellow Brit – he works for Access Data. This presentation condensed an otherwise 4hour block in to 50 minutes. Awesome – just hit me with everything and I’ll sort it out later.

Some of the artifacts I wasn’t aware of.

1. Bitlocker-to-go – If the FveAutoUnlock kvp exists in the Ntuser.dat, then the end-user has selected the “remember this password” option when accessing that specific removable media. No password? Then use one of the many methods to boot up the OS, and simply insert the removable device. You may just get lucky.
2. Jump Lists – Custom or Automatic destinations are listed in the registry. Valuable for behavior analysis.

When did it happen? – Kieth Gould
Kieth rocks. A good solid Geek Meter-5 presentation in to NTFS timestamps and some of the gotchas/misconceptions that forensicators continue to fall prey to.

He reviewed SIA and FNA timestamps, and common scenarios in which the FNA timestamps are changed, file-system tunneling (see this earlier blog article) and reliability monitoring.

Knowledge Management – Sam Wenck
Much has been said about a threat-based approach to Incident Response (as opposed to traditional CND (vulnerabilities) or incident response (presuppose successful intrusion)), and Sam demonstrated the Lockheed Martin implementation of threat-based IR using Request Tracker and some custom programming.

This system comprises the standard ticketing engine with a customized indicator-database and a knowledge management database (like a wiki). The entire system is supported by back-end datastores such as IP databases (where on the perimeters IPs were seen), DNS lookups, proxy logs, etc etc.

The indicator database has a systematic entry method to ensure proper canonicalization of indicator intelligence. At this time we store just atomic indicators. Future work is being pursued to create computer indicators, such as complete TTP models.

Effective Expert Witness Testimony – Donald Flynn
This was a discussion about the requirements to be identified as an expert, and how to deal with cross-examination and technical presentation. An interesting comment made by the presenter jives with my investigative approach; spend the time finding both inculpatory and exculaptory evidence.

Lifting the lid on Cyber Espionage – Randy Lee
This presentation had the largest ratio of doodles-to-notes in my notepad. Yep, it slipped past me when I decided on attending that the presenter was a vendor. Ugh – must scream.

The presentation was just terrible! It was the usual pitch with one scare tactic right after the other, but from 10 years ago when vendors were still trying to sell SIMS/IDS etc. While there exists a need for these tools, the security landscape has evolved, and so must the sales pitch.

It’s the 80/20 rule – we used to spend so much money fighting 80% of the attacks. Firewalls, SIMS, log tools, netflows etc were all designed to provide real-time, behavioral (meh) capabilty as a defense against the 80% threat. The market is now saturated. The 20% threat is the focus now. The sales pitch needs to change.

Do you see what I see? – Paul Cerkez
Cerkez is a PhD student researching the automatic identification of semagrams. A semagram encodes a message in to another file – yep a type of steg, but the encoding makes use of pictures/icons to carry that message. It was an interesting cerebral diversion for the final presentation of the day.

The presenter walked us through the usual techniques of list shadows and mklink, but again, the main problem was developing an operational analysis environment that could run under Windows XP.

He settled on VirtualBox as the VM method of choice; a choice that was easily made since it was the only product that worked. The issue was the inability of other VM products to mount a drive as a physical device – they all mounted them as logical devices. A running volume shadow service can only interrogate the VSCs on a volume if that volume is listed as a physical disk in Disk Manager.

The coup for this presentation came when it was cut short. Mark McKinnon was given the podium and demo’d for us ShadowAnalyzer (yep that tool we’ve all been waiting for). It is in beta at the moment, but he had a pile of CDs to hand out. Woot.

The tool works because they authors essentially reverse engineered the volume shadow service. Therefore they promise versions for Linux and MacOSX in the future. The other cool thing is that this tool can interpret multiple file versions even in the same VSC.

Don’t know what I mean? Well, imagine if a VSC is created every 24 hours, and in that 24 hours you changed a certain spreadsheet 10 times. If you need to get back a ‘previous version’ of that file, Windows will only give you the most recent version that was saved in the VSC even though the ‘diff’ data is there for all 10 versions. The same thing occurs when you manipulate your host OS in to interrogating VSCs on mounted media. ShadowAnalyzer will present to you all 10 different version. Oh my.

Applying the Science of Similarity to Computer Forensics – Jesse Kornblum
Ever attended a talk by Jesse? Then you’ll know you’re in for some fun. My favorite quip is that he asked all of us to turn off our cellphones. And if they did beep – he wouldn’t throw it out, instead he’d do a forensic analysis on the device in front of the entire class! Perfect way to start, I knew I was in store for something good.

Uh oh, this one got mathy. Fortunately all presentations came on some DVDs that were provided to us for the conference – this is one presentation that had some math, and plenty of ‘for more details’ references to go read on Wikipedia.

The problem of similarity began with the obvious, but inefficient method of the simple MD5 hash and compare for reducing data sets during review. While somewhat effective for operating system files (and even then many files through patching are missed by this process) it was highly ineffective for user based electronic files.

He walked us through block hashing and fuzzy hashing, introducing to us various algorithms that generate an end product that should have a low false positive rate and a high false negative rate. This one I might come back to once I read that statistics primer again.

Solid State Drives – Fred Barry
The class lasted 20 minutes but the presenter essentially refreshed everyones’ memory on the workings of SSDs and the implications for forensic examiners. He presented some useful statistics which more than validated that SSDs as a source medium for evidence files most definitely increased the speed of analysis.

The most eye-opening of tests concerned the TRIM command capable OSs (for example Windows 7, Windows Server 2008, and some nix’s). He wrote the same dataset (12gigs) to many test SSDs, and then deleted that data set. Through some measurement mechanism that he didn’t disclose, he would time how long before the data disappeared. While the details were not presented the values varied from 24hours (7gigs of the original data were still present) down to after 60 seconds (all the data was gone!) So while we are all still used to the OS handling garbage collection (i.e. tracking free space etc), when it comes to SSDs, TRIM sends that command to the drive. And worst case, after 60 seconds, you will no longer be able to carve.