When it comes to forensic investigations, Windows is often the primary focus. However, with the rise of Linux in server environments, it’s essential for incident responders to have a deep understanding of Linux filesystems, especially when identifying evidence and tracking an attacker’s activities.
The Importance of Timestamps: MACB
Much like in Windows, timestamps in Linux provide crucial forensic clues. However, the way Linux handles these timestamps can vary depending on the filesystem in use.
M – Modified Time
A – Access Time:
It's often unreliable due to system processes.
C – Metadata Change Time
When a file’s metadata (like permissions or ownership) was last modified.
B – File Creation Time:
Found in more modern filesystems like EXT4 and ZFS, but absent in older systems like EXT3.
Filesystem Timestamp Support:
EXT3: Supports only MAC.
EXT4: Supports MACB, though some tools may show only MAC.
XFS: Supports MAC, and has included creation time since 2015.
ZFS: Supports MACB.
Each of these timestamps provides vital clues, but their reliability can vary based on the specific file operations performed. For example, access time (A) is frequently altered by background processes, making it less trustworthy for forensic analysis.
EXT4 Time Rules: Copying and Moving Files
When dealing with the EXT4 filesystem, understanding how timestamps behave during file operations can provide critical evidence:
File Copy
FILE MAC times change to time of file copy
DIRECTORY MC times change to time of file copy
File Move
FILE C time changes to time of move
DIRECTORY MC times changes to time of move
This timestamp behavior is simpler than that of Windows but still provides important data during an investigation, especially when tracking an attacker’s activities.
Important Note:Curl vs. Wget – different time stamp resultsComparing Linux and Windows Filesystems
For investigators accustomed to Windows, Linux presents unique challenges:
No MFT: Unlike Windows, Linux doesn’t have a Master File Table (MFT) for easy reconstruction of the filesystem. This can make timeline reconstruction more difficult.
Journal Analysis: While EXT3 and EXT4 filesystems use journaling, accessing and analyzing these journals is challenging. Tools like debugfs and jls from The Sleuth Kit can help, but journal data isn’t as easy to parse as NTFS data.
Metadata Handling: Linux filesystems handle metadata differently from Windows, which stores nearly everything as metadata. Linux systems may require deeper analysis of directory structures and permissions.
**************************************************************************************************************
Key Linux Directories for Incident Response
In a forensic investigation, understanding the structure and legitimate locations of files on a Linux system is crucial.
/ - root. This is the “base” of the file structure, and every file starts from here. Only user accounts with root privileges can write files here.
***NOTE: /root is the root users home folder and is different from /./sbin – System binaries. This stores executable files typically used by the system administrator or provide core system functionality. Examples include fdisk and shutdown. Although attackers rarely modify files here, it should still be checked to validate change times etc. As an example, the attackers could replace the reboot binary with one which reopens their connection.
/bin – User binaries. This holds the executable files for common user-commands, such as ls, grep etc. Often this is a symlink to /usr/bin. During IR, this should be checked to see if any legitimate files have been modified or replaced.
/etc – Configuration files. This folder holds configuration data for applications and startup/shutdown shell scripts. As an investigator this is often important to confirm how a system was set up and if the attackers changed critical configurations to allow access. This is one of the most attacked locations.
/dev – Devices. This folder contains the device files. In Linux, where everything is a file, this includes terminal devices (tty1 etc.), which often show up as “Character special file” in directory listings. Mounted disks appear here (often /dev/sda1 etc.) and can be accessed directly or copied to another location.
/mnt – Mount points. Conceptually related to the /dev folder, the /mnt directory is traditionally used to mount additional filesystems. Responders should always check the contents and account for mounted devices.
/var – Variable files. This contains files which are expected to change size significantly and, in some cases, have transitory lifespans.
***For incident responders, /var/log is often the first place to look for significant data. However, this also contains mail (/var/mail), print queues (/var/spool) and temp files trying to persist across reboots (/var/tmp).
/tmp – Temporary files. As the name suggests, system and user generated files can be stored here as a temporary measure. Most operating systems will delete files under this directory on reboot. It is also frequently used by attackers to stage payloads and transfer data.
/usr – User applications. This folder contains binaries, libraries, documentation etc. for non-core system files.
***/usr/bin is normally the location for commands user’s generally run (less, awk, sed etc.)***/usr/sbin is normally files run by administrators (cron, useradd etc.). Attackers often modify files here to establish persistence and privilege escalate. ***/usr/lib is used to store object libraries and executables which aren’t directly invoked./home – Home directories (/root for the root account home directory) for users. This is where most “personal” data and files are stored. It will often be used by attackers to stage data.
***Where attackers compromise an account, the evidence (such as commands issued) is often in the home directory for that account./boot – Bootloader files. This holds the files related to the bootloader and other system files called as part of the start up sequence. Examples include initrd and grub files.
***For incident response, the /boot/system.map file is essential when it comes to building profiles for memory analysis./lib – System libraries. This holds the shared objects used by executable files in /bin and /sbin (and /usr/bin & /usr/sbin). Filenames are often in the format lib*.so.* and function similar to DLL files in Windows.
/opt – Optional/Add-on files. This location is used by applications which users add to the system and the subfolders are often tied to individual vendors.
***During incident response, this is an excellent location to review but remember, nothing forces applications to store data in this folder.
/media – Removable media devices. Often used as a temporary mount point for optical devices. There is normally a permanent mount point for floppy drives here, and it is also used to hold USB devices, CD/DVD etc. Some distros also have a /cdrom mount point as well.
/srv – Service data. This holds location related to running services and the specific content varies from system to system. For example, if tftp is running as a service, then it will store runtime data in /srv/tftp.
Journaling and Forensic Analysis
Linux filesystems like EXT3 and EXT4 use journaling to protect against data corruption, but accessing this data can be a challenge for forensic investigators. Journals contain metadata and sometimes even file contents, but they aren’t as accessible as Windows NTFS data.
For journal analysis, tools like debugfs logdump and jls can help. However, the output from these tools is often difficult to interpret and requires specialized knowledge.
Conclusion
While Linux lacks some of the forensic conveniences found in Windows (like the MFT), understanding its filesystem structure and how timestamps behave during common file operations is key to uncovering evidence. Knowing where to look for modified files, how to analyze metadata, and which directories are most likely to contain signs of compromise will give you a strong foundation for incident response in Linux environments.
Akash Patel
Comments