processes

Overview

A running program on Linux is a process. In CTFs you constantly need to see what is running, find a specific service, understand what a suspicious program is doing, or stop something you started. This lesson covers how Linux manages processes and the everyday commands to list, inspect, and control them during authorized, isolated practice.

Learning objectives

• Explain what a process is, including its PID and parent.
• List running processes with ps and monitor them live with top.
• Find a specific process and read its details.
• Send signals to control processes with kill, and manage foreground/background jobs.

Core concept

A process is an instance of a running program. Every process has a unique PID (process ID) — a number the kernel uses to track it. Each process also has a parent (the process that started it), identified by its PPID, forming a tree that traces all the way back to the first process started at boot. Processes have an owner (the user they run as), which determines their permissions, and a state such as running or sleeping.

Because a process runs as a particular user, it inherits that user's rights. This is why who a process runs as matters so much: a program running as a privileged user can do far more than the same program running as an ordinary one.

How it works

The essential commands:

• ps lists processes. On its own it shows only your current shell's processes. ps aux is the common form that lists all processes with user, PID, CPU and memory use, and the command line.
• top (or htop where installed) shows a live, continuously updating view of processes sorted by resource usage. Press q to quit.
• pgrep <name> finds the PIDs of processes matching a name; pidof <name> is similar.
• kill <PID> sends a signal to a process. By default it asks the process to terminate gracefully (SIGTERM, signal 15). kill -9 <PID> sends SIGKILL, which forces immediate termination and cannot be caught.
• Job control in a shell: append & to run a command in the background; jobs lists background jobs; fg brings one to the foreground; and Ctrl+Z suspends the foreground job.

A signal is a small message the kernel delivers to a process. Common ones include SIGTERM (please stop), SIGKILL (stop now, unblockable), and SIGINT (the interrupt you send with Ctrl+C).

Practical example

A challenge tells you a local service is "already running — talk to it." You need its PID and the port or arguments it was launched with:

$ ps aux | grep flag_service
player   2317  0.0  0.1  12044  3320 pts/0  S  10:02  0:00 /opt/flag_service --port 9001
player   2402  0.0  0.0   6440   896 pts/0  S+ 10:03  0:00 grep flag_service

$ pgrep -a flag_service
2317 /opt/flag_service --port 9001

The listing reveals the service is process 2317, running on port 9001 — exactly the detail the challenge wanted you to discover. If you had earlier started a stuck helper of your own and needed to stop it, you would find its PID and end it:

$ kill 2402        # ask it to stop
$ kill -9 2402     # force it if it ignores the request

Notice the second line in the first listing is the grep command itself catching its own name — a normal quirk you learn to ignore.

Cybersecurity relevance

Process inspection is central to both attack and defense. During incident response, an analyst lists processes to spot malware, a suspicious listener, or a program running as the wrong user. In privilege-escalation challenges, the key insight is often a process running as a privileged account that you can influence. Knowing ps aux, how to find a process by name, and how to read its owner and command line lets you understand what a machine is actually doing. Signals and job control let you manage tools you launch, so your own activity stays under control in a shared lab.

Common mistakes

• Reaching for kill -9 first; a graceful SIGTERM lets a process clean up, so try it before forcing.
• Killing the wrong PID, including the grep line that matches your search rather than the real process.
• Forgetting a job is running in the background after using &, then being confused by its output.
• Ignoring the process owner — the same command means very different things running as an ordinary user versus a privileged one.

Key takeaways

• A process is a running program with a unique PID, a parent (PPID), an owner, and a state.
• ps aux lists all processes; top/htop give a live view; pgrep finds a process by name.
• kill <PID> sends SIGTERM to stop gracefully; kill -9 forces termination and cannot be caught.
• &, jobs, fg, and Ctrl+Z manage foreground and background jobs; the owner of a process defines its rights.

Check your understanding

• What is the difference between sending SIGTERM and SIGKILL to a process, and which should you try first?
• Why does the process owner matter when you are looking for a privilege-escalation path?
• When you run ps aux | grep sshd, why does an extra line for grep itself often appear, and how do you avoid acting on it?