raj3shp/persisthunt

persisthunt is a single bash script for defenders, system administrators, and incident responders who need to quickly check a Linux machine for signs of a hidden intruder. The README explains that attackers who manage to break into a Linux box usually want to stay there even after a reboot, and they do that by hiding small launch hooks in places like cron jobs, systemd services, shell profiles, or boot scripts. The script walks through all those places in one pass and prints what it finds. The usage is simple. The user runs sudo persisthunt.sh > output.log on the suspected host, or pipes the script over SSH if the host cannot be touched directly. Each finding is tagged with a confidence label of High, Low, or Informational, so the analyst can scan straight for the loudest hits first. The author notes that the output can be long and is well suited to being summarized by a language model or AI agent after the fact. The High confidence checks cover the techniques most often used by real Linux malware. They include unusual at jobs, cron entries that mention curl, wget, netcat, or paths like /tmp and /dev/shm, active bind shells where an interpreter is listening on a network port, active reverse shells where a process has its stdin and stdout redirected to a socket, eBPF programs with raw network sockets (a sign of the BPFdoor rootkit family), suspicious systemd service or timer files, edited rc.local and profile files, hidden ELF binaries in /tmp and /home, world writable SUID or SGID binaries, processes hidden from ps, bind mount tricks over /proc, and a populated /etc/ld.so.preload. The Low confidence checks look at softer signals such as files with POSIX capabilities, recently created executables, git hooks, APT hooks, Yum or DNF plugins, Python .pth files, udev rules with RUN keys, PAM modules calling pam_exec, and recent edits to system binaries in /bin or /usr/bin. The Informational section is for manual review and dumps cron files, shell profiles, SSH authorized_keys, local users, mounts, running services, network connections, and container state. The author also describes the script as a flexible starting point that teams can edit with their own keywords and rules.