Are you aware of DLL hijacking? If yes, let’s suppose there is a program that executes the following line of code:
LoadLibrary('riched32.dll');
Its executable has the following name: “i_use_riched32.exe” (just as an example).
Now, take a look at the following contents of a directory containing this executable, the screenshots were taken of three tools: Explorer, FTK Imager Lite, The Sleuth Kit (each one points to the same directory).



Is the “riched32.dll” library hijacked for the “i_use_riched32.exe” executable? Let’s assume that no attempts to hijack the library have been made outside of the directory shown above.
In this particular example, the library has been hijacked. You don’t see a file called “riched32.dll“, but it’s there! What happened?
Take a look at this output for the “looks_good.dll” file (The Sleuth Kit):
$ istat -o 2048 ntfs-short-vs-long.raw 45-128-1 MFT Entry Header Values: Entry: 45 Sequence: 1 $LogFile Sequence Number: 100681841 Allocated File Links: 2 $STANDARD_INFORMATION Attribute Values: Flags: Archive Owner ID: 0 Security ID: 268 (S-1-5-21-1625344160-3855802753-2267751170-1001) Created: 2020-05-17 15:50:46.192252900 (MSK) File Modified: 2020-05-17 18:43:11.938789000 (MSK) MFT Modified: 2020-05-17 15:51:40.118530600 (MSK) Accessed: 2020-05-17 16:10:22.049613700 (MSK) $FILE_NAME Attribute Values: Flags: Archive Name: looks_good.dll Parent MFT Entry: 39 Sequence: 1 Allocated Size: 61440 Actual Size: 0 Created: 2020-05-17 15:50:46.192252900 (MSK) File Modified: 2020-05-17 15:50:46.192252900 (MSK) MFT Modified: 2020-05-17 15:50:46.192252900 (MSK) Accessed: 2020-05-17 15:50:46.192252900 (MSK) $FILE_NAME Attribute Values: Flags: Archive Name: RICHED32.DLL Parent MFT Entry: 39 Sequence: 1 Allocated Size: 61440 Actual Size: 59581 Created: 2020-05-17 15:50:46.192252900 (MSK) File Modified: 2020-05-17 18:43:11.938789000 (MSK) MFT Modified: 2020-05-17 15:49:48.952348000 (MSK) Accessed: 2020-05-17 15:50:46.192252900 (MSK) Attributes: Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 Type: $FILE_NAME (48-2) Name: N/A Resident size: 94 Type: $FILE_NAME (48-3) Name: N/A Resident size: 90 Type: $DATA (128-1) Name: N/A Non-Resident size: 59581 init_size: 59581 6320 6321 6322 6323 6324 6325 6326 6327 6328 6329 6330 6331 6332 6333 6334
As you can see, the file has two names: “looks_good.dll” and “RICHED32.DLL” (in one directory). But only the first one is shown by Explorer and two forensic tools mentioned above.
The second file name isn’t shown because it’s a short one (having the 8.3 format and marked with the DOS name space flag). Multiple forensic tools try to reduce noise in a directory listing by hiding a short file name when there is at least one long file name for the same file (in the same directory). Given that the short file name creation is enabled by default for a system volume (in Windows 10), this looks like a reasonable approach.
The shortcoming of this approach is that a short file name isn’t necessary based on a long file name (like “NEWTEX~1.TXT” which is derived from “New Text Document.txt“), a tool (or a user) can set an arbitrary short file name, even without turning on globally the short file name creation feature (for example, using the “fsutil file setshortname <file name> <short file name>” command).
So, there is a way to create an “invisible” short file name for a file in the same directory. Attackers can use this technique to “hide” a malicious file in a large directory.
One thought on “Deceptive NTFS short file names”