Industroyer

Kurz & knapp

Industroyer ist eine Malware zur gezielten Manipulation der physischen Komponenten industrieller Steuernetze. Sie kam erstmalig 2016 zum Einsatz und bewirkte einen flächendeckenden Stromausfall in der Ukrainischen Hauptstadt Kiew.

Am 17.12.2016 kam es in der ukrainischen Hauptstadt Kiew für mehrere Stunden zu flächendeckenden Stromausfällen. Ursache war das irreguläre Abschalten mehrerer Umspannwerke des regionalen Energieversorgers. Das slowakische IT-Sicherheitsunternehmen ESET wurde nachfolgend mit der Überprüfung der Kommunikation in den Fernwirk- und Netzleitsystemen beauftragt. Dort fand ESET verschiedene Softwaremodule, die sich später als Teile einer komplexen Malware entpuppten. Die Malware erhielt den Namen Win32/Industroyer. Im Juni 2017 beauftragte ESET das US-Amerikanische IT-Sicherheitsunternehmen Dragon Inc. mit der Verifizierung und Zweitanalyse der Malware. Da sich laut Dragon Inc. die Malware im Zuge der Funktionsanalyse mehrfach selbst als CRASH identifiziert, benannte Dragon Inc. die Malware nachfolgend als Crashoverride.

Die Ergebnisse beider Analysen skizzieren eine äußerst professionelle und branchenübergreifend einsetzbare Malware, die spezielle zur Störung physischer Komponenten in industriellen Steuernetzen entwickelt wurde.

Die Inhalte dieses Beitrags beziehen sich mehrheitlich auf die Analysen der beiden involvierten IT-Sicherheitsunternehmen. Der Einfachheit halber wird die Malware in diesem Beitrag als Industroyer bezeichnet.

Besonderheiten der Malware Industroyer

Industroyer ist die 4. bekannte Malware, die speziell auf industrielle Steuernetze ausgerichtet ist. Zuvor gab es die Malwares Stuxnet, Blackenergy 2 und Havex. Nach Stuxnet ist Industroyer die erst 2. Malware, die konkret physische Störungen industrieller Prozesse bewirkt und die 1. bekannte Malware mit Fokus auf elektrische Verteilnetze.

Hinter der Attacke wird eine Gruppe namens ELECTRUM vermutet, der enge Verbindungen zum berüchtigten Sandworm Team  nachgesagt werden. Das Sandworm Team wird für eine Vielzahl von Cyberattacken auf hochrangige Ziele der Industrie und verschiedener Regierungen sowie den flächendeckenden Stromausfall in der Ukraine im Dezember 2015 verantwortlich gemacht.

Industroyer wird aufgrund einiger Besonderheiten von Analysten als besonders potent und wirkungsvoll eingestuft. Es wird gemutmaßt, dass die Cyberattacke im Dezember 2016 nur ein Feldtest sein sollte, um die grundlegende Funktionsweise in einer reellen Umgebung zu prüfen. Deshalb wird auch davon ausgegangen, dass in Zukunft weitere Cyberattacken auf Basis der Industroyer-Architektur vorkommen werden, die weitaus stärkeren Schaden anrichten können.

Zu den Besonderheiten zählen:

  • Angriffsvektor und Funktionsweise machen Industroyer hersteller- und konfigurationsübergreifend einsetzbar.
  • Angreifer und Malware nutzen Netzwerkkommunikationsmuster zur Infiltration und werden damit sehr gut gegenüber gängigen IT-Sicherheitslösungen maskiert. Dafür werden die Industriestandardprotokolle nach IEC 60870-5-104, ICE 60870-5-101, IEC 61850 sowie OLE für Process Control Data Access (OPC DA) genutzt.
  • Die Malware ist leicht übertragbar auf Stromnetze in Europa, Mittlerer Osten und Asien.
  • Die Malware kann mit einer einfachen Erweiterung um das DNP3-Protokoll auf US-Amerikanische Stromnetze angewendet werden.
  • Die Malware kann über einfache Modifikationen beliebig auf andere industrielle Branchen übertragen werden.
  • Industroyer kann mehrere Standorte gleichzeitig attackieren.
  • Industroyer kombiniert die Funktionsweisen der drei bekannten vorhergehenden Malware-Typen Stuxnet, Blackenergy 2 und Havex, verfeinert diese und ergänzt sie um die Wirkweise der Cyberattacke im Dezember 2015. Letztere zeichnete sich dadurch aus, dass sie das Steuersystem so manipulierte, dass es sich selbst außer Gefecht setzte.

