Siemens-SPS-Angriff: KI liefert nur das Tool

Fünf US-Behörden warnen vor Angriffen auf S7-Steuerungen mit KI-geschriebenen Skripten. Warum das noch kein KI-Angriff ist, und was der Unterschied ist.

7 Min. Lesezeit

Fünf US-Behörden haben am 19.08.2026 ein gemeinsames Advisory zu Angriffen auf industrielle Steuerungen veröffentlicht: NSA, CISA, FBI, das Energieministerium und die Umweltbehörde EPA. Die Behörden formulieren es unmissverständlich: "This is not a theoretical risk – it is an active threat." Also kein theoretisches Risiko, sondern eine aktive Bedrohung.

Betroffen sind speicherprogrammierbare Steuerungen der Siemens-S7-Reihe, laut BleepingComputer die Baureihen S7-200, S7-300, S7-400, S7-1200 und S7-1500. Als Zielbranchen nennen die Berichte kritische Fertigung, Energie, Wasser und Abwasser, Chemie, Lebensmittel und Landwirtschaft sowie kommerzielle Einrichtungen. Steuerungen dieser Baureihen laufen daneben auch in der Rüstungsindustrie.

Was die Angreifer tatsächlich machen

Der Ablauf ist unspektakulär, und genau das ist der Punkt.

Gesucht wird über gewöhnliche Suchmaschinen für vernetzte Geräte, Censys und ZoomEye. Ausgenutzt werden veraltete Software und Standardpasswörter. Der Zugriff selbst läuft über python-snap7 und snap7.dll, zwei quelloffene Bibliotheken für industrielle Automatisierung, die es seit Jahren gibt und die für legitime Zwecke gebaut wurden. Den Berichten zufolge nutzen die Angreifer KI, um daraus passende Exploit-Skripte zu erzeugen. Die fertigen Werkzeuge tarnen sich als reguläre OT-Monitoring-Software und erlauben lesenden und schreibenden Zugriff auf Speicher und Programmlogik der Steuerung über das S7comm-Protokoll. Als Ziele nennen die Behörden Erstzugang, Zugangsdaten und die Störung des Betriebs.

Zur Urheberschaft halten sich die Behörden bedeckt. The Register bringt die Aktivität mit iranischen Akteuren in Verbindung, im Zusammenhang mit Angriffen auf Wasserversorger in mehreren US-Bundesstaaten. Das ist eine Einschätzung, keine Feststellung, und sie gehört sauber getrennt vom technischen Befund.

Ist das ein KI-Angriff?

Die Berichterstattung dazu läuft unter Schlagworten wie "AI-powered attacks", und das führt in die Irre. Die Behörden selbst schreiben nüchterner von KI-generierten Skripten. Der Unterschied ist kein Wortklauben, er entscheidet darüber, was man dagegen tut.

Sinnvoll sind drei Stufen:

StufeWas die KI tutBeispiel
WerkzeugbauSetzt aus bekannten Bausteinen ein lauffähiges Skript zusammendieser Fall
Anpassung im EinsatzReagiert auf das konkrete Zielsystem und auf Gegenwehrdie Angriffe auf taiwanische Behördennetze im Juli
SchwachstellensucheFindet die Lücke selbstWiz' autonomer Agent im Fall Snowflake

Dieser Fall ist die unterste Stufe, und das ist kein Kleinreden. python-snap7 gibt es seit Jahren, S7comm ist dokumentiert, die ausgenutzten Schwächen sind veraltete Software und Standardpasswörter. Die KI findet hier nichts und entscheidet nichts, sie schreibt den Klebstoff zwischen bekannten Teilen. Wer daraus "die KI hackt jetzt Kraftwerke" macht, verschiebt die Aufmerksamkeit weg von dem, was tatsächlich hilft: Bestände kennen, Systeme nicht ins Internet hängen, Standardpasswörter loswerden.

