NotPetya: Der teuerste Cyberangriff aller Zeiten

25. Februar 2026 • 12 min read

Inhaltsverzeichnis

Ende Juni 2017 beginnt in der Ukraine etwas, das auf den ersten Blick nach „Ransomware wie immer“ aussieht: Rechner starten neu, Dateien sind plötzlich nicht mehr verfügbar, auf dem Bildschirm erscheint eine Lösegeldforderung.

Nur ein paar Stunden später ist klar: Das ist kein lokaler Vorfall. Das ist ein Flächenbrand.

Der Name, der bis heute hängen geblieben ist, lautet NotPetya. Und er steht sinnbildlich dafür, wie aus einer vermeintlich „einfachen Malware-Welle“ ein Ereignis werden kann, das weltweit Unternehmen lahmlegt und Schäden in Milliardenhöhe verursacht.

In diesem Beitrag möchte ich zwei Dinge verbinden:

Die Story hinter NotPetya: Was ist damals passiert und warum wurde es so teuer?
Die praktische Perspektive: Was bedeutet das für „normale“ Firmen heute, also nicht nur für Fortune-500-Konzerne?

Denn das Unangenehme an NotPetya ist nicht, dass es „zu komplex“ wäre. Das Unangenehme ist: Es ist erschreckend realistisch.

Warum schreibe ich das 2026? Weil wir heute zwar über KI-gesteuerte Deepfake-Phishing-Angriffe reden – aber im Ernstfall immer noch an denselben banalen Dingen scheitern wie 2017: fehlende Segmentierung und Backups, die am selben Tropf hängen wie die Produktion.

NotPetya in 5 Minuten: Was ist passiert?

Damit wir das Ganze einordnen können, müssen wir einmal kurz die Ereignisse sortieren.

Am 27. Juni 2017 tauchte NotPetya zuerst in der Ukraine auf und breitete sich dann sehr schnell global aus. Eine zentrale Rolle spielte dabei ein kompromittiertes Update einer in der Ukraine weit verbreiteten Buchhaltungssoftware (M.E.Doc). Die Malware kam also nicht über „den einen dummen Klick“, sondern über einen Mechanismus, den Firmen täglich verwenden: Updates.

Und das ist ein Punkt, den viele rückblickend unterschätzen: Das war im Kern eine Supply-Chain-Attacke. M.E.Doc war kein „Zufallstreffer“, sondern ein perfekter Hebel, weil Updates in Unternehmen per Design Vertrauen genießen.

Die Lehre für heute ist unbequem, aber wichtig: Du kannst intern sehr viel richtig machen – wenn Software von Dienstleistern, Buchhaltung, ERP-Connectoren oder Remote-Tools kompromittiert wird, bist du trotzdem dran. Supply-Chain-Risiko ist damit kein „Cloud-Problem“, sondern ganz konkret ein Update-Problem.

Sobald NotPetya einmal im Netzwerk war, ging es nicht mehr um einzelne Endgeräte, sondern um Lateral Movement:

Über SMB und bekannte Schwachstellen (u. a. EternalBlue / MS17-010, ein aus dem NSA-Toolset geleakter Exploit) konnte sich NotPetya ohne Benutzerinteraktion auf weitere Windows-Systeme ausbreiten.
Parallel dazu nutzte die Malware Credential-Dumping (Mimikatz/LSASS), um Passwörter/Hashes aus dem RAM zu ziehen und sich mit echten Admin-Credentials weiterzubewegen.
Für die eigentliche Remote-Ausführung wurden dann „normale“ Admin-Werkzeuge (z. B. PsExec/WMI) genutzt. Genau diese Mischung ist so gefährlich, weil sie in Logs erstmal wie „Betrieb“ aussieht.

Das war das „Geheimrezept“: Exploit für den schnellen Sprung auf neue Systeme, Credentials aus dem Speicher für echte Rechte – und dann mit Bordmitteln skaliert.

Wichtig dabei: Patchen allein hätte hier nicht gereicht. Selbst wenn ein System gegen EternalBlue gepatcht war, konnte es trotzdem fallen, sobald die Malware irgendwo gültige Admin-Credentials/Hashes aus dem Netz gezogen hatte.

