Daily Blog #184: Artifacts from alternative file system drivers on NTFS Part 4

Hello Reader,
       In this series we've explored the POSIX namespace, how the ntfs-3g driver uses it, what default system files use it and the win32 api's interaction with it. Today let's focus on what additional artifacts exist soley within the MFT that in combination with the POSIX namespace let us identify absolutely that a non native NTFS driver wrote to the disk.

To accomplish a unique signature that reflects the actions that ntfs-3g takes when writing to a NTFS volume we need to examine three fields within a MFT file record. If you want to see this in a more interactive fashion watch last weeks Forensic Lunch where we walked through it.

1. Namespace

The Namespace can be one of 4 things that determines the encoding of the filename being stored there.The namespace as we discussed previously will be Posix or File Name Namespace 0. This on its own though does not identify a ntfs-3g written file as we've discussed in this series.

2.  LSN

The LSN or Logfile Sequence Number references the most recent change stored within the $logfile. The LSN in a native windows system writing to NTFS has full support for the $logfile and will populate this field to reflect the record entry made. The ntfs-3g driver only updates the restart area and does not populate the $logfile, because of this the LSN value will be 0 for all ntfs-3g written files. If you are looking at a pre vista system then the LSN and Namespace are the only two correlation points you have to identify ntfs-3g written files.

3. USN

The USN or Update Sequence Number references those entries written into the $USNJRNL:$J. We've talked about the USN many times in this blog and hopefully you are familiar with the basic functionality by now. In our testing we were expecting this value to be set to 0 just like the LSN but instead a 64 bit value will be assigned, we are still examining the source to determine the method use in the numbers duration but they do to seem to increase but can be duplicated. The USN values used are outside the range of valid USN Journals that we've seen. The USN number is also the offset into the USN Journal to where that last change has been recorded.

So there we go.
If you are looking at a Windows 2000/XP/2003 system than the Namespace and LSN are your points of analysis to determine if a file was written using the ntfs-3g driver.

If you are looking at a Windows Vista/7/2008 system than the Namespace, LSN and USN fields will determine if a file was written using the ntfs-3g driver.

We haven't tested windows 8 yet but will do so and write a blog to reflect when we have done so and solved what the value used in the USN field means.

Make Sure to Read: 

 Artifacts from alternative file system drivers on NTFS Part 3

 Artifacts from alternative file system drivers on NTFS Part 2

 Artifacts from alternative file system drivers on NTFS Part 1

Read More

Daily Blog #179: Artifacts from alternative file system drivers on NTFS Part 3

Hello Reader,
          In the two prior posts in this series we've examined the characteristics of a POSIX file name made by the linux ntfs-3g driver and the POSIX file names we should expect to see in a normal windows system. Today we are going to focus on the win32 api's that allow file creation to see which would allow a POSIX file name to be created in the first place.

There are three main functions exposed by the win32 api for file creation:

1. CreateFile

 This function is the main function for opening and creating a file on the disk or for accessing a device such as COM1 or a physical drive. Createfile has support for POSIX naming conventions by passing in the 'FILE_FLAG_POSIX_SEMANTICS' flag in the optional dwFlagsAndAttributes field when creating a file. What is interesting is that this flag when set does not actually create a POSIX namespace file name attribute.

 

2. CreateFile2

 This function appears to be related to Windows Store based win 8 apps that operate within sandboxed environments. There is no stated POSIX support which is interesting. This means I need to test to see what Win8 default files are POSIX.

 

3. CreateFileTransacted

CreateFileTransacted support the same methods as CreateFile, including POSIX, but creates a transactional NTFS stream that file resides in until the transaction is committed.  We are doing research into Transactional NTFS and plan to write more about this later. Interesting to note that this article begins with a warning about the possible deprecation of this functionality in the future.

 

So in my current testing I cannot find a win32 api that creates a POSIX filespace filename attribute. Here is my perl code for calling into the win32 api and createfile:

 

 #!/usr/bin/perl -w

use Win32API::File qw( :ALL );

my $hDisk= Win32API::File::CreateFile( "//./H:/\$PosixTesTingAgain", GENERIC_ALL(),
      FILE_SHARE_READ()|FILE_SHARE_WRITE(), [], CREATE_NEW(), FILE_FLAG_POSIX_SEMANTICS(), [] );
      

I've tried this with a couple variations on file name conventions to force a POSIX only compatible name, but then it just fails. I'm not done yet though and will continue trying to find a function that will allow this namespace to be attributed within windows. 

 

Why? It's important to understand whats possible so we can determine if a user program could ever create a POSIX file name. If we can't, that is a great evidence point in supporting whether a file was created by the linux ntfs-3g driver or windows.

