Seit Januar 2025 beobachten Forschende zwei neue Schadprogramme: OctLurk und SilkLurk. Die Backdoors wurden in Angriffen gegen Organisationen mit Schwerpunkt in Zentralasien festgestellt. Betroffen sind unter anderem Einrichtungen in Afghanistan, Kasachstan, Kirgistan, Tadschikistan, Usbekistan sowie auch im Syrian Arab Republic. Besonders auffällig: Die Angriffe richteten sich nicht nur auf klassische IT-Umgebungen, sondern auch auf Bereiche wie Gesundheitswesen, Forschung, Ministerien, Logistik, Strafverfolgung, Stadtplanung und Bildungseinrichtungen.
Obwohl die konkreten Bezeichnungen der Hintertüren im Fokus stehen, steckt dahinter vor allem eines: ein klarer Wille der Angreifer, sich möglichst lange im Netzwerk zu halten, später weitere Module nachzuladen und dabei Technik zu nutzen, die Analyse erschwert. In diesem Beitrag fassen wir die wichtigsten Erkenntnisse zusammen – von der Erstplatzierung über Verschleierung und Entschlüsselung bis hin zu Aktivitäten nach erfolgreicher Kompromittierung.
Wie OctLurk und SilkLurk eingesetzt werden
Die Forschenden ordnen OctLurk und SilkLurk als eng verwandte Backdoors ein. In der Untersuchung zeigte sich, dass zumindest teilweise dieselbe Bedrohungsakteurs-Logik dahintersteckt: Manche Opfer, die mit SilkLurk infiziert waren, enthielten gleichzeitig auch OctLurk.
Die Belege reichen allerdings nur für eine mittelgradige Einschätzung der Urheberschaft. Zum Zeitpunkt der Veröffentlichung konnte die Kampagne nicht eindeutig einem bekannten Kollektiv zugeordnet werden. Weiterhin gehen die Analysten davon aus, dass der Akteur chinesischsprachig ist.
Stark verschleierte Loader und anpassbare Payloads
Ein zentrales Muster betrifft die Loader-Komponente. Beide Systeme nutzen eine stark verschleierte Implementierung. Dadurch wird es für Analysten deutlich schwieriger, Codepfade sauber nachzuverfolgen oder die Payloads direkt zu extrahieren.
Zusätzlich wird die Auslieferung offenbar auf das konkrete Ziel zugeschnitten. Der Loader greift auf Informationen vom kompromittierten System zurück, um die eigentliche Schadkomponente zu entschlüsseln. Für OctLurk beschrieben die Forschenden beispielsweise eine Entschlüsselung, die auf einem System-spezifischen Wert basiert, etwa der Signatur/Seriennummer der Systempartition.
Auch bei den Entschlüsselungsschritten selbst arbeiten die Angreifer mehrstufig: Es kommen mehrere XOR-Schichten und zudem ein zlib-Dekompressionsschritt zum Einsatz. Je nach Phase werden erst fest eincodierte Bytefolgen zu verwertbaren Bestandteilen gemacht, und anschließend werden daraus die Backdoor-Bibliotheken bzw. deren Einstiegspunkte abgeleitet.
OctLurk: Einstieg über geplante Aufgaben und Service-Sideloading
Für OctLurk beobachteten die Forschenden eine typische Persistenz- und Ausführungsstrategie. Der Angreifer erstellt auf entfernten Maschinen eine geplante Aufgabe, die mit Administratorkontext und dann als System läuft. Konkret wird die Task mit einem Namen im Sinne von GoogleUpDate angelegt, führt nach dem Erstellen einmalig ein Batch-Skript aus und fragt vorher den Status der Aufgabe ab.
Das Batch-Skript legt anschließend einen Service an und nutzt dafür eine Loader-DLL, die zuvor ebenfalls identifiziert werden konnte. Über die Servicekonfiguration wird eine Funktion angestoßen, die wiederum in die eigentliche Entschlüsselungslogik übergeht. Damit wird aus einer einfachen Startkette eine komplette Installations- und Ausführungsstrecke.
LurkProxy als spezielles Zusatztool
In einem weiteren Fall wurde ebenfalls eine Komponente eingesetzt, die die Analysten LurkProxy nannten. Diese ist nicht selbst als Backdoor klassifiziert, verfolgt aber eine ähnliche technische Grundstruktur wie OctLurk. Ihre zentrale Aufgabe: Proxyrouting bzw. das Weiterreichen von Netzwerkverkehr.
Die Forschenden konnten dabei erkennen, dass der Akteur zunächst die Erreichbarkeit eines bestimmten Domains-Endpoints prüft, der zur Kommunikationsinfrastruktur führt. Nach erfolgreicher Prüfung wird ein weiteres Skript ausgeführt, das wiederum einen Service startet und eine passende DLL lädt.
Für die Analyse relevant ist vor allem, dass LurkProxy über einen eigenen TLS-verschlüsselten Kanal mit dem C2-Server kommuniziert. Die Pakete werden dabei komprimiert und mit einem mehrstufigen XOR-Verfahren geschützt.
OctLurk Backdoor: Systemdaten, Verschlüsselung und dynamische Befehle
Die Backdoor-Komponente baut eine Netzwerkverbindung zu einem fest eincodierten C2-Endpunkt auf (über Port 443). Zunächst sammelt sie Fingerprint-Informationen, darunter Betriebssystemdetails, Rechner- und Benutzernamen sowie lokale Netzwerkangaben.
Zusätzlich wird auch der lokale Zeitstempel und die Prozess-/Host-Umgebung berücksichtigt. Damit können Angreifer spätere Entscheidungen für weitere Aktionen präziser treffen.
Für den Schutz der gesammelten Daten nutzt die Backdoor mehrere Verschlüsselungsschichten: Die Informationen werden zuerst komprimiert und dann mehrfach per XOR geschützt – einmal mit einem fest eincodierten String-Schlüssel und zusätzlich mit einem zufällig generierten Bytebereich.
Beim Empfang der Befehle folgt ein weiteres Protokollmuster: Pakete enthalten Größenfelder, die erlauben, die nachfolgenden Datenblöcke zu rekonstruieren. Die Befehle bzw. Module werden wiederum entschlüsselt und anschließend zlib-dekomprimiert. Danach können sie als Kommando- oder Plugincode interpretiert werden.
Plugins für weitere Kompromittierung
OctLurk lädt Plugins direkt aus der C2-Infrastruktur in den Speicher. Jedes Plugin stellt dabei mehrere exportierte Methoden bereit, wobei die eigentliche Logik in einer zentralen Funktion liegt.
Die Forschenden nennen mehrere häufig eingesetzte Plugin-Typen:
- Command Shell (stellt eine Kommando-Shell bereit)
- File Manager (führt Dateisystem-Aktionen aus)
- Interaction Manager (synthetisiert Tastatur- und Mauseingaben)
Damit kann die Malware nach der ersten Infektion nicht nur Daten abgreifen, sondern auch interaktiv wirkende Steueraktionen im Zielsystem anstoßen – je nach C2-Kommandos.
Aktivitäten nach der Kompromittierung: vom Fingerprinting bis zum Credential Dumping
Nachdem der Angreifer die Kontrolle hergestellt hat, folgt eine strukturierte Phase der Sammlung und Ausweitung.
Victim Fingerprinting und Eventlog-Sammlung
Ein wiederkehrendes Muster ist das Anlegen geplanter Aufgaben auf entfernten Systemen mit Systemprivilegien. Die zugehörigen Skripte führen anschließend mehrere Befehle aus, die Hardware-, Software- und Netzwerkdetails erfassen. Die Ergebnisse werden dabei in mehreren Dateien im temporären Verzeichnis abgelegt.
Außerdem werden Protokolle ausgewertet, insbesondere erfolgreiche Anmeldungen für Remote-Interaktionen. Dazu gehören Remote-Desktop-nahe Szenarien. Solche Daten helfen, konkrete Konten und Zugriffswege zu identifizieren.
Credential Harvesting mit Impacket secretsdump
Für das Auslesen von Passworthashes verwendeten die Angreifer eine portable Version von Impacket secretsdump. Das Ziel waren dabei Domänencontroller sowie die kritischen Server innerhalb einer Active-Directory-Umgebung.
Nach dem Hash-Export wurde zudem ein Befehl ausgeführt, um alle Mitglieder der Gruppe „Domain Controllers“ aufzulisten. Praktisch bedeutet das: Der Angreifer versucht, weitere zentrale Systeme zu identifizieren und potenziell als Nächstes zu kompromittieren.
Keylogging und Browserpasswort-Auskopplung
Weiterhin wurde ein Keylogger eingesetzt. Die Forschenden beschreiben, dass der Keylogger Dateien anlegt, in denen getippte Eingaben sowie Zwischenablagedaten abgelegt werden. Vor dem Schreiben wird die erfasste Information per Byte-Transformation kodiert.
Zusätzlich kam ein Browserpasswort-Entschlüsselungs-Tool zum Einsatz. Es greift auf Datenbestände wie Login Data (Chrome) und zugehörige Metadaten (u. a. Local State als Masterkey-Quelle) zu. Für Firefox wird ebenfalls eine logins.json-Datei aus dem Profilverzeichnis verwendet.
Remote Access und Netzwerkprobing
Für den Fernzugriff wurde ein Pandora RC agent verwendet. Der Ablauf ähnelt dabei dem oben beschriebenen Mechanismus mit geplanten Aufgaben: Der Angreifer installiert den Agenten nach dem Ausführen eines Batch-Skripts und startet ihn anschließend über die Übergabe passender Parameter.
Um sich im Netzwerk umzusehen, wurde außerdem ein internes Scan-Tool namens Fscan genutzt. Es kann Netzwerke entdecken, Vulnerability-orientierte Checks durchführen und auch versucht, Verbindungen oder Zugriffe über gängige Ports aufzubauen. Die Ausgaben wurden in Dateien im temporären Verzeichnis abgelegt.
E-Mail-Ernte über IMAP-ähnliche Abläufe
Schließlich setzten die Angreifer ein Kommando-basierte Zugriffsschema ein, das sich an einer Verbindung zu einem E-Mail-Server orientiert. Nach Authentifizierung wird der Posteingangsordner ausgewählt, sodass anschließend Nachrichten gelesen oder manipuliert werden können – je nachdem, welche Kommandos über die Kampagnensteuerung ausgegeben werden.
SilkLurk: Side-Loading mit legitimen Windows-Binaries
Während OctLurk stark über geplante Aufgaben und Loader-DLLs arbeitet, zeigt SilkLurk ein anderes Initialisierungsbild. Die Forschenden beschreiben Side-Loading-Verhalten: Der Angreifer lässt legitime Programme ausführen und platziert dabei so, dass eine manipulierte DLL den eigentlichen Loader bereitstellt.
Beispiele für legitime ausführbare Dateien sind u. a. Komponenten, die mit NVIDIA- oder Realtek-Funktionalität assoziiert sind. Je nach Prozess wird eine passende bösartige DLL geladen, die in der Folge die Backdoor in den Prozessspeicher injiziert.
Entschlüsselung und systembezogene Spezialisierung
Der SilkLurk-Loader prüft zunächst, ob er im vorgesehenen legitimen Kontext läuft. Danach bewegt er die Payload-Datei in einen vorgegebenen Pfad und sorgt so für die Grundlage weiterer Schritte.
Um die Entschlüsselung zielgerichtet zu machen, berechnet der Loader einen Hash über den Computernamen. Dieser Hash wird in einer individuell zusammengesetzten Logik verwendet, um sowohl die Pfadangaben als auch die Payload-Bytes zu entschlüsseln. Zusätzlich wird die Shellcode-Komponente in mehreren Phasen manipuliert, etwa über XOR-Operationen auf Headern und bestimmten Sektionen.
Auch hier werden Imports und Relocations geschützt, indem Namen bzw. Werte verschlüsselt werden und erst zur Laufzeit wiederhergestellt bzw. verarbeitet werden.
SilkLurk Backdoor: Konfiguration, C2-Kanal und Paketaufbau
Nach dem Start enthält die SilkLurk-Backdoor eine feste Konfigurationsmenge. Ein Mutex-Anteil und der Rest der Konfiguration sind verschlüsselt gespeichert und werden in einem benutzerdefinierten Dateinamen innerhalb des %APPDATA%-Verzeichnisses abgelegt.
Für die Kommunikation mit dem C2 wird ein TCP-Socket aufgebaut. Falls Proxyinformationen vorliegen, versucht die Backdoor den C2 über den Proxy zu erreichen. Anschließend erzeugt sie einen zufälligen Netzwerk-Schlüssel, nutzt ihn für die Paketverschlüsselung und übermittelt zunächst diesen Schlüssel an den Server.
Beim Senden von Informationen werden die Daten komprimiert und über einen benutzerdefinierten Algorithmus geschützt. Dazu sammelt die Backdoor u. a. Rechnername, zugewiesene DNS-Domäne, Logon-Name, Architektur sowie OS-Detailinformationen. Das Ziel ist erneut ein präziser Überblick über das betroffene System, damit Kommandos passend ausgewählt werden können.
Nach dem ersten Austausch wartet die Backdoor auf eine Antwort vom C2. Diese Antwort wird mit dem gemeinsam genutzten Netzwerk-Schlüssel entschlüsselt; danach steuert ein Feld im Header, welche Aktion als nächstes ausgeführt wird.
Was bedeutet das für Organisationen?
Für Unternehmen und Behörden ergibt sich daraus vor allem eine Erkenntnis: Die Angreifer kombinieren mehrere Techniken, um sowohl die initiale Ausführung als auch die spätere „Arbeitsfähigkeit“ sicherzustellen. Dazu gehören:
- nutzerangepasste Entschlüsselung und verschleierte Loader,
- Persistenz über geplante Aufgaben und Services,
- dynamisches Nachladen von Plugins bzw. Proxy-Fähigkeiten,
- umfangreiches Sammeln von Systemdaten, Anmeldedaten und Browserinformationen.
Wer Angriffe dieser Art reduzieren will, sollte insbesondere auf ungewöhnliche Service- und Task-Erstellungen, verdächtige DLL-Ladevorgänge sowie auffällige Netzwerkkommunikation achten. Auch die Kombination aus Credential Dumping und nachfolgender Lateral-/Remote-Nutzung ist ein Muster, das Monitoring-Teams priorisieren können.
Fazit zu OctLurk und SilkLurk
OctLurk und SilkLurk zeigen, wie aus einer verdeckten Erstinstallation eine breit nutzbare Zugriffskette werden kann. Die Systeme setzen auf stark verschleierte Entschlüsselungsmechanismen, nutzen systembezogene Daten zur Anpassung und liefern dann Backdoor-Funktionen samt Plugins. Ergänzend kommt bei einer verwandten Komponente mit LurkProxy ein Proxy-Ansatz hinzu, der Netzwerktraffic über eine verschlüsselte C2-Verbindung weiterleitet.
Auch wenn die Zuordnung zu einem konkreten bekannten Akteur noch nicht eindeutig ist, belegen die beobachteten Aktivitäten die strategische Ausrichtung: zentrale Infrastrukturen und privilegierte Zugänge werden gezielt vorbereitet, Datenabgriff intensiv betrieben und Remote-Zugriff für weitere Schritte ermöglicht.
Quelle: https://securelist.com/octlurk-silklurk-backdoors-central-asia/120840/
