Linux File Operations Commands: The Complete SOC Analyst's Field Guide to Investigation and Forensics
It's 2:47 AM when the alert fires. A junior SOC analyst gets pinged: unusual outbound traffic from a Linux web server that shouldn't be talking to an IP in Eastern Europe. No fancy EDR agent is installed on this box — it's a legacy production server, and the only thing standing between "false alarm" and "active breach" is a terminal, SSH access, and a set of Linux commands most people learned in a college course and forgot about.
This is the moment where cat, grep, and sha256sum stop being "basic Linux commands" and become forensic instruments. Every SOC analyst, incident responder, and penetration tester eventually learns that file operation commands aren't just for managing files — they're for reading a system's memory of what happened. A modified /etc/passwd, a webshell dropped in /var/www/html, a tampered binary in /usr/bin — all of it leaves fingerprints, and these commands are how you find them.
This guide breaks down the complete list of Linux file operations commands, but not as a dry reference sheet. Each command is framed the way it actually gets used in real SOC investigations, bug bounty recon, and enterprise incident response.
Table of Contents
- Why File Commands Matter in Real Incident Response
- Viewing and Inspecting Files
- Comparing and Verifying File Integrity
- Searching and Processing Text
- File Metadata, Paths, and Links
- Splitting, Truncating, and Secure Deletion
- Encoding, Hex, and Format Conversion
- Checksums and Hashing for Malware Triage
- Real-World Scenario: Tracing a Webshell
- Detection and Prevention Best Practices
- Expert Tips from the Field
- FAQ
- Conclusion
Why File Commands Matter in Real Incident Response
When an EDR agent isn't installed, or when you're working on a hardened jump box, embedded device, or cloud instance with minimal tooling, these native Linux utilities are often all you have. They're pre-installed on nearly every distro, they don't trigger antivirus alerts the way a downloaded forensic tool might, and they're fast enough to run against gigabyte-sized log files without choking the system.
For SOC analysts, these commands answer three core investigative questions: What changed? Who touched it? Is it what it claims to be? For penetration testers and bug bounty researchers, the same commands help enumerate file structures, extract secrets from binaries, and validate findings before reporting.
Viewing and Inspecting Files
The first step in almost any investigation is simply reading what's there — but doing it efficiently matters when you're dealing with multi-gigabyte auth logs or crash dumps.
cat /var/log/auth.log
What it does: Dumps the entire file to standard output. When to use it: Quick review of small config or log files. Expected output: Full file contents printed to terminal — but avoid this on huge files, since it floods your scrollback.
tac /var/log/syslog
What it does: Same as cat but reverses line order. When to use it: Reviewing the most recent log entries first, which is exactly how you want to triage an active incident — newest events at the top.
head -n 50 access.log
tail -f /var/log/nginx/access.log
What they do: head shows the first lines (great for checking file headers and log start times); tail -f streams new lines as they're written — the single most-used command for live-monitoring an attacker's activity on a compromised web server in real time.
less +G suspicious_binary.log
What it does: Opens a file for scrollable, searchable viewing without loading it fully into memory. When to use it: Multi-GB logs where cat would be painfully slow. Use /pattern inside less to search interactively.
touch evidence_placeholder.txt
What it does: Creates an empty file or updates a file's timestamp. Forensic note: Attackers sometimes use touch -r to backdate a malicious file's timestamp to match legitimate system files — a classic anti-forensics trick worth knowing both offensively and defensively.
Comparing and Verifying File Integrity
Change detection is the backbone of file integrity monitoring, and these commands are what most FIM tools use under the hood.
diff config_baseline.conf config_current.conf
What it does: Shows line-by-line differences between two text files. Real-world use: Comparing a known-good sshd_config or crontab against the current version after a suspected compromise instantly reveals unauthorized changes.
cmp original_binary patched_binary
What it does: Byte-by-byte comparison, ideal for binaries where diff's line-based logic doesn't apply. When to use it: Verifying whether a system binary like /bin/ls or /usr/bin/ps has been trojanized by a rootkit.
comm -3 sorted_list_a.txt sorted_list_b.txt
What it does: Compares two sorted files and shows unique lines. Practical use: Comparing a list of expected running processes against actual processes to spot injected or hidden entries.
Searching and Processing Text
This is where the real investigative horsepower lives — turning raw noise into actionable indicators.
grep -E "Failed password|Invalid user" /var/log/auth.log
What it does: Searches for pattern matches using regex. Why it matters: This single command is how most brute-force attacks against SSH get discovered — filtering thousands of lines down to the handful that matter.
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head
What it does: awk extracts fields, sort orders data, uniq -c counts occurrences. Real-world use: This exact pipeline is a go-to for identifying the top source IPs hammering a web server during a suspected DDoS or credential-stuffing campaign.
sed -n '/2026-08-05/,/2026-08-06/p' server.log
What it does: Stream-edits text — here extracting only log lines within a specific date range. When to use it: Narrowing a massive log to the exact incident window before deeper analysis.
cut -d',' -f1,3 breach_data.csv
paste file1.txt file2.txt
join -j1 users.txt logins.txt
What they do: cut extracts specific columns; paste merges files side by side; join combines files on a shared key field — useful for correlating a leaked username list against active account logs during breach triage.
tr -d '\r' < windows_export.txt > clean.txt
What it does: Translates or deletes characters. Common use: Stripping carriage returns from Windows-exported log files so Linux tools parse them correctly.
wc -l access.log
What it does: Counts lines, words, or bytes. Use case: A sudden, unexplained spike in log line count over a short window is often the first quantitative sign of an automated attack.
tail -f auth.log | tee incident_20260807.log
What it does: tee writes output to a file while still displaying it on screen. Why analysts use it: Lets you monitor live activity while simultaneously building a preserved evidence copy for the incident report.
strings malware_sample.bin | grep -i "http"
What it does: Extracts readable text from a binary file. Why it's critical: This is often the fastest way to pull embedded C2 URLs, hardcoded IPs, or suspicious file paths out of a malware sample before you even open a disassembler.
File Metadata, Paths, and Links
file suspicious_upload.php
stat /var/www/html/wp-config.php
What they do: file identifies true file type regardless of extension — catching an attacker's classic trick of naming a webshell image.jpg.php. stat reveals modification, access, and change timestamps (MAC times), which are essential for building an incident timeline.
basename /var/www/html/shell.php
dirname /var/www/html/shell.php
realpath ../shared/config.php
readlink -f /usr/bin/python
What they do: These four commands parse and resolve file paths. Real-world use: readlink -f is particularly useful for tracing symlinks that attackers use to redirect legitimate-looking paths to malicious payloads elsewhere on disk.
ln original.log hardlink.log
ln -s /opt/app/config.yaml /etc/app_config.yaml
What they do: Create hard links (same inode) and symbolic links (path pointers). Forensic angle: Attackers sometimes create symlinks to sensitive files inside publicly accessible web directories to exfiltrate data via HTTP — always audit unexpected symlinks in web roots.
Splitting, Truncating, and Secure Deletion
split -b 100M large_dump.pcap chunk_
csplit access.log '/2026-08-06 00:00/'
truncate -s 0 /var/log/wtmp
What they do: split breaks large files into manageable chunks (useful for uploading large pcap captures to analysis tools with size limits); csplit splits by pattern match; truncate resizes a file, including to zero bytes. Critical warning: truncate -s 0 on a log file is a common anti-forensics technique attackers use to wipe evidence while leaving the file itself intact — seeing a zero-byte log where activity is expected is itself an indicator of compromise.
shred -uz malicious_dropper.exe
What it does: Securely overwrites and deletes a file. Legitimate use: Safely destroying sensitive evidence copies or credentials after an investigation closes, in line with data handling policy.
Encoding, Hex, and Format Conversion
od -c payload.bin | head
xxd firmware.bin | grep "4d 5a"
hexdump -C suspicious.dat
What they do: All three render binary data in human-readable octal or hexadecimal. Real-world use: Spotting a hex signature like 4d 5a (the "MZ" header) inside a file that shouldn't contain an executable is a fast way to catch disguised malware payloads.
nl script.sh
fold -w 80 report.txt
fmt -w 72 notes.txt
expand -t 4 code.py
unexpand -a formatted.txt
iconv -f WINDOWS-1252 -t UTF-8 legacy_log.txt
dos2unix config.ini
unix2dos export.csv
What they do: These handle formatting and encoding cleanup — numbering lines, wrapping text, converting tab/space usage, and fixing encoding or line-ending mismatches between Windows and Linux exports. In enterprise environments where logs move between platforms, these small conversions prevent parsing errors in your SIEM ingestion pipeline.
Checksums and Hashing for Malware Triage
md5sum sample.exe
sha1sum sample.exe
sha256sum sample.exe
cksum sample.exe
What they do: Generate cryptographic or simple checksums of a file. Why this matters most of all: Hashing is the single most common first step in malware triage — you compute a file's SHA-256 hash and check it against threat intelligence platforms like VirusTotal before doing anything else. It's also how you verify that a downloaded security patch or forensic tool hasn't been tampered with in transit. SHA-256 is the current industry standard; MD5 and SHA-1 are still seen in older tooling and IOC feeds but are considered cryptographically weak for security-critical use.
Real-World Scenario: Tracing a Webshell
Back to that 2:47 AM alert. Here's how the investigation actually unfolds using nothing but the commands above:
- SSH into the box and run
tail -f /var/log/nginx/access.logto watch live traffic — a repeated POST request to an unfamiliar PHP file stands out immediately. - Run
file suspicious.phpandstat suspicious.php— the file type checks out as a PHP script, but the modification timestamp is three days old, while the rest of the directory was deployed six months ago. - Use
cat suspicious.phpalongsidegrep -i "eval\|base64_decode"to spot obfuscated code — a near-universal webshell fingerprint. - Run
sha256sum suspicious.phpand check the hash against VirusTotal and internal threat intel — confirmed match to a known webshell family. - Pull the full picture with
grep "suspicious.php" access.log | awk '{print $1}' | sort | uniq -c | sort -nrto identify every source IP that accessed the webshell, building the attacker's access timeline. - Check
/var/log/wtmpand/var/log/auth.logwithlastandgrepfor any related SSH logins around the same window, looking for lateral movement.
Twenty minutes, zero specialized tools, full attacker timeline. This is the value of mastering these fundamentals.
Detection and Prevention Best Practices
- Deploy file integrity monitoring (FIM) tools such as AIDE, Tripwire, or OSSEC to automate the
diff/checksum comparison process across critical directories. - Baseline and hash critical binaries and configs regularly, storing SHA-256 values off-host so an attacker can't tamper with your reference values.
- Monitor for anomalous
truncate,shred, or log-clearing activity — these are strong anti-forensics indicators and should trigger high-priority alerts. - Restrict write access to web roots and audit for unexpected symlinks or newly created files with unusual timestamps.
- Centralize logs to a remote SIEM immediately, so local log tampering can't erase the evidence trail.
- Use immutable file attributes (
chattr +i) on critical system files where operationally feasible.
Expert Tips from the Field
- Chain commands with pipes rather than memorizing one-off tools — the real power is in combinations like
grep | awk | sort | uniq -c. - Always hash a file before you analyze it, and again after, to prove you didn't alter evidence during your own investigation.
- When timestamps look "too clean," suspect
touch -rbackdating rather than trusting them at face value. - Keep a personal cheat sheet of these commands with real incident examples — muscle memory matters more than documentation during an active breach.
- Practice these commands regularly in a lab environment (HackTheBox, TryHackMe) so they're second nature under pressure.
Related Cybersecurity Topics You Should Explore
- How a Fake Movie File Can Empty Your Bank Account in Seconds
- CaptiveCrunch: How Russian Hackers Turned Hotel Wi-Fi Into a Weapon
- CVE-2026-12935: The TP-Link Bug Every Router Owner Should Fix Now
- Adform Hack Turns Trusted Ad Script Into a Crypto Stealer
- The Security Story Hidden Inside Windows 11's Big Update
- SplitVPN Data Breach: 865K Users Exposed, 'No-Logs' Was a Lie
- Brinks Home Data Breach: The Phone Call That Cost Millions
- GPG Command Tutorial: The Encryption Trick Real SOC Analysts Use
- AI Found a Chrome Bug Hiding for 13 Years. Here's How.
- This Open-Source AI Agent Turns ChatGPT Into a Hacker
- GenieLocker Ransomware Explained: How Toy Ghouls Hack ESXi Servers
Frequently Asked Questions
Q1: What's the difference between MD5, SHA-1, and SHA-256 for file verification?
They're all checksum algorithms of increasing cryptographic strength. MD5 and SHA-1 are fast but vulnerable to collision attacks, so SHA-256 is preferred for security-critical verification like malware hash comparison.
Q2: Can these commands replace a full forensic toolkit like Autopsy or FTK?
No — they're excellent for rapid triage and live-system investigation, but formal forensic acquisition and chain-of-custody work still requires dedicated forensic imaging and analysis tools.
Q3: Why do attackers target log files specifically with truncate or shred?
Clearing or wiping logs removes the evidence trail of their access and actions, delaying detection and complicating incident response and attribution.
Q4: Is grep enough for searching large enterprise log files?
For ad-hoc investigation, yes. For continuous, large-scale monitoring, pairing these commands with a SIEM (Splunk, ELK, Sentinel) is the enterprise standard.
Q5: How can I tell if a file's timestamp has been tampered with?
Cross-reference the file's stat output (modify, access, change times) against related system logs and file system journal entries — inconsistencies often reveal manual timestamp manipulation.
Q6: Are these commands available on all Linux distributions?
Nearly all are part of GNU coreutils and are pre-installed on virtually every major distro, including Ubuntu, Debian, RHEL, and CentOS, making them reliable across almost any environment.
Conclusion
These forty-plus commands might look like a basic Linux reference list at first glance, but in the hands of a SOC analyst or incident responder, they form a complete investigative toolkit. Malware doesn't announce itself — it hides in file types that lie about themselves, timestamps that don't add up, and logs that mysteriously go quiet. Mastering these commands means you can find that story even when there's no fancy tooling installed, just a terminal and the knowledge of where to look.




