Audit Daemon (auditd) is a powerful tool in Linux for tracking and logging system events, including file access. It’s part of the Linux Auditing System, which provides detailed and customizable logging of various types of system activity.

Below is an example auditd rule to detect timestamp modification:

sudo nano /etc/audit/rules.d/audit.rules
Opens the auditd rules file with the Nano editor. Add the following line:

-a always,exit -F arch=b64 -S utimensat -F key=timestamp-changed

-a Add a rule to the audit system

always,exit Apply this rule to both the entry and exit points of the system call. It means that audit records will be generated both when the system call starts and when it ends

-F arch=b64 Filter condition. Specifies that this rule applies to 64-bit architecture (this can be replaced with -F arch=b32)

-S utimensat Specifies the utimensat system call to be audited

-F key=timestamp-changed Adds a key to the rule for easier identification in the logs

To review audit logs related to this rule, we can use ausearch (ausearch -k timestamp-changed) or read and retrieve lines from the raw audit logs with grep (sudo grep timestamp-changed /var/log/audit/audit.log).

Sections

ID	Name	Description
AF003	Timestomping	A subject modifies the modified, accessed, created (MAC) file time attributes to hide new files or obscure changes made to existing files to hinder an investigation by removing a file or files from a timeframe scope. nTimestomp is part of the nTimetools repository, and it provides tools for working with timestamps on files on the Windows operating system. This tool allows for a user to provide arguments for each timestamp, as well as the option to set all timestamps to the same value. Linux has the built-in command `touch` that has functionality that allows a user to update the access and modified dates of a file. The command can be run like this: `touch -a -m -d ‘10 February 2001 12:34' <file>` The argument `-a` refers to the access time, `-m` refers to the modify time, and `-d` refers to the date applied to the target file.
AF026	Log Modification	The subject intentionally alters or removes log entries, either at the host, application, or network level, in a deliberate attempt to conceal or misrepresent their actions. This behavior is typically executed to frustrate forensic reconstruction during an investigation and may include deletion of individual log lines, rewriting timestamps, or manipulating source IPs or usernames. Subjects engaging in this technique may use native administrative tools (e.g., PowerShell, auditpol, journalctl), third-party log scrubbers, or direct file system access to tamper with `.evtx`, `.log`, or flat text logs.
AF026.001	Host Log Modification	A subject intentionally alters host-based log records to conceal, misattribute, or misrepresent activity conducted on an endpoint, server, or other operating system. The subject may change timestamps, account names, event identifiers, source addresses, command details, or action outcomes within Windows Event Logs, Linux system or audit logs, macOS logs, security-agent logs, or other locally stored records. Modification may be performed using administrative tools, scripts, third-party log scrubbers, or direct access to `.evtx`, `.log`, or other log files. Investigators should compare local records with centrally forwarded logs, Endpoint Detection and Response (EDR) telemetry, process execution records, file metadata, and File Integrity Monitoring (FIM) events. This Sub-section applies where log content is altered but the record or log remains present.
AF026.002	Application Log Modification	A subject intentionally alters audit, authentication, access, transaction, or administrative records generated by an organizational application to conceal or misrepresent activity conducted through that application. The subject may change the recorded actor, timestamp, source address, action, affected object, approval state, or result. Modification may be performed through application administration functionality, an Application Programming Interface (API), direct database access, scripts, or access to the underlying log repository. Investigators should compare application records with identity logs, database activity, endpoint telemetry, web proxy records, workflow history, and relevant business records.