MSPs sind ein Hauptziel für die Ransomware Akira und Lynx

Zusammenfassung

• Die Acronis Threat Research Unit (TRU) hat aktuelle Samples der Ransomware-Familien Akira und Lynx analysiert, um die neuesten Anpassungen und Optimierungen aufzudecken, die von Cyberkriminellen eingesetzt werden.

• Akira und Lynx nutzen ein gemeinsames RaaS-Modell und doppelte Erpressungstaktiken.

• Lynx ist sollen Elemente des geleakten LockBit-Quellcodes enthalten. Akira weist zudem Ähnlichkeiten mit Conti auf (von dem auch LockBit beeinflusst wurde), was auf eine gemeinsame Code-Basis hindeutet.

• Diese Ransomware-Varianten kompromittieren Systeme über gestohlene Anmeldedaten, VPN-Schwachstellen, Ausspähung, Rechteausweitung, die Umgehung von Abwehrmaßnahmen sowie Datenexfiltration und -verschlüsselung. Sie zielen mit ausgeklügelten, aber auch wiederverwendeten Methoden insbesondere auf kleine und mittlere Unternehmen (KMUs) ab.

• Die Cyberkriminellen können beispielsweise installierte Sicherheitsprogramme deaktivieren, Schattenkopien löschen und Ereignisprotokolle bereinigen, um ihrer Entdeckung zu verhindern und Wiederherstellungsmaßnahmen zu erschweren.

• Funfact-Beobachtung am Rande: Das von uns untersuchte Ransomware-Sample von Lynx kann seine Lösegeldforderung sogar auf den vorhandenen Druckern ausgeben lassen.

Einleitung

Im Rahmen unserer fortlaufenden Bemühungen, die Aktivitäten von Ransomware-Banden zu verfolgen, stellen wir hier zwei Ransomware-Gruppen vor, die im ersten Quartal 2025 besonders aufgefallen sind und die in unseren bisherigen Untersuchungen noch nicht behandelt wurden – nämlich die Ransomware-Familien Akira und Lynx.

• Mit Akira wurden über 220 Opfer angegriffen, darunter viele KMUs wie Anwaltskanzleien, Steuerberater und Bauunternehmen. Aber auch MSPs (Managed Service Provider) wie Hitachi Vantara[1] und Toppan Next Tech wurden ins Visier genommen.[2]
• Bei Lynx gab es bisher etwa 145 Opfer. Die High-Volume-Angriffsstrategie dieser Ransomware lässt eine Fokussierung auf kleinere Unternehmen vermuten. Allerdings sind bisher wenige konkrete Beispiele bekannt. Ein Beispiel, über das berichtet wurde, ist ein Angriff auf einen CBS-Ableger (amerikanischer Fernsehsender) in Chattanooga, Tennessee.[3]

[1] https://www.bleepingcomputer.com/news/security/hitachi-vantara-takes-servers-offline-after-akira-ransomware-attack/

[2] https://www.holdings.toppan.com/en/info/toppan_info20250408.pdf

[3] https://www.scworld.com/brief/cbs-affiliate-purportedly-compromised-by-lynx-ransomware-gang

Auch wenn nicht alle Opfer MSPs sind, scheuen diese Banden sowieso nicht davor zurück, jeden anzugreifen. Solange es sich nur lohnt, sehen sie jedes Unternehmen als potentielle Beute. MSPs sind jedoch ein bevorzugtes Ziel für diese Cyberkriminellen, weil sie sich dadurch erhoffen, auf ein Netzwerk von Kunden zugreifen zu können, was den erhofften Gewinn vervielfachen könnte.

Werfen wir einen genaueren Blick auf die einzelnen Ransomware-Gruppen:

1. Die Ransomware Akira: Ein unangenehmes Comeback

2. Die Ransomware Lynx konzentriert sich auf private Unternehmen

