Monday, November 2, 2026
No menu items!
Google search engine
HomeCheat SheetsLinux Commands Cheatsheet: A Survival Guide for the Terminal-Averse

Linux Commands Cheatsheet: A Survival Guide for the Terminal-Averse

Category: Cheat Sheets

Tags: linux, bash, command-line, enumeration, forensics


There are people who think Linux is hard because it doesn't have a Start menu. There are also people who think Linux is easy because everything is "just a file." Both groups are wrong. Linux is a collection of extremely powerful tools connected by a syntax that was designed in the 1970s by people who charged per keystroke and had strong opinions about vowels.

This cheatsheet covers the commands that matter for security operations -- enumeration, user analysis, networking, process inspection, file hunting, persistence checking, and quick forensic triage. Keep it bookmarked. Your future self, staring at a compromised server at 2am, will thank you.


System Enumeration

Before you can assess a system, you need to know what it is. These commands answer the basics: what OS, what kernel, what hardware, how long has it been running, and who else is logged in.

uname -a                            # Kernel version, architecture
cat /etc/os-release                  # Distribution info
hostnamectl                          # Hostname, OS, kernel
id                                   # Current user, UID, groups
whoami                               # Current username
w                                    # Who is logged in right now
last -a                              # Login history
lastlog                              # Last login per user
uptime                               # Uptime and load average
env                                  # Environment variables
cat /proc/version                    # Kernel compile info
lscpu                                # CPU details
free -h                              # Memory usage
df -h                                # Disk usage
mount                                # Mounted filesystems
lsblk                                # Block devices

The output of uname -a alone tells you the kernel version (is it vulnerable to DirtyPipe?), the architecture (is this a 32-bit relic?), and the hostname (is this the right server?). Starting anywhere else is optimistic.


User and Group Information

Understanding who has access to a system -- and what level of access they have -- is fundamental to both offensive assessment and incident investigation.

cat /etc/passwd                      # All users (check login shells)
cat /etc/shadow                      # Password hashes (requires root)
cat /etc/group                       # Group memberships
cat /etc/sudoers                     # Sudo configuration (requires root)
sudo -l                              # Current user's sudo privileges
getent passwd                        # NSS user database
grep -v nologin /etc/passwd          # Users with actual login shells
awk -F: '$3 == 0 {print $1}' /etc/passwd   # UID 0 accounts (should only be root)

If awk -F: '$3 == 0 {print $1}' /etc/passwd returns anything other than "root," someone has been creative. UID 0 accounts that aren't root are a classic persistence technique -- check the creation date and whether anyone remembers making them.


Networking

Network configuration reveals what the system connects to, what connects to it, and what firewall rules (if any) are in place.

ip a                                 # All interfaces and IPs
ip r                                 # Routing table
ip neigh                             # ARP table (neighbours)
ss -tulnp                            # Listening ports with process names
ss -antp                             # All TCP connections with state
ss -s                                # Socket statistics summary
cat /etc/resolv.conf                 # DNS configuration
cat /etc/hosts                       # Static hostname mappings
iptables -L -n -v                    # Firewall rules (iptables)
iptables -t nat -L -n                # NAT rules
nft list ruleset                     # nftables rules
netstat -tulnp                       # Legacy alternative to ss

Packet capture (when needed):

tcpdump -i eth0 -w capture.pcap     # Full capture to file
tcpdump -i eth0 port 80 -A          # HTTP traffic in ASCII
tcpdump -i eth0 'host 10.10.10.5'   # Traffic to/from specific host
tcpdump -i eth0 -c 100              # Capture 100 packets then stop

The command ss -tulnp is the single most useful networking command during an investigation. It shows every listening port and which process owns it. If something is listening on port 4444 and nobody can explain why, that's your starting point.


Process Management

Understanding what processes are running -- and what they're doing -- is essential during both live response and routine assessment.

ps aux                               # All processes, all users
ps auxf                              # Process tree (shows parent-child)
ps -eo pid,ppid,user,cmd --sort=-%mem   # Sorted by memory usage
top -bn1                             # One-shot snapshot of top
htop                                 # Interactive viewer (if installed)
pstree -p                            # Visual process tree with PIDs
lsof -i                              # All network connections by process
lsof -i :80                          # What process is using port 80
lsof -p <pid>                        # All files opened by a process
lsof -u <user>                       # All files opened by a user
kill -9 <pid>                        # Force terminate (last resort)
strace -p <pid>                      # Trace system calls (live)
ltrace -p <pid>                      # Trace library calls

Investigating suspicious processes:

cat /proc/<pid>/cmdline | tr '\0' ' '    # Full command line
cat /proc/<pid>/environ | tr '\0' '\n'   # Environment variables
ls -la /proc/<pid>/exe                    # Symlink to actual binary
ls -la /proc/<pid>/fd/                    # Open file descriptors
cat /proc/<pid>/maps                      # Memory mappings

The /proc filesystem is the investigator's best friend on a live system. Even if the attacker deleted their binary from disk, /proc//exe still points to it. Copy it out with cp /proc//exe /tmp/recovered_binary before killing the process.


File Search and Analysis

Finding suspicious files is where investigations get interesting. SUID binaries, world-writable files, recently modified files, and files with unusual capabilities are all worth hunting.

# SUID binaries (privilege escalation candidates)
find / -perm -4000 -type f 2>/dev/null

# SGID binaries
find / -perm -2000 -type f 2>/dev/null

# World-writable files (shouldn't exist in system directories)
find / -perm -o+w -type f 2>/dev/null

