Die größten Sicherheitslücken

Die Sicherheitslücken, die die IT-Sicherheit verändert haben, von Code Red bis PHP2Shell. Mit Schweregrad, Ablauf und Zahlen zu jedem Fall.

Fälle
20
Als kritisch eingestuft
8
Angriffe auf Industrieanlagen
10

Schwachstellen

2026PHP2Shell: Die Sicherheitslücken in PHP, die die meisten Websites gefährdenZwei Lücken in PHP selbst lassen Angreifer Webserver ohne Passwort übernehmen. Die reparierten Versionen, betroffene Anwendungen und was jetzt zu tun ist. 2023MOVEit: Die Lücke im Dateitransfer, über die Cl0p Daten stahlÜber eine Lücke im Dateitransfer-Server MOVEit Transfer stahl Cl0p Daten von 2.773 Organisationen. Wie das ablief, wen es traf und was jetzt zu tun ist. 2021Log4Shell: Wenn eine Log-Zeile den Code des Angreifers startetEine Lücke in der Java-Bibliothek Log4j ließ Angreifer mit einer Textzeile Server übernehmen. Wie das ging, wie weit es reichte, was jetzt zu tun ist. 2021ProxyLogon: Die Exchange-Lücken, die Mailserver öffnetenVier Lücken in Microsoft Exchange ließen Angreifer ohne Passwort Postfächer lesen und Server übernehmen. Wie das ging, wen es traf, was jetzt zu tun ist. 2019Citrix ADC: Die Gateway-Lücke, die interne Netze öffneteIm Dezember 2019 ließ eine Lücke in den Fernzugriffs-Gateways von Citrix Angreifer ohne Passwort hinein, 33 Tage lang ohne Fix. Wie das ging, wen es traf. 2019Exim: Die E-Mail-Adresse, die Mailserver übernahm2019 ließ eine Lücke im Mailserver Exim Angreifer Befehle als root ausführen, versteckt in einer E-Mail-Adresse. Wie das funktionierte, der Wurm, der Fix. 2018MikroTik Winbox: Die Lücke, die Router-Passwörter preisgab2018 ließ eine Lücke Angreifer die Passwörter von MikroTik-Routern kopieren. Vier Monate nach dem Patch waren noch 370.000 verwundbar, über 200.000 gekapert. 2018Spectre: Wenn Prozessoren beim Raten Geheimnisse verratenEin Designfehler in Prozessoren von Intel, AMD und Arm ließ Programme fremden Speicher lesen. Wie er wirkt, was die Fixes kosten und was jetzt zu tun ist. 2018Meltdown: Wie Prozessoren geschützten Speicher preisgabenEin Designfehler der meisten Intel-Prozessoren ließ jedes Programm geschützten Systemspeicher lesen. Warum er nur 5,6 erreicht und wie der Fix wirkt. 2017NotPetya: Der zerstörerische Wurm aus einem Software-UpdateEin gekapertes Update einer ukrainischen Buchhaltungssoftware brachte einen Wurm, der sich als Ransomware tarnte, Daten zerstörte und Milliarden kostete. 2017WannaCry: Der Ransomware-Wurm, der den NHS trafEin Wurm sperrte mit einem geleakten NSA-Werkzeug und einer Windows-Lücke über 200.000 Computer. Wie er sich verbreitete, was er den NHS kostete, der Fix. 2014Shellshock: Wie eine Webanfrage über Bash Befehle ausführteEine Lücke in Bash, der Shell von Linux und macOS, ließ Angreifer mit einer Anfrage Befehle auf Webservern ausführen. Wie sie wirkte, die Angriffe, der Fix. 2014Heartbleed: Die Lücke, durch die Angreifer Serverspeicher lasenIm April 2014 ließ eine Lücke in OpenSSL Angreifer den Speicher von 24–55 % der HTTPS-Server beliebter Websites lesen. Warum ein Patch allein nicht reichte. 2014NTP monlist: Wie Zeitserver DDoS-Angriffe verstärktenAb Dezember 2013 vervielfachten Angreifer ihren Datenverkehr mit einem Diagnosebefehl in NTP-Zeitservern. Wie das funktionierte und wie das Netz aufräumte. 2008Conficker: Der Wurm, der Millionen Computer mit Windows befielAb November 2008 infizierte Conficker binnen eines Jahres 5 bis 13 Millionen Windows-Computer. Wie er sich verbreitete und wie über 100 Länder ihn abwehrten. 2008Kaminskys DNS-Lücke: Wie sich jede Domain kapern ließIm Juli 2008 ließ eine DNS-Lücke Angreifer in Sekunden falsche Adressen für jede Domain einschleusen. Wie das ging und wie sie an einem Tag geschlossen wurde. 2003Blaster: Der Wurm, der in einer Woche 100.000 Windows-PCs befielIm August 2003 befiel der Wurm Blaster in einer Woche über 100.000 Windows-Computer. Wie er sich verbreitete, warum er Microsoft angriff und warum er blieb. 2003SQL Slammer: Der Wurm, der in 10 Minuten 90 % seiner Ziele infizierteIm Januar 2003 infizierte ein 376 Byte kleiner Wurm in 10 Minuten über 90 % der verwundbaren Microsoft-SQL-Server. Wie er sich verbreitete und was er traf. 2001Nimda: Der Wurm, der in 7 Stunden 160.000 Rechner befielIm September 2001 verbreitete sich der Wurm Nimda zugleich per E-Mail, über infizierte Websites und durch Angriffe auf Webserver. In 7 Stunden infizierte er 160.000 Computer. 2001Code Red: Der Wurm, der in 14 Stunden 359.000 Server infizierteIm Juli 2001 infizierte Code Red in weniger als 14 Stunden über 359.000 Computer mit Microsofts Webserver. Der Patch war seit einem Monat da.

