PamDOORa: when authentication itself becomes the back door — what a PAM-based Linux backdoor means for mid-market stacks

The 90-second summary

In early May 2026 security researchers documented a new Linux backdoor called PamDOORa, sold on the Russian cybercrime forum “Rehub” by an actor named “darkworm” for USD 1,600. PamDOORa is a PAM-based post-exploitation toolkit: it hijacks the Pluggable Authentication Module setup with its own library, opens a magic-password path on top of the normal login (combined with a defined TCP port for the SSH auth bypass), harvests credentials from every legitimate login, and tampers with auth logs to erase its tracks. Anti-debugging and a builder pipeline make this not a hobbyist PoC but operator-grade tooling. After Plague (August 2025), PamDOORa is the second publicly traded PAM-based backdoor within eight months — the class is no longer a one-off. For German mid-market organisations: this attack isn't neutralised by a classic patch cycle, because it isn't a patch problem. It's a detection and hardening problem. I describe what I check in customer stacks, and which operational disciplines a stack should carry today. Ninth post in the trust/CVE cluster — and the first to mark a pattern shift: away from CVE patching, toward active tool detection.

What PamDOORa is — and how I work it for customer stacks

How the attack works technically

PAM (Pluggable Authentication Module) is the central authentication layer of every mainstream Linux distribution. Login via SSH, sudo, console, su, cron jobs, Cockpit, FTP daemons — they all go through PAM modules. Configuration lives in /etc/pam.d/, the modules themselves typically in /lib/security/ or /lib64/security/.

PamDOORa exploits this central position: a custom .so file is hooked in as an additional module (or replaces an existing one). At runtime the module hooks into every authentication call. Three effects:

• Magic password. A password chosen by the attacker is accepted alongside the real password. In the published reporting the auth is conditioned against a specific TCP port — that makes the bypass invisible to typical penetration-test viewpoints, because the “main entrance” still looks completely normal.
• Credential harvesting. Every cleartext password a legitimate user enters is captured by the PAM module. Incrementally the attacker builds up an inventory of credentials of every Linux user, plus everyone who SSHes into this host.
• Log tampering. Anti-forensic features rewrite the auth trail so that magic-password logins don't appear in /var/log/auth.log or journalctl -u sshd. Anyone searching only the standard logs sees nothing.

Operator-grade indicators: anti-debugging routines hinder static analysis, a builder pipeline lets the buyer compile the module with their own magic credentials — that's not the level of public PAM PoC repositories. It's purpose-built for APT-style operations.

Source: The Hacker News — New Linux PamDOORa Backdoor Uses PAM Modules to Steal SSH Credentials, plus the in-depth threat-intel analysis from Flare.

Why PAM-based backdoors are the hardest persistence class

Three properties make the class so effective:

First, position in the stack. PAM modules run with root privileges and are queried before every authentication decision. A malicious module can read auth data more accurately than any classic userland hook. There's nothing in between.

Second, detection asymmetry. An additional PAM module looks in a quick ls /lib/security/ like a perfectly normal .so file. Without a hash comparison against the distribution package it doesn't stand out. Without continuous file-integrity monitoring on /etc/pam.d/ and /lib*/security/, no one sees the swap.

Third, lateral spread. When the module sits on a central bastion host or a build machine, over days and weeks it harvests credentials from every user and service account passing through. Those credentials open the next hosts. PAM backdoors aren't primarily a target-system problem — they're a supply system for downstream escalation.

After Plague in August 2025, PamDOORa is the second publicly traded representative of this class within eight months. Anyone treating that as an anomaly has been an optimist for a while now.

Detection discipline: what I check on customer stacks

Four check paths, not all of which need to run in parallel, but each of them is an indicator on its own:

1. PAM module integrity. Hash comparison of all .so files in /lib/security/, /lib64/security/ and /usr/lib/security/ against distribution packages — with the distribution's own tooling. RPM family rpm -Va, Debian/Ubuntu debsums -c, NixOS nix store verify. Anything that doesn't belong to a package or has a changed hash gets investigated immediately.

2. PAM configuration inventory./etc/pam.d/ contains a manageable number of files. Every line with auth, account, session, password is compared against the distribution default. Additional module entries, modified order, unusual module paths — all triggers for closer investigation.

3. Unusual TCP listeners. PamDOORa conditions the magic auth against a specific TCP port. ss -tlnp shows every listener with the owning process. Ports that come from neither the system profile nor the documented stack are a clear signal.

4. Auth-log correlation against external aggregator. When the backdoor tampers with local logs, that does nothing against logs streamed in real time to an external SIEM/log aggregator. Discrepancies between local /var/log/auth.log and the external trail are the strongest anti-forensic detection signal.

