Depuis janvier 2025, deux nouvelles portes dérobées, OctLurk et SilkLurk, ont été observées lors d’attaques visant principalement des organisations gouvernementales en Asie centrale. Les victimes identifiées sont notamment situées en Afghanistan, au Kirghizistan, au Tadjikistan, en Ouzbékistan, au Kazakhstan, ainsi que dans la République arabe syrienne. Les secteurs touchés couvrent des domaines sensibles, comme la santé, la recherche, les ministères, la logistique, certaines autorités d’application de la loi, et aussi des établissements publics d’enseignement.
Ce qui rend ces implants particulièrement préoccupants, c’est leur personnalisation par victime et leur niveau élevé d’obfuscation. De plus, ils sont conçus pour télécharger et injecter des modules additionnels afin d’étendre rapidement les capacités malveillantes sur les machines compromises. Dans ce contexte, OctLurk et SilkLurk illustrent une chaîne d’intrusion orientée vers la persistance, la collecte de renseignements et le contrôle à distance.
Deux implants, une même logique d’attaque
Les analyses montrent que l’acteur responsable a probablement opéré à la fois SilkLurk et OctLurk. Des cas ont été observés où des machines déjà infectées par SilkLurk contenaient aussi OctLurk, ce qui suggère une exploitation conjointe de plusieurs implants. L’attribution précise n’a pas pu être confirmée à l’époque de la publication, mais l’enquête indique une orientation linguistique cohérente et une activité d’ensemble pilotée par le même acteur.
Techniquement, les loaders et les backdoors s’appuient sur des mécanismes de chiffrement et de compression pour masquer le contenu. Les données sont fréquemment protégées avant d’être déchiffrées et exécutées, ce qui complique le travail d’analyse statique et dynamique.
Déploiement d’OctLurk : tâches planifiées et chargement en mémoire
Pour installer OctLurk, l’attaquant crée une tâche planifiée à distance nommée GoogleUpDate, en s’appuyant sur des identifiants administrateur. La tâche s’exécute une seule fois, avec des privilèges du compte System, juste après sa création, puis exécute un script batch stocké dans un chemin utilisateur sur la machine distante.
Avant de lancer le script, l’attaquant vérifie l’état de la tâche. Ensuite, le script génère un service dont la configuration pointe vers une bibliothèque DLL servant de loader. Cette DLL expose des points d’entrée conçus pour déclencher le traitement malveillant, dont la phase centrale consiste à récupérer et déchiffrer un payload.
Une chaîne de déchiffrement : double XOR et décompression
Le loader d’OctLurk expose notamment des méthodes de type Refresh et RegisterService. Le flux commence par la récupération d’un chemin de payload, obtenu en double déchiffrement puis décompression. Les octets du payload suivent le même principe : une protection par double XOR et une décompression via zlib.
Les clés du chiffrement sont distinctes : la première est intégrée dans le loader, tandis que la seconde est dérivée du numéro de série du disque C:. Une fois le contenu récupéré, la backdoor est injectée de manière réfléchie (reflective injection) en mémoire, puis son point d’entrée est exécuté. Enfin, le loader peut appeler des fonctions exportées par la backdoor, soit via nom, soit via ordinal, selon des informations chiffrées présentes dans le loader.
Le backdoor OctLurk : collecte de données et communication chiffrée
Après installation, OctLurk établit une communication réseau vers un serveur de commande et contrôle. La backdoor crée un socket réseau, puis collecte un ensemble d’informations sur la machine victime, telles que la version du système, le nom de l’ordinateur, le nom d’utilisateur, ainsi qu’une représentation de l’adresse IP locale.
Avant d’envoyer ces informations, la backdoor applique un chiffrement à base de XOR combinant une clé statique intégrée au code et une seconde clé générée de façon aléatoire (un bloc de 83 octets dans les échantillons observés). Ensuite, les données collectées sont d’abord comprimées avec zlib, puis chiffrées deux fois selon la séquence attendue.
Le protocole de communication inclut des en-têtes de taille et des champs structurés, ce qui permet au serveur de déterminer la taille des paquets et de reconstruire les données. Les messages reçus subissent à leur tour un double déchiffrement, puis une décompression, afin d’obtenir soit une commande, soit du code de plugin.
Plugins et actions : de l’exécution de commandes au vol de secrets
Un élément central de OctLurk et SilkLurk est la capacité à étendre les fonctions via des plugins chargés directement en mémoire depuis le serveur. Les plugins observés couvrent notamment :
- Command Shell : ouverture d’un interpréteur de commandes pour exécuter des instructions à distance.
- File Manager : interaction avec le système de fichiers.
- Interaction Manager : synthèse d’événements clavier et souris.
Au-delà du contrôle, les actions post-compromission décrivent une démarche orientée vers le renseignement et l’augmentation des privilèges. Les attaquants utilisent par exemple la collecte d’informations matérielles et logicielles (hardware/software/network) afin de dresser une empreinte (fingerprinting) de la machine.
Exemples d’activités observées après compromission
Dans les scénarios étudiés, l’acteur met en œuvre plusieurs mécanismes :
- Collecte d’événements : export d’événements liés à des connexions de type interactive à distance, puis filtrage par utilisateurs.
- Récupération d’identifiants : usage d’une version portable d’un outil dérivé de secretsdump afin d’extraire des hachages depuis des contrôleurs de domaine, puis identification des membres d’un groupe de serveurs.
- Keylogging : déploiement d’un enregistreur de frappes exécuté via une tâche planifiée, avec stockage local de frappes et capture de presse-papiers.
- Vol de mots de passe de navigateurs : extraction de données de connexion depuis Chrome et Firefox en ciblant des bases locales, puis exploitation de la clé nécessaire au déchiffrement dans les structures propres à chaque navigateur.
- Accès distant : installation d’un agent de contrôle (Pandora RC agent), exécuté via une tâche planifiée et paramétré pour démarrer après installation.
- Scan réseau : déploiement d’un outil de découverte interne, permettant d’identifier des services sur des ports spécifiques et d’attaquer certains services avec des identifiants présents dans un fichier.
- Collecte d’e-mails : requêtes vers un serveur de messagerie via une commande de type curl pour authentifier, sélectionner le dossier boîte de réception, puis préparer la lecture/manipulation.
Ce panorama montre une utilisation progressive des capacités : commencer par établir la persistance et le contrôle, puis passer à l’exfiltration de données et à l’élargissement des possibilités d’attaque sur le réseau.
LurkProxy : un intermédiaire réseau lié à OctLurk
Les analyses décrivent aussi un composant spécialisé nommé LurkProxy. Cet outil n’est pas présenté comme une porte dérobée à proprement parler, mais comme une brique destinée à proxer du trafic réseau. Son architecture est décrite comme proche de celle d’OctLurk, avec une logique de charge et d’obfuscation similaire.
Une fois exécuté, LurkProxy écoute sur une interface locale à un port codé en dur, puis établit une connexion TLS vers un serveur de commande et contrôle. Les paquets utilisent un protocole binaire propriétaire : compression avec zlib, chiffrement par double XOR, et structure de paquets permettant la redirection.
Le proxy peut fonctionner selon deux modes : un mode de type SOCKS5, qui annonce l’adresse cible au serveur, ou un mode transparent où l’adresse et le port cibles sont fixés. Dans l’exemple examiné, le mode SOCKS5 est celui utilisé.
Déploiement de SilkLurk : chargement latéral via binaires légitimes
Alors qu’OctLurk s’appuie notamment sur des tâches planifiées et des services liés à un loader, SilkLurk suit une approche différente : l’attaquant exécute des binaires légitimes afin de réaliser un side-loading de DLL malveillantes. Autrement dit, des exécutables réels (associés à des outils ou composants visibles côté système) sont utilisés comme vecteurs pour charger des bibliothèques qui, ensuite, injectent SilkLurk dans la mémoire du processus.
Les DLL chargées portent des noms compatibles avec la logique des exécutables hôtes, et servent de loaders qui injectent ensuite la backdoor.
Un payload déplacé, puis une persistance par service
Le loader SilkLurk vérifie d’abord qu’il s’exécute bien dans le contexte prévu par l’exécutable légitime. Ensuite, il déplace un fichier de payload (dans l’échantillon analysé, un nom de type OneDrive.dat) d’un emplacement interne du module vers une destination codée en dur.
Par la suite, il crée un service nommé RmSs afin d’assurer la persistance. Le service lance un binaire légitime qui charge la DLL malveillante correspondante. Le service est configuré pour redémarrer en cas d’échec, renforçant la résilience.
Le cœur de SilkLurk : décryptage lié à chaque machine
Le loader SilkLurk rend la charge plus difficile à analyser en la rendant spécifique à la victime. Il calcule une valeur de hachage 32 bits à partir du nom de l’ordinateur, puis utilise cette valeur via un algorithme personnalisé pour déchiffrer le chemin du payload et les octets de celui-ci.
Le shellcode déchiffré inclut une logique de décryptage et d’injection du blob de backdoor en mémoire. Le code manipule aussi les en-têtes PE (par exemple en masquant certains champs), puis déchiffre des sections avant l’injection. Les noms de DLL et d’API sont déchiffrés avec une clé à octet unique, et les chaînes sont effacées ensuite pour réduire la visibilité.
Enfin, la phase de relocation utilise à nouveau le hachage du nom de la machine, et l’entrée de point du code est déchiffrée avant exécution.
Backdoor SilkLurk : configuration chiffrée et protocole réseau
La backdoor SilkLurk contient une configuration chiffrée stockée dans un emplacement et un nom de fichier codés en dur (variable selon les échantillons) dans le répertoire %APPDATA%. Elle inclut aussi une chaîne utilisée comme mutex, afin de limiter certaines exécutions concurrentes.
La backdoor établit ensuite une connexion TCP vers le serveur de commande et contrôle défini dans la configuration. Si des détails de proxy existent, la connexion peut passer par un intermédiaire. Après connexion, elle génère une clé réseau aléatoire de 32 octets, puis prépare des paquets chiffrés via un algorithme personnalisé, distinct de ceux utilisés pour déchiffrer la configuration.
Avant l’échange de commandes, elle collecte des informations de la victime : nom local, domaine DNS, nom d’utilisateur de session, architecture CPU, version du système, adresse IP, identifiant de processus, valeur de tick count, et nom du module de la backdoor. Ces données sont compressées puis chiffrées avec la clé réseau, puis envoyées sous forme structurée.
Le serveur répond avec une trame chiffrée qui déclenche ensuite des opérations selon un champ de type message contenu dans l’en-tête.
Pourquoi cette campagne compte
OctLurk et SilkLurk illustrent une combinaison de techniques visant la furtivité et l’efficacité opérationnelle : intégration d’informations de contexte pour déverrouiller le payload, offuscation poussée, exécution en mémoire, persistance via services ou tâches planifiées, et extension par plugins ou modules. En parallèle, la nature des actions observées (collecte d’identifiants, keylogging, extraction de mots de passe navigateur, scan réseau, interaction avec la messagerie) montre une intention d’espionnage et de préparation à des mouvements ultérieurs.
Pour les équipes défense, ces observations renforcent l’importance de surveiller les comportements typiques : création de tâches planifiées, déploiement de services inattendus, chargements latéraux de DLL, exécutions depuis des répertoires temporaires ou publiques, ainsi que les communications réseau vers des domaines et adresses codés en dur.
Conclusion
Les campagnes observées autour de OctLurk et SilkLurk mettent en évidence des implants conçus pour fonctionner en profondeur sur des environnements gouvernementaux. D’un côté, OctLurk privilégie une chaîne de déchiffrement par double XOR, une injection réfléchie et des plugins chargés en mémoire pour exécuter des commandes et voler des données. De l’autre, SilkLurk mise sur le side-loading de DLL via des binaires légitimes, une décryption liée au nom de la machine et un protocole réseau chiffré pour piloter l’activité.
Au final, ces deux portes dérobées montrent comment des attaquants peuvent adapter leurs outils à chaque cible, étendre rapidement leurs capacités après compromission et maintenir un contrôle durable sur le réseau.
Source: https://securelist.com/octlurk-silklurk-backdoors-central-asia/120840/
