When using third party image mounting tools to perform the forensic examination of NTFS file systems, it is extremely important to understand NTFS Junction Points so that you don't find yourself making a critical mistake during your analysis. An issue has been identified with third party image mounting software where NTFS junction points are hard linked to folders on the forensic investigator's own hard disk. If you use software to process a file system (such as NetAnalysis® or Anti-Virus software) and the file system is mounted with junction points, the Operating System on the forensic workstation may point the software to folders which are not contained within the suspect volume. This leads to the extremely serious situation, where the investigator may inadvertently process their own file system.
This is a feature of Microsoft Windows/NTFS and is not a bug with NetAnalysis®. When recursively processing a folder structure, NetAnalysis® will process the file system as it is presented by the mounting tool or Operating System. NTFS Junction Points were designed to be transparent to software applications.
This is possible with the following Operating Systems and file systems:
|Operating / File System|
|Microsoft Windows Vista with NTFS volumes (and server Operating Systems)|
|Microsoft Windows 7 with NTFS volumes (and server Operating Systems)|
|Microsoft Windows 8 with NTFS volumes (and server Operating Systems)|
Windows 2000 and higher supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer. By using junction points, you can graft a target folder onto another NTFS folder or "mount" a volume onto an NTFS junction point. Junction points are transparent to software applications.
An NTFS symbolic link (symlink) is a file system object in the NTFS file system that points to another file system object. The object being pointed to is called the target. Symbolic links should be transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems, and were introduced with the modifications made to the NTFS file system with Windows Vista. Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.
Unlike an NTFS junction point, a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.
In Windows Vista, Windows Server 2008 and Windows 8, the default locations for user data and system data have changed. For example, user data that was previously stored in the
%SystemDrive%\Documents and Settings directory is now stored in the
%SystemDrive%\Users directory. For backward compatibility, the old locations have junction points that point to the new locations. For example,
C:\Documents and Settings is now a junction point that points to
C:\Users. Backup applications must be capable of backing up and restoring junction points. These junction points can be identified as follows:
- They have the FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_HIDDEN, and FILE_ATTRIBUTE_SYSTEM file attributes set.
- They also have their access control lists (ACLs) set to deny read access to everyone.
Applications that call out a specific path can traverse these junction points if they have the required permissions. However, attempts to enumerate the contents of the junction points will result in failures. It is important that backup applications do not traverse these junction points, or attempt to backup data under them, for two reasons:
- Doing so can cause the backup application to back up the same data more than once.
- It can also lead to cycles (circular references).
Some mounting tools do not respect these permissions and therefore allow software applications to follow the links. As the links are hard coded into the file system, they can point to actual folder locations on the forensic workstation.
The junction points that are used to provide file and registry virtualisation in Windows Vista, Windows Server 2008 and Windows 8 can be divided into two classes: per-user junctions and system junctions.
Per-user junctions are created inside each individual user's profile to provide backward compatibility for user applications. The junction point at
C:\Users\username\My Documents that points to
C:\Users\username\Documents is an example of a per-user junction. Per-user junctions are created by the Profile service when the user's profile is created.
The other junctions are system junctions that do not reside under the Users\username directory. Examples of system junctions include:
- Documents and Settings
- Junctions within the All Users, Public, and Default User profiles
Examining Junction Points
The following image shows a volume containing junction points. You can also see the corresponding hard link.
Even though, this volume is mounted as F, accessing the folder
F:\Users\All Users\ opens the link and presents the files from
C:\ProgramData as if they were actually contained within