Zum Hauptinhalt springen
Bild für Desktop: CTI-Blog 3 - breit
Ein aufkommendes Thema

CTI Roundup: BERT Ransomware, TGR-CRI-0045, XWorm

Die Ransomware „BERT“ zielt auf Windows- und Linux-Plattformen ab, „ TGR-CRI-0045 “ nutzt durchgesickerte Geräteschlüssel aus, um sich Zugang zu Unternehmen zu verschaffen, und „XWorm“ entwickelt sich zu einem modularen und schwer zu erkennenden Fernzugriffstrojaner

In der Zusammenfassung dieser Woche befasst sich das Cyber Threat Intelligence (CTI)-Team von Tanium mit der kürzlich aufgetauchten Ransomware-Gruppe „BERT“, die nun Windows- und Linux-Plattformen in den Bereichen Technologie, Gesundheitswesen und Veranstaltungsdienstleistungen ins Visier nimmt. Als Nächstes befasst sich das Team mit einer Kampagne eines Initial Access Brokers (IAB), der vorläufig unter der Kennung TGR-CRI-0045 erfasst wird. Abschließend untersuchen wir die Entwicklung von XWorm zu einem äußerst anpassungsfähigen Fernzugriffstrojaner (RAT).

Die Ransomware „BERT“ zielt auf Windows- und Linux-Plattformen ab

Trend Micro hat unter Einzelheiten zur neu aufgetauchten Ransomware-Gruppe „BERT“ veröffentlicht. Die Gruppe, die bereits seit dem Jahr „ April 2025“ aktiv ist, richtet ihre Angriffe nun gegen Organisationen in Asien, Europa und den Vereinigten Staaten und führt dabei plattformübergreifende Angriffe sowohl auf Windows- als auch auf Linux-Systeme durch.

Obwohl der Code einfach aufgebaut ist, setzt BERT aggressive Taktiken wie parallele Verschlüsselung und das Herunterfahren von ESXi-Systemen ein, um die Störungen zu maximieren und den Druck bei den Lösegeldforderungen zu erhöhen.

Wie funktioniert die Windows-Variante von BERT?

Laut Trend Micro verwendet die Gruppe für die Windows-Version ihrer Ransomware eine einfache Codestruktur mit bestimmten Zeichenfolgen, die Prozesse beenden.

Trend Micro stellte fest, dass der öffentliche Schlüssel, die Dateiendung und die Lösegeldforderung im Code leicht zugänglich waren, und identifizierte die Verwendung des Standard-AES-Algorithmus zur Verschlüsselung.

[Lesen Sie auch: Die Kunst der Verhandlungen bei Ransomware-Angriffen]

Trend Micro identifizierte zudem weitere BERT-Beispiele, die im Internet hochgeladen worden waren. Viele davon schienen ältere Versionen zu sein, denen die Verschlüsselung und andere Elemente fehlten, die in ihrer eigenen internen Telemetrie zu erkennen waren, was darauf hindeutet, dass es mehrere Iterationen von BERT gegeben hat.

Darüber hinaus hat Trend Micro ein PowerShell-Skript identifiziert, das als Loader für die eigentliche BERT-Ransomware-Nutzlast fungiert. Dieses PowerShell-Skript „erweitert die Berechtigungen, deaktiviert Windows Defender, die Firewall und die Benutzerkontensteuerung (UAC) und lädt anschließend die Ransomware von einer entfernten IP-Adresse herunter und führt sie aus.“

Entwicklung der BERT-Varianten

Ältere Varianten zählten zunächst die Laufwerke auf und legten die Lösegeldforderung in jedem Verzeichnis ab. Anschließend würden sie die erforderlichen Dateipfade erfassen, diese in einem Array speichern und mit der Verschlüsselung fortfahren.

Die neuere Variante nutzt „ “ (ConcurrentQueue) und erstellt auf jedem Laufwerk einen „ “ (DiskWorker) , um den Verschlüsselungsprozess zu optimieren. Dieser Ansatz ermöglicht eine multithreaded-Verschlüsselung, wodurch BERT bereits mit der Verschlüsselung von Dateien beginnen kann, sobald diese identifiziert werden, anstatt abzuwarten, bis alle Dateipfade erfasst sind – was die Geschwindigkeit und die Wirksamkeit erheblich steigert.

Was Sie über die Linux-Variante wissen sollten

