PamDOORa: Wenn die Authentifizierung selbst zur Hintertür wird — was eine PAM-basierte Linux-Backdoor für Mittelstand-Stacks bedeutet

Zusammenfassung in 90 Sekunden

Sicherheitsforscher haben Anfang Mai 2026 eine neue Linux-Backdoor namens PamDOORa dokumentiert, die im russischen Cybercrime-Forum „Rehub“ durch einen Akteur namens „darkworm“ für 1.600 USD verkauft wird. PamDOORa ist ein Post-Exploitation-Toolkit auf PAM-Basis: Es kapert das Pluggable Authentication Module Linux-Setup mit einer eigenen Library, schaltet einen Magic-Password-Pfad zusätzlich zum normalen Login frei (kombiniert mit einem definierten TCP-Port für SSH-Auth-Bypass), erntet Credentials sämtlicher legitimen Logins ab und manipuliert die Auth-Logs, um die Spuren zu verwischen. Anti-Debugging und Builder-Pipeline machen das Tool nicht zum Hobby-PoC, sondern zu Operator-Grade-Werkzeug. Nach Plague (August 2025) ist PamDOORa die zweite öffentlich gehandelte PAM-basierte Backdoor binnen acht Monaten — die Klasse ist also kein Einzelfund. Für den deutschen Mittelstand bedeutet das: dieser Angriff wird durch einen klassischen Patch-Zyklus nicht entschärft, weil es kein Patch-Problem ist. Es ist ein Detection- und Hardening-Problem. Wir beschreiben, was wir bei Customer-Stacks prüfen, und welche drei operativen Disziplinen ein Stack heute tragen sollte. Neunter Post im Trust-/CVE-Cluster — und der erste, der einen Pattern-Wechsel markiert: weg vom CVE-Patch, hin zu aktiver Tool-Detection.

Was PamDOORa ist — und wie wir es für Customer-Stacks bearbeiten

Wie der Angriff technisch funktioniert

PAM (Pluggable Authentication Module) ist die zentrale Authentifizierungs-Schicht jeder Mainstream-Linux-Distribution. Login über SSH, sudo, Console, su, Cron-Jobs, Cockpit, FTP-Daemons — alle gehen über PAM-Module. Die Konfiguration liegt in /etc/pam.d/, die Module selbst typischerweise in /lib/security/ bzw. /lib64/security/.

PamDOORa nutzt diese zentrale Position aus: Eine eigene .so-Datei wird als zusätzliches Modul eingehängt (oder ein bestehendes Modul ersetzt). Im laufenden Betrieb klinkt sich das Modul in jeden Authentifizierungs-Aufruf ein. Drei Wirkungen:

• Magic-Password. Ein vom Angreifer definiertes Passwort wird zusätzlich zum echten Passwort akzeptiert. Im Bericht ist die Auth gegen einen spezifischen TCP-Port konditioniert — das macht den Bypass aus typischen Penetration-Test-Standpunkten unsichtbar, weil der „Haupteingang“ weiter ganz normal aussieht.
• Credential-Harvesting. Jedes Klartext-Passwort, das ein legitimer Nutzer eingibt, wird vom PAM-Modul mitgeschnitten. Inkrementell baut sich der Angreifer ein Inventar der Credentials sämtlicher Linux-Nutzer auf, plus aller, die zu diesem Host SSHen.
• Log-Tampering. Anti-Forensic-Funktionen schreiben den Auth-Trail so um, dass die Magic-Password-Logins nicht in /var/log/auth.log oder journalctl -u sshd auftauchen. Wer nur die Standard-Logs durchsucht, sieht nichts.

Operator-Grade-Indikatoren: Anti-Debugging-Routinen erschweren statische Analyse, eine Builder-Pipeline erlaubt dem Käufer, das Modul mit eigenen Magic-Credentials zu kompilieren — das ist nicht das Niveau öffentlicher PAM-PoC-Repositories. Es ist gezielt für APT-artige Operationen gebaut.

Quelle: The Hacker News — New Linux PamDOORa Backdoor Uses PAM Modules to Steal SSH Credentials, plus die ausführliche Threat-Intel-Analyse von Flare.

Warum PAM-basierte Backdoors die schwerste Persistenz-Klasse sind

Drei Eigenschaften machen die Klasse so wirksam:

