KI-Exploits in der Industrie: Angriffsvektoren und Gegenmaßnahmen

Industrieanlagen sind attraktive Ziele für Angriffe per KI, sogenannte KI-Exploits. NSA, FBI und weitere US-Behörden haben dazu jetzt eine Warnung herausgegeben.

Gefahrenbeschreibung am Beispiel von Siemens S7-Steuerungen

Am 19. August 2026 haben NSA, die Cybersecurity and Infrastructure Security Agency (CISA), das FBI, das US-Energieministerium und die Umweltbehörde EPA eine gemeinsame Warnung veröffentlicht: Defending Against an Active Threat to Siemens S7 Series PLCs. Angreifer durchsuchen demnach das Internet nach Siemens-Steuerungen der S7-Reihe und greifen sie mit Skripten an, die ihnen KI-Sprachmodelle geschrieben haben. Die Behörden nennen die Lage eine aktive Bedrohung und stellen klar, dass es sich um kein theoretisches Risiko handelt.

Die Warnung gilt zwar nur für US-Anlagen, doch die Technik dahinter ist international relevant. In deutschen Werkhallen laufen die gleichen CPUs, Engineering-Stationen und oft der gleiche Fernzugang eines Systemintegrators. Wer eine S7 betreibt, sollte den Volltext des Advisorys deshalb wie eine Checkliste für die eigene Anlage lesen.

Im Visier stehen alle CPU-Varianten der Reihen S7-200, S7-300 und S7-400, die S7-1200 mit den CPUs 1211C bis 1217C sowie sämtliche S7-1500 einschließlich der F-Steuerungen für Sicherheitsfunktionen. Am häufigsten trifft die Aktivität Anlagen in der Fertigung, der Energieversorgung, der Wasser- und Abwasserwirtschaft, der Chemie und der Lebensmittelbranche. Auch Zulieferer der Verteidigungsindustrie stehen auf der Liste möglicher Ziele.

Der Ablauf ist erstaunlich unspektakulär und genau deshalb gefährlich. In der folgenden Tabelle ist jeweils neben den einzelnen Schritten auch die Technik aus dem MITRE ATT&CK Framwork angegeben. Dabei handelt es sich um eine kostenlose Wissensdatenbank, in der Techniken und Vorgehensweisen bei Cyberangriffen verzeichnet sind. Diese wird von Unternehmen genutzt, um Sicherheitsmaßnahmen zu entwickeln und zu prüfen.

Tabelle 1: KI-Exploit in der Industrie: Vorgehen

Früher scheiterten solche Angriffe meist an mangelndem Wissen. Wer beispielsweise S7comm ansprechen wollte, musste das proprietäre Protokoll verstehen und die Binärpakete selbst zusammensetzen. Diese Hürde ist nun dank KI entfallen. Die Angreifer beschreiben dem Modell ihr Ziel, das Modell greift auf frei verfügbare Automatisierungsbibliotheken zurück, und nach wenigen Korrekturrunden läuft das Werkzeug.

Die Behörden werten die Vorfälle als Aufklärung mit Vorlauf. Lesezugriffe dienen dazu, die Anlage zu verstehen: Welche Ventile hängen an welchem Datenbaustein, wann laufen die Wartungsfenster, wie sieht der Normalbetrieb aus. Schreibzugriffe für einen späteren Zeitpunkt bereiten die Angreifer damit vor.

Wie ernst diese Vorbereitung gemeint ist, zeigt eine ältere Warnung derselben Behördengruppe: In AA26-097A zu iranisch verbundenen Akteuren war bei einem bestätigten Opfer die Kontaktplanlogik so verändert worden, dass Sicherheitsabschaltung und Alarmierung ausfielen, während der Prozess weiterlief.

Eine Untersuchung an der ERP-Software Odoo zeigt, wie weit handelsübliche KI-Modelle gehen. Das Forschungsteam testete GPT-4o, Gemini, Claude, Microsoft Copilot und DeepSeek mit einer Social-Engineering-Technik, die ein Forschungsszenario vortäuscht. Für jede getestete Schwachstelle, darunter unauthentifizierte SQL-Injections und Rechteausweitungen, lieferten die Modelle nach drei bis vier Prompting-Runden lauffähige Angriffsskripte. Die Erfolgsquote lag bei hundert Prozent. Ein einfacher Agent führte den Code aus, gab die Fehlermeldung zurück ins Modell und ließ nachbessern. Kenntnisse über Speicherlayouts oder Systeminterna brauchte dafür niemand.