Im Mai stieß Trend Micro auf eine BERT-Linux-Variante, die 50 Threads nutzt, um die Verschlüsselungsgeschwindigkeit zu maximieren. Diese Variante akzeptiert drei Befehlszeilenparameter:

  1. So geben Sie das zu verschlüsselnde Zielverzeichnis an
  2. So legen Sie die Anzahl der Threads für die Verschlüsselung fest (Standardwert ist 50)
  3. So aktivieren Sie den stillen Modus

Wird die Ransomware ohne diese Parameter ausgeführt, fährt sie die virtuellen Maschinen herunter und beendet dabei alle laufenden Prozesse der virtuellen Maschinen auf dem ESXi-Host. Sobald diese Variante ihren Verschlüsselungsvorgang abgeschlossen hat, fügt sie an jede Datei die Endung „ .encrypted_by_bert“ an und hinterlässt die Lösegeldforderung.

Trend Micro geht davon aus, dass die Gruppe diese Variante möglicherweise von der Linux-Variante von REvil abgeleitet hat.

Analystenkommentare des Cyber Threat Intelligence-Teams von Tanium

Es ist erst wenige Monate her, seit BERT aufgetaucht ist, doch es gibt bereits Varianten, die sowohl auf Windows- als auch auf Linux-Systeme abzielen – was einen zunehmenden Trend unter Angreifern verdeutlicht, Malware und Ransomware so zu entwickeln, dass sie hybride Umgebungen ausnutzen.

Das Fazit lautet, dass der Quellcode von BERT zwar relativ einfach ist, die dahinter stehende Gruppe jedoch hervorragende Fähigkeiten bei der Umsetzung von Angriffen besitzt. Dies macht deutlich, dass die Wirksamkeit einer Bedrohung nicht immer mit ihrer technischen Komplexität zusammenhängt.

TGR-CRI-0045 nutzt durchgesickerte Geräteschlüssel aus, um sich Zugang zu Unternehmen zu verschaffen

Palo Alto hat kürzlich die Kampagne „ “ aufgedeckt, die von einer IAB durchgeführt wird und die vorübergehend unter der Kennung TGR-CRI-0045 erfasst wird.

Es wurde beobachtet, dass dieser Akteur durchgesickerte ASP.NET-Systemschlüssel ausnutzte, um Sitzungen zu kapern und sich unbefugten Zugriff auf Microsoft Internet Information Services (IIS)-Server zu verschaffen, was eine verdeckte Persistenz und weitere Kompromittierungen ermöglichte.

Wie dieser IIS-Exploit entdeckt wurde

Anfang dieses Jahres reagierte Palo Alto auf Angriffe auf Webserver in zwei verschiedenen Kundenumgebungen. Bei beiden Angriffen kam es zur Ausführung einer Befehlsshell, die von einem IIS-Workerprozess ausging, und beide wiesen gemeinsame Merkmale auf.

