PamDOORa Steals SSH Credentials on Linux by Hiding Inside PAM Where No Antivirus Looks

A backdoor called PamDOORa targets Linux systems through PAM and steals SSH credentials from every user who logs in. It leaves no trace in process lists, antivirus, or logs. When the security team connects via SSH to investigate, their credentials get stolen too.

When someone logs into a Linux server, the system runs PAM to check the password. PAM stands for Pluggable Authentication Modules, and it handles authentication for everything that requires a login: SSH, sudo, the login prompt. Instead of building that check into each program separately, Linux sends everything through PAM using configuration files stored in /etc/pam.d/, one file per service. The file for SSH is /etc/pam.d/sshd. It tells PAM which modules to run, in what order, and what to do when one fails.

One of those modules is called pam_exec. It runs an external script when someone logs in, used for things like triggering an alert when a password changes or writing a compliance log entry. A pam_exec line in /etc/pam.d/sshd looks completely normal.

Attackers add the exact same kind of line, with one difference. The control flag is set to “optional.” That tells PAM to keep going no matter what the script does. The login works as usual. The script runs silently in the background. Even when a login attempt fails, the script still executes. Group-IB’s DFIR team documented this technique in September 2024 and noted that it had not been added to the MITRE ATT&CK framework yet. MITRE ATT&CK is the reference list most security teams use to build detection rules. If a technique is not on that list, most tools are not specifically watching for it.

PamDOORa goes further than a script. It is a post-exploitation tool, meaning the attacker needs root access on the system first. This is what happens after they are already in and want to stay invisible while collecting credentials. Instead of running a script, PamDOORa drops its own module directly into the PAM stack. Security researcher Assaf Morag analyzed PamDOORa in May 2026 and found that it installs a file called pam_linux.so. Linux systems have dozens of real PAM modules with names that look exactly like that. The file lands in /lib/x86_64-linux-gnu/security/ next to the legitimate ones.

Once installed, PamDOORa does two things at the same time. It opens a permanent back door through a combination of a secret password and a specific TCP port, accepting connections from the attacker without going through normal authentication. At the same time it intercepts the credentials of every user who logs in. That capture happens inside PAM itself, before any log file or monitoring tool sees anything. The stolen passwords get encrypted using XOR, a method where each byte is scrambled against a key generated fresh at runtime, and exfiltrated via netcat to an attacker-controlled server, written under a random filename in /tmp.

Linux keeps four files that track who logged in and when. The lastlog file records the last login time per account. The wtmp and utmp files track session data. The btmp file logs failed attempts. PamDOORa modifies all four after the attacker connects, removing every record that they were there. What remains are the failed login attempts from automated scanners, the noise that shows up on every internet-facing server.

A security team gets called in to investigate. They connect via SSH to look around. If PamDOORa is still running, their credentials get captured the moment they log in. Their session disappears from the logs. The investigators become part of the breach.

PamDOORa is not the first backdoor built for the PAM stack. In August 2025, researchers at Nextron Systems found a backdoor called Plague that had been running since at least July 2024. They found multiple samples on VirusTotal, all uploaded over that year. Zero out of sixty-six antivirus engines had flagged any of them. PAM modules load into the authentication process as shared libraries. They do not start new processes and look identical to real system files. Before signatures exist for a specific variant, standard antivirus has no reliable way to detect them.

Plague disguised itself as a SELinux library named libselinux.so.8, used three layers of encryption to hide its internal strings, and gave attackers persistent SSH access through hardcoded static passwords. Nextron extracted the actual passwords from the samples: Mvi4Odm6tld7, IpV57KNK32Ih, and changeme. If any of those work over SSH on a system, it is compromised. After Nextron published their findings, more than thirty antivirus engines added signatures for Plague. For the full year before that, every sample came back clean.

When Nextron worked through the encryption layers, they found this line sitting in the code:

“Uh. Mr. The Plague, sir? I think we have a hacker.”

That is where the name came from.