Hardening discipline: what my customer hosts already carry

Five hardening points that run in my standard customer stack and either prevent PamDOORa-style attacks or surface them early:

• File integrity monitoring on /lib*/security/ and /etc/pam.d/ — with AIDE or Tripwire, continuous, alerts on every modification. On NixOS hosts the PAM configuration is declarative in the Nix generation, every deviation would be a drift detection.
• External auth-log streaming — auth.log and journald get streamed in real time to a log aggregator outside the customer host. Local tampering is irrelevant there.
• SSH hardening with public-key-only auth — no password authentication, no magic-password possibility. That doesn't address the PAM manipulation as such, but it severs PamDOORa's primary use path.
• Bastion pattern instead of direct SSH on production hosts — SSH access to production runs through a single, dedicated bastion host with short sessions, just-in-time privilege, and full audit trail. The bastion gets correspondingly more hardening attention.
• NixOS or image-based immutability — wherever possible, run hosts so that the filesystem can't be changed without a rebuild. A foreign .so file in /lib/security/ would be gone on the next reboot in a purely declarative setup.

Architecture layers above the host: what opkssh/OIDC, hardware tokens, and the bastion pattern deliver

The five hardening points above address PamDOORa on the host. Two upstream architecture layers make the attack structurally largely ineffective, because they remove what PamDOORa harvests (static passwords and persistent SSH keys) from the authentication path entirely.

opkssh / OIDC with short-lived SSH certificates

Instead of authenticating with public keys permanently sitting in ~/.ssh/, login goes through an OpenID Connect issuer (self-hosted: Keycloak, Authentik, Zitadel, or comparable; managed: Auth0, Google Workspace, Microsoft Entra) that issues short-lived SSH certificates. Typical lifetime: ten minutes to eight hours. Every new login triggers a new issuer round trip. What PamDOORa can no longer steal: a reusable secret. Even if the backdoor reads along, the attacker has a token that expires soon — and that can't be renewed without renewed issuer contact. Plus: the auth trail lives primarily at the issuer, i.e. outside the compromised host. Anti-forensic on the Linux machine doesn't change that. Tooling note: opkssh makes the OIDC-to-SSH path practical to introduce now — a major engineering project two years ago, today a weekend setup with your own Keycloak, Authentik, or Zitadel instance.

YubiKey-secured, certificate-encrypted VPN as an upstream layer

In my own setup, every SSH access to production hosts runs exclusively through a VPN whose authentication is bound to a hardware YubiKey touch. The VPN tunnel itself is mTLS-secured with certificates that don't sit on a stealable medium but in the YubiKey chip. Three structural consequences: (1) PamDOORa on a host doesn't see VPN authentication, because that happens off-host — the PAM module has no hook into the tunnel setup. (2) Even a stolen SSH token is useless without the additional physical YubiKey touch for VPN access. (3) Phishing paths fail because YubiKey auth is origin-bound and can't be redirected into a forged input mask.

Together the two layers produce a clear effectiveness asymmetry. PamDOORa is installable once an attacker has initial access — but they don't get persistent credentials for lateral escalation, nor login paths to other hosts, because every authentication demands short-lived tokens plus a hardware touch. A persistence pearl turns into a collection tool with no reusable loot.

What to do when no VPN layer is feasible

Not every stack can or wants to put a VPN in front of every SSH access — SaaS customer portals, small on-prem setups, cloud stacks with clear public-IP patterns. For those cases there's a hardening order that achieves almost the same effect:

• Public-key-only auth, no passwords.PasswordAuthentication no and ChallengeResponseAuthentication no in /etc/ssh/sshd_config. With that, PamDOORa's magic password has no entry path, because sshd doesn't even pass password-based auth to PAM in the first place.
• SSH certificates instead of persistent public keys. Even without a VPN: an SSH CA that signs short-lived certificates (e.g. via opkssh or HashiCorp Vault SSH-CA) replaces the authorized_keys collection. Even if an attacker gets onto a host, they have no certificate they could reuse on another host.
• Hardware tokens for SSH auth (FIDO2-SK). OpenSSH has supported native FIDO2 hardware keys since 8.2 (ssh-keygen -t ed25519-sk). Every SSH login then needs a physical YubiKey touch without a VPN in between. PamDOORa can't simulate the touch.
• Source-IP restriction plus Fail2ban. When all engineer workstations come from a defined office range or a static cloud NAT, sshd gets conditioned to a narrow allow-list. That cuts off easy lateral-spread paths.
• Out-of-band audit streaming remains mandatory. Whether VPN in front or not: auth logs have to leave the host in real time. Otherwise anti-forensic wins.

The FIDO2-SK variant in combination with SSH certificates and public-key-only auth delivers 80–85% of the effect of the VPN pattern, without a VPN layer. For many mid-market stacks that's the pragmatic answer.

What this means for Kubernetes / k3s and bastion hosts

Container hosts are the most attractive PamDOORa host type imaginable: they run 24/7, accommodate authentications of many service accounts and operator sessions, and people frequently forget while orchestrating containers that the underlying Linux host still uses PAM.

Kubernetes worker nodes and k3s hosts. The Kube API layer has its own authentication (TLS client certs, service-account tokens, OIDC webhook). But: anyone entering a worker node — either via SSH for maintenance or via kubectl debug node — goes through PAM. PamDOORa on a worker node thus collects every operator credential that ever SSHes to the machine, plus every service-account token in memory once someone runs a pod-exec. Concrete recommendations: (1) Worker nodes have no direct SSH — maintenance runs through the bastion or via kubectl node-shell workflows with OIDC auth. (2) FIM on /lib*/security/ on worker nodes too, not just on the control plane. (3) Image-based workers (Talos Linux, Bottlerocket, Flatcar, NixOS) — that makes implanting a .so file significantly harder.

Control plane / k3s server. A PamDOORa-compromised control-plane host is the worst case: kubelet, etcd, and service-account-token paths all run through this very machine. Hardening has to be sharpest here: declarative configuration (NixOS or Talos), no SSH direct paths, every maintenance through the bastion plus YubiKey, continuous FIM with alerts to SIEM.

Bastion hosts — the double-edged layer. The bastion pattern reduces attack surface because production hosts aren't directly SSH-reachable — but it makes the bastion itself the primary target. A PamDOORa-installed module on the bastion harvests credentials of every engineer and operations session, handing the attacker the master key to the infrastructure behind it. The consequence: bastion hosts need the full hardening package plus two special disciplines — (1) bastion sessions are short and recorded (TLS bastion with recording), and (2) the bastion ideally runs as an ephemeral host (image-based, regularly re-provisioned), so any persistence vanishes on the next rebuild. Anyone running a bastion that's been up for three years has long since given up the bastion advantage.

How I handle this myself

In my own infrastructure, AIDE runs on PAM and authentication paths, auth logs stream in real time to a central log aggregator outside customer hosts, every SSH access is public-key-only, bastion hosts are the only paths into productive stacks, and for my NixOS setups the PAM configuration is part of the Nix generation — every drift would be an alert event, not a quiet observation.

When the PamDOORa threat intel was published, I internally checked my detection paths against the documented indicators — the four paths from the detection block above would have caught a PamDOORa-installed module within minutes. Not because I have special tools, but because the discipline is generic enough to catch any new PAM-based backdoor.

Three depths of action for your stack

Short-term (this week):

• On every productive Linux host, manually check once: rpm -Va | grep security or debsums -c | grep security. Anything deviating in pam packages or libpam-modules packages goes on the inspection bench today.
• ls -la /lib/security/ /lib64/security/ /usr/lib/security/ — sort by date, is one of the modules markedly newer than the last distribution patch?
• ss -tlnp on all productive hosts — port inventory, what's running, what should be running.

Medium-term (next 4 weeks):

• Activate AIDE or Tripwire on /lib*/security/ and /etc/pam.d/, with alerts to SIEM/aggregator. If that's already running, refresh the baseline.
• Establish external auth-log streaming if not yet in place. Local logs are worthless in the backdoor case.
• SSH hardening: disable password auth, allow only public-key auth. Magic-password-based bypass then has nothing to address.

Strategic (next quarter):

• Bastion pattern for all SSH access to production. Direct SSH on application hosts becomes the exception, not the rule.
• Image-based host operation — NixOS, immutable container hosts, or read-only-root with verified layers. Massively raises the cost of PAM persistence.
• Threat-hunting routine: once per quarter a forensic spot check against the detection indicators above. Not because we have leads, but because observation is part of the discipline.
• Set up an opkssh pilot with your own OIDC issuer. Anyone with Keycloak, Authentik, or a comparable self-hosted IdP in the stack already can switch on the SSH CA in a test environment over a weekend. Anyone without those plans the issuer first.
• Hardware-token pilot on engineer workstations: roll out FIDO2-SK keys for SSH (ssh-keygen -t ed25519-sk), let persistent keys expire, then bind production-host SSH access to a hardware touch.
• For stacks without a VPN layer: enforce public-key-only, fully disable password auth, SSH CA via Vault or opkssh, source-IP restriction on the bastion, out-of-band audit streaming.
• Migrate K8s/k3s workers to image-based OS (Talos, Bottlerocket, Flatcar, NixOS) where the workload supports it. Run bastion hosts ephemerally — re-provisioned at least monthly, ideally per session.