Today the UNIX trademark and specification are controlled by the Open Group (www.unix.org/what_is_unix.html). There is a certification program to determine if an operating system (or portion thereof) meets the specification. As there is a cost associated with this process, the free Unix variants are not UNIX certified, and thus are not “UNIX.” To avoid confusion, we will refer to all systems that share common Unix characteristics as Unix-like.

Linux is used to describe any number of operating systems based upon the Linux kernel. These systems generally use code from the GNU project for the core of their userland utilities, and thus you may hear the term GNU/Linux used as well. It can be argued that the more cumbersome GNU/Linux is a more correct description of the total system, however Linux is the more common usage. Linux systems are packaged in distributions. A distribution generically refers to a collection of applications and a Linux kernel. These are usually wrapped together on installation media, and will often come with specific branding, distribution-specific modifications, and a package management system to enable the addition of new or updated software. Popular general purpose distributions include RedHat/Fedora, Ubuntu, Slackware, and SuSE.

Many purpose-specific distributions exist. These are generally stripped down compared to their general-use counterparts, and include distributions designed to operate as web application platforms, wireless routers, firewalls and intrusion detection systems, digital video recorders, and many more. Linux also powers large clusters of low-end computers that operate as a single super-computer. Examples of this setup include the most powerful ranked supercomputing cluster in the world at Los Alamos National Laboratory (www.top500.org/system/9707) and the infrastructure behind Google (http://highscalability.com/google-architecture). At the other end of the scale, Linux powers the current generation of ultraportable netbooks, including the ASUS Eee PC and the One Laptop per Child project.

Given the steady increase in use, it is increasingly probable that at some point in your career you will need to investigate a Linux-based system. Fortunately, familiarity with Linux will transfer over to the other Unix-like systems to varying degrees. At the very least you will be better off knowing Linux than not knowing any Unix-like systems at all.

“The BSDs” refers to the line of Unix-like systems that can trace their origins (directly or indirectly) to the 4.4BSD lineage. Today, this includes FreeBSD, NetBSD, and OpenBSD, FreeBSD being the most widely used of the three. To make very broad generalizations, FreeBSD is used in applications where network throughput and stability is the highest priority, OpenBSD is used in applications where security is the paramount concern, and NetBSD is used when hardware portability is desired. This is not to say that OpenBSD or NetBSD are any less reliable than FreeBSD—after all, NetBSD originated as a fork of the FreeBSD code, and OpenBSD originated as a fork of NetBSD. However, OpenBSD is designed with security as its priority, and NetBSD is designed to be as portable as possible, with ports existing for the Sega Dreamcast and the DEC VAX.

BSD-based desktops and laptops are few and far between, but they do exist (www.pcbsd.org). You are most likely to encounter a BSD-based machine if your investigation involves a web server; particularly of a hosting provider or other enterprise-level web service.

There are a number of Unix-like systems developed by computer companies for their specific hardware, including Sun, IBM, Hewlett Packard (HP), and Silicon Graphics, Inc. (SGI).

Solaris is Sun Microsystem's commercial Unix offering that originated in 1992 and is still used extensively in corporate data centers. Originally developed for Sun's own SPARC processor, modern Solaris runs capably on both 32- and 64-bit Intel x86 processors. Additionally, Sun moved to an open source model in 2005 with the release of OpenSolaris. Strengths of Solaris include the ZFS file system, which is capable of holding a 16 exabyte file (should this ever become physically possible), and robust clustering and virtualization support. Solaris systems are not commonly used by individuals, but can be found in business use. If your investigation brings you to one Solaris system, there is a good chance you will end up investigating many more.

AIX is IBM's commercial Unix, which runs on IBM systems using POWER processors. AIX systems are often deployed to run a specific application or applications that leverage the DB2 database and robust availability. AIX is closely tied to the IBM hardware it runs on, and has a reputation for incredible reliability. Due to the cost of the required hardware, AIX systems are almost never seen outside of corporate use. As with Solaris systems, if you need to investigate one system, be prepared to encounter many more.

HP-UX is HP's commercial Unix, which is tied closely to the HP hardware on which it runs. It has similar positives (reliability, clustering) and negatives (cost) compared to the other commercial Unixes. It is also not usually found outside of corporate data centers, and is also generally found in large deployments.

IRIX is a commercial Unix developed by SGI for their hardware that was widely used to support computer animation and graphical rendering.

In this chapter we will focus primarily on Linux but will make an effort to point out differences and caveats when dealing with other systems where applicable. For the most part, userland utilities are either identical or have interoperable analogs on all the Unix-like systems—dealing with kernel-level information and hardware access is where things diverge quickly.

In addition to being the most common init style across Linux distributions, System V init is also used by Solaris and HP-UX. System V init reads the /etc/inittab file to determine the default runlevel. A runlevel is a numeric descriptor for the set of scripts a machine will execute for a given state. On most Linux distributions, runlevel 3 is synonymous with a full multi-user console (i.e., command line) environment, whereas runlevel 5 is a graphical environment.

Note that each entry in a runlevel directory is actually a symbolic link to a script in /etc/init.d/ that will be started or stopped depending on the name of the symlink. Each script contains myriad variables and actions that will be taken to start or stop the service gracefully.

As you can see in Figure 6.1, there are numerous places an intruder can set up a script to help them maintain persistent access to a compromised system. Careful review of all of the scripts involved in the boot process is mandatory in such a scenario.

The BSD init process is a bit less complex. BSD init reads the script at /etc/rc to determine what system services are to be run, configuration information is read from /etc/rc.conf, and additional services to run from /etc/rc.local. This is the extent of init configuration for OpenBSD, whereas current FreeBSD and NetBSD also read additional startup scripts from the /etc/rc.d/ directory.

The Unix date-time format is a 32-bit value representing the number of seconds since 00:00:00 on 1st January 1970.

On Unix systems, file system date-time stamps are set in UTC, making it necessary to adjust file system dates to the correct time zone. The time zone settings on most Unix systems are stored in a file that is referenced by the /etc/localtime symbolic link. For instance, the following Perl command converts a Unix date-time stamp to local time (e.g., US Eastern time zone).

Unix systems maintain up to four date-time stamps. Each of the four timestamps stored in an Ext inode are updated by different actions. We'll address them in their most commonly referenced order: (M) A C (and D).

The M-time (modification) is updated when the content of a file or directory is modified. For a file, this is triggered by any alteration of the content. The content of a directory's blocks is filenames, so the deletion or creation of a file in a directory will cause its M-time to update.

The A-time (access) is the most frequently updated—this will change whenever the content of a file or directory is read. Actions that cause the content of a file to be read include copying, moving from one volume to another, or simply opening the file. As mentioned previously, directories are simply files that have filenames as their content, so listing the contents of a directory is sufficient to cause that directory's A-time to be updated. Additionally, reading the content of any file will cause the A-time of that file as well as the directory containing that file to be updated.

The C-time (change time) is updated when the inode is altered. This happens when any of the metadata for a file or directory is changed, including either of the previously mentioned timestamps, a file or directory being copied or moved, or the permissions of a file or directory being modified. The C-time is not to be mistaken with the creation date of a file.

Finally, the D-time is updated when a file was deleted. This timestamp will only be set in deleted inodes.

Macintosh systems running Unix operating systems have additional date-time stamps as detailed in Chapter 7, “Macintosh Forensic Analysis.”

On Unix systems, altering the modification or access time of any file is trivially done using the touch command. However, altering either of these timestamps in this manner updates the C-time. Additionally, preventing the updating of access times at all can be achieved using the noatime option to the mount command. When examining a machine possibly controlled by a savvy adversary, keep a healthy skepticism if you encounter strange (or strangely convenient) timestamps.

The C-time is of particular interest, as this timestamp cannot be easily altered to a specific value. In an investigation where the timing of events is key this may be your truest source of temporal information.

All file system activity can be conveniently displayed as a timeline using the mactime utility from TSK. This program is used to create a log-style listing sorted by each timestamp entry in a supplied “body” file. A “body” file is a listing of files in a particular format, often referred to as “mactime” format. An appropriate body file can be generated using the fls program, also a part of TSK, as demonstrated here:

Alternatively, the output from fls can be piped directly to mactime to avoid the creation of an intermediary file as demonstrated here:

The mactime utility can be instructed to present timestamps only for a certain time period as shown here:

We can combine these to generate a timeline that only shows the activity on the “/home” volume occurring on May 30, 2009. Note that in this example we are running fls against the volume (/dev/sda9) directly as opposed to creating a raw image file first.

The resultant file has 200 lines—all this activity was generated during a very simple graphical logon session. Timeline investigations of intrusions occurring over a period of months or years on heavily used systems can grow into the millions of entries!

(Carrier, B. (2005). File system forensic analysis. Addison-Wesley Professional.)

The primary data structures that make up ext2/ext3 are simply data streams with a defined format. The following example of an ext2 formatted floppy disk is provided to demonstrate the simplicity of these structures and their relationships. A forensic duplicate of this floppy disk is available at www.disclosedigital.com/DiscloseDigital/Digital_Evidence_files/ext2-floppy-02132004.zip.

The root directory's inode is always inode 2 and is shown here in WinHex:

Using the following format, we can translate these directory entries.

The root directory translated into the following, where unknown metadata associated with deleted files are indicated with a question mark.

This information, and the contents of subdirectories, can be extracted from a forensic duplicate with TSK using “fls -f linux-ext2 -r -p -u ext2-floppy-021304.dd” (the –r option recurses through folders and –p provides full path names). Although knowing just the filename may be useful in some investigations, having just filenames without their associated metadata is generally of limited value.

To determine important details about the file, including where the content of a file is stored, first we must get information about the overall structure of the disk from the superblock. This structure is located after the boot block, 1024 bytes from the beginning of the disk (offset 1024 = 400 hex).

The superblock is a dense structure with many fields and looks like this in raw form:

The values in this data can be interpreted using the defined format of the superblock.

The format of the ext2 superblock is as follows:

To facilitate the interpretation process, X-Ways has an ext2 superblock template that can be applied to the preceding data as shown in Figure 6.3.

Immediately following the superblock is the first Group Descriptor structure that contains the location of the inode table (there is only one group on a floppy disk).

The format of the group descriptor is as follows, and can also be viewed using the ext2 Group Descriptor template in X-Ways.

Some of this information can be obtained with TSK using fsstat -f ext2-floppy-021304.dd.

This tells us that the inode table is located in block 5, and we know from the superblock that each block is 1024 bytes (offset 5120 = 1400 hex). In raw form, the beginning of the inode table looks like this:

The format of inodes is as follows:

Applying the X-Ways ext2 inode template enables us to view this information in a more readable form as shown for inode 11 in Figure 6.4.

The metadata associated with individual files on a forensic duplicate can be displayed with TSK using the istat command (e.g., istat -f linux-ext2 ext2-floppy-021304.dd 11).

Using this information, such as filenames and block numbers, you can locate and extract the active files on this disk. For example, the entry in the root directory tells us that the text file named file3 is associated with inode 21, which in turn tells us that it starts at block 1034 and is 61 bytes in length. Going to offset 102800 (1034 blocks x 1024 bytes/block = 1058816 = 102800 hex) brings us to the start of the file as shown here:

When performing a forensic analysis of Unix file systems, there are features that should be inspected beyond just the file date-time stamps. As shown in Figure 6.3, the last time a Unix file system was mounted is recorded, which should be consistent with other activities on the system.

File permissions can also be revealing in a case, enabling digital investigators to determine which user account was used to create a particular file, or which group of users had access to data of concern.

Because Unix systems break portions into the disk into block groups, data of similar types are often stored in the same area of the disk, facilitating more efficient and focused searching for deleted data. For instance, efforts to recover deleted logs can focus on the /var/logs partition.

Unix systems in an Enterprise are often configured with some remote storage locations, which can be seen in /etc/fstab as shown here:

In this instance, all files in user home directories are stored on a remote server named remote-server along with spooled e-mail. Therefore, preserving just the hard drive of the single system would not preserve all potentially relevant files associated with the use of that system. It would also be necessary to preserve files stored on the remote server.

When a file is deleted, its inode link count is set to zero, the directory entry is removed (and may be added as slack to a previous entry). In addition, the inode table is updated to show that the inode is no longer in use, and the block bitmap is updated to release blocks. In some versions of Linux file systems, the inode reference is set to zero and an additional deleted date stamp is updated. This process allows forensic examiners to recover deleted filenames and deleted inodes (and the associated data on disk) but makes it difficult to associate deleted filenames with deleted inodes.

The most effective strategy to recover deleted data is to examine deleted inodes, which are listed in the inode tables. Although the deleted inode does not contain a filename, it does provide useful metadata including dates, attributes, and location of data on disk. For smaller files, the inode contains a list of the actual blocks that contains data from the deleted file. The inode for larger files reference indirect blocks, which are simply lists of the actually allocated blocks.

Deleted files can be listed with TSK using fls with the -d option (deleted) as shown here for the same floppy disk used in previous examples:

There is no date-time information associated with these files because we do not know with which inode they were associated. Older versions of the ext2 file system did not zero out the inode numbers making it easier to associate a deleted filename with its associated inode. Because the inode is not available in newer versions of ext2, the fls output does not give us much information, so let us look at the associated inodes in more detail using ils.

How do we associate the filenames with the appropriate inodes? We compare the metadata in each inode with metadata associated with each file to determine links. The preceding results show us that inode 15 referred to a 47-byte file and inode 18 referred to a 80117-byte file (in bold). By extracting the contents of inodes 15 and 18 using icat and determining what type of data they contain, we can make an educated guess about at least one of the files.

Note that cat is a standard UNIX command that is used to concatenate and print files, whereas icat is part of TSK and is used to print inodes.

Ordering the date-time stamps of unallocated inodes using the mactime utility combined with the ils -m option, we can see when the inodes were last modified, last accessed, and deleted.

The only item with activity around 19:10 on Feb 8 is inode 15, indicating that it was named file2.

Another useful phenomenon on Unix file systems from a forensic perspective is the persistence of deleted inodes. When a file is deleted, the corresponding inode will retain some metadata associated with the file until the inode is reused. Therefore, deleting a file effectively freezes its metadata until that inode is overwritten by a new file, which may not occur for months or longer (Farmer & Venema, 2005). When large numbers of files are created and deleted, such as when an intruder installed malicious code on a compromised system, these traces can remain in the inode table for a long time.

In findings first described in Forensic Discovery by Farmer and Venema (2005), the authors made the discovery that inodes are typically allocated in fairly linear fashion, and that wildly outlying inodes may be used to find replaced binaries, and trace them back to their original creation location. You can list the inode number of a file using the –i flag to ls as demonstrated here:

Note that the ls binary's inode number is not in the same range as the other items in the “/bin” directory. Where did it come from? Searching for other files with similar inodes reveals the answer as shown:

We can be pretty certain at this point that ls wasn't modified as part of a standard system update.

There are two methods of scheduling a command to be executed automatically at a preset time: at and cron. The cron process is the main method for scheduling a task to run at some point (or points!) in the future on a Linux system. Intruders may create a cron job on a compromised system to periodically launch a backdoor or beacon to enable them to regain entry.

There are two primary locations where cron will look for jobs to process: “/var/spool/cron,” which will contain the user IDs of any users who have entered cron jobs using the crontab command, and “/etc/crontab”, which will list additional locations for systemwide cron jobs. Generally these are found in the directories “/etc/cron.hourly,” “/etc/cron.daily,” “/etc/cron.weekly,” and “/etc/cron.monthly.”

These locations (and any others referenced in /etc/crontab) should be examined for unauthorized jobs. This is an old but still extremely popular and effective way to maintain access on a compromised Unix system.

The at command provides similar functionality to cron and creates job files in “/var/spool/cron.”

When a user logs into a Unix system, they may be presented with information about the previous logon to that account, which is stored in the lastlog file. At that point, the lastlog and utmp files are updated with information about current logon session, including the time and host name. The utmp file contains information about active login sessions that can be displayed using the who or w command. The same information that is entered in the utmp file is appended to the wtmp log file, which is a simple user logon/logoff database common on most forms of Unix, including Mac OS X. The difference between these two files is that utmp entries are cleared when the user logs off, whereas the entries in wtmp are retained indefinitely.

On Unix systems, the default locations are “/var/run/utmp” and “/var/log/wtmp”. Each entry in the wtmp database includes the user login name, device name, and host name, if remote. In addition, the wtmp database will generally have the time of logon and logoff, which can be helpful when trying to determine which user accounts were connected to the system at the time of interest.

The last command is used to query the wtmp database to determine who logged into a system and when they logged out. However, as can be seen in the first line of Table 6.1, the last command on most systems truncates the host name, making it necessary to use a customized version of last to process the wtmp file or obtain the host name from somewhere else.

The wtmp database can also be parsed using an EnScript as shown in Figure 6.5.

There are a number of potential problems to be aware of when it comes to these logon records. Not all programs make an entry in wtmp in all cases. For instance, sshd does not make an entry in wtmp when someone connects using scp or using the port forwarding feature of SSH. Also, because different systems have slightly different wtmp formats (as defined in the system's “/usr/include/utmp.h” include file), programmers sometimes create programs that create improperly formatted entries in the wtmp database. For instance, some versions of MIT's Kerberized Telnet daemon create logout entries with the same time as the corresponding logon entry, causing sessions to be displayed as 0 minutes long. Additionally, the wtmp database can be corrupted by an incomplete write, making it necessary to analyze each log entry carefully using customized programs (Blank-Edelman, 2000).

Unix also maintains system logs (a.k.a. syslog) that can either be stored locally or sent to a remote system. These logs show incoming connections to servers and outgoing connections to WiFi. The following log entries show a Linux computer connecting to a WiFi Access Point named AWPERUCES.

Unix systems can be configured to send syslog entries to a remote system by adding the following line to /etc/syslog.conf configuration file:

Notably, syslog uses an unreliable mechanism to send information to a central logging host, since it relies on the connectionless UDP protocol. In other words, a computer sends its log entries over the network to the syslog server on a remote computer but has no way of determining if the log entries reach their destination. If the syslog server is fortunate enough to receive the log entry, syslog timestamps the log entry with the date and time of the syslog server, not the sending host. Therefore, even if the clock on the sending host is accurate, the syslog server can introduce a time discrepancy. Also, the syslog server has no way of confirming the origin of a given log entry. So, it is possible to forge a log entry and send it to the syslog server, giving the false impression that a certain event occurred on a certain computer.

A command history file is maintained for each user account on a Unix system, and contains recent commands executed under that account. The name of the command history files depends on the shell being used. It is most common to find .bash_history files in user home directories on a Linux system, and .history or .sh_history files on other Unix systems.

Command history files can be very useful for determining what a user or intruder did on a Unix system. The sample command history in Figure 6.7 shows the use of a secure deletion program (srm) to destroy the contents of a file named trade-secrets.tar.gz and a related folder.

Observe in Figure 6.7 that the command history does not show the date that each command executed. However, by examining the last accessed dates of files referenced in a command history file, it may be possible to determine when some of the activities occurred.

In addition to the earlier records of activities maintained by Unix systems, individual applications generate artifacts of user activities that can be useful in an investigation. Examples of traces that applications leave behind on Unix systems relating to user activities are provided here.

Gnome is the default desktop environment on some versions of Linux (e.g., Ubuntu), and is available for other versions of Linux. Gnome maintains lists of recently opened files in a number of locations, providing digital investigators with information about user account activities. For instance, Gnome maintains a list of recently opened files in a file named .recently-used.xbel in the home directory of each user account. In addition to the full path of the opened files, the entries in .recently-used.xbel contain the date-time stamp the file was opened and the application used to open the file. A sample of entries from this file are provided here.

As this example demonstrates, this information can reveal the use of removable media.

Additional information about files that were opened using a particular user account can be found in files under the .gnome2 directory. For instance, the gnome2/gedit-metadata.xml and gnome2/evince/ev-metadata.xml files may contain names of files opened under a specific user account.

Some application like Open Office maintain their own list of recently used files. Figure 6.8 shows entries in a .recently-used file under a specific user account, providing the full path of files that were opened and the associated dates.

Similarly, the GIMP graphics viewing and editing program maintains a list of recently opened files in .gimp/documents under each user account as shown in Figure 6.9.

The Wireshark program for capturing network traffic as detailed in Chapter 9, “Network Analysis” maintains a list of recently used files and filters in the .wireshark/recent file under each user directory as shown in Figure 6.10.

Forensic examiners should experiment with the specific programs found on a subject computer to determine whether the application maintains historical details of usage. The possibilities are limited only by the number of applications that are available. For instance, the Nautilus file manager application can retain some information about files that were in use under a specific user account in the .nautilus directory, and a program called Midnight commander has similar information (see the DFRWS2008 Forensics Challenge at www.dfrws.org).

Printing on Unix systems often is handled by the Common Unix Printing Solution (CUPS), which creates printer spool files in “/var/spool/cups” by default.

It is also possible to direct print spool files to a remote location by modifying the “/etc/printcap” configuration file.

When a file is printed, CUPS creates two files, a control file containing metadata and a data file containing the contents of the printed file in PostScript format. Figure 6.11 shows the contents of the “/var/spool/cups” folder on a Linux system, with control files starting with a “c” and data files starting with a “d” (deleted in this case).

The lower panel Figure 6.11 shows a CUPS control file with the username and other attributes associated with the print job. Control files are deleted only periodically (e.g., after 500 print jobs), but data files are deleted immediately after a document is printed.

Although the spool file containing the PostScript version of the document is generally deleted after printing is complete, it may be possible to recover these deleted spool files by carving in unallocated space of the “/var” partition for PDF documents. The beginning of a spool file (“/var/spool/cups/d00006-001”) associated with the printed document “Chapter4-IntrusionInvestigation_05122009” is show here with the username eoghan, document name, and date of printing:

The items in this header provide useful signatures for file carving, as well as keyword searching of unallocated space for specific documents or all items printed by a specific user account.

For accounting purposes, the “/var/log/cups/page_log” records the number of pages (and sometimes the associated filenames) that each user printed at specific times. Although this log does not provide the contents of printed documents, it shows that a user account was in use at a particular time.

Attaching a USB storage device of any kind will create a handful of entries in the syslog.log file. These entries will occur each time the device is connected to the system.

In addition, there may be references to files stored on removable media that were opened using applications on a Linux system.

There are many userland utilities for obliterating data on Unix-like systems. Although these tools are generally effective at destroying data, forensic practitioners may be able to detect traces of their use as noted in the section on command history earlier in this chapter (see Figure 6.7).

Realizing the value of log files in a digital investigation, some offenders simply delete them. Some intruders will also clear entries from the wtmp database using specialized utilities to make it more difficult for digital investigators to reconstruct events relating to an intrusion. Fortunately, forensic practitioners may be able to recover deleted files or references to files that have been obliterated. Recall the example in Figure 6.6 earlier in this chapter, showing a recoverable deleted syslog file.

In addition, similar to the Recycle Bin concept in Microsoft Windows, when a user deletes a file within a graphical environment, the file is simply moved to a directory. For instance, the Gnome environment places files deleted by a user in the .Trash directory under the home directory. This feature enables users to restore files that were deleted accidentally, but also provides forensic examiners with useful information relating to user deletion activities.

Every time a user connects to a remote host using Secure Shell (SSH), that host's IP/host name and key are added to the known_hosts file, which can be helpful if an intruder used SSH to connect to another host, either on the local LAN or on the Internet as shown here:

As its name implies, grepmail is a utility for searching for e-mail items that meet specific criteria, much in the same way the grep utility searches for lines or files that match certain patterns. The grepmail program has built-in knowledge of mail formats and thus gives the examiner more precision when defining search parameters. Although grepmail works only on mbox format mailboxes, it can parse compressed mailboxes, and can search through a number of mailboxes at once. The grepmail options of particular interest to examiners are noted as follows:

One particularly interesting feature of grepmail is its date searching capabilities. Dates can be entered in a number of nonstandard formats. “02/21/09,” “4:00am October fourth,” and “today” are all valid date entries. Additionally, date searches can be constrained by keywords like “before,” “since,” or “between.” This level of granularity may prove to be invaluable if your investigation revolves around specific times or dates.

For example:

This command will print the headers of all mail found in “2009-February.mbox” sent before 12:30 am each day (the default date field to match is the “sent” date).

This will display the full content of all mail with a “deleted” status that was received after February 19.

Although certainly flexible and powerful, grepmail tends to slow down when dealing with very large mbox files (I have attempted to use grepmail on ~30GB mbox files). The grepmail program is well suited for queries against relatively small mailboxes and queries where a specific set of keywords, dates, and other search criteria are fixed before the search begins. Many legal discovery cases would fit this description. For investigations that don't have a fixed keyword list from the beginning, and those that may deal with very large mailbox, Mairix is a better choice.

The Mairix tool is quite a bit more complex than grepmail, but it is also quite a bit more powerful. We recommend a thorough read through the main page for a full understanding of the tool's capabilities, but hopefully this section will provide you with enough information to get started.

The key difference between Mairix and grepmail is that Mairix first builds an index, which is subsequently queried as the examiner performs searches. Additionally, Mairix is able to search both mbox and Maildir mail files. Unlike grepmail, you won't be able to simply jump into a shell and begin making queries. Searching with Mairix requires several steps. First, you need to create an rcfile that defines some variables Mairix needs to operate. Next, you build the index from your mailbox. Last, you query the index.

Our very minimal Mairix rcfile follows:

Base defines the base path that Mairix will treat as its root; mbox points to the mbox file we'll be processing. This can be a colon-delimited set of mbox files. Database tells Mairix where to build its index. Finally, mfolder defines where Mairix will store the output from any subsequent queries. Search results are stored in Maildir format by default but this can be configured as necessary.

Next, we tell Mairix to build the index. This is achieved with a simple mairix –f rcfile, but adding a -v flag will increase verbosity and give you some progress information to watch while you wait. Indexing time will obviously increase with larger amounts of data.

Now we can query the index. Mairix supports a broad range of search operators. Chaining these together allows the investigator to quickly hone in on a small number of interesting e-mails that can be reviewed manually.

We'll issue a query for a known-bad domain. Any mail arriving from this domain is suspicious at best.

The resulting mail files can be found in the “new” subdirectory.