Die Ransomware Akira tauchte erstmalig 2022 mit einer anfänglich noch geringen Anzahl von Angriffen auf. Aber schon im Jahr 2023 stieg sie mit 174 Angriffen in die Top 10 der Ransomware-Banden auf. Aufgrund ihrer Aktivitäten ergab die Spike-Analyse, dass die untersuchten Samples viele Ähnlichkeiten mit der Ransomware Conti aufwiesen. Conti wurde mit der russischen Hacker-Gruppe Wizard Spider in Verbindung gebracht, die 2022 selbst Opfer eines Datenlecks wurde, bei dem unter anderem Quellcode und interne Nachrichten der Gruppenmitglieder in die Öffentlichkeit gelangten. Nach diesem Vorfall wurde Wizard Spider aufgelöst. Es ist noch unbekannt, ob Akira eher eine Art umbenannter Ableger von Wizard Spider ist oder ein neuer Akteur, der sich den geleakten Code zunutze gemacht hat. Im Jahr 2024 rangierte Akira erneut unter den Top 10 der Ransomware-Banden, gemessen an der Anzahl der Angriffe (315 bekannte Opfer).

Zu Beginn seiner Aktivitäten hat die Ransomware Akira mithilfe von Phishing-Angriffen und der Ausnutzung von Schwachstellen (wie etwa Cisco CVE-2023-20269) Zugriff auf seine Opfer erlangt. Im Jahr 2024 hat Akira vor allem Benutzer-VPNs ins Visier genommen, wobei die Ransomware verschiedene Schwachstellen (wie etwa SonicWall Firewall CVE-2024-40766) ausgenutzt hat, durch die die Angreifer Firewalls deaktivieren und sich mit der Infrastruktur verbinden konnten.

Im Jahr 2025 konnte dieTRU beobachten, dass die Akira-Betreiber:innen gestohlene/gekaufte Anmeldedaten eingesetzt haben, um Zugriff auf die betroffenen Maschinen/Server zu erlangen. Bei Erfolg wurde dann die vorliegende Sicherheitssoftware deaktiviert. Wenn dies nicht gelang, haben sie eine Remote-Exfiltration gestartet und anschließend eine Verschlüsselung mit regulären Tools durchgeführt, die oft auf Positivlisten stehen und daher nicht gescannt oder überwacht werden.

Wenn der Zugriff erlangt war, wurden weitere Informationen gesammelt, laterale Bewegungen im Netzwerk durchgeführt und die Verschlüsselungskomponente der Ransomware ausgelöst. Außerdem haben die Akira-Akteur:innen die Dateien der Opfer vor deren Verschlüsselung erst einmal auf eigene Server exportiert, um die Opfer doppelt erpressen zu können.

Das analysierte Sample ist eine PE64-Datei, die in C/C++ geschrieben und mit Visual Studio Build-Tools kompiliert wurde. Diese Datei wurde erstmals Ende 2024 in „freier Wildbahn“ entdeckt.

Die Ausführung beginnt mit einer WinMain-Funktion, die recht umfangreich ist und viel Code enthält. Zunächst ruft die Funktion das aktuelle Datum sowie die aktuelle Uhrzeit ab und erstellt dann eine Protokolldatei in dem Ordner, in dem sie ausgeführt wurde.

Das Sample ruft dann Befehlszeilenargumente ab und vergleicht diese mit einer gespeicherten Liste. Hier ist eine Auflistung von unterstützten Befehlen und eine entsprechende Beschreibung

Nach dem Speichern der Werte aus den Argumenten ruft das Sample alle verfügbaren logischen Laufwerke im System ab. Bei jedem Laufwerk wird dessen Typ überprüft. Wenn es mit dem Wert für das Netzlaufwerk übereinstimmt und das Argument '-localonly' übergeben wird, wird dieses Laufwerk übersprungen.

Der nächste Schritt besteht darin, eine Liste aller laufenden Prozesse im System abzurufen. Dazu verwendet das Sample die Funktion 'WTSEnumerateProcess'. Diese Funktion wird hauptsächlich verwendet, um Prozesse auf Remote-Servern aufzulisten, aber Akira verwendet den Wert 'NULL' als Handle-Argument, was bedeutet, dass diese Funktion Prozesse auf dem lokalen System auflisten kann.

Als nächstes werden einige Symbole in einen Puffer geladen, die dann in einer Schleife entschlüsselt werden. Als Ergebnis wird ein PowerShell-Befehl generiert. Dieser Befehl löscht alle Schattenkopien mithilfe des WMI-Objekts.

Das Sample legt dann die Authentifizierungsinformationen fest, die für Aufrufe auf der lokalen Maschine verwendet werden. Hier wird 'CoSetProxyBlanket' mit folgenden Argumenten verwendet:

●      dwCapabilities = 0 – kein Eigenschaftskennzeichen (Flag).

