Problem This recipe demonstrates how to develop an FTimes snapshot of a compromised (subject) file system and create a MAC/MACH timeline. MAC timelines contain Modified (MTime), Accessed (ATime), and Changed (CTime) timestamps. MACH timelines contain Modified (MTime), Accessed (ATime), Created (CTime), and Changed (ChTime) time stamps -- MACH timelines are specific to NTFS. Motivation During a response, the enterprise must be prepared to collect evidence, analyze harvested data, and construct a timeline that attempts to answer the following questions: - Who was the intruder? - What did the intruder do, and what data was compromised or stolen? - When did the intrusion and associated events take place? - Where did the intrusion take place, where did it enter the network, and where did it originate? - How did the intruder compromise the network/system? - Why did the intruder attack? As leads develop, the timeline can be revised, refined, and annotated until a clear (or clearer) picture emerges. One source of data that should be included in the timeline is MAC/MACH timestamps. Requirements This recipe assumes that a working copy of the subject file system, previously imaged and stored as evidence, has been mounted read-only on your forensic platform (e.g., a UNIX system that supports loopback or vn file systems) under /SUBJECT. This recipe also assumes that all commands are in the search path and that they will be executed from a Bourne shell. Solution The solution is to take a snapshot of the subject file system and construct a MAC/MACH timeline with ftimes-map2mac.pl. 1. Use FTimes to map the /SUBJECT file system. The following command allows you to map the subject file system with default configuration settings. # ftimes --mapauto all-magic /SUBJECT > ftimes.map 2> ftimes.log If you want/need fine-grained control over these settings, you can use --maplean with a configuration file similar to the one shown below. In either case, refer to to the man page for all the details. # ftimes --maplean maplean.cfg --- maplean.cfg --- BaseName=ftimes OutDir=. FieldMask=all-magic Include=/SUBJECT --- maplean.cfg --- 2. Use ftimes-map2mac.pl to create a MAC/MACH timeline: # ftimes-map2mac.pl -e -f ftimes.map > SUBJECT_HOSTNAME_TIMELINE.mac If you are working on NTFS data collected using the Windows NT/2K version of FTimes, add the -w flag to create a MACH timeline. # ftimes-map2mac.pl -e -w -f ftimes.map > SUBJECT_HOSTNAME_TIMELINE.mach The following output along with commentary has been provided as an example to illustrate one possible analysis scenario. From other evidence and logs, you have determined that the subject system was compromised on or about 2004-03-18. Using this as the initial point of reference for the examination, you begin to analyze the timeline. As you correlate MAC timestamps to suspicious activity around 2004-03-18 in both directions, you find two files, tcp_shell.c and ida.c, in /tmp that are one second apart: 2004-03-21 19:16:03|M.C|/SUBJECT/tmp/tcp_shell.c 2004-03-21 19:16:04|M.C|/SUBJECT/tmp/ida.c At 19:20:17, four minutes later, ida.c is accessed along with a number of include files. Note that include files are typically accessed at compile time, and they often provide clues as to the functionality and capabilities of the program being compiled. In this particular case, you observe that inet.h, signal.h, and wait.h were accessed. This suggests that the program has the ability to manipulate IP addresses, send or receive signals, and that it may be able to spawn and/or wait for sub-processes. 2004-03-21 19:20:17|.A.|/SUBJECT/tmp/ida.c 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/arpa/inet.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/limits.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/machine/limits.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/machine/signal.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/machine/trap.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/machine/ucontext.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/netdb.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/signal.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/_posix.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/fcntl.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/filio.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/ioccom.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/ioctl.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/signal.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/sockio.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/syslimits.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/time.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/ttycom.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/ucontext.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/unistd.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/sys/wait.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/time.h 2004-03-21 19:20:17|.A.|/SUBJECT/usr/include/unistd.h 2004-03-21 19:20:19|MAC|/SUBJECT/tmp/ida-x At 19:20:19, a new file ida-x appears. This suggests that ida.c was compiled into ida-x: 2004-03-21 19:20:19|MAC|/SUBJECT/tmp/ida-x Similar activity occurs with tcp_shell.c 16 seconds later, and this time, several library files are accessed as well. Note that it's quite possible that some or all of these include and library files may have been accessed during the compilation of ida.c. 2004-03-21 19:20:35|.A.|/SUBJECT/tmp/tcp_shell.c 2004-03-21 19:20:35|.A.|/SUBJECT/dev/urandom 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/machine/ansi.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/machine/endian.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/machine/param.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/machine/types.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/netinet/in.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/netinet6/in6.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/stdio.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/stdlib.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/string.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/sys/cdefs.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/sys/errno.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/sys/inttypes.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/sys/socket.h 2004-03-21 19:20:35|.A.|/SUBJECT/usr/include/sys/types.h 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/crt1.o 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/crtbegin.o 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/crtend.o 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/crti.o 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/crtn.o 2004-03-21 19:20:36|.A.|/SUBJECT/usr/lib/libgcc.a At 19:20:36, a new file tsh3ll appears. This suggests tcp_shell.c was compiled into tsh3ll: 2004-03-21 19:20:36|MAC|/SUBJECT/tmp/tsh3ll Also, the MTime and CTime for /tmp change at 19:20:36. This suggests that the addition of tsh3ll was the last change made to that directory before the subject system was imaged. 2004-03-21 19:20:36|M.C|/SUBJECT/tmp To confirm ida.c and tcp_shell.c actually reference the include files listed above, you recover and analyze the corresponding source code. This yields the lists shown below. Next, you observe that each of the files in these lists was accessed just prior to the binaries appearing on the subject. Therefore, you conclude that the evidence supports the hypotheses that ida.c and tcp_shell.c were compiled into ida-x and tsh3ll, respectively. However, you are troubled by the fact that you expected to see a corresponding ATime change for gcc (and any other utilities used in the build process). At some point you may need to explain that. For now, it is left as an open issue, and you move on. ida.c: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include tcp_shell.c: #include #include #include #include #include #include #include Note that if the original source files had been deleted, you would naturally attempt to locate and recover them using data recovery techniques. You may also decide to search for them on the Internet or other hosts within your network. Closing Remarks This recipe provided a simple example of how to use ftimes and ftimes-map2mac.pl to create a MAC/MACH timeline. It also provided an example scenario of how such a timeline might be used. Timestamp analysis can provide valuable clues as to what the intruder may have been doing or what files were affected. However, because timestamps can be altered, their implications must be considered carefully (even cautiously). Where possible, attempt to gather evidence that independently supports the story that your timestamps are telling. Credit This recipe is brought to you by Jon Orbeton and Klayton Monroe.