PANIX is a modular bash framework that simulates more than thirty Linux persistence mechanisms so detection engineers and authorized penetration testers can build and validate defensive coverage.
| Tool | Aegrah/PANIX — modular Linux persistence framework for security research and detection engineering |
| Category | Offensive security simulation framework (bash/Shell) |
| Primary Use | Emulating persistence techniques such as systemd services, cron, LD_PRELOAD, and PAM backdoors in labs to author detections for them |
| Safe Use | Strictly for authorized penetration tests, CTF environments, isolated lab VMs, and defensive research; every mechanism ships with a paired revert_*.sh script for clean removal |
| Telemetry Note | Because PANIX manipulates well-documented artifacts (/etc/passwd, /etc/sudoers, systemd units, udev rules, SSH authorized_keys), defenders can detect its footprint through file integrity monitoring, auditd rules, and EDR telemetry on privilege-relevant paths |
PANIX, subtitled Persistence Against *NIX, is a bash-based framework from Aegrah that operationalizes an unusually broad catalog of Linux persistence mechanisms behind a single command-line interface. The README is explicit about the intended audience: security researchers, detection engineers, penetration testers, and CTF enthusiasts. That framing matters, because the tool's real value is not the ability to plant persistence — most of these techniques are decades old and documented elsewhere — but the ability to reproduce them consistently and reversibly, which is exactly what detection engineering workflows need when building and validating coverage.
The feature table in the README is the heart of the project, listing over thirty mechanisms with a matrix showing which work with root privileges versus an unprivileged user. The user-level set is instructive on its own: at jobs, authorized_keys, cron, Git hook and pager persistence, bind and reverse shells built on LOLBins, shell profile modification, systemd user services, web shells, and XDG autostart entries. These are the techniques that survive without root, and the ones blue teams most often overlook because they live in user-writable locations that traditional hardening does not touch.
The root-level catalog goes considerably deeper into the operating system's boot and authentication stack. PANIX can backdoor /etc/passwd directly, create a UID=0 user, plant SysVinit scripts in /etc/init.d, hook /etc/rc.local, and reach into pre-OS territory with GRUB and initramfs persistence. There is kernel-level coverage via an LKM backdoor and the well-known Diamorphine rootkit, plus subtler privilege plays: SUID bits on binaries, Linux capabilities, sudoers manipulation, and an overly permissive Polkit configuration that allows pkexec as any user. Even package managers are treated as a persistence surface, with mechanisms abusing APT, YUM, DNF, and forged DPKG/RPM packages.
What elevates PANIX above a loose script collection is its architecture, which the repository structure section documents clearly. main.sh holds the core argument parsing, modules/ contains a setup_*.sh for each mechanism, and modules/revert/ holds a matching revert_*.sh for every one of them. This paired setup-and-revert design is the framework's most important property for legitimate use: a detection engineer can plant a technique, capture the telemetry it generates, and then cleanly undo it without reimaging the lab box. common.sh provides shared functions and help-menu registration, while build.sh concatenates everything into the distributable panix.sh artifact.
That build pipeline also makes the project genuinely extensible, and the README spells out the contribution recipe: drop a new setup_*.sh into modules/, add its revert_*.sh counterpart, wire both into main.sh and common.sh, then run build.sh to regenerate panix.sh. For teams maintaining internal detection libraries, this means a novel persistence variant observed in the wild can be turned into a reproducible test case and contributed back upstream — a feedback loop between threat research and detection validation that few open-source projects formalize this cleanly.
Distribution support is documented honestly, with tested versions called out rather than glossed over. Debian 11 and 12 and Ubuntu 22.04 are the reference platforms, with the caveat that Diamorphine is unavailable on Ubuntu. RHEL 9 and both CentOS Stream 9 and 7 are supported but lack MOTD and pre-OS boot techniques, which tracks with how those distributions handle motd scripts and bootloader configuration. Fedora, Arch Linux, and OpenSUSE are marked as supported but not fully tested, and the README warns that custom or outdated distributions may need the --custom flag, which most features expose to override default paths and commands.
Installation is a single self-contained script shipped from the releases page, currently panix-v2.1.0. The straightforward path is to fetch panix.sh with curl -sL from the GitHub release URL, chmod +x it, and run ./panix.sh. Running it without arguments prints an ASCII banner and a help menu that switches based on privilege: an unprivileged user sees only user-level options, while sudo ./panix.sh surfaces the full root catalog, from --at and --authorized-keys through --ld-preload, --lkm, --rootkit, --systemd, and --udev. This privilege-aware menu is a small but thoughtful touch for lab work where you deliberately want to test the unprivileged attack surface.
From a defensive perspective, PANIX is best understood as a coverage-mapping instrument. Nearly every mechanism it implements leaves a concrete, monitorable artifact: new entries in /etc/passwd or /etc/sudoers, modified SSH authorized_keys, unexpected systemd unit files, udev rules, NetworkManager dispatcher scripts, XDG autostart desktop files, or LD_PRELOAD variables pointing at unusual shared libraries. A purple-team exercise built around PANIX is effectively a checklist for verifying that file integrity monitoring, auditd rules, and EDR sensors actually fire on privilege-relevant paths — and the revert scripts make it practical to iterate repeatedly against the same host.
The more exotic modules highlight detection gaps worth probing deliberately. Diamorphine and the generic LKM backdoor test kernel-module loading telemetry; GRUB and initramfs persistence test pre-OS monitoring, which most endpoints simply do not have; the malicious-container module, which deploys a Docker container designed for host escape, stresses container runtime visibility; and PAM persistence via a rogue module or pam_exec tests whether authentication-stack changes are alerted on. These are the categories where detection engineering tends to be weakest, and having a controlled way to demonstrate that weakness to stakeholders is the tool's core professional use case.
It is worth being clear-eyed about the dual-use nature of what PANIX packages. A framework that consolidates backdoor users, rootkits, web shells, and reverse shells into one menu could shorten an intruder's post-exploitation work considerably if run against systems the operator does not own. The project's MIT license and research-oriented framing do not change that. The appropriate posture is to treat PANIX like any adversary-emulation toolkit: run it only in isolated lab VMs, snapshot before executing, and always use the paired revert scripts or restore from snapshot afterward rather than assuming a clean rollback on shared infrastructure.
With 887 stars and an active release cadence, PANIX has clearly found a niche with both red and blue practitioners, and the breadth of its module catalog — spanning user land, system services, the boot chain, the kernel, and the container layer — makes it one of the more complete persistence references available in Shell. For detection engineers it doubles as living documentation: reading each setup_*.sh in modules/ teaches the exact file paths, permissions, and syntax a technique requires, which is often the fastest route to writing a precise, low-noise detection for it.
Aegrah/PANIX.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.