40 Linux Commands Every SOC Analyst Should Know in 2026
Linux commands are not just system-administration tools. For a SOC analyst, they are investigation tools used to read logs, validate users, review processes, inspect network connections, calculate file hashes and build an incident timeline. This guide explains 40 commands through practical blue-team use cases rather than definitions alone.
What You Will Learn
- Why Linux knowledge matters in SOC monitoring and incident response
- Exactly 40 commands for files, logs, accounts, processes and networks
- Safe command examples and the suspicious signs an analyst should notice
- How to combine commands during an SSH account-compromise investigation
- A compact cheat sheet, hands-on exercises and interview questions
Why Linux Commands Matter for SOC Analysts
Linux powers web servers, cloud workloads, security appliances, containers, development systems and many enterprise applications. A SOC alert may point to an unfamiliar login, an unusual process, a suspicious outbound connection or a modified file on a Linux host. The analyst must turn that alert into evidence.
Linux command-line skills help you answer practical questions:
- Which user was logged in, and from where?
- Which processes and services were running?
- Was an unexpected port listening?
- Which files were created or modified during the incident window?
- Do authentication logs show brute force, password spraying or a successful login?
- What is the cryptographic hash of a suspicious file?
If you are new to blue-team work, pair this guide with our SOC home lab beginner guide. The lab gives you a safe environment in which to generate logs and practise investigations.
Before You Start: Safe Investigation Habits
Start read-only
Prefer commands that observe state. Do not delete, edit, restart, kill or change ownership until evidence is collected and an authorized responder approves containment.
Record your timeline
Note the system time, timezone, hostname, analyst name, case number and every command used. Timestamp differences can otherwise create a misleading incident timeline.
Understand distribution differences
Ubuntu and Debian commonly use /var/log/auth.log; RHEL-family systems commonly use /var/log/secure. Systems using systemd may store relevant events in the journal.
Protect sensitive output
Logs can contain usernames, IP addresses, tokens and business data. Save evidence only in approved locations and follow your organization’s privacy and retention requirements.
Linux Commands 1–10: Files and Directories
1pwd — Confirm your location
Prints the current working directory. Analysts should confirm location before collecting output or running a relative-path command.
pwd
/tmp or a compromised user’s home directory.2ls — List files and metadata
Lists directory contents. The long, hidden-file and time-sorted options are useful during triage.
ls -lah ls -lat /tmp | head
3cd — Move between directories
Changes the working directory. Use absolute paths during investigations to reduce mistakes.
cd /var/log pwd
/var/log, /tmp, /etc and user home directories.4find — Locate suspicious files
Searches by path, name, type, size, ownership or modification time.
find /tmp -type f -mmin -120 -ls find /home -type f -name "*.sh" -perm /111 2>/dev/null
5file — Identify the real file type
Examines file signatures instead of trusting the extension.
file /tmp/invoice.pdf file /tmp/update
6stat — Inspect detailed metadata
Shows size, owner, permissions and access, modification and metadata-change timestamps.
stat /tmp/suspicious_file
7cat — Read a short text file
Prints file content to the terminal. Use it for small, known text files—not unknown binaries or enormous logs.
cat /etc/os-release cat /etc/hostname
less for large output.8less — Review large logs safely
Opens text in a searchable pager without loading everything on screen.
less /var/log/auth.log # Press /, type a term, then Enter
9head — View the beginning
Displays the first lines of a file or pipeline output.
head -n 20 /etc/passwd ps aux --sort=-%cpu | head
10tail — View or follow recent events
Shows the last lines of a file. The -f option follows new entries in real time.
tail -n 100 /var/log/auth.log tail -f /var/log/syslog
Linux Commands 11–19: Logs and Text Analysis
11grep — Search for evidence
Searches text using strings or regular expressions. Recursive, case-insensitive and line-number options are especially useful.
grep -in "failed password" /var/log/auth.log grep -Rin "curl\\|wget" /tmp 2>/dev/null
12awk — Extract and summarize fields
Processes column-oriented text and is valuable for quick log summaries.
awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log |
sort | uniq -c | sort -nr13sed — Select or transform text
Can print a range or normalize output. During evidence review, direct results to a new file instead of modifying the source.
sed -n '120,170p' /var/log/auth.log sed -n '/Jul 23 10:00/,/Jul 23 10:30/p' /var/log/auth.log
14cut — Extract delimited fields
Quickly selects columns from consistently delimited data.
cut -d: -f1,3,7 /etc/passwd
15sort — Order investigation results
Sorts text alphabetically, numerically or by a selected field.
sort /tmp/source_ips.txt sort -nr /tmp/ip_counts.txt | head
16uniq — Count repeated evidence
Removes or counts adjacent duplicate lines, so it is normally used after sort.
sort /tmp/source_ips.txt | uniq -c | sort -nr
17wc — Count lines, words or bytes
Helps quantify activity and validate the size of collected output.
grep -i "failed password" /var/log/auth.log | wc -l wc -l /tmp/investigation_results.txt
18journalctl — Query systemd logs
Reads the systemd journal and filters by service, boot, priority or time.
journalctl --since "2 hours ago" journalctl -u ssh --since "2026-07-23 09:00" journalctl -p warning --since today
19dmesg — Review kernel messages
Displays kernel ring-buffer messages relating to hardware, drivers, interfaces and low-level events.
dmesg --ctime | tail -n 50 dmesg --level=err,warn
Linux Commands 20–26: Users, Authentication and Permissions
20who — See logged-in sessions
Shows users currently logged in, terminals and login times.
who who -u
21w — See sessions and activity
Shows logged-in users and their current commands, idle time and system load.
w
22last — Review login history
Reads login history and can show remote source addresses.
last -ai | head -n 30 last reboot | head
23id — Check identity and group membership
Displays a user’s UID, primary group and supplementary groups.
id id analyst id suspicious_user
sudo, wheel or application-admin groups.24sudo — Review permitted privilege
The read-oriented -l option lists commands the current user may run through sudo.
sudo -l
25chmod — Understand permission changes
Changes file permissions. SOC analysts should understand it because attackers may make tools executable or expose sensitive data.
# Lab-only example: chmod 640 evidence-copy.log
26chown — Understand ownership changes
Changes the owner or group of a file. Ownership affects who can access or execute it.
# Lab-only example: chown analyst:analyst evidence-copy.log
Linux Commands 27–30: Processes and Services
27ps — Inspect running processes
Displays process details such as user, PID, resource use and command line.
ps aux --sort=-%cpu | head ps -eo user,pid,ppid,lstart,cmd --forest
28top — Monitor active processes
Provides a dynamic view of CPU, memory, load and running processes.
top # Press P for CPU or M for memory sorting
29kill — Send a signal to a process
Can request that a process stop. In incident response, termination may destroy volatile evidence or trigger attacker behavior.
# Inspect available signals: kill -l # Authorized containment only: kill -TERM 1234
30systemctl — Inspect systemd services
Shows service state, enablement and recent status information.
systemctl --failed systemctl status ssh systemctl list-unit-files --state=enabled
Linux Commands 31–38: Network Investigation
31ip — Review interfaces and routes
Shows or manages addresses, links, neighbors and routes. Analysts generally begin with read-only display commands.
ip -brief address ip route ip neigh
32ss — Inspect sockets
Displays listening and established sockets and can associate them with processes.
ss -tulpn ss -tpn state established
33ping — Test basic reachability
Sends ICMP echo requests. Failure does not always mean a host is down because ICMP may be filtered.
ping -c 4 192.0.2.10
34traceroute — Observe the network path
Shows responding hops toward a destination. Results can be incomplete when devices filter probes.
traceroute example.com
35dig — Investigate DNS
Queries DNS records and resolver responses.
dig example.com A dig example.com MX dig +short suspicious.example
36curl — Inspect a web endpoint
Transfers data using URLs. Header-only and verbose TLS checks can help validate a suspicious or failing endpoint.
curl -I https://example.com
curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\\n" https://example.com37tcpdump — Capture or read packets
Captures traffic matching a filter or reads an existing packet capture. Use only with authorization because packet data may be sensitive.
sudo tcpdump -i any -nn -c 100 port 53 tcpdump -nn -r approved-capture.pcap
38lsof — Map open files and connections
Lists open files, including network sockets, and helps connect a process to a port or deleted file.
lsof -i -P -n lsof -p 1234 lsof +L1
Linux Commands 39–40: Evidence and File Triage
39sha256sum — Calculate a file hash
Calculates a SHA-256 digest for identification, integrity checking and controlled threat-intelligence searches.
sha256sum /tmp/suspicious_file sha256sum evidence-copy.log > evidence-copy.log.sha256
40strings — Extract readable text
Extracts printable sequences from binary data for initial triage. It does not safely execute the file.
strings -a /tmp/suspicious_file | less strings -a /tmp/suspicious_file | grep -Ei "https?://|/bin/|token|password"
Practical SOC Scenario: Investigating a Suspected SSH Account Compromise
Assume your SIEM raises an alert for repeated SSH failures followed by a successful login to a Linux server. The account normally connects only during business hours, but this activity occurred at night from an unfamiliar address.
- Confirm system context.
pwd cat /etc/hostname cat /etc/os-release date
Record hostname, operating system, time and timezone in your case notes.
- Focus on the incident window.
journalctl -u ssh --since "2 hours ago" # Debian/Ubuntu alternative: grep -i "failed password\\|accepted" /var/log/auth.log
The service may be named
sshorsshd. Log paths also vary by distribution. - Summarize source addresses.
awk '/Failed password/ {print $(NF-3)}' /var/log/auth.log | sort | uniq -c | sort -nr | headValidate the extracted field against sample lines before relying on the count.
- Review login history and current sessions.
last -ai | head -n 30 who -u w
Compare source IPs, usernames, login times and active commands with the user’s normal pattern.
- Check privilege and group context.
id affected_user sudo -l
Determine whether the affected account has privileged access. Run
sudo -lin the correct authorized user context. - Review processes and persistence clues.
ps -eo user,pid,ppid,lstart,cmd --forest systemctl --failed systemctl list-unit-files --state=enabled
Investigate unfamiliar commands, parent-child relationships and newly enabled services.
- Review network state.
ss -tulpn ss -tpn state established lsof -i -P -n
Correlate unexpected connections with process IDs, command lines and the alert timeline.
- Find recent files without executing them.
find /tmp /var/tmp -type f -mmin -120 -ls 2>/dev/null file /tmp/suspicious_file stat /tmp/suspicious_file sha256sum /tmp/suspicious_file strings -a /tmp/suspicious_file | less
Do not open an unknown executable normally. Preserve it according to the incident-response and evidence-handling procedure.
- Correlate and escalate.
Build a timeline containing failed logins, successful login, privilege activity, process execution, file creation and network connections. Document your evidence, confidence level and recommended containment. Do not declare compromise based on one command alone.
Linux Commands for SOC Analysts: Quick Cheat Sheet
| Investigation goal | Commands | Typical evidence |
|---|---|---|
| Locate and inspect files | pwd, ls, cd, find, file, stat | Paths, owners, permissions, file type and timestamps |
| Read and filter logs | cat, less, head, tail, grep, awk, sed | Authentication, service and application events |
| Count and summarize | cut, sort, uniq, wc | Frequent IPs, users, ports and event counts |
| Review system logs | journalctl, dmesg | Service, boot, kernel and priority-filtered messages |
| Investigate users | who, w, last, id, sudo | Sessions, login history, groups and allowed privilege |
| Understand permissions | chmod, chown | Permission and ownership changes |
| Investigate execution | ps, top, kill, systemctl | Processes, resource use and service state |
| Investigate networking | ip, ss, ping, traceroute, dig, curl, tcpdump, lsof | Interfaces, routes, sockets, DNS, HTTP and packet data |
| Triage suspicious files | sha256sum, strings | File hashes and readable indicators |
Five Safe Hands-On Exercises
- Authentication baseline: Generate successful and failed SSH logins in your lab, then find and count them with
journalctl,grep,awk,sortanduniq. - Process investigation: Start an approved test process, locate it with
psandtop, identify its open files withlsof, and document its parent process. - Network investigation: Run a local web server in your lab, identify its listening port with
ss, test its headers withcurl, and capture a small authorized packet sample. - File triage: Create a harmless shell script, inspect it with
fileandstat, calculate its hash, change the copy, and observe the new hash. - Incident report: Create a short timeline containing alert summary, evidence, commands used, findings, conclusion and recommended response.
For a broader portfolio, explore our guide to 15 cybersecurity projects for beginners.
Linux SOC Analyst Interview Questions
How would you find the IP addresses generating failed SSH logins?
First identify the correct authentication source, such as the systemd journal, /var/log/auth.log or /var/log/secure. Search for failed-login messages, validate the source-IP field, extract it with awk, then use sort | uniq -c | sort -nr to rank repeated sources.
What is the difference between ps and top?
ps produces a point-in-time process listing that is easy to document and filter. top provides a continuously updating view useful for observing changing CPU and memory use.
How do you identify which process is listening on a port?
Use ss -tulpn or an approved equivalent. Then validate the PID with ps and review its executable, owner, parent process, open files and service context.
Why use SHA-256 instead of trusting a filename?
Names and extensions are easily changed. A SHA-256 hash provides a content-based identifier that can support integrity validation and controlled reputation searches.
Would you immediately kill a suspicious process?
No. First preserve relevant volatile evidence, understand the process and its connections, assess business impact, follow the incident-response playbook and obtain the required authorization. Premature termination may destroy evidence or disrupt services.
Continue Your SOC Learning
Official Technical References
Frequently Asked Questions
Does a beginner SOC analyst need Linux?
Yes. You do not need to become a Linux administrator first, but you should be comfortable navigating directories, reading logs, reviewing users, checking processes and examining network connections.
Which Linux commands should a SOC analyst learn first?
Start with ls, find, less, tail, grep, journalctl, last, ps, ss, lsof and sha256sum. Then learn how to combine them into an investigation workflow.
Where are Linux authentication logs stored?
The location depends on the distribution and logging configuration. Debian and Ubuntu commonly use /var/log/auth.log; RHEL-family systems commonly use /var/log/secure. On systemd-based systems, relevant events may be available through journalctl.
Is netstat still required?
It may exist on older systems, but ss is the modern tool normally preferred for socket investigation. Analysts should still recognize netstat because it can appear in older runbooks and interview questions.
Can Linux commands replace a SIEM or EDR?
No. Local commands provide valuable host evidence, while SIEM and EDR platforms provide centralized visibility, correlation, detection and historical context. Good investigations combine both.
Can I upload a suspicious file hash to a public reputation service?
Only if organizational policy permits it. A hash is safer than uploading the file, but hashes may still reveal that your organization possesses a particular sample. Follow data-classification and incident-response requirements.
How can I practise these commands safely?
Build an isolated Linux virtual machine or SOC home lab, create harmless test events, and keep snapshots. Never practise intrusive actions on production systems or systems you do not own.
Do I need to memorize all 40 commands?
No. Understand the purpose and investigation workflow, practise common options and know how to use man command or command --help. Real SOC skill is knowing what evidence you need and how to validate it.
Final Thoughts
A strong SOC analyst does not use Linux commands as isolated tricks. The analyst uses them to build a defensible story: who accessed the host, what changed, which process ran, where it connected, what evidence supports the conclusion and what response is appropriate.
Start with read-only triage, practise in a lab and document every finding. Once these commands become familiar, move into Linux audit logs, detection engineering, shell scripting and SIEM correlation.
Want to Build Practical SOC Investigation Skills?
CybersecurityTRAIN helps beginners and working professionals learn SOC operations through practical labs, SIEM, Windows and Linux log analysis, alert triage, phishing investigation, MITRE ATT&CK and incident-response workflows.
Call or WhatsApp: +91 98857 89887
Email: trainings@thecyberseal.com