Zurück zur Übersicht
6 min Lesezeit

8base Ransomware-Angriff liefert überraschende Erkenntnisse

6 min Lesezeit
November 19, 2024
Autor Eye Security Incident Response Team
Ransomware-Angriff bewältigen
Autor Eye Security Incident Response Team
19 November 2024

Aus fast jedem Einsatz des Eye Security Incident Response-Teams lernen wir etwas Neues. Wir teilen dies Erkenntnisse mit Fachleuten für Cybersicherheit und IT, denn das Wissen um Taktiken, Techniken und Verfahren (TTPs) eines Angreifers kann anderen Incident-Respondern nützlich sein. Wenn Sie einen Ransomware-Angriff erfolgreich zugeordnet haben, verschafft Ihnen die Kenntnis des Modus Operandi des Angreifers einen erheblichen Vorteil.

Bei einem kürzlichen Vorfall, den wir der Ransomware-Gruppe 8Base zuschreiben, haben wir mehrere neue und interessante TTPs beobachtet, die wir im Folgenden vorstellen.  

Hintergrund der Ransomware-Untersuchung

Wir wurden von einem Unternehmen kontaktiert, das von einem erfolgreichen Ransomware-Angriff betroffen war. In diesem Blog-Beitrag werden wir dieses Unternehmen als "das Ziel" bezeichnen. Wir arbeiteten mit den Führungskräften und dem IT-Team zusammen, um den Vorfall schnell zu untersuchen und zu beheben. Mit Erfolg, denn wir konnten die Infrastruktur schnell wiederherstellen, ohne dass das Lösegeld gezahlt werden musste.   

Um die Vertraulichkeit und Anonymität des Kunden zu wahren, können wir nicht alle Einzelheiten detailliert beschreiben. Die folgenden Informationen werden Ihnen dennoch interessante Einblicke bieten.  

Die Entdeckung des Ransomware-Angriffs   

Die Zielperson entdeckte eine Ransomware-Nachricht, die auf einem der betroffenen Hosts hinterlassen wurde. Dies führte sofort zu unserer ersten überraschenden Entdeckung: Die Ransomware-Nachricht war mit einer ungenutzten und offline geschalteten .onion-Site verknüpft. Dies ist wahrscheinlich darauf zurückzuführen, dass eine veraltete Version eines Verschlüsselungsprogramms verwendet wurde. Selbst wenn die Zielperson das Lösegeld hätte zahlen wollen, hätte sie keine Möglichkeit gehabt, mit dem Angreifer in Kontakt zu treten.   

Dies schien ein Irrtum zu sein, was uns zu der Vermutung veranlasste, dass der Bedrohungsakteur, der sich als die 8Base-Ransomware-Gruppe ausgab, vielleicht gar nicht verantwortlich war. Wir blieben jedoch unvoreingenommen, da es bei der Reaktion auf Vorfälle von großem Vorteil ist, den Gegner und seine TTPs zu kennen. Später, als die Leak-Site der 8Base-Gruppe mit den vom Ziel gestohlenen Informationen aktualisiert wurde, bestätigten wir, dass wir es mit 8Base zu tun hatten 

Bei der Untersuchung stellte sich heraus, dass der Angriff auf das Wochenende terminiert war, als das Ziel wahrscheinlich am anfälligsten war. Der Zeitplan und die Maßnahmen werden im Folgenden erläutert.         

Ransomware-Attacke Tag 1 

  1. Der erste Zugriff erfolgte über das SSL-VPN des Ziels. Der Bedrohungsakteur verwendete ein Service-Account mit hohen Berechtigungen. Wir haben keine erfolglosen Anmeldeversuche beobachtet. Die Anmeldedaten befanden sich also bereits im Besitz des Angreifers. Da es sich um ein Service-Account handelte, konnten sie nicht durch einen früheren Phishing-Angriff erlangt worden sein. Wir vermuten, dass sie von einem Initial Access Broker (IAB) erlangt wurden. Bei der Durchsuchung der Protokolle wurden keine weiteren Informationen gefunden, so dass wir davon ausgehen, dass sie bereits vor einiger Zeit kompromittiert wurden.   
  2. Der Bedrohungsakteur wechselte unmittelbar nach dem Aufbau der SSL-VPN-Verbindung seitlich zu einem anderen Host im Netzwerk. Dies wurde von der Endpoint Detection and Response (EDR) des Hosts erkannt.  Die daraus resultierende Warnung blieb jedoch unbemerkt. Der Angreifer fuhr damit fort, die Registrierungsstruktur zu löschen und seinen Erkundungsprozess fortzusetzen. Nach ein paar Stunden wurden die Aktivitäten im VPN eingestellt.  