●      pAuthInfo = NULL – DCOM verwendet die aktuelle Proxyidentität (entweder das Prozess- oder das Impersonation-Token).

●      dwImpLevel = 3 – Der Server-Prozess kann den Sicherheitskontext des Clients imitieren, während er im Namen des Clients handelt.

●      dwAuthLevel = 3 – Authentifiziert nur zu Beginn jedes Remote-Prozedur-Aufrufs, wenn der Server die Anfrage erhält.

●      pServerPrincName = NULL – keine gegenseitige Authentifizierung.

●      dwAuthzSvc = NULL – keine Autorisierung.

●      dwAuthSvc = NULL – keine Authentifizierung.

Anschließend lädt das Sample Zeichenfolgen, die beim Import aus der Bibliothek 'fastprox.dll' verwendet werden, bei der es sich um einen benutzerdefinierten WMI-Marshaller handelt. Es verwendet auch einige Importe aus der COM-Bibliothek 'wbemprox.dll'. Sowohl COM als auch WMI werden hier verwendet, um Berechtigungen zu kontrollieren und decodierte Powershell-Befehle als ausführbare Datei auszuführen.

Nach der Befehlsausführung ruft das Sample die Funktion 'GetSystemInfo' auf und beginnt damit, Threads zu erstellen. Es erstellt drei verschiedene Arten von Threads mit unterschiedlichen Thread-Nummern.

Die Anzahl der Verschlüsselungsthreads hängt direkt von der Anzahl der Computer-CPUs ab, die mit 'GetSystemInfo' ermittelt werden. Auf einem Computer mit sechs logischen Prozessoren werden beispielsweise zwei Threads für Ordner-Parser erstellt – die anderen vier werden zur Verschlüsselung verwendet. Diese Zahlen werden in die Protokolldatei geschrieben.

Akira verwendet sowohl Windows-API-Aufrufe als auch Funktionen aus der CRT (C-Laufzeit) in der Datei-Verschlüsselungsroutine. Um die Ordner im System zu durchlaufen, erstellt es einen Verzeichnis-Iterator.

Wenn eine Datei gefunden wird, wird nach zwei Symbolen im Dateinamen gesucht – nämlich '\' und '.'. Diese Operation wird verwendet, um festzustellen, ob es sich bei einer Datei um einen Ordner handelt. Sollte die Datei tatsächlich ein Ordner sein, wird das Sample dessen Namen mit der gespeicherten Liste abgleichen. Wenn der Name übereinstimmt, wird der Ordner von der Verschlüsselung ausgeschlossen. Wenn die Datei kein Ordner ist, wird das Sample deren Dateierweiterung ermitteln, indem es nach dem letzten Punkt (.) im Dateinamen sucht und die ermittelte Erweiterung mit einer Liste gespeicherter Dateierweiterungen vergleicht.

Die folgenden Ordner und Dateierweiterungen werden von der Verschlüsselung ausgeschlossen, da dies die Systemfunktionalität stören könnte: $Recycle.Bin, System Volume Information, Boot, ProgramData, Windows, temp, .dll, .exe, .akira.

Alle anderen Dateien werden mit den Zugriffsrechten 'GENERIC_ALL' geöffnet. Das Sample ruft das Ergebnis dieser Aktion mit der Funktion 'GetLastError' ab. Der letzte Fehlercode wird dann mit dem Wert '20h' (32 in Dezimal) verglichen, der dem Fehler 'ERROR_SHARING_VIOLATION' entspricht. Bei einer Übereinstimmung ruft das Sample eine Funktion auf, die den Prozess beendet, der diese Datei blockiert.

Um Prozesse zu beenden, verwendet das Sample die 'Restart Manager API'. Nach dem Erstellen einer Sitzung registriert es eine Ressource, bei der es sich um den Namen einer gesperrten Datei handelt. Anschließend ermittelt das Sample eine Liste der Prozesse, die auf diese Datei zugreifen und diese blockieren. Bevor Prozesse aus dieser Liste beendet werden, ruft das Sample seine eigene PID ab, damit es von der Beendigung ausgeschlossen wird.

Akira verwendet ChaCha20 zum Verschlüsseln von Dateien. Wenn der Datei-Prozentsatz als Argument angegeben wurde, wird Akira berechnen, wie viele Daten gelesen werden müssen. Es verwendet gespeicherte magische Konstanten, die von der Schlüsselgröße abhängen und im vorliegenden Fall immer 256 sind.