Zweck und Funktion von Industroyer

Die Malware wird aufgrund ihrer Kommunikationsmuster als reine Attackier-Malware klassifiziert. Eine Spionagefunktion konnte ihr nicht nachgewiesen werden.

Die Grundfunktion der Industroyer-Malware besteht darin, virtuelle Schalter in Umspannwerken und Überstromschutzeinrichtungen direkt zu beeinflussen.

Dadurch kann Industroyer:

  • die Stromverteilung komplett ausschalten;
  • ein kaskadenförmiges Zusammenbrechen des Stromnetzes bewirken und
  • die Hardwarekomponenten der Netzleit- und Fernwirksysteme schwerwiegend beschädigen.

Aufbau von Industroyer

Die Malware wurde gezielt auf das Stören von Stromverteilnetzen ausgerichtet. Um die Funktionsweise nachvollziehen zu können, lohnt sich ein kurzer Blick in die generelle Architektur der Netzleit- und Fernwirksysteme.

Nach der Energieerzeugung wird die Energie in der Regel über Hochspannungsleitungen längere Wegstrecken zu Umspannwerken transportiert (long-transmission level). In den Umspannwerken wandeln Transformatoren den Hochspannungsstrom in Mittelspannungsstrom bzw. Niederspannungsstrom um. Von dort wird der Strom an die jeweiligen regionalen Verbraucher weitergeleitet. Stadtwerke speisen ihren Strom häufig direkt in das Mittelspannungsnetz ein.

Die Steuerung der Umspannwerke erfolgt über SCADA-Systeme (Supervisory Control and Data Acquisition). Unter anderem werden darüber auch die Fernbedienterminals (Remote Terminal Unit, RTU) angesteuert, welche die Lasttrennschalter in Umspannwerken öffnen und schließen können. Diese Lasttrennschalter sorgen dafür, dass Strom in die Verteilernetze fließt (geschlossen) oder der Stromfluss unterbrochen wird (geöffnet). Letzterer Zustand bedeutet, dass die Verbraucher im Einflussbereich des Umspannwerkes, dann nicht mit Strom versorgt werden (Blackout).

In Europa, dem Mittleren Osten sowie Asien werden für die Kommunikation über SCADA-Systeme standardmäßig die Protokolle IEC 104 und IEC 101 genutzt. In den USA ist das Industrieprotokoll DNP3 im Einsatz. Alle Protokolle werden letztlich angewendet, um die physischen Komponenten über RTUs, speicherprogrammierbare Steuerungen (SPS) sowie spezifische Komponenten zu steuern. Zusätzlich kommt das Protokoll IEC 61850 global zum Einsatz, um die Kommunikation zwischen Human-Machine-Interfaces (HMI) mit Digitalrelais und anderen intelligenten elektronischen Einheiten (Intelligent Electronic Devices, IEDs) zu steuern. Verschiedene IEDs finden sich typischerweise als zusätzliche Komponenten an den Lasttrennschaltern.

Wie sich hier schon zeigt, sattelt Industroyer sehr dezidiert auf die Kommunikationsstrukturen der Stromverteilnetze auf, die im Übrigen global mehr oder weniger identisch sind. 

Industroyer wurde als modulare Malware konzipiert. Die Hauptkomponenten sind:

  • Hauptbackdoor als Kommunikationsgateway zu externen Servern (Befehlsempfang und Reporting) und für Steuerung der anderen Komponenten;
  • Ersatzbackdoor;
  • Port-Scanner;
  • Denial-Of-Service-Tool;
  • Launcher;
  • Data Wiper;
  • Nutzlastkomponenten-Module (Payload-Module) für die vier Protokolltypen IEC 104, IEC 101, IEC 61850 und OLE für Process Control Data Access (OPC DA).

Funktionsweise von Industroyer

