Re: [sleuthkit-users] sleuthkit-users Digest, Vol 125, Issue 4

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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