Ransomware-Attacke Tag 2 

  1. Der Angreifer kehrte in den frühen Abendstunden zurück. Aus den Firewall-Protokollen geht hervor, dass das gesamte /24-Subnetz auf sechzehn verschiedene TCP-Ports gescannt wurde (TCP-Ports: 22, 80, 135, 139, 443, 445, 1556, 3389, 4119, 4343, 5800, 5900, 8000, 8080, 9392, 9443, UDP-Ports: 137, 161, 5353). Mindestens einer dieser Ports wird von Backup-Lösungen wie Veeam verwendet (z.B. tcp/9392). Wie zu erwarten war, suchten die Akteure aktiv nach Backups und sabotierten diese, was eine Standardvorbereitung für einen Ransomware-Angriff ist. 
  2. Der Angreifer verschaffte sich dann Zugriff auf den Domain Controller. Es ist unklar, wie er die Anmeldeinformationen erhalten hat. Wir vermuten, dass sie aus dem Registry Hive Dump von Tag 1 stammen, da es auf keinem der Hosts im Angriffspfad Warnungen in Bezug auf den Missbrauch von Anmeldeinformationen gab, wie z. B. einen LSASS-Dump. Wenn sie bereits vor Beginn des Angriffs im Besitz dieser Daten waren, haben sie sie wahrscheinlich für den ersten Zugriff verwendet. 8Base ist nicht für subtile Methoden bekannt und zieht Geschwindigkeit der Geheimhaltung vor. Die anfängliche Verwendung dieser Anmeldedaten hätte ihr Vorankommen sicherlich beschleunigt.
  3. Der Fortschritt wurde noch dadurch beschleunigt, dass ein zweiter Angreifer "Hand anlegte". Wir entdeckten eine zweite IP-Adresse auf dem SSL-VPN und wussten nun, dass zwei Bedrohungsakteure beteiligt waren, die beide virtuelle Windows-Maschinen (VM) verwendeten.  
  4. Als nächstes wurden die Angreifer beim Zugriff auf Dateifreigaben beobachtet. Sie setzten alle ihre Aktivitäten über das SSL-VPN fort und unternahmen in dieser Phase keine Versuche, Malware zu installieren, um einen Host vor Ort zu kompromittieren, oder zur Tarnung auf einen Bastion-Host auszuweichen. Wahrscheinlich war ihnen klar, dass sie das SSL-VPN frei nutzen konnten, warum also den Angriff übermäßig verkomplizieren.  
  5. Die Angreifer machten dann mehrere "Fehler", als sie sich über RDP mit den Windows-Hosts der Ziele verbanden. Wir haben beobachtet, dass ein neuer Windows-Hostname auf das VPN zugreift, den wir nun für zukünftige Zwecke mit der Gruppe verknüpfen können. Anschließend versuchten sie, sich bei den Hosts der Ziele als UserName und kali anzumelden. Dies sind die Standardanmeldungen, die die von ihnen verwendeten Tools für den Zugriff auf die Zielhosts verwenden. Dass sie diese nicht durch die korrekten, kompromittierten Anmeldedaten ersetzt haben, zeigt ihre etwas aggressive Vorgehensweise und ihre Vorliebe für Geschwindigkeit.