Make Sure to Read: 

 Artifacts from alternative file system drivers on NTFS Part 4

 Artifacts from alternative file system drivers on NTFS Part 2

 Artifacts from alternative file system drivers on NTFS Part 1

Read More

Daily Blog #178: Artifacts from alternative file system drivers on NTFS Part 2

Hello Reader,
           Yesterday we went through the linux ntfs-3g driver's interaction with the MFT in NTFS. If you haven't read that you should as it explains why POSIX filespace's are the focus of today's post. Today I am going to compare the MFT my system and a test system to see how many POSIX file names are created by default so we can determine a set of rules to see if we can ascertain when a file was created by the linux ntfs-3g driver.

I parsed my MFT using mft2csv as we just added the filespace name support to v3 of anjp which we are polishing up for this months beta release. I like mft2csv and think its an easy tool to use when you just care about high detail MFT parsing. My system drive has 628,480 MFT records, its been in active use for over a year with the current install. Of those 628,480 have POSIX filespace records. So having a POSIX namespace in your filename alone does not indicate that the linux-3g driver was used in creating a file. Whats interesting here is that these POSIX filenames break down to some basic categories:

1. System files/directories like \boot and it's directories, $Recycle.bin and $Extend
2. Applications from OEMs like cygwin and hp
3. Shared libraries from visual studio, microsoft common libs and other programs
4. FTK Job work queues
5. The entire QT SDK
6. Windows directories and files
7. The user profile directories for default and public

Why is that interesting? Not a single file that I or program at my direction made in the last year as a POSIX filespace name is stored under my profile.  I want to test this on a non OEM windows install to see if the same number of POSIX filespace file names are created when you install from MS media directly.

So taking the logic one step forward, based on my limited sample set so far there should not be a user created file originally made by the native NTFS driver and using standard win32 system calls that results in a POSIX filespace file names. I am going to take this a step further tomorrow by finding which win32 calls can create POSIX filespace named files and testing this same theory against my virtual machines.

Make Sure to Read: 

 Artifacts from alternative file system drivers on NTFS Part 4

 Artifacts from alternative file system drivers on NTFS Part 3

 Artifacts from alternative file system drivers on NTFS Part 1

Read More

Daily Blog #177: Artifacts from alternative file system drivers on NTFS Part 1

Hello Reader,
        Often times when I talk to security professionals a kind of game arises where they try to come up with a scenario where they can perform an action on a system that we cannot detect in our analysis. Often times these question sessions lead to the idea that the hypothetical will simply mount his NTFS drive in Linux and perform his bad actions there to get around Windows logging and artifacts. 

I've talked before about the Linux driver's lack of support for the $logfile and $Usnjrnl leading to a lack of artifacts that can be correlated but we can now actually go one further.

The inherent limitation when basing the detection of a past event on the journals ($logfile and $USNJrnl) is that they have a finite time of existence before being written over. While the shadow copies will retain them for a period of time they will eventually expire and be overwritten as well. This finite lifespan and further research into MFT internals ( and a very nice tweet from Willi Ballenthin) lead me to an interesting documentation page from the linux3g project: http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/concepts/filename_namespace.html that listed all the available NTFS name spaces for FILENAME attributes.

This then lead to the mount.ntfs-3g man page, http://linux.die.net/man/8/mount.ntfs-3g,  that had the following statement:

"Windows Filename Compatibility

NTFS supports several filename namespaces: DOS, Win32 and POSIX. While the ntfs-3g driver handles all of them, it always creates new files in the POSIX namespace for maximum portability and interoperability reasons. This means that filenames are case sensitive and all characters are allowed except '/' and '\0'. This is perfectly legal on Windows, though some application may get confused. The option windows_names may be used to apply Windows restrictions to new file names."

 So I grabbed the CFReDS project deletion file testing image 11, you can download it here http://www.cfreds.nist.gov/dfr-images/dfr-11-ntfs.dd.bz2 and ran it through mft2csv which I know actually identifies which namespace a filename is set to. From prior testing with the $logfile and confirmation from NIST I knew that the files in this test where created in Linux and then deleted in Windows. This is what mft2csv see's from those files:

Tomorrow we'll talk about what other default files are created as POSIX by windows to prevent false positives and end this series Thursday talking about how user created file could be POSIX.

Make Sure to Read: 

 Artifacts from alternative file system drivers on NTFS Part 4

 Artifacts from alternative file system drivers on NTFS Part 3

 Artifacts from alternative file system drivers on NTFS Part 2

Read More