Nachdem die verschlüsselten Daten geschrieben wurden, führt es eine weitere Schreibaktion mit einem Puffer von 512 Bytes (200 in Hexadezimal) durch. Es enthält einen ChaCha20-Schlüssel, der mit RSA chiffriert ist.

In früheren Versionen von Akira wurde ein modifizierter Verschlüsselungsalgorithmus der Ransomware Conti verwendet, der ChaCha20 und RSA umfasste. Während die neuesten Samples dieselben Verschlüsselungsalgorithmen verwenden, haben die Angreifer in früheren Versionen einen Fehler bei der Implementierung der Algorithmen gemacht, indem sie nur einmal während der Ausführung einen Schlüssel generierten Die Folge war, dass jede verschlüsselte Datei denselben Schlüsselstrom hatte, wodurch Cyber Security-Unternehmen ein Entschlüsselungsprogramm entwickeln konnten. Akira hat anschließend sein Verschlüsselungsschema verbessert, sodass dieser Schlüssel nun für jede Datei separat generiert wird. Die Linux-Version verwendet ebenfalls ChaCha20 zum Verschlüsseln von Dateien, wobei jedoch die CryptoPP-Bibliothek zum Einsatz kommt. Die Windows-Versionen enthalten hingegen Verschlüsselungsimplementierungen im Sample, ohne dass externe Bibliotheken verwendet werden müssten.

Akira war 2024 sehr aktiv und hat seine Aktivitäten auch 2025 fortgesetzt. Während das analysierte Sample einige Ähnlichkeiten mit dem geleakten Quellcode von Conti aufweist, hat es sich mittlerweile weiterentwickelt und ist zu einer der gefährlichsten Bedrohungen dieses Jahres geworden. Wie viel Zeit Akira seinen Opfern für die Zahlung des Lösegeldes einräumt, ist unklar. Aus den Lösegeldforderungen geht lediglich hervor, dass der Preis für jedes Opfer individuell berechnet wird, abhängig von den gestohlenen Daten (wozu auch Bankdaten gehören können). Die TRU hat einen Fall beobachtet, bei dem die Daten des betreffenden Opfers innerhalb von nur fünf Tagen nach dem dem Angriff durch Akira geleakt wurden.

SHA256

88da2b1cee373d5f11949c1ade22af0badf16591a871978a9e02f70480e547b2

URL

https://akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion

https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id.onion

Lynx wurde erstmals Mitte 2024 beobachtet und weist viele Ähnlichkeiten mit der Ransomware INC auf, die 2023 von der TRU untersucht wurde. Als Ransomware-as-a-Service-Gruppe sind die Lynx-Angreifer:innen ständig auf der Suche nach neuen Kompliz:innen, weswegen sie in russischen Underground-Foren posten und nach Mitstreiter:innen suchen. Der Verfasser der Foren-Nachrichten behauptete jedenfalls, dass Lynx nur private Unternehmen angreift, über einen eigenen Builder verfügt, Windows- und Linux-Versionen unterstützt und einen Service bietet, um gestohlene Dateien zu speichern. Außerdem würden die Mitstreiter:innen Zugriff auf das Admin-Panel der Datenleck-Website erhalten.

Im April 2024 wurde in einem Untergrundforum ein Angebot veröffentlicht, bei dem drei Kopien der Ransomware INC für jeweils 300.000 (vermutlich in Rubel) angeboten wurden. Die in dem Posting beschriebene Funktionalität ähnelt bekannten Samples der Ransomware INC. Ob es sich aber tatsächlich um den INC-Quellcode handelt, ist nicht bekannt.

Kurz darauf tauchte die Ransomware Lynx auf. Da die INC-Gruppe auch 2025 noch aktiv ist, ist es unwahrscheinlich, dass es einfach nur ein Rebranding von INC ist. Wahrscheinlich haben die Person(en) hinter Lynx den INC-Builder eher in einem Untergrundforum gekauft und dann den Code noch für sich angepasst.

Übersetzung aus dem Russischen:

„Verkaufe den Quellcode der Ransomware INC für 3 Käufer.

aes-ctr-128 + curve25519-donna

IOCP, Linux-Version identisch, ESXI-Build kompatibel für alle Systeme

