Re: [sleuthkit-users] Encryption flag issue

[Brian C. <ca...@sl...>]

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
>>
>