Forensics FAQ

Tool Analysis

If you have a test network, then you should move any binaries to that network.

General File Analysis

The file command:

When one first compiles a computer program you will find that either the binary is dynamically linked, statically linked, with debug output, or stripped.

Dynamically Linked

Requires the availability of libraries loaded by the operating system.

Statically Linked

All functions are included in the binary. But with a price that the results in much larger executable file. This is typically seen in commercial apps like Netscape, Staroffice, etc.

Debug Output

Includes Debugging Symbols (e.g. variable names, functions, internal symbols, source line numbers, source file information)

Stripped

Discards symbols from object files and makes executable much smaller

It is interesting to note that most "script kiddies" will compile programs straight from the "makefile" without adjusting the properties inside that file. For instance, the default for tfn (TRIBE FLOOD NETWORK) and some other programs compiles the program with debugging symbols. If a hacker is smart and he is good he will statically link his executable and then strip it. This would make the binary VERY hard to take apart. But luckily for us security types and forensic experts, most hackers do not go to this detail. But THE GOOD ONES WILL!!!

The strings command:

The strings -a command will display printable characters sequences that are at least 4 characters long and the -a command shows all strings in the binary file.

You can tell a BUNCH from just this alone. Compare it against strings of other binaries so you get used to knowing what to look for.

The grep command:

Hopefully I dont need to go into too much detail here.

Non-Running Program File Analysis

The Unix Debuggers

gdb, xxgdb, memprof

Allows the actions taken in a program to be monitored

displays function and variable names

strace

System Call Tracer

Wiretap on the interactions between a program and the operating system

displays information on file access, network access, memory access, and tons of other calls

Drawback is that the program is actually run (USE A STANDALONE MACHINE!)

ltrace

log every library routine call

nm

display compiler and runtime linker symbol table

ldd

identify dynamic libraries used

Running Program Analysis

Finally once you have gotten this far execute the program on a stand-alone machine OR if you have a program in MEMORY that no longer resides on the box itself you need to do the following. DO NOT CONNECT TO THE PORT THE PROGRAM IS RUNNING ON (BAD THINGS COULD HAPPEN!).

If you are on a live box. SUSPEND the process until you have figured out what it is. KILL -STOP <pid>

the /proc directory

pseudo-filesystem which is used as an interface to kernel data structures

contains links to executable code (EVEN IF DELETED---> CAN RETRIEVE BINARY OF A DELETED PROCESS )

File Descriptors (EVEN IF UNLINKED--> CAN RETRIEVE CONTENTS OF AN UNLINKED FILE)

there is a Numerical Subdirectory for each Running Process

To Attain a Process

1. Identify the Process ID of the Target Process Using
   • ps -auxeww for command, environment, and more
   • reviewing contents of /proc
   • using network monitor logs
   • using the program lsof
2. Change directories to the /proc/<pid>
3. Copy the exe Link to your chosen destination
4. Once you have the binary. Do the initial file analysis, the debugging, etc...

For Solaris:

object/a.out (program file)

ms (process memory)

map (memory map)

For Linux

exe (program file)

mem (process memory)

maps (memory map)

For FreeBSD

file (program file)

mem (process memory)

map (memory map)

The top command

useful process information

The lsof command

This program will list all the open files and sockets on a system. You will be able to tell if something is listening for connections.

You can see the inode of the files and configuration files that were used. This is useful if you want to look at the inodes that had deleted files in their place. You should be able to pull out the data.

You can see the libraries that are used with the program. Really easy to see sniffers here. (PCAP?)

run lsof -p <pid>

The gcore command (or reasonable derivatives)

Note: gcore is not available on LINUX but other alternatives exist)

This program will produce a core file dump from the running process. VERY useful if you would run strings on it.

If you have any question please contact me at rob AT karrde DOT com.