Introduction

Microsoft platforms continue to proliferate and multiply. Corporate server and desktop systems are running Windows NT (NT) and Windows 2000 (2K), while home user and student systems are running Windows XP (XP). These platforms are extremely popular, and in widespread use. However, very little is known by the administrators and users of these systems about a feature of the NTFS file system called 'alternate data streams'.

NTFS is the preferred file system due to its stability, functionality, and the level of security it provides. NTFS alternate data streams (ADSs) are provided for compatibility with the Macintosh Hierarchical File System (HFS), which uses resource forks to maintain information associated with a file, such as icons, etc (RUSS00). While Microsoft provides a means for creating specific ADSs via Windows Explorer, the necessary tools and functionality for detecting the presence of arbitrary ADSs is conspicuously absent. Oddly enough, the operating systems have the necessary native functionality and tools to allow a user to create ADSs and to execute code hidden within those streams. Microsoft KnowledgeBase article Q101353 acknowledges the fact that the Win32 base API supports ADSs inconsistently.

The purpose of this paper is to describe in detail how ADSs are created and manipulated, and how code hidden in ADSs can be executed. Specific differences in the treatment of ADSs by NT, 2K, and XP will be noted.

Creating ADSs

The syntax used to create ADSs is relatively simple and straightforward. To create an ADS associated with the file 'myfile.txt', simply separate the default stream name from the ADS name with a colon.

c:\ads>echo This is an ADS > myfile.txt:hidden

Additionally, an ADS can be created using the contents of another file.

c:\ads>echo This is a test file > test.txt

c:\ads>type test.txt > myfile.txt:hidden

The ADS can then be verified using Notepad.

c:\ads>notepad myfile.txt:hidden

However, none of the variations of the ‘dir’ command nor any available switches or settings for Windows Explorer will detect the presence of this newly created ADS.

Additionally, ADSs can be created and associated with the directory listing, rather than a file. This peculiarity will take on some significance later in this article, but for now it’s sufficient to describe how such ADSs can be created.

c:\ads>echo This ADS is tied to the directory listing > :hidden

ADSs of this type can be created with Notepad and the ‘type’ command, as well.

The content of ADSs should not be considered limited to simply text data. Any stream of binary information can constitute a file, and the ADS is nothing more than a file. Executables can be hidden in ADSs quite easily.

c:\ads>type c:\winnt\notepad.exe > myfile.txt:np.exe

c:\ads>type c:\winnt\system32\sol.exe > myfile.txt:sol2.exe

Similarly, image files, audio files, or any other stream of data can be hidden in ADSs.

Finally, Windows Explorer provides a means by which very specific ADSs can be created (RUSS00). If the user opens Explorer and chooses a file, and then right-clicks on that file, a drop-down menu appears. Choosing 'Properties' will open a Properties dialogue, and choosing the Summary tab (see Fig. 1) will reveal fields in which the user can insert information.

ADSs have no attributes of their own, per se. The access rights assigned to the default unnamed stream control access for creating or viewing ADSs. Quite simply, if a user cannot write to a file, that user cannot add an ADS to that file. Further, while Windows File Protection prevents the replacement of protected system files, it does not prevent a user with the appropriate permissions from adding ADSs to those system files. The System File Checker (sfc.exe) will verify that protected system files have not been overwritten, but will not detect ADSs.

Users and administrators should also be aware of KB article Q319300 , which states that the Windows 2000 Content Indexing Server adds alternate data streams named '?Q30lsldxJoudresxAssqpcawXc' to image files on NTFS volumes.  These ADSs contain thumbnails of the images.

Detecting, Viewing, and Manipulating ADSs

As previously stated, Microsoft provides no tools or utilities either within the operating system software distribution or the Resource Kits for detecting the presence of ADSs. One of the best tools available for this is lads.exe, written by Frank Heyne . Lads.exe is currently available as version 3.01, and does an excellent job of reporting the availability of ADSs. For administrators used to working with graphical tools, lads.exe is a command line interface (CLI) tool that reports its findings to the screen (i.e., standard output or STDOUT). Figure 2 shows an example lads.exe output, run against the test directory, c:\ads.

Figure 2 shows just how useful lads.exe can be. Not only does the utility report the presence of ADSs, but it also reports the full path and size for each ADS. Particular note should be taken of the three of the ADSs associated with myfile.txt. Two begin with an ASCII character resembling the spade from a playing card, and the third is a long series of numbers and letters between two curly braces. These are the ADSs that were associated with the file using the Summary tab of the Properties dialogue (fig. 1).