Ransomware-Attacke Tag 3 

  1. Die Angreifer kehrten mitten in der Nacht/am nächsten Morgen ein letztes Mal zurück und nutzten weiterhin das SSL-VPN als Zugangspunkt zum Netzwerk des Ziels. In dieser letzten Phase kompromittierten sie einen Windows-Host und luden ihre Tools auf ihn herunter. Wir entdeckten Netscan, ihren Verschlüsseler (namens Fast.exe) und Anydesk, ein Tool zur Fernüberwachung und -verwaltung (RMM). Dies ist ein weiterer Schritt, der zu EDR-Warnungen führte. Bei einer Überwachung hätten diese zur Entdeckung der Angreifer geführt. Zu diesem Zeitpunkt waren sie wahrscheinlich schon ziemlich sicher, dass ihre Aktivitäten nicht überwacht wurden.  Also machten sie weiter und erzeugten eine beträchtliche Anzahl von EDR-Warnungen des Zielunternehmens.
  2. Als nächstes initiierten die Angreifer eine FTP-Sitzung direkt über das Internet von einem kompromittierten Host zu ihrer Windows-VM. Sie nutzten dies, um Dutzende von Gigabyte an Daten zu exfiltrieren. Dies alles wurde von der Firewall des Ziels überwacht und protokolliert—ein weiteres Zeichen für einen laufenden Angriff. 
  3. Der letzte Akt war die Verschlüsselung der Daten des Ziels über dessen VMWare-Instanz. Überraschenderweise verwendeten die Angreifer keinen Verschlüsseler, der direkt auf einem ESXi-Hypervisor läuft, sondern hängten die Festplatten auf eine kompromittierte Windows-VM im Netzwerk des Ziels an und verschlüsselten sie von dort aus. Dies ist eine neue TTP, die wir in den von uns verwendeten OSINT-Quellen noch nicht gesehen haben. Dies hätte länger gedauert als die Verwendung eines direkt auf dem Hypervisor installierten Verschlüsselungsprogramms. Aber wie wir gesehen haben, waren diese Angreifer nun von ihrem Erfolg überzeugt. Selbst wenn sie entdeckt würden und es ihnen nicht gelänge, alle Daten des Opfers zu verschlüsseln, könnten sie diese erpressen, da sie drohen könnten, die bereits exfiltrierten Daten weiterzugeben.

Die Wiederherstellungsphase 

Nach der Ausführung des Verschlüsselungsprogramms waren die VMWare ESXi-Maschinen nicht mehr startfähig. Mehrere von ihnen wurden unbrauchbar und mussten neu installiert werden.   

Als wir einen ESXi entdeckten, bei dem die Ransomware-Binärdatei noch in einer virtuellen Gastmaschine lief, besuchte ein Mitarbeiter von Eye Security die Büros des Unternehmens, um den Vorfall persönlich zu untersuchen. Wir beobachteten, dass neue Dateien auf der Festplatte des ESXi verschlüsselt wurden, sobald sie erstellt wurden. Wir sammelten Protokolle und forensische Artefakte, um zu versuchen, die verwendeten Verschlüsselungsschlüssel zu ermitteln. Dann beschlossen wir, die ESXi-Maschinen komplett neu zu installieren. (Weitere Informationen finden Sie unter 8Base Ransomware - Wiederherstellung von Schlüsseln und Dateien).   

Zum Modus Operandi von 8base gehört es, aktiv nach lokalen Backups zu suchen und diese zu zerstören. Glücklicherweise hatte das Unternehmen unveränderliche Backups außerhalb des Standorts, von denen die gesamte Infrastruktur wiederhergestellt werden konnte.   

Jedes wiederhergestellte System wurde in einer eingeschränkten Netzwerkumgebung online geschaltet, so dass unsere Incident Response Spezialisten unseren bevorzugten EDR-Agenten einsetzen konnten. Auf diese Weise konnten wir die wiederhergestellten Systeme sofort auf Anzeichen verdächtigen Verhaltens, wie z. B. Hintertüren, überprüfen, sie weiter überwachen und digitale forensische Beweise sammeln.   

Dies ist ein Standardelement des Incident Response Service von Eye Security. Wir melden die Endgeräte unserer Kunden automatisch für einen Monat bei unserem MDR-Service an. Dieser Ansatz ermöglicht eine schnelle und sichere Wiederherstellung der Umgebung. Bedrohungen werden frühzeitig erkannt und neutralisiert, was die Zeit bis zur Wiederaufnahme des normalen Betriebs erheblich verkürzt.   

