I didn't want to complicate with this post but, I've got to. I can't help myself none. I've been talking an awful lot because I like to document every step I take. 😅
This article is divided into the following sections:
- A minimum of theory...
- In short...
- The time stamps
- The environment
- Create files
- Playing with the times
- My own CheatSheet
Let me to start this article with the same phrase with which I ended up he preceding article: There are things that It best not believe, that must be viewed for oneself. As Brett Shavers was saying in a post in his Blog:
"When you research for an answer and find it, the retention of what you learn is so much better than posting a question on a forum and waiting for someone to spoon feed you the answer."
In the previous article we saw how we could generate, (and filter), a timeline with a pair of tools, (The SleuthKit, Plaso and AnalyzeMFT), on an 'NTFS' file system, (New Technology File System). We know that something has happened at a certain time, in a particular file. But, what happened? To get to know what has happened, we must study the time stamps.
But, before continuing, let me tell you, very briefly, about this file system and the 'MFT', (Master File Table). I consider it basic to understand how the file system we are analyzing works, to understand well and to be able to interpret a timeline. It is not easy to talk about this without going too deep. But we're only interested in a couple of things, in what little I'm going to tell. Let's see if I can make it simple ...
'NTFS' works on a 'Unicode' data format.
The 'NTFS' file system was introduced when Microsoft created Windows NT, back in July 1993. 'NTFS' offers some significant improvements over the 'FAT, (File Allocation Table)' file systems. Provides more information about a file, including security features, file properties, and other attributes. There is more control over files and directories. The system keeps track of everything that happens in it, because it works with several registers, as a journal, that keep all its changes, always based on the metadata of the files.
In the 'NTFS' file system, everything written on the disk is considered a file.
What log files can we find in an 'NTFS' volume? '$Mft', '$MftMirr', '$LogFile', '$Volume', '$AttrDef', '$', '$Bitmap', '$Boot', '$BadClus', '$Secure', '$Upcase', '$Quota', '$ObjId', '$Reparse', $UsnJrnl and '$Extend'. These files can be metadata files or 'normal' files. The metadata files contain information about the volume and the normal files contain its data. These files, these metadata, are known as Metafiles. I am convinced that many of these files sound familiar to you. All these files define and organize this file system.
No system activity goes unnoticed in the files '$MFT', '$UsnJrnl' and '$Logfile'.
The first file that we find on a disk with an 'NTFS' file system is the one corresponding to the 'MFT', ($MFT), which is created at the same time as the volume is formatted as 'NTFS'. As everything that is recorded on the disk is considered a file, any modification that is made to the system will be recorded, like a metadata record, in the 'MFT' file, which even contains information on the system files and which it stores all the files and directories, with several properties and that can occupy up to 50% of the size of the partition.
Two files of the 'MFT' are created. The first one is the main one, ($MFT), and the other is a mirror copy, ($MftMirr), which contains the first four records. If the main file of the 'MFT' is damaged, it can be restored with the mirror copy.
The information of each record recorded in the 'MFT' is divided into fields, known as attributes. Each attribute has an attribute type, represented by an ID, a name and a value. The attributes can be residents or non-residents. Residents are those who store all its information in the 'MFT' registry and are non-residents who store data outside the 'MFT'.
What types of file attributes can we find? '$Standard Information', '$Attribute_List', '$File_Name', '$Object_ID', '$Security_Descriptor', '$Volume_Name', '$Volume_Information', '$Data', '$Index_Root', '$Index_Allocation', '$Bitmap', '$Reparse_Point', '$EA_Information', '$EA', '$Volume_Version', '$Symbolic_Link', '$Property_Set' and '$Logged_Utility_Stream'.
And, so far I'm going to read. I have already mentioned the two elements that I am interested in seeing today: The file '$MFT' and the attributes '$Standard_Information' and '$File_Name'.
The objective of this article is not to go into depth in the architecture of the 'NTFS' file system, nor to extend too much with the 'MFT'. I just wanted to show, at least, how this file system works and the amount of information it handles.
To give you an idea of the technical complexity of the metadata properties of the files, I show you this image, which corresponds to a record of a file that is in the 'MFT', opened with a hexadecimal viewer.
All the information of a file is saved in a record, in the 'MFT'. Specifically, you can find a total of 18 attributes for each record, represented by IDs. And this information starts at the value 46494C4530 and ends at the value FFFFFFFF.
If you wish, you have very good explanations in the following links:
- How NTFS Works: https://technet.microsoft.com/en-us/library/cc781134.aspx
- Master File Table: https://msdn.microsoft.com/en-us/library/bb470206(v=vs.85).aspx
- NTFS vs FAT vs exFAT: http://ntfs.com/ntfs_vs_fat.htm
- NTFS File System: http://ntfs.com/ntfs.htm
- NTFS Master File Table (MFT): http://ntfs.com/ntfs-mft.htm
In the 'NTFS' file system, everything on the disk is a file. Even metadata is stored as a set of files. The 'MFT' is an index of each file in the volume. For each file, the 'MFT' maintains a set of records, called attributes, and each attribute stores a different type of information.
As Brian Carrier said:
"The MFT is the heart of NTFS because it contains information about all the files and directories."
Timestamps are generated in the wake of the metadata of the file system and are represented by a series of letters. When a timeline is made, what is done is to sort that metadata chronologically. Each letter is assigned a meaning, which corresponds to an action. In this way, it is provided that:
- M, (mtime) - Modified
- A, (atime) - Accessed
- C, (ctime) - Changed, ('$MFT' modified)
- B, (crtime) - Birth
The first thing that I am going to clarify is that not all the file systems register a creation time, (B). It is not the case of the 'NTFS' file system, which does register it.
Timestamps are stored in two of the attributes we have seen previously:
- In the attribute '$Standard_Information': It contains information about a file, which includes timestamps, its permissions and a link counter. This attribute is used by all the visualization utilities of timestamps, such as Windows Explorer, and many other forensic tools.
- In the attribute '$File_Name': Represents the name of the file, with long names, (up to 255 Unicode characters), and short names, (8 characters, 8.3 filename). A file can have one or more names, which can be in any directory. This attribute is always resident. It also contains another set of timestamps.
These two attributes will contain the four corresponding timestamps. That is, the 'MFT' registers two sets of timestamps, one manipulated by the user and another managed by the system.
The main difference, within the two attributes, is that the attribute '$Standard_Information' can be modified by user-level processes, for example, using the 'Timestomp' technique, an anti-forensic tool that can completely change all the timestamps, (a technique widely used by malware), while the attribute '$File_Name' can only be modified by the system kernel. There are currently no anti-forensic tools to do so, although there are other methods for evading them, such as the disabling to update these records.
Well. It seems easy to understand the time stamps that we can find on a timeline, right? 4 letters, 4 meanings, 4 actions. But, what happens when we find the 'MACB' or '....' marks? Would you know how to interpret each one of those timestamps? Possibly you will say yes. Then I will ask you: Why? If your answer is that because you have studied it, I will ask you, again: But have you seen it? Do you believe it?
Before continuing, I must tell you that the first thing we have to be clear about is that we must know how it is used, how it works and what results each of the tools we use to perform an analysis of these characteristics. Why? Because it is not the same, for example, to run 'Plaso' on a Windows system than to do it on a Linux system. If we run it on a Windows system we will not see the timestamps as 'MACB', but we will simply see those time stamps as dates. If we choose to generate with 'Plaso' the timeline in a Windows system, we must perform the analysis of that timeline in that same Windows system because if we take the temporary file '.Plaso' to a Linux system and try to execute it, for example, 'Pinfo' on that file, will tell us that there is no data warehouse.
In the following image you can see an extract of a timeline made with the version of 'Plaso' for Windows, in which I have filtered the results to search for a specific file.
And in this other image you can see a timeline made with the version of 'The SleuthKit' for Windows, on the same image file and with the same type of filtering.
In the first case we obtain 98 references to that filtered file, from different artifacts, while in the second case we obtain 12 references, under the same filtering.
On the other hand, it is not the same to make a timeline with 'The SleuthKit' than with 'Plaso'. Why? Because even if we do it on the same forensic image, we will not get the same timestamps. Keep in mind that, to begin with, 'Plaso' analyzes more artifacts than 'The SleuthKit'.
In the following image you can see the difference between generating a timeline with 'The SleuthKit' and 'Plaso', on the same forensic image. The image on the left corresponds to one generated with 'The SleuthKit' in its Windows version. The image on the right corresponds to one generated with 'Plaso' in its version for Linux.
Differences? In this particular case '....' and '..cb' appear in the one generated with 'Plaso', but not in the one generated with 'The SleuthKit'.
Continuing with the interpretation of the timestamps, I will tell you that there is a very good reference regarding the meaning of this type of time stamps. This is the Poster_Windows_Forensics_2017_4.2, and that, among other reference data to take into account, we find this
And I ask you... Do you believe it? You've seen? Come on. It is true that it comes from a community of recognized prestige such as SANS. But, still, do you believe everything they tell you?
The first thing we see in this wonderful reference sheet is that it shows us the timestamps of the two attributes that I mentioned earlier:
'$Standard_Information', ($STDINFO), and '$File_Name', ($FILENAME)
In this way, we have to:
I think I've never been good at explaining something theoretical. I have the feeling of having released a scroll of text, and that has not been understood. It's time to see, as I like, everything I've said before.
For the realization of the tests that I have carried out to write this article, I have chosen to install a virtual machine, on VirtualBox, with a Windows 7 x64 operating system, clean, and a disk size of 10 GB, which is enough to work with the timestamps. Once the operating system was installed, I carried out several actions on several files that I created myself, on consecutive days and at different times. For each action I carried out, I made a timeline of the system using 'The Sleuth Kit', which will present the times in UTC format, in its version of Windows, and 'AnalyzeMFT', (to compare results). I also generated the timelines with 'Plaso'. And I extracted the file '$MFT', (Habits that has one), to parse it with fte, that will present the local time of the system.
The 'MFT' is a much smaller file than a forensic image and I can work on it to generate the same timelines, in case I had made an error. 🙂
The tool that I used to visualize the timelines was Timeline Explorer, to show the content in a comfortable and simple way, using filters for it.
We have seen in the previous table the timestamps, which are produced on 8 actions that can be carried out with a file in a Windows system, in the two attributes that contain timestamps, ('$Standard_Information' and '$File_Name').
Are 8 the total actions that can be carried out on a file? Well. First, I can think of 14 actions to carry out and surely I have left some in the inkwell. Agree. Not all will have an impact on time stamps, but its are actions that must be marked and taken into account. Our lateral thinking will be responsible for relating one action or another.
Let's start ... with the creation of files. Maybe I have exceeded the extension of this section, but I wanted to do several tests with several files because the same results are not always obtained when creating the files.
I can think of a couple of ways to create files.
File 'Nuevo documento de texto enriquecido.rtf'
First I create a '.rtf' file from the mouse's context menu, respecting its default name, 'New enriched text document.rtf'. After parsing the 'MFT' with fte and after setting a table format, I open your timeline with Timeline Explorer. Filter the results and I get this first image, in which we see, in addition to the file name, in a 'Unicode' data format, the 4 dates corresponding to the 4 timestamps, in a type of 'Filetime' format. We can also see a field named 'nspace', with a value of 'DOS, Win32'. What is that? A field that defines the type of name and can be:
- POSIX, (Unicode, case-sensitive)
- Win32, (unicode, case-insensitive)
- DOS, (8.3 ASCII, case-insensitive)
- Win32 7 DOS, (when Win32 fits in the DOS space)
This information corresponds to the file attribute '$Standard_Info', ($SI).
If we move to the right of the timeline of this file, we can see the 4 timestamps corresponding to the attribute '$File_Name', ($FN).
Clearly, in all cases, the same date coincides. In such a way that we have, in the file 'New text document enriched.rtf':
Now I analyze the 'MFT' with 'AnalyzeMFT' and I ask it to show me the information of the file in a short file name format. This type of format supports a maximum of 8 characters. As in this case it exceeds them, it assigns a name with 6 characters, followed by the symbol '~', (Alt + 126), and a number, correlative, in case there are more files with the same name. In this case, the name we see is 'NUEVOD ~ 1.RTF', (in this way we will see the names of files with many forensic tools, or even if we analyze the raw information), followed by the timestamps, which in this case corresponds to 'MACB'.
Now I analyze, again, the 'MFT', with 'AnalyzeMFT', but I indicate that it shows the name of the file in 'Unicode' format. Clearly there is a huge difference when interpreting these names. The timestamps, logically, are the same.
When analyzing the 'MFT' with 'AnalyzeMFT', we are extracting the metadata information corresponding to the attribute '$File_Name'.
To finish seeing the information in this file I use 'TSK', in its version of Windows. In this case, we obtain two references to the file. One of them, the one that contains in parentheses '$File_name', corresponds, effectively, to the attribute '$File_name'. The other of them, which has no associated comment in parentheses, corresponds to the attribute '$Standard_Information'.
In this way, it can be seen in the file 'New text document enriched.rtf', which:
I create a second '.rtf' file, also from the context menu, and assign it the name 'N4rr34n6.rtf'. I analyze the file 'MFT' with fte. As in the example of the previous file, I first study the information with fte. I examine both its attribute '$Standard_Information'
As its attribute '$File_Name'.
You can see that there is some difference in the time stamps. Specifically, in the timestamps corresponding to the attribute '$Standard_Information', it can be seen that the dates of creation, modification and access coincide, but the change date does not coincide. Why is this happening? Because the file is created at the same time that we click on the mouse, at the same moment that the file icon appears. By assigning a different name to the one introduced by the system by default, a change is made in the properties of the file. And that difference of seconds is what led me to assign the name to the file. In the attribute '$File_Name' the timestamps coincide. In such a way that we have:
I analyze the 'MFT' with 'AnalyzeMFT' with a short name format.
By not exceeding 8 characters, its file name does not change.
I also analyze it with a name in 'Unicode' format, with its full path.
Two references to the file are appreciated. The second one coincides in time with the previous brands but ... What the hell is that? '/Users/Marks/Desktop/N4rr34n6.rtf/snapshot.etl'.
I think that the '.etl' files, (Event Tracing for Windows Log), are log files, created by the operating system itself, (Microsoft Tracelog), which are associated with the event viewer and always contain very useful information. that can be parsed using SysInternals Strings, for example, or with the same System event viewer. But I had never found this type of files outside of the locations I know, in a newly created document that has not even been opened, and I have not seen it in time to get hold of it. So, if someone can throw me some ligh ... grateful.
However, what strikes me, in addition to that file that, remember, appears in the property of '$File_name', is the date presented. It shows the date of '2017-11-13 15:56:08', but we have seen that the file was created in '2017-11-14 16:30:07'. What happened? Who lies?
Again, I use 'TSK' to generate the timeline.
In this case, we obtain three references to the file 'N4rr34n6.rtf'. Two in the relative to the property '$Standard_Information' and one in the relative to the property of '$File_Name'. How do we interpret this? It must be taken into account that, with each action carried out in each file, the time stamps are updated. In such a way that, if the file is created, the time stamp that corresponds to it is 'MACB'. But if it is renamed, the timestamp is updated and becomes, on the one hand, 'MA.B' and on the other hand, '..C.'.
That is, a file must always contain the four timestamps, in its two attributes.
I create a third '.rtf' file, also from the context menu, and assign it the name 'Marcos_N4rr34n6_FollowtheWhiteRabbit.rtf'. As in the example in the previous file, I first study the information with 'fte'. I examine both its attribute '$Standard_Information'
As its attribute '$File_Name'.
Have you noticed something strange, different? In the first example, the type of date format was represented by a 'Filetime' format. In this case, the type of date format is represented by 'Unix (Posix)'. All this corresponds to the 'System Time', which can appear in different formats, with its respective differences. For example, the format 'Filetime' uses as a basis to date the files on January 1, 1601, while the format 'Unix (Posix)' uses the files on January 1, 1970 as the basis for dates.
As in the previous case, there is a difference of several seconds in one of the timestamps, which corresponds to the modification of the file name.
I look at his short name
And its long name, (up to 255 characters).
I generate its timeline with 'TSK' and its results are the same as in the previous case.
To finish seeing, a bit, the creation of files, I think of a second way to do it. And it is from the application itself. So, I open the 'Wordpad' application and save it, without editing of any kind, as 'FWHIBBIT.rtf'.
Parse the 'MFT' file with fte and study its two attributes: the one corresponding to '$Standard_Information'
And the one corresponding to '$File_Name'
What can we see? That there are two references to that file. One corresponds to the file itself and another corresponds to the symbolic link. The timestamps appear to be the same for each attribute, but there is a difference given in milliseconds. What does this correspond to?
The difference of milliseconds existing in the timestamps of the file 'FWHIBBIT.rtf' is given by the process of saving the file. That is, it is given by the time it takes the system to save that new file. So several time stamps are presented, which correspond, in chronological order, to the creation, modification and change of name:
The symbolic link 'FWHIBBIT.lnk', given that the new file was open at the same time of the saving action, is generated, since the system understands that it has been accessed. Therefore, create a file, also called 'Direct Access'.
I look at its properties in a short name format.
And in a long name format.
We have seen that there are differences in the timestamps of this file, established in milliseconds. However, 'TSK' seems unable to recognize that difference, since it only presents, for the two files that appear, the same brand with the same time stamp, 2017-11-14 16:34:14 MACB.
I generate the timeline with 'TSK'
Two files are presented, corresponding to the file created and the symbolic link. Both files present the two information properties of timestamps. Why have not I read anything about symbolic links? Symbolic links, (shortcuts), are a file, and therefore, must have its own attributes and its own timestamps.
Finished this section of the creation of files, in which I wanted to explain, briefly, some nuances that have been interesting to me at an informative level, it is time to play for real.
From here, I will focus only on the file 'FWHIBBIT.rtf', created from the own application of 'Wordpad', and I will only study the timelines generated with 'TSK', discarding all the others.
I have previously commented that I can think of 14 actions to carry out with a file. What are those actions?
- 01 Save it, (Create it), on the desktop.
- 02 Access the file, (Open it).
- 03 Modify the file, (Edit).
- 04 Rename the file.
- 05 Copy the file from the Desktop to the Documents folder.
- 06 Move the file from the Documents folder to the Downloads folder.
- 07 Send the file from the Desktop to the Trash.
- 08 Delete the file from the Downloads folder, (Shift + Delete).
- 09 Restore the file from the Trash.
- 10 Copy the file from the Desktop to a USB device.
- 11 Move the file from the Desktop to a USB device.
- 12 Copy the file from a USB device to the Desktop.
- 13 Move the file from a USB device to the Downloads folder.
- 14 Overwrite the file in the Downloads folder to the Desktop.
I will number each of the actions separately and highlight in a red box the timestamps corresponding to the day on which the action was carried out.
File created in the Desktop
I created a file from the Wordpad application and saved it on the Desktop, on November 14, 2017, at 5:34 p.m.
When a file is created, it is created as it is created, and it is the data file itself or the symbolic link, it will always appear with the time stamp of 'MACB' in the two attributes that contain this information: $SI and $FN.
If this file had been created from the context menu and it had not been renamed, it would also contain the 'MACB' timestamp, but there would be no references to its symbolic link.
From here, the timestamps will vary as we carry out one action or another.
I open the file, without editing it, and I close it again, on November 15, 2017, at 5:11 p.m.
In this case we find that the text file does not suffer variations in its time stamps, in any of its attributes, but the symbolic link presents the timestamps of 'MAC.', In the two information attributes. This means that it has been opened previously and it is enough to locate the attribute '... B' to know its date of creation, which is the date of opening of the document.
Here I will make a clarification. When you access, (open), for the first time to a file, it create, as I said before, a symbolic link that will present the 'MACB' mark, in both attributes. From there, if it is opened again, that mark changes and it is set to 'MAC.', Also in both attributes, since that link is already created.
I open the file and I modify it on November 16, 2017, at 5:58 p.m.
In this case we are presented that, the data file contains the mark of 'M.C.', in the attribute '$SI', and that of the symbolic link continues in 'MAC.', In its two attributes. As the timestamp presented by this text file lacks '.A.B', we look for it above to find out when it was created, or we can locate the marks referring to the attribute '$FN'. To know when the file was opened, we look for the '... B' that we need in the symbolic link.
I rename the file from 'FWHIBBIT.rtf' to '_FWHIBBIT.rtf', on November 17, 2017, at 10:37 p.m.
The current timestamp presented by the data file is '..C.', In its '$SI' attribute, with the new name. All references to that file, except for the symbolic link, will contain the new name. If we go up the lines of this file, we find the mark 'M ...', when it was modified, and the mark '.A.B', when it was created. There are no changes in the attribute '$FN' and the symbolic link does not suffer variations either.
File copied from the Desktop to Documents
I copy the file '_FWHIBBIT.rtf', located on the Desktop, to the Documents folder, on November 18, 2017, at 6:04 p.m.
In this case we find that the text file, in the destination path, has two modifications. The marks '.ACB' in the attribute '$SI' and the marks 'MACB' in the attribute '$FN' are appreciated. The other brands are also visible on the different dates and on the two paths, the source and the destination.
File moved from Documents to Downloads
I move the file '_FWHIBBIT.rtf', located in the Documents folder, to the Downloads folder, on November 19, at 22:15 hours.
There is only a modification in the timestamps of the text file, in its attribute '$SI', which presents '..C.', With the new path.
File sent from the Desktop to the trash
I send the file '_FWHIBBIT.rtf', located on the Desktop, to the Trash, on November 20 at 5:50 p.m.
If we look in the timeline for the date of this action we can see that there is no type of change.
File removed from Downloads
For the execution of this action I had to change the file, due to an error made with the previous one, but the actions carried out with all the files have been the same, (I did the tests with four files). That is, the only thing that changes is the name of the file.
I delete the file '_N4rr34n6.rtf', located in the Downloads folder, throught 'Shift + Delete', on November 21, 2017, at 20:03 hours.
There are no current timestamps, but we are presented with a line, without a time stamp and with the path of the file removed, the 'MACB' and 'deleted' marks.
File restored from the trash
I restore the file '_FWHIBBIT.rtf', which was sent to the Trash from the Desktop, to that same path, on November 22, 2017, at 5:54 p.m.
A new mark is seen in the '$SI' attribute of the text file, which presents '..C.'. There are no more changes.
File copied from the Desktop to a USB device
I copy the file 'FWHIBBIT.rtf', located on the Desktop, to an external device, on November 23, 2017, at 22:31.
There are no changes.
File moved from the Desktop to a USB device
I move the file 'FWHIBBIT.rtf', located on the Desktop, to an external device, on November 24, 2017, at 6:10 p.m.
There are no changes in the timestamps, but we find a reference to that same file, with its route, which tells us that it has been deleted. So, is there any way to know when a file has been moved out of the system? Yes, but it will be the subject of another chapter.
File copied from a USB device to the Desktop
I copy the file '_FWHIBBIT.rtf', located in an external unit, to the Desktop, on November 25, 2017, at 4:45 p.m.
In this case we find that the text file, presents in its attribute '$SI', a new brand, '.ACB', and in its attribute '$FN', 'MACB'.
File moved from a USB device to Downloads
I move the file '_FWHIBBIT.rtf', located on an external unit, to the Downloads folder, on November 26, 2017, at 7:54 p.m.
We can see that the text file has, in its '$SI' attribute, the marks '.A ..' and '..C.', Separately. Why? For the time it takes the system to locate the file from one route to another. We also see that in its '$FN' attribute it presents the 'MACB' marks.
Overwritten file of Downloads to the Desktop
Finally, the last action I can think of is to overwrite the file '_FWHIBBIT.rtf', located in the Downloads folder, by the one located on the Desktop, on November 27, 2017, at 10:51 p.m.
In this case, we will only observe a change in the timestamps, consisting in that the text file has, in its attribute '$SI', the mark '..C.'.
I do not know if in this section I have explained myself well or I have complicated alone. But for something there are summaries, in this case, represented by a nice table, called CheatSheet 😉
In this simple way you can have your own CheatSheet of timestamps. I present it in this way, highlighting in red the marks corresponding to the day in which each of the actions was carried out.
Both for a file created from the context menu
As for a file generated through the application itself
And I can read anywhere, anything else, but this is what I have done, this is what I have seen and this is what I have to believe.
With all this we have seen, and taking into account that the oldest mark that a file should have is that of its creation, '...B', would you be able to tell me something about this image? 🙂
Since the System records in various log files and different artifacts all the actions that occur in it, and since everything in the file system 'NTFS is a file, I consider that it is necessary to make a timeline, always.
A timeline will not be enough to complete an analysis, but it is the best way to see that something has happened, at a certain time, with a specific element. Therefore, it will always be an excellent reference sheet.
It is necessary to know well, both the file system that we are analyzing, and the tool we are using. Not all work the same and not all of them will yield the same results. We have seen that 'TSK' does not interpret the milliseconds but, nevertheless, 'fte' does. We have seen that in these milliseconds different actions have been carried out. However, it is more complicated to interpret an action with 'fte' than with 'TSK'.
Likewise, we must take into consideration the time formats on which each of the tools we use works. It is not the same to use a tool that works on the local time of the system than one that works on the UTC format. In a single minute there can be a lot of activity in the System, both inculpatory and exculpatory.
We have also seen that 'AnalyzeMFT' only interprets the attribute '$FN', while 'TSK' and 'fte' interpret the two attributes, '$SI' and '$FN'. Therefore it is necessary to choose the right tool, since everything will depend on the case to be analyzed.
About the timestamps, the first thing you need to know is that, as you can see in my own CheatSheet, a file should always contain the four elements that compose it, (crTime, aTime, mTime and cTime), in its two attributes: '$SI' and '$FN'. Both in the data files and in the symbolic links, which are files of the same form, with its respective timestamps in both attributes. That is, it is not enough to rely solely on the four brands separately, since it can be related to establish what type of action has been carried out.
This point is important because, finding ourselves with no time stamps, or with differences between the time stamps of the attributes '$SI' and '$FN', means that something 'weird' has happened, so we should focus in those elements. Likewise, the oldest action that must appear in a file is that of its creation.
It is very interesting to note and relate the different marks, of the different dates, both between the names of the data files and its symbolic links. Lateral thinking.
I can not help but recommend that you read my previous post, dedicated to generating timelines: About the timelines: The limit, your imagination
As references to keep in mind, I think it is very interesting to always carry the following:
PD: Life is based on decision making. No decision is easy and some hurt and cost more than others. Today I have made a decision that will hurt me a lot. But the circumstances are what they are and I can not change the times either. Some people have told me that I am wasted, laboriously speaking. Maybe they're right I do not know. Why do I say this? Because my work has no relation whatsoever to the world of Cybersecurity and it is a very high handicap and a huge effort, to continue to keep this pace of life. I can not commit to posting anything with deadlines. Therefore, this post, it will probably be, if not the last, one of the last articles I will write in Follow the White Rabbit. I will continue studying and working on my small projects, on my
free part time, and, if these rabbits leave me, publishing that material when I have it ready.
Will we read in the next post? Marcos, @_N4rr34n6_