PamDOORa: Analyzing a New Linux PAM-Based Backdoor for Sale on the Dark Web

By Assaf Morag, Cybersecurity Researcher

For $1,600, a threat actor on a Russian cybercrime forum is selling the complete source code for a Linux backdoor that embeds itself in one of the most trusted layers of the operating system: the Pluggable Authentication Module (PAM) stack. The tool, called PamDOORa, is a new PAM-based backdoor, designed to serve as a post-exploitation backdoor, enabling authentication to servers via OpenSSH. Allegedly this would remain persistent on Linux systems (x86_64).

As Linux systems continue to dominate enterprise infrastructure and cloud environments, attackers are constantly exploring new post-exploitation tools to maintain persistence on compromised servers.

We analyzed the threat actor’s post, reviewed the shared screenshots and comparable open-source tools, and assessed the tool’s risk and novelty as a post-exploitation capability. 

Key Findings About PamDOORa

• PamDOORa is a PAM-based post-exploitation backdoor for Linux (x86_64) that provides persistent SSH access via a magic password and specific TCP port combination, while simultaneously harvesting credentials from all legitimate users who authenticate through the compromised system. The credential capture occurs within the PAM stack itself, meaning it intercepts passwords before any application-layer logging.
• The tool includes anti-forensic capabilities that manipulate lastlog, btmp, utmp, and wtmp authentication logs to remove traces of attacker access. This directly undermines incident response timelines and means that IR teams connecting to investigate a compromised server may themselves have their credentials captured and their access silently erased from logs.
• The threat actor reduced the asking price by nearly 50% (from $1,600 to $900), suggesting either limited buyer interest or an attempt to accelerate a sale. Our analysis identified five distinct personas using the same alias across multiple forums, but the PamDOORa seller demonstrates notably higher technical credibility than the others, with realistic code snippets and techniques that align with known PAM abuse methods.
• PamDOORa represents an evolution over existing open-source PAM backdoors. While the individual techniques (PAM hooks, credential capture, log tampering) are well-documented, the integration into a cohesive, modular implant with anti-debugging, network-aware triggers, and a builder pipeline places it closer to operator-grade tooling than the crude proof-of-concept scripts found in most public repositories.

Important caveat: this analysis is based on a dark web advertisement and shared screenshots, not full source code review. The tool’s actual capabilities, reliability, and sophistication could differ from what the threat actor claims.

What is Linux PAM?

On Linux systems, Pluggable Authentication Modules (PAM) serve as the central authentication engine that controls how users and services verify identity and gain access. Instead of hardcoding authentication logic into each application, PAM uses a modular, policy-driven approach defined in /etc/pam.d/, where each file governs how a specific service (such as SSH, sudo, or login) handles authentication, authorization, password policies, and session management. 

This design provides flexibility and consistency across the system, but it also makes PAM a highly sensitive security layer: any modification to these configurations can affect all authentication flows, making it a powerful target for attackers seeking persistence, credential harvesting, or stealthy access control bypass.

PAM library

The file /etc/pam.d/sshd defines how SSH authentication is handled. It serves as a policy layer for Pluggable Authentication Modules (PAM), specifying which modules are invoked when a user connects via SSH. Rather than implementing authentication itself, it references pam_*.so modules that perform tasks like password validation, account checks, and session setup. /etc/pam.d/sshd controls the authentication flow, while the underlying .so modules execute it.

How Attackers Abuse PAM

Threat actors typically don’t rewrite the entire configuration. They make small, strategic changes to gain control while staying invisible.

In setups like /etc/pam.d/sshd, the most common approach is to insert or modify a single line so it calls a malicious or abused module. For example, adding a line early in the auth chain (often via common-auth) with a permissive control flag like sufficient can allow a hidden password or bypass to succeed before normal authentication even runs. Because SSHD PAM files often rely on includes (@include common-auth, common-account, etc.), attackers often target those shared files instead -giving them system-wide impact across SSH, sudo, and login through one change.

pam_*.so files on our lab VM

Another common technique is abusing legitimate modules such as pam_exec.so to execute a script during login, enabling credential harvesting or silent command execution without dropping obvious malware. In more advanced cases, attackers may introduce a custom pam_*.so module that blends in with legitimate ones, ensuring persistence that only triggers during authentication events – making it far stealthier than typical cron or systemd backdoors.

What Can We Learn about PamDOORa from a Dark Web Post?

The threat actor is selling a post-exploitation tool with assumed root privileges, thus getting initial access to a server and gaining root privileges is part of the buyer’s responsibilities. The threat actor is offering a tool that will inject PAM configuration and .so file/s that will allow both persistent SSH access to the compromised system and collection of legitimate users’ credentials.

Screenshot shared by the threat actor

Attack Flow: From Foothold to Long-Term Persistence

Based on the shared materials, a likely operational flow for PamDOORa is:

1. The attacker gains root access to a Linux server through a separate exploit or initial access method.
2. PamDOORa is deployed, injecting a malicious PAM module into the authentication stack.
3. The backdoor enables SSH access via a specific TCP port and magic password combination.
4. All legitimate user credentials that pass through PAM are captured, encrypted with XOR, and written to /tmp with dynamically generated filenames and timestamps.
5. Authentication logs (lastlog, btmp, utmp, wtmp) are manipulated to remove traces of the attacker’s access.

PamDOORa attack flow

What’s Revealed from PamDOORa’s Backdoor Access

The threat actor shared various code files in the forum. The Makefile produces pam_linux.so rather than overwriting the standard pam_unix.so, suggesting the implant is designed to be loaded as an additional module via PAM configuration changes rather than by replacing a system file.

The makefile

Controlled Backdoor Access via Network-Aware Triggers

PamDOORa backdoor access is done via a specific TCP port and a magic password. This is declared in the README file and also in the code screenshot as well. 

A routine resembling procFindConnectionSocket enumerates file descriptors under /proc/[pid]/fd, resolves symbolic links, and inspects socket metadata (type, family, protocol). This enables the module to associate an authentication attempt with a particular network connection and apply conditional logic based on its characteristics. This approach is stricter than the typical backdoors, which generally accepts any connection matching a password. 

Socket TCP connection snippet

Credential Harvesting Inside PAM

PamDOORa doesn’t only offer persistence access to the server, but it also captures user credentials during login attempts. The data is collected and encrypted with XOR with a runtime-generated key. The files are written to /tmp with dynamically generated names and timestamps.

While XOR is not intended to provide strong cryptographic protection, it serves as a practical evasion layer against naive content inspection. Because the capture occurs within PAM, the implant can observe credentials presented by legitimate users and administrators without needing to hook higher-level applications.

From a defender’s perspective, it makes the process of incident response (IR) and server cleaning much more difficult. The IR team’s own credentials are compromised the moment they SSH into the affected server to investigate, increasing the attacker’s hold on the machine.

Anti-Forensics: Log Manipulation and Quiet Operation

Another factor that further complicates IR operations is the manipulation of the lastlog file. Based on the observed code snippet, lastlog (and likely other authentication logs such as btmp, utmp, and wtmp) are deliberately altered to remove traces of the attacker’s access. Since these logs are key artifacts examined during IR investigations, tampering with them can significantly distort the forensic timeline and obscure the true sequence of events.

We also observed evidence of selective execution (via PAM_IGNORE) and network-aware triggers. The implant is designed to leave a minimal forensic footprint during normal operation.

PAM ignore hooks

This blend of stealth techniques (dormant hooks, conditional activation, and log tampering) mirrors patterns seen in more advanced Linux persistence tooling.

Project Maturity and Code Organization

The structure and components visible in the screenshots suggest that the project is organized and modular, potentially reflecting a more mature implementation than a basic proof-of-concept.

The presence of anti-debugging components indicates attempts to detect or hinder analysis environments. Combined with modularization and a builder pipeline, the project aligns more closely with operator-grade tooling than commodity scripts.

Even where techniques are individually familiar (PAM hooks, credential capture, log tampering) the integration into a cohesive, configurable implant reflects an evolution toward maintainable and reusable Linux persistence frameworks.

Disclaimer: It is important to note that this backdoor was analyzed based on a threat actor’s dark web post and screenshots rather than full code analysis. This provides us only partial visibility into the nature and functionality of the tool.

Assessing the Threat Actor and Market Credibility

Rehub is a Russian-speaking cybercrime forum that rose in prominence after the disruption of major underground platforms in 2025–2026, offering a broad marketplace for ransomware recruitment, initial access sales, malware, and fraud. 

While it has attracted a mix of actors (including some technically capable operators) the overall level of sophistication is uneven, with many low-tier to mid-tier participants and a noticeable presence of opportunistic users. Its low barrier to entry makes it accessible but also contributes to a higher prevalence of scams, unreliable vendors, and inflated claims. As a result, Rehub reflects a fragmented underground ecosystem where activity remains high, but trust, technical consistency, and credibility are significantly weaker than in more established, invite-only forums.

The “darkworm” Alias

In Flare, we identified 136 items associated with a threat actor using the alias “darkworm.” At this stage, it is not possible to confidently attribute all activity to a single individual, so each item was carefully analyzed and grouped based on factors such as timeline, language, criminal domain, and technical capability. The diversity of activity suggests either a highly opportunistic actor operating across multiple domains, or more likely, several distinct threat actors reusing the same alias.

The diversity of activity suggests either a highly opportunistic actor operating across multiple domains or, more likely, several distinct individuals reusing the same alias.

Pricing History

In the initial post, the threat actor is selling a single copy of the source code rather than a compiled binary.

Screenshot from the post published by the threat actor in the forum

