Encrypted data and ...
 
Notifications
Clear all

Encrypted data and strange MFT entries

10 Posts
4 Users
0 Likes
937 Views
(@t_oliver)
Posts: 17
Active Member
Topic starter
 

Can anyone shed any light on what created this encrypted data.
There are 317 x 216 MB files in a folder. The folder and files names are all completely random.

What is odd is that apart from one of the 317 files, all have SIA 64 bit times and dates which are 10 27 00 00 00 00 00 00. The filename dates appear correct as 11/4/2017. How or what can create invalid SIA dates?

One of the files only has an initialised size which is a lot smaller than the logical size and this file only has correctly formed SIA time and dates?

Has anyone seen this or know of a software product that creates such files. I suspect they contain illicit material
Screen Capture

 
Posted : 24/09/2018 10:02 am
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

There are several different Windows APIs that can be used to change the the $STANDARD_INFORMATION timestamps. The most obvious is SetFileTime() but it can also be done with SetFileInformationByHandle() and probably other less documented routes like NtSetInformationFile(). I would expect all of these to validate the times and reject times out of range but perhaps one of them doesn't. This would be the *most* obvious way an application could change the $SI timestamps. No special application permissions are required to change these timestamps. It wouldn't be very difficult to write some test code and see how far the API can be pushed with invalid timestamps.

The $FN timestamps are harder to change programmatically and therefore probably a more reliable "witness". The ultimate method to change them is by modifying the $MFT entries directly. This requires a high level of system access, and one would think, that if an application did this and went to all this trouble, would change both the $FN and $SI timestamps. This may suggest an application that uses (or abuses) a legitimate API.

The sequence of identical files could smell like some kind of spanned data storage split into regular sized chunks. Are there any signs of file encryption software/archiving tools installed?

Its probably a long shot now if the files were modified over a year ago, but it may be worth parsing $UsnJrnl$J. If you are lucky, this may contain entries from when the files were originally created and give you sight of the contemporaneous activity. You can parse this using my (free) BMTK software. Please PM me if you need this.

I will be intrigued to see what other theories there are. Maybe I missed something obvious.

Jim

www.binarymarkup.com

 
Posted : 24/09/2018 11:19 am
(@t_oliver)
Posts: 17
Active Member
Topic starter
 

Thanks for the quick reply and detailed response Jim.

I didn't elaborate too much on first message but everything you suggested I already checked. I am aware of API's and time stamps etc and came to the same conclusion that windows APIs would not allow out of range data, but i don't know

$USNJRNL already parsed and only goes back a month or so.

There are various 'Eraser' type programs installed (i have check logs they create).

I have recovered old LNK files from UA to see if they point to any of the files. I cannot see any system artifacts that reference any of the files.

I have been through everything installed and cannot find anything obvious which would create such files or which would modify SIA times. Thats not to say it was not on external volume but I cant find any links etc which would suggest such.

My best guess at present is that there is some encryption software that creates a spanned file volume which increased in size as data is added and screws SIA times and dates on purpose.

Hoping someone might recognise such a product. Various decryption products suggest the data blocks are veracrypt / truecrypt. I have concatenated files back together but having to make some guesses on order of 371 files

 
Posted : 24/09/2018 12:03 pm
(@athulin)
Posts: 1156
Noble Member
 

What is odd is that apart from one of the 317 files, all have SIA 64 bit times and dates which are 10 27 00 00 00 00 00 00. The filename dates appear correct as 11/4/2017. How or what can create invalid SIA dates?

Why do you think they are invalid?

A Windows FileTime timestamp is a simple counter of tenths of microseconds elapsed since midnight 1601-01-01 (well, notionally). The timestamp takes 64 bits, but there are some indications that only 63 of them are used. So a Filetime is, as best as we know, 0x0000000000000000 - 0x7FFFFFFFFFFFFFFF.

Your observations fall within that range. So no obvious illegal time stamps.

Each of the four timestamps can be set by simple API calls. The only check I know of is if the most significant bit is set – that causes an error.

So, again, no obvious illegal time stamp.

If there are any flags of illegality, they probably come from the policies of the tool you are using. But that's something you should know about.

The reverse situation is less clear Windows can convert a FileTime to a SystemTime without problem. But software that doesn't use built-in APIs tend to have bugs and restrictions. But they should not be confused with Windows restrictions.

If you search for 'Interpretation of NTFS Timestamps' in the Articles of ForensicForum you'll get an idea of the situation.

One of the files only has an initialised size which is a lot smaller than the logical size and this file only has correctly formed SIA time and dates?

Is that a problem? Initialized size < size (you seem to call it 'logical size') is the situation why initialized size was created.

Has anyone seen this or know of a software product that creates such files.

I'm glad you asked. Check out the SourceForge project CompForTest at

https://sourceforge.net/projects/compfortest/files/NTFSTEST001%20-%20File%20Timestamp%20Interpretation/

You want the _2.0 image … and if you're interested in knowing how that image was created, check the accompanying source code.

