Von der russischen Regierung unterstützte Hacker **Turla** (auch bekannt als Secret Blizzard) haben ihre **Kazuar**-Backdoor erheblich verbessert und sie in ein hochentwickeltes, modulares Botnet für Tarnung und Persistenz verwandelt. **Turla's Verbindungen zur FSB** Laut der U.S. Cybersecurity and Infrastructure Security Agency (**CISA**) ist **Turla** mit dem Zentrum 16 des russischen Föderalen Sicherheitsdienstes (**FSB**) verbunden. Die Gruppe wird unter verschiedenen Namen verfolgt, darunter ATG26, Blue Python, Iron Hunter, Pensive Ursa, Secret Blizzard, Snake, SUMMIT, Uroburos, Venomous Bear, Waterbug und WRAITH. Bekannt für die gezielte Angriffe auf Regierungs-, Diplomaten- und Verteidigungssektoren in Europa und Zentralasien, zielt **Turla** auch auf Endpunkte ab, die zuvor von Aqua Blizzard (auch bekannt als Actinium und Gamaredon) kompromittiert wurden, um strategische Ziele weiter zu verfolgen.  ### Kazuar's Transformation Das Microsoft Threat Intelligence Team stellte fest, dass dieses Upgrade das Ziel von Secret Blizzard widerspiegelt, langfristigen Systemzugriff für die Informationsbeschaffung aufrechtzuerhalten. Anstatt sich auf native Tools zur Umgehung von Erkennungsmaßnahmen zu verlassen, bettet **Turla** Widerstandsfähigkeit und Tarnung direkt in seine Werkzeuge ein. **Kazuar**, eine .NET-Backdoor, die seit 2017 aktiv ist, hat sich von einem monolithischen Framework zu einem modularen Bot-Ökosystem entwickelt. Diese neue Architektur verfügt über drei verschiedene Komponententypen: * Kernel * Bridge * Worker Jedes Modul hat eine spezifische Rolle, die eine flexible Konfiguration, die Reduzierung der beobachtbaren Fußabdrücke und die Optimierung der Aufgabenausführung ermöglicht.  _Übersicht über die Interaktionen der Kernel-, Bridge- und Worker-Module_ ### Modulfunktionen Die Malware-Verteilung beruht auf Droppern wie Pelmeni und ShadowLoader, um die Module zu entschlüsseln und zu starten. Die Kernfunktionen jedes Moduls sind: * **Kernel**: Der zentrale Koordinator, der Aufgaben an die Worker-Module ausgibt, die Kommunikation mit der Bridge verwaltet, Protokolle führt, Anti-Analyse- und Sandbox-Prüfungen durchführt und die Umgebung konfiguriert. Die Konfiguration umfasst Parameter für die Command-and-Control (C2)-Kommunikation, den Zeitpunkt der Datenexfiltration, die Aufgabenverwaltung, die Dateiprüfung, die Sammlung und die Überwachung. * **Bridge**: Fungiert als Proxy zwischen dem Kernel und dem C2-Server. * **Worker**: Protokolliert Tastatureingaben, fängt **Windows**-Ereignisse ab, verfolgt Aufgaben und sammelt Systeminformationen, Dateilisten und Details der Messaging Application Programming Interface (**MAPI**). Das Kernel-Modul verwendet Windows Messaging, Mailslot und benannte Pipes für die interne Kommunikation sowie Exchange Web Services, HTTP und WebSockets für die externe Kommunikation. Ein einzelner Kernel-Leader wird gewählt, um mit dem Bridge-Modul zu kommunizieren.  _Wie der Kernel-Leader die Worker-Aufgaben koordiniert und die Bridge nutzt_ ### Wahl und Kommunikation Kernel-Leader-Wahlen finden über Mailslot statt, basierend auf der Betriebszeit geteilt durch Interrupts. Der gewählte Leader gibt sich selbst bekannt und weist andere Kernel-Module an, in einen Stumm-Modus zu wechseln. Dies ermöglicht es dem führenden Kernel-Modul, Aktivitäten zu protokollieren und Aufgaben über das Bridge-Modul anzufordern. Das Modul richtet auch einen benannten Pipe-Kanal zwischen den Kernel-Modulen ein und erleichtert die Kernel-zu-Worker- und Kernel-zu-Bridge-Kommunikation über Windows Messaging oder Mailslot. Der Kernel fragt neue Aufgaben vom C2-Server ab, analysiert Nachrichten, weist Aufgaben dem Worker zu, aktualisiert die Konfiguration und sendet Aufgabenergebnisse zurück an den Server. Ein Task-Handler verarbeitet Befehle, die vom Kernel-Leader ausgegeben werden. Von den Workern gesammelte Daten werden aggregiert, verschlüsselt und in ein Arbeitsverzeichnis geschrieben, bevor sie an den C2-Server exfiltriert werden. ### Organisierte Datenverarbeitung **Kazuar** verwendet ein dediziertes Arbeitsverzeichnis als zentralen Staging-Bereich für seine internen Operationen. Dieses Verzeichnis wird über die Konfiguration definiert und verwendet vollständig qualifizierte Pfade, um Mehrdeutigkeiten zu vermeiden. Innerhalb des Arbeitsverzeichnisses organisiert **Kazuar** Daten nach Funktion und isoliert Aufgaben, Sammlungsausgaben, Protokolle und Konfigurationsmaterial. Dieses Design entkoppelt die Aufgabenausführung von der Datenspeicherung und -exfiltration, erhält den Betriebszustand über Neustarts hinweg und koordiniert asynchrone Aktivitäten zwischen den Modulen, während die direkte Interaktion mit externer Infrastruktur minimiert wird.