Flare has detailed PamDOORa, a Linux backdoor advertised on a Russian-language cybercrime forum as a PAM-based post-exploitation tool for OpenSSH access. The sales pitch matters because PAM sits in the authentication path for services such as SSH, sudo, and console login: once an attacker has root access long enough to alter that layer, the next problem is not just one stolen password. The compromised host can become a credential collection point and a hidden return door.
According to Flare’s report, PamDOORa is marketed as an x86_64 Linux backdoor that can preserve SSH access through a magic password and a TCP port condition, while also collecting credentials from legitimate users who authenticate through the infected system. That places it in the same practical risk family as Linux malware that hides inside trusted server workflows: Gridinsoft recently covered QLNX RAT, which also showed why Linux developer and server systems are valuable when they expose SSH keys, cloud tokens, and deployment access.
Why PAM Backdoors Are Hard to Clean
PAM is useful because applications can delegate authentication to shared modules instead of each implementing login logic on its own. That same design makes a malicious PAM change dangerous. A backdoored module or altered PAM configuration can sit below the application layer, so changing a user password before the host is trusted again may simply feed the new credential through the same compromised path.
For defenders, the first useful question is not only “which account was used?” but which authentication path handled the login. On Linux servers, that means comparing files such as /etc/pam.d/sshd, distro-specific shared auth files, and PAM module directories under /lib*/security or /usr/lib*/security against known-good packages or golden images. Unexpected .so files, changed module hashes, unusual timestamps, suspicious pam_exec-style calls, or authentication logs with gaps around successful SSH activity all deserve closer review.
The response sequence should treat a confirmed PAM compromise as a host-integrity incident, not a simple account reset. Kernel escalation bugs such as Dirty Frag show why this matters: after initial Linux access, an attacker may be able to move from a limited account to root before defenders rotate credentials. Isolate the server, preserve logs and suspicious modules, reinstall PAM/OpenSSH packages from trusted repositories or rebuild from a clean image, and only then rotate passwords, SSH keys, deployment tokens, and cloud credentials that touched the host. If the machine was a build runner, admin jump box, or shared hosting node, review downstream access as well. Earlier Linux rootkit cases such as Symbiote show the same lesson in a different form: once malware lives below ordinary user-space checks, process lists and password changes are not enough proof that the system is clean.
