Linux top Command Cheat Sheet: Find Suspicious Processes Fast

Linux top Command Cheat Sheet: Real-World Process Monitoring for SOC Analysts and Admins

Quick Answer
The Linux top command shows live CPU, memory, and process activity. Security teams use it to spot runaway or suspicious processes fast, then verify them with ps, /proc, and network tools before acting.

Last verified: October 15, 2026. Syntax checked against common procps-ng behavior; options and keys can vary slightly by distribution and version.

It is 3:12 AM and your monitoring platform fires a high-load alert on a production web server. The box has four cores, and the load average reads 14. Nobody deployed anything. The application team swears nothing changed. You SSH in, type four letters, and within seconds one process with an unfamiliar name is eating most of the CPU.

That scenario is illustrative, but it plays out in some form in nearly every SOC and sysadmin rotation. The Linux top command is often the first tool you reach for during Linux server monitoring and incident triage. This guide covers it the way practitioners use it: as a fast triage instrument, not just a task viewer.

Table of Contents

• Why top Still Matters in Security Work
• Reading the top Header Like an Analyst
• Startup Options You Will Actually Use
• Interactive Keys That Speed Up Triage
• Batch Mode for Logging and Evidence
• From Suspicious Process to Verified Finding
• Detection and Prevention Practices
• Expert Tips
• FAQ
• Conclusion

Why top Still Matters in Security Work

Modern environments lean on endpoint detection and response tools, centralized logging, and cloud-native telemetry. Even so, top remains installed almost everywhere, needs no agent, and gives you a live view of what the machine is doing right now. When an EDR agent is unreachable or you are working on a legacy host, that matters.

Resource anomalies are also a common side effect of unwanted activity. Cryptocurrency mining malware, brute-force storms against SSH, runaway scripts, and data-staging jobs can all leave visible marks in CPU, memory, or process lists. A spike is not proof of compromise, since plenty of benign causes exist, but it tells you where to look next.

Reading the top Header Like an Analyst

Before touching any option, learn the summary area at the top of the screen.

• Load average shows the 1, 5, and 15-minute averages. Compare them against your logical CPU count. A load of 4 on a 4-core machine is roughly fully busy; 14 means work is queuing.
• Tasks lists running, sleeping, stopped, and zombie counts. A growing zombie count can point to a parent process that is not reaping children.
• CPU line splits time into user, system, idle, and I/O wait. High user time suggests compute-heavy work; high wait suggests disk or storage pressure.
• Memory and swap show used, free, and available memory. Heavy swap use alongside rising load usually means memory pressure.

Startup Options You Will Actually Use

These are the command-line flags worth memorizing. Each can be run directly in a terminal.

Basic monitoring

top

Starts live monitoring of CPU, memory, load average, and processes. Use it as your first look at a host.

top -c

Toggles the full command line versus the short command name from startup. This is very useful when several processes share a name like python or java and you need to tell them apart.

Refresh timing

top -d 2
top -d 0.5

The first refreshes every two seconds. The second refreshes every half second, which helps catch short bursts but adds monitoring overhead on busy hosts. Avoid very fast intervals on already struggling servers.

Targeting specific processes

top -p 1234
top -p 1234,5678
top -p "$(pgrep -d, -x nginx)"
top -p "$(pgrep -d, -x sshd)"

Replace the sample PIDs with real ones. The pgrep versions build a comma-separated PID list for a named service. If no matching process exists, the command can fail, so confirm the service is running first. Watching sshd this way is handy when you suspect authentication floods.

Filtering by user and threads

top -u username
top -u "$USER"
top -H

Filter by account, or switch to thread view. User filtering is valuable when one service account behaves oddly, such as a web server user suddenly running heavy jobs. Thread view shows which individual threads burn CPU inside a multi-threaded application.

Limited runs and help

top -n 5
top -V
top -h

The -n flag refreshes a set number of times, then exits. top -h lists supported options. For version output, newer procps-ng builds use -V, while some older builds accepted -v, so try both if one fails.

