Linux & macOS Artifacts

Linux powers most of the world's servers, and macOS runs tens of millions of professional workstations — both are common targets in corporate investigations. This chapter maps the artifact locations that matter most: where users leave traces, where the system logs activity, and how persistence mechanisms work.

5.1Linux File System Layout

Unlike Windows, Linux mounts everything under a single root directory /. There are no drive letters — a USB drive, a network share, and the main hard disk all appear as subdirectories under the same tree. That single-root design means an examiner who knows the standard directory layout can navigate any Linux system.

The directories most relevant to forensic work are:

• /etc/ — system configuration files. The files passwd, shadow, hosts, crontab, and sudoers live here. passwd lists every user account; shadow holds their password hashes (root-only readable).
• /var/log/ — system and application logs. This is the single most important directory for timeline reconstruction.
• /home/username/ — each user's personal directory. Contains command history, dotfiles, downloads, browser profiles, and SSH keys.
• /tmp/ and /var/tmp/ — temporary files. /tmp is cleared on every reboot; /var/tmp persists across reboots and is preferred by malware that needs to survive a restart.
• /proc/ — a virtual filesystem generated by the kernel at runtime. It is not on disk — you cannot image it. It contains live process information via /proc/[pid]/ directories for each running process. In a live response, /proc/[pid]/cmdline shows the exact command that launched a process, and /proc/[pid]/fd/ shows its open files.
• /root/ — the home directory of the root (superuser) account. A separate directory from /home/ so that root always has a home even if /home/ is on a different partition.
• /usr/bin/ and /bin/ — system binary executables. Legitimate tools live here; malware sometimes copies itself here to blend in.
• /dev/ — device files. sda is the first SATA disk, sda1 its first partition, sdb the second disk. These are the device nodes you pass to dd when imaging.

5.2Log Files & Syslog

Linux logs everything — authentication events, kernel messages, application errors, and user sessions. Most logs live in /var/log/ as plain text, which makes grep your first analysis tool. However, some critical logs are binary and require dedicated commands to read.

Log rotation matters for examiners: logrotate compresses old log files and renames them with a date suffix — auth.log.1, auth.log.2.gz, and so on. Always check for .gz compressed archives because they contain older entries that are just as forensically valid as the live file. An attacker may wipe the current log but cannot reach back into already-rotated archives that were compressed before they gained access.

Web server access logs are especially valuable in intrusion cases. Each line records the client IP address, timestamp (check the server timezone — it affects your timeline), the exact HTTP request, the response code, and response size. A cluster of 404 responses from one IP is a directory-enumeration scan. A series of POST requests to /wp-login.php is a brute-force login attempt.

5.3Bash History, Hidden Files & Dotfiles

The .bash_history file in each user's home directory records every command typed in a terminal. The default limit is 500 to 1,000 entries. Attackers know this: history -c clears in-memory history, and unset HISTFILE before a session prevents it from being written at all. Even so, if those anti-forensic commands were run in a session that started with history enabled, the earlier commands from that same session may still exist in the kernel's memory at /proc/[pid]/fd/ for the bash process — always worth checking in a live acquisition.

Key dotfiles and their forensic significance:

• ~/.ssh/known_hosts — every remote host the user has connected to via SSH, listed by IP or hostname. This is often the best artifact to prove that a user connected to a specific remote server, even when no other logs survive.
• ~/.ssh/authorized_keys — public keys allowed to log in without a password. Attackers establishing persistence add their own public key here. A key added after the incident start time is a strong indicator of compromise.
• ~/.bashrc and ~/.bash_profile — run automatically when a new shell or login session starts. Attackers add malicious commands here (a reverse shell one-liner, for example) to achieve persistence that survives reboots.
• ~/.profile — similar to .bash_profile; used at login on many distributions.

The files /etc/passwd and /etc/shadow deserve examination in every Linux investigation. passwd lists every account: username, UID, GID, home directory, and default shell. An account with UID 0 other than root is root-equivalent and always suspicious. shadow holds password hashes and requires root to read on a live system — but in a forensic image you have full disk access regardless.

5.4Startup Services & Persistence

Attackers who gain access to a Linux system want that access to survive reboots. There are four main mechanisms, and an examiner should check all four.

Cron jobs are the most common persistence mechanism on older Linux systems. crontab -l shows the current user's schedule; /etc/crontab and files under /etc/cron.d/ hold system-wide schedules. Each entry has five time fields (minute, hour, day, month, weekday) followed by the command. A suspicious cron entry typically calls a script stored in /tmp/ or /var/tmp/, or uses curl or wget to download and execute a remote payload.

Systemd services are the modern equivalent. Unit files live in /etc/systemd/system/ (administrator-created) and /usr/lib/systemd/system/ (package-installed). Run systemctl list-unit-files to see everything with its enabled/disabled state. A recently created .service file pointing to a binary in /tmp/, or bearing an unusual name like systemd-network-helper.service, is a red flag. The ExecStart= line in the unit file shows exactly what command runs.

SysV init (legacy, still present on older servers): startup scripts in /etc/init.d/, with symlinks in /etc/rc*.d/ controlling which runlevel activates them. Less common on modern systems but still encountered in long-running corporate servers.

At jobs schedule one-time commands via the at command; pending jobs are stored in /var/spool/at/. Attackers use these to schedule a payload for a specific future time, then delete the at binary — but the spool files remain and are readable.

5.5macOS Artifacts

macOS is a Unix-based system (BSD lineage), so many Linux concepts apply directly — bash/zsh history, SSH keys, and dotfiles work identically. But macOS adds its own proprietary artifact layer that requires dedicated tools or commands to parse.

Unified Log is the central logging system since macOS 10.12 Sierra. Binary log data lives in /var/db/diagnostics/ with supporting data in /var/db/uuidtext/. On a live Mac, log show --style syslog queries it. On a forensic image, use the open-source UnifiedLogReader tool. The Unified Log is extraordinarily dense — it records nearly every system event, app launch, and network connection, and it is the macOS equivalent of Windows Event Logs combined with Syslog.

Property list files (.plist) are XML or binary configuration files that appear throughout macOS. The forensically critical locations are ~/Library/LaunchAgents/ for user-level programs that launch automatically at login, and /Library/LaunchDaemons/ for system-level daemons run as root. Any .plist with RunAtLoad = true and a ProgramArguments key pointing to an unusual path — especially one in /tmp/, /var/folders/, or a user's Downloads folder — warrants immediate investigation.

FSEvents records a log of every file system change (create, modify, rename, delete) in /.fseventsd/ at the root of each volume. The log persists across reboots and is one of the strongest timeline sources on macOS. The open-source tool FSEventsParser (Python) converts these binary files into human-readable CSV output.

Spotlight metadata in .Spotlight-V100/ at the root of each volume indexes file contents and metadata. The index can reveal recently accessed files and their metadata even after the files themselves have been deleted from the file system.

APFS snapshots: Apple File System creates local snapshots for Time Machine and system updates. Run tmutil listlocalsnapshots / to list them on a live system. Snapshots may contain files deleted from the live system — a useful source of deleted evidence without needing any carving.

Quarantine database at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 is a SQLite database populated every time a file is downloaded from the internet. It records the file name, source URL, referrer URL, and exact download timestamp. This is the macOS equivalent of the Windows Zone.Identifier alternate data stream — strong proof of intent when a suspect claims not to have downloaded a specific file.