Die Fälle und die Kriterien, die sie erfüllen

NameJahrCVSSReichweiteMassenausnutzungSchadenAußergewöhnliche Reaktion
Code Red200110,0 erfüllt erfüllt erfülltnicht erfüllt
Nimda20017,5 erfüllt erfülltnicht erfülltnicht erfüllt
SQL Slammer20037,5nicht erfüllt erfüllt erfülltnicht erfüllt
Blaster20037,5 erfüllt erfülltnicht erfüllt erfüllt
Kaminsky DNS20086,8 erfülltnicht erfülltnicht erfüllt erfüllt
Conficker200810,0 erfüllt erfülltnicht erfüllt erfüllt
NTP monlist20145,0 erfüllt erfülltnicht erfüllt erfüllt
Heartbleed20147,5 erfülltnicht erfülltnicht erfüllt erfüllt
Shellshock20149,8 erfüllt erfülltnicht erfülltnicht erfüllt
WannaCry20178,8 erfüllt erfüllt erfüllt erfüllt
NotPetya20178,8nicht erfüllt erfüllt erfülltnicht erfüllt
Meltdown20185,6 erfülltnicht erfülltnicht erfüllt erfüllt
Spectre20185,6 erfülltnicht erfülltnicht erfüllt erfüllt
MikroTik Winbox20189,1 erfüllt erfülltnicht erfülltnicht erfüllt
Exim20199,8 erfüllt erfülltnicht erfülltnicht erfüllt
Citrix ADC20199,8 erfüllt erfüllt erfüllt erfüllt
ProxyLogon20219,8 erfüllt erfülltnicht erfüllt erfüllt
Log4Shell202110,0nicht erfüllt erfülltnicht erfüllt erfüllt
MOVEit Transfer20239,8nicht erfüllt erfüllt erfülltnicht erfüllt
PHP2Shell20269,8 erfülltnicht erfülltnicht erfüllt erfüllt
Schweregrad (CVSS) des Haupt-CVE
Code Red10,0
Conficker10,0
Log4Shell10,0
Shellshock9,8
Exim9,8
Citrix ADC9,8
ProxyLogon9,8
MOVEit Transfer9,8
PHP2Shell9,8
MikroTik Winbox9,1
WannaCry8,8
NotPetya8,8
Nimda7,5
SQL Slammer7,5
Blaster7,5
Heartbleed7,5
Kaminsky DNS6,8
Meltdown5,6
Spectre5,6
NTP monlist5,0

CVSS-Basiswerte aus der US-amerikanischen National Vulnerability Database. Ältere Einträge enthalten Werte der Version 2, die auf einer anderen Skala basieren.

Alle Fälle von 2000 bis 2026

SchwachstellenAngriffe auf Industrieanlagen

200020052010201520202025Code RedNimdaSQL SlammerBlasterKaminsky DNSConfickerNTP monlistHeartbleedShellshockWannaCryNotPetyaMeltdownSpectreMikroTik WinboxEximCitrix ADCProxyLogonLog4ShellMOVEit TransferPHP2ShellStuxnetHavexBlackEnergyIndustroyerTRISISEKANSIndustroyer2PIPEDREAMFuxnetFrostyGoop

