1. COEN 250 Computer Forensics Unix System Life Response

2. Creating a Response Toolkit  Toolkits depend on the OS.  Often, need to compile tools from source.  Many Unix versions are not compatible.

3. Creating a Response Toolkit  Tools on the system are often Trojaned.  Much more than on Windows machines.  Statically link tools.  http://www.incident-response.org

4. Store information  On local hard drive.  On remote media (floppies, USB, tape)  Record information by hand.  Use netcat or cryptcat to transfer to a forensic workstation over the net.

5. Collecting Data before a Forensic Duplication  System date and time.  Currently logged-on users.  Time/date stamps for the entire file system.  List of currently open sockets.  Application listening on these sockets.  List of recent connections.

6. Collecting Data before a Forensic Duplication  Create a trusted shell.  Exit X-windows or other GUI  Log on with root privileges  Mount floppy: mount /dev/fd0 /mnt/floppy  Run shell from floppy (bash)  Set path to. (dot)

7. Collecting Data before a Forensic Duplication  Use “date” for the time.  Use “w” for current users.  Use ls recursively (R) to record access times, starting at /.  ls –alRu / > floppy/atime  ls –alRc / > floppy/ctime  ls –alR / > floppy/mtime

8. Collecting Data before a Forensic Duplication  Alternative  find / printf “%m;%Ax;%AT;%TX;%TT;%Cx;%CT;%U;% G%s;%p\n”

9. Collecting Data before a Forensic Duplication  Find open TCP / UDP ports  Goal:  Find open backdoors  Use “netstat –an” to view all open ports.  Use “netstat –anp” (on Linux) to list all applications associated with open ports.  Check normal use of open ports:  www.portsdb.org (currently down) www.portsdb.org  http://logs.sofaware.com/resolveport/?portnumber=80& protocol=TCP http://logs.sofaware.com/resolveport/?portnumber=80& protocol=TCP  Use “lsof” (list of open files) utility as in “lsof –i –D r”

10. Collecting Data before a Forensic Duplication  Take a snapshot of all running processes  ps –eaf on Solaris  ps –aux on FreeBSD and Linux

11. Collecting Data before a Forensic Duplication  Open Files  lsof

12. Collecting Data before a Forensic Duplication  Internal Routing Table  netstat –rn  Goal: Evidence of man in the middle attack

13. Collecting Data before a Forensic Duplication  Loaded Kernel Module  Used to be standard way to install a rootkit  Use lsmod command  Warning: Knark and other loadable kernel module rootkits will subvert this program

14. Collecting Data before a Forensic Duplication  Mounted File Systems  df command  Example: Mounted NFS shares can be used by an intruder to transfer data

15. Collecting Data before a Forensic Duplication  System version and patch level  uname -a

16. Collecting Data before a Forensic Duplication  Obtain all system logs  /var/run/utmp log contains currently logged on users  Warning: tools like “zap2” delete these entries  http://www.packetstormsecurity.com/ http://www.packetstormsecurity.com/  /var/log/wtmp  History of logins  Syslog logs in syslog.conf

17. Collecting Data before a Forensic Duplication  User accounts  Look for evidence of backdoors in password files  /etc/passwd  For suspicious users, check user history files

18. Collecting Data before a Forensic Duplication  Obtain important config files  Dump System RAM  Often in /proc/kmem or /proc/kcore  Use it for keyword searches

19. Collecting Data before a Forensic Duplication  Suspicious files  Assume attacker runs a binary such as datapipe and then deletes it.  Binary is kept in /proc file system  /proc does not exist on the hard drive  To collect binary image of process pid 1234:  Change into /proc/1234  Copy exe to forensics workstation using cat and netstat  fd directory contains all open files for a particular process.

20. Collecting Data before a Forensic Duplication  Take Date again  Record all steps (script, history)  Record MD5 sums to prevent challenges of changed data.

21. Rootkits  Rootkits: tools to acquire and keep root access.  File Level Rootkits: Trojan  login  ps  find  who  netstat

22. Rootkits  Trojaned login  Works as designed.  But lets one special username in.  Trojaned who  Works as designed.  But does not display the user with the special username.  Provides access and protection

23. Rootkits  Use Tripwire to detect system file alterations.  Use trusted forensics tool to find file level rootkits.

24. Rootkits  Kernel-Level Rootkits  Create their own kernel.  That is, let users live in a virtual reality that they created.  Loadable Kernel Modules (LKM)  Supported by Linux, Solaris, etc.  Allow to add modules to the kernel.

25. Rootkits  Rogue LKM can intercept system commands.  Tripwire will not help, system files are still there and unchanged.

26. Rootkits  Knark  To hide a process, send kill -31.  Knark LKM takes care of the rest.  Forensically sound tools are not circumvented, though.

27. Rootkits  Detection  Look for inconsistencies in the data  Example:  lsof output contains file /tmp/.kde  find does not list /tmp/.kde  Discrepancy is strong hint at existence of a rootkit set to hide /tmp/.kde

28. Sniffers  Used to capture network traffic  Payload are unencrypted login procedures  Payload are email messages  …

29. Sniffers  Ethernet card needs to be in promiscuous mode for sniffing.  Use ifconfig –i eth0  Look for keyword PROMISC  Use lsof to find large output files