Grab a fresh cup of coffee, settle into your terminal, and let’s get back to work. Now we are diving into Process and Services Management.
In our last session, we cracked open the world of Package Management. Now that you know how to bring software into your machine, it is time to understand how that software actually runs, breathes, and sometimes hides. Today, we are diving deep into Process and Services Management.
For a hacker or a cybersecurity analyst, understanding this isn’t just a nice-to-have skill. It is absolutely vital. If you can’t control your processes, you can’t control your system. And if you can’t find hidden services, well… khel khatam (game over).
The Daemons Among Us
Let’s start with services. In the Linux world, services are often called “daemons” (pronounced dee-mons, though some prefer day-mons). These are fundamental components of your operating system that run silently in the background, completely without direct user interaction.
Think of a bustling restaurant. You, sitting at the table, are the user interacting with the menu (your terminal). The waiters are your foreground applications. But the daemons? They are the kitchen staff, the dishwashers, and the managers working behind closed doors. You don’t see them, but if they stop working, the whole place falls apart.
Generally, services fall into two broad categories:
- System Services: These keep the OS breathing. Things like network managers, SSH servers, and logging utilities.
- User-Installed Services: These are things you (or someone else) bring to the party, like a custom database, a web server, or… something malicious.
Which brings us to a rather sticky scenario.
The Case of the Malicious Service
Imagine this: You’re doing a routine check on your machine, or maybe you are conducting incident response on a compromised server. You notice some strange network activity. A cheeky hacker has sneaked in and installed a malicious service for persistence. They want to ensure that even if you reboot the server, their backdoor starts right back up automatically.
Let’s say the hacker named their backdoor tu-to-gaya.service (which roughly translates to “you’re finished” in Hindi). We need to find it, see what it does, and understand how it operates.
To do this, we use the systemctl command. This is your master control switch for systemd, the system and service manager for most modern Linux distributions.
Install the Malicious Script for Practice
Below is the script that install’s ‘tu-to-gaya.service’ on your device. I want you to copy the code below and save it in a bash script then execute it on your Linux machine. ( Learn how to run scripts by yourself 😊 )
#!/bin/bash
SERVICE_NAME="tu-to-gaya.service"
SCRIPT_PATH="/usr/local/bin/tu-to-gaya.sh"
SERVICE_FILE="/etc/systemd/system/$SERVICE_NAME"
echo "[+] Deploying tu-to-gaya node..."
sleep 1
echo "[+] Creating runtime script at $SCRIPT_PATH"
cat << 'EOF' > $SCRIPT_PATH
#!/bin/bash
while true
do
echo "tu-to-gaya signal active..."
sleep 5
done
EOF
chmod +x $SCRIPT_PATH
echo "[+] Creating systemd service at $SERVICE_FILE"
cat << EOF > $SERVICE_FILE
[Unit]
Description=Bohot bhayankar vala hack
After=network.target
[Service]
Type=simple
ExecStart=$SCRIPT_PATH
StandardOutput=journal
StandardError=journal
Restart=always
[Install]
WantedBy=multi-user.target
EOF
echo "[+] Reloading systemd"
systemctl daemon-reload
echo "[+] Enabling tu-to-gaya"
systemctl enable $SERVICE_NAME
echo "[+] Starting tu-to-gaya"
systemctl start $SERVICE_NAME
echo "[+] tu-to-gaya Status:"
systemctl status $SERVICE_NAME --no-pagerNow Analyze the Malicious script
If you ran the script above on your machine correctly, the malicious service must be running on your machine. Now the only thing left is to open the thing apart and see what it is doing 😂.
Let’s list all the active services running right now:
systemctl list-units -t serviceRun that, and you’ll see a massive list of everything currently loaded and active. But hackers are sneaky. What if the service isn’t actively running right this second? What if it only triggers under certain conditions, or what if it failed to start? We need to see everything.
By adding the -a (all) flag, we force systemctl to show us every service it knows about, whether it is running, stopped, or failed:
systemctl list-units -t service -aAh! Scrolling through that output, there it is. The rogue tu-to-gaya.service is sitting in our system. But what exactly is it doing? A service is ultimately just a configuration file telling Linux what script or binary to execute. We can read that configuration file directly without having to hunt down where it lives on the hard drive.
systemctl cat tu-to-gaya.serviceThis command prints out the contents of the service file. In the output, you would typically look for the ExecStart= line. That tells you the exact path of the malicious script the hacker is trying to run (maybe something nasty like /usr/local/bin/reverse_shell.sh).
When Daemons Crash: Reading the Journals
Here is a fun fact about hackers: they make mistakes. Sometimes their custom malware is buggy, or it conflicts with a system library. What if tu-to-gaya.service tried to execute but crashed?
To figure out what went wrong (or just to spy on what the service has been logging), we use a tool called journalctl.
Systemd collects logs from all its services in a central journal. If you just type journalctl by itself, you will get slammed with every single log entry your system has generated since it booted. It is a bit like drinking from a firehose.
To filter the noise and look only at the logs for our hacker’s service, we use the -u (unit) flag:
journalctl -u tu-to-gaya.serviceThis is pure gold for a cybersecurity analyst. You might see error messages revealing the hacker’s IP address, missing dependencies they forgot to install, or clues about what data they were trying to steal before the script failed. A little jugaad (clever hacking) on your part to read their error logs can completely expose their operation.
Want to learn how to create services in Linux: CLICK HERE
Moving on to Processes
So, services are the configuration and management of background tasks. But what about the tasks themselves? Once a program is actually running in memory and taking up CPU cycles, it is called a Process.
If you open a terminal and run a Python script, that’s a process. If you launch Firefox, that’s a process. Understanding processes is how you gain immediate, real-time control over your machine.
To get a snapshot of what is running right now, we use the ps (process status) command.
If you just type ps, it only shows processes running in your current terminal session, which isn’t very helpful if we are hunting for hidden malware. To see everything running on the system, across all users, we use a very common combination of flags:
ps auxLet’s break that down because it’s a command you will use daily:
- a: Shows processes for all users.
- u: Displays the user/owner of the process and memory/CPU usage.
- x: Shows processes that aren’t attached to a terminal (like our silent daemons).
When you run ps aux, you get a massive table. You’ll see the User, the PID (Process ID – a unique number assigned to every running task), CPU usage, and the actual command that was executed.
Pro tip not in the video: You rarely just run ps aux alone. You usually pipe it into grep to search for specific things. For example, ps aux | grep bash will show you all running bash shells.
Bringing the Hammer Down: Killing Processes
Let’s say you spotted the PID of the hacker’s reverse shell script from your ps aux output, and it is actively running. It has a PID of 4092. It is time to stop it dead in its tracks. ( remember the PID can be different when you run the command )
We do this using the kill command.
kill 4092By default, the kill command sends a polite “SIGTERM” (Signal Terminate) message to the process. It basically says, “Excuse me mate, would you mind wrapping up what you’re doing, saving your data, and shutting down?”
Most polite applications will listen to this. Malware usually won’t. If the process ignores your polite request, you have to bring out the big guns. You send a “SIGKILL” signal, which bypasses the program entirely and tells the Linux kernel to instantly execute the process. No saving, no cleanup, just immediate termination. You do this by adding the -9 flag.
kill -9 4092Boom. Gone. The hacker’s process is dead.
The Art of the Juggle: Foreground and Background
Let’s shift gears slightly. As a hacker, you are often running multiple tools at once. Let’s say you are running a massive nmap scan against a target network. It’s going to take 20 minutes.
You run the command, and… your terminal is stuck. The nmap process is running in the foreground, meaning it has taken hostage of your command line until it finishes. But you need to type other commands right now!
You could open a new terminal tab. Or, you could learn how to juggle your jobs.
While your long-running command is hogging the terminal, simply press:
Ctrl + z
This is magic. It doesn’t kill the process; it suspends it. It hits the pause button. Your terminal prompt will instantly return, and Linux will give you a little message saying something like [1]+ Stopped nmap...
Now you have your terminal back, but your scan is paused. To tell Linux to keep running that scan, but to do it invisibly in the background, you use the bg command:
bgNow your nmap scan is happily chugging along behind the scenes, and you are free to type whatever commands you want.
If you do this a few times with different tools, you might lose track of what you pushed into the background. To see a list of all your current background tasks, use:
jobsThis will output a numbered list of your background tasks.
[1]- Running nmap ...
[2]+ Running netcat ...If you ever want to bring one of those tasks back to the foreground so you can interact with it directly again, use the fg (foreground) command, followed by the job number:
fg 1And just like that, your nmap scan is back on your screen. Mastering Ctrl+z, bg, jobs, and fg makes you look and feel like an absolute wizard on the command line. It is a massive productivity boost.
Wrapping Up and Looking Ahead
We’ve covered a lot of ground today. You’ve learned how to identify the silent daemons running your system (and how to spot the bad ones), how to read their logs, how to view active processes, how to ruthlessly terminate them, and how to juggle multiple heavy tasks in a single terminal window.
These aren’t just parlor tricks. Whether you are attacking a box and trying to hide your tracks, or defending a server and hunting for anomalies, process and service management is your bread and butter.
But what if you don’t want to run a task right now? What if you want to tell the system, “Hey, I need you to run this specific backup script, or this specific malware payload, every Tuesday at 3:00 AM”?
Well, my friend, that requires scheduling. And that is exactly what we are going to tackle in our next article and video: Task Scheduling. We will be exploring Services and Timers in more depth, and diving into the legendary cronjob and crontab utilities.
Until then, keep practicing. Run ps aux, see what your computer is actually doing, and I’ll see you in the next one.
Frequently Asked Questions (FAQs)
Q: What is the main difference between a process and a service?
A: A process is simply any executing program currently loaded into memory (like a web browser or a script you just ran). A service (or daemon) is a specific type of background process managed by the system, designed to run continuously without user interaction, often starting automatically when the computer boots.
Q: Why does kill -9 work when a regular kill command fails?
A: A standard kill sends a SIGTERM signal, asking the program to shut itself down gracefully. If a program is frozen or maliciously programmed to ignore signals, it won’t work. kill -9 sends a SIGKILL signal directly to the Linux kernel, forcing the operating system to forcefully terminate the program immediately, giving the program no chance to object.
Q: If I put a process in the background using bg, will it keep running if I close my terminal?
A: Usually, no. If you close the terminal window, it sends a hangup signal (SIGHUP) to all jobs attached to that session, terminating them. If you want a process to survive after you close the terminal, you need to use tools like tmux, screen, or prepend your command with nohup (no hangup).
Q: Where are systemctl service files actually located on the filesystem?
A: While systemctl cat is the easiest way to read them, the actual .service files are typically stored in /etc/systemd/system/ (for user-created or modified services) and /lib/systemd/system/ (for default packages installed by the OS).
