Ransomware-Angriff erlebt — hier der Ablauf und unsere Learnings

Haben denselben Mist vor zwei Jahren auch erlebt. Mit einem Unterschied: Unser Backup war nicht sauber.

Drei Tage Stillstand in der Produktion. Jetzt liegt die Backup-Kopie getrennt und unveränderbar. War eine teure Lehre.

Ich würde gerne noch ein paar Punkte zur Management-Seite der Incident Response ergänzen, denn diese Seite bestimmt den Prozess genauso stark wie die technische Reaktion.

Erstens muss vorher feststehen, wer entscheidet. Wenn im Ernstfall nicht klar ist, wer auf die Frage "Fahren wir das System runter?" antwortet, verliert man Stunden.

Zweitens, der Kommunikationsplan. Was den Mitarbeitern gesagt wird, wann Kunden informiert werden und wie ggf. die gesetzliche Meldepflicht erfüllt wird, muss vorher schriftlich festgelegt sein. Falls personenbezogene Daten betroffen sind, prüft die Fristen und das Verfahren mit der Rechtsabteilung; diese Fristen sind kurz.

Drittens, die Entscheidung über die Lösegeldzahlung. Ich möchte betonen, dass das keine technische, sondern eine Entscheidung des Top-Managements und der Rechtsabteilung ist. Bezahlen garantiert nicht, dass die Daten zurückkommen, und kann zusätzliche rechtliche Risiken mit sich bringen.

Viertens, der Nachfallbericht. Nach den heißen Tagen kehrt alle zur Normalität zurück und die Lessons Learned werden nicht dokumentiert. Ein Incident Report, der nicht innerhalb einer Woche geschrieben wird, wird nie geschrieben.

Ich möchte mal einen Punkt ansprechen: Du sagst, es gab keine Schwachstellen. Wie hast du das verifiziert?

Meine Frage kommt nicht aus böser Absicht. In den meisten Fällen wird der zuerst gefundene Einstiegspunkt als der richtige angenommen und die Recherche endet dort. Dabei hinterlassen Angreifer oft mehrere Persistenzmethoden.

Konkrete Frage: Wurde nach der Sitzung des Nutzers, der mit einem geleakten Passwort eingedrungen ist, im System ein anderes Konto erstellt, ein geplanter Task hinzugefügt oder ein Remote-Access-Tool installiert – habt ihr das geprüft? Es ist keine Seltenheit, dass ein als sauber geltendes System drei Wochen später erneut kompromittiert wird.

Berechtigte Frage, ich antworte mal.

Wurde geprüft. Ein unabhängiges Team hat zwei Wochen lang untersucht. Zwei geplante Tasks und ein nachträglich erstelltes lokales Administratorkonto wurden gefunden. Beide waren bei der ersten Bereinigung übersehen worden.

Deshalb möchte ich noch hinzufügen: Die Entscheidung über die Bereinigung sollte nicht vom Team getroffen werden, das den Vorfall erlebt hat. Das erschöpfte Team mitten im Geschehen neigt dazu, seine eigenen Befunde bestätigen zu wollen. Wenn möglich, sollte ein externer Blick draufschauen.

Am Ende haben wir die betroffenen Maschinen komplett neu aufgesetzt. Das war langsamer, aber der sicherere Weg.

Ich würde mal aus Infra-Sicht eine konkrete Backup-Struktur vorschlagen, denn „getrennt halten“ bleibt etwas abstrakt.

Die gängige und funktionierende Regelung ist folgende: Es sollten mindestens drei Kopien der Daten vorhanden sein, diese sollten auf mindestens zwei verschiedenen Medien gespeichert werden und mindestens eine Kopie sollte vollständig an einem separaten Ort liegen. Zusätzlich ist es im Ransomware-Szenario entscheidend, dass diese separate Kopie nach dem Schreiben unveränderlich ist.

Und messt auch die Wiederherstellungszeit. Der Satz „Wir haben ein Backup“ ist nicht so wertvoll wie der Satz „Wir sind in acht Stunden wieder online“. Wenn ihr Letzteres nicht wisst, probiert es mal an einem Samstag.

Ich bin ein kleines Unternehmen, ich erzähle es aus meiner Sicht. Der meiste Zeitverlust entsteht durch Arbeiten die auf Freigaben warten.

Ein automatisierter Scan-Report ist kein Penetrationstest. Aus Erfahrung weiß ich das.

Danke fürs Schreiben, das ist genau richtig. Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

Korrigiert mich, falls ich falsch liege.

Du hast recht. Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.

Wenn deine Situation anders ist, ändert sich das natürlich.

Wie habt ihr das Problem gelöst? Ein nicht getestetes Backup ist kein Backup.

Wenn es jemand anders macht, würde mich das auch interessieren.

Dieses Thema ist archiviert.

Richtig.

Ich würde mich freuen wenn du das Ergebnis postest.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. naja änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt, über den sie eingehen.

Das war's entschuldige wenn ich zu lang war.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Wenn wir ohne Messung entscheiden, landen wir immer wieder am selben Punkt.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Beim Lesen dieser Antwort war ich erleichtert, es liegt also nicht nur an mir. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Korrigiert mich, falls ich falsch liege.

ich bin ein kleines Unternehmen ich erzähle es aus meiner Sicht aber in den ersten drei Monaten läuft alles gut die Probleme tauchen im vierten Monat auf.

die Anwtort hängt stark von der Branche ab es gibt keine allgemeine Regel.

Ich möchte kurz warnen. Wenn Genehmigung und Umfang nicht schriftlich vorliegen darf der Test nicht starten.

Verlasst euch nicht auf eine einzige Maßnahme; geht schichtweise vor. Schreibt mir wenn ihr Fragen habt, ich antworte so gut ich kann.