Skip to content

Artifact Analysis: Linux Filesystem & MAC Times

In Unix-like systems, a filename is merely a label—a convenient pointer for humans. The true identity and metadata of a file are stored in a data structure known as the Inode (Index Node).

  • What an Inode contains: The file size, owner (UID/GID), permissions (RWX), timestamps, and pointers to the actual data blocks on the disk.
  • What an Inode does NOT contain: The filename. Filenames are stored in the directory file, mapping names to specific inode numbers.

Forensic Implication: If a threat actor uploads a reverse shell named malware.sh and later renames it to systemd-update to blend in, the inode number remains identical. Tracking the inode number (ls -i) allows analysts to track the file across renaming evasion attempts.

2. Decoding Linux Timestamps (The MAC Trap)

Section titled “2. Decoding Linux Timestamps (The MAC Trap)”

Timestamp analysis is the foundation of timeline reconstruction. However, Linux POSIX timestamps frequently trap junior analysts who assume they operate identically to Windows.

The standard timestamps are known as MAC times:

LetterFull NameMeaningTrigger Action
Mmtime (Modify)The content of the file was altered.Writing to the file (e.g., echo >>, vim).
Aatime (Access)The file was read or executed.cat, grep, execution. (Note: Often disabled or set to relatime on modern servers to improve I/O performance, making it highly unreliable for forensics).
Cctime (Change)The metadata (inode) was altered.Changing permissions (chmod), ownership (chown), moving, or renaming the file.

3. Advanced DFIR: Recovering Creation Time (crtime)

Section titled “3. Advanced DFIR: Recovering Creation Time (crtime)”

To establish when a malicious payload originally hit the disk, analysts must extract the crtime. If the underlying filesystem is Ext4, this requires querying the raw disk device directly.

  1. Identify the Inode: Find the inode number of the suspicious payload. ls -i /mnt/analysis/tmp/malware(Assume the result is 12345)
  2. Query the Raw Device: Use the debugfs utility. Note that debugfs requires the raw partition identifier (e.g., /dev/sda1), not the mount point. debugfs -R 'stat <12345>' /dev/sda1
  3. Extract crtime: The output will reveal the raw inode structure. Locate the crtime field to establish the exact moment the attacker dropped the file.

4. Hunting in Drop Zones (The Staging Areas)

Section titled “4. Hunting in Drop Zones (The Staging Areas)”

Adversaries rarely drop their initial toolkits in heavily monitored or permission-restricted directories. DFIR analysts must prioritize scanning world-writable “Drop Zones.”

/tmp/ and /var/tmp/

The classic staging directories. While /tmp/ is generally cleared upon a system reboot, /var/tmp/ is persistent. Search for hidden files (starting with a dot), compiled ELF binaries, or dropped shell scripts.

/dev/shm/ (Shared Memory)

Critical Threat Vector: This is a virtual RAM disk. Files written here exist only in memory and are completely destroyed upon reboot. Threat actors drop their payloads here to execute “Fileless” malware. If an analyst performs live triage, listing the contents of /dev/shm/ and acquiring the volatile memory (RAM) is absolutely mandatory before powering down the system.

Advanced threat actors understand MAC times and actively manipulate them to disrupt the forensic timeline, a technique known as Timestomping.

  • The Attack: The adversary uses the native touch command to backdate their malware: touch -d "2020-01-01" /tmp/malware.sh
  • The Result: The mtime (Modify) and atime (Access) are artificially changed to 2020, making the file appear as a legacy system script.

The touch command successfully spoofs mtime and atime. However, altering a file’s timestamps is, by definition, an alteration of the file’s metadata.

Consequently, the ctime (Change time) is automatically updated to the actual, current system time by the kernel.

The Golden Rule: If you encounter a system binary or script where the mtime indicates 2020, but the ctime indicates yesterday (aligning with the suspected intrusion window), the file has definitively been tampered with or timestomped.

hunt_linux_mac_times.sh
#!/bin/bash
TARGET_DIR="/mnt/analysis"
# Hunt for files whose CONTENT was modified in the last 48 hours
echo "[+] Files modified (mtime) in the last 2 days:"
find $TARGET_DIR -mtime -2 -ls
# Hunt for files whose METADATA (permissions/timestamps) changed in the last 48 hours
echo "[+] Metadata changed (ctime) in the last 2 days:"
find $TARGET_DIR -ctime -2 -ls