Re: [sleuthkit-users] Views area of Autopsy Question
Brought to you by:
carrier
Menu
▾
▴
Re: [sleuthkit-users] Views area of Autopsy Question
|
From: Troy B. <tro...@gm...> - 2016-11-07 17:34:34
|
2 please. On Nov 7, 2016 12:30 PM, "John Lehr" <slo...@gm...> wrote: > 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 > > > ------------------------------------------------------------ > ------------------ > 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 > |