Interactive Keys That Speed Up Triage

Once top is running, single keystrokes change the view. These are common on procps-ng; behavior can differ on minimal or older builds.

Key	Action	Triage use
P	Sort by CPU usage	Find the process driving a CPU spike
M	Sort by resident memory	Find memory hogs or suspicious staging
T	Sort by cumulative CPU time	Find long-running heavy consumers
c	Toggle command name / full command line	Reveal arguments and paths
1	Show or hide per-CPU statistics	Spot one pinned core versus an even load
u	Filter by user	Focus on one account
o	Add a filter expression	Narrow the list on supported versions
V	Forest (hierarchy) view	See parent-child relationships
y	Highlight running tasks	Visually separate active processes
z	Toggle color	Improve readability where supported
d	Change refresh delay	Slow down or speed up updates
m / t / l	Cycle memory summary / CPU summary / load line display	Customize the header
0	Toggle display of zero values	Reduce clutter in columns
k	Send a signal to a process	Terminate after verification
h	Help	List available keys
q	Quit	Exit top

Accuracy note: the 0 key suppresses zero values in the process columns on procps-ng. It does not toggle the task-count summary, which some cheat sheets claim. The V, y, and o keys depend on your version, so check h if a key does nothing.

A warning about the k key

Caution: pressing k asks for a PID and then a signal; the default is commonly SIGTERM. Killing the wrong process can take down a production service or destroy volatile evidence. In an incident, do not terminate a suspicious process until you have documented it (see the investigation section below) and cleared the action with your incident lead.

Batch Mode for Logging and Evidence

Interactive mode is great for live triage, but incident response needs records. Batch mode (-b) prints plain text instead of the full-screen display, so you can redirect it to a file, pipe it, or schedule it.

top -b -n 1 > top-report.txt

Saves a single snapshot. Use it the moment you notice an anomaly, so you have a timestamped record even if the behavior stops.

top -b -d 2 -n 5

Collects five snapshots two seconds apart, which helps show whether a process is consistently heavy or just spiking.

top -b -d 5 -n 12 > top-monitoring.log

Records 12 snapshots at five-second intervals into a log file, about one minute of observation.

top -b -n 1 | head -n 25

Captures the summary and the first portion of the process list, which is usually enough for a quick note in a ticket.

while true; do
  date
  top -b -n 1 | head -n 15
  sleep 10
done

Repeats a compact, timestamped snapshot every ten seconds. Press Ctrl+C to stop. Redirect output to a file if you want to keep it, and remember it will grow over time.

Cross-checking with other tools

top gives one perspective, so confirm with independent tools:

ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
free -h
uptime
ps -e --no-headers | wc -l

These show a separate CPU-sorted process snapshot, memory and swap totals, uptime with load averages, and a rough process count. A sudden jump in process count compared to your baseline is worth a closer look.

From Suspicious Process to Verified Finding

Back to the 3 AM scenario. top shows an unfamiliar process using heavy CPU. What now? Resist the urge to kill it. Work through a short verification routine.

1. Capture first. Save a snapshot with top -b -n 1 > top-report.txt and note the time.
2. Get the full command line with c in top, or run the command below.

ps -o pid,ppid,user,lstart,cmd -p 1234

Shows the parent PID, owner, start time, and full command. A process started minutes ago by a web server account deserves more attention than a database that has run for weeks.

3. Check where the binary lives.

ls -l /proc/1234/exe

Shows the executable path the process is running from. Processes running from temporary directories, or whose binary shows as deleted, are commonly treated as red flags by responders, though legitimate software can occasionally behave this way too.

4. Look at network activity.

ss -tnp

Lists TCP connections with owning processes (run with sufficient privileges to see process details). Unexpected outbound connections from a process that should not talk to the internet are a strong lead.

5. Escalate with context. Compare findings against change records, review authentication and web logs around the start time, and follow your organization's incident response plan before any containment step.

Per general industry guidance, such as NIST's incident handling recommendations, preserving evidence and documenting actions before containment helps later analysis. Treat this as a general principle rather than specific legal or compliance advice.

