File System Tunneling in Windows

File System Tunneling is a really old feature of Windows. It was already discussed on many security or Windows administration related blogs and books. However, it is still somewhat obscure for lots of examiners because its forensic implication is limited. The simplest way to test and observe it in action is to delete a file and then create a new one with the same name in the same path. The new file is going to inherit the creation timestamp of the original file. This function can mess with versioning systems and it can also make it tricky to find files created in a specific timeframe. But why does it even exist?

File System Tunneling

FST is used to mimic the safe save method. During safe save the original file is not immediately overwritten. A temporary file is generated first, the original file removed and then the temp is going to be moved into the place of the original. It is trivial that in a situation like this the newly generated file should have the same creation date since it was just a modification. After these multiple actions, the new file should seem like its the original one so the timestamp is going to be inherited. Thus the function is needed to provide compatibility with programmes which are using the safe save method.

It is also needed to ensure the correct short/long names are retained in case of a 16-bit application. Each file has two names: a short file name (SFN) and a long file name (LFN). While both can be used by a 32-bit application only the former one can be utilized by a 16-bit application. With the safe save method in mind, it is easy to see that the connection between the SFN and LFN and therefore the whole LFN information can be lost.

Let’s say there is a file with the LFN “Long file for test.txt”, whose SFN is “LONGFI~1.TXT”. Load this file into a 16-bit application which can only handle short file names. The safe save method happens the following way. The original file is renamed. A new temporary file is created with the initial name of the original file. The content of the file is saved into a temporary file. After that, the original file is removed, destroying the correlation between the SFN and LFN. As a last step a new file is created with the same SFN and the content is stored in it but now without the related LFN value.

Tunneling can handle the previous situation in the following way:

1. In case of deletion or rename operation, an entry is created in the tunnel cache.
2. Once an entry is inserted it going to stay in the cache for a period of time.
3. Every time when a file is created or renamed the cache is going to be checked and if a file can be found with the name of the newly created or renamed file then the values from the cache are going to be used.

Let’s translate this to the 16-bit application safe save function:

1. The original file is renamed and handled as a temporary file (in case of older editors it is renamed with the .bak suffix)
2. Due to the rename operation, an entry is created in the tunnel cache. This entry contains the SFN, LFN and other values.
3. Due to the rename operation, the tunnel cache is checked to find a match with the newly created filename, but a match is not going to happen in this case.
4. A new file is created with the initial SFN of the original file.
5. Due to the creation operation, the tunnel is checked. There will be a match and the necessary metadata will be used as the metadata of the newly generated file.
6. Content is going to be written into the new file.
7. The temporary file is going to be removed.

The values which can be stored in the cache and used later depend on the file system. For example, NTFS stores object ID and creation time of the file while FAT preserves the creation time only.

According to Microsoft, Windows supports file system tunneling in case of the following filesystems:

1. NTFS
2. FAT
3. exFAT

Settings

There are two values in the Windows Registry which can be used to configure the behavior of file system tunneling. The values can be added under the following registry key as 32-bit DWORD values: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

The first value is MaximumTunnelEntries. This can be used to configure how many values can exist in the cache simultaneously. The value 0 means the tunneling function is effectively turned off.

The second value that is worth mentioning is MaximumTunnelEntryAgeInSeconds. This key can be used to modify the lifetime of the entries in the cache. After the set amount of seconds, the entries are going to be removed from the cache. The default value is 15 seconds.

Normally none of the above-mentioned values exist in the registry. If any of them can be found in the registry, that means somebody has already messed with them deliberately.

Investigation

I tested the file system tunneling from MACB timestamp changes perspective to find out its forensic and incident response indications. The first part of the test contains the subsets of the previously defined operations which can start a tunneling cache entry creation or cache check. The operations which can trigger a cache entry creation are the rename and the deletion operations. The operations which can start a cache check are the rename and the creation.

So these are the subsets:

1. delete(A)/create(A)
2. delete(A)/rename(X, A)
3. rename(A, B)/create(A)
4. rename(A, B)/rename(C, A)

