Linux · Lesson 08

Processes & Resource Review

Investigate Linux processes using identity, parentage, executables, resources, open files, sockets, packages, and service context before deciding what should stay, stop, or be contained.

Process review is runtime forensics. The objective is not to kill anything that looks unfamiliar. It is to understand what is running, why it started, what it touches, what depends on it, and whether the scenario requires it.

Lesson Snapshot

Core concepts6

Common process states5

Inspection commands12

Main goalEvidence-based process review

Learning objectives

Understand runtime behavior before you terminate it

Explain how Linux processes, PIDs, parent-child relationships, users, executables, and system resources fit together.

Use ps, top, free, uptime, lsof, and /proc data to inspect activity before stopping anything.

Distinguish a process from a service and understand why not every suspicious-looking process is systemd-managed.

Identify evidence that helps classify a process as required, normal, resource-heavy, misconfigured, suspicious, or unknown.

Trace a running process back to its executable, user, parent, package, network sockets, files, and service context.

Terminate or contain a process only when the evidence and scenario justify it, then verify required functionality.

Core idea

A process is a runtime fact, not a verdict

A process name, CPU percentage, or user account can be a useful clue, but no single field proves whether a process is required or malicious. Build the decision from multiple sources.

Investigation risk

Killing first can destroy both function and evidence

A process may support a required application or contain valuable runtime evidence. Preserve the executable path, command line, parent, sockets, files, and logs before destructive containment.

Process fundamentals

Six concepts behind runtime activity

PID

Every running process has a process identifier. PIDs are temporary runtime identifiers and can be reused after a process exits.

PPID

The parent process identifier links a process to the process that created it. Parent-child relationships can help explain how an application or suspicious process started.

User context

Processes run under a user identity. The account affects file access, privilege, environment, and the impact of the process.

Executable

A process executes code from an executable or interpreter. The command shown by ps is useful, but the actual executable path and package origin may provide stronger evidence.

Resources

CPU, memory, open files, sockets, and I/O can reveal performance problems or unusual behavior, but high usage by itself does not prove malicious activity.

Lifecycle

Processes start, run, sleep, stop, become zombies, or exit. Runtime state is evidence about behavior, not a complete security verdict.

Process states

Runtime state gives context, not a conclusion

R

Running or runnable on the CPU.

A process can briefly appear in R during normal execution. High CPU over time matters more than one snapshot.

S

Interruptible sleep, commonly waiting for an event.

This is very common and usually normal.

D

Uninterruptible sleep, often waiting on I/O.

Persistent D state can indicate storage or device problems. Investigate before forcing actions.

T

Stopped or traced.

Could be caused by job control, debugging, or another signal. Context matters.

Z

Zombie process: the process exited but its parent has not collected the exit status.

The zombie itself consumes little memory, but repeated zombies can reveal a parent-process problem.

Inspection first

Build a runtime picture before taking action

ps aux

Show a broad process list with user, PID, CPU, memory, start time, and command information.

ps -eo user,pid,ppid,stat,lstart,cmd --sort=user

Show user, PID, parent PID, process state, start time, and command in a structured format.

ps -ef --forest

Display process relationships in a tree-like format.

pstree -ap 2>/dev/null

Show parent-child process relationships with PIDs and arguments when pstree is installed.

top

Interactively inspect CPU, memory, load, and running processes.

uptime

Show how long the system has been running and recent load averages.

free -h

Show memory and swap usage in human-readable form.

sudo lsof -p PID

Show files and sockets opened by one process when lsof is installed.

readlink -f /proc/PID/exe

Resolve the executable associated with a running process.

tr '\0' ' ' < /proc/PID/cmdline

Display the process command line directly from /proc.

cat /proc/PID/status

Inspect process status information such as UIDs, GIDs, memory, state, and capabilities-related fields.

ss -tulpn

Correlate listening network sockets with processes where permissions allow.

Evidence map

