The FTimes Project The HashDig Project The WebJob Project The PaD Project
Location: / Home / FTimes / FTimes in Action / Intrusion Analysis
FTimes in Action
FTimes
Home
Hidden Directories, Files, and Streams

The term hidden is somewhat misleading. Whether or not a particular directory, file, or stream is hidden is a matter of perspective and visual acuity. In other words, a tool can only see what it is allowed to see. Likewise, it can only see what it was built to see.

For example, in NTFS a file object is implemented as a series of streams. By default, file content is stored in the object's unnamed stream or "::$DATA". However, a user can choose to create and store data in an alternate or named stream (e.g., ":stream:$DATA"). The problem with this is that File Explorer has no mechanism to enumerate these additional streams. Therefore, they remain hidden to the observer because the tool lacks visual acuity. Consider the scenario where a binary such as ls has been Trojanized to hide selected directories or files. This is a case where visual acuity has been actively impaired by the attacker. A third example is that of kernel modification. In this case, File Explorer or ls will be unable to detect the hidden objects because they lack perspective (i.e., it has been altered by the attacker).

FTimes can overcome both of these limitations, but there are scenarios where it can not. If you are strictly using FTimes on an isolated platform where you are analyzing the contents of a previously recorded disk image, you can certainly overcome both limitations. However, if you are runing FTimes on an operational system whose kernel was compromised prior to your arrival, then you can't expect FTimes to overcome either of the limitations. Between those two extremes, FTimes can get a lot of useful work done.

Here's an example of a hidden directory that was discovered on a compromised system. The file names have been URL encoded. Thus, '+++' is actually three spaces.

"/usr/share/man/man5/mansun.5"
"/usr/share/man/man5/math.5"
"/usr/share/man/man5/+++"
"/usr/share/man/man5/+++/.prt"
"/usr/share/man/man5/+++/.prt/prtmap"
"/usr/share/man/man5/+++/.prt/conf"
"/usr/share/man/man5/+++/.prt/prtmap.log"
"/usr/share/man/man5/+++/.prt/show"
"/usr/share/man/man5/me.5"
"/usr/share/man/man5/mm.5" 
Known vs Unknown Signatures

It is easy to determine if a particular file warrants further investigation by comparing its hash with a known good signature. This can lead to such things as identification of Trojan binaries, misconfiguration, abuse of privilege, et cetera.

Even when the system in question has never been baselined, it is still possible to weed out a large percentage of files by comparing collected hashes to a set of known good signatures.

String Searches

As the typical intrusion investigation unfolds, various leads and hypotheses surface. The practitioner can usually extract or develop a set of significant keywords from this information. With FTimes, one can search for these keywords in any type of file (e.g., executable, disk image, etc.).

Timestamp Analysis

Time stamp analysis can be used to correlate activities that occurred on a compromised system. If the compromise is particularly fresh, time stamps can often lead an investigator right to the very areas the intruder was trying to hide. If a compiler was used to create a program whose purpose is not known, time stamp analysis of the various include files used may suggest interesting qualities about the program. For example, if socket.h was accessed during the build, one might conclude that the program has some networking component.

CAUTION: time stamps can also lead an investigator straight over the cliff. This is because they can be altered by the intruder. The forensic examiner must always challenge the assertion that time stamps are somehow truth. They may be the truth, in which case the forensic examiner should look for supporting evidence.

The following segment of real data suggests that someone connected to the ftp server on 2000-09-21 00:48:48 GMT. It appears that they may have executed the ls command, but only on the root directory. Specifically, they did not list files in /ftp/pub. The piece of information that made this interesting was the fact that an IDS posted an FTP Bounce alert at or about the same time. This time stamp cluster suggests that the user who connected did not conform to the normal anonymous ftp profile (i.e., log in as the ftp user, cd into the pub dir, and list or get files). While nothing here is conclusive, one would certainly want to check the log files to determine what hosts were connected to ftp at that time.

2000-09-21 00:48:48|"/ftp/usr/bin/ls"
2000-09-21 00:48:48|"/ftp/usr/lib/ld.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/libc.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/libdl.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/libmp.so.2"
2000-09-21 00:48:48|"/ftp/usr/lib/libnsl.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/libsocket.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/nss_files.so.1"
2000-09-21 00:48:48|"/ftp/usr/lib/nss_nis.so.1"
...
2000-09-21 00:48:48|"/ftp/bin"
2000-09-21 00:48:48|"/ftp/etc/passwd"
2000-09-21 00:48:48|"/ftp/etc/group"
2000-09-21 00:48:48|"/ftp"
2000-03-30 18:18:35|"/ftp/pub"
2000-03-05 04:22:36|"/ftp/usr/bin"
2000-03-05 04:22:36|"/ftp/usr/lib/security"
2000-03-05 04:22:36|"/ftp/usr/lib"

more...

Copyright 2000-2014 The FTimes Project, All Rights Reserved.
The FreeBSD Project SourceForge Logo KoreLogic, Inc.