In the tables I used the following coloring scheme:

1. white: original timestamps
2. yellow: the timestamp was changed to the execution time. Execution is mostly the rename or creation operation.
3. green: the timestamp was inherited from the similarly named file or the timestamps weren’t changed. (these two technically mean the same)
4. blue: the timestamp was inherited from the file which was renamed.

delete(A)/create(A)

In this experiment, I created a file first. After some time, I removed the file and I created a new one with the name of the original. I compared the $STANDARD_INFO and $FILE_NAME timestamps of the original and the newly created file.

Based on the values in the table, one can see that the $STD and the $FN Creation dates got inherited from the original file while every other value was changed to the time of the re-creation. In fact, these time changes mean that a new file was created. New file creation according to the posters means every timestamp should be changed. But in this case file system tunneling made a little difference and it changed the Creation timestamps back to the original file creation time. Therefore, every timestamp shows the date of the re-creation time except for the creation timestamps which show the original creation of the similarly named file.

delete(A)/rename(X, A)

I initially created 2 files an ‘A’ and an ‘X’ files. For the test, I removed file ‘A’ and renamed file ‘X’ to ‘A’. Be aware that the creation date of ‘A’ and ‘X’ are close to each other, so focus on the minutes and seconds.

One can see that $STD Modification and Access date and also every $FN date were inherited from the ‘X’ file. The Creation date was inherited from the ‘A’ file due to file system tunneling and the Metadata was updated to the execution time. (which was the time of the rename).

This means the following things happened in the background. The ‘X’ file was renamed, which leaves every timestamp intact except for the metadata which is going to be updated to the actual time. Apart from that, the FST cache was checked and since there was an entry with name ‘A’ in it the creation date was inherited from the cache entry.

rename(A, B)/create(A)

No surprise here either. The first colored column shows a normal ‘rename’ timestamp change. The second colored column shows the timestamp value of a newly created file (everything is set to the execution time) with the addition of a file system tunneling Creation time inheritance.

rename(A, B)/rename(C, A)

The same update happened here as in the case of delete(A)/rename(X, A).

Tunneling test with the move operation

The previous tests were based on the definition and documentation of file system tunneling. According to this, an entry is created in the cache when the rename or delete operation occurs. I was also curious whether the same is going to happen in the case of file moving. A file move doesn’t work in a way that it removes and recreates the file. Only the metadata of the file is modified. Due to this, I assumed FTS is not going to work in this case but based on my research this also triggered the file system tunneling (caching) to function.

Here are the results of the testing:

In the first timestamp column, we can see the original values. In the second one we can see that the $STD Metadata timestamp was changed only due to the local file move. The value of this timestamp is the time of the file moving. In the last column every value was updated except for the Creation which was inherited from the original file. The updated values are the time and date of the new file creation. So it clearly shows that file system tunneling (the caching part) happens in case of file moving as well and not just when renaming or deleting.

Cross copy test

In this analysis, I performed multiple rename operations to find out if there will be any unusual timestamp generation. The below pattern was followed during the test. I created 3 files intentionally, ‘A’, ‘B’ and ‘C’. During the test I first renamed ‘A’ to ‘X’, then ‘B’ to ‘A’, ‘C’ to ‘B’ and finally ‘X’ to ‘C’. After every renaming, I saved the MFT to check the timestamps. This way we can see every change based on the following pictures.

The first image contains the $STD timestamp changes after each period. I colored the ones which are relevant compared to the previous period. The first uncolored section contains the initial timestamps. The second section is the one which contains the ‘A’ file renaming. In this case, only the metadata timestamps were changed since this was a normal renaming. However, in the next section, we can see that the Modification and Access time remained the same, the Creation was inherited from the original ‘A’ named file and the Metadata was changed to the execution time. This timestamp indicates a normal renaming happened but the file system tunneling modified the creation data as well.

The last section is the other one worth to mention. The file which now has the name ‘C’ was previously named ‘X’ and originally it was named ‘A’. In this situation the Modification and Access times are inherited from the original ‘A’ file (or the previous ‘X’ file since they are the same), the Creation time was inherited from the original ‘C’ file due to file system tunneling while the Metadata was set to the execution time.

Most of the cases the $FN times are boring. Almost none of them are touched at all. On the other hand, in one case it was set to a changed value. In the last section when ‘X’ was renamed to ‘C’ the $FN Metadata date was set to a date which we couldn’t see before as an $FN Metadata date. The value “2019-04-12 14:37:54.336630” is the $STD Metadata date of ‘X’ after ‘A’ was renamed. So this is the time the name ‘X’ first appeared. The interesting thing here is, with normal file operations there is no way to modify only this date. In fact, based on cyberforensicator’s or SANS’s MACB posters there aren’t any sequence of operations which can create an $FN metadata timestamp which is different than the $FN Modification or $FN Access timestamp. (Update: in case of BITS copy, only the Metadata timestamp is changed from the $FN ones as well, so this is not unique)

This is either an action/operation which wasn’t tested yet or some kind of issue which shouldn’t even happen. On the other hand, this can be used to detect file system tunneling but only in a case of these “cross copy” actions.

See the posters below. One can see that the mentioned $FN value can’t be set with any of the series of the listed operations.

Cyberforensicator’s timestamp poster Windows Forensic Analysis poster by Sans (https://www.sans.org/security-resources/posters/windows-forensic-analysis/170/download).

File system tunneling on drive E:

I tested file system tunneling in multiple locations with an NTFS volume. It looks like FST is working in every directory I tested on the C drive and it also worked on a network drive. On the other hand, it does not seem to work on any other drives. I tested it on other NTFS partitions and file system tunneling didn’t happen on them.

However, when I formatted the partition to FAT32 file system tunneling worked again. So far it looks like FST works only on C: drive in case of NTFS filesystem but it works on other drives without any issue if the filesystem is FAT32.

Testing environment and methods

Windows: Win 10 Pro, V1803, Build: 17134.706

I used [CyLR] (https://github.com/orlikoski/CyLR) to collect MFT files and parsed the values with analyzeMFT.py.

I used powershell to generate, modify and collect files for testing the following way. Example code for file move testing:

New-Item "move_test.txt" -ItemType file
New-Item "move" -ItemType directory

Start-Sleep -s 10
Start-Process -FilePath "C:\Users\for\Desktop\CyLR_win-x64\CyLR.exe" -ArgumentList "-c C:\Users\for\Desktop\CyLR_win-x64\mft_config.txt.txt -of MFT_1"
Start-Sleep -s 30

Move-Item -Path "move_test.txt" -Destination "move\move_test.txt"
Start-Sleep -s 5
New-Item "move_test.txt" -ItemType file
Start-Sleep -s 5

Start-Process -FilePath "C:\Users\for\Desktop\CyLR_win-x64\CyLR.exe" -ArgumentList "-c C:\Users\for\Desktop\CyLR_win-x64\mft_config.txt.txt -of MFT_2"

Incident Response implications

Most of the time file system tunneling won’t really affect any investigations. The only situation I can think of is the case when an investigator has to collect files which were created by an attacker. In a situation like this, it will be hard to determine whether a file was generated during an incident or not. In a real-life scenario every file which was touched during that timeframe can be considered compromised. During any action at least one of the timestamps is going to be updated so regardless of the Creation date timestamp inheritance we can identify potentially interesting files.

Real life example:

At the time of my first forensic related challenge I was absolutely not aware of the file system tunneling function. One of the tasks was to collect every file which could have been generated by a potential attacker. Since I knew the timeframe of the incident I collected only the files with Creation timestamps matching the given timeframe. What a mistake. I missed a lot of ‘potentially attacker generated’ files due to this, so be vigilant.

So far I could only show one situation where file system tunneling is identifiable based on the MACB timestamp values but it needs some further investigation. Nevertheless, this is definitely a Windows service worth to be aware of.