Die Untersuchung ergab, dass der Angreifer „Befehle ausführte, mit denen verwaltete .NET-Assemblies (C#-Code) direkt in den Arbeitsspeicher geladen wurden (reflektives Laden).“ Dieser Exploit zielte auf den „View State“ ab, einen Parameter innerhalb von ASP.NET-Websites, die auf Microsoft IIS ausgeführt werden.

Die Exploit-Kette „TGR-CRI-0045 “ erklärt

Websites nutzen „View State“, um die Interaktionen zwischen Browsern und Servern zu verwalten. Wie sich herausstellt, weist der Parameter „ _VIEWSTATE “ eine Sicherheitslücke auf, die durch Deserialisierungstechniken ausgenutzt werden kann, mit denen Angreifer die Ausführung von Code aus der Ferne ermöglichen können. Dies kann jedoch nur geschehen, wenn der Angreifer über den richtigen Maschinenschlüssel verfügt.

Es ist bekannt, dass Angreifer entweder Listen mit durchgesickerten Maschinenschlüsseln verwenden oder die Schlüssel direkt von laufenden Servern extrahieren. Sobald sie über diese Schlüssel verfügen – unabhängig davon, auf welche Weise sie an sie gelangt sind –, können sie die Deserialisierungs-Nutzlast erstellen und den Server angreifen.

Nach Angaben von Palo Alto nutzte TGR-CRI-0045 vermutlich Tools wie , ysoserial.net und – einen Open-Source-Payload-Generator zur Erstellung bösartiger Deserialisierungs-Payloads.

Die Baugruppen verstehen

Palo Alto identifizierte fünf Teilmengen von .NET-Assemblies, die in den Arbeitsspeicher geladen wurden, nachdem der Angreifer den View-State ausgenutzt hatte. Dazu gehören:

  1. cmd /c: Führt beliebige Systembefehle auf dem kompromittierten Server aus
  2. Gewinner: Wird vermutlich zur Überprüfung einer erfolgreichen Ausnutzung oder der Betriebsbereitschaft der Umgebung verwendet
  3. Datei-Upload: Ermöglicht es dem Angreifer, schädliche Dateien oder Tools direkt auf den Server hochzuladen, um diese für weitere Angriffe zu nutzen oder eine dauerhafte Präsenz zu etablieren
  4. Dateidownload: Ermöglicht es dem Angreifer, sensible Daten zu entwenden oder Payloads aus der kompromittierten Umgebung abzurufen
  5. Reflective Loader: Lädt .NET-Assemblies direkt in den Arbeitsspeicher und führt sie dort aus, ohne die Festplatte zu belasten – eine wichtige Umgehungstechnik, die das Schreiben von Artefakten auf die Festplatte verhindert und dabei hilft, herkömmliche Erkennungsmethoden zu umgehen

Diese Assemblies wiesen alle ähnliche Merkmale bei der Datenverarbeitung auf und führen dieselben Aufrufe aus, um HTTP-Antworten zu beenden.

[Lesen Sie auch: Schützen Sie Ihre Eingabeaufforderungen: Ihre KI-Tools sind von Injektionsangriffen bedroht]

Was geschieht nach der Ausbeutung?

Zu den Aktivitäten dieses Akteurs nach der Ausnutzung gehörten Erkundungsmaßnahmen sowohl auf dem kompromittierten Host als auch im Netzwerk. Palo Alto stellt fest, dass der Akteur durchgängig den Pfad „ Windows\Temp\111t “ als Staging-Verzeichnis verwendet hat.

Zur Ausweitung der Berechtigungen nutzte der Angreifer eine benutzerdefinierte Binärdatei updf, die Befehle mit SYSTEM-Berechtigungen ausführen sowie neue lokale Benutzer anlegen und diese der lokalen Administratorengruppe hinzufügen kann.

Der Akteur lud zudem regelmäßig eine ELF-Binärdatei namens „ “ (derzeit unter) herunter, nutzte „ “ (TxPortMap, ), um festzustellen, welche Server von dem ursprünglich kompromittierten Gerät aus erreichbar waren, und führte über die Befehlsshell-Assembly Erkundungsmaßnahmen durch.

Analystenkommentare des Cyber Threat Intelligence-Teams von Tanium

Die Analyse von Palo Alto zeigt, wie sich IABs hinsichtlich ihrer technischen Ausgereiftheit weiterentwickeln. Sie verlassen sich nicht mehr ausschließlich auf traditionelle Techniken wie „ “, Phishing oder Brute-Force-Angriffe.

Die Analyse macht zudem deutlich, dass die Verwaltung von Geheimnissen wie Maschinenschlüsseln genauso behandelt werden sollte wie die von Anmeldedaten oder API-Tokens, da deren Missbrauch zu schwerwiegenden Sicherheitsvorfällen führen kann.

Der Bericht enthält Anleitungen zur Behebung und Absicherung von „ “ () sowie eine umfassendere Zusammenfassung der Auswirkungen von In-Memory-IIS-Angriffstechniken.

XWorm entwickelt sich zu einer modularen und schwer aufzuspürenden RAT

Laut dem Splunk- hat sich XWorm zu einem modularen Fernzugriffstrojaner weiterentwickelt, der wechselnde Dateiformate, Skriptsprachen und Verschleierungstechniken nutzt, um einer Erkennung zu entgehen und Schadcode zu verbreiten.

Die Analyse von Splunk hebt den modularen Aufbau der Malware sowie deren Verbindungen zu Ransomware-Operationen hervor. Der Bericht enthält zudem umsetzbare Erkennungsstrategien, die den Sicherheitsverantwortlichen dabei helfen sollen, diesem verdeckten Verhalten entgegenzuwirken.

Der Aufbau eines XWorm-Phishing-Angriffs

Splunk stellt fest, dass XWorm im Rahmen einer umfassenderen Strategie zur Umgehung von Abwehrmaßnahmen zwischen verschiedenen Dateiformaten und Skriptsprachen wechselt. Die Malware nutzt in ihrer Infektionskette zudem eine Reihe von Droppern, Stagern und Ladeprogrammen.

Die Analysten haben sich eingehender mit XWorm befasst, um die verschiedenen Dateiformate zu identifizieren, die er verwendet. Das Team entnahm 1 000 XWorm-Proben aus dem „Malware Bazaar“ und suchte dabei nach weiteren einzigartigen Dateitypen anstelle der herkömmlichen EXE- und DLL-Dateien. Zu den am häufigsten verwendeten Dateiformaten zählen VBS, Batch, JavaScript und PowerShell. Dateien dieser Art werden häufig per E-Mail übermittelt.

Ebenso hat Splunk Dateinamen analysiert, um zu ermitteln, welche Art von Social-Engineering-Köder von XWorm am häufigsten verwendet wird. Sie stellten fest, dass sich mehrere Themen immer wiederholten, darunter Rechnungen, Quittungen und Versandbenachrichtigungen.

Einige der Skriptkomponenten laden die Haupt-Payload von XWorm direkt vom C2 -Server herunter. Im Zuge der Untersuchung stieß Splunk auf HTA-Dateien und PowerShell-Stager, die als erste Stufe fungierten und für das Herunterladen der Payload der nächsten Stufe zuständig waren.

Wie XWorm seine Schadcodes einsetzt

Splunk identifizierte VBS- und Batch-Skript-Stager, die verschleiert wurden, um die Codeanalyse zu erschweren und einer Erkennung zu entgehen.

Diese Skripte dekodieren und entschlüsseln zwei ausführbare Dateien direkt im Speicher – eine gängige Technik, um das Schreiben auf die Festplatte zu vermeiden und einer Erkennung zu entgehen. Diese ausführbaren Dateien fungieren als Stager und Loader der nächsten Stufe und sind dafür zuständig, zusätzliche Komponenten bereitzustellen und schließlich die XWorm-Nutzlast zu implementieren:

  1. Stager: Umgeht AMSI (Antimalware Scan Interface), um die Skriptprüfung zu deaktivieren
  2. Loader: Manipuliert Windows ETW (Event Tracing for Windows), um der Laufzeitüberwachung zu entgehen

Beide sind als Anti-Analyse-Mechanismen konzipiert, um die Erkennbarkeit zu verringern und die Aufdeckung zu erschweren.

Der Stager sorgt zudem für Persistenz und erweitert die Berechtigungen, indem er Registrierungsschlüssel für die Ausführung sowie geplante Aufgaben erstellt. Es versucht, GZIP-Daten aus seinen Ressourcenabschnitten zu entpacken, nutzt das seitliche Laden von DLLs, um bösartigen Code als legitime Bibliotheken zu tarnen, und injiziert Shellcode in Zielprozesse, um Payloads im Speicher auszuführen.

Was die XWorm-Nutzlast nach der Infektion tut

Die endgültige XWorm-Nutzlast ist eine entschlüsselte ausführbare Datei (payload.exe). XWorm nutzt WMI (Windows Management Instrumentation), um eine Erkundung des Hosts durchzuführen, einschließlich der Identifizierung verfügbarer Webcams. Wie andere Arten von Malware nutzt auch XWorm die Ausschlusseinstellungen von Microsoft Defender, um zu verhindern, dass sein Verzeichnis gescannt wird.

Splunk hat zudem eine Funktion namens „ RunDisk()“ identifiziert, die eine PowerShell-Komponente mit einer geänderten Ausführungsrichtlinie ausführt. Die Malware versucht, sich über Wechseldatenträger zu verbreiten, und verfügt über eine Funktion zur Ausführung von Backdoor-Befehlen. Ähnlich wie der Stager und die Loader nutzt die Malware Registrierungsschlüssel für die Ausführung sowie geplante Aufgaben, um ihre Persistenz zu gewährleisten.

Analystenkommentare des Cyber Threat Intelligence-Teams von Tanium

XWorm ist äußerst anpassungsfähig und stellt die Verteidiger vor eine Reihe einzigartiger Herausforderungen.

Seine Entwicklung spiegelt einen allgemeinen Trend hin zu größerer Modularität und verbesserten Ausweichfähigkeiten wider. Dies dürfte in Verbindung mit der Verwendung wechselnder Dateiformate und Skriptsprachen die Erfolgsquote verbessern und die Attraktivität für Angreifer erhöhen.

Die Analyse von Splunk unterstreicht zudem die Bedeutung von verhaltensbasierten Erkennungsmechanismen – beispielsweise bei verdächtigen Aktivitäten in der Registrierungsdatenbank – im Gegensatz zu statischen Indikatoren.

Haben Sie Einblicke in diese Geschichten, die Sie gerne weitergeben möchten? Besuchen Sie das Tanium-Diskussionsforum unter , um eine Diskussion zu starten.

Wenn Sie sich weiter informieren möchten, lesen Sie unsere aktuellen Zusammenfassungen zu Cyber-Bedrohungsinformationen von unter.