PamDOORa : Analyse d’une nouvelle porte dérobée Linux basée sur PAM en vente sur le Dark Web

Par Assaf Morag, chercheur en cybersécurité

Un individu malveillant, actif sur un forum russe de cybercriminalité, propose à 1 600 $ le code source complet d'une porte dérobée Linux s'intégrant à l'une des couches les plus sécurisées du système d'exploitation : la pile PAM (Pluggable Authentication Module). Cet outil, baptisé PamDOORa, est une nouvelle porte dérobée basée sur PAM, conçue pour fonctionner après exploitation et permettre l'authentification aux serveurs via OpenSSH. Elle serait persistante sur les systèmes Linux (x86_64).

Alors que les systèmes Linux continuent de dominer les infrastructures d'entreprise et les environnements cloud, les attaquants explorent constamment de nouveaux outils de post-exploitation pour maintenir leur présence sur les serveurs compromis.

Nous avons analysé la publication de l'acteur malveillant, examiné les captures d'écran partagées et les outils open source comparables, et évalué le risque et la nouveauté de l'outil en tant que capacité de post-exploitation. 

Principales conclusions concernant PamDOORa

• PamDOORa est une porte dérobée post-exploitation basée sur PAM pour Linux (x86_64) qui permet un accès SSH persistant via un mot de passe unique et une combinaison spécifique de port TCP, tout en collectant simultanément les identifiants de tous les utilisateurs légitimes s'authentifiant sur le système compromis. La capture des identifiants s'effectue au sein même de la pile PAM, interceptant ainsi les mots de passe avant toute journalisation au niveau applicatif.
• Cet outil intègre des fonctionnalités anti-forensiques qui manipulent les journaux d'authentification lastlog, btmp, utmp et wtmp afin d'effacer toute trace d'accès de l'attaquant. Ceci compromet directement les délais de réponse aux incidents et signifie que les équipes d'intervention qui se connectent pour enquêter sur un serveur compromis risquent de voir leurs identifiants capturés et leur accès effacé silencieusement des journaux.
• L'auteur de la menace a réduit le prix demandé de près de 50 % (de 1 600 $ à 900 $), ce qui laisse supposer soit un intérêt limité de la part des acheteurs, soit une tentative d'accélérer la vente. Notre analyse a identifié cinq profils distincts utilisant le même pseudonyme sur plusieurs forums, mais le vendeur de PamDOORa fait preuve d'une crédibilité technique nettement supérieure aux autres, avec des extraits de code réalistes et des techniques conformes aux méthodes d'abus PAM connues.
• PamDOORa représente une évolution par rapport aux portes dérobées PAM open source existantes. Si les techniques individuelles (hooks PAM, capture d'identifiants, falsification de journaux) sont bien documentées, son intégration dans un implant modulaire et cohérent, doté de mécanismes anti-débogage, de déclencheurs sensibles au réseau et d'un pipeline de construction, le rapproche davantage d'un outil de qualité professionnelle que les scripts de démonstration rudimentaires que l'on trouve dans la plupart des dépôts publics.

Avertissement important : cette analyse repose sur une publicité du dark web et des captures d’écran partagées, et non sur un examen complet du code source. Les capacités réelles, la fiabilité et la sophistication de l’outil pourraient différer de ce qu’affirme l’auteur de la menace.

Qu'est-ce que Linux PAM ?

Sur les systèmes Linux, les modules d'authentification enfichables (PAM) constituent le moteur d'authentification central qui contrôle la manière dont les utilisateurs et les services vérifient leur identité et obtiennent l'accès. Au lieu d'intégrer la logique d'authentification directement dans chaque application, PAM utilise une approche modulaire, basée sur des politiques définies dans le répertoire `/etc/pam.d/`. Chaque fichier y régit la manière dont un service spécifique (tel que SSH, sudo ou login) gère l'authentification, l'autorisation, les politiques de mots de passe et la gestion des sessions. 

Cette conception offre flexibilité et cohérence à l'ensemble du système, mais elle fait également de PAM une couche de sécurité très sensible : toute modification de ces configurations peut affecter tous les flux d'authentification, ce qui en fait une cible de choix pour les attaquants cherchant à assurer la persistance, à collecter des informations d'identification ou à contourner furtivement le contrôle d'accès.

Bibliothèque PAM

Le fichier `/etc/pam.d/sshd` définit la gestion de l'authentification SSH. Il sert de couche de stratégie pour les modules d'authentification enfichables (PAM), spécifiant les modules à exécuter lors de la connexion d'un utilisateur via SSH. Au lieu d'implémenter l'authentification directement, il référence les modules `pam_*.so` qui effectuent des tâches telles que la validation du mot de passe, la vérification du compte et l'établissement de la session. `/etc/pam.d/sshd` contrôle le flux d'authentification, tandis que les modules `.so` sous-jacents l'exécutent.

Comment les attaquants abusent de PAM

Les acteurs malveillants ne modifient généralement pas l'intégralité de la configuration. Ils effectuent des changements mineurs et stratégiques pour prendre le contrôle tout en restant invisibles.

Dans des configurations comme `/etc/pam.d/sshd`, l'approche la plus courante consiste à insérer ou modifier une seule ligne pour qu'elle appelle un module malveillant ou exploité. Par exemple, l'ajout d'une ligne au début de la chaîne d'authentification (souvent via `common-auth`) avec un indicateur de contrôle permissif comme `suffisamment` peut permettre à un mot de passe caché ou à un contournement de réussir avant même que l'authentification normale ne s'exécute. Étant donné que les fichiers PAM SSHD dépendent souvent d'inclusions (`@include common-auth`, `common-account`, etc.), les attaquants ciblent généralement ces fichiers partagés, ce qui leur permet d'avoir un impact sur l'ensemble du système, affectant SSH, sudo et la connexion, en une seule modification.

Fichiers pam_*.so sur notre machine virtuelle de laboratoire

Une autre technique courante consiste à détourner des modules légitimes tels que pam_exec.so pour exécuter un script lors de la connexion, permettant ainsi la récupération d'identifiants ou l'exécution silencieuse de commandes sans installer de logiciel malveillant visible. Dans des cas plus sophistiqués, les attaquants peuvent introduire un module pam_*.so personnalisé qui se fond avec les modules légitimes, assurant une persistance qui ne se déclenche que lors des événements d'authentification – ce qui le rend beaucoup plus furtif que les portes dérobées cron ou systemd classiques.

Que pouvons-nous apprendre sur PamDOORa à partir d'une publication sur le Dark Web ?

L'acteur malveillant vend un outil de post-exploitation qui suppose des privilèges root ; l'obtention d'un accès initial au serveur et des privilèges root fait donc partie des responsabilités de l'acheteur. Cet outil injecte une configuration PAM et un ou plusieurs fichiers .so permettant un accès SSH persistant au système compromis et la collecte des identifiants des utilisateurs légitimes.

Capture d'écran partagée par l'auteur de la menace

Déroulement de l'attaque : de la prise d'appui à la persistance à long terme

D’après les documents partagés, le flux opérationnel probable de PamDOORa est le suivant :

1. L'attaquant obtient un accès root à un serveur Linux via une faille de sécurité ou une méthode d'accès initiale distincte.
2. PamDOORa est déployé, injectant un module PAM malveillant dans la pile d'authentification.
3. La porte dérobée permet un accès SSH via un port TCP spécifique et une combinaison de mot de passe magique.
4. Toutes les informations d'identification légitimes des utilisateurs qui transitent par PAM sont capturées, chiffrées avec XOR et écrites dans /tmp avec des noms de fichiers et des horodatages générés dynamiquement.
5. Les journaux d'authentification (lastlog, btmp, utmp, wtmp) sont manipulés pour supprimer les traces de l'accès de l'attaquant.

Flux d'attaque PamDOORa

Ce que révèle l'accès à la porte dérobée de PamDOORa

L'auteur de la menace a partagé divers fichiers de code sur le forum. Le Makefile génère pam_linux.so au lieu de remplacer le fichier standard pam_unix.so, ce qui suggère que l'implant est conçu pour être chargé comme un module supplémentaire via des modifications de la configuration PAM plutôt que par le remplacement d'un fichier système.

Le fichier makefile

Accès contrôlé par porte dérobée via des déclencheurs réseau

L'accès par porte dérobée à PamDOORa se fait via un port TCP spécifique et un mot de passe secret. Ces informations sont indiquées dans le fichier README et dans la capture d'écran du code. 

Une routine similaire à procFindConnectionSocket énumère les descripteurs de fichiers sous /proc/[pid]/fd, résout les liens symboliques et examine les métadonnées des sockets (type, famille, protocole). Ceci permet au module d'associer une tentative d'authentification à une connexion réseau particulière et d'appliquer une logique conditionnelle en fonction de ses caractéristiques. Cette approche est plus stricte que les portes dérobées classiques, qui acceptent généralement toute connexion correspondant à un mot de passe. 

Extrait de connexion Socket TCP

Collecte d'identifiants au sein de PAM

PamDOORa offre non seulement un accès permanent au serveur, mais capture également les identifiants des utilisateurs lors des tentatives de connexion. Les données sont collectées et chiffrées par XOR à l'aide d'une clé générée dynamiquement. Les fichiers sont enregistrés dans le répertoire /tmp avec des noms et des horodatages générés de manière dynamique.

Bien que l'opération XOR ne soit pas conçue pour offrir une protection cryptographique robuste, elle constitue une couche d'évasion pratique contre l'inspection de contenu basique. La capture s'effectuant au sein de PAM, l'implant peut observer les identifiants présentés par les utilisateurs et administrateurs légitimes sans avoir besoin d'intercepter des applications de niveau supérieur.

Du point de vue de la défense, cela complique considérablement le processus de réponse aux incidents et de nettoyage des serveurs. Les identifiants de l'équipe de réponse aux incidents sont compromis dès qu'elle se connecte en SSH au serveur affecté pour mener l'enquête, renforçant ainsi le contrôle de l'attaquant sur la machine.

Anti-forensique : Manipulation de données et fonctionnement silencieux

Un autre facteur qui complique davantage les opérations de réponse aux incidents est la manipulation du fichier lastlog. D'après l'extrait de code observé, lastlog (et probablement d'autres journaux d'authentification tels que btmp, utmp et wtmp) est délibérément altéré afin d'effacer toute trace d'accès de l'attaquant. Ces journaux étant des éléments clés analysés lors des investigations de réponse aux incidents, leur falsification peut considérablement fausser la chronologie des événements et masquer leur véritable déroulement.

Nous avons également observé des signes d'exécution sélective (via PAM_IGNORE) et de déclenchements prenant en compte le réseau. L'implant est conçu pour laisser une empreinte numérique minimale en fonctionnement normal.

PAM ignore les hooks

Ce mélange de techniques furtives (hooks dormants, activation conditionnelle et falsification de journaux) reflète des schémas observés dans des outils de persistance Linux plus avancés.

Maturité du projet et organisation du code

La structure et les composants visibles sur les captures d'écran suggèrent que le projet est organisé et modulaire, reflétant potentiellement une implémentation plus aboutie qu'une simple preuve de concept.

La présence de composants anti-débogage indique des tentatives de détection ou d'entrave des environnements d'analyse. Associée à une modularisation et à un pipeline de construction, cette approche rapproche davantage les outils destinés aux opérateurs que les scripts standard.

Même lorsque les techniques sont individuellement familières (PAM hooks, capture d'identifiants, falsification de journaux), leur intégration dans un implant cohérent et configurable reflète une évolution vers des frameworks de persistance Linux maintenables et réutilisables.

Avertissement : Il est important de noter que cette porte dérobée a été analysée à partir d’une publication et de captures d’écran d’un acteur malveillant sur le dark web, et non par une analyse complète du code. Cela ne nous offre qu’une visibilité partielle sur la nature et le fonctionnement de l’outil.

Évaluation de la crédibilité de l'acteur menaçant et du marché

Rehub est un forum de cybercriminalité russophone qui a pris de l'importance après la perturbation des principales plateformes clandestines en 2025-2026, offrant un vaste marché pour le recrutement de spécialistes en Rançongiciels. accès initial ventes, logiciels malveillants et fraude. 

Bien qu'elle attire des acteurs variés (dont certains opérateurs compétents techniquement), la plateforme présente un niveau de sophistication inégal, avec de nombreux participants de niveau débutant à intermédiaire et une présence notable d'utilisateurs opportunistes. Sa facilité d'accès la rend accessible, mais contribue également à une plus grande prévalence d'escroqueries, de vendeurs peu fiables et de promesses exagérées. De ce fait, Rehub reflète un écosystème underground fragmenté où l'activité reste intense, mais où la confiance, la cohérence technique et la crédibilité sont nettement inférieures à celles des forums plus établis et accessibles uniquement sur invitation.

L'alias « ver noir »

Dans Flare, nous avons identifié 136 éléments associés à un acteur malveillant utilisant le pseudonyme « darkworm ». À ce stade, il est impossible d'attribuer avec certitude l'ensemble de l'activité à un seul individu ; chaque élément a donc été analysé avec soin et regroupé selon des critères tels que la chronologie, la langue, le domaine criminel et les capacités techniques. La diversité des activités suggère soit un acteur très opportuniste opérant dans plusieurs domaines, soit, plus probablement, plusieurs acteurs malveillants distincts réutilisant le même pseudonyme.

La diversité des activités suggère soit un acteur très opportuniste opérant dans plusieurs domaines, soit, plus probablement, plusieurs individus distincts réutilisant le même pseudonyme.

Historique des prix

Dans le message initial, l'auteur de la menace vend une seule copie du code source plutôt qu'un fichier binaire compilé.

Capture d'écran du message publié par l'auteur de la menace sur le forum

Après avoir surveillé l'activité de l'acteur malveillant sur Flare, nous avons constaté qu'il avait réduit le prix initial de près de 50 %, le faisant passer de 1 600 $ US à 900 $ US.

La publicité originale telle que capturée sur Flare

Le prix mis à jour tel qu'il apparaît sur Flare (Flare lien vers la publication, inscrivez-vous à essai gratuit(pour y accéder si vous n'êtes pas déjà client)

Bien que l'identification de cinq profils distincts opérant sous le même pseudonyme « darkworm » ne soit pas inhabituelle, elle souligne la difficulté d'attribution. Ce nom n'est pas unique et il est raisonnable de supposer que plusieurs acteurs malveillants peuvent adopter le même surnom, notamment lorsque certaines activités se chevauchent dans le temps. L'acteur associé à la vente de PamDOORa se distingue particulièrement : les extraits de code partagés semblent réalistes et techniquement plausibles, et les techniques décrites correspondent à des méthodes connues et réalisables. De ce fait, nous estimons que ce profil représente un acteur malveillant plus compétent techniquement et plus crédible que les autres.

Que savons-nous des autres portes dérobées PAM open source ?

Nous avons effectué une recherche sur GitHub et identifié 22 dépôts correspondant au terme « porte dérobée PAM ». La plupart de ces dépôts sont des projets d'exploitation de PAM, mais tous ne sont pas des « portes dérobées PAM Linux » au sens strict. Certains sont plutôt des outils de vol d'identifiants PAM ou des installateurs persistants PAM/SSH.

Tous ces outils partagent une approche commune consistant à tenter d'exploiter le processus d'authentification en remplaçant ou en complétant le comportement de PAM afin qu'un attaquant puisse se connecter avec un mot de passe magique, n'importe quel mot de passe, ou capturer les identifiants en clair. 

Portes dérobées PAM

• Le dépôt segmentati0nf4ult/linux-pam-backdoor : automatise la création d'un pam_unix.so avec porte dérobée, avec des versions testées pour PAM 1.2.0 et 1.3.0–1.4.0.
• Le dépôt ociredefz/pambd : un module PAM séparé (pambd.so) inséré dans la pile PAM.
• Le dépôt raj77in/pam_auth_backdoor indique explicitement qu'il s'agit d'un module PAM, donc n'importe quel mot de passe fonctionne.
• Le dépôt mrmoss/poovey : modules PAM pré-assemblés pour Linux/BSD avec code source inclus.
• Le dépôt flkn404/pamdoor : porte dérobée de style pam_unix patchée avec des mots de passe tournants d'une minute.
• Le dépôt radi0heap/dayofd00m : une simple porte dérobée PAM utilisant la chaîne de date actuelle comme mot de passe.

En lien avec PAM, au-delà d'une simple porte dérobée

• Le dépôt rek7/madlib contient un script Python qui automatise la compilation et le déploiement d'un fichier PAM modifié, mais enregistre également les identifiants, met à jour les hachages des paquets, horodate les fichiers, modifie la gestion SELinux et remplace les fichiers `/bin/false` et `/bin/nologin`. Il s'agit donc davantage d'un outil de persistance/gestion des identifiants après compromission que d'une simple porte dérobée PAM.
• Le dépôt flashnuke/ssh-door : porte dérobée SSH qui utilise l’injection d’objets partagés PAM, tout en indiquant explicitement qu’elle évite de modifier directement pam_unix.so. 
• Le dépôt wanmywan/duar-pamspy : outil de capture d’identifiants via PAM, axé sur la collecte et la livraison chiffrée plutôt que sur un simple chemin de connexion secret.
• Le dépôt hensitskyi/PAMinant : combine à la fois un enregistreur de mots de passe en clair et une porte dérobée PAM, et crédite même segmentati0nf4ult/linux-pam-backdoor pour la partie porte dérobée. 
• Le dépôt FlamingSpork/libpam_spooky contient des scripts bash qui modifient en continu la configuration PAM, permettant ainsi la connexion avec un mot de passe incorrect. Il s'agit d'une utilisation abusive de PAM, davantage une manipulation persistante de la configuration qu'un développement de module élégant. Ce dépôt est également compatible avec FreeBSD.

Les autres se sont révélés non pertinents.

Classification

Si nous classons ces outils, nous pouvons créer quatre familles :

• Corrigez ou remplacez pam_unix.so
• Charger un module PAM malveillant dans la pile
• Capture d'identifiants via PAM
• Enveloppes de persistance SSH ou PAM

L'analyse de la répartition du code révèle que la majorité est écrite en Shell. La qualité globale du code est faible à moyenne. De nombreux dépôts sont petits, anciens, peu maintenus, ou présentent un nombre minimal de contributions et peu ou pas d'étoiles. Plusieurs dépôts utilisent des correctifs rudimentaires ou le remplacement de fichiers de pam_unix.so, ce qui fonctionne en environnement de laboratoire, mais est difficilement applicable en production.

Bien que certains paraissent plus soignés car ils incluent une logique d'installation, des fonctionnalités anti-analyse forensique ou des notes sur l'environnement, ils ne sont pas nécessairement plus furtifs face aux outils de détection modernes.

Implications pour les défenseurs

Un outil de post-exploitation comme une porte dérobée de niveau PAM est problématique car il s'exécute dans l'une des couches les plus fiables du système d'exploitation, où les contrôles traditionnels axés sur les processus de l'espace utilisateur ou les binaires d'application sont souvent insuffisants. 

Les équipes de défense peuvent prioriser le déploiement de capacités de détection comportementale sur les systèmes de production et autres systèmes critiques, avec une visibilité sur les points de jonction sensibles tels que les piles PAM, les flux d'authentification SSHD, les hooks au niveau du noyau et les injections de fichiers ou de bibliothèques non autorisées.

La surveillance doit s'étendre au-delà des contrôles d'intégrité statiques pour inclure les signaux comportementaux d'exécution, tels que des modèles d'authentification inhabituels, des ports sources rares, un comportement de session incohérent ou des interactions anormales avec les composants d'authentification. 

Évitez toute falsification des journaux lors d'une réponse à un incident, car les attaquants opérant à ce niveau peuvent manipuler des artefacts tels que btmp, utmp, wtmp et lastlog, créant ainsi une piste d'investigation trompeuse ou incomplète. Les processus de réponse aux incidents peuvent anticiper une éventuelle falsification des journaux et s'appuyer, dans la mesure du possible, sur des sources de télémétrie redondantes.

Une approche de défense en profondeur, associée aux principes du modèle « zéro confiance », est essentielle pour limiter l’impact de telles compromissions. Les organisations peuvent considérer leur infrastructure d’authentification comme une zone à haut risque, en appliquant des contrôles d’accès stricts, une vérification continue et une segmentation.

Lors de la remédiation, les équipes de sécurité doivent partir du principe qu'un système compromis implique une exposition totale des identifiants. Les efforts de nettoyage doivent donc inclure la rotation des identifiants, la révocation des clés et le rétablissement de la confiance entre les systèmes affectés, plutôt que de se concentrer uniquement sur la suppression du dispositif implanté.