After monitoring the threat actor’s activity in Flare, we found that they reduced the initial price by almost 50% from $1,600 USD to $900 USD.

The original advertisement as captured on Flare

The updated price as captured on Flare (Flare link to post, sign up for the free trialto access if you aren’t already a customer)

While identifying five distinct personas operating under the same “darkworm” alias is not unusual, it reinforces the challenge of attribution. The name itself is not unique, and it is reasonable to assume that multiple threat actors may adopt the same nickname, especially when some of the activity overlaps in time. Notably, the actor associated with selling PamDOORa stands out: the shared code snippets appear realistic and technically plausible, and the described techniques align with known and feasible methods. Based on this, we assess that this particular persona represents a more technically capable and credible threat actor compared to the others.

What Do We Know about Other Open-Source PAM-Backdoors?

We searched GitHub and identified 22 repositories matching the term “PAM backdoor.” Most of these repos are PAM abuse projects, but not all are strictly “PAM Linux backdoors” in the narrow sense. Some are better described as PAM credential theft tools or PAM/SSH persistence installers.

All these tools share a common approach of trying to abuse the authentication path by either replacing or supplementing PAM behavior so an attacker can log in with a magic password, any password, or capture credentials in cleartext. 

PAM Backdoors

• The repo segmentati0nf4ult/linux-pam-backdoor: automates creation of a backdoored pam_unix.so, with tested version claims for PAM 1.2.0 and 1.3.0–1.4.0.
• The repo ociredefz/pambd: a separate PAM module (pambd.so) inserted into the PAM stack.
• The repo raj77in/pam_auth_backdoor: explicitly says it is a PAM module, so any password works.
• The repo mrmoss/poovey: pre-made PAM modules for Linux/BSD with included source.
• The repo flkn404/pamdoor: patched pam_unix style backdoor with rolling one-minute passwords.
• The repo radi0heap/dayofd00m: simple PAM backdoor using the current date string as password.

PAM-Related, Beyond a Simple Backdoor

• The repo rek7/madlib: Python automation that compiles and deploys a modified PAM file, but also logs credentials, updates package hashes, time-stomps files, modifies SELinux handling, and replaces /bin/false and /bin/nologin. That makes it more of a post-compromise persistence/credential tool than a minimal PAM backdoor.
• The repo flashnuke/ssh-door: SSH backdoor that uses PAM shared object injection, while explicitly saying it avoids directly modifying pam_unix.so. 
• The repo wanmywan/duar-pamspy: credential capture tool over PAM, focused on collection and encrypted delivery rather than only a secret login path.
• The repo hensitskyi/PAMinant: combines both a cleartext password logger and a PAM backdoor, and even credits segmentati0nf4ult/linux-pam-backdoor for the backdoor portion. 
• The repo FlamingSpork/libpam_spooky: bash scripts that keep editing PAM config, so login works with a wrong password; that is PAM abuse, but more “config tampering persistence” than elegant module development. It also supports FreeBSD.

The rest were found to be irrelevant.

Classification

If we classify these tools, we can create four families:

• Patch or replace pam_unix.so
• Load a malicious PAM module into the stack
• Credential capture via PAM
• SSH or PAM persistence wrappers

When analyzing the code language distribution, the majority is written in Shell. The overall code quality is low to medium. Many repos are small, old, lightly maintained, or have minimal commits and no or few stars. Several repos rely on crude patching or file replacement of pam_unix.so, which is effective in a lab environment, but hardly in the wild.

While some look more polished because they include installer logic, anti-forensic features, or environment notes, they aren’t necessarily stealthier against modern detection tools.

Implications for Defenders

A post-exploitation tool like a PAM-level backdoor is problematic as it is running in one of the most trusted layers of the operating system, where traditional controls focused on user-space processes or application binaries are often insufficient. 

Defenders can prioritize deploying behavioral detection capabilities on production and other critical systems, with visibility into sensitive junctions such as PAM stacks, SSHD authentication flows, kernel-level hooks, and unauthorized file or library injections.

Monitoring must extend beyond static integrity checks to include runtime behavioral signals, such as unusual authentication patterns, rare source ports, inconsistent session behavior, or anomalous interactions with authentication components. 

Avoid log tampering during incident response, as attackers operating at this level may manipulate artifacts such as btmp, utmp, wtmp, and lastlog, creating a misleading or incomplete forensic trail. IR processes can assume potential log tampering and rely on redundant telemetry sources where possible.

A defense-in-depth approach, combined with zero trust principles, is critical to limit the blast radius of such compromises. Organizations can treat authentication infrastructure as a high-risk zone, enforcing strict access controls, continuous verification, and segmentation.

During remediation, defenders must assume that a compromised system implies full credential exposure. Cleanup efforts should therefore include credential rotation, key revocation, and re-establishing trust across affected systems, rather than focusing solely on removing the implant.