Re: [sleuthkit-users] sleuthkit-users Digest, Vol 125, Issue 4
Brought to you by:
carrier
From: maría e. D. <dar...@gm...> - 2016-11-08 00:41:43
|
2 2016-11-07 15:34 GMT-02:00 <sle...@li...>: > Send sleuthkit-users mailing list submissions to > sle...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > or, via email, send a message with subject or body 'help' to > sle...@li... > > You can reach the person managing the list at > sle...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sleuthkit-users digest..." > > > Today's Topics: > > 1. Re: Views area of Autopsy Question (John Lehr) > 2. Re: Views area of Autopsy Question (Troy Bettencourt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Nov 2016 09:19:24 -0800 > From: John Lehr <slo...@gm...> > Subject: Re: [sleuthkit-users] Views area of Autopsy Question > To: Brian Carrier <ca...@sl...> > Cc: sle...@li... > Message-ID: <135...@gm...> > Content-Type: text/plain; charset=utf-8 > > 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 > > > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Nov 2016 17:34:25 +0000 > From: Troy Bettencourt <tro...@gm...> > Subject: Re: [sleuthkit-users] Views area of Autopsy Question > To: John Lehr <slo...@gm...> > Cc: Brian Carrier <ca...@sl...>, > sle...@li... > Message-ID: > <CAOsgDY0NBnt2Erh_QVKTPoOm9Ez4qe8dt-coHoci_dejePuM= > A...@ma...> > Content-Type: text/plain; charset="utf-8" > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------ > ------------------ > 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 > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > > > End of sleuthkit-users Digest, Vol 125, Issue 4 > *********************************************** > -- Prof. Mg. María Elena Darahuge M P Copitec 5100 |