File Analysis (Windows Forensic Analysis) Part 7

Image Files

Word processing files aren’t the only files that maintain internal metadata. In February 2006, an article about a bot-herder (someone who infects systems with bots and then manages and even rents those networks) in the Washington Post Magazine included a JPEG image in the online version of the story. Although the author of the story took pains to keep the bot-herder’s identity a secret, the JPEG image included notes from the photographer that stated the location (city and state) where the photo was taken.

The metadata available in a JPEG image depends largely on the application that created or modified it. For example, digital cameras embed Exchangeable Image File Format (EXIF) information in images, which can include the model and manufacturer of the camera (unfortunately, no serial number seems to be either used or stored), and can even store a thumbnail or audio information (EXIF uses the TIFF image file directory format). Applications such as Adobe’s Photoshop have their own set of metadata that they add to JPEG files.

Tools such as Exifer (www.friedemann-schmidt.com/software/exifer/), IrfanView (www.irfanview.com), and the Image::MetaData::JPEG Perl module allow you to view, retrieve, and in some cases modify the metadata embedded in JPEG image files. ProDiscover can also display EXIF data found in a JPEG image. Chris Brown (of Technology Pathways) provides a white paper (http://toorcon.techpathways.com/cs/forums/storage/8/11/EXIF.pdf) that describes the EXIF data and, to a small degree, the format of a JPEG file.

File Signature Analysis

During an investigation, you might come across files with unusual extensions or files with familiar extensions that are in unusual locations. In such cases, you can use file signature analysis to determine the nature of these files as well as gain some insight into an attacker’s technical abilities. One way to determine the true nature of files, regardless of their extension, is through file signature analysis.

File signature analysis pertains to collecting information from the first 20 bytes of a file and looking for a specific signature or "magic number" that will tell you the type and function of the file. Different file types have different signatures, and these signatures are independent of the file extension. In fact, often the bad guy will change the extension of a file so that when it’s viewed in Windows Explorer, the file will appear with an icon that effectively masks the contents and intent of the file. Once, long ago, on a system far, far away, I was analyzing an IRCbot that I dubbed the russiantopz bot (www.securityfocus.com/infocus/1618). This IRCbot deposited a number of files on the infected system and gave those files .drv and .dll extensions, so when an administrator viewed those files, they would appear to be ominous files that most administrators simply do not open. After all, in most cases when an administrator opens a file with one of those extensions in a hex editor, all he sees is a bunch of binary "stuff." During my analysis, I actually opened those files and was able to see that they contained text information, specifically configuration information and actions that the bot would perform when sent a command.

Forensic analysis tools such as ProDiscover allow the investigator to readily perform file signature analysis and easily view the results. When such tools perform the analysis, they get the file’s extension and compare the signature associated with that extension to the information contained in the first 20 bytes of the file. For example, Windows portable executable (PE) files will begin with the letters MZ (a reference to Mark Zbikowski [http://en.wikipedia.org/ wiki/Mark_Zbikowski], a Microsoft architect), which are located at the first two bytes of the PE file. Executable files can have .exe, .dll, .sys, .ocx, or .drv (to name a few) file extensions, as seen in the headersig.txt file used by ProDiscover as its "database" of file extensions and signatures. In short, if a file has an executable extension, you should expect to see a valid executable signature. Files that do not have valid signatures that match their extensions are flagged for further investigation.

Image files such as JPEG and GIF files also have their own signatures. The signature for a JPEG file is JFIF, and the signature for a GIF file is GIF87a or GIF89a. Figure 5.10 illustrates the signature for a PDF document, or %PDF-, followed by the version of the Portable Document Format for the file.

Figure 5.10 PDF File Signature

The sigs.pl Perl script located on the accompanying DVD will allow you to perform file signature analysis on live systems. The script will examine a file, a directory of files, or all the files in a directory structure to determine whether the file signatures match the file extensions. The script uses that headersig.txt file from Technology Pathways as its default "database" of file signatures; however, other listings of the same format can be used. As the script parses through the files, it will determine whether the file signature matches the extension, but it will also alert the investigator if the file extension is not found in its "database." If this is the case, the script will provide the extension and the signature so that the investigator can update her database, if she deems it necessary to do so. By default, the script sends its output to the console in comma-separated value (.csv) format so that it can be redirected to a file and opened in Excel for easy analysis.

NTFS Alternate Data Streams

An NTFS alternate data stream (ADS) is a feature of the NTFS file system that is neither well known nor understood among members of the system administration community. After all, why would it be? On the surface, ADSes are used "behind the scenes" by several Microsoft applications, so they can’t be bad, right?

Let me put it another way. What if I were to tell you that there is a way to create legitimate files on a Windows system, files that can contain data as well as scripts or executable code, and that these files can be created or launched but that there are no native tools within the operating system distribution that will allow you to detect the presence of arbitrary files. That’s right. The Windows operating system has all the native tools to create, modify, and manipulate ADSes, but no native tools are available to view the existence of arbitrary ADSes. Well, that’s not completely true, because beginning with Vista, the dir command now has a switch to let you see ADSes. We’ll address this in a moment.

So, what are alternate data streams, where do they come from, and how are they used? ADSes are a feature of the NTFS file system that were introduced beginning with Windows NT 3.1. ADSes were added to the file system to support the Hierarchical File System (HFS) used by the Macintosh. HFS employs resource forks so that the file system can maintain metadata about the file, such as icons, menus, or dialog boxes. This functionality was incorporated into the NTFS file system but was never something that was widely discussed. In fact, for the longest time, there was very little discussion of ADSes and very little information available on the topic, even from Microsoft. Although Microsoft applications and functionality in the shell allow for the creation of specific ADSes, the fact remains that there is very little operational, day-to-day use for ADSes. Bad guys have picked up on this and have used ADSes to hide tools, even as part of rootkits. This is an effective approach because some antivirus utilities either do not scan ADSes or do not do so by default. Therefore, malware that is dropped onto a system in an ADS might not be detected or removed/quarantined by the antivirus application.

Notes from the Underground…

Using ADSes

In the late 1990s, as a consultant, I was involved in a number of penetration tests and vulnerability assessments. During a penetration test, if we gained access to a Windows system and had authorization to do so, we’d leave an ADS on the system. This had no effect other than to consume a few bytes, because we left only a text message. However, this was our way of telling the system administrator, "Tag, you’re it!" and to provide proof that we’d gotten as far as we said we had. I have spoken to other pen testers who will copy all their tools over to a compromised system into ADSes.

Creating ADSes

Creating an ADS is relatively simple; heck, some Microsoft applications do it automatically. Any user can do it, as long as the user has the ability to create a file. For example, the simplest way to create an ADS is to type the following command:

You’ll initially see a dialog box that will ask you whether you want to create a new file. Click Yes, add some text to the window, save the file, and then close the Notepad window. At this point, if you type dir, you’ll see that the file myfile.txt is zero bytes in size, although you just typed a bunch of text into Notepad.

Another way to create an ADS is to use the echo command:

Okay, so you’ve created two ADSes, and whether you type dir or view the contents of the directory in Windows Explorer, you’ll see a single file in the directory, and that file will be zero bytes in size.

Yet another way to create an ADS is to use the type command to copy another file into an ADS:

So, now what you’ve done is copied the contents of the file called sol.exe (which is the Solitaire card game on Windows 2000, XP, and 2003) into an ADS. You can run these same commands on Vista to create ADSes, although for some applications (such as the Solitaire game) the paths to the executable files might be different.

You can add ADSes to directory listings as well, using the following syntax:

Notice that no specific filename was provided. This causes the ADS to be attached to the directory listing; in this case, D:\ads.

ADSes will also be created in other ways, often without you ever being aware of it. When you right-click a file and choose Properties, one of the tabs you see is called Summary (interestingly enough, this tab doesn’t seem to be available on Vista). You can enter just about anything in the various text fields, and when you save the information by clicking OK, the information is saved in an ADS (unless you’re working with an Office document, in which case the information you entered is saved within the structured storage or OLE document itself).

Further, the Attachment Manager (http://support.microsoft.com/kb/883260) which is part of Windows XP SP2 will add an ADS to files downloaded from the Internet or retrieved as file attachments from an e-mail (via Internet Explorer and Outlook, respectively). When you download a file through Internet Explorer, the file will be written to whichever location you choose and an ADS named Zone.Identifier will be appended to the file (assuming that the file system is NTFS, of course; otherwise, per Knowledge Base article 883260, the Attachment Manager will fail silently). The ADS is added to the file so that when the user attempts to execute or open the file, he is presented with a warning dialog box that notifies him that the file might not be safe to open.

Enumerating ADSes

Now that you’ve created several ADSes, how do you go about detecting them? As I mentioned before, there are no tools native to Windows systems that allow you to enumerate arbitrary ADSes. You can’t see them through Windows Explorer, and the dir command is equally useless. Well, that last statement isn’t exactly true; Vista has a switch that allows you to enumerate ADSes with dir using the /r switch, as Figure 5.11 illustrates.

Figure 5.11 Example of Enumerating ADSes on Vista

Figure 5.11 shows the results of running the dir /r command on Vista after creating several ADSes in a similar manner as we did in the "Creating ADSes" section (in that section, we created ADSes on XP).

With the other Windows operating systems (2000, XP, and 2003), you need to get outside help to enumerate ADSes. My favorite is lads.exe (www.heysoft.de/Frames/f_sw_la_en. htm), written by Frank Heyne. Lads.exe is a command-line interface (CLI) tool that you can run against any directory.

Lads.exe is just one of the available tools that allow you to enumerate ADSes on Windows. There are others that are also CLI tools, there are GUI tools, and there are even some that install as shell plug-ins so that you can enumerate ADSes via the Windows Explorer user interface.

ADSes added to a file by adding summary information to the file (mentioned in the previous section) appear somewhat different from the ADSes we’ve already added. For example, if we add summary information to myfile.txt and then run lads.exe again, we see:

From the output of lads.exe, we can see that three additional ADSes have been added to myfile.txt: one that appears as a globally unique identifier or GUID (and is 0 bytes in size) and two others that start with *. These last two are where the information entered into the Properties | Summary tab is saved.

Sometimes you may see an ADS named AFP_AfpInfo or AFP_Resource. If you see an ADS named in this manner, you should check to see whether the File Services for Macintosh service is installed and enabled on your system. If so, the unnamed stream might have been copied from a Macintosh system via the AppleTalk protocol. When this occurs, the data fork for the file is saved to a filename, such as myfile.txt. The resource fork is then saved to myfile. txt:AFP_Resource, and the finder or attribute information is saved to myfile.txt:AFP_AfpInfo.

As previously mentioned, other tools exist for enumerating ADSes. Streams.exe (a Sysinternals tool available from Microsoft), lns.exe (from Arne Vidstrom, at NTSecurity.nu), and sfind.exe (part of the Forensic Toolkit available from Foundstone.com) are CLI tools similar to lads. exe. ADS Detector is a shell (i.e., Windows Explorer) plug-in from CodeProject.com that allows for "visual real-time viewing of a nonencrypted file’s alternative data streams." Finally, CrucialADS (from CrucialSecurity.com) and ADS Spy (from SpyWareInfo.com) are GUI-based tools for enumerating ADSes. ADS Spy, illustrated in Figure 5.12, also allows the user to delete selected ADSes.

Figure 5.12 ADS Spy GUI

Once you’ve located an ADS, you can view the contents of the file by opening it in Notepad or by using the cat utility, part of the UnxUtils package on SourceForge.net. You can use cat to view the contents of an ADS at the console (i.e., STDOUT) or by redirecting the output of the command to a separate file.

Warning::

In 2000, Benny and Ratter, then of the virus-writing group known as 29A (the hexadecimal representation for 666), released a virus named W2K. Stream that used ADSes. The virus would infect a file, replace it, and then copy the original file into an ADS. For example, if the virus infected notepad. exe, it would replace the executable file and copy the original Notepad into Notepad.exe:STR. This worked only on NTFS-formatted systems. If the file system was formatted as a FAT file system, there was no ADS, and all you were left with was the infected file.

In June 2006, the F-Secure antivirus company blog contained an entry that described the Mailbot.AZ (a.k.a. Rustock.A) kernel-mode rootkit driver that makes detection especially difficult by hiding itself in an ADS. Further, the ADS reportedly cannot be enumerated by tools that detect ADSes, because it is hidden by the rootkit. Very tricky!

Using ADSes

So, you’re probably wondering, what can ADSes be used for besides hiding data? As it turns out, they can be used for a number of things. For example, you can put an executable file into an ADS and run it from there. Use the type command, just as we did before, to place an executable in an ADS, like so:

In this case, we’ve placed the Solitaire game in an ADS. This is a good example to use because when run, it results in a nice GUI that lets us see that things are working properly. To execute the program, type the following command:

As you can see, we’re presented with the Solitaire GUI. And this isn’t restricted to executables, because scripts (Windows Scripting Host [WSH], Perl, etc.) can be hidden in

ADSes and launched just as easily. The WSH tools (cscript.exe, wscript.exe) will run scripts hidden in ADSes with no trouble, as will Perl; even the IIS Web server will serve up HTML and script files hidden in ADSes (which is a great way to grade "capture the flag" events).

Attempting to execute an ADS on Vista returns a different result, as Figure 5.13 illustrates.

Figure 5.13 Dialog Box Returned When You Attempt to Execute an ADS on Vista

Attempts to launch the ADS (myfile.txt:ads3.exe contains the Vista version of Solitaire) were met with the same result, including variations of the start command as well as using Start | Run. However, launching WSH scripts from within an ADS worked without any issues on Vista.

Another interesting use for ADSes is in hiding media. Movies and podcasts can be hidden in ADSes, and then the Windows Media Player can be launched from the command line to open the media:

I listened to an edition of the CyberSpeak podcast this way. Interestingly enough, although the podcast was launched from the command line, the filename appeared in the following Registry key:

The entry was listed in the data associated with the FileO value, indicating that whenever a new file is added to this list, the filename is added to the top of the list and the older filenames are pushed down the list; the smaller the file number, the more recent the file. As you learned in next topic, getting the LastWriteTime from the Registry key will tell you when that file was accessed via the Windows Media Player.

Warning::

When looking at a sample case in ProDiscover, I noticed that there were several ADSes in the Recycle Bin. ProDiscover displays ADSes with a red-colored font so that they stand out and are obvious. I had deleted some files I’d been working with, one of which I downloaded from the Internet. I noticed that the Zone.Identifier ADS was visible for the file (I had downloaded the file via Internet Explorer) but that the record count for the total number of files via the INFO2 file did not reflect the existence of the ADS.

Removing ADSes

Now that you’ve seen how ADSes can be created and used, what can you do about removing them? There are several ways to go about this, and the way you choose depends on your needs and preferences.

One way to remove an ADS is to simply delete the file to which the ADS is attached. However, the obvious result is that if the original file was important to you (document, spreadsheet, image file), you lose that data.

To save your original data, you might want to use the type command to copy the contents of the original unnamed stream (in our example, myfile.txt) to another filename and then delete the original file. Another option is to copy the file to non-NTFS media. Remember, ADSes are an NTFS feature, so copying the file to a floppy disk (remember those?), thumb drive, or another partition formatted in FAT, FAT32, or some other file system (FTP file to a Linux-system-formatted ext2 and then back again) will effectively remove the ADS.

But what if the ADS you’ve detected is attached to a directory listing, such as C:\ or C:\windows\system32? You can’t just delete the directory, and copying it to and from another file system is going to be a bit cumbersome. So, what do you do? Using the echo command, you can reduce the ADS to a harmless text file, regardless of its contents. From our previous example of copying the Solitaire game into an ADS, we can run lads.exe and get information about that ADS:

Okay, so we have an ADS that is 56,832 bytes in size, and we already know this is an executable file. So, type in the following command:

Rerunning lads.exe, we see that the file size has changed:

So, we’ve effectively "taken care of" the ADS; although we didn’t delete it, we rendered it harmless. You can even write a message to the ADS stating the nature of the ADS you located, your name, and when you deleted it.

Finally, another option is to use the ADS Spy GUI application mentioned previously.

ADS Summary

At this point, we’ve covered a lot of information about ADSes, discussing how they are created and how they can be used and removed. This information is important to keep in mind when you’re performing either incident response or computer forensic activities. ADSes are unusual enough that commercial forensic analysis tools such as ProDiscover display ADSes in red. However, not all ADSes are malicious in nature; you saw how some applications use ADSes simply as part of how they operate.

One thing investigators should keep in mind is to view the contents of an ADS. Just because an ADS is named using one of the naming schemes employed by known, legitimate applications doesn’t mean that what’s in the ADS isn’t malicious. That is to say, do not simply write off the ADS as benign because it’s named AFP_AfpInfo. Bad guys love to hide malware in plain sight by naming it something an administrator or forensic analyst will most likely overlook.