Jump to content

Ransomware Ryuk teilweise aktiv - zwingend Server neu installieren? Wie prüfen?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

heute Morgen klingelt das Telefon: SAP-Druckserver geht nicht mehr. Die Analyse zeigt u. a. eine "RyukReadMe.html" und Dateien mit der Endung "RYK", z. B. "loader.cfg.RYK". Wir haben das System dann vom Netz genommen. Der ITler vor Ort könnte uns die komplette Maschine aus einem Snaphot wiederherstellen. Da das System keine Daten in dem Sinn beinhaltet, sondern lediglich PDFs erzeugt, wäre das für uns OK.

 

Ich habe mal ein bisschen was über den Schädling gelesen und da wird von einer möglichen, vorgelagerten Infektion gesprochen, die das Netzwerk durchsucht und erst nach einem gewissen Zeitraum beginnt dann die Verschlüsselung von Daten.

 

Ich weiß also nicht, ob das wiederhergestellte System nun frei von Schädlingen ist. Sicher kommt nun auch der Einwand von euch, es gibt keine 100%ige Sicherheit und am besten sollen wir alles neu installieren, um sicher zu gehenn Das verstehe ich auch.

 

Trotzdem möchte ich mal von euch erfahren, ob und wie ihr solche Maschinen behandelt habt bzw. behandeln würdet, wenn sie erst mal noch nicht gelöscht werden sollen. Es gibt dort auch Systeme, die bisher überhaupt keine Verschlüsselungsaktivität zeigen.

 

Welche Schritte soll ich nach dem Hochfahren der Maschinen unternehmen?

 

- Windows Updates

- Viren/Ransom-Scan? Welche Tools empfehlt ihr? Malwarebytes, SpyHunter 5, Kaspersky Anti Ransomware Tool,...?

- Sysinternals-Tools?

- ...

 

Viele Grüße + mal wieder ein Dankeschön an dieser Stelle!

Samoth

bearbeitet von Samoth
Link zu diesem Kommentar

Moin,

 

so ein verzögertes Verhalten ist heute typisch für Malware. Es kann auch durchaus sein, dass ihr hier nur die Spitze des Eisbergs seht und in Wirklichkeit eine "richtig große" Malware in eurem System ist.

 

Aus Sicht der reinen Lehre muss jetzt alles neu gemacht werden. Ob das angeraten ist, steht auf einem anderen Blatt - wobei ich damit auch nicht davon abrate. Es wäre vielleicht sinnvoll, einen guten Dienstleister hinzuzuziehen, und zwar schnell.

 

Hier ein bisschen dazu, was wir in solchen Situationen schon gemacht haben:

 

[Hackerangriff, Trojanerausbruch, Lösegeldforderung - und jetzt? - michael wessel Blog]
https://www.michael-wessel.de/blog/2019/11/20/hackerangriff-trojanerausbruch-loesegeldforderung-und-jetzt/


Gruß, Nils

 

  • Danke 1
  • Verwirrend 1
Link zu diesem Kommentar
Am 6.12.2019 um 14:42 schrieb NilsK:

Hier ein bisschen dazu, was wir in solchen Situationen schon gemacht haben:

 

[Hackerangriff, Trojanerausbruch, Lösegeldforderung - und jetzt? - michael wessel Blog]
https://www.michael-wessel.de/blog/2019/11/20/hackerangriff-trojanerausbruch-loesegeldforderung-und-jetzt/uß, Nils

 

Guten Abend,

darf ich fragen warum die SSDs in dem Bericht (Blog) erneuert und nicht gelöscht wurden? Hatte es wirtschaftliche (löschen ist teurer als 20 € für eine 120 GB SSD) oder einen technischen Grund?

 

Wie hat es Emotet geschafft sich lateral im Netz auszubreiten? Wenn das herausgefunden wurde, würde mich das brennend interessieren. Manchmal sind das ja wirklich blöde Sachen, wie bei Heise, dass sich ein Domänenadmin lokal anmeldet.

 

Warum wurden keine Backups wiederhergestellt? Lt. Bericht wurden auch Server bereinigt. Das bedeutet, man hätte das Backup auf eine Infektion prüfen können. Wenn man bereinigt weiß man ja auf was man achten muss.

 

Vielen Dank für den Erfahrungsaustausch, falls das Ausplaudern OK ist.

 

Grüße

wznutzer

 

P.S.

Seid ihr bundesweit tätig?

Link zu diesem Kommentar

Für

vor 10 Stunden schrieb wznutzer:

Wie hat es Emotet geschafft sich lateral im Netz auszubreiten? Wenn das herausgefunden wurde, würde mich das brennend interessieren. Manchmal sind das ja wirklich blöde Sachen, wie bei Heise, dass sich ein Domänenadmin lokal anmeldet.

Tja, in manchen Umgebungen gibts Softwareverteilung, da ist da ein Domänennutzer SWINST dann lokaler Admin auf den Clients, und zwar überall mit Kennwort GTUZ43234GGH!!57, damit kann man sich prima seitwärts ausbreiten auf den Clients.

 

Link zu diesem Kommentar
Zitat

... zwar überall mit Kennwort GTUZ43234GGH!!57, damit kann man sich prima seitwärts ausbreiten ...

Dagegen hilft nur ein Privileged Access Management (PAM). Admin-Credentials sind nie ausreichend sicher vor findigen Angreifern geschützt. 

Zufällig arbeite ich in einem PAM-Evaluierungsprojekt, um genau diesem Lateral Movement mit entwendeten Admin Credentials entgegen zu wirken.  

 

Solange du die Admin-Accounts nicht im Griff hast, plus eine wirksame Detection aufgebaut hast, hilft eine Neuinstallation/ Bereinigung meines Erachtens wenig. 

bearbeitet von SandyB
Link zu diesem Kommentar
vor 13 Stunden schrieb SandyB:

Dagegen hilft nur ein Privileged Access Management (PAM). Admin-Credentials sind nie ausreichend sicher vor findigen Angreifern geschützt. 

Zufällig arbeite ich in einem PAM-Evaluierungsprojekt, um genau diesem Lateral Movement mit entwendeten Admin Credentials entgegen zu wirken. 

Das Thema PAM hab ich mal ausgegliedert in https://www.mcseboard.de/topic/216946-pam-evaluierungsprojekt-um-ua-lateral-movement-mit-entwendeten-admin-credentials/

Link zu diesem Kommentar
Am 6.12.2019 um 15:10 schrieb sgn9:

Infektionsweg nachvollzogen oder nicht?

Laut Info vom Kunden durch eine Mail in einer Außenstelle, die per VPN angebunden war.

 

Am 6.12.2019 um 19:10 schrieb DocData:

Wenn‘s eine Mail mit Anhang war - warum war‘s dann ausgerechnet der SAP Druckserver? Ich glaube: Es ist die Spitze des Eisberges.

Das war nur der erste infizierte. Als ich dann die übrigen Windows-Applikationsserver zur Verfügung gestellt bekam, war dort auch schon Einiges verschlüsselt.

 

vor 3 Minuten schrieb Squire:

aua ... um wieviele Clients/Server dreht es sich dabei?

Warum die ESX neu?

Habe leider keine gesicherte Info, aber ich vermute, um absolut sicher zu sein, dass da nichts mehr hochkommt...? Anzahl der Clients ist mir nicht bekannt, aber mehr als 50 - grob geschätzt.

 

Aktueller Stand SAP:

- Einige Server sind leider nicht mehr aus älteren Backups wiederherzustellen

- Wiederherstellbare Server wurden mehrfach gescannt und in ein eigenes SAP-Netz gepackt und sind nutzbar

- Da die DBs auf Linux laufen war das Glück im Unglück: Keine Infektion auf den Linux-Maschinen. Daher war es nicht zu schwierig den Applikationsserver und den jeweiligen DB-Server wieder zu koppeln

 

Fragen zum Thema:

- Evtl. habe ich es auch übersehen, aber hat sich noch jemand dazu geäußert wie ich mit wiederhergestellten Maschinen umgehen soll? Also konkrete Tool-Empfehlungen zum Prüfen, etc.?

 

- Unsere IT hat dann nach Bekanntwerden der Infektion auch gleich den Tunnel zum Kunden dicht gemacht. Wie wahrscheinlich/realistisch ist es denn eigentlich, dass wir uns den Schädling ins eigene Netz ziehen, wenn ich per Site-to-Site-VPN und RDP auf die Kundensysteme zugreife?

 

Viele Grüße einstweilen :-)

Samoth

bearbeitet von Samoth
Link zu diesem Kommentar

Wird die Aussenstelle auch gesäubert? oder sogar mehrere Aussenstellen?

Wie wurde erforscht, welche Daten seit wann abgesaugt wurden?

Übrigens "Die DSGVO-Meldepflicht regelt, dass betroffene Unternehmen Datenpannen sofort öffentlich melden müssen. Jetzt hat die EU die Meldepflicht noch einmal weiter verschärft." steht unter https://it-service.network/blog/2019/05/29/dsgvo-meldepflicht/

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...