Backdoorinstallation

Die Angreifer installierten zuerst die Hauptbackdoor. Diese authentifizierte sich mit einem lokalen Proxy über das interne Netzwerk. Die Grundstruktur hierfür wurde bereits vor der Installation gelegt. Nach der Authentifizierung öffnete die Backdoor einen HTTP-Kanal zu einem externen Command-and-Control-Server, der im TOR-Netzwerk verborgen war. Mit Etablierung dieser Verbindung wurden die weiteren Module und Befehle übertragen. Dafür erstellte die Backdoor eine Datei im lokalen System, deren Inhalte jedoch nicht mehr rekonstruiert werden konnten. Weiterhin überschrieb die Backdoor einen bestehenden Service und verwies auf sich selbst als neuen Service. Dadurch hatte sich die Backdoor im System etabliert und würde auch nach Reboots automatisch geladen werden.

Zusätzlich installierte die Backdoor eine zweite Backdoor, die als Notepad-Applikation getarnt wurde. Diese Ersatz-Backdoor fungierte als Fallback, falls die Hauptbackdoor vom Netzbetreiber detektiert und deaktiviert werden sollte.

Weiterhin installierte die Backdoor weitere spezifische Tools, zu denen nach heutigem Stand ein Port-Scanner sowie ein Denial-of-Service-Tool zählten. Der eigens für den Angriff programmierte Port-Scanner sollte das Netzwerk weiter nach geeigneten Computern und Komponenten scannen, um vermutlich eine Ausweitung des Angriffs zu ermöglichen. Das Denial-of-Service-Tool wiederum galt dem gezielten Ausschalten bestimmter Geräte. Dafür wurde die CVE-2015-5374-Schwachstelle in Siemens SIPROTECT-Geräten genutzt.

Schlussendlich installierte die Backdoor das Launcher-Modul, welches die operative Umsetzung der Störungen steuerte.

Die Backdoor fungierte demnach als vorbereitende Instanz, um alle Komponenten in die richtige Position zu bringen sowie um die Kommunikation zu den externen Servern zu gewährleisten.

Launcher

Der Launcher öffnete sich selbst als regulärer Service - vermutlich, um sich besser zu tarnen.

Dieser lud automatisch die Payloads mit den Modulen IEC 104, IEC 101, IEC 61850 und OPC DA und führte diese aus. Die Payload-Module manipulierten nachfolgend die verschiedenen Komponenten im Netzteil- und Fernwirksystem und führten so zu den Störungen.

Mit einem Countdown von 1-2 Stunden wurde zusätzlich der Data Wiper aktiviert, um nach der Störung alle Beweise zu vernichten und die Wiederherstellung des Systems zu erschweren.

Payload-Module

Die einzelnen Payload-Module griffen je nach verwendeten Protokollen in die Kommunikation mit relevanten Komponenten im Netzleit- und Fernwirksystem ein.

Die Module IEC 101 und IEC 104 ermittelten über eine Konfigurationsdatei zuerst die Ziele (vermutlich RTUs der Lasttrennschalter). In diesen übernahmen sie nachfolgend den Master-Prozess und schalteten die Komponenten in einen von vier bis dato identifizierten Modus:

1. Sequence Mode: RTUs Information Object Adress (IOA) wird dauerhaft auf offen gesetzt und der Stromfluss unterbrochen.

2. Range Mode: Payload untersucht den aktuellen Zustand der IOA und schaltet sie auf den entgegengesetzten Zustand (offen zu geschlossen, geschlossen zu offen).

3. Shift Mode: Bisher nicht geklärt.

4. Persist Mode: Bisher nicht geklärt.

Während das Modul IEC 104 auf fernbediente Komponenten zugreifte, zielte das Modul IEC 101 auf Geräte mit seriellen Verbindungen.

Das Modul IEC 61850 identifizierte ebenfalls über eine Konfigurationsdatei seine Ziele. Lag keine Konfigurationsdatei vor, untersuchte es das Netzwerk nach potentiellen Zielen. Über entsprechende Protokolle kommunizierte es mit den Zielen, um herauszufinden, ob diese Lasttrennschalter steuerten. Fiel die Anfrage positiv aus, veränderte das Modul bestimmte Statusparameter und erstellte ein Action Log. Zu den konkreten Parametern liegt bisher keine Information vor.

