Notifications
Clear all

Shellbag analysis

24 Posts
6 Users
0 Reactions
5,714 Views
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
Topic starter  

What kind of answer are you fishing for? You seem to have a preconceived notion of either a problem or something.

Not fishing for anything.

Each of the component structures in the shellbags paths are shell items, similar to the structures that comprise the shell item ID list in LNK files. Each of those shell items that point to a folder also include a series of embedded time stamps in DOSDate format. Several of the available tools include these in the output.

I know that many analysts state that they want "everything", and that they want to be the ones to determine what's useful…and that's fine. So I'm asking how folks use this information in their analysis.

I find that very few tools report the exact same results. Results are named differently, outputs are in different formats, etc. I look at the output of the tools, look to see if they are reasonable and cat the results into a usable format.

Perhaps that's where the confusion lies…different tools provide different information. I have compared my own tools to TZWorks sbag64.exe (v0.28). I tried MiTeC's Windows Registry Recovery, but it doesn't show anything from a Windows 7 USRCLASS.DAT hive.

Maybe the issue is that if folks don't know what data is in the structures…they're only seeing the output of the tools…then using different tools that output different information (perhaps not all of it) might lead to the confusion.

As for time stamps, I guess I am missing question. I normalize everything on UTC, output the results, make sure they are reasonable… Not sure to what you are alluding.

Not alluding to anything…asking a straight up question.


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
Topic starter  

i just finished a big case and shellbags were included. i used Xways and the Mitec tool.

"Mitec" tool? Which one?

my use of shellbags was more to show how an encrypted drive was organized and the files the folders contained. it worked VERY well

Very cool. How did you find the encrypted drive in the shellbags? Was it listed as a volume/drive letter?


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
Topic starter  

To both BitHead and EricZ,

What have you done to validate the tools you use?

I've done analysis similar to what Eric describes…however, I've found that some tools miss some critical data structures…had I not been aware of that, I might have blown passed it, thinking, "okay, that user never accessed that item….", when, in fact, they had.


   
ReplyQuote
 gmkk
(@gmkk)
Active Member
Joined: 14 years ago
Posts: 13
 

As per ShellBags detailed structure, you may want to have a look at the following sources

"Using shellbag information to reconstruct user activities" - excellent paper by Yuandong Zhu, Pavel Gladyshev, and Joshua James
http//www.dfrws.org/2009/proceedings/p69-zhu.pdf

"Windows Shell Item format specification" by Joachim Metz
http//liblnk.googlecode.com/files/Windows%20Shell%20Item%20format.pdf

Speaking about tools, you may also want to check Willi Balenthin's shellbag parser, written in Python (source code available), however I didn't use this tool to date
http//www.williballenthin.com/forensics/shellbags/index.html
You will also find a lot of detailed information about ShellBag's internals on this page.

As per validation of ShellBags - some time ago I did a lot of manual checks of ShellBags artifacts on my lab box. I have prepared a fresh virtual XP instance and then I was accessing various files and folders, connecting USB mass storage devices, accessing files on these devices (making detailed log of operations including time, path etc.). Then I used a few tools to parse ShellBags and compared results with my notes (sbag, EnCase's 42LLC Bag Parser and MiTeC's WRA - no RR at that time, though) as well as I did a spot manual check on selected raw entries by following TZWorks process.

All three tools did a good job and produced consistent results, therefore I have marked them as valid for my toolbox, with some remarks, though

1) TZWorks - overall note "very good", it can parse both NTUSER.DAT and USRCLASS.DAT files on both x86 and x64 Windows platforms; moreover you can easily export results to Excel for further processing (e.g. to include it in the final timeline of user's activity). It can also parse ShellBags from live system - good choice for scripting.
http//tzworks.net/prototype_page.php?proto_id=14

2) EnCase's 42LLC Bag Parser by Yogesh Khatri - overall note "excellent"; it can parse both NTUSER.DAT and USRCLASS.DAT files on both x86 and x64 Windows platforms (ShellBags+StreamMRUs) and it is parsing all relevant registry hives found in the image (e.g. located in System Restore). You can easily export data to Excel (with some bells and whistles, e.g. you can select columns for export, select entries for export, export entries based on custom conditions etc.) + results are presented in nice Explorer-like form. Definitely a tool of choice with only one drawback - it is EnPack, so you need to use EnCase.
http//www.swiftforensics.com/p/downloads.html

3) MiTeC WRA - overall note "medium" - although this tool did a good job on parsing (both ShellBags and StreamMRUs), it has a few major drawbacks

