SIMULATION You are about to enter the virtual environment. DO NOT perform the following actions within the virtual environment. Making any of these changes will cause the virtual environment to fail…

Explanation: Identifying and Remediating a Malicious TCP Service + Systemd Persistence --- Overall Goal An attacker exploited a vulnerability, gained access, and left two artifacts behind even after the vulnerability was patched: 1. A malicious TCP listener - a backdoor or…

Submitted by mike_84· Mar 6, 2026Security Operations

Question

SIMULATION You are about to enter the virtual environment. DO NOT perform the following actions within the virtual environment. Making any of these changes will cause the virtual environment to fail and prevent proper scoring. 1. Disable ssh 2. Disable systemd 3. Alter the network adapter 172.162.0.0 4. Change the password on the lab admin account 5. Reboot the machine Once you have completed the item in the virtual environment, you will NOT be allowed to return to this item. TEST QUESTION This system was recently patched following the exploitation of a vulnerability by an attacker to enable data exfiltration. Despite the vulnerability being patched, it is likely that a malicious TCP service is still running and the adversary has achieved persistence by creating a systemd service. Examples of commands to use: kill, killall lsof man, --help (use for assistance) netstat (useful flags: a, n, g, u) ps (useful flag: a) systemctl (to control systemd) Please note: the list of commands shown above is not exhaustive. All native commands are available. INSTRUCTIONS Using the following credentials: - Username: labadmin - Password: Passw0rd! Investigate to identify indicators of compromise and then remediate them. You will need to make at least two changes: 1. End the compromised process that is using a malicious TCP service. 2. Remove the malicious persistence agent by disabling the service's ability to start on boot. Answer: STEP 1: Identify and Kill the Malicious TCP Process 1. List listening TCP services with associated processes: sudo netstat -tulnp Look for suspicious services (e.g., uncommon ports like 4444, 1337, etc.) 2. Verify the process details: ps aux | grep <PID> 3. Terminate the suspicious process: sudo kill <PID> Or use sudo killall <process-name> if needed. STEP 2: Disable the Malicious systemd Service (Persistence) 1. List all systemd services: systemctl list-units --type=service 2. Look for any unusual or suspicious service (often not part of a typical system, e.g., revshell.service, malicious.service, backdoor.service, etc.) 3. Check the service path and content (optional but helpful): systemctl status <suspicious-service> cat /etc/systemd/system/<suspicious-service>.service 4. Disable the malicious service: sudo systemctl disable <suspicious-service> 5. Stop the service (if still running): sudo systemctl stop <suspicious-service> Once these steps are done, you will have: - Ended the malicious process. - Disabled its persistence via systemd. Avoid: Disabling SSH or systemd, changing passwords, rebooting, or touching the 172.162.0.0 network adapter.

Explanation

Explanation: Identifying and Remediating a Malicious TCP Service + Systemd Persistence

Overall Goal

An attacker exploited a vulnerability, gained access, and left two artifacts behind even after the vulnerability was patched:

A malicious TCP listener - a backdoor or reverse shell process still running in memory
A systemd service - persistence so the backdoor restarts automatically on reboot

Patching the vulnerability only closes the door of entry. It does not evict the attacker who is already inside. You must manually find and remove both artifacts. The order matters: find first, then kill, then disable persistence.

Step 1: Identify and Kill the Malicious TCP Process

Step 1.1 - sudo netstat -tulnp

This lists all TCP and UDP sockets that are listening, shows numeric addresses (no DNS resolution), and includes the process name/PID owning each socket.

Why necessary: You cannot kill what you cannot find. Netstat gives you the map from port -> PID. Attackers often use ports like 4444, 1337, 9001, or other non-standard ports that have no legitimate reason to be listening.

What to look for: Any entry under LISTEN on a port that isn't expected (SSH=22, HTTP=80/443, etc.). The last column shows PID/process-name.

If skipped: You'd have no way to identify which process to kill without blind guessing.

Step 1.2 - ps aux | grep <PID>

Cross-references the PID from netstat against the full process list to see the command line that launched it.

Why necessary: The process name in netstat may be truncated or obfuscated (e.g., bash, python3, sshd2). The full command line from ps reveals the actual script or binary path, confirming it's malicious.

If skipped: You risk killing a legitimate system process with a similar name, or missing confirmation that you have the right target.

Step 1.3 - sudo kill <PID> or sudo killall <name>

Terminates the running process, severing the attacker's active connection and stopping the malicious listener.

Why necessary: The process is actively running and potentially exfiltrating data or awaiting commands. It must be stopped immediately.

If done before Step 1.1: You don't know what to kill. If skipped entirely: The attacker remains connected. Even if you disable the service (Step 2), the current session stays alive.

Step 2: Disable the Malicious systemd Service (Persistence)

Step 2.1 - systemctl list-units --type=service

Lists all currently loaded systemd services.

Why necessary: Killing the process (Step 1) only stops it this session. The systemd service will restart it on next boot or even automatically via Restart=always in the unit file. You must find the service definition to neutralize it permanently.

What to look for: Service names that don't match standard Linux services - things like update-helper.service, sysmonitor.service, or anything that sounds vague or generic.

Step 2.2 - systemctl status <suspicious-service> / cat /etc/systemd/system/<name>.service

Inspects the service unit file to confirm it's malicious and see what binary it runs.

Why necessary: Confirms you have the right service before disabling it. The ExecStart= line in the unit file will show the exact command (e.g., ExecStart=/tmp/backdoor or ExecStart=/bin/bash -i >& /dev/tcp/...).

If skipped: You might disable a legitimate service by mistake, potentially breaking the system.

Step 2.3 - sudo systemctl disable <suspicious-service>

Removes the service's symlink from the boot targets, preventing it from starting on reboot.

Why necessary: This is the core remediation for persistence. disable does not stop a currently running instance - it only prevents future auto-starts.

If done without Step 1.3: The service is still running right now. If skipped: The malware comes back after every reboot.

Step 2.4 - sudo systemctl stop <suspicious-service>

Stops the service if it's still running (e.g., if it relaunched itself after you killed the PID).

Why necessary: disable only affects boot behavior. If the service respawned after the kill in Step 1, stop terminates it via systemd's own process management.

Order note: stop before or after disable both work, but disable first ensures it won't restart if stop triggers a restart policy.

What Goes Wrong If Steps Are Out of Order

Mistake	Consequence
Kill process before finding it	Nothing to target; guesswork
Disable service but skip kill	Attacker's current session stays live
Kill process but skip disable	Malware returns on reboot
Skip `ps` verification	Risk killing wrong process

Memory Tip

Think "Find, Verify, Kill, Audit, Disable, Stop" - or the acronym FVKADS:

Find the port (netstat) -> Verify the process (ps) -> Kill it -> Audit the service list -> Disable the persistence -> Stop any remnant

A simpler mental model: treat it like evicting a squatter. First you find them (netstat), confirm their identity (ps), remove them now (kill), then change the locks so they can't get back in (disable + stop the service).

Topics

#Incident Response#Linux Security#Systemd#Network Monitoring

Community Discussion

No community discussion yet for this question.

Full CAS-005 Practice