Ähnlich sieht es bei Smart Contracts aus. Eine Studie zur automatisierten Exploit-Generierung zeigt, dass Verschleierung des Quellcodes gegen Sprachmodelle nichts ausrichtet. Erst architektonische Komplexität, etwa verteilte Angriffsflächen über tiefe Vererbungsbäume, senkt die Erfolgsquote.

Die andere Seite der Medaille: Auch Verteidiger finden mit KI bestehende Lücken. Googles Agent Big Sleep entdeckte CVE-2025-6965 in SQLite, bevor Angreifer sie ausnutzen konnten. In der OpenSSL-Sicherheitsmeldung vom Juni 2026 taucht auch ein Forscher von Anthropic auf. Die Fähigkeit ist also echt und steht beiden Seiten offen.

Der Unterschied liegt in der Geschwindigkeit: Angreifer müssen eine einzige Lücke finden, Betreiber müssen möglichst alle Lücken schließen. Weil die Kosten auf der Seite der Angreifer stärker sinken als bei denjenigen, die sich gegen Angriffe verteidigen müssen, wächst die Asymmetrie.

Staatlich unterstützte Hackergruppen arbeiten längst mit diesen Techniken

Analysen von Microsoft Threat Intelligence, aufbereitet von der Cloud Security Alliance, dokumentieren den Übergang vom Experiment zum Werkzeug. Die russische Gruppe Forest Blizzard beispielsweise wertet mit KI-Sprachmodellen öffentlich zugängliche Informationen zu Satellitenkommunikation, Radartechnik und Technologie-Stacks möglicher Ziele aus. Aufklärungsarbeit, für die Analysten früher Tage brauchten, dauert damit nur noch Stunden.

Chinesische Akteure wie Charcoal Typhoon beschleunigen das Reverse Engineering von Sicherheitswerkzeugen und übersetzen Schadcode zwischen Programmiersprachen.

Nordkoreanische Gruppen bauen im großen Stil digitale Identitäten mit gefälschten Arbeitszeugnissen und Code-Portfolios, um Operatoren als Entwickler in westliche Technologieunternehmen einzuschleusen. Wer Fernwartung an Dienstleister vergibt, sollte diesen Punkt zweimal lesen.

Zwei Szenarien, die noch drohen könnten

Angriffsmuster aus dem KI-Modell

Forscher der Newcastle University haben mit dem Framework AttackLLM geprüft, ob Sprachmodelle physikalische Angriffsmuster selbst entwerfen können. Mehrere Agenten leiteten dafür die Regeln eines Prozesses ab: Die Pumpe muss zum Beispiel stoppen, wenn der Tank den Maximalpegel erreicht. Ein Agent las dazu historische Sensordaten, ein zweiter die Designdokumentation, ein dritter prüfte die Konsistenz.

Am Prüfstand einer mehrstufigen Wasseraufbereitung mit Ultrafiltration, Umkehrosmose und chemischer Dosierung entwarf ein Team menschlicher Fachleute in fünf Tagen 36 Angriffsszenarien. Die KI kam auf 159 neuartige Vektoren. Beunruhigend ist die Machart: Das Modell senkte Sensorwerte über viele Stunden in winzigen Schritten ab und legte kurze Störimpulse auf Pumpen und Ventile.

Das würde in der Realität dazu führen, dass der Tank irgendwann überläuft und die Pumpe nicht mehr funktioniert. Das bevorstehende Versagen des Systems ist in diesem Szenario bis kurz vor dem Eintritt des Ereignisses nicht anhand der gemessenen Daten vorhersehbar..

Eigene Engineering-Assistenten als Hintertür