Panel – React, Backend – Node.js + Typescript, alles in Docker verpackt, alles kann mit einem Befehl gestartet werden, keine Komplikationen“

Lynx verwendet in der Regel Phishing-E-Mails, um seine Malware bei den Opfern einzuschleusen. Wenn die Angreifer:innen Zugriff auf die Opfer-Computer erhalten, sammeln sie zunächst Informationen über das System und die Infrastruktur. Anschließend versuchen sie, Benutzer-Anmeldedaten abzugreifen und sich lateral im Netzwerk zu bewegen, um weitere Computer zu infizieren. Nachdem sie Zugriff auf die Computer der Opfer erlangt haben, können die Angreifer:innen auch die installierte Software untersuchen und nach Schwachstellen suchen, weil diese später dazu genutzt werden könnte, weitere Ransomware auszuführen.

Bei den Angriffen im Jahr 2025 haben wir gesehen, dass Lynx versucht, Sicherheitsprogramme zu deinstallieren, wenn es solche denn findet.

Wenn dieser Schritt durchgeführt wurde, geht die Ransomware dazu über, zunächst Dateien auf bestimmte Server zu exfiltrieren und dann ihre Verschlüsselungskomponente zu aktivieren.

Das analysierte Sample ist eine PE32-Datei, geschrieben in C\C++. Es ist weder gepackt noch sonst wie verschleiert.

Das Sample unterstützt mehrere Befehle. Jeder Befehl und dessen Beschreibung ist im Code gespeichert:

Nachdem es die Argumente über die Befehlszeile erhalten hat, vergleicht das Lynx-Sample diese mit gespeicherten Argumenten. Bei einer Übereinstimmung setzt das Sample den entsprechenden Wert auf '1'. Bei Nichtübereinstimmung setzt das Sample den Wert '0'. Das Ergebnis wird in der globalen Variable gespeichert.

Wenn ein Argument zusätzliche Informationen erfordert (wie beispielsweise den Verzeichnispfad im Argument '--dir'), wird Lynx diese Daten ebenfalls speichern, indem es ein zusätzliches Offset aus der Befehlszeilen-Zeichenfolge verwendet.

Wenn das Argument '--verbose' übergeben wird, wird das Lynx-Sample verschiedene Informationen ausgeben, wie z. B. Einstellungen, den Status einiger Aktionen und den Verschlüsselungsfortschritt.

Dieses Argument zwingt die Lynx-Samples dazu, alle versteckten Laufwerke im System zu ermitteln und zu mounten. Hier wird eine gespeicherte Liste von Laufwerksbuchstaben geladen, von denen dann jeder einzeln überprüft wird. Wenn ein Laufwerk gefunden wird, wird überprüft, ob es vom Typ 'DRIVE_NO_ROOT_DIR' ist. Wenn der Typ übereinstimmt, wird das Laufwerk mit der Funktion 'SetVolumeMountPointW' gemountet.

Lynx verwendet zwei Methoden zum Beenden von Prozessen. Beide werden über Befehlszeilenargumente aktiviert. Wenn das Argument '--kill' übergeben wird, erstellt Lynx einen Snapshot aller im System laufenden Prozesse und beginnt damit, diese zu iterieren. Jeder Prozessname wird mit der gespeicherten Liste verglichen und bei Übereinstimmung beendet.

Das '--kill'-Argument ist auch für das Beenden von Diensten verantwortlich. Hier verwendet das Sample den 'SC Manager' und die Funktion 'EnumServicesStatusExW', um eine Liste aller auf dem System ausgeführten Dienste abzurufen. Das Lynx-Sample vergleicht diese Liste dann mit den gespeicherten Namen. Wenn eine Übereinstimmung gefunden wird, wird die Funktion 'ControlService' mit dem Flag 'SERVICE_CONTROL_STOP' aufgerufen.

Die folgenden Prozesse werden beendet, um Fehler aufgrund von Dateifreigabeverletzungen während der Verschlüsselung zu vermeiden:

sql, veeam, backup, exchange, java, notepad

Beendete Dienste:

sql, veeam, backup, exchange

