LockBit-Ransomware über Apache-ActiveMQ-Lücke: Angriff in zwei Wellen

Ein ungepatchter Apache-ActiveMQ-Server wurde zum Einfallstor für einen mehrstufigen Ransomware-Angriff, der sich über knapp 19 Tage erstreckte. Das geht aus einer Analyse von The DFIR Report hervor. Nachdem der Angreifer zunächst vertrieben wurde, kehrte er über denselben Angriffsweg zurück und setzte LockBit-Ransomware im gesamten Netzwerk ein – offenbar auf Basis des geleakten LockBit-Builders.

Erster Zugriff über bekannte Schwachstelle

Im Februar 2024 kompromittierte ein unbekannter Angreifer einen Windows-Server, auf dem eine verwundbare Version von Apache ActiveMQ betrieben wurde. Grundlage war die Schwachstelle CVE-2023-46604, die eine Remote Code Execution (RCE) ermöglicht. Laut den Sicherheitsexperten übermittelte der Angreifer einen manipulierten OpenWire-Befehl an den Server und lud über die Java-Klasse ClassPathXmlApplicationContext eine bösartig präparierte XML-Konfigurationsdatei nach. Diese enthielt Anweisungen, die auf dem kompromittierten System ausgeführt wurden.

Zur Übertragung der eigentlichen Schadsoftware setzte der Angreifer das Windows-Bordmittel CertUtil ein. Die heruntergeladene Datei entpuppte sich als Metasploit-Stager, der eine verschlüsselte Verbindung zu einem vom Angreifer kontrollierten Command-and-Control-Server aufbaute.

Grafik Quelle: The DFIR Report

Privilegieneskalation und Ausbreitung im Netzwerk

Rund 40 Minuten nach dem ersten Zugriff führte der Angreifer über die Meterpreter-Shell den Befehl GetSystem aus und erlangte damit SYSTEM-Rechte auf dem betroffenen Host. Anschließend griff er auf den Arbeitsspeicher des LSASS-Prozesses zu – eine gängige Methode zur Extraktion von Zugangsdaten.

Etwa 20 Minuten später war ein deutlicher Anstieg des SMB-Datenverkehrs vom kompromittierten Ausgangssystem in Richtung anderer Netzwerkknoten zu beobachten, was auf einen Netzwerk-Scan hindeutete. Unter Verwendung eines Domänenadministratorkontos führte der Angreifer anschließend Remote-Dienste auf mehreren Hosts aus und platzierte weitere Metasploit-Payloads. Auf einigen dieser Systeme wurde ebenfalls auf den LSASS-Speicher zugegriffen.

Aktive Antivirenlösungen auf einzelnen Hosts erkannten und blockierten Teile dieser Aktivitäten, was letztlich dazu beitrug, dass der Angreifer am zweiten Tag den Zugang zur Umgebung verlor.

Grafik Quelle: The DFIR Report

Zweite Einbruchswelle nach 18 Tagen

Da das betroffene System in der Zwischenzeit nicht gepatcht wurde, gelang dem Angreifer 18 Tage nach dem ersten Einbruch die erneute Kompromittierung über denselben Angriffsweg. Er verwendete dabei identische Techniken, lediglich die Dateinamen der nachgeladenen Komponenten wurden angepasst.

Nach dem zweiten Zugriff prüfte der Angreifer zunächst die Zusammensetzung der Domänenadministratorengruppe und bewegte sich anschließend innerhalb von 20 Minuten lateral zu mehreren Servern, darunter Domänencontroller. Für diese Aktivitäten nutzte er das privilegierte Dienstkonto, dessen Zugangsdaten beim ersten Einbruch aus dem LSASS-Speicher extrahiert worden waren – so die Analyse.

Parallel dazu baute er über RDP Verbindungen zu einem Backup- und einem Dateiserver auf. Zur Absicherung des Zugriffs installierte er das Fernwartungstool AnyDesk und stellte über eine Batch-Datei sicher, dass RDP aktiviert und der entsprechende Port freigegeben war.

Ransomware-Einsatz im laufenden Betrieb

Über den injizierten Winlogon-Prozess wurden zwei ausführbare Dateien auf dem Ausgangssystem abgelegt: LB3.exe und LB3_pass.exe. Beide Dateien wurden als LockBit-Ransomware identifiziert. Die Auswertung der hinterlassenen Lösegeldforderung legte nahe, dass die Ransomware mit dem öffentlich zugänglich gemachten LockBit-Black-Builder erstellt wurde – einem Werkzeug, das nach einem Leak von Dritten für eigene Angriffe genutzt werden kann.

Der Angreifer verteilte die Ransomware-Dateien manuell über RDP-Sitzungen auf die Zielsysteme. Auf dem Datei- und Backup-Server wurde LB3_pass.exe mit spezifischen Pfad- und Passwortparametern ausgeführt. Auf anderen Hosts startete LB3.exe über den Windows Explorer mit der Option -psex, die einen PsExec-artigen SMB-Verbreitungsmechanismus auslöste.

Die Verschlüsselung der betroffenen Systeme erfolgte innerhalb weniger Stunden. Gleichzeitig wurden Lösegeldforderungen in betroffene Verzeichnisse geschrieben und Desktop-Hintergründe der kompromittierten Rechner ausgetauscht.

Abweichende Kommunikationswege als Hinweis auf unabhängigen Akteur

Auffällig war die Lösegeldforderung selbst: Statt wie bei LockBit üblich auf Tor-basierte Seiten oder Kommunikation über TOX bzw. Jabber hinzuweisen, wurden die Opfer angewiesen, den verschlüsselten Messaging-Dienst Session zu nutzen. Die Experten werten das Fehlen jeglicher Verbindung zur offiziellen LockBit-Infrastruktur sowie die veränderte Nachricht als Hinweis darauf, dass es sich um einen unabhängig agierenden Angreifer handelt, der den geleakten Builder für eine eigenständige Kampagne einsetzte.

Zeitlicher Verlauf unterstreicht Handlungsbedarf bei Patch-Management

Die sogenannte Time to Ransomware (TTR) – also die Zeitspanne vom ersten Zugriff bis zur Ransomware-Ausführung – betrug in diesem Fall rund 419 Stunden, entsprechend etwa 19 Kalendertagen. Wäre der erste Einbruch unentdeckt geblieben und die Aktivitäten erst beim zweiten Anlauf bemerkt worden, hätte die Zeitspanne bis zur Ransomware-Ausführung weniger als 90 Minuten betragen. Der ungepatchte Server war dabei der entscheidende Faktor, der dem Angreifer den Wiedereinstieg ermöglichte.

„Die in diesem Beitrag veröffentlichten Informationen wurden sorgfältig recherchiert. Dennoch übernehmen wir keine Gewähr für Vollständigkeit oder absolute Richtigkeit. Die Inhalte dienen der allgemeinen Orientierung und ersetzen keine fachkundige Beratung. Für etwaige Fehler, Auslassungen oder Folgen aus der Nutzung der Informationen übernimmt die Redaktion keine Haftung. Trotz sorgfältiger Prüfung können vereinzelt unbeabsichtigte Fehler oder Ungenauigkeiten, etwa bei Übersetzungen, auftreten.“

Auch interessant:

 

---