The goal of the freeze script is simple: to halt most of the running processes on a system that may have been hacked so that potential malicious applications are stopped in their tracks. This allows a forensic analyst to examine the state of the system without worrying about a malicious app that would otherwise have continued to run.

The "freeze" script gathers all the PID's on a system and sends a "kill -STOP" to every PID on the system except for:

Now that all the pids except for the above are halted, the analyst can take their time in examining the state of the running system. I had thought a memory image could be copied from /proc/{pid}/mem to offsystem storage, but can't seem to make that happen at the moment.

Known good apps can be restarted by hand with "kill -CONT {pid}" or "killall -CONT httpd". If the analyst doesn't care about the state of the application, it can simply be killed off with "killall -9 httpd".

Known malicious apps can be examined with gdb, simply killed outright with "kill -9 {pid}", or killed with a core file left for future analysis with "kill -ABRT {pid}".

Unfreezing the system is a one line command:

cd /proc ; kill -CONT [0-9]*


The tool is a shell script, and so depends on known good copies of bash/sh, awk, grep, ls, pgrep, and tty. For that reason, I'll be putting a copy of this on the Static binary CD at .

The script also depends on having the kernel return correct information about running processes, so unfortunately, if a kernel module has been loaded, all bets are off. Freeze may work correctly if the module does not alter the process list, but I wouldn't count on it.

If there are any legitimate applications running that have active network connections, the analyst has about two minutes to manually unfreeze those applications without losing those connections, assuming the analyst decides those network connections should not be lost.

The tool is especially useful for malicious code with a panic button (a tool that looks for a disconnected ethernet cable and erases the hard drive if there has been no network activity for, say, 60 seconds). By halting the application entirely, the app has no chance to check that timer and perform a malicious act. Also, any backdoor programs are halted, stopping an attacker that may be currently connected without erasing the daemon he/she was using.

An application could choose to ignore any signal (with the exception of the KILL signal which immediately destroys the application without any attempt at graceful shutdown). For that reason, Freeze reports the pids for which the kill -STOP command failed. I'm considering allowing the analyst to define both a primary signal to send (STOP, by default), and a secondary signal to send if the primary fails for any reason (nothing by default, just report the fact, but an analyst could choose ABRT to create a core file, or KILL to destroy the app entirely).