Und NotPetya spielte zusätzlich mit Zeit: Es baute eine Verzögerung ein und erzwang den „großen Knall“ (Reboot/Wipe) nicht sofort, sondern erst nach einer Weile. Das ist fies für die Erkennung – und nebenbei ein Klassiker gegen Sandboxing, weil die Malware nicht sofort „detoniert“, während sie im Hintergrund schon skaliert.

Das Ergebnis ist genau das, was man in solchen Situationen immer beobachtet:

Erst wirken ein paar Systeme „komisch“.
Dann kippt plötzlich ein ganzer Standort.
Und wenn man nicht extrem schnell reagiert (Netz trennen, Accounts sperren, Segmentgrenzen schließen), kippt das Ganze unter Umständen standortübergreifend.

Warum „Ransomware“ hier nur Tarnung war

NotPetya wurde vielerorts als Ransomware wahrgenommen, weil es eine Lösegeldforderung anzeigte. Technisch und praktisch war es aber etwas anderes.

Der entscheidende Punkt: NotPetya war in der Realität eher ein Wiper. Also Schadsoftware, deren Zweck nicht „Geld verdienen“ ist, sondern Systeme dauerhaft zu zerstören und Betrieb zu stören.

Das klingt im ersten Moment nach Wortklauberei. Im Incident macht es aber einen riesigen Unterschied:

Bei klassischer Ransomware gibt es (manchmal) eine Chance, über Keys oder Verhandlungen Daten zurückzubekommen.
Bei einem Wiper ist das Ziel „kaputt“. Da hilft dir kein Bitcoin-Transfer.

Bei NotPetya kommt ein technisches Detail dazu, das den „Wiper“-Charakter brutal unterstreicht: Es hat den MBR (Master Boot Record) überschrieben und die MFT (Master File Table) verschlüsselt. Und selbst die „Ransomware“-Mechanik war fehlerhaft umgesetzt: Die angezeigte Installations-ID war zufällig generiert und nicht sauber mit einem Entschlüsselungsschlüssel verknüpft. Heißt unterm Strich: Es gab technisch praktisch keinen Weg zurück.

Und genau deshalb war NotPetya so perfide: Es hat den Incident Response Prozess vieler Firmen zunächst in die falsche Richtung gedrückt. Man denkt „Ransomware Playbook“, dabei ist es eigentlich „Disaster Recovery Playbook“.

Dass der Angriff eher auf Zerstörung als auf Geld ausgerichtet war, passt auch zur späteren Einordnung: Mehrere Regierungen haben NotPetya öffentlich russischen staatlichen Akteuren zugeschrieben.

10 Milliarden Dollar: Warum wurde das so teuer?

Wenn du nur auf das „Ransomware“-Label schaust, wirkt der Schaden erstmal schwer erklärbar. „Dann spielt man halt das Backup zurück, oder?“

In der Praxis war NotPetya vor allem deshalb so teuer, weil es Unternehmen an einer Stelle getroffen hat, die in jeder Budget-Diskussion zu kurz kommt: Verfügbarkeit.

Der größte Kostenblock war nicht die Malware selbst, sondern der Stillstand.

Produktionslinien stehen.
Logistik läuft wieder auf Papier.
Identitäten und Domänen müssen neu aufgebaut werden.
Anwendungen, Schnittstellen und Abhängigkeiten knallen nacheinander um.
Und das Ganze passiert nicht in einem System, sondern in vielen gleichzeitig.

Dass NotPetya oft als „teuerster Cyberangriff aller Zeiten“ bezeichnet wird, hat genau damit zu tun. In Berichten werden die Gesamtschäden auf rund 10 Milliarden US-Dollar geschätzt.

Und man sieht das auch in den Zahlen einzelner Firmen: Merck, FedEx (inkl. TNT Express) und Mondelez haben in ihren Berichten sehr konkret beschrieben, dass der Angriff nicht nur „ein IT-Thema“ war, sondern ein Business-Thema mit echten Auswirkungen auf Umsatz, Kosten und Lieferfähigkeit.

