SANS Digital Forensics and Incident Response Blog: Category - Linux IR

Helix 3 Pro: First Impressions

I have used several versions of Helix over the recent years. I enjoy the tool set and recommend it to forensics colleagues, sysadmins, and even family members.

Quite a substantial ruckus was raised this year when e-fense announced that Helix 3 would no longer be free to download. Instead, would-be users must pay to register as a forum user to get access to Helix 3 Pro updates for a year.

I took the plunge and


Tricking the "script" Command

Keeping a record of all of the commands you type as well as their output is obviously useful during a forensic investigation. On Unix and Linux systems, we have the "script" command which does precisely this. You run "script " and the script command spawns a new shell: everything you type and all output you receive in return is automatically captured to the specified file.

From a forensic perspective, however, the classic problem is that script insists on writing its output to a file in the local file system. This is particularly a problem during the initial stages of incident response when you're operating on a live system trying to verify whether or not it has been compromised. If you capture your session with the script command, you may be trampling important data as your output file grows. Of course you could attach a portable storage device and write your output there, but that could be problematic on many levels.

This topic came up recently

... Continue reading Tricking the "script" Command

Directory Link Counts and Hidden Directories

by Hal Pomeranz, Deer Run Associates

One of the things I love about teaching at SANS is that the students are smart people and come up with great ideas. Sometimes these ideas even lead to useful tools, as was the case a few years ago when we were talking about hidden directories in the Digital Forensics section of Sec506.

First, a little background information. Unix file systems keep track of a "link count" to all objects in the file system. This "link count" value is the number of different directory entries that all point to the inode associated with the object. In the case of a regular file, the link count is the number of hard links to that file.

However, Unix file systems don't let you create hard links to


Google Privacy tip of the day

by Jeff Bryner

If I keep writing on Google and forensics, they'll probably re-arrange my searches someday to all return kittenwar. However, just for you I'll sacrifice my sanity to pass on a helpfull tidbit about Google Toolbar.

Whether you're looking to determine information about what's in the toolbar, or looking to protect your privacy you may be interested to know that on startup the toolbar retrieves the favicon.ico file of all sites in your bookmark list.

I don't normally use it, but in deciphering some web traffic I had a hunch to work out so I tested it against XP and IE. I bookmarked two sites, rebooted and restarted IE with a blank home page. The network traffic on


Recovering Open But Unlinked File Data

By Hal Pomeranz, Deer Run Associates

If you've ever been a Unix system administrator, you may have encountered "open but unlinked" files in the course of your normal duties. The typical scenario is a user who's launched a process that creates an unexpectedly large output file which consumes all of the free space in the partition. In a panic, the user deletes the output file but leaves the process running. Unfortunately, the operating system is not allowed to reclaim the space until the last process that has the output file open actually exits. So until the user kills their process, the space is still in use and the file system is full. But when you as the system administrator logs in to free some space in the partition, you're unable to find the massive file that's consuming all of the space with your normal file system