Wie die zweite Stufe aussieht, hat Taiwans Digitalministerium im Juli erlebt: Laut der Sicherheitsfirma Dream arbeiteten dort zeitweise acht Agenten parallel, suchten nach Schwachstellen und änderten bei Widerstand ihr Vorgehen. Das ist eine andere Klasse als ein fertiges Skript.

Ob die Skripte im Siemens-Fall je Zielsystem angepasst werden, geht aus den Berichten nicht hervor. Eine S7-300 spricht anders als eine S7-1500, irgendeine Anpassung wird es also geben. Aber das ist ein Mensch, der ein Werkzeug nachschärft, keine Software, die sich im Einsatz selbst umbaut.

Warum das auch für Softwareteams zählt

Die meisten unserer Leser haben nie eine SPS programmiert. Trotzdem steht in diesem Advisory etwas, das den eigenen Arbeitsalltag betrifft, und es hängt genau an der untersten Stufe.

Was sich geändert hat, ist die Lücke zwischen "die Information ist öffentlich" und "ich habe ein lauffähiges Werkzeug". Diese Lücke war früher die eigentliche Schutzwirkung. Nicht die Geheimhaltung, sondern der Aufwand: Man musste ein Protokoll verstehen, eine Bibliothek einarbeiten, Fehler debuggen. Wer das konnte, war eine überschaubare Gruppe.

Genau diesen Teil der Arbeit erledigt heute ein Coding-Assistent in einer Sitzung. Die Einstiegshürde verschwindet damit nicht vollständig, Zielauswahl und Betriebswissen bleiben nötig, aber sie sinkt so weit, dass die entscheidende Größe nicht mehr das Können ist, sondern die Zahl der erreichbaren Systeme.

Das ist dieselbe Mechanik, die wir in diesem Jahr schon zweimal beschrieben haben: bei den offen im Netz liegenden Datenbanken hinter Vibe-Coding-Projekten und bei den Scannern, die gezielt Konfigurationsdateien von KI-Werkzeugen absuchen. Kein neuer Angriffstyp, sondern ein alter, der plötzlich in großer Zahl auftritt.

Was daraus folgt

Für Teams mit OT-Bezug nennen die Behörden das Übliche, und es ist nicht deshalb falsch, weil es bekannt ist: Bestand der S7-Systeme aufnehmen, Sicherheitsupdates einspielen, Internetzugang unterbinden, Authentifizierung härten, Netze segmentieren und auffälligen S7comm-Verkehr überwachen.

Für alle anderen ist die übertragbare Frage eine andere. Welcher Teil eurer Sicherheit beruht darauf, dass ein Angriff zu mühsam wäre? Ein internes Werkzeug ohne Authentifizierung, das nur über einen unbekannten Port erreichbar ist. Ein Admin-Endpunkt, den man kennen muss. Eine Altanwendung, deren Protokoll niemand mehr versteht. Solche Annahmen haben jahrelang getragen, weil der Aufwand für Angreifer real war. Dieser Aufwand ist gerade dabei zu verschwinden, und zwar für beide Seiten gleichzeitig.

Der ehrliche Trost dabei: Dieselben Werkzeuge stehen auch der Verteidigung offen. Ein Nachmittag mit einem Coding-Agenten reicht heute, um den eigenen Bestand zu scannen, Standardpasswörter zu suchen oder ein vergessenes System zu finden. Wer diese Arbeit nicht macht, überlässt sie jemand anderem, der dieselben Werkzeuge benutzt.

Einschränkung

Das Advisory selbst war aus unserer Arbeitsumgebung nicht abrufbar, sowohl cisa.gov als auch der Server mit der PDF-Fassung antworten mit einem 403. Alle Angaben in diesem Artikel stammen deshalb aus zwei unabhängigen Sekundärquellen, die sich in den technischen Details decken. Wer betroffene Anlagen betreibt, sollte AA26-231A im Original lesen, bevor er Maßnahmen ableitet.

Quellen4