Es war ein Donnerstagabend. Ich war gerade dabei, meinen Laptop zuzuklappen, als mein Telefon klingelte. Die Nummer des NOC. Das ist selten ein gutes Zeichen.

„Wir haben da ein Problem. Der Domain Controller antwortet nicht mehr. Und… da sind seltsame Prozesse auf mehreren Servern.“

Die nächsten 72 Stunden sollten die intensivsten meiner Karriere werden. Und sie haben mich mehr gelehrt als jedes Training, jede Zertifizierung, jede Konferenz es konnten.

Die erste Stunde: Chaos

Die erste Reaktion war Chaos. Nicht organisiertes Chaos sondern echtes, unkoordiniertes Durcheinander.
Verschiedene Teams fingen an, auf eigene Faust zu handeln. Jemand zog Netzwerkkabel. Jemand anderes startete Server neu. Die Geschäftsführung wollte sofort wissen, ob Kundendaten betroffen waren. Die PR-Abteilung fragte, was sie sagen sollte. Die Rechtsabteilung wollte informiert werden.
Und mittendrin stand ich, mit dem Versuch, zu verstehen, was eigentlich gerade passiert war.

Lektion eins: Ohne vorbereitete Incident-Response-Pläne ist sind die ersten Stunde verloren. Nicht weil niemand arbeitet, sondern weil alle arbeiten – aber nicht koordiniert.

Die Erkenntnis: Er war schon länger drin

Im Laufe der Nacht wurde klar: Der Angreifer war nicht erst heute gekommen. Die Spuren reichten Wochen zurück. Wir hatten ihn nur noch nicht gesehen.
Er war über einen kompromittierten Laptop reingekommen. Ein Mitarbeiter hatte einen Anhang geöffnet und das Verhängnis nahm seinen Lauf. Von dort aus hatte er sich langsam durch das gesamte Netzwerk bewegt. Credentials gesammelt, Rechte erweitert und geduldig gewartet.
Der Donnerstagabend war nicht der Beginn des Angriffs sondern es war vielmehr der Moment, an dem der Angreifer sein Ziel erreicht hatte und entsprechend laut wurde.

Lektion zwei: Dwell Time ist real. Die meisten Angriffe werden nicht beim Eindringen entdeckt, sondern erst, wenn der Schaden bereits angerichtet ist.

Was wir nicht wussten

Die frustrierendste Erkenntnis kam in den folgenden Tagen. Wir wussten sehr vieles nicht.
Wir wussten nicht genau, welche Systeme betroffen waren. Das Asset-Inventar war unvollständig. Wir wussten nicht, welche Daten auf welchen Systemen lagen. Die Datenklassifizierung existierte auf dem Papier, aber nicht in der Praxis.
Wir wussten nicht, was normal war. Ohne Baseline konnten wir nicht sagen, welche Aktivitäten zum Angreifer gehörten und welche zum regulären Betrieb. Die Logs existierten, aber niemand hatte sie jemals für diesen Zweck analysiert.
Wir wussten nicht, wann der Angriff begonnen hatte. Die Log-Retention war zu kurz. Irgendwann im Zeitstrahl klaffte ein gewaltiges Loch. Das war der Punkt, an dem die Logs endeten und die reine Spekulation begann.

Lektion drei: Incident Response beginnt nicht beim Incident. Sie beginnt mit dessen Vorbereitung: Inventar, Baselines, Logs, Dokumentation. Alles, was du während des Incidents nicht hast, wirst du dann wirklich schmerzlich vermissen.

Die Entscheidung, aber die falsche

Mitten in der Nacht, unter Druck, trafen wir eine Entscheidung, die sich nachträglich als falsch herausstellte.
Wir entschieden uns, die betroffenen Systeme sofort vom Netz zu nehmen. Das schien da noch ein vernünftiger und logischer Schritt zu sein: Den Angreifer aussperren, den Schaden begrenzen.
Was wir allerdings nicht bedachten: Damit verloren wir auch wertvolle forensische Evidenzen. Prozesse, die im RAM liefen, waren weg. Netzwerkverbindungen, die hätten dokumentiert werden können bzw. müssten, waren unterbrochen. Der Angreifer war raus. Allerdings wussten wir noch immer nicht genau, was er getan hatte.

Lektion vier: Isolation ist nicht immer die beste erste Reaktion. Manchmal ist kontrolliertes Beobachten wertvoller. Die Entscheidung hängt sehr stark vom jeweiligen Kontext ab. Sie muss sehr bewusst getroffen werden, und auf keinen Fall reflexartig.

Die menschliche Seite