Once an ADS is detected, what can be done to view its contents? Notepad is a very handy utility for viewing files, and can be used for viewing the contents of ADSs. However, there is a catch. For example, the following command produces unexpected results:

c:\ads>notepad myfile.txt:hidden

When this command is executed, Notepad opens and asks if the user wishes to create a new file. This is an unusual request, because the ADS was created earlier. In order to observe the expected results enter the following commands:

c:\ads>echo This is another ADS > myfile.txt:hidden.txt

c:\ads>notepad myfile.txt:hidden.txt

The same effects can be observed when the ADS is associated the directory listing, as in ':hidden.txt'. The addition of the extension on the end of the filename allows the ADS to be opened in Notepad. This will also work for other ADSs, such as:

c:\ads>notepad myfile.txt:np.exe

ADSs are a feature of the NTFS file system, so if a file with an ADS is moved to a disparate file system, such as FAT, FAT32, or ext2, the ADS is removed, as it is not supported on these other file systems. ADSs are preserved if the default unnamed stream (i.e., myfile.txt from the previous examples) is copied or moved across NTFS partitions, or even to a mapped NTFS drive. This can be accomplished using the ‘copy’ or ‘move’ commands, as appropriate.

Removing all ADSs from a default stream is relatively simple, using the following commands:

c:\ads>type myfile.txt > myfile.bat

c:\ads>del myfile.txt

c:\ads>ren myfile.bat myfile.txt

Using LADS, it is easy to verify that all ADS created in the above examples have vanished.

Executing ADSs

In previous examples, executables were hidden in ADSs. This information seems fairly useless unless the executables themselves can be launched, without the overhead of having to copy them out of the ADS first. In fact, the ‘start’ command can be used to do just that. Since the executables hidden earlier were deleted, rerunning the commands will serve the purpose of an example. Using the ‘type’ command, hide Notepad and Solitaire in ADSs associated with myfile.txt.

On NT, a simple command will launch either executable (MCCL99):

c:\ads>start myfile.txt:np.exe

c:\ads>start myfile.txt:sol2.exe

However, these commands generate an error on 2K. From the error message, it appears as if the information pointing to the executable wasn’t sufficient. Therefore, either absolute or relative paths should suffice, and running either of the following commands will demonstrate this:

c:\ads>start c:\ads\myfile.txt:np.exe

c:\ads>start .\myfile.txt:np.exe

An interesting item to note is how the process appears while running. For example, running pslist.exe from SysInternals after executing either of the above two commands displays a process called 'myfile.txt' running with a PID of 1512, as shown in figure 3.

Figure 4 shows the process running in the Process tab of the TaskManager.
 

Oddly enough, the Process tab on 2K shows that PID 1512 has an Image Name of 'myfile.txt'. Figure 5 shows the Application tab of the Task Manager.

Figure 6 shows that the Process tab of the Task Manager on XP displays when the same command is executed on that operating system.

Finally, obtaining information about the process with listdlls.exe from SysInternals will display 'c:\ads\myfile.txt:np.exe' as the command line for the above command (see fig. 7), on both 2K and XP.

An alternative method for launching hidden executables on 2K is a shortcut (KASP01). To demonstrate the point, create a shortcut on the desktop. The location of the item for this shortcut should be 'c:\ads\myfile.txt'. Once the shortcut has been created, observe the icon on the desktop. Assuming the ADS for Solitaire was created, edit the Properties of the shortcut so that the target now refers to 'c:\ads\myfile.txt:sol2.exe'. Wait a few seconds and observe any changes to the icon. Launch the executable by double-clicking the icon.

Interestingly enough, as similar technique works by adding an entry to the Windows Startup Folder (KASP01) or to the ‘Run’ key in the Registry (KASP01). The full path to the key is:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Specifying the complete path to the hidden executable will guarantee that it is launched the next time the system is started.

Yet another method for launching executables hidden in ADSs is via the ‘Run’ box in the Start menu (KASP01). Clicking on the Start button, then 'Run', and typing the following command will launch the Solitaire ADS:

file:///c:/ads/myfile.txt:sol2.exe

For administrators using Perl , the Perl interpreter handles ADSs quite easily. For example, the following lines of Perl code make use of backticks to launch an ADS:

my $file = 'c:\ads\myfile.txt:sol2.exe';

`$file`;

Save the above code as ‘ads.pl’, and execute the code by typing:

c:\perl>ads.pl

As an interesting variation, the following code also works:

c:\perl>type ads.pl > myfile.txt:ads.pl