Ein riesiges Nachspiel hatte NotPetya auch juristisch: Unternehmen stritten mit ihren Versicherungen. Einige Versicherer wollten nicht zahlen, weil sie NotPetya als „kriegerischen Akt“ („Act of War“) einstuften (also als staatlich gesteuerten Angriff). Bekannt geworden ist z. B. der Streit von Mondelez mit seinem Versicherer. Für Firmen ist das bis heute eine harte Lesson Learned: Deckt meine Cyber-Versicherung staatliche Angriffe ab – oder greift im Ernstfall eine War-Exclusion?

Update für die Pro-Leser: Der Fall rund um Mondelez wurde 2023 final beigelegt. Die Branche hat danach (und generell nach NotPetya) vielerorts nachgeschärft: In vielen Policen werden „staatlich motivierte“ Angriffe heute deutlich enger definiert oder explizit ausgeschlossen. Das macht Cyber-Versicherung plötzlich zu einem handfesten finanziellen Risiko, wenn man die Klauseln nicht wirklich versteht.

Was man dabei nicht unterschätzen darf: Selbst wenn du „nur“ IT-Systeme wiederherstellst, kämpfst du in der Realität gegen Abhängigkeiten.

Ein Beispiel, das in vielen Rückblicken auftaucht, ist Maersk: Dort ging es nicht um ein paar verschlüsselte Files, sondern um den kompletten Wiederaufbau von Kernsystemen, Identitäten und der operativen IT, damit Häfen und Logistik überhaupt wieder anlaufen konnten.

Die Story dahinter ist legendär, weil sie perfekt zeigt, wie fragil Identitäten und Backups in der Praxis sein können: Maersk verlor praktisch sein gesamtes Active Directory – bis auf einen einzigen Domain Controller in Ghana, der zum Zeitpunkt des Angriffs wegen eines Stromausfalls offline war. Dieser „Lucky Punch“ war am Ende so etwas wie ein unbeabsichtigtes Offline-Backup: Nur mit diesem einen physischen Server konnten sie ihr globales AD rekonstruieren und den Wiederaufbau beschleunigen.

Das trifft am Ende nicht nur „die IT“, sondern direkt das Business:

Bei einem Lebensmittelkonzern bedeutet das: Produktion, Planung und Lieferketten laufen nicht mehr.
Bei einer Reederei bedeutet das: Container bleiben stehen.
Bei einem Pharmaunternehmen bedeutet das: Fertigung, Qualitätsprozesse und Lieferfähigkeit geraten unter Druck.

Und genau deshalb ist die Zahl so hoch: Der Lösegeldbildschirm ist nur das Symptom. Der eigentliche Schaden ist der Stillstand.

Praxisfall: Der Angriff, den ich bei einer normalen Firma erwarten würde

Ich möchte bewusst einen Fall beschreiben, der sich nicht nach Hollywood anfühlt. Kein „State Actor vs. Big Tech“, sondern ein Szenario, das ich bei einer typischen Firmengröße für plausibel halte.

Stell dir eine mittelständische Firma vor:

Ein Hauptstandort, ein kleiner zweiter Standort.
Ein klassisches Windows-Setup: AD, Fileserver, ein paar VMs, ein ERP.
Dazu eine Handvoll Systeme, die man aus guten Gründen kaum anfasst: Maschinensteuerungen, alte Spezialsoftware, ein „Windows-Server-2008-irgendwas“, weil der Hersteller nie nachgezogen hat.
Backups gibt’s: täglich auf ein NAS, wöchentlich zusätzlich auf ein zweites System.

Und jetzt kommt der Punkt, den viele unterschätzen:

Diese Firma hat nicht „zu wenig Security“, weil alle inkompetent sind. Sondern weil Betrieb und Zeit immer gewinnen.

Patchen wird verschoben, weil die Produktionsplanung eng ist. Segmentierung wird „später mal“ gemacht, weil VLANs Aufwand sind. Lokale Admin-Passwörter sind historisch gewachsen. Und das NAS hängt natürlich im Netz, weil das Restore sonst so umständlich wäre.

