Les pirates parrainés par l'État russe **Turla** (également connu sous le nom de Secret Blizzard) ont considérablement amélioré leur backdoor **Kazuar**, le transformant en un botnet modulaire sophistiqué conçu pour la furtivité et la persistance. **Les liens de Turla avec le FSB** Selon l'Agence américaine de cybersécurité et de sécurité des infrastructures (**CISA**), **Turla** est affilié au Centre 16 du Service fédéral de sécurité russe (**FSB**). Le groupe est suivi sous divers noms, notamment ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard, Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug et WRAITH. Connu pour cibler les secteurs gouvernementaux, diplomatiques et de la défense en Europe et en Asie centrale, **Turla** cible également les points d'extrémité précédemment compromis par Aqua Blizzard (alias Actinium et Gamaredon) pour faire avancer ses objectifs stratégiques.  ### La transformation de Kazuar L'équipe de renseignement sur les menaces de **Microsoft** a noté que cette mise à niveau reflète l'objectif de Secret Blizzard de maintenir un accès système à long terme pour la collecte de renseignements. Au lieu de s'appuyer sur des outils natifs pour échapper à la détection, **Turla** intègre la résilience et la furtivité directement dans ses outils. **Kazuar**, un backdoor .NET actif depuis 2017, est passé d'un framework monolithique à un écosystème de bots modulaires. Cette nouvelle architecture comprend trois types de composants distincts : * Kernel * Bridge * Worker Chaque module a un rôle spécifique, permettant une configuration flexible, réduisant l'empreinte observable et rationalisant l'exécution des tâches.  _Aperçu des interactions des modules Kernel, Bridge et Worker_ ### Fonctions des modules La distribution du malware repose sur des droppers comme Pelmeni et ShadowLoader pour décrypter et lancer les modules. Les fonctions principales de chaque module sont : * **Kernel** : Le coordinateur central, qui émet des tâches aux modules Worker, gère la communication avec le Bridge, maintient les journaux, effectue des vérifications anti-analyse et anti-sandbox, et configure l'environnement. La configuration comprend des paramètres pour la communication de commande et de contrôle (C2), le calendrier d'exfiltration des données, la gestion des tâches, l'analyse des fichiers, la collecte et la surveillance. * **Bridge** : Agit comme un proxy entre le Kernel et le serveur C2. * **Worker** : Enregistre les frappes au clavier, intercepte les événements **Windows**, suit les tâches et collecte les informations système, les listes de fichiers et les détails de l'interface de programmation des applications de messagerie (**MAPI**). Le module Kernel utilise Windows Messaging, Mailslot et les pipes nommés pour la communication interne, et Exchange Web Services, HTTP et WebSockets pour la communication externe. Un seul leader Kernel est élu pour communiquer avec le module Bridge.  _Comment le leader Kernel coordonne le travail des Worker et utilise le Bridge_ ### Élection et Communication Les élections du leader Kernel ont lieu via Mailslot, basées sur le temps de fonctionnement divisé par le nombre d'interruptions. Le leader élu s'annonce, dirigeant les autres modules Kernel vers un mode silencieux. Cela permet au module Kernel leader de consigner l'activité et de demander des tâches via le module Bridge. Le module met également en place un canal de pipe nommé entre les modules Kernel et facilite la communication Kernel-à-Worker et Kernel-à-Bridge via la messagerie Windows ou Mailslot. Le Kernel interroge les nouvelles tâches auprès du serveur C2, analyse les messages, attribue des tâches au Worker, met à jour la configuration et renvoie les résultats des tâches au serveur. Un gestionnaire de tâches traite les commandes émises par le leader Kernel. Les données collectées par le Worker sont agrégées, cryptées et écrites dans un répertoire de travail avant d'être exfiltrées vers le serveur C2. ### Gestion organisée des données **Kazuar** utilise un répertoire de travail dédié comme zone de staging centralisée pour ses opérations internes. Ce répertoire est défini par la configuration et utilise des chemins complets pour éviter toute ambiguïté. Dans le répertoire de travail, **Kazuar** organise les données par fonction, isolant les tâches, les résultats de la collecte, les journaux et le matériel de configuration. Cette conception découple l'exécution des tâches du stockage et de l'exfiltration des données, maintient l'état opérationnel entre les redémarrages et coordonne l'activité asynchrone entre les modules tout en minimisant l'interaction directe avec l'infrastructure externe.