Ask a different question of each data source

Who owns the process?

ps / /proc/PID/status

User and group context can show whether the process runs as root, a service account, or a normal user.

What started it?

PPID, ps --forest, pstree

Parent relationships can connect a process to systemd, a shell, cron, a script, an application, or another process.

What code is running?

/proc/PID/exe

Resolving the executable helps distinguish the actual binary from a misleading command name.

What arguments were used?

/proc/PID/cmdline

Arguments can reveal configuration paths, network targets, file locations, or application mode.

What files are open?

lsof

Open files can reveal configuration, logs, data, working directories, deleted-but-open files, and sockets.

What network activity is exposed?

ss / lsof

Listening ports and established connections can connect a process to a required or unexpected network function.

What package owns the executable?

dpkg -S

Package ownership can help determine whether the executable belongs to an installed package or was placed manually.

Is it tied to a service?

systemctl status / systemctl show

systemd context can reveal restart behavior, service user, unit configuration, and logs.

/proc

Runtime evidence directly from the kernel

/proc/PID/exe

Symbolic link to the process executable.

/proc/PID/cmdline

Raw command-line arguments separated by null characters.

/proc/PID/environ

Process environment variables. May contain sensitive data, so inspect only when authorized and necessary.

/proc/PID/cwd

Symbolic link to the current working directory.

/proc/PID/fd/

Open file descriptors including files, pipes, sockets, and devices.

/proc/PID/status

Human-readable runtime status including identity and memory information.

/proc/PID/maps

Memory mappings showing loaded libraries and mapped files.

Evidence

Purpose, package, user, parent, executable, or scenario relationship is not yet clear.

Weak response

Ignore it because the file is already gone.

Better reasoning

Preserve evidence. A process can continue running from an executable that has been deleted or replaced on disk, which can be important for forensics or update troubleshooting.

Resource review

Performance data helps explain process behavior

CPU

topps aux --sort=-%cpu | head

Is one process consuming sustained CPU, and is that usage expected for its workload?

Memory

free -hps aux --sort=-%mem | head

Is memory pressure real, and which processes are using the most memory?

Load

uptime

Are load averages elevated relative to the system's CPU count and current workload?

Open files

sudo lsof -p PID

What configuration, data, logs, devices, or sockets does the process currently use?

Network

ss -tulpn

Does the process listen on or connect through network ports that match the scenario?

Storage / I/O

df -hdu -sh /relevant/path

Could low disk space or rapidly growing files be causing the process or service problem?

One snapshot is not a trend

CPU and memory usage change quickly. A process that spikes during startup or backup activity may be normal. Look for sustained, unexplained behavior and correlate it with logs and workload.

Process evidence

Preserve runtime context before containment

Process list

ps -eo user,pid,ppid,stat,lstart,cmd

Shows runtime identity, parentage, state, start time, and command line.

Executable path

readlink -f /proc/PID/exe

Shows the executable backing the process when accessible.

Command line

tr '\0' ' ' < /proc/PID/cmdline

Shows process arguments that can reveal configuration and runtime behavior.

Open files

sudo lsof -p PID

Shows files, sockets, pipes, and deleted-but-open objects used by the process.

Service logs

journalctl -u service-name

Provides service-specific events when systemd manages the process.

Package ownership

dpkg -S /path/to/executable

Shows whether an executable belongs to an installed Debian package.

Controlled process actions

Use the least destructive control that solves the problem

Ask a process to terminate normally

sudo kill PID

Default SIGTERM allows the process to clean up. Use only after confirming the process should stop.

Terminate by service

sudo systemctl stop service-name

Prefer service-level control when systemd manages the required lifecycle and you understand dependencies.

Force-kill as a last resort

sudo kill -KILL PID

SIGKILL prevents cleanup and cannot be handled by the process. Use only when justified and after evidence is preserved.

Pause a process

sudo kill -STOP PID