Werkzeuge wie Siemens Industrial Copilot erzeugen SPS-Code aus natürlicher Sprache. Das Framework STBack demonstriert, wie sich genau dieser Weg nutzen lässt. Angreifer erzeugen zunächst harmlose Codebeispiele, injizieren Schadlogik und schleifen sie über einen Regelkreis aus Compiler, formaler Verifikation und Ähnlichkeitsprüfung so lange, bis der veränderte Code dem Original zu über 95 Prozent gleicht. Anschließend wird ein Zielmodell mit diesem Datensatz nachtrainiert.

Der Ingenieur schreibt später einen unauffälligen Prompt, das Modell liefert unbemerkt manipulierte Logik. Die Injections sind auf Steuerungen zugeschnitten und laufen an statischer Analyse und Fuzzing vorbei.

Zwei Beispiele aus den evaluierten Regeln:

• Ein Zähler koppelt die Schadroutine an den Ausführungszyklus der SPS und schaltet sie erst nach einem sehr hohen Schwellenwert scharf, womit sie jeden Kurztest in der Sandbox überlebt.
• Eine Variable wird korrekt initialisiert und bekommt zur Laufzeit einen winzigen Offset, der den Prozess langsam abdriften lässt. Die durchschnittliche Erfolgsquote lag bei knapp 83 Prozent.

Dass ausgerechnet SPS-Code so verwundbar ist, hat einen strukturellen Grund. Eine informationstheoretische Analyse von IEC-61131-3-Programmen zeigt, dass die meisten Informationen mit Relevanz zu Schwachstellen im Kontrollfluss stecken. In klassischer IT-Software liegen Fehler oft in der Syntax oder der Speicherverwaltung. In einer Steuerung hängt der Kontrollfluss direkt am physikalischen Prozess, und hier sind Sprachmodelle stark.

Welche Modellklasse dabei überhaupt zum Einsatz kommt, ist ebenfalls eine Sicherheitsfrage: Ein nachtrainierbares Open-Weights-Modell verhält sich hier anders als ein gehostetes Angebot, wie unser Beitrag zum Unterschied zwischen Open Source und Open Weights beschreibt.

Gegenmaßnahmen: was heute wirkt

Patchen allein reicht nicht mehr, um die Gefahren durch KI-Exploits zu vermeiden. Ein Angreifer, der Exploit-Code in wenigen Stunden produziert, gewinnt jedes Rennen gegen ein reaktives Schwachstellenmanagement. Die Behörden empfehlen deshalb einen mehrschichtigen Aufbau, in dem jede einzelne Schicht auch dann noch etwas bringt, wenn die Schicht davor versagt.

Nachfolgend ist ein Beispiel anhand der Siemens S7-Reihe beschrieben. Angegeben sind auch die Taxonomien aus den D3EFEND Framework.

Tabelle 2: Gegenmaßnahmen gegen KI-Exploits in der Industrie

Erkennung, die auf Verhalten statt auf Signaturen setzt

Polymorpher Code aus dem Modell läuft an signaturbasierten Systemen vorbei. Die Verteidigung muss deshalb selbst lernen. In einem Versuchsaufbau mit Mitsubishi-Steuerungen und SCALANCE-Switches wurde legitimer und manipulierter Netzverkehr aufgezeichnet und für maschinelles Lernen aufbereitet. Decision Trees erreichten 97 Prozent binäre und 98,6 Prozent Multi-Class-Genauigkeit, XGBoost kam auf 99 beziehungsweise 97,3 Prozent. In der Praxis leisten das ICS-taugliche Systeme wie Claroty, Dragos oder Nozomi, sofern sie den S7comm-Verkehr wirklich sehen und eine Baseline des Normalbetriebs gelernt haben.

Vier Alarmtypen lohnen sich sofort:

• Verbindungen von Rechnern, die keine Engineering-Station sind.
• Sequenzielle IP-Scans auf Port 102.
• Aktivität außerhalb der Wartungsfenster.
• Und ein python-snap7-Import auf einer Workstation, auf der er nichts zu suchen hat.

KI im eigenen Engineering absichern

Um KI im eigenen Engineering abzusichern, sind verschiedene Maßnahmen erforderlich. Nachfolgend ist das anhand des Beispiels Siemens S7 beschrieben:

• Generierten SPS-Code wie fremden Code behandeln: Review durch eine zweite Person, formale Verifikation kritischer Bausteine, keine direkte Übernahme in die Produktion.
• Kontaktplan und Bausteine versionieren und regelmäßig online gegen offline vergleichen. Eine stille Änderung fällt nur auf, wenn ein Sollstand existiert.
• Herkunft der Modelle klären: Wer hat das Modell trainiert, wer kann es nachtrainieren, welche Daten flossen ein. Bei lokal betriebenen Modellen liegt diese Verantwortung im Haus.
• Know-how-Schutz und Neustartschutz im TIA Portal aktivieren und modellspezifische Empfehlungen über Siemens ProductCERT abholen.

Compliance und Vorschriften zum Schutz vor KI-Exploits

NIS2 und das KRITIS-Dachgesetz verpflichten Betreiber zu Risikomanagement und gehärteten OT-Umgebungen. Einen Überblick über Schwellenwerte und Fristen führt OpenKRITIS. Für den Einsatz von KI in Anlagen hat das BSI den Prüfkatalog A5 für vertrauenswürdige KI-Systeme vorgelegt, der die Bewertung an EU AI Act und Cyber Resilience Act anschließt. Ein praktischer Einstieg für die Netzarchitektur ist der BSI-Leitfaden zur sicheren Konnektivität von OT.

Auf Anbieterseite bewegt sich ebenfalls etwas: OpenAI beispielsweise vergibt seine durchlässigeren Cyber-Modelle nur noch über ein Verifikationsprogramm für geprüfte Abwehrspezialisten. Eine solche Zugangsbeschränkung verschiebt die Kosten für Angreifer nach oben, sie beseitigt das Problem allerdings nicht: Frei verfügbare Open Weights-Modelle haben inzwischen in Punkto Leistung zu den kommerziellen Frontier Models aufgeschlossen .

FAQ: häufige Fragen zu KI-Exploits in der Industrie

Sind auch Anlagen in Deutschland betroffen?

Die im Advisory beschriebene Methode funktioniert überall dort, wo eine Anlage aus dem Internet erreichbar ist oder ein schwach abgesicherter Fernzugang existiert. Die betroffenen Baureihen am Beispiel Siemens S7 gehören zu den meistverbauten Steuerungen in europäischen Werken. Die frühere Warnung AA26-097A nannte bereits die S7-1200 unter den beobachteten Zielen.

Reicht es, die Firmware zu aktualisieren?

Nein. Patches schließen bekannte Lücken, die Angreifer kommen im beschriebenen Fall aber über offene Ports, fehlende Passwörter und Standardkonfigurationen herein. Behörden empfehlen deshalb die Kombination aus Netztrennung, Zugriffskontrolle, Härtung und Überwachung. Bei abgekündigten CPUs, für die keine Firmware mehr erscheint, trägt ohnehin nur die Architektur.

Unsere Anlage hängt nicht am Internet, nur der Integrator kommt per Fernwartung rein. Genügt das?

Das Advisory weist ausdrücklich auf diesen Fall hin: Viele Betreiber halten ihre Anlage für isoliert, weil sie die Zugangswege ihres Dienstleisters nicht kennen. Prüfen Sie Mobilfunkrouter, VPN-Endpunkte und Sprungserver des Integrators und verlangen Sie Mehr-Faktor-Anmeldung sowie zeitlich begrenzte Zugänge.

Dürfen wir KI-Assistenten im SPS-Engineering überhaupt noch einsetzen?

Ja, mit Reviewpflicht. Das Risiko liegt in der ungeprüften Übernahme. Behandeln Sie generierten Code wie Code aus einer fremden Quelle: zweites Augenpaar, formale Prüfung kritischer Bausteine, Versionierung und ein regelmäßiger Abgleich zwischen dem, was im Projekt steht, und dem, was auf der Steuerung läuft.

Welche Pflichten ergeben sich aus NIS2?

Betroffene Unternehmen müssen Risiken systematisch bewerten, technische Maßnahmen umsetzen und erhebliche Vorfälle melden. Eine internetexponierte Steuerung ohne Passwortschutz ist in diesem Rahmen ein dokumentierter Mangel im Risikomanagement. Die Geschäftsleitung haftet für die Umsetzung persönlich.