Angriffe auf Industrieanlagen

Angriffe, die industrielle Steuerungssysteme erreichten, dokumentiert in öffentlichen technischen Analysen: was geschah, wie die Angreifer hineinkamen und was der Angriff im Prozess anrichtete.

2024Zerstörung

Fuxnet

unbrauchbar gemachte Sensor-Gateways – Schätzung von Claroty (Angreifer gaben etwa 1.700 an)
500+
Sensoren, die die Angreifer zerstört haben wollen; Claroty hält sie für wahrscheinlich intakt
87.000

Im April 2024 gab eine Gruppe namens Blackjack bekannt, sie habe Moscollector lahmgelegt. Das Moskauer Unternehmen überwacht das unterirdische Wasser- und Abwassernetz der Stadt. Die Malware, die die Angreifer Fuxnet nannten, lief auf den Sensor-Gateways des Netzes. Diese kleinen Linux-Computer sammeln über einen seriellen Standard namens M-Bus die Messwerte von Tausenden unterirdischen Sensoren. Auf jedem Gateway unterbrach die Malware den Fernzugriff, löschte Teile des Dateisystems und überschrieb den Flash-Speicher, bis er ausfiel.

Außerdem überflutete sie die M-Bus-Verkabelung mit Datenmüll, in der Hoffnung, auch die Sensoren zu beschädigen. Wie Blackjack zuerst eindrang, ist nicht dokumentiert. Die Gruppe gab an, seit Juni 2023 Zugriff zu haben. Die Angreifer behaupteten, 87.000 Sensoren zerstört und 30 Terabyte Daten gelöscht zu haben. Das Sicherheitsunternehmen Claroty analysierte die Malware und die durchgesickerten Daten. Es schätzt, dass nur etwas mehr als 500 Gateways unbrauchbar gemacht wurden und die Sensoren wahrscheinlich intakt blieben. Claroty berichtet, Blackjack stehe vermutlich dem ukrainischen Geheimdienst nahe. Keine Regierung hat das bestätigt.

Namen
Fuxnet (Blackjack)
Ziel
Moscollector, ein Moskauer Unternehmen, das die unterirdische Wasser- und Abwasserinfrastruktur überwacht
Zugeschrieben
Blackjack (Claroty berichtet, Blackjack stehe vermutlich dem ukrainischen Geheimdienst nahe; keine Regierung hat dies bestätigt)
Erster Zugang
Nicht öffentlich bekannt
Protokolle
M-Bus
Angegriffene Systeme
Linux-Sensor-Gateways (MPSB und TMSB) sowie ein 3G-Router, über das serielle M-Bus-Protokoll mit den Sensoren verbunden

2024Störung

FrostyGoop / BUSTLEBERM

Wohngebäude ohne Heizung (Dragos)
600+
ohne Heizung bei Minusgraden (Dragos)
~2 Tage

Im Januar 2024 fiel bei Minusgraden in mehr als 600 Wohngebäuden einer ukrainischen Stadt fast zwei Tage lang die Heizung aus. Laut Dragos war es Lwiw. Die Malware hinter dem Ausfall, später FrostyGoop genannt, ist ein kleines Programm, das über Modbus TCP mit den Heizungsreglern kommuniziert. Dieses einfache, weit verbreitete Protokoll sendet Befehle über Port 502, meist ohne Passwort. FrostyGoop las und änderte die Halteregister der Regler, also die Speicher für ihre Einstellungen. Außerdem setzte es ihre Software auf eine ältere Version zurück, sodass sie ihren Status nicht mehr melden konnten.

Dadurch hatten die Betreiber keinen klaren Überblick, während die Regler mit falschen Werten arbeiteten. Dragos rekonstruiert den wahrscheinlichen Einstieg. Monate zuvor nutzten die Angreifer eine Schwachstelle in einem mit dem Internet verbundenen Router aus. Sie richteten einen über Tor erreichbaren Webtunnel ein und stahlen Windows-Anmeldedaten. Weil das Netzwerk flach war und nichts die Regler abschottete, waren sie direkt erreichbar. Dragos schreibt den Angriff niemandem zu und verweist nur auf Verbindungen zu Adressen in Moskau während des Vorfalls.

Namen
FrostyGoop (Dragos), BUSTLEBERM (Mandiant)
Ziel
Ein Fernwärmeunternehmen in Lwiw, Ukraine
Zugeschrieben
Nicht zugeordnet (Dragos stellte Verbindungen zu Adressen in Moskau fest, schreibt den Angriff aber niemandem zu)
Erster Zugang
Vom Internet erreichbarer Router, Gestohlene Zugangsdaten
Protokolle
Modbus TCP
Angegriffene Systeme
ENCO-Heizungsregler, erreichbar über Modbus TCP auf Port 502

2022Störung

Industroyer2

Stromausfälle – der Angriff wurde rechtzeitig gestoppt (CERT-UA)
0
verwendetes Industrieprotokoll – in der Version von 2016 waren es noch vier (ESET)
1

Am 8. April 2022 versuchte die Gruppe Sandworm, einen Teil des ukrainischen Stromnetzes abzuschalten. Ihr Tool, von der Sicherheitsfirma ESET Industroyer2 getauft, war ein abgespeckter Nachfolger der Malware Industroyer von 2016. Es nutzte nur ein Industrieprotokoll, IEC 104. Die Adressen der Ziel-Umspannwerke und die Schaltbefehle steckten direkt im Programm. Es war also für einen bestimmten Energieversorger gebaut. Eine separate „Wiper“-Malware sollte gleichzeitig die Windows-, Linux- und Solaris-Server des Energieversorgers zerstören.

Wie die Angreifer zuerst eindrangen, ist nicht öffentlich bekannt. Sie hatten aber schon Administratorrechte und verteilten die Malware über die Windows-Gruppenrichtlinien. Eine geplante Aufgabe sollte sie am selben Abend starten. CERT-UA, das ukrainische Team für Cybervorfälle, gibt an, dass das Netzwerk mindestens seit Februar 2022 kompromittiert war. Laut CERT-UA wurde der Angriff rechtzeitig gestoppt und es kam zu keinem Ausfall. CERT-UA führt den Angriff auf Sandworm (UAC-0082) zurück; ESET kommt mit hoher Sicherheit zum selben Schluss.

Namen
Industroyer2 (ESET), INDUSTROYER.V2 (Mandiant)
Ziel
Ein ukrainischer Stromversorger; dessen Hochspannungs-Umspannwerke
Zugeschrieben
Sandworm (CERT-UA führt dies auf Sandworm (UAC-0082) zurück; ESET kommt mit hoher Sicherheit zum selben Schluss)
Erster Zugang
Nicht öffentlich bekannt
Protokolle
IEC 104
Angegriffene Systeme
Anlagen in Hochspannungs-Umspannwerken, gesteuert über das IEC-104-Protokoll

2022Störung

PIPEDREAM / INCONTROLLER

Einsätze – das Toolkit wurde entdeckt, bevor es zu einem Angriff kam (Dragos)
0
die siebte bekannte ICS-spezifische Schadsoftware, laut Dragos
7

PIPEDREAM ist ein Fall ohne Opfer. Anfang 2022 analysierten die Sicherheitsfirmen Dragos und Mandiant ein komplettes Angriffs-Toolkit. Eine staatlich unterstützte Gruppe hatte es gebaut, um industrielle Steuerungen aufzuspüren und zu übernehmen. Dragos nannte es PIPEDREAM, Mandiant INCONTROLLER. Am 13. April 2022 veröffentlichten vier US-Behörden eine gemeinsame Warnmeldung, AA22-103A. Nach Dragos’ Zählung ist es die siebte bekannte ICS-spezifische Schadsoftware und die erste, die vor einem Angriff entdeckt wurde.

Das Toolkit ist modular. Einige Teile fassen unter Windows Fuß und erhalten über einen signierten, aber fehlerhaften Treiber tiefen Zugriff. Andere nutzen die Industrieprotokolle CODESYS, Modbus, OPC UA und Omron FINS. Damit können sie Steuerungen scannen, sich dort anmelden, sie umprogrammieren oder zum Absturz bringen. Das Toolkit brachte Module für Geräte von Schneider Electric und Omron mit. Dragos geht mit hoher Sicherheit von einem staatlichen Entwickler aus und nennt ihn CHERNOVITE. Ein Land wurde nicht genannt. Mandiant bezeichnete die Verbindungen zu Russland als Indizien.

Namen
PIPEDREAM (Dragos), INCONTROLLER (Mandiant)
Ziel
Kein reales Opfer; wahrscheinliche Ziele waren laut Dragos Anlagen für Flüssigerdgas (LNG) und Strom
Zugeschrieben
CHERNOVITE (staatlich unterstützt) (So nennt Dragos den Entwickler; ein Land wurde nicht genannt; Mandiant bezeichnete die Verbindungen zu Russland als Indizien)
Erster Zugang
Nicht öffentlich bekannt
Protokolle
CODESYS, Modbus, OPC UA, Omron FINS
Angegriffene Systeme
SPS und Servoantriebe von Schneider Electric und Omron sowie beliebige OPC-UA-Server; über CODESYS, Modbus, OPC UA und Omron FINS

