Detecting PamDOORa and PAM-Layer Backdoors on Linux: What Your EDR Isn't Telling You

Your IR Team's Credentials Were Stolen the Moment They Logged In

Picture a standard engagement. A Linux server shows signs of compromise — maybe unusual outbound connections, maybe a tip from threat intel. Your incident response team SSHs in, starts pulling logs, runs their usual triage. What they don't know is that the moment they authenticated, their passwords were intercepted, XOR-encrypted with a runtime key, and written to a file in /tmp with a randomized filename. Their login was silently erased from lastlog, utmp, wtmp, and btmp. By the time they finish their investigation, the attacker has fresh credentials to every account that touched that box — including theirs.

This is PamDOORa. A PAM-based post-exploitation backdoor that went up for sale on the Rehub Russian cybercrime forum in early May 2026, initially listed at $1,600 before the seller "darkworm" dropped it to $900. Flare.io's Assaf Morag published the first detailed technical analysis on May 7th, and it reveals a tool built specifically to exploit a blind spot that most security stacks simply don't cover: the Linux Pluggable Authentication Module layer.

PamDOORa is the second PAM-targeting backdoor disclosed in the past year, following Nextron's research on the Plague backdoor. That's no longer a coincidence. It's a pattern. And it demands a shift in how defenders think about Linux authentication monitoring.

How PamDOORa Operates Inside the Authentication Stack

PamDOORa requires root access to deploy — this is a post-exploitation tool, not an initial access vector. Once an attacker has root, installation involves injecting a malicious PAM module that compiles to a shared object file named pam_linux.so. That name is deliberate. It sits alongside legitimate PAM modules in the authentication chain and blends in on casual inspection. It does not replace an existing module; it adds itself.

The module is loaded into /etc/pam.d/sshd and hooks into the authentication flow using pam_exec.so to trigger scripts during SSH login events. When any user authenticates — successfully or not — PamDOORa intercepts the credentials before higher-level applications process them. The captured username, password, timestamp, and PAM environment variables (PAM_USER, PAM_RHOST, PAM_SERVICE) are XOR-encrypted with a runtime-generated key and written to /tmp under randomized filenames with manipulated timestamps. XOR isn't strong cryptography, but that's not the point. It defeats naive content inspection and automated string-matching scanners looking for plaintext password files.

Persistence works through a "magic password" mechanism paired with a specific TCP port. The attacker authenticates to SSH using a static secret password that bypasses normal PAM validation. If both the password and port match, access is granted regardless of the actual account credentials. Plague, the earlier PAM backdoor, used a similar approach — researchers extracted hardcoded passwords like Mvi4Odm6tld7 and IpV57KNK32Ih from samples.

The anti-forensic layer is where PamDOORa gets serious. It directly manipulates four authentication log files: lastlog, btmp, utmp, and wtmp. After the attacker's session is established, their entries are surgically removed from these files. Failed login attempts from legitimate users are preserved — and may actually be injected — so that an analyst reviewing auth logs sees exactly what they'd expect to see on a noisy internet-facing server: a list of failed brute-force attempts and nothing else. The successful attacker sessions simply don't exist in the record.

Why Standard Detection Approaches Fail

This is the operational problem. Most Linux endpoint detection — whether you're running CrowdStrike Falcon, SentinelOne, or an open-source stack built on osquery and Wazuh — focuses on user-space process behavior. Suspicious process trees, unusual network connections, known-bad binaries. PAM modules don't trigger those detections because they aren't standalone processes. They're shared objects loaded by sshd itself, running within the trusted authentication daemon's process context.

Application-level logging won't help either. PAM handles credential material before the application layer sees it. If you're relying on journalctl -u sshd or parsed auth.log entries to detect unauthorized access, you're reading logs that PamDOORa has already manipulated. The attacker's sessions have been removed. What remains looks completely normal.

YARA rules targeting known PamDOORa hashes will catch exact samples, and CYFIRMA published IOCs including MD5 b9500f72e9ad39d9efc0b5152e2807e0. But the source code is for sale. Buyers will recompile with modified strings, different XOR keys, and new module names. Signature-based detection has a shelf life measured in weeks here.

The deeper issue is that PAM is a trusted subsystem. Security tools don't typically instrument it with the same scrutiny applied to, say, a web server process spawning a shell. This trust assumption is exactly what PamDOORa exploits (T1556.003 — Modify Authentication Process: Pluggable Authentication Modules).

Building Detection Around What PamDOORa Can't Hide

PamDOORa can manipulate auth logs and avoid process-level detection, but it can't install itself without modifying files on disk. That's the anchor point for detection.

File integrity monitoring on PAM directories. This is non-negotiable for any Linux server exposed to SSH. Monitor /etc/pam.d/ and the PAM module directories (/lib/x86_64-linux-gnu/security/, /lib64/security/, or wherever your distro stores them) with AIDE, Tripwire, or your EDR's FIM capability. Any new .so file appearing in the PAM module directory, or any modification to /etc/pam.d/sshd, should generate a high-severity alert. PamDOORa drops pam_linux.so — a name that looks plausible but isn't part of any standard distribution.

Here's an auditd rule set that covers the critical file paths:

# Monitor PAM configuration changes
-w /etc/pam.d/ -p wa -k pam_config_change
-w /etc/pam.d/sshd -p wa -k pam_sshd_change

# Monitor PAM module directories for new or modified shared objects
-w /lib/x86_64-linux-gnu/security/ -p wa -k pam_module_change
-w /lib64/security/ -p wa -k pam_module_change

# Monitor pam_exec script execution
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/sh -F key=pam_exec_script
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/bash -F key=pam_exec_script

Baseline your PAM modules. On a clean system, run ls -la against your PAM module directory and hash every .so file. Store that baseline. Any module that appears post-deployment and doesn't match a known package update is suspect. This is simple, unglamorous work — and it's the single most reliable detection for PAM-layer persistence.

Watch for XOR-encrypted temp files. PamDOORa writes credential data to /tmp with randomized filenames. On most production servers, the contents of /tmp are predictable enough that anomalous files — especially small binary or encoded files with manipulated timestamps — should trigger investigation. An auditd rule watching for file creation in /tmp by the sshd process (or child processes of sshd) narrows this further:

-a always,exit -F arch=b64 -S openat -S creat -F dir=/tmp -F success=1 -F auid!=4294967295 -k tmp_file_creation

Validate auth log integrity externally. If your detection relies on the logs stored on the host, PamDOORa wins. Ship utmp, wtmp, btmp, and lastlog data off-box in real time. Better yet, use a centralized auth logging pipeline where the host's local logs are treated as supplementary, not authoritative. Compare: if your SIEM shows an SSH session from an IP but the host's wtmp has no corresponding entry, that delta is a high-confidence indicator of log tampering.

eBPF: The Detection Layer PAM Backdoors Didn't Anticipate

The most promising detection approach for PAM-layer attacks comes from eBPF-based runtime monitoring. Tools like Falco, Tetragon (Cilium), and Spyderbat instrument the kernel directly, observing system calls and process behavior below the level where PAM backdoors operate. This matters because PamDOORa can manipulate lastlog and wtmp, but it can't prevent the kernel from seeing the open() and write() syscalls that perform the manipulation.

With Tetragon, you can write a TracingPolicy that fires when sshd (or any child of sshd) opens lastlog, btmp, utmp, or wtmp with write permissions. Legitimate sshd behavior writes to these files during normal authentication. But PamDOORa's pattern is distinct: it writes to these files and to a file in /tmp within the same authentication event. That combination — auth log write plus temp file creation by the same process lineage — is not normal.

A Falco rule targeting this looks something like:

- rule: PAM Module Suspicious File Write
  desc: Detect sshd writing to both auth logs and tmp directory in same session
  condition: >
    spawned_process and
    proc.pname = "sshd" and
    (fd.name startswith "/tmp/" or fd.name = "/var/log/lastlog") and
    evt.type in (open, openat) and
    evt.arg.flags contains O_WRONLY
  output: >
    Suspicious file write by sshd child process
    (user=%user.name command=%proc.cmdline file=%fd.name parent=%proc.pname)
  priority: WARNING

This isn't a production-ready rule — you'll need to tune for your environment's auth patterns and acceptable pam_exec usage. But it illustrates the detection philosophy: monitor the kernel-level behavior that PAM backdoors cannot suppress.

Incident Response When PAM Is Compromised

If you suspect a PAM backdoor on a host, your standard IR playbook needs modification. The biggest operational risk is credential exposure: every analyst who authenticates to the compromised system via SSH has their credentials captured. That's not theoretical. It's the designed behavior of PamDOORa.

Response teams should access suspected hosts through out-of-band management interfaces (IPMI/iLO/iDRAC console access) or by mounting the filesystem from a live boot environment rather than authenticating over SSH. If SSH access is unavoidable, use key-based authentication only — PAM backdoors that hook password authentication won't capture SSH keys (though more sophisticated variants could log key paths or agent forwarding sessions, so don't treat this as bulletproof).

Once on the system, immediate triage should include checking PAM configuration integrity against known-good baselines, hashing all modules in the PAM directory against package manager records (dpkg -V on Debian/Ubuntu, rpm -Va on RHEL/CentOS), examining /tmp for recently created small binary files, and reviewing whether lastlog entries show gaps that don't match SIEM records for that host.

Any credentials that were used to authenticate to the compromised host during the suspected compromise window should be treated as burned. Rotate them. All of them. This includes service accounts that may authenticate via SSH for automated tasks — those passwords are captured just as readily as interactive logins.

The Bigger Pattern: PAM as an Emerging Attack Surface

PamDOORa isn't an isolated data point. Plague appeared last year with three-layer string obfuscation, anti-debugging, and credential harvesting through the same PAM mechanism. Before that, PAM-based persistence appeared in nation-state operations — notably in the Ebury malware family targeting Linux servers at scale. The pattern is clear: attackers have identified PAM as a high-value, low-visibility persistence point that sits in a monitoring blind spot for most organizations.

The Linux security model treats PAM modules as trusted code. There's no code-signing enforcement. There's no integrity verification at load time. Any shared object placed in the right directory and referenced in the right configuration file will be loaded by sshd without question. Until distributions implement module signing or mandatory integrity checks at the PAM layer, this attack surface stays wide open.

For teams running Linux infrastructure — and that's nearly everyone with a cloud presence — the minimum viable defense is file integrity monitoring on PAM directories, off-host log shipping, and kernel-level runtime visibility. If you're relying on auth logs stored on the host itself to tell you whether someone broke in, PamDOORa has already shown you how that story ends.