This One Linux Command Exposed a Hacker's Fake Timestamps

The stat Command in Linux: How SOC Analysts Catch Hidden File Tampering

It was 2:50 AM when a mid-sized fintech company's SOC team got the alert: a suspicious binary had appeared in /tmp on a production server. The file looked harmless at first glance — same name as a legitimate cron script, same size, even the same owner. But something felt off. When the on-call analyst ran a simple, decades-old Linux command, the story fell apart in seconds. The file's change time didn't match its modification time. Someone had touched the metadata to fake the timestamps, but they'd missed one detail that stat exposes every single time.

That command was stat — one of the most underrated tools in a Linux investigator's toolkit. Most sysadmins know it as a quick way to check file size or permissions. But in incident response, digital forensics, and malware triage, stat is often the first command that tells you whether a file has been tampered with, planted, or backdated to blend in with legitimate system activity.

This guide breaks down the stat command from the ground up — not as a dry man-page rehash, but as a working tool used in real SOC investigations, Linux server hardening, and forensic timeline reconstruction.

Table of Contents

• What Is the stat Command and Why It Matters in Security
• Real-World Scenario: Catching a Backdated Malware Drop
• Understanding the Three Linux Timestamps (MAC Times)
• Complete stat Command Reference with Examples
• Detection & Prevention Techniques Using stat
• Expert Tips from Real Incident Response Work
• Related Reading
• FAQ
• Conclusion

What Is the stat Command and Why It Matters in Security?

stat is a built-in Linux/Unix utility that displays detailed metadata about a file or directory — far more than what ls -l shows on the surface. It reveals file size, permissions, ownership, inode number, filesystem block size, file type, and three separate timestamps that track when a file was accessed, modified, and had its metadata changed.

For everyday sysadmin work, that's useful for troubleshooting. For a security analyst, it's something else entirely: a window into a file's history that attackers often forget to fully cover. Malware authors and intruders frequently use tools like touch to reset a file's modification and access times to match surrounding files — a classic anti-forensics trick called timestomping. But the inode's change time (ctime) is much harder to fake convincingly, and stat is usually the tool that surfaces the mismatch.

Real-World Scenario: Catching a Backdated Malware Drop

Back to that 2:50 AM alert. The suspicious file in /tmp claimed to be a legitimate cron helper script. Its modification timestamp read six months old — consistent with the rest of the directory. A less careful analyst might have moved on. Instead, the SOC analyst ran stat against the file and compared all three timestamps side by side.

The access time and modification time had clearly been manipulated to match older files nearby. But the change time — the timestamp that updates whenever permissions, ownership, or inode metadata is altered — showed the file had been touched less than an hour earlier. That single inconsistency confirmed the file was planted, not part of the original system image. It triggered a full incident response, isolation of the host, and a hunt for lateral movement.

This is the everyday reality of Linux forensics: attackers can rewrite the story a file tells, but they rarely rewrite it perfectly. stat is often the tool that catches the seam.

Understanding the Three Linux Timestamps (MAC Times)

Before diving into command syntax, it helps to understand what investigators call "MAC times":

• Modification time (mtime) — Updated when the file's content changes.
• Access time (atime) — Updated when the file is read or opened.
• Change time (ctime) — Updated when the file's metadata changes (permissions, ownership, links) or the content changes. This is the one attackers most often forget to fake, since common tools like touch don't let you set it directly.

When these three timestamps don't align in a way that makes sense for how a file was supposedly created or used, that's a red flag worth escalating.

Complete stat Command Reference with Examples

Here's the full breakdown of practical stat usage, from basic checks to forensic-grade custom output.

Get file details

stat file.txt

What it does: Displays a full metadata report — size, permissions, owner, group, inode, and all three timestamps.
When to use it: The first command to run when triaging a suspicious file.
Expected output: A multi-line block showing File, Size, Blocks, Device, Inode, Links, Access, Modify, and Change fields.

Check a directory

stat myfolder

What it does: Shows the same metadata for a directory instead of a single file.
When to use it: Useful when investigating whether an attacker created a new directory to stage tools or exfiltrated data.

Show only the modification time

stat -c %y file.txt

What it does: Prints just the last modification timestamp.
When to use it: Quick scripting checks or when building timelines across many files.

Show only the file size

stat -c %s file.txt

What it does: Prints file size in bytes only.
When to use it: Handy for spotting suspiciously small "empty" binaries or oversized log files that could indicate data staging.

Check multiple files

stat file1.txt file2.txt

What it does: Displays metadata for several files in one pass.
When to use it: Comparing a batch of files dropped around the same time during an intrusion.

Show only permissions (symbolic)

stat -c %A file.txt

What it does: Shows permissions in symbolic form (e.g., rwxr-xr-x).
When to use it: Quickly spotting world-writable files or unexpected executable bits — a common privilege escalation vector.

Show octal permissions

stat -c %a file.txt

What it does: Prints permissions as octal (e.g., 755).
When to use it: Useful in scripts and hardening audits comparing against baseline permission policies (like CIS Benchmarks).

Show file owner

stat -c %U file.txt

What it does: Displays the username that owns the file.
When to use it: Detecting files owned by root or a service account that shouldn't have write access to that location.

Show file group

stat -c %G file.txt

What it does: Displays the group owner.
When to use it: Checking group-based access misconfigurations during audits.

Show inode number

stat -c %i file.txt

What it does: Prints the file's inode number.
When to use it: Tracking whether a file was replaced (same name, different inode) — a common sign of a swapped-in malicious binary.

Show access time

stat -c %x file.txt

What it does: Displays the last access timestamp.
When to use it: Determining whether a sensitive file (like /etc/shadow) was read recently.

Show change time

stat -c %z file.txt

