Useful evidence
- ps for process visibility.
- ss for sockets and connections.
- systemctl for service state.
- journalctl for system logs.
- File ownership and permissions for relevant binaries.
RR CYBERLAB • Linux Security
Linux Processes & Services
Use basic Linux process and service telemetry to support security troubleshooting and investigations.
QUICK READ
Processes represent running programs; services provide long-running or managed functionality. Commands such as ps, ss, systemctl and journalctl help analysts build a host-level picture.
Use this page after the daily quiz: learn the concept first, then follow the investigation workflow and examples.
Investigation workflow
- Identify unusual processes.
- Check the executable path and user.
- Inspect network connections.
- Check parent process where available.
- Review service configuration and logs.
- Compare against the host’s expected role.
Example
A server that normally runs a web service suddenly has a new process making repeated external connections. Validate the binary, service context, deployment history and network destination before concluding compromise.Common mistakes
- Killing a process before collecting evidence.
- Ignoring service ownership.
- Assuming an unfamiliar process name is malicious without checking the binary and host role.
Daily quiz hook
Which Linux evidence helps connect a running process to network activity: process list alone, or process plus socket information?
Quiz flow: introduce this topic briefly on social media, ask the question, reveal the answer, then send learners here for the detailed investigation.
Analyst practice note
A process snapshot is most useful when it includes parent process, executable path, user, start time, arguments, and network or file behavior. Service names can be imitated, and short-lived processes may be missed by snapshots, making event telemetry and persistence checks valuable complements.
Compare the simulated process tree with the expected service owner and parent. Treat unusual names as a lead; verify the executable location, package or deployment history, and related events before calling it malicious.
Continue practicing: open a fictional mission and test your reasoning against the simulated evidence.