The Forensic ToolKit (FTK) is a small collection of utilities from Foundstone that allows you to analyze the NTFS filesystem. The tools included in the package are all command-line utilities for Microsoft Windows. At one time, NTFS was used only on Windows NT, but with the advent of Windows 2000 and Windows XP, this filesystem type became increasingly widespread. These tools really shine if you are looking for a quick and dirty way to ferret out hidden data left behind after an intrusion.
Currently, the Forensic ToolKit is available from the Foundstone web site (http://www.foundstone.com/). Navigate to the Resources portion of the web site. From there, click on Free Tools. The Forensic ToolKit is available under the Forensic Tools section.
Take the time to explore some of the other free tools available from this site. Tools like NTLast are also useful in trying to track down the source of an intrusion.
Extract the downloaded ZIP file to a fresh scratch directory. For my examples, I unzip everything into the freshly created C:\ftk directory. The toolkit contains a somewhat scattered array of tools, but its strength is in finding hidden information, so I will cover the tools that do that best individually.
Collectively, the utilities are best utilized once you have already narrowed down your search in terms of time. For example, in a situation where you know that your Windows 2000 web server was broken into yesterday using the latest DCOM exploit and that the hacker had stashed some tools on the server because the firewall logs show that she was using it to scan for other vulnerable hosts on the rest of the network. The *find.exe utilities are great for working through your system to find creatively hidden tools within a certain time frame.
Hfind.exe is a very simple tool included with the FTK that offers an easy method for searching large directory structures in search of hidden files. If an attacker were to look for a quick and dirty way to keep files hidden from the casual observer, the Hidden attribute may be set so that anyone not looking specifically for hidden files will not see them. On a FAT partition, this may be one of the easier ways to hide files. On NTFS partitions, there are much more effective methods (covered shortly).
Here is an example usage of Hfind:
C:\ftk>dirVolume in drive C has no label. Volume Serial Number is BCD4-2C5D Directory of C:\ftk 09/14/2006 11:04 AM <DIR> . 09/14/2006 11:04 AM <DIR> .. 07/01/2003 03:27 PM 58,880 AFind.exe 07/01/2003 03:27 PM 190,013 Audited.exe 07/01/2003 03:35 PM 186,942 DACLchk.exe 07/01/2003 03:27 PM 104,960 FileStat.exe 07/01/2003 03:28 PM 51,200 HFind.exe 07/01/2003 03:28 PM 43,008 Hunt.exe 07/01/2003 03:28 PM 51,712 SFind.exe 11/02/2000 09:34 AM 5,087 terms_of_use.txt 8 File(s) 691,802 bytes 2 Dir(s) 11,338,084,352 bytes free C:\ftk>hfind.exeSearching... C:\ftk BOSERVER.EXE 14/09/2006 11:04:52 Finished
I first ran the dir command to get a list of all of the unhidden files in the current directory, and then I ran hfind.exe for a list of hidden files. This was mostly for the sake of demonstration. Note that I ran Hfind without any options. This causes Hfind to search the current directory for hidden files, then continue to recurse into subdirectories in search of hidden files. Hfind does take a couple of simple arguments:
-nsTells hfind.exe to search only the current directory for hidden files.
-?Prints out a usage statement.
Hfind takes one more argument (sans flag) that specifies a directory to search. Without this argument, it assumes a search in the current working directory.
If you are looking for a list of hidden files only, then this is a great tool. Otherwise, it might be worth your time to simply browse to the folder graphically and make sure that the "Show hidden files and folders" option is enabled in the Tools → Folder Options → View tab.
Alternate data streams offer a much better method for hiding files on an NTFS filesystem. By embedding a file within an alternate stream to another file, malicious files and content may be effectively hidden due to there being a lack of native Windows tools for establishing what files contain these alternate streams. Sfind.exe is used to find these files.
Here, a search of the C:\WINDOWS\system32 directory turns up a backdoor and a scanning utility hidden in alternate data streams for the calc.exe binary:
C:\ftk>sfind c:\windows\system32
Searching...
c:\windows\system32
calc.exe:boserver.exe Size: 106496
calc.exe:scanner.exe Size: 20370
FinishedSfind returns a list of each alternate data stream, along with the original filename and size of the alternate stream, in the following format:
Filename:Alternate_streamSize:streamsize
Though somewhat rare, there are some legitimate uses of alternate data streams. Often, you may encounter streams called Zone.Identifier and encryptable. They are used to pass persistent file-specific information to the applications that access them frequently. If legitimate, they will usually have a very small size; e.g., 26 bytes in the case of the Zone.Identifier tags that I have seen.
Usage of Sfind follows the exact same format as that of Hfind.
After finding some strange files to look at, you need to get a little more information about them to know whether or not they were involved in the same security incident that you are investigating. FileStat, included with the FTK, can be called on each file to get some more information about each. FileStat gives us a dump of all the NTFS file information about the file. What you should care most about are the security attributes, alternate data streams, and timestamps. Though you can access some of the information listed by FileStat using native Windows tools, these utilities might modify potentially important information, such as the Last Access Time timestamp. Luckily, Filestat leaves the timestamps unmolested.
Usage for Filestat is as simple as it gets. It can be called on only one file at a time. Run it from the command line by supplying the filename as an argument; as with all FTK tools, running it with the -? flag prints out a usage summary.
Example 21-2 shows what happens when Filestat runs on the backdoor-laden calc.exe I found while using Sfind in the earlier section "Sfind.exe: Discover Files Hidden in Alternate Data Streams."
Example 21-2. Output from Filestat when run on an example backdoor
1C:\ftk>filestat c:\windows\system32\calc.exe2Dumping c:\windows\system32\calc.exe...3SD is valid.4SD is 144 bytes long.5SD revision is 1 == SECURITY_DESCRIPTOR_REVISION16SD's Owner is Not NULL7SD's Owner-Defaulted flag is FALSE8SID = BUILTIN/Administrators S-1-5-32-5449SD's Group-Defaulted flag is FALSE10SID = NT AUTHORITY/SYSTEM S-1-5-1811SD's DACL is Present12SD's DACL-Defaulted flag is FALSE13ACL has 4 ACE(s), 96 bytes used, 0 bytes free14ACL revision is 2 == ACL_REVISION215SID = BUILTIN/Users S-1-5-32-54516ACE 0 is an ACCESS_ALLOWED_ACE_TYPE17ACE 0 size = 2418ACE 0 flags = 0x0019ACE 0 mask = 0x001200a9 -R -X20SID = BUILTIN/Administrators S-1-5-32-54421ACE 1 is an ACCESS_ALLOWED_ACE_TYPE22ACE 1 size = 2423ACE 1 flags = 0x0024ACE 1 mask = 0x001f01ff -R -W -X -D -DEL_CHILD -CHANGE_PERMS -TAKE_OWN25SID = NT AUTHORITY/SYSTEM S-1-5-1826ACE 2 is an ACCESS_ALLOWED_ACE_TYPE27ACE 2 size = 2028ACE 2 flags = 0x0029ACE 2 mask = 0x001f01ff -R -W -X -D -DEL_CHILD -CHANGE_PERMS -TAKE_OWN30SID = /Everyone S-1-1-031ACE 3 is an ACCESS_ALLOWED_ACE_TYPE32ACE 3 size = 2033ACE 3 flags = 0x0034ACE 3 mask = 0x001200a9 -R -X35SD's SACL is Not Present36Stream 1:37Type: Security38Stream name = ?↕?? Size: 1443940Stream 2:41Type: Data42Stream name = ?↕?? Size: 1146884344Stream 3:45Type: Alternate Stream46Stream name = boserver.exe Size: 1064964748Stream 4:49Type: Alternate Stream50Stream name = scanner.exe Size: 203705152Stream 5:53Type: Unknown54Stream name = scanner.exe Size: 645556Creation Time - 07/11/2005 13:54:1157Last Mod Time - 12/09/2006 11:52:5358Last Access Time - 12/09/2006 11:52:5359Main File Size - 11468860File Attrib Mask - Arch Comp61Dump complete...
I have numbered the output from Filestat for ease of explanation; the sections of important information are not clearly labeled, but become easy to identify after some inspection.
The first 35 lines of the output here are a dump and validation of the file's Security Descriptor. This section describes which users or groups can read, modify, and execute the file. (A full explanation of the Security Descriptor is available from http://technet2.microsoft.com/windowsserver/en/library/.) We are most concerned with which users have full access to the file and just how much access they have. It is worth having a look at which users are on the Access Control List (ACL) and how much access they have. Lines 12 through 34 describe a default ACL for files in a Windows system directory. All users have Read and Execute permissions, but only Administrators and the System user have the ability to modify these files.
After a breakdown of the Security Descriptor, Filestat provides a dump of all streams present in the file, identified numerically (for example, Stream 1, Stream 2, and so on). In this case, the file has five streams (not normal), identified here in lines 36 through 55. Each stream is presented with a stream type, name, and size. On an NTFS filesystem, the first two streams are standard. Stream 1, with a stream type of security, is the Security Descriptor that was previously examined. Stream 2, with a stream type of data, is the content of the file; in this case, the binary that runs the Windows calculator. Streams 3 through 5 should be considered very suspicious. They are labeled with a stream type of Alternate Stream, named as executables and size-wise far too large to be legitimate usage alternate streams (for example, a short Zone.Identifier stream). In the case of this evil calculator, it looks like there is both a backdoor and a scanner application hidden here.
The last important tidbits of information about this file are the timestamps. Filestat provides three timestamps, starting on line 56.
The time the file was created. Once created, unless modified by some trickery, this value should never change. In this case, since calc.exe is a file installed as part of the default installation, the Creation Time probably represents the time of its build. If this were a log file created by our intruder, it might tell us a bit more about when the hacker got started with the funny business.
The last time any changes were made to the file. Time to start asking questions and look a bit deeper. Were permissions changed? Did the hacker hide the scanner executable at this time?
The time that this file was last accessed. This could be something as simple as viewing the file properties in the Windows Explorer or opening it for reading. If you have been careful not to touch it yet, this may be a good indicator of when the hacker last used this file.
That is it. Run it on a few known illegitimate files and a few legit ones too. Though the output is not the most user friendly, checking the differences in a few files should give you a good feel for it.
Interacting with an alternate data stream in an existing file is generally very simple. You address it in the file:stream format. For example, to access the scanner.exe stream hidden in the system calculator, you use the following command:
C:\windows\system32>start .\calc.exe:scanner.exe
Or, if you wanted to separate the scanner stream from calc.exe into its own file, you could do this:
C:\windows\system32>more < calc.exe:scanner.exe > scanner.exe
Because certain programs do not understand the syntax required to interact with a stream, you have to become creative. For more information on interacting with alternate data streams, check out the following web sites: