Seit März 2026 ist die GenieLocker Ransomware-Familie im Einsatz. Sicherheitsbeobachter berichten über Angriffe auf Organisationen in der Russischen Föderation, besonders aus dem Industriesektor. Auffällig ist dabei, dass die Schadsoftware sowohl auf Windows als auch auf Linux und ESXi abgestimmt ist – und damit eine größere Reichweite als klassische, nur für ein Betriebssystem entwickelte Varianten bekommt.
Im Folgenden gehen wir auf die beobachteten Vorgehensweisen der Angreifer ein, erläutern wesentliche technische Unterschiede zwischen den Versionen und ordnen die Verschlüsselungslogik in verständliche Schritte ein. Ziel ist weniger Panik als Klarheit: Wer die Mechanismen versteht, kann präventiv besser planen und im Ernstfall schneller reagieren.
Hintergrund: Wer steckt hinter GenieLocker?
Nach Open-Source-Beobachtungen wird die GenieLocker Ransomware einem finanziell motivierten Erpressungsakteur namens Toy Ghouls zugeschrieben. Die Gruppe ist außerdem unter weiteren Namen bekannt, unter anderem Bearlyfy, Labubu und Laboo.boo. Frühere Operationen sollen sich stärker auf externe Verschlüsselungs-Trojaner gestützt haben.
Mit GenieLocker wirkt es so, als würde die Gruppe stärker eigene Bausteine entwickeln: Statt sich vollständig auf Dritttools zu verlassen, bauen sie offenbar eine maßgeschneiderte Lösung auf, die ihre Toolkit-Fähigkeiten erweitert und über mehrere Plattformen hinweg konsistent nutzbar macht.
So gelangten die Angreifer in die Umgebung
Im beschriebenen Vorfall nutzten die Täter zunächst eine OpenVPN-Verbindung, die aus dem Netzwerk eines externen Partners stammte. Dabei wird vermutet, dass die Täter die bestehende Vertrauensstellung zum Partner ausnutzten und anschließend gestohlene, aber noch gültige Zugangsdaten verwendeten, um sich einzuloggen.
Dieser Einstiegstyp ist besonders relevant, weil er nicht zwingend direkt auf ein kompromittiertes internes System schließen lässt. Vielmehr zeigt er, wie wichtig es ist, Zugänge zu Drittparteien und deren Vertrauensbeziehungen sauber zu überwachen.
Entdeckung, Credential Access und weitere Werkzeuge
Nachdem die Angreifer ein Zielsystem kompromittiert hatten, installierten sie zusätzliche Tools. Genannt werden unter anderem OpenSSH, socks5.exe, ein SoftPerfect Network Scanner sowie Mimikatz.
Für die interne Erkundung kam der Network Scanner zum Einsatz. Mimikatz diente dazu, Zugangsdaten auszulesen. Zusätzlich deutet die forensische Auswertung darauf hin, dass die Angreifer das Bereits installierte KeePassXC genutzt haben – mit dem Versuch, in den Datenbanken gespeicherte Credentials zu extrahieren.
Seitliche Bewegung und Kommando- und Steuerung
Für die laterale Ausbreitung setzten die Angreifer auf gängige Fernzugriffswege: RDP für Windows-Hosts und SSH für Linux-Server. Das Verbreiten der Verschlüsselungsroutine erfolgte zudem über legitime Administrations-Tools wie PsExec und PAExec.
Damit die Systeme weiterhin koordiniert werden konnten, etablierten die Angreifer außerdem einen Reverse-SSH-Tunnel zur Kommando- und Kontrollinstanz. Solche Tunnel können die Kommunikation vereinfachen, insbesondere wenn direkte Verbindungen nach außen erschwert sind.
Was passiert während der Auswirkung (Impact)?
In der Impact-Phase begannen die Angreifer, Daten systematisch unbrauchbar zu machen. Auf Windows-Maschinen wurde die PE-Version der GenieLocker Ransomware eingesetzt, um Dateien zu verschlüsseln.
Auf Linux– und ESXi-Systemen liefen ihre Varianten in einer ELF-Ausprägung. Hier wird zusätzlich berichtet, dass laufende virtuelle Maschinen gestoppt und anschließend Festplatten verschlüsselt wurden. Das deutet auf einen konsequenten Ansatz hin, der nicht nur Dateien, sondern die Infrastruktur selbst betrifft.
Wichtig: In der beschriebenen Auswertung gab es keine Hinweise auf Datenausfiltration. Außerdem wird betont, dass die Angreifer kein sogenanntes Double-Extortion-Modell gefahren haben und keinen eigenen Daten-Leak-Auftritt betreiben.
GenieLocker für Windows: Verschlüsselung, Schutzmechanismen und Startlogik
Die Windows-Variante der GenieLocker Ransomware ist hauptsächlich in C geschrieben, aber so kompiliert, dass auch C++-Bibliotheken zum Einsatz kommen. Bei den Kryptofunktionen greift die Schadsoftware auf die libsodium-Bibliothek zurück.
Ein bemerkenswertes Detail: Laut Analyse speichert GenieLocker keine Lösegeldhinweise direkt auf dem betroffenen System und enthält auch keine Kontaktinformationen oder Verhandlungsadressen. Die Kommunikation soll stattdessen manuell während des Angriffs bereitgestellt werden. Als möglicher Grund wird genannt, dass dadurch das frühzeitige Erkennen durch das Erstellen vieler Readme-Dateien erschwert wird.
Geheimer Startparameter und Sandboxing-Vermeidung
GenieLocker unterstützt mehrere Startargumente. Für den Start wird ein „secret argument“ erwartet, das als Hex-String in den Code eingebunden ist. Der Wert wird in Bytes umgewandelt, mit SHA-256 gehasht und anschließend mit einem hardcodierten Wert verglichen.
Wenn der Check gelingt, wird der Literalstring „session“ an den Secret-Wert angehängt und erneut gehasht – in diesem Schritt entsteht jedoch ein Ergebnis, das laut Beschreibung nicht weiter verwendet wird. Ein Teil davon könnte zu einer Funktion gehören, die noch im Entwicklungsstadium ist.
Anti-Debugging: Schnell aussteigen, wenn etwas „nicht stimmt“
Nach dem Start führt GenieLocker mehrere Prüfungen durch, um Debuggers zu erkennen. Dabei nutzt es Windows-API-Funktionen wie IsDebuggerPresent und CheckRemoteDebuggerPresent.
Nach der Validierung des secret argument startet das Programm einen watchdog-Thread, der in einer Endlosschleife alle 500 Millisekunden Checks für bekannte Debugger durchführt. Falls ein Check fehlschlägt, wird der gesamte Prozess sofort beendet.
Zusätzlich wird die CRC32 der eigenen .text-Sektion berechnet und bei jedem Durchlauf erneut verglichen. Damit lässt sich erkennen, ob Codeabschnitte verändert wurden – beispielsweise durch Debugger oder andere Eingriffe.
Vorbereitung der Verschlüsselung: Ausschlüsse und Ressourcenfreigabe
Vor dem Verschlüsseln nutzt GenieLocker für Windows mehrere Ausschlusslisten. So werden bestimmte Ordnernamen nicht verschlüsselt, vor allem um zu verhindern, dass essenzielle Systembereiche beschädigt werden.
Auch bestimmte Systemdateien und Dateiendungen sind von der Verschlüsselung ausgenommen. Zusätzlich gibt es eine Hostnamen-Ausschlussliste, wobei im betrachteten Beispiel keine Einträge vorhanden waren.
Wenn der Hostname nicht ausgeschlossen ist, versucht die Malware Prozesse zu beenden, die relevante Dateien verwenden könnten. Dazu wird die Funktion TerminateProcess genutzt. Außerdem werden bestimmte Dienste über ControlService gestoppt, bevor die Verschlüsselung startet.
Dateiverschlüsselung auf Windows: Chunks, Journaling und Kryptografie
Die Dateierweiterung für verschlüsselte Dateien ist im Körper der Malware fest hinterlegt. In der analysierten Probe lautet sie .03ffc1c4a3da0f02.
Bevor ein Fileprozess beginnt, erstellt GenieLocker zwei Hilfsdateien:
- Lock-Datei: <filename>.fileext.03ffc1c4a3da0f02.lock
- Journal-Datei: <fileext>.03ffc1c4a3da0f02.journal
Die Lock-Datei dient dem Schutz vor doppelter Verschlüsselung. In ihr speichert die Malware die aktuelle PID des Prozesses.
Das Journal enthält unter anderem die Zeichenfolge VCJOURN, einige weitere Felder sowie Informationen zur Anzahl der zu verschlüsselnden Blöcke. Zusätzlich ist eine CRC32-Prüfsumme enthalten, um die Integrität des Journalinhalts zu überwachen.
Optionaler Prozentsatz und zufällige Blockpositionen
Standardmäßig verschlüsselt GenieLocker Dateien in 0x1000000-Byte-Chunks. Wird das Argument -p übergeben, berechnet die Malware, wie viele Chunks nötig sind, um einen gewünschten Anteil der Dateiinhalte zu verschlüsseln.
Die Auswahl erfolgt dabei über zufällige Positionen innerhalb der Datei. Selbst wenn der Prozentwert auf null gesetzt wäre, wird laut Beschreibung mindestens der erste Chunk am Dateianfang trotzdem verschlüsselt.
Krypto-Details: XChaCha20-Poly1305 und Curve25519
Für die Verschlüsselung nutzt die GenieLocker Ransomware das AEAD-Verfahren XChaCha20-Poly1305. Pro Datei wird dabei jeweils ein eigener Schlüssel und ein eigenes Nonce verwendet. Außerdem fügt die Malware einen Footer hinzu, der Informationen für eine spätere Entschlüsselung sowie Metadaten enthält.
Die Metadaten werden mit dem gleichen Cipher und Schlüssel wie der Dateiinhalt verschlüsselt, jedoch mit einem anderen Nonce. Für die Schlüsselverschlüsselung kommt Curve25519-XSalsa20-Poly1305 zum Einsatz. Der Master-Public-Key der Angreifer ist im Binärbestand hardcodiert.
GenieLocker für Linux und ESXi: weniger Schutzschichten, dafür ESXi-Funktionen
Im Vergleich zur Windows-Variante wirkt das Linux-/ESXi-Build der GenieLocker Ransomware deutlich „schlanker“. Laut Analyse gibt es dort keinen secret argument, auch Anti-Debugging und Ausschlusslisten sollen fehlen.
Die ESXi-Variante bringt jedoch plattformspezifische Funktionen mit: Dazu gehören double-fork-Unterstützung und die Fähigkeit, die Welcome Message zu verändern.
ESXi-spezifische Anpassungen
Die Malware kann sich mit dem Parameter -d als Daemon absetzen. Dafür wird das klassische double-fork-Verfahren genutzt, sodass der neue Prozess vollständig vom Parent entkoppelt wird.
Außerdem wird die Datei /etc/vmware/welcome angepasst, die die ESXi-„Message of the Day“ enthält. Im untersuchten Beispiel wurde die Nachricht leer gelassen. Auf Linux-Systemen wird nichts am „Message of the Day“-Pfad geändert, weil dort andere Mechanismen existieren.
Weitere Optionen sind unter anderem ein Startverzögerungsmodus sowie die Konfiguration der Anzahl von Worker-Threads. Das Kommandozeilenlayout orientiert sich im Styling an bekannten LockBit-Mustern, was als Hinweis gewertet wird, dass hier eine ähnliche Betriebslogik nachgebaut wurde.
Verschlüsselung unter ESXi und Linux: gleiche Krypto-Bausteine, gleicher Ansatz
Beim Dateibereich bleibt die Kernidee gleich: Die Malware verwendet auch auf Linux und ESXi das gleiche Verschlüsselungsprinzip wie in Windows. Das bedeutet konkret: XChaCha20-Poly1305 für Inhalt und Metadaten sowie Curve25519-XSalsa20-Poly1305 für die Schlüsselverschlüsselung.
Da als Standardpfad für das Zielverzeichnis /vmfs/volumes angenommen wird, wirkt die ESXi-Version primär für diese Umgebung gedacht. Gleichzeitig kann sie laut Analyse auch auf Linux-Distributionen ausgeführt werden.
Welche Branchen trifft GenieLocker besonders?
Aus Telemetriedaten wird berichtet, dass GenieLocker-Erkennungen überwiegend auf Endpoints in der Russischen Föderation konzentriert sind. In der Kampagne rund um März 2026 wird besonders der Fertigungssektor genannt, gefolgt von Bauwesen, Finanzdienstleistungen, Handel und Technologie.
Das ist typisch für Angreifer, die Produktionsumgebungen und kritische Unternehmensprozesse mit hoher Abhängigkeit von Daten und Verfügbarkeit anvisieren.
Fazit: Warum die Entwicklung eine größere Bedrohung ist
Die GenieLocker Ransomware steht in Zusammenhang mit einer zunehmenden Aktivität von Toy Ghouls gegenüber russischen Unternehmen. Entscheidend ist die offenbar strategische Weiterentwicklung: Durch eine maßgeschneiderte Verschlüsselungssoftware, die nativ auf Windows, Linux und ESXi läuft, senken die Angreifer ihre Abhängigkeit von vorgefertigten Dritt-Encryptern und schaffen gleichzeitig eine einheitliche kryptografische Basis.
Für Verteidiger heißt das: Nicht nur ein Betriebssystem beobachten, sondern die gesamte Umgebung betrachten – inklusive Remote-Zugänge über Drittparteien, Credential-Exposure (z. B. KeePassXC) sowie die lateralen Bewegungsmuster über RDP/SSH und die Nutzung legitimer Admin-Tools. Je besser diese Kette unterbrochen wird, desto geringer ist die Chance, dass die Verschlüsselung in der Impact-Phase durchgreift.
Einordnung zur Erkennung
Für Produkte der Kaspersky-Produktlinie wird die Malware als Trojan-Ransom.Win64.Agent.genie sowie als heuristische Varianten wie HEUR:TrojanRansom.Win64.Generic und Trojan-Ransom.Linux.Agent.genie erkannt.
Für zusätzliche Details zu Indicators of Compromise (IOCs) wird auf den Kundenservice der Threat Intelligence Reporting Lösung verwiesen.
Quelle: https://securelist.com/genielocker-ransomware-for-windows-linux-and-esxi/120843/
