Hiding on a Live System

Data hiding is a subject that I'll probably be posting on quite a bit as time goes on.

Robert Hensing's recent blog entry on advanced hiding techniques is a very interesting read, as he provides a lot of information about areal-world incident.

In his blog entry, Robert covers a topic I've presented on...file signature analysis. Several years ago, I took the EnCase Intro Course, and got interested in this thing called file signature analysis. Now, this doesn't mean generating MD5 hashes and comparing them. File signature analysis involves looking forspecific sequences of bytes in the first 20 bytes of a file. As an exercise, I went home and wrote my own file signature analysis tool in Perl, and I've compiled it as "sigs.exe". The Perl source code for this tool is included on the CD with my book, and the EXE version is included on my web site ...click on the "Tools" link and extract sigs.exe, p2x580.dll, and headersig.txt from the archive. The file signature database used by sigs.exe is available from TechPathways.com, home of the forensics tool ProDiscover.

The FILExt.com site is an excellent resource for file signature information. For example, do a search on the extension "exe", and this is what you'll find this. Notice the section on "Identifying Characters". This is the information that is used to locate executable files on Windows systems. By "executable", I'm also referring to files that may have extensions such as .dll, .sys, .ocx, etc. Keep in mind that file association information is maintained in the Registry, and can be viewed via the 'assoc' and 'ftype' commands.

So, in a nutshell, just because a file has an extension of '.gif', that doesn't mean that the file itself is a GIF image file. In the case of Robert's blog entry, and from what others have relayed to me, it could be an executable file. This technique of changing the extension of the file seems to be one of the more popular methods of hiding things on a Windows system, right behind simply changing the name of the file.

Another search method to use when looking for suspicious files on a system is to look for file and product version information compiled into executables. Robert's blog shows examples of using strings.exe to view this information...tools written in Perl can pull this information from binary files, as well. Something like this can probably be added to the sigs.exe tool, as accessing the first 20 bytes of the file causes the last access time to be modified, so why not get everything you can? Or how about being able to search a system for all non-Microsoft executable files? That would be a pretty nifty tool to have, wouldn't it?

The HackerDefender rootkit can reportedly be detected using RKDetect, a VBS script that runs queries for services using the Service Control Manager via sc.exe, and also via WMI. The output of these two queries are compared for anomolies; ie, does a service appear in one listing that does not appear in the other? This is not a signature-based approach, but instead looks for anomolies. In the case of Robert's blog entry, the "Dynamic Storage Allocation" service would be the anomoly.

Robert goes on in his entry to show how file times can be searched and used to look for events that occurred on the system, even if they aren't logged in the Event Log.

Also, a couple of tools are mentioned in the blog entry, several of which aren't publicly available. Checksym.exe can be found here.

One final note on SFC/WFP...after reading Robert's blog, I took a look on my XP Home system, and found that while Winlogon.exe is in the system32 directory, it is not in the system32\dllcache directory. The same is true on my XP Pro system. As Robert pointed out, SFC/WFP is for reliability, not security...and the process the implements SFC is not itself protected by SFC. This is definitely something to keep in mind.