Dank des besonders wirksamen Wiederherstellungskonzepts von Eye Security konnte die Umgebung des Kunden innerhalb von 12 Tagen vollständig wiederhergestellt werden, mit minimalen Auswirkungen auf den Geschäftsbetrieb. Während des Prozesses wurden alle Risiken durch den Managed Detection und Response Dienst von Eye Security vollständig entschärft. 

Schlussfolgerung

8base ist derzeit eine der aktivsten Ransomware-Gruppen, und wie Sie sehen können, sind sie mit ihren Methoden nicht zimperlich. Dies führt zu mehr Schaden als nur zu verschlüsselten Dateien, wie die zerstörten ESXi-Hosts zeigen. Man könnte annehmen, dass die Opfer es sich zweimal überlegen, ob sie ihre Daten entschlüsseln wollen, wenn sie sich über das Ausmaß der Wiederherstellung im Klaren sind. Und das selbst nachdem sie für die Schlüssel zur Entschlüsselung ihrer Daten bezahlt haben.     

Auch den letzten Teil dieser Geschichte wollen wir Ihnen nicht vorenthalten. Eye Security und die Teams des Unternehmens haben 8Base während des gesamten Prozesses nicht kontaktiert. Selbst wenn das Opfer das Lösegeld hätte zahlen wollen, konnte sie das nicht, da der Link zur .onion-Website in der Ransomware-Notiz nicht verfügbar war. Die Zielperson erhielt eine Reihe von E-Mails und dann einen Telefonanruf im Zusammenhang mit dem Angriff. Der Anrufer gab vor, im Namen von 8Base zu handeln und über das Lösegeld verhandeln zu wollen. Aber sie kamen viel zu spät, selbst wenn die Zielperson interessiert gewesen wäre.      

Alles in allem war dieser Ransomware-Fall weder raffiniert noch fortschrittlich. 8base hatte keine Probleme, auf das Netzwerk des Ziels zuzugreifen und es auszunutzen, und wurde zu keinem Zeitpunkt abgewehrt, obwohl die bereits vorhandene EDR-Lösung verwertbare Warnmeldungen generierte. Wäre nach einer dieser frühen Warnungen ein menschliches Eingreifen erfolgt, hätte es der Angreifer viel schwerer gehabt, und der gesamte Vorfall wäre wahrscheinlich verhindert worden.  

Wie man den Angreifern einen Schritt voraus ist  

Während dieses Angriffs gab es mehrere Phasen, in denen eine Aktivität einen Alarm auslöste, der hätte untersucht werden müssen. Der Zeitpunkt des Angriffs spielte jedoch eine wichtige Rolle für seinen Erfolg.   

Dies ist jedoch nicht ungewöhnlich—die Angreifer wissen, dass viele Organisationen weder das Budget noch die Ressourcen haben, um ihre EDR rund um die Uhr zu überwachen. Aus diesem Grund wenden sich viele Unternehmen an MDR-Anbieter. Die meisten hätten in der ersten Phase dieses Angriffs reagiert, als auf dem Server, von dem Daten exfiltriert wurden, eine seitwärts Bewegung (lateral movement) festgestellt wurde.   

Wäre das Ziel ein Eye Security MDR-Kunde gewesen, hätte der Angriff höchstwahrscheinlich nicht einmal dieses Stadium erreicht. Ein grundlegender Bestandteil unseres Onboarding-Prozesses ist die Durchführung einer Reihe von Scans der Angriffsfläche eines Kunden, um seine Sicherheitslage zu bewerten.   

Diese Bewertungen werden von erfahrenen Mitarbeitern durchgeführt. In diesem Fall wären die übermäßigen Berechtigungen des Service-Accounts aufgefallen. Ohne diese hätte der Angriff von vornherein verhindert werden können.     

Sind Sie ausreichend vor Ransomware geschützt? Möchten Sie wissen, wie Eye Security Ihnen dabei helfen kann? Buchen Sie jetzt ein Beratungsgespräch:  

 

Nehmen Sie Kontakt auf

Möchten Sie wissen, wie wir helfen können?

Lassen Sie uns drüber reden
GET IN TOUCH
Artikel weiterleiten