2020Ransomware

EKANS / Snake

Windows-Prozesse auf der Kill-Liste, darunter auch einige industrielle (FireEye)
1.000+
Branchen, die Unit 42 nennt – von Energie bis Gesundheitswesen
5

EKANS (das Wort „snake“ rückwärts) ist eine Ransomware, die 2020 auftauchte. Sie läuft auf gewöhnlichen Windows-Computern. Die Steuerungen der Maschinen kann sie daher nicht umprogrammieren. Stattdessen greift sie die Windows-PCs an, mit denen Bediener eine Anlage überwachen und steuern. Dazu gehören Bedienoberflächen (HMIs), Verlaufsdatenbanken (Historians) und Lizenzserver. Bevor sie die Dateien verschlüsselt, beendet sie eine fest einprogrammierte Liste von Programmen. So sind die Dateien nicht mehr gesperrt.

Laut dem Sicherheitsunternehmen FireEye umfasst die Liste über 1.000 Prozesse, darunter Industriesoftware von Herstellern wie General Electric und Honeywell. EKANS löscht zudem die von Windows gespeicherten Sicherungskopien. Wie die Angreifer zuerst eindrangen, wurde nie öffentlich bekannt. EKANS ist die Schadsoftware, die am Ende abgelegt wird. Weder eine Gruppe noch ein Staat wurde benannt. MITREs ATT&CK bringt unter Berufung auf Presseberichte eine EKANS-Infektion mit einem vorübergehenden Produktionsausfall in einem Honda-Werk im Juni 2020 in Verbindung.

Namen
EKANS (Dragos), Snake
Ziel
Industrieunternehmen in verschiedenen Branchen, von der Energiewirtschaft bis zur verarbeitenden Industrie (Unit 42)
Zugeschrieben
Nicht zugeordnet (Kriminelle Ransomware; weder eine Regierung noch ein Sicherheitsunternehmen hat einen Betreiber benannt)
Erster Zugang
Nicht öffentlich bekannt
Angegriffene Systeme
Windows-PCs der Leitwarte – Bedienoberflächen (HMIs), Verlaufsdatenbanken (Historians) und Lizenzserver –, nicht die Steuerungen selbst

2017Zerstörung

TRISIS / TRITON

Stillstand der angegriffenen Raffinerie (CISA)
mehrere Tage
US-Stromversorger, 2019 von denselben Angreifern ausgekundschaftet (US-Finanzministerium)
20

2017 gelangten Angreifer in das Sicherheitssystem einer petrochemischen Anlage im Nahen Osten. Seine unabhängigen Steuerungen sollen einen Prozess in einen sicheren Zustand versetzen, bevor er gefährlich wird. Die Malware, bekannt als TRISIS oder TRITON, war eigens für die Triconex-Steuerungen von Schneider Electric gebaut. Sie nutzte TriStation, das undokumentierte Protokoll der Steuerungen, das die Angreifer rückentwickelt hatten. Sie schrieb eine versteckte Hintertür in den Speicher einer Steuerung, um deren Sicherheitslogik zu verändern.

Wie die Angreifer zuerst eindrangen, haben US-Behörden nicht mitgeteilt. Im Netz der Anlage erreichten sie den Arbeitsplatzrechner, von dem aus die Steuerungen programmiert werden. Dort starteten sie ein Tool, das als Software des Herstellers getarnt war. Während der Aktion lösten einige Steuerungen eine Sicherheitsabschaltung aus und legten die Anlage mehrere Tage lang still. So wurde die Malware entdeckt. FireEye sah 2018 mit hoher Sicherheit eine Verbindung zum russischen Staatsinstitut TsNIIKhM. Die USA verhängten 2020 Sanktionen gegen das Institut. Dragos führt die Gruppe dahinter unter dem Namen XENOTIME.