Das Modul OPC DA schlussendlich untersuchte alle OPC-Server und damit verbundenen Komponenten im Netzwerk auf Dateien, die mit Geräten der Firma ABB assoziiert sind und den String “ctl.” enthalten. Fiel die Anfrage positiv aus, wurden in den Dateien die Anlagenzustandsdaten zu doppelt “0x01” umgeschrieben. In der Steuersprache bedeutet dies, dass die betroffene Komponente oberhalb seiner Belastbarkeitsgrenze operiert. Damit wurde dem Betreiber ein falscher Statuswert der Komponente im SCADA zugespielt. Diese Form der Attacke wird auch als Denial-Of-Visibility bezeichnet, da die Betreiber einer Anlage blind gegenüber den tatsächlichen Prozessdaten werden.

Neben der konkreten Manipulation der Steuerungen durch die IEC-Module wurde somit auch die Kontrollvisualisierung effektiv manipuliert.

Data Wiper

Der Data Wiper sollte 1-2 Stunden nach dem Launch der Payload-Module starten. Seine Funktion galt der Verschleierung der Attacke sowie der Erschwerung der Systemwiederherstellung. Dafür wurden drei Kernschritte durchgeführt:

1. Löschen aller mit dem System assoziierten Registry Keys.

2. Überschreiben aller Steuernetz-Konfigurationsdateien auf allen Harddrives und Netzwerk-Drives mit spezieller Zielsetzung auf ABB PCM600-Konfigurationsdateien.

3. Überschreiben aller generischen Windows-Dateien.

Mit diesen Schritten wurde das gesamte System unbenutzbar.

Warum haben die IT-Sicherheitstechnologien versagt?

Aktuell ist nicht bekannt, welche Sicherheitsvorkehrungen in den Systemen des Verteilnetzbetreibers aktiv waren. In der Regel kann jedoch von Perimeter-Firewalls ausgegangen werden, welche am Übergang zwischen Netzteil- und Fernwirksystem zum Internet appliziert waren.

Industroyer brachte zwei Eigenschaften mit, die es der Sicherheitslösung unmöglich machte, die Malware zu identifizieren:

1. Die Malware war unbekannt. Damit wurde sie beim Eindringen in das System nicht als Gefahr detektiert.

2. Die Malware kommunizierte und agierte in der systemeigenen Sprache der Industrieprotokolle.

Zudem konnte die Malware innerhalb des Systems vermutlich undetektiert agieren, weil die IT-Sicherheitstechnologie (Firewall) ausschließlich die “Tore” zum und aus dem System überwachte. Eine Firewall hat jedoch keinerlei Einblick in das System.

Hätte die Malware erkannt werden können?

Eine Lösung mit Echtzeit-Anomalieerkennung auf Basis der Deep-Packet-Inspection-Technologie hätte die Attacke frühzeitig detektiert und gemeldet.

Eine Anomalieerkennung hätte bereits die Hauptbackdoor als neuen Netzwerkteilnehmer identifiziert. Nachfolgend wären die neuen Kommunikationsstränge zwischen der Hauptbackdoor, seinen neu installierten Komponenten sowie den Netzwerkkomponenten (RTUs, OPC-Server) als verdächtig gemeldet worden. Bereits in der ersten Phase der Attacke wäre der Betreiber über diese verdächtigen Aktivitäten informiert worden.

Weiterhin wären verschiedene Befehle aufgefallen, die nicht zur Standardkommunikation des jeweiligen Netzwerkes gehören (Überschreiben von Dateien oder Festschreiben dynamischer Werten). Die Deep-Packet-Inspection-Technologie hätte mittels der kontinuierlichen Detailanalyse aller Datenpakete im Netzwerk hierfür die Belege geliefert. So wäre die Übernahme von Master-Prozessen oder das harte Überschreiben von Werten sofort aufgefallen.

Die Betreiber hätten die Veränderungen in der Netzwerkkommunikation umgehend überprüfen und entsprechende Gegenmaßnahmen einleiten können.