Temporarily suspends execution but can freeze dependent workflows. Use only for controlled investigation.

Resume a stopped process

sudo kill -CONT PID

Use when you intentionally suspended the process and are ready to restore execution.

Lower CPU scheduling priority

sudo renice 10 -p PID

Changes scheduling priority rather than solving the root cause. Appropriate only for a known legitimate workload.

High-risk shortcuts

Process-response mistakes that can destroy evidence or function

kill -9 every unfamiliar process

Can terminate required applications, corrupt in-progress work, destroy runtime evidence, and trigger automatic restart mechanisms.

Trusting only the process name

Names can be generic, truncated, changed, or deliberately misleading. Resolve the executable and package origin.

Treating high CPU as malicious

Legitimate updates, backups, scans, builds, compression, and indexing can create high resource use.

Ignoring parent-child relationships

You may kill a child repeatedly while the parent, service, cron job, or persistence mechanism immediately recreates it.

Deleting an executable before collecting evidence

Removes file metadata and can make it harder to understand the running process or answer forensic questions.

Stopping network-facing processes without scenario review

Can remove required SSH, web, DNS, database, or application functionality.

Verification

Prove the runtime state after containment or troubleshooting

Process state

Re-run ps or pstree and confirm the intended process is running, stopped, or gone.

Parent / persistence

Confirm the process does not immediately respawn from a service, timer, cron job, shell, or other parent mechanism unless that behavior is expected.

Resource usage

Review CPU, memory, and load again to confirm the resource issue changed as expected.

Network exposure

Re-run ss -tulpn and confirm required ports remain available while unnecessary exposure is reduced.

Required function

Test SSH, web, backup, desktop, or other scenario-required functions that may depend on the affected process.

Evidence

Confirm command lines, executable metadata, logs, process relationships, and other useful evidence were preserved before destructive action.

Defensive lab

Investigate a fictional high-resource process

Read the fictional scenario: SSH and an internal web application are required; a scheduled backup job runs nightly; one unknown process named updaterd is consuming CPU and listening on a high port.

Use ps, top, pstree, and /proc to record updaterd's PID, PPID, user, start time, executable path, command line, and resource use.

Use lsof, ss, dpkg -S, and systemctl to determine whether the process is package-managed, service-managed, and network-facing.

Check the parent process and persistence sources before killing anything so you understand how updaterd started.

Classify the backup process as Required, the web and SSH processes as Required, and updaterd as Investigate until package, executable, parent, and log evidence are clear.

If updaterd is confirmed unauthorized in the fictional lab, preserve evidence first and contain it using the least disruptive process or service control.

Verify SSH, the web application, backup scheduling, system load, network exposure, and logs after remediation.

Lesson checklist

Before moving on

I can explain PID, PPID, process user, executable, and process state.

I know a process is not the same thing as a service.

I can use ps, pstree, top, uptime, free, lsof, ss, and /proc to investigate runtime activity.

I resolve the executable path instead of trusting the displayed process name alone.

I check parent-child relationships before killing a process.

I investigate package ownership and service context when possible.

I do not classify high CPU or root ownership as malicious by itself.

I preserve process evidence before destructive containment.

I prefer graceful termination or service-level control before SIGKILL when appropriate.

I verify required functionality, network exposure, and resource state after changes.

Reflection

Check your reasoning

Question 1

Why can a process name be misleading during investigation?

Question 2

Why is the parent process important when a process keeps returning after termination?

Question 3

What evidence would you collect before killing an unfamiliar root-owned process?

Question 4

Why does high CPU use not prove malicious activity?

Question 5

When is systemctl stop better than kill PID?

Question 6

What should you verify after terminating a network-facing process?

Carry this forward

Process review is about identity, parentage, executable origin, resource use, sockets, files, and scenario role. Preserve evidence, choose the least destructive response, and verify the system still performs its required functions.

Back to Linux CyberPatriot Hub

← Previous Lesson Next Lesson →