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:
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.
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 CompatibilitySo 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:
- 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."
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.