Erstens, Position im Stack. PAM-Module laufen mit Root-Rechten und werden vor jeder Authentifizierungs-Entscheidung gefragt. Ein bösartiges Modul kann genauer Auth-Daten lesen als jeder klassische Hook im Userland. Es gibt nichts dazwischen.

Zweitens, Detection-Asymmetrie. Ein zusätzliches PAM-Modul sieht in einem flotten ls /lib/security/ aus wie eine ganz normale .so-Datei. Ohne Hash-Vergleich gegen das Distribution-Paket fällt es nicht auf. Ohne kontinuierliches File-Integrity-Monitoring auf /etc/pam.d/ und /lib*/security/ sieht niemand den Wechsel.

Drittens, Lateral Spread. Wenn das Modul auf einem zentralen Bastion-Host oder einer Build-Maschine sitzt, sammelt es über Tage und Wochen die Credentials aller dort durchgehenden Nutzer und Service-Accounts. Diese Credentials öffnen die nächsten Hosts. PAM-Backdoors sind nicht primär ein Zielsystem-Problem — sie sind ein Lieferanten-System für die nachfolgende Eskalation.

Nach Plague im August 2025 ist PamDOORa der zweite öffentlich gehandelte Vertreter dieser Klasse innerhalb von acht Monaten. Wer das für eine Anomalie hält, ist seit längerem optimistisch.

Detection-Disziplin: was wir bei Customer-Stacks prüfen

Vier Prüf-Pfade, die nicht alle gleichzeitig laufen müssen, aber von denen jeder einzeln ein Indikator ist:

1. PAM-Modul-Integrität. Hash-Vergleich aller .so-Dateien in /lib/security/, /lib64/security/ und /usr/lib/security/ gegen die Distribution-Pakete — mit dem distributionseigenen Werkzeug. Auf RPM-Familien rpm -Va, auf Debian/Ubuntu debsums -c, auf NixOS über nix store verify. Was nicht zum Paket gehört oder einen geänderten Hash hat, gehört sofort untersucht.

2. PAM-Konfigurations-Inventur./etc/pam.d/ liefert eine überschaubare Anzahl Dateien. Jede Zeile mit auth, account, session, password wird gegen den Distribution-Default verglichen. Zusätzliche Module-Einträge, modifizierte Reihenfolgen, ungewöhnliche Module-Pfade — alles Trigger für eine Nähere-Untersuchung.

3. Ungewöhnliche TCP-Listener. PamDOORa konditioniert die Magic-Auth gegen einen spezifischen TCP-Port. ss -tlnp zeigt jeden Listener mit zugehörigem Prozess. Ports, die weder vom System-Profil noch vom dokumentierten Stack stammen, sind ein klares Indiz.

4. Auth-Log-Korrelation gegen externes Log-Aggregat. Wenn die Backdoor lokale Logs manipuliert, hilft das nichts gegen Logs, die in Echtzeit an einen externen SIEM-/Log-Aggregator gestreamt werden. Diskrepanzen zwischen lokalem /var/log/auth.log und dem externen Trail sind das stärkste Anti-Forensic-Detection-Signal.

Hardening-Disziplin: was unsere Customer-Hosts ohnehin tragen

Fünf Hardening-Punkte, die in unserem Standard-Customer-Stack laufen und PamDOORa-artige Angriffe entweder verhindern oder früh sichtbar machen:

• File Integrity Monitoring auf /lib*/security/ und /etc/pam.d/ — mit AIDE oder Tripwire, kontinuierlich, mit Alerts auf jede Modifikation. Auf NixOS-Hosts ist die PAM-Konfiguration deklarativ in der Nix-Generation, jede Abweichung wäre eine Drift-Detektion.
• Externes Auth-Log-Streaming — auth.log und journald werden in Echtzeit an einen Log-Aggregator außerhalb des Customer-Hosts geschickt. Manipulation lokal ist dort wirkungslos.
• SSH-Hardening mit Public-Key-Only-Auth — keine Passwort-Authentifizierung, keine Magic-Password-Möglichkeit. Das adressiert nicht die PAM-Manipulation als solche, aber es zerschneidet den primären Nutzungs-Pfad von PamDOORa.
• Bastion-Pattern statt Direkt-SSH auf Production-Hosts — SSH-Zugriff auf Production läuft über einen einzigen, dedizierten Bastion-Host mit kurzen Sessions, Just-in-time-Privilege und vollem Audit-Trail. Der Bastion bekommt entsprechend mehr Hardening-Aufmerksamkeit.
• NixOS oder Image-basierte Immutability — wo möglich Hosts so betreiben, dass das Filesystem nicht ohne Rebuild geändert werden kann. Eine fremde .so-Datei in /lib/security/ wäre bei einem rein deklarativen Setup beim nächsten Reboot weg.