Namen
TRISIS (Dragos), TRITON (FireEye), HatMan (DHS NCCIC)
Ziel
Ein petrochemisches Werk im Nahen Osten (US-Behörden sprechen nur von „einer ausländischen Ölraffinerie“)
Zugeschrieben
TsNIIKhM (russisches staatliches Institut) (In den US-Sanktionen wird dieses Institut namentlich genannt; Dragos führt die Gruppe als XENOTIME; FireEye kam mit hoher Sicherheit zu diesem Schluss)
Erster Zugang
Nicht öffentlich bekannt
Protokolle
TriStation
Angegriffene Systeme
Sicherheitssteuerungen von Schneider Electric Triconex (ein sicherheitsgerichtetes System, kurz SIS) über das undokumentierte TriStation-Protokoll

2016Störung

Industroyer / CRASHOVERRIDE

Stromausfall in Teilen von Kiew (ESET)
~1 h
Netzprotokolle, die die Schadsoftware beherrschte
4

Am 17. Dezember 2016 fiel in Teilen von Kiew etwa eine Stunde lang der Strom aus. Die Malware dahinter wurde 2017 analysiert. ESET nannte sie Industroyer, Dragos CRASHOVERRIDE. Es war die erste Malware, die Netztechnik direkt ansteuerte. Statt eines Menschen, der sich durch Fernsteuerungstools klickte, öffneten ihre eigenen Module die Leistungsschalter automatisch. Dafür nutzten sie die Standardprotokolle des Netzes: IEC 60870-5-101, IEC 60870-5-104, IEC 61850 und OPC DA. Wie die Angreifer anfangs eindrangen, wurde nie geklärt.

Ein Launcher startete den Schadcode zu einem festgelegten Zeitpunkt. Ein bis zwei Stunden später zerstörte ein Wiper Dateien und Einstellungen, um die Wiederherstellung zu verlangsamen. Ein separates Tool konnte Siemens-SIPROTEC-Schutzrelais deaktivieren. Die US-Regierung schreibt den Angriff Sandworm (dem russischen GRU) zu. Dragos führt die Gruppe dahinter unter dem Namen ELECTRUM. ESET fand 2017 keine Code-Überschneidungen mit BlackEnergy und schrieb den Angriff niemandem zu.

Namen
Industroyer (ESET), CRASHOVERRIDE (Dragos)
Ziel
Ein ukrainischer Übertragungsnetzbetreiber; Teile von Kiew waren ohne Strom
Zugeschrieben
Sandworm (GRU) (Zuschreibung durch die US-Regierung; ESET nahm 2017 keine Zuordnung vor)
Erster Zugang
Nicht öffentlich bekannt
Protokolle
IEC 60870-5-101, IEC 60870-5-104, IEC 61850, OPC DA
Angegriffene Systeme
Leistungsschalter und Relais in Umspannwerken, über die Netzprotokolle IEC 60870-5-101/104, IEC 61850 und OPC DA

2015Störung

BlackEnergy

Kunden ohne Strom (US-Heimatschutzministerium)
225.000
bis zur manuellen Wiederherstellung der Stromversorgung (INL)
~6 h

Am 23. Dezember 2015 verloren drei regionale Energieversorger in der Ukraine innerhalb von etwa einer halben Stunde die Kontrolle über ihre Stromnetze. Rund 225.000 Kunden waren ohne Strom (ESET zählte etwa 230.000 Menschen). Es ist der erste bestätigte Stromausfall durch einen Cyberangriff. Monate zuvor hatten Spear-Phishing-E-Mails mit makrohaltigen Office-Dateien die BlackEnergy-Malware in die Büronetze eingeschleust.

Die Angreifer sammelten Zugangsdaten und gelangten dann mit den eigenen VPN- und Fernsteuerungstools der Versorger in die SCADA-Systeme. Dort öffneten sie von Hand Leistungsschalter in mehr als 50 Umspannwerken. Sie deaktivierten Seriell-zu-Ethernet-Konverter, löschten PCs mit KillDisk und überlasteten ein Callcenter. Deshalb musste die Stromversorgung vor Ort wiederhergestellt werden, was etwa sechs Stunden dauerte. Die US-Regierung schrieb den Angriff später Sandworm zu, einer Einheit des russischen GRU.

Ziel
Drei regionale Stromverteilungsunternehmen in der Ukraine
Zugeschrieben
Sandworm (GRU) (Zuschreibung durch die US-Regierung; Anfang 2016 konnten Analysten die Verantwortlichen noch nicht benennen)
Erster Zugang
Phishing-E-Mail, Gestohlene Zugangsdaten, VPN-Zugang
Angegriffene Systeme
SCADA-Steuerungssysteme, erreicht über Fernzugriffstools; Seriell-zu-Ethernet-Konverter in Umspannwerken

2014Spionage

