Detecting Timestamp Manipulation via MFT and NTP Cross-Correlation Sequence Analysis

Why This Matters

Timestamp manipulation — also called timestomping — is an anti-forensic technique in which an attacker modifies file metadata timestamps or log entry timestamps to move evidence outside the incident window or to create a false chronology. Attackers use touch -t on Linux, the Windows API SetFileTime (wrapped in Metasploit's timestomp module), or direct hex editing of log files. An analyst who builds a timeline solely from recorded timestamps without corroborating them against other timestamp sources may reconstruct a false picture of when events occurred.

Core Concept

Every file on a typical filesystem carries multiple timestamps. On NTFS: $STANDARD_INFORMATION ($SI) contains mtime, atime, ctime (changed), and $crtime (created). $FILE_NAME ($FN) contains a parallel set of timestamps maintained by the kernel and much harder for user-space tools to modify without kernel-level access. Discrepancy between $SI and $FN timestamps is the classic timestomping indicator: touch -t and SetFileTime modify $SI but not $FN.

On Linux ext4/xfs: user-accessible timestamps are mtime (content last modified), atime (last accessed), and ctime (inode last changed — permissions, links, or content). Ctime cannot be set by touch or utimensat by an unprivileged user and therefore provides a more reliable lower bound on when a change occurred.

Log entry timestamps are distinct from filesystem timestamps. An attacker editing log entries must also update any hash-chain fields, maintain timestamp monotonicity, and ensure the timestamps are plausible given NTP server records and network-level packet captures.

Physically impossible sequences are the strongest indicator: a file whose $SI mtime predates the creation timestamp of the compiler used to build it, or a log entry timestamped before the service was installed.

Technical Deep-Dive

# Linux: examine all four timestamps for a suspicious file
stat /var/log/auth.log
# Access: (atime)
# Modify: (mtime) — last content change
# Change: (ctime) — last inode change (cannot be set by touch)
# Birth:  (crtime) — not always available on Linux

# Compare mtime to ctime: if mtime < ctime, mtime was backdated
python3 -c "
import os, datetime
s = os.stat('''/var/log/auth.log''')
mtime = datetime.datetime.fromtimestamp(s.st_mtime)
ctime = datetime.datetime.fromtimestamp(s.st_ctime)
print(f'''mtime: {mtime}''')
print(f'''ctime: {ctime}''')
if mtime < ctime:
    print(f'''ANOMALY: mtime predates ctime by {ctime-mtime}''')
"

# NTFS: use The Sleuth Kit to compare $SI and $FN timestamps
# (run from a Linux forensics workstation with TSK installed)
istat -f ntfs /dev/sdb1 <inode_number>
# Look for $STANDARD_INFORMATION vs $FILE_NAME timestamp differences

# Alternatively, use fls + mactime for timeline creation
fls -r -m / /dev/sdb1 > bodyfile.txt
mactime -b bodyfile.txt -d 2024-03-10 2024-03-20 > timeline.csv

# Detect timestamp regression in a log file (entries out of chronological order)
import re
from datetime import datetime

TS_RE = re.compile(r'(w{3}s+d+s+d{2}:d{2}:d{2})')
YEAR = 2024   # supply year as syslog omits it

prev_ts = None
with open("auth.log") as fh:
    for lineno, line in enumerate(fh, 1):
        m = TS_RE.search(line)
        if not m:
            continue
        try:
            ts = datetime.strptime(f"{YEAR} {m.group(1)}", "%Y %b %d %H:%M:%S")
        except ValueError:
            continue
        if prev_ts and ts < prev_ts:
            delta = (prev_ts - ts).total_seconds()
            print(f"[L{lineno}] REGRESSION by {delta:.0f}s: {ts} < {prev_ts}")
        prev_ts = ts

# Compare against NTP server logs to verify host clock accuracy
# (NTP synchronisation log on Linux with chrony)
grep "offset" /var/log/chrony/tracking.log 
  | awk '''{print $1, $2, $NF}''' | head -20
# Large offsets or sudden jumps indicate clock manipulation

Analytical Methodology

1. For each file of interest, collect all available timestamps using stat (Linux) or istat/Autopsy (NTFS). Record mtime, atime, ctime, and birth time separately.
2. On NTFS evidence: compare $SI and $FN timestamps using The Sleuth Kit or Autopsy. Any file where $SI mtime predates $FN mtime is a timestomping candidate, because the kernel updates $FN automatically on creation and modification.
3. Check for impossible timestamps: a file timestamp before the operating system was installed, before the filesystem was created (check $MFT record 0 creation time), or before the version of the creating software was released.
4. For log files: verify that entry timestamps are monotonically non-decreasing (allowing for log rotation resets). Implement a simple parser that flags any entry where the timestamp is earlier than the previous entry by more than a few seconds.
5. Cross-reference with NTP logs (/var/log/chrony/tracking.log, Windows Time Service event 37). Large clock offsets or sudden clock jumps during the incident window indicate the attacker adjusted the system clock.
6. Examine network-level timestamps: packet capture frame timestamps are assigned by the capture interface and cannot be modified post-capture without re-generating the PCAP. Compare log entry timestamps to PCAP frame times for the same events — divergence confirms timestamp manipulation.
7. For PCAP-confirmed event times, use network timestamps as the authoritative source and flag all log entries that diverge from them by more than the expected NTP drift (typically < 1 second on a well-managed network).
8. Document all timestamp anomalies with supporting evidence: the anomalous timestamp, the authoritative timestamp source used for comparison, the delta, and the forensic significance.

Common Analytical Errors

• Trusting atime: Access time is frequently disabled in modern deployments (noatime mount option) or updated by backup tools and security scanners, making it unreliable as evidence. Prefer ctime and $FN timestamps.
• Ignoring sub-second precision: High-resolution timestamps (nanoseconds in ext4, 100ns in NTFS) are rarely spoofed with sub-second precision. A file timestamp rounded to an exact second when surrounding files have nanosecond precision is a timestomping indicator.
• Missing the $MFT entry change time: NTFS $MFT records have their own ctime (the time the MFT entry itself was last modified) in the $STANDARD_INFORMATION attribute. Timestomping tools that update timestamps via the API do NOT update the MFT record's own change time, leaving a reliable indicator.
• Conflating UTC and local time: Log files may record timestamps in local time, UTC, or with timezone offsets. Ensure all timestamps are normalised to UTC before comparison to avoid false positives from timezone arithmetic.

NICE Framework Alignment

Further Reading

• Harlan Carvey: "Windows Forensic Analysis Toolkit" — $MFT timestamp analysis chapter
• The Sleuth Kit documentation: istat, fls, and mactime timeline construction
• SANS FOR508: Advanced DFIR — timestomping detection module
• Maxim Suhanov: "dfir.ru" blog — deep dives into NTFS timestamp artefacts
• Joachim Metz: "libfsntfs" and associated analysis tools for low-level $MFT parsing