Anti-forensic - introduction and timestomping

As I mentioned in the blog, threat intelligence is essentially threat counterintelligence – a process aimed at stopping hostile infiltration of the environment. This time we will deal with a strictly technical issue related to how attackers can try to (anti-forensic) hide traces of their activities and how to detect such activities. The starting point for our considerations will be issues in the field of computer forensics and incident response (DFIR). Analyzing incidents and evidence left behind by attackers is a challenge on many levels. If we look at the example of the Windows registry - one of the most useful artifacts in computer forensics - it was not created for the purpose of forensic analysis. Its original purpose is to collect information about user behavior to improve system operation, not to collect evidence. Therefore, it is difficult to expect that it will have additional protection against malicious manipulation. However, in the end, the registry is quite a resilient artifact, because of the structure of the database, simply deleting keys and values does not actually make them unavailable for analysis. As with other fields of security, computer forensics and anti-forensic is an arms race between attackers and analysts.

Anti-forensic, broadly speaking, are techniques used to make evidence left behind by malicious activity more difficult to access or to distort it in such a way as to prevent its effective use in analysis. At counterintelligence.pl, we usually deal with typical network operations, so perhaps readers will first think about evidence that helps to reveal and stop the activity of, for example, the APT group. However, we need to look at anti-forensic more broadly, because the quality of the evidence will be of the greatest importance when the materials have to be submitted to the court. This will be the case, for example, in cases related to CSAM (Child Sexual Abuse Material), evidence of participation in criminal groups, or industrial espionage carried out by company employees. Members of the blue teams will therefore rather focus on obtaining information enabling operational actions to remove the attackers from the environment, while law enforcement or legal departments of the company will also be interested in making the evidence as indisputable as possible.

In terms of specific techniques, we will focus on operations that can be performed at the level of logical manipulation of files and system configuration. So we will not deal with the physical destruction of the media or the entire computer. To systematize the techniques, we will use a methodology MITER ATT&CK. Most anti-forensic techniques can be found within the identifier T1070 - Indicator Removal.

The techniques indicated in ATT&CK include deleting logs generated by audit tools, deleting specific artifacts such as implant files or network keys and modifying file properties, including changing the access time to the resource - timestomping.

So let's take a look at what timestomping is and how it looks from the point of view of analyzing the Windows environment. This technique consists in modifying the timestamps of the file so as to hide the moment of its creation or modification. In this way, the attacker can try to match the modification time with other files in the folder, or set a date that suggests that the file is not related to the incident. Timestomping can be done using the functionality of Windows and PowerShell, copying the file to the folder to which we have permissions and using the Get-Item command to read and modify the "creationtime", "lastaccesstime" or "lastritetime" values. These parameters correspond to the records of properties in the Master File Table (MFT), which is a database that stores information about file properties in Windows. The MFT maintains four signatures, known as MACE:

• M – modified – file modification
• A – accessed – access to the file
• C - created - creating a file
• E - entry modification - change of entry in the MFT

Alternatively, we can meet the MACB notation:

• M – modified – file modification
• A – accessed – access to the file
• C – changed – change of entry in MFT
• B - birth - file creation

In addition, we must bear in mind that (MFT) saves information with timestamps in two data sets - $FILE_NAME ($FN) and $STANDARD_INFORMATION ($SI). While the $SI can be changed by the user, the $FN should only be modified by the operating system. Here, however, the previously mentioned file copying comes in handy. Because if we change the Standard Information attributes manually, then when copying the file back to the original folder, the values will be written to the $FN attributes.

Let's take a step-by-step look at the technique using an example text file:

We move the file creation date back a few days using Get-Item.creationtime:

As a result, we obtain a file with the time of modification and access selected by us.

An example of the use of timestomping in practice was action NOBELLIUM during attacks exploiting access to SolarWinds software. The attackers modified the file attributes so that the DLLs looked like normal Windows files. Similarly, the Temp.Veles group responsible for attacks using the Triton malware modified the attributes of $SAnd using the PowerShell functionality. In the report, the analysts even point to searching for parameters like ".CreationTime=" as a method of detecting malicious activity.

So, moving on to detection, what options do analysts have against this anti-forensic technique? The simplest method is to look closely at the timestamp of the file, specifically the value of nanoseconds. The Windows system records time with such accuracy, but not all tools have the ability to set the parameter with such precision. Going back to our example and using nTimeview tools we can see that the file creation time stands out from the other values:

However, the kit also includes a tool that allows you to set nanosecond values, nTimestomp:

And making sure with nTimeview:

Thanks to which, as we can see on the example of the time of last access to the file, we can also set any value of nanoseconds - like the unobtrusive 1234567.

So which method will be more reliable? We have already mentioned that we can compare the value of Standard Information and File Name contained in the MFT. And actually listing the data will indicate irregularities:

However, the attacker can bypass the problem of editing the $FILE_NAME field by copying the file to the target location. So let's look for a more reliable method. The USN log (Update Sequence Number) comes to the rescue, which records all changes that occur in the file system. We can extract the log file from the disk image where we find it in alternative data stream in the path $Extend\$UsnJrnl:

Then we can convert the file to a friendly CSV format using the tool MFTECmd by Eric Zimmerman:

The USN analysis will show the true values of file creation time and change history. However, to show the entire history of the file, I had to use two filenames as filters, as our example was initially created as "New Text Document.txt":

The "BasicInfoChange" lines are just traces of manipulation of file properties. During the analysis, it is also worth paying attention to LNK files, created by the system when opening files and which will also have time attributes:

In this case, we see three such files located between a series of entries, which is not particularly strange. However, if the attacker decided to run the file after it had been timestamped, or changed the time to the future (e.g. to exclude the file from the analysis of events that took place on the day of the attack), the comparison of the timestamps of the file and the created LNK files could show, for example, that the file was launched before its creation.

Depending on how intensively the computer is used, we can also use the content of $LogFile, i.e. a file that saves metadata changes in the file system. There we can find entries related to the change of the $STANDARD_INFORMATION and $FILE_NAME attributes, and thus also artifacts related to timestomping. Specifically, by filtering the values according to the Operation and CurrentAttribute fields, we can find changes in the field values in $FILE_NAME. Unfortunately, in my example, I couldn't find evidence of my malicious activity in the $LogFile (if I discover the reason, I will certainly update the entry), but for illustration, here are some sample entries:

In this way, we learned one of the many ways attackers use to make life difficult for computer forensics analysts. The inclusion of anti-foresic methods adds another layer of effort required to determine what has happened in the environment, but it is essential to ensure that the evidence we are reviewing is not leading us in the wrong direction.