You may want to use the image to test just how far you can trust the tool you're using when it comes to NTFS time stamps.

As they say, if I can do it, you can too.

But in your particular case, it's almost certainly a 'clean' operation on the part of the software that encrypted or otherwise messed up this file system. The timestamp values may be accidental, or it may be something that can be used to fingerprint the software.

 
Posted : 24/09/2018 1:12 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

I was intrigued, so created a quick test program to try this using the most obvious SetFileTime() API. It worked first time and that value is a legal FILETIME. I would have realised this if I had decoded it rather than just accepted the original premise

http//www.binarymarkup.com/forensicfocus/setfiletime.jpg

Interestingly, that API only permits the MAC times to be changed. It doesn't change the last record (E) updated timestamp. This may provide some more clue about how it was done.

AFIK I would say this is a clear bug in XWF. The value 0x0000000000002710 is a legal FILETIME just after midnight on 1st Jan 1601 and should not be reported as "Out of range". This can be reproduced with the following quick C code

HANDLE hFile = CreateFile( "D\\Time.txt", GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);

FILETIME ftTime;
ftTime.dwHighDateTime=0x00000000;
ftTime.dwLowDateTime=0x00002710;

SetFileTime(hFile, &ftTime, &ftTime, &ftTime);

CloseHandle(hFile);

Jim

www.binarymarkup.com

 
Posted : 24/09/2018 1:59 pm
(@t_oliver)
Posts: 17
Active Member
Topic starter
 

OK, I was slack with my use of the word 'illegal time stamp'. I am aware of how Windows 64 bit times are derived. I used intialised size of the file against the logical or physical (cluster space) simply as the one file which has correct SIA dates where initialised size is not the same as logical (perhaps it was the last chunk of the data file?

The thing I was trying to point out in an effort to find out what created these files, without going too deep into technicalities which are simply a side issue in my view is

Does anyone know of an encryption product / online or otherwise which

Creates a multipart encrypted volume
changes to SIA dates to 1601 (or perhaps anything the user wantS to be precise) apart from one (maybe the last chunk)

By changing the date to this value, most forensic tools and Windows itself no longer display the 1601 date. Windows itself just defaults to 1/1/1970, hence my loose use of the word invalid..

 
Posted : 24/09/2018 2:14 pm
(@t_oliver)
Posts: 17
Active Member
Topic starter
 

AFIK I would say this is a clear bug in XWF. The value 0x0000000000002710 is a legal FILETIME just after midnight on 1st Jan 1601 and should not be reported as "Out of range". This can be reproduced with the following quick C code

Encase - No dates displayed
xWays forensics - Out of range
dCode = not a valid date
Blacklight 2018 R3 - 022618 1940-10-24
FTK 01/01/1601

Whatever, its not normal…

 
Posted : 24/09/2018 2:17 pm
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

Well… the timestamp was created using a standard Windows API and works fine with no special trickery. If each of those products fails with that timestamp then they are all equally lame.

I think I will enjoy reporting this to XW.

Jim

www.binarymarkup.com

 
Posted : 24/09/2018 2:26 pm
(@t_oliver)
Posts: 17
Active Member
Topic starter
 

Well… the timestamp was created using a standard Windows API and works fine with no special trickery. If each of those products fails with that timestamp then they are all equally lame.

I think I will enjoy reporting this to XW.

Jim

www.binarymarkup.com

To be fair, I should report it to xWays, Encase, Blackbag and Microsoft!. They all do not show date for the files correctly.

 
Posted : 24/09/2018 3:12 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Whatever, its not normal…

You will need to define "normal".

And there might be the need to distinguish between the value (which is "legal"), and the date (that being senseless might be considered "illegal").

Here is an article (right here on FF, by member Athulin) that deals with the matter

https://articles.forensicfocus.com/2013/04/06/interpretation-of-ntfs-timestamps/

If we agree that timestamps on a file in a filesystem, such as (example) the creation date, must represent the actual creation date of the file in the filesystem, any date - even within the allowed numerical range - that makes no sense whatsoever as it pre-dates the actual existence of the filesystem (not of the specific filesystem, the actual existence of the concept of filesystem) should be rendered as "A suffusion of Yellow" [1] as it simply cannot represent properly what it is supposed to represent.

The real problem is that - as seen in the article - every other programmer/software has decided to use a different (mis-)representation and - additionally - without clearly stating that.

And now - only seemingly off topic - the queer case of local time on 1/1/1601 dates
https://eventlogxp.com/blog/invalid-dates-inside-some-events/

In a perfect world, whenever you try (short of direct hexediting) to create a date that makes no sense whatsoever, the API (or whatever other tool) should prevent you from doing so and whenever any tool encounters such a date should output a "same" "A suffusion of Yellow" warning that the found date is not valid/plausible.

jaclaz

[1] http//www.thateden.co.uk/dirk/

 
Posted : 25/09/2018 1:32 pm
Share: