PamDOORa – The 00 Linux Backdoor That Turns SSH Against Itself + Video

Listen to this Post

Featured Image

Introduction:

The Pluggable Authentication Modules framework is the bedrock of identity verification on Linux systems, silently mediating every login, every `sudo` command and every SSH handshake. Now, a sophisticated backdoor named PamDOORa is exploiting this very foundation, embedding a malicious module directly into the authentication stack to harvest credentials from all legitimate users while providing attackers with a covert, persistent entry point.

First advertised on the Russian cybercrime forum “Rehub” by a threat actor known as “darkworm,” the tool’s price dropped from $1,600 to $900—a significant discount that suggests either limited buyer interest or an urgent need to offload the malware. This analysis dissects its inner workings, from the abuse of the `pam_exec` module to its anti-forensic log manipulation, and provides security teams with practical commands to detect, harden, and mitigate this emerging threat.

Learning Objectives:

  • Objective 1: Understand how PamDOORa weaponizes the PAM framework to intercept plaintext credentials and grant persistent SSH access via a “magic password.”
  • Objective 2: Learn to detect unauthorized modifications to PAM configurations and binaries using command-line forensics on Linux systems.
  • Objective 3: Implement a multi-layered defense strategy, including file integrity monitoring, configuration hardening, and proactive incident response for SSH environments.

You Should Know:

1. The Anatomy of the Attack: Weaponizing `pam_exec`

The core of the PamDOORa backdoor lies in the abuse of a completely legitimate PAM module: pam_exec. In standard Linux administration, this module allows system operators to trigger external scripts during authentication events, for example, to log every `sudo` attempt. However, a threat actor with root access can insert malicious entries into critical PAM configuration files, such as /etc/pam.d/sshd, forcing the system to execute arbitrary code during every SSH login attempt.

The malicious script runs during the authentication phase, capturing sensitive environment variables like PAM_USER, PAM_RHOST, and `PAM_SERVICE` before the login process completes. This data is then exfiltrated to a remote Command-and-Control (C2) server, often using lightweight tools like `netcat` to bypass standard firewall scrutiny. By marking the malicious module with the “optional” control flag, the attacker ensures that even if the script fails or encounters an error, the normal login process continues uninterrupted, meaning no obvious errors alert the user or administrator.

Step‑by‑step guide explaining what this does and how to use it (Defensive Perspective):

This guide is for security professionals to simulate and understand the mechanism on an isolated test system. Do not use in production.

1. Simulate a Malicious PAM Module (Lab Only):

On a test Linux VM, create a simple script that logs authentication attempts.

sudo nano /usr/local/bin/pam_logger.sh

Add the following content to simulate credential capture:

!/bin/bash
echo "$(date) - User: $PAM_USER, Service: $PAM_SERVICE, Remote: $PAM_RHOST" >> /var/log/pam_test.log
exit 0

Make it executable: `sudo chmod +x /usr/local/bin/pam_logger.sh`

2. Inject the Script into `pam_exec` (Demonstration):

Edit the SSH PAM configuration:

sudo nano /etc/pam.d/sshd

At the end of the authentication section, add:

session optional pam_exec.so /usr/local/bin/pam_logger.sh

3. Observe the Effect:

Initiate an SSH connection to the test machine. Then, check the log:

cat /var/log/pam_test.log

You will see the captured variables. This is precisely how PamDOORa operates, but instead of logging to a file, it would exfiltrate the credentials to a remote C2 server.

4. Cleanup:

Remove the test line from `/etc/pam.d/sshd` and delete the script to restore the system to its original state.

  1. Detecting a Compromised PAM Stack: A Proactive Audit

Because PamDOORa operates within the legitimate PAM framework, traditional antivirus and process-monitoring tools often miss it. Detection requires a focused, forensic examination of the PAM configuration files and module binaries. Administrators should look for unauthorized entries in files like `/etc/pam.d/sshd` and /etc/pam.d/common-auth, particularly those invoking `pam_exec` or referencing suspicious, user-created scripts. Furthermore, the presence of unexpected shared objects (.so files) in /lib/security/—the standard directory for PAM modules—is a red flag.

Step‑by‑step guide explaining what this does and how to use it:

1. Check PAM Configuration Integrity:

Baseline your PAM configurations and compare them against known-good states from your distribution’s documentation. Use `diff` to spot unauthorized changes.

 Backup of known-good configuration
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

After a potential incident, compare
diff /etc/pam.d/sshd /etc/pam.d/sshd.bak

2. Audit for Suspicious `pam_exec` Modules:

Search through all PAM configuration files for any `pam_exec` lines that call non-standard scripts or binaries.

sudo grep -r "pam_exec" /etc/pam.d/

Examine each result. If a `pam_exec` line points to a script in `/tmp/` or a user’s home directory, it is highly suspicious.

3. Verify PAM Module Integrity:

Use `dpkg` (Debian/Ubuntu) or `rpm` (RHEL/CentOS) to verify that all PAM modules are part of an official package and have not been tampered with.

 On Debian/Ubuntu
sudo dpkg --verify libpam-modules
 On RHEL/CentOS
sudo rpm -V pam

Any output from these commands (e.g., S.5....T. c /lib/security/pam_unix.so) indicates a potential compromise.

4. Harden SSH Configuration to Mitigate Backdoors:

To limit the damage even if a backdoor is installed, enforce restrictive SSH policies.

sudo nano /etc/ssh/sshd_config

Set the following directives:

PermitRootLogin no
MaxAuthTries 3
AuthenticationMethods publickey,password

Restart SSH: sudo systemctl restart sshd. This forces two-factor authentication (2FA) and prevents direct root logins.

3. Anti-Forensics: The Silent Log Tampering

One of the most insidious features of PamDOORa is its ability to systematically tamper with authentication logs, erasing any evidence of the attacker’s presence. It targets critical files like `lastlog` (records the last login of each user), `btmp` (records failed login attempts), `utmp` (records currently logged-in users), and `wtmp` (records all login/logout history). By selectively deleting or altering these records, the backdoor undermines standard incident response procedures—an investigator connecting to a compromised server may have their own credentials stolen and their access silently erased from the logs.

Step‑by‑step guide explaining what this does and how to use it:

To protect against and investigate such tampering, implement the following measures:

1. Centralized Logging is Non-Negotiable:

The single most effective defense against log manipulation is to send logs to a remote, write-once, read-many (WORM) storage location. Configure `rsyslog` or `syslog-ng` to forward all auth, authpriv, and `daemon` logs to a dedicated log server.

 On the client, edit /etc/rsyslog.conf
 Add a line to forward all logs to a central server (192.168.1.100)
. @192.168.1.100:514
sudo systemctl restart rsyslog

2. Monitor Log Files with `auditd`:

Use the Linux Audit Daemon (auditd) to watch for any modifications to authentication logs and PAM configuration files. This provides a forensic trail that even root users cannot easily erase without being detected.

 Install auditd (if not present)
sudo apt install auditd  Debian/Ubuntu
sudo yum install audit  RHEL/CentOS

Add a watch on critical files
sudo auditctl -w /etc/pam.d/ -p wa -k PAM_CONFIG_CHANGE
sudo auditctl -w /var/log/auth.log -p wa -k AUTH_LOG_CHANGE
sudo auditctl -w /var/log/wtmp -p wa -k WTMP_CHANGE

View the audit logs
sudo ausearch -k PAM_CONFIG_CHANGE

3. File Integrity Monitoring (FIM) with AIDE:

Deploy the Advanced Intrusion Detection Environment (AIDE) to create a cryptographic baseline of all critical system files, including PAM modules and configurations. Run regular comparisons to detect any unauthorized changes.

 Install AIDE
sudo apt install aide  Debian/Ubuntu
sudo yum install aide  RHEL/CentOS

Initialize the database (run on a known-clean system)
sudo aideinit
 Copy the new database to the working location
sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Run a manual integrity check
sudo aide --check

4. From Post-Exploitation to Persistence: The $900 Threat

PamDOORa is explicitly a post-exploitation tool. This means an attacker must first gain root access on the target system—likely through a separate vulnerability, stolen credential, or misconfigured service. Once inside, they deploy the backdoor, transforming a temporary foothold into a permanent, undetectable backdoor. Its design includes anti-debugging features and a builder pipeline that allows the attacker to compile customized binaries, making static signature detection by security tools largely ineffective. The “magic password” and specific TCP port combination method ensures the attacker can always authenticate, even if the legitimate user passwords are changed, without generating a single failed login attempt in the logs.

Step‑by‑step guide explaining what this does and how to use it (Mitigation):

To defend against this class of threat, focus on preventing initial compromise and deploying advanced detection:

1. Enforce Privileged Access Management (PAM):

Use tools like `sudo` and `polkit` to strictly control who can gain root access. Review the `/etc/sudoers` file and remove any overly permissive rules (e.g., ALL=(ALL:ALL) ALL).

 Safely edit the sudoers file
sudo visudo
 Add a restrictive rule, e.g., allow only specific commands
john ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/journalctl

2. Deploy Runtime Security Monitoring:

Traditional antivirus is ineffective. Use endpoint detection and response (EDR) systems or tools like `osquery` to monitor the `pam_exec` module’s execution across all endpoints. A query to detect `pam_exec` usage would look like:

SELECT  FROM process_events WHERE cmdline LIKE '%pam_exec%';

This should be correlated with known administrative change requests.

3. Linux Kernel Hardening with eBPF:

Advanced security teams can use eBPF (extended Berkeley Packet Filter) to create custom probes that monitor the PAM stack’s interaction with the kernel. For example, a probe can be written to alert any time a process in the authentication flow attempts to open a network socket to an unknown IP address, a key behavior of PamDOORa.

 Use bpftrace to trace suspicious bash commands run via PAM
sudo bpftrace -e 'kprobe:sys_execve { if (strcontains(str(argptr[bash]), "pam")) { printf("PAM execution: %s\n", str(argptr[bash])); } }'

5. System Hardening and Incident Response Checklist

Proactive hardening is the foundation of resilience against complex threats like PamDOORa. In the event of a suspected compromise, a swift, methodical response is critical to contain the breach and prevent lateral movement.

Your incident response plan should include:

  • Isolation: Immediately block inbound and outbound SSH traffic at the network firewall for the compromised host, except from a dedicated, secure jump box.
  • Memory and Disk Capture: Preserve the system’s RAM and a forensic image of the disk for offline analysis. Use tools like `LiME` for memory capture.
  • Credential Reset: Force a reset of all user passwords on the affected system and any interconnected services, as PamDOORa is designed to harvest everything.
  • Re-image: Do not attempt to clean the system; the anti-forensics capabilities of the backdoor make it impossible to guarantee a full recovery. Re-image the server from a known-good template and restore data from backups.
  • Root Cause Analysis: Determine the initial access vector. Was it a stolen SSH key, a vulnerable web application, or an unpatched software vulnerability? Remediate this flaw before reconnecting the system.

What Undercode Say:

  • Key Takeaway 1: The Linux PAM framework, despite its flexibility, represents a high-value target for attackers. The emergence of PamDOORa shows that abusing core system components for stealth and persistence is a rapidly growing trend, moving from proof-of-concept to commercial-grade malware.
  • Key Takeaway 2: Defenders cannot rely on traditional security tools. Proactive audits of PAM configurations, coupled with robust file integrity monitoring and centralized logging, are essential. The most effective defense is to assume logs are compromised and to push all critical events to a dedicated, immutable remote collector.

PamDOORa is a final reminder that in security, trust is a vulnerability. We place immense trust in the PAM framework, and tools like this weaponize that trust against us. The path forward requires a shift from reactive security—waiting for an alert on a suspicious process—to proactive hardening. By aggressively managing root access, continuously validating system integrity, and building detection mechanisms that monitor the behavior of the authentication layer itself, we can turn systemic trust into a series of verifiable, and therefore defensible, statements. The $900 price tag is not just the cost of a tool; it is the price of complacency in Linux environments.
.
.
.

.

This article was researched and written based on the technical analysis published by Flare.io on May 7, 2026, and subsequent reporting by The Hacker News and other cybersecurity outlets.

▶️ Related Video (86% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Hackermohitkumar A – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky