Torvalds Tuesday: /etc

For today’s post, I’m going to briefly discuss the importance of including the /etc directory in your Linux investigations. Admittedly, some of the contents of this directory deserve their own posts; /etc/passwd and /etc/shadow got that, in fact. With that, if a particular artifact within /etc deserves it’s own post, expect to see it in the future. We’ll cover it briefly here.


The /etc directory is the configuration depot for the system. This directory contains configuration files for both the system and, usually, additional third-party applications. The files within this folder should be in plain text, and contain configuration options in a format specific to the tool that requires the configuration file.

Its also worth taking a look in etc for configuration files to understand where logs may be stored on the system. Oftentimes, log forwarding options will also be set in config files, so you may discover an offline repository as well. These config files should also list the level of log verbosity, and may help set expectations for what data logs may actually yield.

Let’s go over a few key files within this directory that may help during analysis:

Note: For this analysis, I’m looking at the contents of the /etc folder on a SIFT Workstation VM, which is an Ubuntu distribution.


The environment file contains systemwide environment variables. One important note between this file and other environment variable locations is that variables must be entered line by line and this file is not a script; it cannot handle variables. Each line entered is interpreted literally.

/etc# cat environment


The aptly-named hostname file contains the hostname of the system. Often times, when I receive a Linux image for analysis, I go to this file to determine what the system called itself. This should line up with the system you expected to receive.

/etc# cat hostname


The hosts file, which oddly enough also has a presence on Windows, is yet another text file to correlate IP addresses with hostnames. I often see this file used when someone wants to map a hostname to an IP address, which can then be simply typed in the web browser. Attackers may utilize this file to redirect communications or mask communication to a known-bad IP address. The contents of the hosts file often contain IPs followed by the canonical hostname:

/etc# cat hosts localhost siftworkstation
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters


The sudoers file essentially controls what users can run the sudo command and any additional rules on that activity. From a DFIR perspective, I’d be looking at this file to identify if any compromised, or attacker-created, accounts had the ability to escalate. Here’s a snippet of the default sudoers file from the SIFT workstation:

Snippet of the sudoers file from the SIFT workstation


Yet another important forensic step is to establish timezone information for your evidence. Quickly dumping the contents of /etc/timezone can help identify the timezone that logs with local timestamps are written in.

/etc# cat timezone

I’ll continue adding artifacts as I explore more of the etc folder. If you find yourself performing analysis, lean on the etc folder to tell you the location of logs, what level of logging to expect, and other details about the system and third party applications.

Until tomorrow, Happy Forensicating!

Like what you read? Give Matt B a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.