# World-writable directories
find / -perm -o+w -type d 2>/dev/null

# Files owned by root but writable by others
find / -user root -perm -o+w -type f 2>/dev/null

# Recently modified files (last 24 hours)
find / -mtime -1 -type f 2>/dev/null

# Files with no owner (orphaned -- potentially suspicious)
find / -nouser -type f 2>/dev/null

# Config files containing passwords
find /etc -name "*.conf" -exec grep -il "password" {} \;

# Files with capabilities set
getcap -r / 2>/dev/null

# Immutable files (can't be modified even by root)
lsattr -R / 2>/dev/null | grep "\-i\-"

SUID binaries are the gift that keeps on giving for privilege escalation. Cross-reference every result with GTFOBins -- if a SUID binary appears there, you likely have a path to root.


Cron and Scheduled Jobs

Scheduled tasks are a favourite persistence mechanism. Check all of them -- system-wide, per-user, and systemd timers.

crontab -l                           # Current user's crontab
crontab -l -u <user>                 # Other user's crontab (requires root)
cat /etc/crontab                     # System-wide crontab
ls -la /etc/cron.d/                  # Additional cron jobs
ls -la /etc/cron.daily/              # Daily jobs
ls -la /etc/cron.hourly/             # Hourly jobs
ls -la /etc/cron.weekly/             # Weekly jobs
ls -la /etc/cron.monthly/            # Monthly jobs
ls -la /var/spool/cron/crontabs/     # User crontab files
systemctl list-timers --all          # systemd scheduled timers
cat /etc/anacrontab                  # anacron jobs

Pay special attention to cron jobs that execute scripts in world-writable directories, or jobs that run as root but reference files owned by non-root users. Both are exploitable.


Service Management

Understanding which services are running, enabled, and what their configurations look like is critical for both hardening and investigation.

systemctl list-units --type=service --state=running    # Running services
systemctl list-units --type=service --state=active     # Active services
systemctl status <service>                              # Service details
systemctl cat <service>                                 # Unit file contents
systemctl show <service>                                # All properties
systemctl list-unit-files                               # Enabled/disabled state
systemctl is-enabled <service>                          # Check specific service

# Logs
journalctl -u <service> --since "1 hour ago"           # Recent service logs
journalctl -u <service> -f                              # Follow logs live
journalctl -u <service> --no-pager                      # Full output

Log Locations

Knowing where logs live saves time during every investigation. The locations differ between Debian/Ubuntu and RHEL/CentOS families.

Log Debian/Ubuntu RHEL/CentOS
System messages /var/log/syslog /var/log/messages
Authentication /var/log/auth.log /var/log/secure
Kernel /var/log/kern.log /var/log/messages
Boot /var/log/dmesg /var/log/dmesg
Failed logins /var/log/faillog /var/log/faillog
Login records /var/log/wtmp (use last) /var/log/wtmp
Bad logins /var/log/btmp (use lastb) /var/log/btmp
Cron /var/log/syslog /var/log/cron
Audit /var/log/audit/audit.log /var/log/audit/audit.log

Journald queries:

journalctl --since "2024-01-01" --until "2024-01-02"   # Date range
journalctl -p err                                       # Errors only
journalctl _COMM=sshd                                   # By program name
journalctl -k                                           # Kernel messages only
journalctl --disk-usage                                  # How much space logs use

If /var/log/auth.log or /var/log/secure has been truncated or deleted, that's not a log rotation issue -- that's evidence of someone covering their tracks.


Persistence Locations

When investigating a compromise, check every common persistence mechanism. Attackers need to survive reboots, and these are the locations that let them.

# Startup scripts and init
/etc/rc.local                        # Legacy startup script
/etc/init.d/                         # SysV init scripts
/etc/systemd/system/                 # systemd unit files (custom services)

# Shell profile scripts (execute on login)
~/.bashrc
~/.profile
~/.bash_profile
/etc/profile
/etc/profile.d/
/etc/bash.bashrc

# SSH persistence
~/.ssh/authorized_keys               # Added SSH keys
/etc/ssh/sshd_config                 # Modified SSH config

# LD_PRELOAD hijacking
/etc/ld.so.preload                   # Libraries loaded before all others
cat /etc/ld.so.conf                  # Shared library search paths
ldconfig -p                          # Shared library cache

# Kernel modules
lsmod                                # Currently loaded modules
modinfo <module>                     # Module details
ls /lib/modules/$(uname -r)/         # Available modules

The most overlooked persistence location is ~/.bashrc. Adding a reverse shell one-liner to a user's .bashrc means it executes every time they open a terminal. Subtle, effective, and frequently missed during triage.


Quick Forensic Triage

When time is short and the incident is live, these commands give rapid insight into what happened and when.

# Timeline of recent file changes
find / -mtime -1 -printf "%T+ %p\n" 2>/dev/null | sort

# Hash a file for IOC checking
sha256sum <file>
md5sum <file>

# Baseline all binaries for integrity checking
find /usr/bin -type f -exec sha256sum {} \; > baseline.txt

# Find deleted files still held open by processes
lsof +L1

# Network connections with process context
ss -tulnp

# Raw TCP connections from /proc
cat /proc/net/tcp

# Package integrity verification (Debian)
dpkg -V
debsums -c

# Package integrity verification (RHEL)
rpm -Va

The combination of find / -mtime -1, ss -tulnp, and lsof +L1 gives a rapid picture of what changed recently, what's communicating, and what's been deleted but is still running. In the first five minutes of an incident, that's usually enough to determine the scope.


What's Next

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments