Incident Response & Computer Forensics in Software

Creation PDF417 in Software Incident Response & Computer Forensics

When you collect volatile data, you will want to respond to the target system at the console, rather than access it over the network This eliminates the possibility of the attacker monitoring your response and ensures that you are running trusted commands If you are certain that you will be creating a forensic duplication of the target system, you should concentrate on obtaining the volatile system data before powering down the system The volatile data includes currently open sockets, running processes, the contents of system RAM, and the location of unlinked files The unlinked files are files marked for deletion when processes that access it terminate The files marked for deletion will disappear when the system is powered down Therefore, the initial response should recover each type of volatile evidence, including the files marked for deletion! This will save you some grief, because recovering a deleted file in most flavors of Unix is not as simple as running a file undeletion tool Lesson number one when dealing with Unix systems is that you should not shut off the machine before performing an initial response to find files marked for deletion! Although these files may be recoverable during the static analysis of the media, it is much more difficult

At a minimum, you should collect the following information: M I I I I I L System date and time A list of the users who are currently logged on Time/date stamps for the entire file system A list of currently running processes A list of currently open sockets The applications listening on open sockets A list of the systems that have current or recent connections to the system

To collect the live data in this list, you can take these steps: 1 Execute a trusted shell 2 Record the system time and date 3 Determine who is logged on to the system 4 Record modification, creation, and access times of all files 5 Determine open ports 6 List applications associated with open ports

6:

7 Determine the running processes 8 List current and recent connections 9 Record the system time 10 Record the steps taken 11 Record cryptographic checksums Keep in mind that the steps we outline are merely a game plan You will certainly need to tailor the order and the tools used based on the totality of the circumstances You may opt to include tools we do not mention, as well as conduct your steps in a different manner

When an attacker runs a process, he usually deletes the program file he executed from the file system in an effort to hide his actions He is not truly deleting the program on the hard drive The attacker is unlinking the file Unix tracks a file s link count, which is a positive integer representing the number of processes currently using the file When the link count equals zero, that means no process is using or needs the file, so it will be deleted When an attacker deletes his rogue program, the program on the hard drive is removed from the directory chain (so it will not be displayed in an ls listing), the link count is decremented by one, and the file s deletion time is set However, note that the link count does not equal zero until the process terminates Files marked for deletion (these are the unlinked files) at the time a system is powered down whether gracefully (through normal shutdown procedures) or not (you pulled the power cord) will ultimately end up deleted on the system Let s examine why When Unix mounts a file system, a file system dirty bit is set When the operating system goes through a normal shutdown, every process is forced to close The attacker s process terminates normally, and all file handles are closed This means that the link count on the deleted file is set to zero After all processes have exited and other general housekeeping items have been completed, the file system is unmounted, and the file system dirty bit is cleared If the operating system goes through a traumatic shutdown, the file system is left in an unstable state Unlinked files may still have false link counts, and the dirty bit remains set On the next bootup, the file system is mounted, and the operating system detects the nonzero value of the dirty bit Most of the time, the administrator will be forced to wait while the system performs a file system check (fsck) The fsck utility will scan the entire file system for damage If the utility comes across a file with a positive link count and a deletion time set, it will decrement the link count, rendering the file deleted Some versions of fsck will relink the orphaned file to the lost+found directory, but this is not something that you can rely on