Wenn das Argument '--stop-process' angegeben wird, verwendet das Sample die 'Restart Manager API', um Prozesse während des Verschlüsselungsvorgangs zu beenden. Diese Funktion wird nur aufgerufen, wenn die Datei, die Lynx zu verschlüsseln versucht, durch einen anderen Prozess blockiert wird. Das Sample wird diese Datei als Ressource registrieren, um den Prozess zu ermitteln. Es wird auch seine eigene PID abrufen, um sich selbst vom Beenden auszuschließen.

Bevor die Verschlüsselungsroutine gestartet wird, durchsucht das Lynx-Sample alle Laufwerke im System. Bei jedem Laufwerk wird dessen Typ überprüft. Für die Verschlüsselung werden nur Laufwerke mit den Kennzeichnungen (Flags) 'DRIVE_REMOVABLE', 'DRIVE_FIXED' und 'DRIVE_REMOTE' akzeptiert. Wenn ein passendes Laufwerk gefunden wurde, wird ein Handle dafür geöffnet und die Funktion 'DeviceIoControl' mit dem Parameter '53C028h' als Steuercode ausgeführt, der 'IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE' entspricht.

Dies ist ein undokumentierter Steuercode, der die maximale Größe für eine Schattenkopie ändert. Da 'lpInBuffer' den Wert '1' enthält, führt die Einstellung einer so geringen Größe dazu, dass die Schattenkopien gelöscht werden. Nach Abschluss dieser Aktionen werden alle gefundenen Laufwerke an die Verschlüsselungsroutine übergeben.

Das Lynx-Sample erstellt Threads mit der Funktion 'sub_275600' als Startadresse. Die Anzahl der Threads entspricht der Anzahl der Prozessoren – ermittelt mit dem Aufruf 'GetSystemInfo' und dann multipliziert mit vier.

Threads mit dieser Startadresse werden zum Suchen von Dateien verwendet. Wenn das Lynx-Sample einen Ordner öffnet, erstellt es eine Lösegeldforderung in diesem Ordner und beginnt mit den Funktionen 'FindFirstFile' und 'FindNextFile' nach Dateien zu suchen. Sollte die gefundene Datei ein Ordner sein, wird das Sample dessen Namen mit der gespeicherten Liste abgleichen. Wenn es beim Ordner-Namen ein Übereinstimmung gibt, wird dieser übersprungen.

Wenn eine gefundene Datei kein Ordner ist, kann das Sample die Datei ebenfalls von der Verschlüsselung ausschließen. Das Sample vergleicht Erweiterungen und Dateinamen. Wenn die Dateigröße 0 ist, wird die Datei ebenfalls übersprungen.

Wenn eine passende Datei gefunden wurde, prüft das Sample zunächst, ob diese Datei gerade von einem anderen Prozess verwendet wird. Wenn das Argument '--stop-process' übergeben wird, wird das Sample den Prozess, der die Datei blockiert, beenden. Anderenfalls wird die Datei übersprungen. Anschließend ermittelt das Sample, ob es Schreibzugriff auf diese Datei hat. Dies wird erreicht, indem ein Datenblock an das Ende der Datei geschrieben wird. Vor dem Schreibprozess setzt das Sample 36 Bytes mit dem Wert '2' in den Puffer. Die Anzahl der Zeichen, die in den Puffer gestellt werden müssen, sowie die Puffergröße, die in die Datei geschrieben werden muss, wird berechnet, indem die Länge der Zeichenfolge 'LYNX' und 32 addiert werden.

Wenn Lynx diese Datei nicht schreiben kann, wird es versuchen, die Besitzrechte für diese Datei zu erlangen. Hier versucht das Sample, die Berechtigung 'SeTakeOwnership' zu erhalten und die Besitzrechte für die Datei zu ändern, indem es eine neue ACL-Struktur erstellt und festlegt, die Schreibrechte gewährt.

Am Anfang der Thread-Routine dekodiert Lynx die Zeichenfolge, die im Base64-Format gespeichert ist:

8SPEMzUSI5vf/cJjobbBepBaX7XT6QT1J8MnZ+IEG3g=

Dieser Wert ist ein öffentlicher ECC-Schlüssel, der zur Generierung des AES-Schlüssels verwendet wird. Jeder Thread initialisiert Kryptografie-Anbieter mit den Flags 'CRYPT_VERIFYCONTEXT' und 'PROV_RSA_AES'. Anschließend generiert das Sample 32 zufällige Bytes mit der Funktion 'CryptGenRandom'.