Architektur-Schichten oberhalb des Hosts: was opkssh/OIDC, Hardware-Token und Bastion-Pattern leisten

Die fünf Hardening-Punkte oben adressieren PamDOORa auf dem Host. Zwei vorgelagerte Architektur-Schichten machen den Angriff strukturell weitgehend wirkungslos, weil sie das, was PamDOORa abgreift (statische Passwörter und persistente SSH-Keys), aus dem Authentifizierungs-Pfad nehmen.

opkssh / OIDC mit kurzlebigen SSH-Zertifikaten

Statt mit dauerhaft im ~/.ssh/ liegenden Public-Keys zu authentifizieren, läuft der Login über einen OpenID-Connect-Issuer (self-hosted: Keycloak, Authentik, Zitadel oder vergleichbar; managed: Auth0, Google Workspace, Microsoft Entra), der kurzlebige SSH-Zertifikate ausstellt. Typische Lebenszeit: zehn Minuten bis acht Stunden. Jeder neue Login löst eine neue Issuer-Round-Trip aus. Was PamDOORa damit nicht mehr stehlen kann: ein wiederverwendbares Geheimnis. Selbst wenn die Backdoor mitliest, hat der Angreifer ein Token, das in absehbarer Zeit verfällt — und das nicht ohne erneuten Issuer-Kontakt erneuert werden kann. Plus: der Auth-Trail liegt primär beim Issuer, also außerhalb des kompromittierten Hosts. Anti-Forensic auf der Linux-Maschine ändert daran nichts. Werkzeug-Hinweis: opkssh macht den OIDC-zu-SSH-Pfad inzwischen zumutbar einführbar — vor zwei Jahren ein Major-Engineering-Projekt, heute ein Wochenend-Setup mit der eigenen Keycloak-, Authentik- oder Zitadel-Instanz.

YubiKey-gesichertes, Zertifikat-verschlüsseltes VPN als vorgelagerte Schicht

Bei uns selbst läuft jeder SSH-Zugriff auf Production-Hosts ausschließlich über ein VPN, dessen Authentifizierung an einen Hardware-YubiKey-Touch gebunden ist. Der VPN-Tunnel selbst ist mTLS-gesichert mit Zertifikaten, die nicht auf einem klau-baren Datenträger liegen, sondern im YubiKey-Chip. Drei strukturelle Folgen: (1) PamDOORa auf einem Host sieht keine VPN-Authentifizierung, weil die außerhalb des Hosts stattfindet — das PAM-Modul hat keinen Hook in den Tunnel-Aufbau. (2) Selbst ein erbeutetes SSH-Token nützt nichts ohne zusätzlichen physischen YubiKey-Touch für den VPN-Zugang. (3) Phishing-Pfade scheitern, weil YubiKey-Auth Origin-Bound ist und nicht in eine gefälschte Eingabe-Maske umlenkbar ist.

Zusammen ergeben die zwei Schichten eine deutliche Wirkungs-Asymmetrie. PamDOORa ist installierbar, wenn der Angreifer einmal initial Zugriff hat — aber er erhält damit weder dauerhafte Credentials zur lateralen Eskalation noch Login-Pfade auf andere Hosts, weil jede Authentifizierung kurzlebige Token plus Hardware-Touch verlangt. Aus einer Persistenz-Perle wird ein Sammel-Tool ohne wiederverwendbare Beute.

Was tun, wenn kein VPN-Layer möglich ist?

Nicht jeder Stack kann oder will ein VPN vor jeden SSH-Zugang stellen — SaaS-Customer-Portale, kleine On-Prem-Setups, Cloud-Stacks mit klaren Public-IP-Patterns. Für diese Fälle gibt es eine Hardening-Reihenfolge, die fast die gleiche Wirkung erzielt:

