Thread: [sleuthkit-users] Encryption flag issue
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Søren B. <shb...@gm...> - 2019-03-20 09:47:54
|
Hi. I've got this issue that I haven't been able to solve: Autopsy 4.10.0 on Windows 10 Pro Problem: A known encrypted file is not flagged when running the Encryption Detection Module. Secondary problem: The encrypted file is saved as a .dll file, but is not flagged when running the Extension Mismatch Detector Module. Pre: An encrypted container was created using Veracrypt. The size of the container was set to 100MB. Hash sha512, encryption serpent, filesystem NTFS. The container was named "VBoxClient-64bit.dll" and was placed in folder "C:\Program Files\Oracle\VirtualBox\x86". The forensic image on where the container is located, was also tested using X-Ways and EnCase, and both tools flag the container as encrypted. Best regards Soren Berggreen |
|
From: Nanni B. <dig...@gm...> - 2019-03-20 11:54:15
|
I tried and in my test image file (EWF format) it founds two TrueCrypt volumes as encrypted suspects. Il giorno mer 20 mar 2019 alle ore 10:48 Søren Berggreen < shb...@gm...> ha scritto: > Hi. > > I've got this issue that I haven't been able to solve: > > Autopsy 4.10.0 on Windows 10 Pro > > Problem: > A known encrypted file is not flagged when running the Encryption > Detection Module. > > Secondary problem: > The encrypted file is saved as a .dll file, but is not flagged when > running the Extension Mismatch Detector Module. > > Pre: > An encrypted container was created using Veracrypt. The size of the > container was set to 100MB. Hash sha512, encryption serpent, filesystem > NTFS. The container was named "VBoxClient-64bit.dll" and was placed in > folder "C:\Program Files\Oracle\VirtualBox\x86". > > The forensic image on where the container is located, was also tested > using X-Ways and EnCase, and both tools flag the container as encrypted. > > Best regards > Soren Berggreen > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > -- Dott. Nanni Bassetti http://www.nannibassetti.com CAINE project manager - http://www.caine-live.net INFORMATIVA TRATTAMENTO DATI: I dati da voi inviati alla mia e-mail dig...@gm... ( https://www.google.com/intl/it/policies/privacy/) sono trattati esclusivamente da me medesimo (Dott. Giovanni Bassetti) presso la mia sede legale e protetti adeguatamente e gli allegati sono anche conservati cifrati. Per qualsiasi informazione e richiesta non esitate a contattarmi. L'interessato, può chiedere in qualsiasi momento informazioni e/o cancellazione dei suoi dati. La finalità, la tempistica e la modalità del trattamento è formata dalla richiesta stessa dell'interessato e degli accordi intrapresi col sottoscritto.*Si prega di LEGGERE l'informativa completa sulla PRIVACY* https://nannibassetti.com/privacy.html <https://nannibassetti.com/privacy.html> |
|
From: Richard C. <rco...@ba...> - 2019-03-20 13:58:47
|
Is it at all possible to share the file (or a similar one that you make that recreates the issue) with us here at Basis Technology so that we can look into this? V/R, Richard Cordovano Autopsy Team Lead Director of Engineering - Cyber Forensics, Basis Technology On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> wrote: > Hi. > > I've got this issue that I haven't been able to solve: > > Autopsy 4.10.0 on Windows 10 Pro > > Problem: > A known encrypted file is not flagged when running the Encryption > Detection Module. > > Secondary problem: > The encrypted file is saved as a .dll file, but is not flagged when > running the Extension Mismatch Detector Module. > > Pre: > An encrypted container was created using Veracrypt. The size of the > container was set to 100MB. Hash sha512, encryption serpent, filesystem > NTFS. The container was named "VBoxClient-64bit.dll" and was placed in > folder "C:\Program Files\Oracle\VirtualBox\x86". > > The forensic image on where the container is located, was also tested > using X-Ways and EnCase, and both tools flag the container as encrypted. > > Best regards > Soren Berggreen > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Brian C. <ca...@sl...> - 2019-03-21 03:04:39
|
Hi Soren, 1) If you navigate to the file in Autopsy, select it, and go to the File Metadata tab, then what MIME type does it say the file is? I'd assume application/octet-stream. 2) The default behavior for the extension mismatch module is to only focus on hidden pictures, videos, executables, etc. So, if the encrypted volume had a type of application/octet-stream, then it is not surprising that it wasn't flagged. The module is flagging known content types (such as JPEG) that have been renamed. 3) The Encryption Detection module does have a setting about entropy levels. I believe the default value is 7.5. If you change it to 7.0 and re-run ingest then does it find the file? thanks, brian On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> wrote: > Hi. > > I've got this issue that I haven't been able to solve: > > Autopsy 4.10.0 on Windows 10 Pro > > Problem: > A known encrypted file is not flagged when running the Encryption > Detection Module. > > Secondary problem: > The encrypted file is saved as a .dll file, but is not flagged when > running the Extension Mismatch Detector Module. > > Pre: > An encrypted container was created using Veracrypt. The size of the > container was set to 100MB. Hash sha512, encryption serpent, filesystem > NTFS. The container was named "VBoxClient-64bit.dll" and was placed in > folder "C:\Program Files\Oracle\VirtualBox\x86". > > The forensic image on where the container is located, was also tested > using X-Ways and EnCase, and both tools flag the container as encrypted. > > Best regards > Soren Berggreen > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Søren B. <shb...@gm...> - 2019-03-21 11:15:50
|
Hi 1) It says application/x-msdownload. 3) I tried with lower settings, but still no luck. Best regards Soren Berggreen On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> wrote: > Hi Soren, > > 1) If you navigate to the file in Autopsy, select it, and go to the File > Metadata tab, then what MIME type does it say the file is? I'd assume > application/octet-stream. > > 2) The default behavior for the extension mismatch module is to only focus > on hidden pictures, videos, executables, etc. So, if the encrypted volume > had a type of application/octet-stream, then it is not surprising that it > wasn't flagged. The module is flagging known content types (such as JPEG) > that have been renamed. > > 3) The Encryption Detection module does have a setting about entropy > levels. I believe the default value is 7.5. If you change it to 7.0 and > re-run ingest then does it find the file? > > thanks, > brian > > > On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> > wrote: > >> Hi. >> >> I've got this issue that I haven't been able to solve: >> >> Autopsy 4.10.0 on Windows 10 Pro >> >> Problem: >> A known encrypted file is not flagged when running the Encryption >> Detection Module. >> >> Secondary problem: >> The encrypted file is saved as a .dll file, but is not flagged when >> running the Extension Mismatch Detector Module. >> >> Pre: >> An encrypted container was created using Veracrypt. The size of the >> container was set to 100MB. Hash sha512, encryption serpent, filesystem >> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >> folder "C:\Program Files\Oracle\VirtualBox\x86". >> >> The forensic image on where the container is located, was also tested >> using X-Ways and EnCase, and both tools flag the container as encrypted. >> >> Best regards >> Soren Berggreen >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org >> > |
|
From: Brian C. <ca...@sl...> - 2019-03-21 14:47:36
|
Interesting. The MIME type is what is throwing it off. Our algorithm will only flag items that do not have a known type because videos and such can be big and random. We use Apache Tika for file type detection and we recently observed a file that had an incorrect type applied and Tika seemed to have made the decision based on the file extension. I wonder if that happened here too. We'll try to recreate this. In the mean time, can you rename the file to something like ".dat" and see if you get the same results. On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...> wrote: > Hi > > 1) It says application/x-msdownload. > > 3) I tried with lower settings, but still no luck. > > Best regards > Soren Berggreen > > > On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> > wrote: > >> Hi Soren, >> >> 1) If you navigate to the file in Autopsy, select it, and go to the File >> Metadata tab, then what MIME type does it say the file is? I'd assume >> application/octet-stream. >> >> 2) The default behavior for the extension mismatch module is to only >> focus on hidden pictures, videos, executables, etc. So, if the encrypted >> volume had a type of application/octet-stream, then it is not surprising >> that it wasn't flagged. The module is flagging known content types (such >> as JPEG) that have been renamed. >> >> 3) The Encryption Detection module does have a setting about entropy >> levels. I believe the default value is 7.5. If you change it to 7.0 and >> re-run ingest then does it find the file? >> >> thanks, >> brian >> >> >> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> >> wrote: >> >>> Hi. >>> >>> I've got this issue that I haven't been able to solve: >>> >>> Autopsy 4.10.0 on Windows 10 Pro >>> >>> Problem: >>> A known encrypted file is not flagged when running the Encryption >>> Detection Module. >>> >>> Secondary problem: >>> The encrypted file is saved as a .dll file, but is not flagged when >>> running the Extension Mismatch Detector Module. >>> >>> Pre: >>> An encrypted container was created using Veracrypt. The size of the >>> container was set to 100MB. Hash sha512, encryption serpent, filesystem >>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >>> folder "C:\Program Files\Oracle\VirtualBox\x86". >>> >>> The forensic image on where the container is located, was also tested >>> using X-Ways and EnCase, and both tools flag the container as encrypted. >>> >>> Best regards >>> Soren Berggreen >>> _______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>> http://www.sleuthkit.org >>> >> |
|
From: Luís F. N. <lfc...@gm...> - 2019-03-22 03:46:29
|
Default Tika behaviour is to detect mimetypes based on known signatures or structures (looking inside zip and ole containers). If no known signature/structure is found, Tika falls back to name/file extension detection. Hope this helps, Regards, Luis Nassif Em qui, 21 de mar de 2019 às 11:48, Brian Carrier <ca...@sl...> escreveu: > Interesting. The MIME type is what is throwing it off. Our algorithm will > only flag items that do not have a known type because videos and such can > be big and random. > > We use Apache Tika for file type detection and we recently observed a file > that had an incorrect type applied and Tika seemed to have made the > decision based on the file extension. I wonder if that happened here too. > We'll try to recreate this. > > In the mean time, can you rename the file to something like ".dat" and see > if you get the same results. > > > > On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...> > wrote: > >> Hi >> >> 1) It says application/x-msdownload. >> >> 3) I tried with lower settings, but still no luck. >> >> Best regards >> Soren Berggreen >> >> >> On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> >> wrote: >> >>> Hi Soren, >>> >>> 1) If you navigate to the file in Autopsy, select it, and go to the File >>> Metadata tab, then what MIME type does it say the file is? I'd assume >>> application/octet-stream. >>> >>> 2) The default behavior for the extension mismatch module is to only >>> focus on hidden pictures, videos, executables, etc. So, if the encrypted >>> volume had a type of application/octet-stream, then it is not surprising >>> that it wasn't flagged. The module is flagging known content types (such >>> as JPEG) that have been renamed. >>> >>> 3) The Encryption Detection module does have a setting about entropy >>> levels. I believe the default value is 7.5. If you change it to 7.0 and >>> re-run ingest then does it find the file? >>> >>> thanks, >>> brian >>> >>> >>> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> >>> wrote: >>> >>>> Hi. >>>> >>>> I've got this issue that I haven't been able to solve: >>>> >>>> Autopsy 4.10.0 on Windows 10 Pro >>>> >>>> Problem: >>>> A known encrypted file is not flagged when running the Encryption >>>> Detection Module. >>>> >>>> Secondary problem: >>>> The encrypted file is saved as a .dll file, but is not flagged when >>>> running the Extension Mismatch Detector Module. >>>> >>>> Pre: >>>> An encrypted container was created using Veracrypt. The size of the >>>> container was set to 100MB. Hash sha512, encryption serpent, filesystem >>>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >>>> folder "C:\Program Files\Oracle\VirtualBox\x86". >>>> >>>> The forensic image on where the container is located, was also tested >>>> using X-Ways and EnCase, and both tools flag the container as encrypted. >>>> >>>> Best regards >>>> Soren Berggreen >>>> _______________________________________________ >>>> sleuthkit-users mailing list >>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> http://www.sleuthkit.org >>>> >>> _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Brian C. <ca...@sl...> - 2019-03-22 18:55:27
|
Do you know a way to turn off falling back to the extension? I don't see anything obvious in the docs. On Thu, Mar 21, 2019 at 11:46 PM Luís Filipe Nassif <lfc...@gm...> wrote: > Default Tika behaviour is to detect mimetypes based on known signatures or > structures (looking inside zip and ole containers). If no known > signature/structure is found, Tika falls back to name/file extension > detection. > > Hope this helps, > > Regards, > Luis Nassif > > Em qui, 21 de mar de 2019 às 11:48, Brian Carrier <ca...@sl...> > escreveu: > >> Interesting. The MIME type is what is throwing it off. Our algorithm >> will only flag items that do not have a known type because videos and such >> can be big and random. >> >> We use Apache Tika for file type detection and we recently observed a >> file that had an incorrect type applied and Tika seemed to have made the >> decision based on the file extension. I wonder if that happened here too. >> We'll try to recreate this. >> >> In the mean time, can you rename the file to something like ".dat" and >> see if you get the same results. >> >> >> >> On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...> >> wrote: >> >>> Hi >>> >>> 1) It says application/x-msdownload. >>> >>> 3) I tried with lower settings, but still no luck. >>> >>> Best regards >>> Soren Berggreen >>> >>> >>> On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> >>> wrote: >>> >>>> Hi Soren, >>>> >>>> 1) If you navigate to the file in Autopsy, select it, and go to the >>>> File Metadata tab, then what MIME type does it say the file is? I'd >>>> assume application/octet-stream. >>>> >>>> 2) The default behavior for the extension mismatch module is to only >>>> focus on hidden pictures, videos, executables, etc. So, if the encrypted >>>> volume had a type of application/octet-stream, then it is not surprising >>>> that it wasn't flagged. The module is flagging known content types (such >>>> as JPEG) that have been renamed. >>>> >>>> 3) The Encryption Detection module does have a setting about entropy >>>> levels. I believe the default value is 7.5. If you change it to 7.0 and >>>> re-run ingest then does it find the file? >>>> >>>> thanks, >>>> brian >>>> >>>> >>>> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> >>>> wrote: >>>> >>>>> Hi. >>>>> >>>>> I've got this issue that I haven't been able to solve: >>>>> >>>>> Autopsy 4.10.0 on Windows 10 Pro >>>>> >>>>> Problem: >>>>> A known encrypted file is not flagged when running the Encryption >>>>> Detection Module. >>>>> >>>>> Secondary problem: >>>>> The encrypted file is saved as a .dll file, but is not flagged when >>>>> running the Extension Mismatch Detector Module. >>>>> >>>>> Pre: >>>>> An encrypted container was created using Veracrypt. The size of the >>>>> container was set to 100MB. Hash sha512, encryption serpent, filesystem >>>>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >>>>> folder "C:\Program Files\Oracle\VirtualBox\x86". >>>>> >>>>> The forensic image on where the container is located, was also tested >>>>> using X-Ways and EnCase, and both tools flag the container as encrypted. >>>>> >>>>> Best regards >>>>> Soren Berggreen >>>>> _______________________________________________ >>>>> sleuthkit-users mailing list >>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>> http://www.sleuthkit.org >>>>> >>>> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org >> > |
|
From: Luís F. N. <lfc...@gm...> - 2019-03-23 17:57:40
|
Hi Brian, If you do not fill Metadata.RESOURCE_NAME_KEY, only content will be used. But I do not recommend that, because there are many mimetypes detected based only on filename/extension. This logic is in MimeTypes class, unfortunatelly it is final. Will talk to Tika colleagues to see if we can make that configurable, so filename would be used only when there is no signature registered for the mimetype. Regards, Luis Em sex, 22 de mar de 2019 às 15:55, Brian Carrier <ca...@sl...> escreveu: > Do you know a way to turn off falling back to the extension? I don't see > anything obvious in the docs. > > On Thu, Mar 21, 2019 at 11:46 PM Luís Filipe Nassif <lfc...@gm...> > wrote: > >> Default Tika behaviour is to detect mimetypes based on known signatures >> or structures (looking inside zip and ole containers). If no known >> signature/structure is found, Tika falls back to name/file extension >> detection. >> >> Hope this helps, >> >> Regards, >> Luis Nassif >> >> Em qui, 21 de mar de 2019 às 11:48, Brian Carrier <ca...@sl...> >> escreveu: >> >>> Interesting. The MIME type is what is throwing it off. Our algorithm >>> will only flag items that do not have a known type because videos and such >>> can be big and random. >>> >>> We use Apache Tika for file type detection and we recently observed a >>> file that had an incorrect type applied and Tika seemed to have made the >>> decision based on the file extension. I wonder if that happened here too. >>> We'll try to recreate this. >>> >>> In the mean time, can you rename the file to something like ".dat" and >>> see if you get the same results. >>> >>> >>> >>> On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...> >>> wrote: >>> >>>> Hi >>>> >>>> 1) It says application/x-msdownload. >>>> >>>> 3) I tried with lower settings, but still no luck. >>>> >>>> Best regards >>>> Soren Berggreen >>>> >>>> >>>> On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> >>>> wrote: >>>> >>>>> Hi Soren, >>>>> >>>>> 1) If you navigate to the file in Autopsy, select it, and go to the >>>>> File Metadata tab, then what MIME type does it say the file is? I'd >>>>> assume application/octet-stream. >>>>> >>>>> 2) The default behavior for the extension mismatch module is to only >>>>> focus on hidden pictures, videos, executables, etc. So, if the encrypted >>>>> volume had a type of application/octet-stream, then it is not surprising >>>>> that it wasn't flagged. The module is flagging known content types (such >>>>> as JPEG) that have been renamed. >>>>> >>>>> 3) The Encryption Detection module does have a setting about entropy >>>>> levels. I believe the default value is 7.5. If you change it to 7.0 and >>>>> re-run ingest then does it find the file? >>>>> >>>>> thanks, >>>>> brian >>>>> >>>>> >>>>> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> >>>>> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> I've got this issue that I haven't been able to solve: >>>>>> >>>>>> Autopsy 4.10.0 on Windows 10 Pro >>>>>> >>>>>> Problem: >>>>>> A known encrypted file is not flagged when running the Encryption >>>>>> Detection Module. >>>>>> >>>>>> Secondary problem: >>>>>> The encrypted file is saved as a .dll file, but is not flagged when >>>>>> running the Extension Mismatch Detector Module. >>>>>> >>>>>> Pre: >>>>>> An encrypted container was created using Veracrypt. The size of the >>>>>> container was set to 100MB. Hash sha512, encryption serpent, filesystem >>>>>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >>>>>> folder "C:\Program Files\Oracle\VirtualBox\x86". >>>>>> >>>>>> The forensic image on where the container is located, was also tested >>>>>> using X-Ways and EnCase, and both tools flag the container as encrypted. >>>>>> >>>>>> Best regards >>>>>> Soren Berggreen >>>>>> _______________________________________________ >>>>>> sleuthkit-users mailing list >>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>> http://www.sleuthkit.org >>>>>> >>>>> _______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>> http://www.sleuthkit.org >>> >> |
|
From: Luís F. N. <lfc...@gm...> - 2019-03-23 17:59:41
|
Actually it is not a fall back mechanism, it is a mimetype refinement strategy. Em sáb, 23 de mar de 2019 às 14:57, Luís Filipe Nassif <lfc...@gm...> escreveu: > Hi Brian, > > If you do not fill Metadata.RESOURCE_NAME_KEY, only content will be used. > But I do not recommend that, because there are many mimetypes detected > based only on filename/extension. > > This logic is in MimeTypes class, unfortunatelly it is final. Will talk to > Tika colleagues to see if we can make that configurable, so filename would > be used only when there is no signature registered for the mimetype. > > Regards, > Luis > > Em sex, 22 de mar de 2019 às 15:55, Brian Carrier <ca...@sl...> > escreveu: > >> Do you know a way to turn off falling back to the extension? I don't see >> anything obvious in the docs. >> >> On Thu, Mar 21, 2019 at 11:46 PM Luís Filipe Nassif <lfc...@gm...> >> wrote: >> >>> Default Tika behaviour is to detect mimetypes based on known signatures >>> or structures (looking inside zip and ole containers). If no known >>> signature/structure is found, Tika falls back to name/file extension >>> detection. >>> >>> Hope this helps, >>> >>> Regards, >>> Luis Nassif >>> >>> Em qui, 21 de mar de 2019 às 11:48, Brian Carrier <ca...@sl...> >>> escreveu: >>> >>>> Interesting. The MIME type is what is throwing it off. Our algorithm >>>> will only flag items that do not have a known type because videos and such >>>> can be big and random. >>>> >>>> We use Apache Tika for file type detection and we recently observed a >>>> file that had an incorrect type applied and Tika seemed to have made the >>>> decision based on the file extension. I wonder if that happened here too. >>>> We'll try to recreate this. >>>> >>>> In the mean time, can you rename the file to something like ".dat" and >>>> see if you get the same results. >>>> >>>> >>>> >>>> On Thu, Mar 21, 2019 at 7:15 AM Søren Berggreen <shb...@gm...> >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> 1) It says application/x-msdownload. >>>>> >>>>> 3) I tried with lower settings, but still no luck. >>>>> >>>>> Best regards >>>>> Soren Berggreen >>>>> >>>>> >>>>> On Thu, Mar 21, 2019 at 4:04 AM Brian Carrier <ca...@sl...> >>>>> wrote: >>>>> >>>>>> Hi Soren, >>>>>> >>>>>> 1) If you navigate to the file in Autopsy, select it, and go to the >>>>>> File Metadata tab, then what MIME type does it say the file is? I'd >>>>>> assume application/octet-stream. >>>>>> >>>>>> 2) The default behavior for the extension mismatch module is to only >>>>>> focus on hidden pictures, videos, executables, etc. So, if the encrypted >>>>>> volume had a type of application/octet-stream, then it is not surprising >>>>>> that it wasn't flagged. The module is flagging known content types (such >>>>>> as JPEG) that have been renamed. >>>>>> >>>>>> 3) The Encryption Detection module does have a setting about entropy >>>>>> levels. I believe the default value is 7.5. If you change it to 7.0 and >>>>>> re-run ingest then does it find the file? >>>>>> >>>>>> thanks, >>>>>> brian >>>>>> >>>>>> >>>>>> On Wed, Mar 20, 2019 at 5:48 AM Søren Berggreen <shb...@gm...> >>>>>> wrote: >>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> I've got this issue that I haven't been able to solve: >>>>>>> >>>>>>> Autopsy 4.10.0 on Windows 10 Pro >>>>>>> >>>>>>> Problem: >>>>>>> A known encrypted file is not flagged when running the Encryption >>>>>>> Detection Module. >>>>>>> >>>>>>> Secondary problem: >>>>>>> The encrypted file is saved as a .dll file, but is not flagged when >>>>>>> running the Extension Mismatch Detector Module. >>>>>>> >>>>>>> Pre: >>>>>>> An encrypted container was created using Veracrypt. The size of the >>>>>>> container was set to 100MB. Hash sha512, encryption serpent, filesystem >>>>>>> NTFS. The container was named "VBoxClient-64bit.dll" and was placed in >>>>>>> folder "C:\Program Files\Oracle\VirtualBox\x86". >>>>>>> >>>>>>> The forensic image on where the container is located, was also >>>>>>> tested using X-Ways and EnCase, and both tools flag the container as >>>>>>> encrypted. >>>>>>> >>>>>>> Best regards >>>>>>> Soren Berggreen >>>>>>> _______________________________________________ >>>>>>> sleuthkit-users mailing list >>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>>> http://www.sleuthkit.org >>>>>>> >>>>>> _______________________________________________ >>>> sleuthkit-users mailing list >>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> http://www.sleuthkit.org >>>> >>> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X