Was mich am meisten überraschte, war die menschliche Seite.
Der Mitarbeiter, dessen Laptop kompromittiert worden war, war am Boden zerstört. Er fühlte sich persönlich verantwortlich für alles, was passiert war. Er bot an, zu kündigen.
Er war aber nicht schuld. Ja sicher, er hatte einen Fehler gemacht. Allerdings! Das System hatte ihm aber auch nicht dabei geholfen, den Fehler zu vermeiden. Die E-Mail hätte gefiltert werden müssen. Der Anhang hätte in einer Sandbox analysiert werden müssen. Die Rechte auf seinem Laptop hätten eingeschränkt sein müssen.

Lektion fünf: Menschen machen Fehler. Das ist keine Schwäche, das ist Realität. Security-Architekturen, die auf perfektem menschlichem Verhalten basieren, müssen und werden versagen. Und wenn sie versagt haben, darf der Mensch nicht zum Sündenbock gemacht werden!

Wir haben aber auch etwas richtig gemacht

Es war nicht alles schlecht. Einiges hat sehr gut funktioniert.
Wir hatten Backups. Echte, getestete, offline gespeicherte Backups. Gut, sie waren nicht ganz aktuell. Es fehlten ein paar Tage, aber sie waren da. Ohne sie wäre die Wiederherstellung um einige Wochen länger gewesen. Wenn sie überhaupt stattfinden hätte können.
Wir hatten externe Hilfe auf Kurzwahl. Ein Incident-Response-Dienstleister, mit dem wir einen Retainer-Vertrag hatten. Innerhalb von Stunden waren Experten vor Ort, die das schon hundertmal gemacht hatten. Ihr Wissen war in dieser Situation unbezahlbar.
Wir kommunizierten. Nicht perfekt, aber wir kommunizierten. Regelmäßige Updates an die Geschäftsführung. Ehrliche Aussagen darüber, was wir wussten und was nicht. Keine Versprechungen, die wir nicht halten konnten.

Lektion sechs: Vorbereitung zahlt sich aus. Nicht jede Vorbereitung, aber die richtigen Vorbereitungen. Backups. Externe Expertise. Kommunikationswege.

Danach: Die ehrliche Analyse

Nachdem der akute Druck vorbei war, kam die ehrliche Analyse. Was war schiefgelaufen? Nicht um Schuldige zu finden, sondern um besser zu werden.
Die Liste war lang. Unzureichende E-Mail-Filterung. Übermäßige Berechtigungen auf Endpoints. Fehlende Netzwerksegmentierung. Lücken im Logging. Kein etablierter IR-Prozess. Keine regelmäßigen Übungen.
Das Interessante: Vieles davon war bekannt. Es stand in Audit-Berichten. Es stand in Risikobewertungen. Es war dokumentiert, akzeptiert, priorisiert und dennoch nicht umgesetzt. Wie immer waren andere Projekte dringender. Weil das Budget knapp war. Weil es nie der richtige Zeitpunkt war.

Lektion sieben: Die Risiken, die du akzeptierst, werden irgendwann Realität. „Akzeptiertes Risiko“ ist keine Garantie, dass es nicht eintritt. Es ist nur eine Dokumentation, dass du es hättest wissen müssen.

Was ich heute anders machen würde

Was würde ich anders machen wenn ich die Zeit zurückdrehen könnte?
Ich würde mehr Aufwand in die Vorbereitung investieren. Nicht nur in Tools, sondern in Prozesse, Tabletop-Übungen, IR-Playbooks, klare Rollen und Verantwortlichkeiten. Eben in Dinge investieren, die dann unter Druck automatisch ablaufen können, weil sie eingeübt sind.
Ich würde zu mir ehrlicher sein, über die vorhandenen Lücken und nicht sagen: „Wir haben ein akzeptables Risiko“, sondern: „Wir haben hier eine Lücke, und wenn sie ausgenutzt wird, sieht das dann so und so aus“. Meistens hilft es auch ein konkretes Szenario zu haben, um ein abstraktes Risiko greifbar zu machen. Eben ein Szenarien-basierte Risikomangement und -Analyse ernst zu nehmen.

Die bleibende Lektion

Der Incident ist sehr viele Jahre her. Aber er hat mich geprägt wie es nur wenig andere Erfahrungen es konnten.
Er hat mir gezeigt, dass die Theorie nur ein kleiner Teil der Geschichte ist. Dass all die Frameworks und Best Practices im Moment der Krise zusammenfallen können, wenn sie nicht gelebt wurden und werden. Dass Menschen unter Druck oft anders handeln als in Workshops.
Und er hat mir gezeigt, dass wir uns von einem Incident erholen können. Dass das Team daraus stärker herauskommt, wenn die Aufarbeitung dann auch ehrlich durchgeführt wird. Fehler sind keine Schande. Fehler werden nur zur Schande, wenn man nichts aus ihnen lernt.

Jeder Security-Profi wird irgendwann seinen ersten großen Incident erleben müssen. Ich hoffe sehr, dass du besser darauf vorbereitet bist als ich es damals war.

—

Die Details in diesem Beitrag sind aus Vertraulichkeitsgründen verändert. Aber die Lektionen sind echt.