Detection and Prevention Practices

top is reactive by nature. To make it part of a stronger defensive posture, pair it with the following.

Build a baseline

You cannot spot abnormal behavior without knowing normal. Record typical load, process counts, and top consumers per server role during healthy periods. Even a simple weekly batch snapshot gives you something to compare against.

Alert on resource anomalies

Feed CPU, memory, and load metrics into your monitoring or SIEM stack, and alert on sustained deviations rather than momentary blips. Cryptojacking detection, for example, often starts with a sustained, unexplained CPU rise.

Reduce the attack surface

• Patch internet-facing services promptly and track vendor advisories.
• Restrict SSH exposure, use key-based authentication, and monitor failed login volume.
• Apply least privilege to service accounts so a compromised web user cannot do much.
• Limit write and execute permissions on temporary directories where your environment allows.

Use layered tooling

No single control stops everything. Combine host-based monitoring, EDR coverage where available, centralized logs, and regular review. These measures reduce risk but do not guarantee protection.

Expert Tips

• Press 1 early. One logical CPU pinned at 100% while others idle looks very different from an evenly loaded system.
• Read load against core count. A load of 8 is calm on a 32-core server and alarming on a 2-core VM.
• Use thread view for big apps. top -H helps pinpoint busy threads inside Java or database processes.
• Do not rely on the process name. Names are easy to imitate. Check the path, parent, owner, and network behavior.
• Save your config. Many procps-ng versions let you press W to save your preferred display layout.
• Mind your overhead. Very short refresh intervals on loaded systems can add noise to the problem you are investigating.
• Document everything. A saved snapshot with a timestamp is worth more than a memory of what you saw.

Related Cybersecurity Topics You Should Explore

• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux findmnt Command: 43 Examples for Security Audits
  
• Linux tune2fs Cheat Sheet: 41 Commands, 4 Costly Mistakes
  
• Linux blkid Command: 41 Examples Every SOC Analyst Should Know
  
• Linux fsck Command Guide: Fix Disk Errors Without Data Loss
  
• Linux mkfs Command Cheat Sheet: Format Disks Safely (2026)
  
• Linux parted Command Cheat Sheet: Partition Disks Safely
  
• Linux fdisk Command Cheat Sheet: Partition Disks Safely (2026)

FAQ

What does top show in Linux?

It shows a live, updating view of system uptime, load average, task counts, CPU and memory usage, and a sortable list of running processes.

How do I sort top by CPU or memory?

Inside top, press P to sort by CPU, M to sort by memory, or T to sort by cumulative CPU time.

How do I save top output to a file?

Use batch mode, for example top -b -n 1 > top-report.txt. For longer captures, add -d for the interval and a higher -n count.

Can top detect malware?

Not by itself. It can reveal suspicious resource usage or unfamiliar processes, but you need follow-up checks on the process path, network connections, logs, and ideally an EDR or malware analysis workflow to confirm anything.

What is the difference between top and ps?

top is a continuously refreshing, interactive view. ps gives a one-time snapshot that is easier to script and filter. Analysts often use both to cross-verify.

How do I monitor a single service with top?

Combine it with pgrep, for example top -p "$(pgrep -d, -x sshd)". If the service is not running, the command may fail.

Is it safe to kill a process from top?

It can be risky. Killing the wrong process may disrupt services or erase evidence. Verify the process and follow your incident procedures first.

Why is my load average high while CPU looks idle?

On Linux, load can include tasks waiting on disk or other I/O. Check the I/O wait value in the CPU line and investigate storage performance.

Conclusion

The top command is not flashy, but in the hands of a careful analyst it is one of the fastest ways to understand what a Linux host is doing. Learn the header, memorize a handful of flags and keys, capture snapshots with batch mode, and always verify before you act. The 3 AM alert will come eventually. With a repeatable routine, you will spend less time guessing and more time making sound decisions.

Analysis based on SOC monitoring and public threat intelligence review.