DEEP#DOOR : backdoor Python qui pille SSH, cloud et Wi-Fi

Ce qui s'est passé

L'équipe Securonix Threat Research a publié le 30 avril 2026 un rapport détaillé sur une nouvelle campagne baptisée DEEP#DOOR, qui s'appuie sur un backdoor Python conçu pour évader durablement les détections sur les hôtes Windows. La campagne semble cibler en priorité les développeurs et les administrateurs systèmes ayant des accès privilégiés à des environnements cloud, avec une charge utile spécifiquement orientée vers le vol de credentials de production. Securonix, qui a observé les premières infections fin mars 2026 chez plusieurs clients, n'a pas formellement attribué la campagne à un groupe connu, mais note des chevauchements techniques avec une opération précédemment surnommée DarkPython et observée fin 2024 contre des entreprises du secteur fintech aux États-Unis.

L'infection débute par un script batch obfusqué, généralement livré via un email de spear-phishing thématique RH (faux contrats freelance, factures de prestataires, notes de frais) ou via un téléchargement drive-by depuis un site WordPress compromis. Le script déchiffre puis exécute un payload Python intégré directement dans le dropper sous forme de chaîne base64, sans téléchargement réseau intermédiaire. Cette approche auto-contenue réduit les indicateurs réseau exploitables par les NDR et permet à DEEP#DOOR de reconstruire son payload à la fois en mémoire et sur disque pendant son exécution, ce qui complique l'analyse forensique post-incident.

La persistance est assurée via trois mécanismes redondants. Le malware crée un raccourci dans le dossier de démarrage utilisateur, ajoute une clé Run dans HKCU\Software\Microsoft\Windows\CurrentVersion\Run, et planifie une tâche Windows déguisée en mise à jour Microsoft Office. Cette redondance signifie que la suppression d'un seul vecteur de persistance ne suffit pas : un nettoyage complet doit cibler les trois mécanismes simultanément, faute de quoi le backdoor se relance au redémarrage. Securonix note également que le malware horodate ses fichiers persistants pour qu'ils correspondent à la date de création des fichiers système Windows légitimes du même répertoire, technique connue sous le nom de timestomp qui empêche les triages chronologiques de remonter à l'infection initiale.

L'arsenal d'évasion est particulièrement complet. DEEP#DOOR patche AMSI (Antimalware Scan Interface) et ETW (Event Tracing for Windows) en mémoire pour empêcher Defender et les EDR d'inspecter les commandes PowerShell ou les appels d'API critiques. Le malware procède également à l'unhooking de ntdll.dll, technique consistant à recharger une copie propre de la DLL système depuis le disque pour neutraliser les hooks placés par les EDR commerciaux. La détection de sandbox combine plusieurs vérifications : analyse de la résolution écran, du nombre de cœurs CPU, de la présence de processus VMware/VirtualBox, et de la durée écoulée depuis le démarrage de la machine. Si l'environnement est suspect, le payload reste dormant et n'exfiltre aucune donnée, contournant ainsi les analyses automatiques en bac à sable.

Le canal de commande et de contrôle constitue l'innovation principale de DEEP#DOOR. Le backdoor utilise bore.pub, un service de tunneling open source destiné à exposer des services locaux à Internet pour faciliter le développement et le debugging à distance. En détournant ce service, les opérateurs de DEEP#DOOR atteignent les machines compromises sans devoir maintenir une infrastructure C2 traditionnelle exposée publiquement, et profitent d'une connexion sortante sortant légitime vers bore.pub qui sera typiquement laissée passer par les firewalls. La rotation rapide des tunnels et l'absence de domaine fixe rendent le takedown difficile et brouillent l'attribution. Le rapport Securonix indique que les premiers tunnels observés étaient hébergés depuis des conteneurs sur Hetzner et OVH, mais la nature open source de bore.pub permet aux attaquants de héberger leur propre instance à volonté.

Une fois actif, le backdoor offre des capacités complètes de surveillance et d'exfiltration. Le keylogging capture toutes les frappes clavier dans tous les processus utilisateur, y compris les saisies dans les gestionnaires de mots de passe et les navigateurs. Le module clipboard surveille en continu le presse-papiers et exfiltre tout contenu correspondant à des patterns sensibles (adresses crypto, JWT, clés AWS, mots de passe). Des screenshots sont pris toutes les 30 secondes et compressés en JPEG basse qualité pour réduire la bande passante d'exfiltration. Le module de browser harvesting cible Chrome, Edge, Firefox, Brave et Opera, en extrayant directement les bases de données SQLite contenant les cookies de session, les mots de passe enregistrés et l'historique de navigation. Sur Edge en particulier, le malware exploite la nouvelle API Windows Hello bypass découverte début 2026 pour décrypter les credentials sans nécessiter d'interaction utilisateur.

Le module SSH harvesting copie l'intégralité du dossier ~/.ssh/, y compris les clés privées non protégées par passphrase. Pour les clés protégées, le malware tente une attaque par dictionnaire sur les passphrases courantes en arrière-plan. Le module Wi-Fi extrait les SSID enregistrés et leurs mots de passe via la commande netsh wlan show profile name="X" key=clear, fournissant aux attaquants un accès potentiel aux réseaux corporates et résidentiels fréquentés par la victime. Enfin, le module cloud harvest balaie les fichiers credentials AWS, GCP, Azure CLI, kubeconfig, ainsi que les fichiers .env dans les répertoires de projet identifiés par la présence de package.json, requirements.txt ou Dockerfile.

L'effacement des traces est réalisé en deux étapes. Pendant l'exécution, le malware tient un journal interne de ses actions qu'il chiffre en mémoire pour faciliter le debugging par ses opérateurs, journal jamais écrit sur disque. À la fin de chaque session, ou périodiquement, le backdoor exécute wevtutil cl Security, wevtutil cl Application et wevtutil cl System, effaçant les trois principaux journaux d'événements Windows. La ligne de commande qui a lancé le payload est également wipée du registre via la suppression de la clé RecentDocs et l'effacement des entrées MUICache. Cette combinaison rend l'analyse forensique post-incident particulièrement laborieuse et nécessite le recours à des outils tiers comme Velociraptor ou KAPE pour reconstituer la timeline d'attaque.

Pourquoi c'est important

DEEP#DOOR illustre la convergence inquiétante entre les techniques traditionnellement réservées aux groupes APT et l'outillage criminel grand public. Le patching AMSI/ETW, le désassemblage de ntdll, l'usage de tunnels légitimes pour le C2 et la détection avancée de sandbox étaient encore, il y a deux ans, l'apanage des opérations étatiques de haut niveau. Les retrouver assemblés dans un backdoor probablement développé par un acteur criminel signale un transfert de compétences accéléré, vraisemblablement entretenu par la circulation de tutoriels détaillés sur des forums underground et par l'usage croissant d'assistants IA pour générer du code d'évasion. Les défenseurs doivent désormais considérer que le niveau technique des attaquants moyens a structurellement augmenté.

L'exploitation de bore.pub comme canal C2 mérite une attention particulière de la part des équipes SOC. La pratique consistant à filtrer le trafic sortant uniquement par catégories de réputation devient inopérante face à des services de tunneling légitimes utilisés à mauvais escient. La même logique s'applique à ngrok, à Cloudflare Tunnels (Argo), à Tailscale et à plusieurs autres outils dont l'usage normal en développement masque les emplois malveillants. La recommandation pratique est de bloquer par défaut tout trafic vers ces services en environnement de production, et de n'autoriser leur usage qu'au cas par cas en environnement de développement avec journalisation explicite.

Le ciblage explicite des credentials cloud, kubeconfig et clés SSH place DEEP#DOOR dans la catégorie des malwares destinés à servir de tête de pont vers une intrusion d'envergure. Les attaquants ne cherchent pas à monétiser directement les machines infectées, mais à collecter le matériel d'authentification permettant un mouvement latéral ultérieur vers les infrastructures les plus précieuses des organisations. Ce mode opératoire est typique des courtiers d'accès initiaux (Initial Access Brokers) qui revendent ensuite les accès collectés à des opérateurs de ransomware comme Qilin, ALPHV-successors ou les groupes émergents observés en 2026. Le délai entre infection initiale et déclenchement du ransomware est en moyenne de 23 jours selon le dernier rapport Mandiant M-Trends, ce qui laisse une fenêtre de détection encore exploitable mais impose une chasse proactive aux indicateurs de compromission.

Pour les équipes SOC, l'incident impose plusieurs ajustements concrets. La détection des modifications du dossier de démarrage utilisateur et des clés Run du registre HKCU doit être instrumentée avec une corrélation cross-source, en particulier sur les machines hébergeant des secrets de production. La surveillance de l'usage anormal de bore.pub, ngrok et services de tunneling similaires doit être activée dans les SIEM, avec génération d'alertes sur tout trafic sortant vers ces domaines depuis des postes utilisateurs ou des serveurs d'application. Enfin, la rotation périodique automatisée des credentials cloud et SSH, avec des durées de vie courtes (15 à 30 minutes pour les jetons, 90 jours maximum pour les clés SSH), réduit drastiquement la valeur des données exfiltrées par ce type de backdoor.

Ce qu'il faut retenir

• Bloquez par défaut le trafic sortant vers bore.pub, ngrok, Cloudflare Tunnels et Tailscale depuis les environnements de production et générez des alertes SIEM sur toute connexion détectée.
• Activez la surveillance temps réel des modifications du dossier de démarrage utilisateur, des clés HKCU\Software\Microsoft\Windows\CurrentVersion\Run, et des tâches planifiées créées hors maintenance.
• Imposez une rotation automatique courte (15-30 minutes) des credentials cloud via federation OIDC ou IAM Roles Anywhere, plutôt que des access keys persistantes stockées en clair.
• Déployez un EDR avec protection AMSI et ETW renforcée, et désactivez la possibilité pour les utilisateurs standards d'exécuter des scripts batch ou PowerShell non signés.