Re: [sleuthkit-users] Views area of Autopsy Question

[John L. <slo...@gm...>]

2

> On Nov 7, 2016, at 8:54 AM, Brian Carrier <ca...@sl...> wrote:
> 
> Votes sent to me in private show overwhelming support for 2 trees (one based on extension and another based on signature).
> 
> Now the question is how people want to see the tree based on signature organized.   Please vote.
> 
> 1) Nodes for images, videos, executables, documents, etc.  Each node would have one or more MIME types in it. For example, Images would have all of the JPG, GIF, BMP, etc. MIME types. 
> 
> 2) Nodes for each MIME type.  This would give a full taxonomy of the system. For example:
> 
> application
> + exe
> + msword
> + x-msdownload
> 
> audio
> + aiff
> 
> image
> + bmp 
> + jpeg
> ...
> 
> text
> + html
> + plain
> ...
> 
> #1 is easier to find general types of data, #2 allows you more fine grained access.  Preference?
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Nov 4, 2016, at 12:08 PM, Brian Carrier <ca...@sl...> wrote:
>> 
>> Fair points. 
>> 
>> Let’s get some votes, otherwise we’ll stay with status quo.  There are three options on the table. 
>> 
>> 1) We intermix extensions and MIME type in the current views area and items may come and go from nodes as ingest progresses.
>> 
>> 2) We have two trees.  One is the current extension-based one is available immediately.  The new one is signature-based on is available after ingest. Files would be in both of them.
>> 
>> 3) We do nothing and the tree stays extension-based.  If you care about getting all pictures (regardless of extension), then use the Image Gallery. If you want other MIME types, you can use “File Search By Attribute”.
>> 
>> Please send me your votes (or to the list) with 1, 2, or 3 so that we can get this into the next release. 
>> 
>> thanks,
>> brian
>> 
>> 
>> 
>> 
>> 
>>> On Nov 3, 2016, at 6:04 PM, noxdafox <nox...@gm...> wrote:
>>> 
>>> The MIME type and possible subcategories (dll, com etc) are indeed 
>>> relevant information but relying on them to infer the file type might be 
>>> error prone.
>>> 
>>> There are lots and lots of corner cases to take into account:
>>> 
>>> * When opening a file, Windows (not sure about MAC OS) merely relies 
>>> on the file extension. This has led to several cases in which malware 
>>> would not execute if the extension was not the correct one. Most recent 
>>> case I stumbled upon was a document file which would execute only if the 
>>> extension was .rtf. Extensions such as .doc, .docx or .docm would not 
>>> show the real behaviour of the sample.
>>> * Current trend is to rely on scripts. Locky ransomware has been 
>>> spread as .js, (JScript a Microsoft javascript "dialect"), .jse, .vbs 
>>> and .wsf. It's very hard to programmatically detect the language type 
>>> with good accuracy (think about how many javascript dialects are out 
>>> there). User would probably see lots of text files and might loose the 
>>> relevant ones.
>>> * How to deal with encrypted/packed/obfuscated files?
>>> 
>>> It is true that file extensions might be abused to make investigation 
>>> harder but in several cases the file extension is a very important piece 
>>> of information. Only point of mine in here is not to treat it as second 
>>> class citizen during investigations.
>>> 
>>> On 03/11/16 16:11, Brian Carrier wrote:
>>>> Another effort we have underway is to incorporate file type signatures into the Views area of Autopsy and not rely only on extension.  This is a frequent request. But like many things, it gets complicated and potentially confusing to the user.
>>>> 
>>>> Based on Autopsy’s philosophy of providing data as quickly as possible, the basic idea is to use a file’s extension if its MIME type is not yet known.  When its MIME type becomes known, then ignore the extension and rely on the file type.
>>>> 
>>>> A couple of things we’d like feedback on:
>>>> 
>>>> - When the image is being ingested, we are constantly learning about file types.  If we update the set of files under each type (JPEGs for example), then it would be frequently changing and this could get confusing and resource intensive.  Would you prefer that it is only updated after ingest is completed or at some periodic interval (say 5 minutes)?
>>>> 
>>>> - We currently break down executables in the tree into .exe, dll, .com, etc nodes.  However, their MIME type is usually the same.  Do people use the detailed breakdown of executables or would it be good enough to have a single executable node in the tree?   How are people using these nodes?
>>>> 
>>>> - We currently have a node in the tree for “.txt” files.  If we put all files of type “text/plain” in this node, it would have TONS of files. It would almost seem to make this node useless and impossible to find stuff in.  Do people ever use this node and, if so, would you like it to stay as just extension-based?
>>>> 
>>>> Put another way, the current tree was easy to implement and understand when it was only extension-based.  It’s not as easy when it is signature-based and we want to know how much of the current tree to keep.  What types of files do you want to be able to find from the tree?
>>>> 
>>>> brian
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> _______________________________________________
>>>> sleuthkit-users mailing list
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>> http://www.sleuthkit.org
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>> 
>> 
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 
> 
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org