🎯 Goal

Stop treating Linux commands like trivia and start building a baseline understanding of running processes.

Focus areas:

  • observing what “normal” processes look like on my Ubuntu VM
  • interpreting ps and top output
  • identifying system services vs unknown processes
  • capturing investigation-relevant metadata such as PID, user, CPU usage, memory usage, and command line.

Understanding normal system activity is the foundation for detecting suspicious behavior during investigations.

🛠️ What I Did

I began by examining running processes on my Ubuntu VM (Parallels environment).

Inspecting process lists

First commands used:

ps aux | head

This displayed the beginning of the process list.

To identify active processes, I sorted by CPU usage:

ps aux --sort=-%cpu | head -15

This quickly reveals which processes are currently consuming the most CPU.

Observing live system activity

Next I used:

top

This tool provides a live view of system activity including:

  • CPU usage
  • memory consumption
  • running processes
  • system load averages

This helped visualize how processes change in real time.

Identifying common system processes

Several processes appeared consistently:

  • systemd
  • gnome-shell
  • gnome-terminal-server
  • dbus-daemon
  • polkitd
  • cupsd
  • avahi-daemon
  • Parallels integration services (prlcc, prldnd)

Understanding these baseline services is important before labeling anything suspicious.

Understanding PID 1

The first process on the system is typically:

systemd

It runs as PID 1 and is responsible for starting and managing system services.

Most background services are launched either directly or indirectly by systemd.

Inspecting kernel threads

Some entries appear in brackets:

[kworker/...]

These are kernel threads, which perform background kernel tasks.

They are normal and not user processes.

Inspecting specific processes

To investigate individual processes in more detail:

ps -p <PID> -o pid,ppid,user,%cpu,%mem,stat,time,command

This reveals important investigation fields:

  • PID (process ID)
  • PPID (parent process)
  • user account
  • CPU and memory usage
  • command path

These details form the basis of process investigation during security analysis.

🔐 Key Cybersecurity Connections

Process baselining

Security analysts first need to understand normal system behavior.

Without a baseline, everything looks suspicious.

Important investigation questions include:

  • What processes normally run on this host?
  • Which users execute them?
  • What parent process launched them?

Parent-child relationships

The PPID field shows which process launched another.

Unexpected parent-child relationships can indicate suspicious activity.

Example concept:

browser → shell → download tool

Such chains may represent malicious behavior depending on context.

Resource anomalies

Processes consuming unusual CPU or memory resources can signal:

  • misconfigured software
  • runaway processes
  • cryptocurrency miners
  • malicious programs

Sorting processes by resource usage is a fast way to locate anomalies.

⚠️ Challenges

Initially the process list looked chaotic because many services were unfamiliar.

Another confusion was assuming that:

ps aux | head

would display the most important processes.

In reality it simply shows the first entries of the list, which are often kernel or system processes.

Sorting by CPU or memory provides more meaningful results.

🧠 What I Learned

Key takeaways from this session:

  • PID 1 (systemd) manages system services
  • bracketed entries in ps are kernel threads
  • sorting process output reveals useful patterns
  • many unfamiliar processes are normal background services

Process inspection becomes much easier once a baseline of normal behavior is established.

⏭️ Next Steps

Next steps to strengthen process investigation skills:

  • sort processes by memory usage
ps aux --sort=-%mem | head -15
  • inspect several processes using detailed metadata
ps -p <PID> -o pid,ppid,user,%cpu,%mem,stat,time,command
  • investigate log files to understand how process activity is recorded.

Key logs to explore:

/var/log/syslog
/var/log/auth.log

💭 Reflection

This was the first time I approached processes as investigation objects rather than random system activity.

Sorting processes and observing real behavior made the system feel far more understandable.

Instead of memorizing process names, the goal is now to recognize patterns of normal behavior.

🧩 Lessons Learned

What worked

  • sorting processes by CPU usage
  • observing real-time system behavior with top
  • inspecting individual process metadata

What broke

  • assuming the first lines of ps output represent the most important processes

Why it broke

  • the default process list is not sorted by activity

Fix / takeaway

Always sort process output based on the metric that matters (CPU, memory, or time).