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...
|