Anschließend berechnet das Sample den Hash-Wert des generierten Schlüssels. Die SHA512-Konstanten werden in der Binärdatei gespeichert.

Nachdem der Thread die gefundene Datei gelesen hat, erstellt das Sample einen Verschlüsselungsthread, übergibt diesem ein Fertigstellungssignal und beendet sich selbst. Der Verschlüsselungsthread erhält Daten vom vorherigen Thread, darunter die gelesenen Dateidaten und Chiffrierungsschlüssel. Je nach Ergebnis von 'GetQuedCompletionStatus' springt das Sample zu einem von fünf 'Cases'.

Während des Debugging-Prozesses wurde als erster Case zwei ausgelöst. Hier überprüft das Sample zunächst einige Werte und führt dann eine Schreibaktion für die aktuelle Datei durch. Es werden 116 Bytes an Daten geschrieben, einschließlich des chiffrierten Schlüssels.

Das Sample wechselt dann in 'Case 0', wo es überprüft, ob der aktuelle Verschlüsselungsblock-Offset nicht größer als die Dateigröße ist. Wenn es zum ersten Mal in diesen Case eintritt, wird der Block-Offset immer '0' sein und dazu führen, dass der Thread Dateidaten liest. Wenn die Bedingung jedoch erfüllt ist, signalisiert das Sample, dass die Datei keine Daten mehr zu verschlüsseln hat, und veranlasst den Thread, einen verschlüsselten Block in die Datei zu schreiben. Außerdem wird die Case-Anweisung auf den Wert '3' gesetzt.

Als nächstes geht das Sample in 'Case 1'. Hier wird die Dateigröße ermittelt und '116' daraus entfernt. Das wird gemacht, um einen bereits geschriebenen Datenblock aus der Verschlüsselung zu entfernen.

Nachdem alle Vorbereitungen erledigt wurden, tritt das Sample in eine Schleife ein, in der es Dateidaten verschlüsselt. Hier ruft das Sample die Funktion 'sub_AE1110' auf, die den Schlüssel mit AES verschlüsselt. Als Ergebnis wird der Wert v32 als Schlüsselstrom (v16) verwendet, der mit den Dateidaten per XOR verknüpft wird. Bei jeweils 16 Durchläufen der Verschlüsselungsschleife wird der Schlüsselstrom erneut generiert.

Schließlich schreibt das Beispiel verschlüsselte Daten in die Datei und geht zu 'Case 3' über, wo es die Erweiterung ".LYNX" an die Datei anhängt. Danach löscht der Thread seinen Speicher und beginnt auf die nächste Datei zu warten.

Lynx speichert eine Lösegeldforderung im Base64-Format. Lynx lädt diese und übergibt sie an die Funktion 'CryptStringToBinaryA', die mit dem Flag 'CRYPT_STRING_BASE64' aufgerufen wird.

Während die entschlüsselte Nachricht keine Opfer-ID enthält, wird diese nach dem Entschlüsselungsprozess angehängt. Diese ID ist fest codiert und für jedes Sample unterschiedlich.

Nachdem der Verschlüsselungsprozess abgeschlossen wurde, verwendet das Sample Importe aus dem 'Winspool'-Header, um alle angeschlossenen Drucker zu finden. Es wird die Druckernamen überprüfen, diese mit gespeicherten Namen vergleichen, um sie zu vermeiden, und dann Lösegeldforderungen an alle gefundenen Drucker senden.

Zusätzlich zu den Textdateien wird die Lösegeldforderung am Ende des Verschlüsselungsprozesses auch noch als Desktop-Hintergrundbild gespeichert.

Obwohl nicht bekannt ist, ob Lynx nur eine umbenannte Version der Ransomware INC ist, wissen wir, dass beide Ähnlichkeiten im Quellcode aufweisen. Die analysierten Ransomware-Samples können Prozesse beenden, versteckte Laufwerke mounten, Schattenkopien löschen und Dateien auf Netzwerk-Freigaben verschlüsseln. Obwohl die Datei-Verschlüsselung sehr stark ist, laden die Angreifer:innen als doppelte Erpressungsstrategie auch noch Dateien auf ihre Server hoch und zwingen die betroffenen Opfer dadurch, nicht nur für die Entschlüsselung, sondern auch für die Geheimhaltung ihrer vertraulichen Daten ein Lösegeld zu zahlen.

SHA256

571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b

URL