PamDOORa turned up on Rehub, a Russian-speaking cybercrime forum that filled the gap after several bigger platforms got taken down in 2025 and 2026. It is a low-barrier marketplace, and that shows. Scams are common, vendors are unreliable, and claims are often inflated. The seller behind PamDOORa, going by the alias “darkworm,” stood out from the noise. The code snippets in the listing were technically solid and matched known PAM exploitation methods. The price started at $1,600 on March 17, 2026, and dropped to $900 by April 9. Nearly fifty percent in three weeks. On a serious forum that would already be a red flag. On Rehub it tells you something. The analysis was based on the advertisement and screenshots, not the actual source code, so what it really does could differ from what was claimed.

None of the techniques inside PamDOORa are new. Hooking into PAM, capturing credentials, manipulating logs: all documented before. What PamDOORa does is bundle everything into one tool with anti-debugging, network-aware triggers, and a build pipeline. That puts it closer to professional attack tooling than the proof-of-concept scripts found in public repositories.

This technique did not start on a forum. Mandiant has tracked advanced threat clusters using PAM-based backdoors primarily on Solaris and Linux systems for years, long before anyone put it up for sale.

PAM does not store passwords. When someone logs in, PAM passes the password between its modules to verify it. At that point it moves in plaintext. That is not a bug, that is how PAM was designed to work. PamDOORa sits at exactly that point. Before anything else can see it, log it, or encrypt it, the credential is already captured.

Start by checking the SSH PAM configuration file:

1

cat /etc/pam.d/sshd

Look for any pam_exec lines pointing to scripts in /tmp, /var, or anywhere outside a standard system directory. Any line that was not intentionally added is worth following up.

Then check which PAM modules are installed:

1

ls -la /lib/x86_64-linux-gnu/security/

On Red Hat-based systems the path is /lib64/security/. Sort by modification date. A file newer than everything else that did not come from a package update needs a closer look.

If this file exists, it is a direct indicator of PamDOORa:

1

find / -name "pam_linux.so" 2>/dev/null

Compare the installed PAM module hashes against what the package manager has on record:

1
2

sha256sum /lib/x86_64-linux-gnu/security/*.so
dpkg --verify libpam-modules

On Red Hat-based systems:

1

rpm -Va | grep pam

Check the authentication logs for anything off. A log file that stopped growing when it should not have, or one with a modification time that does not match its content, is worth investigating:

1
2

last -f /var/log/wtmp
lastb -f /var/log/btmp

If a system is suspected of having a PAM backdoor, do not connect via SSH to investigate. Every connection hands the attacker another set of credentials. Use a console or out-of-band management interface, one that does not route through PAM.

The most direct fix is switching SSH to key-based authentication and turning off password logins entirely. If no password ever gets typed, PamDOORa has nothing to steal. Key-based authentication skips PAM’s auth phase completely because the login never involves a password moving through the module chain. Set the following in /etc/ssh/sshd_config:

1
2

PasswordAuthentication no
PubkeyAuthentication yes

Then restart SSH:

1

systemctl restart sshd

Nextron Systems published YARA rules for hunting PAM implants, and their THOR Lite scanner includes updated signatures for Plague. File integrity monitoring on /lib/security/ and /etc/pam.d/ with an alert on any change catches this before credentials are gone.

Auditd adds another layer. With DISA-STIG recommended rules enabled, Auditd watches for modifications to files like /etc/pam.d/sshd and flags changes that normal monitoring would miss. SELinux and AppArmor both restrict what a PAM module is allowed to do at the process level, making it harder for a rogue module to write files to arbitrary locations like /tmp.

If you want to understand how attackers get in, stay in, and cover their tracks on Linux systems, my ethical hacking course covers exactly that. Privilege escalation, Linux persistence, credential harvesting, how each technique works and how to recognize it:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: PamDOORa: A New Linux PAM-Based Backdoor, Flare.io · The Duality of the Pluggable Authentication Module, Group-IB · Plague: A Newly Discovered PAM-Based Backdoor for Linux, Nextron Systems