Havex

bekannte Opfer weltweit (Kaspersky)
2.800+
namentlich genannte Opferorganisationen
101

Havex war eine Spionagekampagne gegen den Energiesektor. Sie wurde im Juni 2014 bekannt und wird auch unter den Namen Dragonfly oder Energetic Bear verfolgt. Ihre Opfer erreichte sie auf drei Wegen: über Phishing-E-Mails mit manipulierten PDF-Dateien, über präparierte Websites, die Besucher infizierten, und vor allem über gehackte Download-Seiten. Bei mindestens drei kleinen Herstellern von Industriesoftware wurden die Installationsprogramme durch Versionen ersetzt, die zusätzlich Havex enthielten. Kaspersky zählte weltweit mehr als 2.800 Opfer.

Havex war eine Hintertür, die sich bei den Angreifern meldete und weitere Module nachlud. Ein Modul suchte im Netzwerk nach OPC-Servern, also nach der Windows-Middleware, mit der Programme Live-Daten vieler Steuerungen lesen können. Es schickte die Angaben zu diesen Servern an die Angreifer. Schon das Scannen ließ einige Server abstürzen. Havex stahl Informationen, hatte aber keine Sabotagefunktion. 2014 waren sich Analysten über die Herkunft uneinig. 2022 schrieb die US-Regierung die Kampagne dem russischen FSB zu.

Namen
Havex, Backdoor.Oldrea (Symantec)
Ziel
Energieunternehmen und Hersteller von Industrieanlagen, vor allem in den USA und Europa
Zugeschrieben
FSB (Russland) (Im Jahr 2014 vermuteten Sicherheitsfirmen einen staatlichen Akteur; die USA nannten 2022 den russischen FSB als Verantwortlichen)
Erster Zugang
Phishing-E-Mail, Gehackte Website, Lieferkette
Protokolle
OPC
Angegriffene Systeme
OPC-Server, die Windows-Middleware, die Live-Anlagendaten für andere Software bereitstellt

2010Zerstörung

Stuxnet

in Natanz außer Betrieb genommene Zentrifugen (Schätzung von ISIS)
~1.000
weltweit infizierte Computer bis September 2010
100.000

Stuxnet wurde im Juni 2010 entdeckt und ist die erste bekannte Malware, die physische Maschinen beschädigt hat. Der Wurm verbreitete sich auf etwa 100.000 Computer in mehr als 150 Ländern. Schaden sollte er aber nur einem Ziel: einer iranischen Urananreicherungsanlage, die Forscher mit Natanz in Verbindung brachten. Weil das Steuerungsnetz der Anlage keine Internetverbindung hatte, wurde der Wurm höchstwahrscheinlich auf einem Wechseldatenträger eingeschleust. Danach verbreitete er sich selbstständig über vier unbekannte Windows-Lücken und die Projektdateien der Siemens-Engineering-Software Step 7.

Er lud versteckten Code auf Siemens-S7-300-Steuerungen und ließ die Motoren der Zentrifugen weit außerhalb ihres normalen Drehzahlbereichs laufen. Gleichzeitig spielte er den Bedienern normale Messwerte vor, sodass sie nichts bemerkten. Ein Institut schätzte, dass etwa 1.000 der 8.692 installierten Zentrifugen außer Betrieb genommen wurden. Der Zusammenhang mit Stuxnet ist nicht bewiesen. Presseberichte beschreiben eine gemeinsame Operation der USA und Israels. Keine Regierung hat bestätigt, wer den Wurm entwickelt hat.

Namen
Stuxnet, Rootkit.TmpHider (VirusBlokAda), W32.Temphid (Symantec)
Ziel
Eine Urananreicherungsanlage im Iran, die von Forschern mit Natanz in Verbindung gebracht wird
Zugeschrieben
Nicht offiziell zugeordnet (Keine Regierung hat dies bestätigt; die Zuordnung stützt sich auf Presseberichte)
Erster Zugang
Wechseldatenträger
Protokolle
Profibus, Siemens S7
Angegriffene Systeme
Siemens-S7-300-Steuerungen und deren Frequenzumrichter, über die Software Step 7 und WinCC
Wie weit jeder Angriff entlang der Kill Chain kam
NamePhase 1: EindringenPhase 2: Angriff auf den industriellen Prozess
Stuxnet 2010 5 / 8 4 / 5
Havex 2014 7 / 8 0 / 5
BlackEnergy 2015 4 / 8 4 / 5
Industroyer / CRASHOVERRIDE 2016 2 / 8 4 / 5
TRISIS / TRITON 2017 1 / 8 4 / 5
EKANS / Snake 2020 0 / 8 2 / 5
Industroyer2 2022 1 / 8 2 / 5
PIPEDREAM / INCONTROLLER 2022 0 / 8 1 / 5
Fuxnet 2024 1 / 8 4 / 5
FrostyGoop / BUSTLEBERM 2024 4 / 8 3 / 5

