Malicious systemd Services

A Debian-first guide to identifying unexpected services, tracing their execution paths, and removing service-based persistence safely.

What this is

systemd services control what runs automatically on a Debian system. Attackers can abuse service units to create persistence, relaunch malware at boot, or hide execution behind service-like names that blend in with normal operations.

A malicious or unauthorized service may appear legitimate at first glance, especially if it uses a vague name or runs from an unusual path.

What it looks like

An unfamiliar service enabled at boot
A service executing from /tmp, user directories, or custom hidden paths
A vague or deceptive service name
A service whose purpose nobody can explain

Detect

List running services

sudo systemctl list-units --type=service --state=running

List enabled unit files

sudo systemctl list-unit-files --type=service | grep enabled

Inspect a suspicious service

sudo systemctl status <service_name>
sudo systemctl cat <service_name>

Search service files for unusual execution paths

sudo grep -R "ExecStart" /etc/systemd /lib/systemd 2>/dev/null

Review recent service-related journal activity

sudo journalctl --since "24 hours ago"

Contain

Stop the suspicious service

sudo systemctl stop <service_name>

Disable it from starting automatically

sudo systemctl disable <service_name>

Mask it if needed

sudo systemctl mask <service_name>

Masking prevents the unit from being started normally while you investigate further.

Recover

Inspect the referenced executable or script

file /path/to/binary
sha256sum /path/to/binary
strings /path/to/binary | less

Remove the service file if confirmed malicious

sudo rm /etc/systemd/system/<service_name>
sudo systemctl daemon-reload

Check for related persistence elsewhere

sudo find /etc/cron* -type f
sudo find /tmp /var/tmp /dev/shm -type f 2>/dev/null
cut -d: -f1 /etc/passwd

If a service was added maliciously, review who created it, what it launched, and whether it was paired with other persistence mechanisms.

Prevent

Option 1 — Review enabled services regularly

sudo systemctl list-unit-files --type=service | grep enabled

Option 2 — Watch for services running from unusual paths

sudo grep -R "ExecStart" /etc/systemd /lib/systemd 2>/dev/null

Option 3 — Reduce unnecessary software and services

sudo systemctl list-units --type=service --state=running
sudo apt list --installed

Option 4 — Restrict remote admin exposure

sudo ufw allow from <trusted_ip> to any port 22
sudo ufw deny 22

Option 5 — Review logs after updates or suspicious events

sudo journalctl --since "24 hours ago"

Optional Tools & Hosting

Manual service review should come first. Future recommendations may include options that improve visibility into service changes or host behavior, but the core workflow remains Debian-first and transparent.

Notes

systemd services are powerful because they survive reboots and look normal in system administration contexts.
The most suspicious service units usually reveal themselves through odd names or odd execution paths.
Stopping a service is containment; understanding its origin is recovery.

Environment Note

All commands shown are based on Debian-based systems unless otherwise noted. Unit file locations may vary depending on how the service was installed.