Der Ablauf (realistisch, nicht dramatisch)

An einem Dienstagmorgen kommt ein Update rein. Kann ein Lieferant sein, ein Dienstleister-Tool, ein Connector, irgendwas, das automatisch nachlädt. Oder es ist ein kompromittiertes System bei einem Partner, der über VPN Zugriff hat.

08:10 Uhr: Erste Clients werden instabil. Ein Reboot hier, ein komischer Fehler da.
08:25 Uhr: Der erste Fileserver reagiert langsam. Helpdesk-Tickets gehen hoch.
08:40 Uhr: Plötzlich ist „die Domäne komisch“. Login dauert, Gruppenrichtlinien spinnen.
09:00 Uhr: Ein Admin meldet sich an, „um schnell zu schauen“. Genau das ist der Moment, in dem Lateral Movement oft richtig Fahrt aufnimmt.
09:20 Uhr: Ein ganzer Standort ist effektiv offline.

Und jetzt kommt der Teil, den man erst im Nachhinein wirklich versteht:

Wenn du in so einem Moment nicht sofort hart trennst, skaliert der Schaden nicht linear, sondern exponentiell.

Und natürlich kommt dann die Frage, die immer kommt:

„Müssen wir zahlen?“

Bei NotPetya war die bittere Antwort: Selbst wenn du wolltest, wäre das höchstwahrscheinlich keine Lösung gewesen. Das ist psychologisch ein riesiger Unterschied im Incident, weil du dich mental sofort auf „Wiederaufbau“ einstellen musst, nicht auf „Entschlüsselung“.

Je länger du wartest, desto mehr Systeme müssen neu. Je mehr Systeme neu müssen, desto länger bist du im Notbetrieb. Und je länger du im Notbetrieb bist, desto teurer wird es.

Was am Ende wirklich weh tut

Nach ein paar Stunden ist klar: Das ist kein „wir spielen ein paar Files zurück“. Das ist „wir bauen Active Directory und Kernsysteme neu auf“.

Und dann stellst du fest:

Deine Backups hängen im Netz und wurden mit erwischt.
Deine Dokumentation ist nicht aktuell.
Du hast zu wenig „goldene Images“, um schnell zu re-imagen.
Die Admin-Credentials waren überall.
Und niemand hat je geübt, wie man in 30 Minuten einen Standort sauber segmentiert.

Das ist der Moment, in dem aus einem IT-Incident eine Unternehmenskrise wird.

Was ein SOC heute anders macht (und was KI damit zu tun hat)

In einem großen Security Operations Center (SOC) laufen pro Tag Milliarden Events aus sehr vielen Quellen ein. Das ist nicht mehr „ein Admin schaut ins Firewall-Log“, sondern ein industrialisierter Prozess aus Sensorik, Korrelation, Automatisierung und menschlicher Analyse.

Spannend finde ich dabei die Rollenverteilung:

KI/Automatisierung als erste Linie: Sie sortiert, korreliert, erkennt Muster und filtert das Offensichtliche.
Menschen als zweite/dritte Linie: Wenn ein Fall kritisch ist oder unklar bleibt, übernehmen Analysten, entscheiden Maßnahmen und koordinieren Response.

Das klingt nach „nur was für Konzerne“, aber die Erkenntnis ist auch für kleine Firmen wichtig:

Du musst nicht selbst ein SOC bauen. Aber du brauchst denselben Denkansatz:

Sammle Signale (EDR, Firewall, Auth-Logs).
Definiere, was „normal“ ist.
Und hab einen Prozess, der in Minuten reagiert, nicht in Tagen.

NotPetya war 2017 schon so schnell, dass kein Mensch „schnell genug reagieren“ konnte, sobald die Ausbreitung einmal lief. Der Punkt an KI ist deshalb weniger „noch schneller“, sondern: Sie hilft, die Anomalie im Rauschen früher zu finden (z. B. wenn nachts um 03:00 Uhr plötzlich 500 Rechner via SMB miteinander sprechen). Genau diese Minuten entscheiden: früher sehen, früher begrenzen, früher isolieren.