c:\perl>perl myfile.txt:ads.pl

The Windows Scripting Host (WSH) began shipping with 2K and presents some interesting possibilities with regards to ADSs (KASP01). This is particularly important because WSH is native to the 2K and XP distributions, while Perl must be installed separately. To demonstrate the capabilities of WSH, type the following command:

c:\ads>echo MsgBox 'VBS file to test ADSs' > ads.vbs

To execute the script using WSH, type:

c:\ads>wscript ads.vbs

Alternatively, type:

c:\ads>cscript ads.vbs

Or, simply double-click the file in Windows Explorer. All three of these methods will run the VBScript code. Now type the following commands:

c:\ads>type ads.vbs > myfile.txt:ads.vbs

c:\ads>wscript myfile.txt:ads.vbs

Or:

c:\ads>start .\myfile.txt:ads.vbs

Cscript.exe also runs the script. Alternatively, the shortcut and Run box methods mentioned above also run the script (KASP01).

The Really, Really Dark Side

If the script hidden in an ADS ends with a different extension (i.e., other than '.vbs'), WSH has trouble recognizing the type of file, and will complain that an engine for executing the file cannot be found. For example:

c:\ads>type ads.vbs > myfile.txt:ads.txt

c:\ads>wscript myfile.txt:ads.txt

Executing the second command above results in the error described. However, both wscript.exe and cscript.exe have switches that allow the administrator to control the execution of the program. The command syntax can be seen by typing:

c:\ads>wscript /?

The '//E' switch allows the user to specify an engine to be used. The new command looks like:

c:\ads>wscript //E:vbs myfile.txt:ads.txt

This provides some interesting opportunities for malicious use. For example, the earlier example of ADSs produced via Windows Explorer (i.e., the Summary tab of the Properties dialogue for a file) produced on ADS with the name '♣SummaryInformation'. Code, such as VBScript, can be created and written to an ADS with the same name, and then launched. The following Perl code illustrates this:

my $file = 'c:\\ads\\myfile.txt:'.chr(5).'SummaryInformation';

my $src = 'c:\ads\ads.vbs';

`type $src > $file`;

`wscript //E:vbs $file`;

The final command in the script is the one of interest. For both wscript.exe and cscript.exe, the '//E' switch forces the application to use a particular script engine. In this case, the ADS containing the script to be launched has no file extension, so the scripting host has no means for determining the scripting engine to be used.  This example could also apply quite easily to ADSs created by the Content Indexing Server, as mentioned above.

Conclusion

ADSs are a feature of the NTFS file system intended to provide compatibility with HFS, which may still be necessary for compatibility. However, the lack of visibility of this 'feature' poses a significant risk for administrators. There has already been one virus released that employed ADSs, W2K.Stream written by Bennie and Ratter of the group 29A (KASP01). As the release of malware and incidents of cybercrime increase, the malicious use of ADSs will likely increase as well.

The solution is not to stop using the NTFS file system, as the benefits in security and reliability are too great. This 'feature' has remained part of the file system since NT 3.1. Given the circumstances, a far more prudent solution would have been to include support for HFS files in the File and Print Services for the Macintosh, rather than the file system. As it is, administrators should make judicious use of discretionary access control lists (DACLs) on files and directories (CARV00), and regularly scan their critical systems using utilities such as lads.exe. In addition, Microsoft should be lobbied to add the ability to detect and view ADSs to Windows Explorer and the command interpreter. A more than appropriate measure would be to have ADSs appear in Windows Explorer by default, using an icon with a scarlet 'A' to signify an ADS. Additionally, Microsoft should provide restrictions within the operating system for creating processes from executable files whose names contain a colon.

Further, antivirus software vendors should include support for ADSs within their products by default. While many of the worms seen over the past year or more have been executables written in Visual Basic or Delphi, others have been Visual Basic scripts. This malware has been capable of wreaking considerable havoc, and all prudent steps should be taken to protect systems.

References

RUSS00 Russinovich, M., Inside Win2K NTFS, Part 2 , Windows 2000 Magazine, November, 2000

MCCL99 McClure, S., Scambray, J., and Kurtz, G., Hacking Exposed: Network Security Secrets and Solutions, Berkeley: Osbourne, 1999

KASP01 Kaspersky, E. and Zenkin, D., NTFS Alternate Data Streams , Windows and .Net Magazine, Spring 2001

CARV00 Carvey, H., Network Trojans: What You REALLY Need To Know , Information Security Bulletin, Vol. 5, Issue 8