Jeder Balken zählt die Schritte einer Phase, die öffentliche Berichte für den Angriff beschreiben. Ein kurzer Balken kann auch bedeuten, dass ein Schritt nicht dokumentiert ist.

So liest du die Fälle

Jeder Artikel beginnt mit dem Steckbrief der Schwachstelle. Darin stehen die CVE-Nummer, die Bewertung in der US-amerikanischen National Vulnerability Database und die Daten von der ersten Meldung bis zum Patch und zu den ersten Angriffen. Darunter erklärt der Artikel, wie die Lücke funktionierte und wie es weiterging. Diagramme zeigen die Zahlen aus öffentlichen Berichten.

Der CVSS-Wert gibt auf einer Skala von 0 bis 10 an, wie schwerwiegend eine Sicherheitslücke ist. Er sagt nichts darüber aus, wie oft sie bei Angriffen ausgenutzt wurde. Einige der Fälle mit den größten Schäden haben hier nur mittlere Werte.

Wie eine Schwachstelle auf diese Liste kommt

Diese Liste ist keine Datenbank aller Sicherheitslücken: Jedes Jahr erhalten Zehntausende eine CVE-Nummer. Sie enthält nur die Fälle, die das ganze System erschüttert haben. Eine Schwachstelle kommt nur auf die Liste, wenn sie alle drei Grundbedingungen und mindestens zwei der vier Ausmaß-Kriterien erfüllt.

Grundbedingungen

  1. Ein konkreter Fehler in einem weit verbreiteten Produkt oder einer Komponente, öffentlich dokumentiert: mit CVE-Nummer oder Sicherheitshinweis des Herstellers. Schadsoftware zählt über die Lücke, die sie ausgenutzt hat.
  2. Viele unabhängige Betreiber betroffen, in vielen Ländern, nicht nur die Kunden eines einzelnen Unternehmens.
  3. Durch Primärquellen belegt: Herstellerhinweise, Behörden oder Messstudien.

Ausmaß-Kriterien (mindestens zwei)

KriteriumErfüllt, wenn
ReichweiteMessungen mindestens 100.000 betroffene Systeme fanden oder die Lücke in einer Komponente steckt, die auf mindestens einem Zehntel aller Systeme ihrer Art läuft, etwa Prozessoren, Webservern oder Websites
MassenausnutzungAngriffe mindestens 1.000 Organisationen oder 100.000 Systeme trafen oder sich ein Wurm selbst verbreitete
Schadenein Schaden von mindestens einer Milliarde US-Dollar belegt ist, kritische Dienste wie Krankenhäuser, Stromversorgung oder Verkehr ausfielen, oder Daten von mindestens zehn Millionen Menschen betroffen sind
Außergewöhnliche ReaktionMaßnahmen über das übliche Patchen hinausgingen: die höchste Warnstufe einer nationalen Cyberbehörde, eine Notfallanordnung einer Regierung, Fixes in allen großen Betriebssystemen zugleich oder eine Koordination über Branchen und Länder hinweg

Ein hoher Schweregrad allein reicht nicht. Meltdown hat einen CVSS-Wert von 5,6 und steht auf der Liste, viele Lücken mit dem Wert 10 nicht. Jede Fallseite zeigt, welche Kriterien der Fall erfüllt und warum.

Bekannt, aber nicht auf der Liste

Diese Schwachstellen sorgten für Schlagzeilen, erfüllen aber weniger als zwei der vier Ausmaß-Kriterien.

NameJahrHaupt-CVEWarum nicht
xz Utils backdoor2024CVE-2024-3094Entdeckt, bevor die Hintertür in stabile Versionen der großen Linux-Distributionen gelangte; keine bekannten Angriffe, kein Schaden. Erfüllt nur das Kriterium Reaktion: ein Beinahe-Fall.
TunnelVision2024CVE-2024-3661Erlaubt einem Angreifer im selben lokalen Netz, Datenverkehr am VPN vorbeizuleiten; keine Massenangriffe, kein gemeldeter Schaden, keine außergewöhnliche Reaktion.