[elJefeDonBiazzi]

We've all been there. We compromised a system, and now we need to keep persistence in order to keep on moving in the network, while knowing we will have access to the system when we need it. Here are my 10 favorite ways to achieve persistence on Linux machines:





These were my favorites, if u have more ways, let me know!
It was my pleasure.

Ill let you know what i think after i read it.

alright so i read thru the original list of linux persistance methods, it’s solid overall and covers the basics pretty well. def a good writeup for ppl learning red team stuff or messing in lab boxes. but heres some feedback + better methods that work well on actual server targets (not desktops)

• good mix of techniques, covers cron, rc.local, ssh keys, sudoers, etc
  
• works fine for CTFs and basic internal tests
  
• all methods are manual and easy to test
  

but there’s some stuff missing or that could be better:

1. some of the methods are kinda outdated, like rc.local, a lot of newer distros don’t even use it anymore unless u manually re-enable. not reliable by default on modern ubuntu or debian
   
2. no stealth consideration, all the methods are loud af. things like crontab with * * * * * or adding users w/ sudo rights will get spotted fast if any monitoring is in place
   
3. some methods are GUI/desktop focused, like .bashrc and anything involving XDG or .desktop stuff. that won’t run at all on most production servers, since theres no graphical user session
   
4. no event-triggered persistence, everything runs at boot or login. nothing that waits for a file change, or specific system event like config file edits or new package installs
   
5. no fallback or multi-layer setup, if defender removes your cron or user, access is gone. good attackers will setup layered persistance that replaces itself or rotates methods if one is killed
   

these ones work better on actual linux servers, especially if u got root or sudo

1. systemd path-based units
you can run ur payload only when a file changes (like sshd_config). way quieter than normal services

2. /etc/profile.d/ scripts
runs for every user on login, not just 1 user like .bashrc. great for shared systems

3. fake binaries in $PATH
drop a fake ssh or sudo binary in /usr/local/bin and wrap ur payload around the real cmd. works when ur PATH is writable

4. LD_PRELOAD via /etc/ld.so.preload
load ur .so file into every process. advanced but powerful. just don’t break anything

5. apt/yum/dpkg hook scripts
drop payloads into update scripts or post-install hooks. gets triggered during package installs

6. wrap legit binaries (like sshd)
replace with a script that runs ur backdoor, then runs the real binary after

7. PAM module backdoors
modify pam_unix.so or add a rule in /etc/pam.d/sshd that lets u login with a special password. stealthy af

8. packet-based triggers (iptables or nfqueue)
set up a script that runs only when a special packet is received. no cron, no open ports

9. socat/ncat listener on boot
binds a hidden shell on localhost or high port. easy way to maintain access

10. ssh authorized_keys w/ forced command
don’t just drop the key. use command="payload.sh" in the key to auto-run code when u login

• cron - use @reboot or drop in /etc/cron.d/ with weird times like 37 3 * * 2 so it doesn’t look obvious
  
• systemd - use Type=oneshot or PathChanged=, and name it like dbus-watcher.service to blend in
  
• ssh keys - hide in root/.ssh/, or add to lesser known users (like system accounts)
  
• rc.local - symlink ur shell to /usr/bin/kmod-check or something boring
  
• suid - don’t make new suid binaries. use cp or bash in a weird folder with +s bit set
  

• touch ur files with timestamps from legit binaries -
  touch -r /bin/bash your_file.sh
• stash stuff in /dev/shm/, /run/lock/, or /var/lib/dpkg/, these don’t always get scanned
  
• encrypt ur payloads w/ gpg or openssl so they look like garbage unless u decrypt on boot
  
• rotate methods - have cron reinstall systemd unit if it’s deleted, etc
  
• name things boring - udev-helper, modprobe-check, system-sync sounds clean
  

ur original list is good for entry level red teamers or people in training labs, but on real engagements or hardened boxes, a lot of that stuff gets flagged quick. u need better stealth, fallback plans, and awareness of modern linux setups (esp systemd vs init)

Nice man, you defiantly added to the post.
You right, my list is for beginners and it is quite "loud" as you call it.

[Wazz313]

Thank you for sharing!

[Raiden_Shogun]

This is quite useful for me.

This forum account is currently banned. Ban Length: (Permanent)
Ban Reason: Impersonating @Anastasia

[k4mui]

Thanks sir, I want to see persistence techniques