Und dann kommt das Mindset, das ich in vielen modernen Security-Konzepten inzwischen als Default sehe:

Assume breach.

Also: Plane so, als wäre der Angreifer schon drin. Nicht aus Paranoia, sondern aus Pragmatismus.

Was ich heute als Minimum sehen will (ohne Enterprise-Budget)

Wenn du aus NotPetya etwas mitnehmen willst, dann das:

NotPetya war nicht „eine Lücke“. NotPetya war eine Kette aus Schwächen, die sich gegenseitig verstärkt haben.

Die gute Nachricht: Genau deshalb kannst du mit ein paar Basics massiv Risiko rausnehmen.

1) Patch- und Exposure-Management (wirklich ernst nehmen)

Kritische Windows-Updates (insbesondere rund um SMB) dürfen nicht „irgendwann“ passieren.
Alles, was von außen erreichbar ist, hat Priorität.
Und wenn du Legacy brauchst: dann wenigstens segmentiert, mit klaren Regeln.

2) Lateral Movement unbequem machen

Admin-Accounts trennen (Alltag vs. Admin).
Lokale Admin-Passwörter pro Gerät (Stichwort LAPS).
Remote-Admin-Tools (WMI, PsExec) nicht pauschal offen lassen.
SMB dort begrenzen, wo es nicht zwingend gebraucht wird.

3) Segmentierung, aber pragmatisch

Du musst nicht sofort Zero Trust „perfekt“ machen. Aber:

Clients, Server, Backup, OT/Produktion gehören nicht in ein flaches Netz.
Domain Controller sind Tier 0 und müssen entsprechend geschützt sein.
Ost-West-Traffic braucht genauso Aufmerksamkeit wie Internet-Traffic.

4) Backups: offline, immutable, getestet

Ich sag’s so, wie ich es in Projekten immer wieder sehe:

Ein Backup, das ständig beschreibbar im Netz hängt, ist im Ernstfall oft kein Backup.

3-2-1 ist ein guter Start.
Immutable Storage (oder offline Medien) ist ein Gamechanger.
Restore-Tests sind Pflicht. Nicht „wir haben Backups“, sondern „wir haben restores geübt“.

5) Incident-Runbooks und ein „Kill-Switch“ für Standorte

Du brauchst kein 80-seitiges Handbuch. Aber du brauchst Klarheit:

Wer entscheidet, dass ein Standort getrennt wird?
Wie sperrst du Accounts schnell?
Welche Systeme müssen als erstes wieder hoch (AD, DNS, DHCP, VPN, ERP)?

Und ja: Das muss man üben, sonst hilft es dir im Ernstfall nicht.

Reality-Check: In NotPetya war die effektivste Maßnahme in vielen Fällen nicht „noch ein Tool“, sondern physisch trennen. Zu Maersk gibt es Berichte, dass Mitarbeiter durch Büros gelaufen sind und Strom-/Netzkabel aus Switches gezogen haben, um die Ausbreitung zu stoppen. Klingt banal – ist aber manchmal die beste High-Tech-Security, wenn Sekunden zählen.

Fazit

NotPetya ist für mich bis heute eines der besten Beispiele dafür, warum IT-Security nicht mit „wir haben ein Antivirus“ erledigt ist.

Der Angriff war nicht deshalb so verheerend, weil er magisch war. Sondern weil er an ganz normalen Stellen angesetzt hat:

Vertrauen in Updates
zu viel Lateral Movement
zu wenig Segmentierung
Backups, die zu nah am Produktivnetz kleben

Und genau deshalb ist es so relevant für normale Firmen.

Wenn du heute investierst, dann investiere nicht nur in Tools, sondern in Resilienz: Sichtbarkeit, schnelle Reaktion und die Fähigkeit, Systeme sauber wiederherzustellen. Das ist der Unterschied zwischen „ein sehr schlechter Tag“ und „ein Quartal, das du nie wieder aufholst“.

Quellen und weiterführende Links

Bis zum nächsten Mal, Joe