Process and Service Management

Everything Running Is a Process

Every program that runs on Linux is a process with a PID (process ID), an owner and a parent. A service (or daemon) is a process that runs in the background, such as a web server or SSH. When you investigate a suspected compromise, one of your first questions is: what is running, who started it and why?

Looking at Processes: ps

ps            # your own processes in this terminal
ps aux        # every process, with owner, CPU and memory
ps -ef        # a similar view showing parent PIDs

Sample output:

USER       PID %CPU %MEM COMMAND
root         1  0.0  0.4 /sbin/init
root       588  0.0  0.6 /usr/sbin/sshd -D
www-data   731  0.2  1.9 /usr/sbin/apache2 -k start
kali      1342  0.0  0.1 nc -lvnp 4444

Red flags to look for:

• A shell or netcat (nc, bash -i) running as a service user. Netcat listening on a port is a classic backdoor.
• Processes running from odd places such as /tmp or a hidden folder.
• A process with a name that imitates a system one, like sshd spelled slightly differently.
• Unexpected high CPU, which can mean crypto-mining malware.

Other handy tools: top and htop (live view) and pstree (the parent and child tree).

Stopping Processes: kill

kill 1342           # ask politely (SIGTERM, signal 15)
kill -9 1342        # force it (SIGKILL). Use only if needed
killall nc          # kill by name

Killing a malicious process is only containment. The attacker probably has a way to start it again, so you must find out how it started. Also, in an incident, capture evidence first (what it was doing, its command line and open connections) before you destroy it.

Managing Services: systemctl

Modern Linux uses systemd. Use systemctl to control services:

systemctl status ssh          # is it running?
sudo systemctl stop apache2   # stop it now
sudo systemctl disable telnet # do not start at boot
systemctl list-units --type=service

Hardening rule: disable every service you do not need. Fewer running services means less attack surface.

Cron Jobs: Scheduled Tasks

cron runs commands on a schedule. A crontab line has five time fields and a command:

# m  h  dom mon dow   command
0    2  *   *   *     /usr/local/bin/backup.sh     # every day at 02:00
*/5  *  *   *   *     /tmp/.update.sh              # every 5 minutes

Cron is a favourite persistence technique. An attacker who gets in once adds a cron job so their access returns after a reboot or after you kill their process. Check with:

crontab -l                 # your jobs
sudo crontab -l -u root    # root's jobs
ls /etc/cron.d /etc/cron.daily

The second line above should worry you: a hidden file in /tmp running every five minutes.

A Real-World Scenario

A Lagos e-commerce site notices that its server is slow. An engineer runs ps aux and finds an unknown process using 95% CPU, started from /tmp. They kill it and it returns within five minutes. Checking crontab -l reveals a job that downloads and re-runs the miner. The same pattern appears in cloud incidents worldwide. The fix: remove the cron job, delete the file, find the entry point (often an outdated plugin), patch it and rotate credentials.

Try It in the Lab: Process Hunt

The web server has been slow all night and the CPU is pinned at 98%. Something is mining cryptocurrency on this box, disguised as a kernel worker. In the simulated terminal on the right, processes and services really change when you act on them:

1. ps aux (or top): find the process eating the CPU. Note its PID and owner.
2. ps -ef (or pstree): use the PPID column to find the process that started it.
3. systemctl status sys-update: confirm which service runs that parent, and read its restart policy.
4. Stop the service so it cannot respawn the miner. You will need sudo.
5. Kill the miner with kill -9. Kill it before stopping the watchdog and see what happens.

Bonus: disable the service so it does not come back after a reboot. While you are there, look at nc -lvnp 4444 running under www-data and at crontab -l. In a real incident those are findings too.

Write up what you found as if for a report: what, where, evidence, and recommended action.