RTU-Forensik: Wie Sandworm vom Büronetz ins polnische Stromnetz sprang
15.08.2026 ot-forensicsics-securitywiper-malwarecritical-infrastructure
Am Morgen des 29. Dezember 2025 verloren mehr als 30 Wind- und Solarparks in Polen sowie ein großes Heizkraftwerk gleichzeitig die Fernsteuerbarkeit ihrer Umspannwerke. CERT Polska dokumentierte in seinem am 30. Januar 2026 veröffentlichten Bericht, dass die Angriffe auf Netzverknüpfungspunkte abzielten – Knotenpunkte, die Energie aus Wind- und Photovoltaikquellen ins Verteilnetz einspeisen, mit zahlreichen Automatisierungsgeräten wie RTUs für Fernsteuerung, lokalen HMIs, Schutzrelais sowie Kommunikationsgeräten wie seriellen Port-Servern, Modems, Routern und Switches. Nach der Erstinfiltration führte der Angreifer eine Aufklärung durch und bereitete anschließend einen Plan destruktiver Aktionen gegen die kompromittierten Geräte vor: Beschädigung der Controller-Firmware, Löschen von Systemdateien oder Ausführung eigens entwickelter Wiper-Malware. Der teilautomatisierte Plan wurde am Morgen des 29. Dezember ausgelöst; durch die Beschädigung der RTUs verloren die Stationen die Kommunikationsfähigkeit mit den Systemen des Verteilnetzbetreibers und die Fernsteuerung wurde verhindert, ohne jedoch die laufende Energieproduktion zu beeinträchtigen.
Vom FortiGate ins RTU: Der Weg quer durch IT und OT
Besonders für Forensiker relevant ist der initiale Zugangsweg. Sicherheitsforscher beschrieben, wie Angreifer über ein privates APN und ein Teltonika-Gerät von der IT-Seite in die OT-Umgebung vordrangen. Beim Heizkraftwerk verlief der Angriff klassischer über Enterprise-Kompromittierung: CERT Polska dokumentierte Initialzugriff, Modifikation der FortiGate-Konfiguration zur Persistenz sowie Aktivitäten gegen Cloud-Dienste. Die Gruppe nutzte dabei Zugangsdaten aus der On-Premises-Umgebung, um Zugriff auf Cloud-Dienste zu erlangen; nach Identifikation von Konten, die auch in M365 existierten, wurden gezielt Daten aus Exchange, Teams und SharePoint heruntergeladen. Besonders aufschlussreich für die Absicht: der Angreifer interessierte sich vor allem für Dateien und E-Mails zur OT-Netzmodernisierung, SCADA-Systemen und technischen Arbeiten in den Organisationen. Beim Heizkraftwerk-Ziel erlangte der Angreifer Zugriff auf privilegierte Konten, wodurch er sich frei im System bewegen konnte – der Versuch, die Schadsoftware zu aktivieren, wurde jedoch durch die eingesetzte EDR-Lösung blockiert.
Die eingesetzte Wiper-Malware war technisch bemerkenswert: Ein PowerShell-basierter Wiper namens LazyWiper überschrieb Dateien mit pseudozufälligen 32-Byte-Sequenzen, um sie unwiederherstellbar zu machen – die Kernfunktion wurde vermutlich mithilfe eines Large Language Models entwickelt. Bei den Erneuerbaren-Anlagen kam ein zweiter Wiper namens DynoWiper zum Einsatz, der direkt auf der HMI-Maschine ausgeführt wurde. ESET attribuierte den Angriff später mit mittlerer Konfidenz der Sandworm-Gruppe, während CERT Polska Infrastrukturüberlappungen mit dem auch als Static Tundra, Berserk Bear oder Dragonfly bekannten Cluster feststellte.
Warum klassische Forensik an RTUs scheitert
Für Incident Responder liegt die eigentliche Herausforderung nicht in der Attribution, sondern in der Beweissicherung an den betroffenen Embedded-Geräten selbst. Mandiant weist in seinem DFIR-Framework für eingebettete Systeme darauf hin, dass etablierte Tools wie Redline, FTK Imager oder Volatility zwar den Standard für IT-Endpunkte und OT-Zwischensysteme setzen, bei der Datensammlung aus Embedded-Systemen aber nur begrenzten Wert haben. Das Problem ist strukturell: Forschungsarbeiten zur PLC-Speicherforensik zeigen, dass bestehende Methoden zur Speicherakquise entweder unpraktikabel sind, weil sie das Zerlegen des verdächtigen Geräts oder einen Power-Cycle erfordern, oder unvollständig, weil sie nur Teile des Speicherinhalts erfassen. Genau dieses Dilemma trifft RTUs im Poland-Fall: Ein Abschalten zur „Sicherung" hätte flüchtige Laufzeitartefakte vernichtet, ein Weiterbetrieb hätte die Wiper-Aktivität möglicherweise fortgesetzt.
Hinzu kommt die physische Realität von OT-Incident-Response: Anders als ein Server lässt sich ein Schutzrelais oder eine RTU an einem Netzverknüpfungspunkt nicht einfach isolieren, ohne Sicherheits- und Prozessfolgen abzuwägen. SANS betont entsprechend, dass ICS/OT-Vorfälle Reaktionspläne erfordern, die auf technischem Kontext, Prozessbewusstsein und operativer Kontinuität aufbauen statt auf IT-Recovery-Playbooks – ohne zweckgebundene ICS/OT-Incident-Response-Planung riskieren Organisationen, dass aus einem Cyber-Vorfall ein selbstverschuldeter Ausfall der Leittechnik wird.
Für Forensik-Teams ergeben sich daraus konkrete Konsequenzen: Beweissicherung an RTUs und Schutzrelais muss vorab getestet und dokumentiert sein, bevor ein Vorfall eintritt – Ad-hoc-Imaging im Feld ist keine Option. Firmware-Hashes, Konfigurationsbackups und Netzwerk-Baselines der seriellen und Ethernet-Kommunikation gehören ebenso zur Forensic Readiness wie die Frage, welche Geräte im Ernstfall überhaupt sicher vom Netz genommen werden können. Der Fall zeigt zudem, dass der Übergang von IT zu OT – über VPNs, private APNs oder wiederverwendete Zugangsdaten – der eigentliche Tatort ist, an dem forensische Spuren gesammelt werden müssen, bevor der Angreifer die physische Ebene erreicht.
← Zurück zur Übersicht