• Public-Key-Only-Auth, kein Passwort.PasswordAuthentication no und ChallengeResponseAuthentication no in /etc/ssh/sshd_config. Damit hat das PamDOORa-Magic-Password keinen Eintrittspfad mehr, weil sshd Passwort-basierte Auth gar nicht erst an PAM weiterreicht.
• SSH-Zertifikate statt persistenter Public-Keys. Auch ohne VPN: eine SSH-CA, die kurzlebige Zertifikate signiert (z.B. via opkssh oder HashiCorp Vault SSH-CA), ersetzt die authorized_keys-Sammlung. Selbst wenn ein Angreifer Zugriff auf einen Host bekommt, hat er kein Zertifikat, das er auf einem anderen Host wiederverwenden könnte.
• Hardware-Token für SSH-Auth (FIDO2-SK). OpenSSH unterstützt seit 8.2 native FIDO2-Hardware-Keys (ssh-keygen -t ed25519-sk). Damit braucht jeder SSH-Login einen physischen YubiKey-Touch, ohne dass ein VPN dazwischenhängen muss. PamDOORa kann den Touch nicht simulieren.
• Source-IP-Restriktion plus Fail2ban. Wenn die Engineer-Workstations alle aus einem definierten Office-Range oder einem statischen Cloud-NAT kommen, wird sshd auf eine schmale Allow-List konditioniert. Das schneidet einfache Lateral-Spread-Pfade ab.
• Out-of-Band-Audit-Streaming bleibt obligatorisch. Egal ob VPN davor oder nicht: Auth-Logs müssen in Echtzeit aus dem Host raus. Sonst greift Anti-Forensic.

Die FIDO2-SK-Variante in Kombination mit SSH-Zertifikaten und Public-Key-Only-Auth liefert ohne VPN-Layer 80–85% der Wirkung des VPN-Patterns. Für viele Mittelstand-Stacks ist das die pragmatische Antwort.

Was das für Kubernetes / k3s und Bastion-Hosts bedeutet

Container-Hosts sind der attraktivste PamDOORa-Wirts-Typ überhaupt: Sie laufen 24/7, beherbergen Authentifizierungen vieler Service-Accounts und Operator-Sessions, und häufig vergisst man bei der Container-Orchestrierung, dass der unterliegende Linux-Host weiterhin PAM nutzt.

Kubernetes Worker-Nodes und k3s-Hosts. Der Kube-API-Layer hat seine eigene Authentifizierung (TLS-Client-Certs, Service-Account-Tokens, OIDC-Webhook). Aber: Wer einen Worker-Node betritt — sei es über SSH zur Wartung oder über kubectl debug node — geht durch PAM. PamDOORa auf einem Worker-Node sammelt also alle Operator-Credentials, die jemals zur Maschine SSH-en, plus alle Service-Account-Tokens, die im Speicher liegen, sobald jemand einen Pod-Exec ausführt. Konkrete Empfehlungen: (1) Worker-Nodes haben kein direktes SSH — Wartung läuft über den Bastion oder über kubectl node-shell-Workflows mit OIDC-Auth. (2) FIM auf /lib*/security/ auch auf Worker-Nodes, nicht nur auf Control-Plane. (3) Image-basierte Worker (Talos Linux, Bottlerocket, Flatcar, NixOS) — das macht das Einnisten einer .so-Datei deutlich schwerer.

Control-Plane / k3s-Server. Ein PamDOORa-kompromittierter Control-Plane-Host ist der Worst Case: kubelet-, etcd- und Service-Account-Token-Pfade laufen über genau diese Maschine. Hier muss das Hardening am schärfsten greifen: deklarative Konfiguration (NixOS oder Talos), keine SSH-Direktwege, jede Wartung über den Bastion plus YubiKey, kontinuierliches FIM mit Alerts auf SIEM.

Bastion-Hosts — die zweischneidige Schicht. Der Bastion-Pattern reduziert Angriffsfläche, weil produktive Hosts gar nicht direkt SSH-erreichbar sind — aber er macht den Bastion selbst zum primären Ziel. Ein PamDOORa-installiertes Modul auf dem Bastion sammelt die Credentials sämtlicher Engineers und Operations-Sessions und gibt damit den Generalschlüssel zur dahinterliegenden Infrastruktur. Die Konsequenz: Bastion-Hosts brauchen das volle Hardening-Paket plus zwei Sonder-Disziplinen — (1) Bastion-Sessions sind kurz und protokolliert (TLS-Bastion mit Recording), und (2) der Bastion läuft idealerweise als ephemerer Host (Image-basiert, regelmäßig neu provisioniert), damit eine etwaige Persistenz beim nächsten Rebuild verschwindet. Wer einen Bastion betreibt, der seit drei Jahren läuft, hat den Bastion-Vorteil längst aufgegeben.

Wie wir das selbst handhaben

In unserer eigenen Infrastruktur läuft AIDE auf PAM- und Authentifizierungs-Pfaden, Auth-Logs gehen in Echtzeit an einen zentralen Log-Aggregator außerhalb der Customer-Hosts, alle SSH-Zugänge sind public-key-only, Bastion-Hosts sind die einzigen Pfade in produktive Stacks, und für unsere NixOS-Setups ist die PAM-Konfiguration Teil der Nix-Generation — jede Drift wäre ein Alarm-Event, nicht eine stille Beobachtung.

Bei der Veröffentlichung der PamDOORa-Threat-Intel haben wir intern unsere Detection-Pfade gegen die dokumentierten Indikatoren geprüft — die vier Pfade aus dem Detection-Block oben hätten ein PamDOORa-installiertes Modul innerhalb von Minuten gefangen. Nicht weil wir besondere Tools haben, sondern weil die Disziplin generisch genug ist, jede neue PAM-basierte Backdoor zu fangen.

Drei Maßnahmen-Tiefen für Ihren Stack

Kurzfristig (diese Woche):

• Auf jedem produktiven Linux-Host einmal manuell prüfen: rpm -Va | grep security bzw. debsums -c | grep security. Was bei pam-Paketen oder libpam-modules-Paketen abweicht, gehört heute auf den Prüfstand.
• ls -la /lib/security/ /lib64/security/ /usr/lib/security/ — Datum-Sortierung, ist eines der Module deutlich neuer als der letzte Distributions-Patch?
• ss -tlnp auf allen produktiven Hosts — Port-Inventur, was läuft, was sollte laufen.

Mittelfristig (nächste 4 Wochen):

• AIDE oder Tripwire auf /lib*/security/ und /etc/pam.d/ aktivieren, mit Alerts an SIEM/Aggregator. Wenn das schon läuft, Baseline aktualisieren.
• Externes Auth-Log-Streaming etablieren, falls noch nicht vorhanden. Logs lokal sind im Backdoor-Fall wertlos.
• SSH-Hardening: Passwort-Auth disablen, nur Public-Key-Auth zulassen. Magic-Password-basierter Bypass adressiert dann nichts.

Strategisch (nächstes Quartal):

• Bastion-Pattern für alle SSH-Zugänge auf Production. Direkt-SSH auf Application-Hosts wird zur Ausnahme, nicht zur Regel.
• Image-basierte Host-Operation — NixOS, immutable Container-Hosts oder Read-only-Root mit verifizierten Layers. Macht den Aufwand für eine PAM-Persistenz drastisch höher.
• Threat-Hunting-Routine: einmal pro Quartal eine forensische Stichprobe gegen die Detection-Indikatoren oben. Nicht weil wir Hinweise haben, sondern weil das Beobachten Teil der Disziplin ist.
• opkssh-Pilot mit eigenem OIDC-Issuer aufsetzen. Wer einen Keycloak, Authentik oder vergleichbaren self-hosted IdP schon im Stack hat, schaltet die SSH-CA in einer Test-Umgebung an einem Wochenende. Wer noch nichts davon hat, plant zuerst den Issuer.
• Hardware-Token-Pilot auf Engineer-Workstations: FIDO2-SK-Keys für SSH (ssh-keygen -t ed25519-sk) ausrollen, persistente Keys ablaufen lassen, danach SSH-Zugriff auf Production-Hosts an Hardware-Touch koppeln.
• Für Stacks ohne VPN-Layer: Public-Key-Only erzwingen, Passwort-Auth komplett deaktivieren, SSH-CA mit Vault oder opkssh, Source-IP-Restriktion auf Bastion, Out-of-Band-Audit-Streaming.
• K8s/k3s-Worker auf Image-basierte OS (Talos, Bottlerocket, Flatcar, NixOS) migrieren, wo die Workload das trägt. Bastion-Hosts ephemer betreiben — mindestens monatlich neu provisioniert, idealerweise pro Session ephemer.