- first of all, the report it produces does not contain RegLastWritten timestamp which strongly reduces functionality of this tool (only MAC timestamps are available)
- it can't parse USRCLASS.DAT files (Win7).
- it is not easy to export the data to Excel
- the last free version (1.5.2) comes from 2004, so it's rather old (AFAIK, later it was purchased by Paraben and now it's a part of Paraben's forensic suite). Google is your friend so you can still find v1.5.2 available for download on some sites.

Having all that in mind, I'm using "approved" sbag and 42LLC Bag Parser on daily basis and usually do not perform manual ShellBags verification on each case (except some spot checks on critical items for high priority cases). Moreover, in many cases it is OK just to verify that user accessed given folder in the past and exact timestamp is not always critical to the case (so you can easily cross-verify ShellBags findings with other artifacts).

Have a good day!

Greg


   
ReplyQuote
Chris_Ed
(@chris_ed)
Reputable Member
Joined: 16 years ago
Posts: 314
 

Greg,

Wondefully detailed post, thanks for taking the time to write it!


   
ReplyQuote
EricZimmerman
(@ericzimmerman)
Estimable Member
Joined: 13 years ago
Posts: 222
 

I used MiTeC Registry Analyser (latest version as of april 2012, 1.5.2 i think) and compared the results with X-Ways registry reporting.

I was, in this case, no concerned so much with the dates that were there, but rather the directory names and the contents.

I had several indicators of TrueCrypt being used in conjunction with Limewire and i knew how Limewire was set up by looking in limewire.props.

Once i had the save and share paths from .props, i looked in the shellbags to see how his file system was organized on all his folders inside the truecrypt container. it was hard for him to argue accidental downloads when he had folder for his family pics, folders for adult porn, and many separate folders for CP.

I used the full reports from MiTec tool as exhibits in the case. I had reports from 2 machine showing very consistent information.

In my case the shellbags gave me 'x-ray vision' into the encryption so to speak.

I also used fileurns.cache to see what was inside the encryption and since the hash value is in fileurns.cache, i could say with certainty the exact files that were in the encryption on a given date.

*EDIT* my case was based around Windows XP as well


   
ReplyQuote
EricZimmerman
(@ericzimmerman)
Estimable Member
Joined: 13 years ago
Posts: 222
 

Just played with the TZWorks sbags tool a bit. i like it A LOT better than MiTec. the layout and dates are really nice.


   
ReplyQuote
EricZimmerman
(@ericzimmerman)
Estimable Member
Joined: 13 years ago
Posts: 222
 

H

Check this out

http//tzworks.net/prototype_page.php?proto_id=14

especially this section as it speaks to the DOS dates you mention

Timestamp Verification
For sbag algorithm updates we internally perform regression testing as a normal course of action to verify the entries are valid. Likewise, it is highly recommended that any user of our tools do some sort of integrity validation to ensure the data reported is accurate. Below is a quick way of one way to verify the timestamps reported by sbag reflect the raw data.
One starts out by identifying where the source of an entry came from (shown as #1 in the diagram). This can be viewed in the last column of the sbag output. Next, one can use any registry viewer to extract the binary data from the appropriate cell value (shown as #2 in the diagram). For the example below we used yaru to extract and review the binary data. The timestamps embedded are DOS based (vice FILETIME based), and thus are four byte values. After locating the three DOS timestamps, one converts these timestamps into a readable form. Step #3 below shows a multipurpose utility we use to convert between various time formats, however, any trusted time-conversion tool that is available will suffice.


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
Topic starter  

Eric,

Thanks, I've seen that, and I've seen all of the stuff that Greg posted. But again, that does not really go toward answering my question.

I'm trying to ascertain how you…you…as an analyst, use the time stamps in your analysis. I'm beginning to believe that based on all of the redirection that's going on, no one really does use those timestamps.


   
ReplyQuote
EricZimmerman
(@ericzimmerman)
Estimable Member
Joined: 13 years ago
Posts: 222
 

well, in my last case that i used them, i didn't really use the timestamps (as i previously mentioned) as part of my exhibits. I was more interested in how the files were organized into directories by their type/content. I did look at the dates a bit, but not to the point of relying on them other than to point me in the right direction for filters based on dates and times in my forensic tool(s) to get to other artifacts.

Looking at the output of sbags, if i needed more than i already had date wise, i would use the created and last accessed dates to corroborate the info i had in fileurns.cache, lnk files, etc in order to

1. start with a known, demonstrable file based on the SHA in fileurns.cache
2. show how/when it got on the computer and in what folder
3. show when it was viewed via various artifacts.

since bags contain file names and dates (ie no hash value) i cant, at least as far as my last case went, say exactly what the contents of the file are, but since i had other artifacts to use which guarantees the contents of a file and gives me the size and full path, i can show the connection between things pretty nicely.

it worked in this case. jury convicted subject of receipt, possession and distribution.


   
ReplyQuote
Page 2 / 3
Share: