Linux Forensic Artifacts: File System, Logs, Cron and Shell History

Identify the actual filesystems and features instead of assuming a national default. ext variants, XFS, Btrfs and other storage arrangements have different metadata and recovery behaviour. A container or network mount may add another layer between the examined path and persistent storage.

In ext filesystems, directory entries associate names with inode numbers. Inodes can describe ownership, permissions, size, links, timestamps and data references. ext4 may use extents, inline data or other supported structures; creation-time availability depends on the inode layout and stored fields.

Deletion, remaining hard links, open files and later reuse affect what survives. The original name, inode contents and data do not have one universal persistence rule. Interpret generation, allocation and directory context before associating a reused inode number with an earlier file.

Journaling supports filesystem consistency. ext3/ext4 journal contents and retention depend on configuration, workload and scope; a busy server does not have a universally known minutes-long recovery window. An ext journal is not the same source as systemd’s application/system journal.

Preserve the original image and avoid unrecorded replay or repair. Tool support for the actual filesystem features matters. A recovery utility’s name is not a guarantee it can reconstruct every deleted inode or file.

/proc and /sys expose live kernel information rather than ordinary persistent copies of that state. Per-process maps concern mapped memory regions; file-descriptor links concern open descriptors. They answer different questions and are subject to permissions, namespaces and possible compromise.

Owner, group and other mode bits provide basic read, write and execute permissions. ACLs and their effective masks can add or constrain permissions, while mandatory access-control policy supplies another layer. Record the actual attributes and policy rather than infer all access from one ls listing.

Set-user-ID and set-group-ID can affect supported executable behaviour, subject to conditions such as executable type, mount options and security restrictions. A shared-library filename with a special mode bit is not, by itself, proof of an effective privileged execution path.

On directories, a sticky bit restricts deletion or renaming according to ownership and privilege rules; it is not simply a rule that only the file owner can act. Set-group-ID can influence inherited group ownership, with filesystem and permission context also relevant.

Compare unusual privileged files or ACLs with a trusted baseline, package records, administrative changes and actual use. An unexpected attribute is a lead; it does not independently establish a backdoor or identify who changed it.

SELinux and AppArmor policies, modes and deployment differ. A disabled profile, permissive setting or changed label can reflect maintenance or configuration as well as tampering. Preserve relevant policy and records before interpreting the change.

A leading dot is a filename convention affecting ordinary listings, not a separate hidden-file security mechanism. Inspect relevant names, permissions and content on a protected source without treating every dotfile or unusual path as malicious.

Authentication and system records can be plain text, binary databases, structured journal data or remote exports. Identify the actual logging services and configuration. Not every Linux system uses systemd, and not every systemd installation retains the same persistent journal or text logs.

wtmp, utmp and btmp are commonly associated with session history, current sessions and failed-login records respectively. They depend on participating programs and retention; they are not guaranteed complete accounts of all network or human access.

For systemd systems, journal storage may be persistent under /var/log/journal or volatile under /run/log/journal, depending on configuration. Text files may be produced through another logging service. Preserve all relevant available sources and supporting configuration, not only a familiar filename.

When using journalctl on acquired files, record the file selection, filters, output mode and tool version. Fields such as _COMM, _UID or a service unit describe the logging context; a filter for bash does not create a complete transcript of shell commands.

Reconcile time zones, clock changes, boot identities and forwarded-log timestamps. An IP address can describe an observed connection context, not necessarily the individual operating an account. Missing records require investigation of generation, storage, access and collection before a deletion conclusion.

Shell history depends on the shell, settings and session behaviour. A .bash_history file is one possible source, not a complete command audit. Entries can be omitted, merged, appended late, changed or never written to persistent storage.

For Bash, HISTSIZE, HISTFILESIZE and HISTFILE influence retained history and its destination. HISTTIMEFORMAT relates to timestamp presentation and recording behaviour; its current absence does not prove that an acquired history file contains no timestamp comments. Inspect the raw file and the actual Bash semantics.

Where reliable per-entry timing is absent, a login window or nearby journal record can suggest enquiries without assigning a precise time to each command. Concurrent sessions, delayed history writes and multiline commands prevent a simple rule that history position 47 belongs to one known session.

Examine scheduled work through the actual implementation: system and user crontabs, cron.d and interval directories, anacron, systemd timers, associated services and relevant user-level configuration. The presence of a task file is different from an enabled schedule or a recorded execution.

Formats and eligible filenames vary. For example, Debian cron’s documented cron.d rules ignore names containing dots; a hidden dotfile is not automatically a functioning scheduled job. System crontabs and per-user crontabs can also differ in their user-field syntax.

Compare task content, referenced scripts, permissions, enablement and service logs with an appropriate baseline. A suspicious schedule is a testable persistence hypothesis; ordinary maintenance also uses these mechanisms. Preserve both the definition and evidence relevant to whether it actually ran.

Linux Audit coverage depends on the active audit subsystem, configured rules, queue handling and retained records. auditd receives and writes records in userspace; rule files can be generated from a rules.d configuration. Preserve relevant settings and information about loss or backlog, not only the main log.

Use compatible ausearch or aureport processing on acquired records with the time and input scope documented. A configured key or watched path does not prove that every relevant operation was captured, and a log-retention law does not prove an audit daemon was deployed.

Temporary-directory persistence varies with mounts and cleanup policies. /tmp may be memory-backed, persistent or cleaned according to local rules; /var/tmp is not guaranteed to retain everything indefinitely. Inspect actual configuration and collection timing.

A current mount table can legitimately differ from /etc/fstab because of automounts, removable media, bind mounts, containers or temporary administration. Evaluate a discrepancy with source context instead of treating every extra mount as attacker activity.

Live tools share dependencies on the kernel and runtime environment. Agreement between ls, find or module listings does not prove absence of compromise. Compare suitable independent sources, trusted baselines and preserved memory or offline data where feasible, while retaining their own limitations.

Loader-preload settings can be legitimate or abused. Their effect depends on the binary, loader and secure-execution context; they do not inject code into every process universally. Preserve the actual configuration, library identity and relevant process evidence before interpreting a rootkit hypothesis.

The Sleuth Kit and compatible forensic tools can examine supported partition and filesystem structures from preserved images. Identify actual offsets, sector size and filesystem features. Tool syntax and support need checking for the version used; do not combine an illustrative command with an unsupported offset convention.

Plaso/log2timeline can extract events from supported formats and write a timeline store. Record selected parsers, filters, versions and warnings. A preset does not ensure that every Linux artefact or custom application was parsed.

Timeline tools may represent filesystem timestamps, record times and interpreted event fields differently. Retain their source path or offset, original values and time basis. A row’s proximity to another row is not proof that the same person caused both.

Hypothetical example: an untimed shell-history entry mentions an administrative action while a timer definition and a service record are also present. Check whether the timer was enabled, whether the service record reports an execution and whether independent audit data describes the action. The history line alone cannot supply a precise command time.

Legal retention and reporting duties vary by jurisdiction, covered entity and activity. Assess the applicable requirements separately from actual logging: a retention duty does not establish that a particular auth.log, journal or audit record exists.

For related allocation and journal concepts, see Operating Systems, Boot Process and File Systems. Report the supported sequence, missing sources and unresolved alternatives without converting an absence into automatic legal noncompliance.