What it does: Displays the last metadata change timestamp — the ctime discussed earlier.
When to use it: Comparing against mtime/atime to detect timestomping attempts.

Show filesystem information

stat -f file.txt

What it does: Displays details about the filesystem hosting the file (type, block size, total/free blocks).
When to use it: Useful when investigating disk space anomalies tied to log flooding or data staging attacks.

Show file type

stat -c %F file.txt

What it does: Prints the file type — regular file, directory, symbolic link, socket, etc.
When to use it: Confirming a suspicious object isn't disguised as something it's not (e.g., a symlink pretending to be a regular config file).

Show block size

stat -c %o file.txt

What it does: Displays the optimal I/O block size for the file.
When to use it: Mostly performance tuning, but occasionally relevant when analyzing disk layout during forensic disk imaging.

Check a symbolic link

stat symlink

What it does: Shows metadata for the link's target by default (use stat -l/lstat behavior variants to inspect the link itself).
When to use it: Detecting malicious symlinks used to redirect trusted scripts to attacker-controlled files — a known privilege escalation technique.

Display all information in custom format

stat -c "Name: %n Size: %s Owner: %U" file.txt

What it does: Prints only the fields you choose, in the order you choose.
When to use it: Building automated log-collection scripts for SIEM ingestion or bulk audits across thousands of files.

Check hidden file details

stat .env

What it does: Displays metadata for hidden configuration files.
When to use it: Checking whether sensitive files like .env, .bash_history, or .ssh/authorized_keys were modified outside expected maintenance windows.

Check file using absolute path

stat /home/user/file.txt

What it does: Runs the same inspection using a full path.
When to use it: Essential in scripts and remote investigations where the working directory isn't guaranteed.

Verify file information

stat file.txt && ls -l file.txt

What it does: Runs both commands back to back for cross-verification.
When to use it: Good practice during evidence collection — having two independent tools agree strengthens your findings in an incident report.

Detection & Prevention Techniques Using stat

On its own, stat is a manual inspection tool. In a real SOC workflow, it's usually combined with automation and monitoring:

• Baseline critical files: Record inode numbers, permissions, and hashes for key binaries and configs. Any drift caught by stat plus a hash check (e.g., sha256sum) is a strong tampering signal.
• Automate MAC time comparisons: Script a check that flags files where ctime is newer than mtime by an unusual margin — a common timestomping fingerprint.
• Watch high-value directories: Combine stat with inotifywait or auditd rules on directories like /etc, /tmp, and web server upload folders.
• Correlate with auditd and syslog: stat shows the current state; audit logs show the history of who changed what. Together they build a defensible timeline.
• Harden permissions proactively: Use stat -c %a across cron jobs and startup scripts to catch overly permissive files before attackers exploit them.

Expert Tips from Real Incident Response Work

• Don't trust mtime alone — always pull all three timestamps together before drawing conclusions.
• When comparing suspected duplicate files, check inode numbers with stat -c %i first; identical names with different inodes almost always mean something was swapped.
• Build a "known-good" stat snapshot of your gold-image server and diff it against production regularly. It's a low-cost, high-value integrity check that many teams skip.
• Remember that root can still manipulate atime and mtime with touch -d, so treat stat output as a strong clue, not absolute proof — always cross-reference with filesystem journals or EDR telemetry when stakes are high.

Related Cybersecurity Topics You Should Explore

• locate Command in Linux: Small Tool, Big Security Implications
  
• The Linux find Command: A SOC Analyst's Guide to Hunting Hackers
  
• mv Command Guide: How SOC Analysts Use It Safely (2026)
  
• I Found a Hacker Hiding in a Single Linux cp Command
  
• Kali Linux 2026.2 Released: 9 New Hacking Tools & Major Upgrades
  
• rm Command in Linux: The Tutorial (And the Mistake That Kills Servers)
  
• rmdir vs rm -r: The Linux Command Mistake That Costs Evidence

FAQ

Is the stat command available on all Linux distributions?

Yes, stat is part of GNU coreutils and ships by default on virtually every major Linux distribution, including Ubuntu, Debian, RHEL, and CentOS. macOS and BSD systems use a slightly different syntax (using -x flags instead of -c), so always check man stat on unfamiliar systems.

Can stat detect malware directly?

No. stat doesn't scan file content or signatures — it only reveals metadata. It's a supporting forensic tool that helps analysts spot inconsistencies, not an antivirus replacement.

What's the difference between stat and ls -l?

ls -l gives a quick summary line per file. stat provides a far deeper metadata report, including inode numbers, all three timestamps, and block allocation details that ls doesn't show.

Can attackers fake all three timestamps shown by stat?

Sophisticated attackers with root access can manipulate mtime and atime fairly easily using tools like touch. Ctime is harder to falsify convincingly through normal userland tools, which is why analysts pay close attention to it during timeline reconstruction.

Is stat useful for file integrity monitoring (FIM)?

Yes, many lightweight FIM scripts use stat output (permissions, ownership, and timestamps) alongside file hashes to detect unauthorized changes to critical system files.

Does stat work on remote or networked files?

Yes, as long as the filesystem is mounted locally, such as an NFS or SMB share. For files on a remote host you don't have direct access to, you'd need to run stat over SSH or through your EDR's remote query capability.

Conclusion

stat is proof that some of the most powerful security tools aren't flashy dashboards or expensive platforms — they're small, reliable commands that have been sitting in Linux since the early days of Unix. For SOC analysts, incident responders, and system administrators, mastering stat means being able to look past a file's surface-level story and ask the harder question: does the metadata actually add up?

The next time you're triaging a suspicious file at 2 AM, skip the guesswork. Run stat, compare the timestamps, check the inode, and let the metadata tell you what really happened.