KI-Angriffe auf OT: Was die Laborstudie zeigt und welche Gegenmaßnahmen jetzt sinnvoll sind

Hinweis: Dieser Artikel enthält Affiliate-Links zu Amazon, gekennzeichnet mit „(Werbung)“. Kaufst du darüber, erhalte ich eine kleine Provision, für dich ändert sich am Preis nichts.

Was Booz Allen getestet hat

Booz Allen hat Anfang Oktober 2026 ein Whitepaper veröffentlicht, in dem aktuelle KI-Modelle eine OT-Testumgebung angreifen durften. Das Labor in Chantilly, Virginia, ist vom Produktivbetrieb isoliert und einer allgemeinen Fertigung nachempfunden. Das Netz ist nach dem Purdue-Modell in Unternehmensnetz, industrielle DMZ, Anlagenbetrieb und Produktionszonen gegliedert, getrennt durch Firewalls und Switches. Darin stehen SPS verschiedener Hersteller, HMIs, SCADA, ein Frequenzumrichter und ein Roboterarm, dazu bewusst gemischte Firmwarestände und eine nicht perfekte Segmentierung. Genau diese technische Schuld kenne ich aus vielen gewachsenen Anlagen.

Die Modelle bekamen die Subnetzgrenzen und ein allgemeines Ziel, aber keinen Quellcode, keine Engineering-Unterlagen und keine OT-spezifische Anleitung. Wichtig für die Einordnung: Die Agenten mussten vor jedem Exploit und vor jeder Aktion mit möglicher physischer Wirkung anhalten und auf eine menschliche Freigabe warten.

Die Ergebnisse

• Acht von acht Testzielen erreicht: von der Kartierung der Umgebung über Exploits und SPS-Manipulation bis zur Übernahme von SCADA und zur Bewegung eines Roboterarms.
• Gut 16 Minuten dauerte es in einem Test vom kompromittierten Perimeter bis zu Aktionen im Steuerungsnetz.
• Roboterarm: Ein Agent suchte im Netz nach typischen Roboterprotokollen, fand die API, erlangte Administratorzugriff, las Schutzzonen und Bewegungsgrenzen aus und bewegte den Arm, alles innerhalb von Minuten.
• Anpassung nach Fehlschlag: Beim SCADA-Test zielten die Modelle zuerst auf die falsche Version der Bedienoberfläche, prüften dann aktive Sitzungen, passten ihr Vorgehen an und fanden vorauthentifizierte Verbindungen zu 14 OT-Geräten.

Was die Studie nicht zeigt

Ich halte die Studie für relevant, aber man sollte sie nicht größer machen, als sie ist. Sie zeigt kein autonomes Kraftwerks-Szenario und keinen realen Vorfall. Es war ein Labor mit bekannter Architektur, mit Menschen, die jeden kritischen Schritt freigegeben haben, und Booz Allen nennt die Ergebnisse selbst vorläufig. Die Autoren schreiben auch, dass ein erfahrenes menschliches Team mit genug Zeit und Fachwissen viele der einzelnen Aktionen nachstellen könnte. Neu ist nicht, was möglich ist, sondern wie schnell und mit wie wenig Spezialwissen es zusammengesetzt wird.

Genauso lehrreich ist, was nicht funktioniert hat. Eine Steuerung lehnte einen Stopp-Befehl ab. Ein Motor im Modus Vor-Ort-Bedienung ließ sich nicht aus der Ferne starten. Firewalls, Segmentierung und Endpunktschutz bremsten oder blockierten weitere Aktionen. Allerdings stoppte keine einzelne Maßnahme die Modelle zuverlässig, weil sie auf andere Wege auswichen. Das ist für mich die eigentliche Botschaft: Defense in Depth wirkt, aber nur als Kette mehrerer Hürden.

Die Schwächen sind alt, das Tempo ist neu

Was die Modelle ausgenutzt haben, kennst du aus jedem Audit. Laut Whitepaper waren Standard- und wiederverwendete Passwörter trivial zu umgehen. Die Agenten recherchierten Herstellervorgaben selbst und merkten sich bereits gefundene Passwörter für spätere Schritte. Auf Geräteebene nutzten die meisten Agenten keine Exploits, sondern native Protokolle und Befehle. Und gerade dann wurden sie unauffälliger: In der frühen Erkundung waren sie laut, mit nativen OT-Protokollen und vertrauten Anwendungswegen gingen sie im normalen Betrieb unter.

Dasselbe Muster beschreibt die indische Behörde CERT-In in ihrer als kritisch eingestuften Warnung CIAD-2026-0049 vom 15. Oktober 2026, allerdings für IT-Systeme. KI-Agenten, die von Modellanbietern getestet wurden, überschritten ihren Auftrag und gelangten in Live-Systeme indischer Organisationen. Dort lasen sie Geschäftsunterlagen, über Zugangsdaten in Anwendungskonfigurationen und öffentlichen Code-Repositories sowie zu weit gefasste Cloud-Rollen. Keine der betroffenen Organisationen hat den Zugriff selbst bemerkt, gemeldet haben ihn in allen Fällen die Anbieter. Bei Angreifern, die frei verfügbare KI-Werkzeuge nutzten, schrumpfte die Zeit vom ersten Zugang bis zum Schaden von Tagen auf wenige Stunden. CERT-In betont: Die ausgenutzten Schwächen sind konventionell.

Ein Beispiel aus dem echten Betrieb: Kühlanlagen in Frankreich

Wie teuer exponierte Altgeräte werden können, zeigt ein Fall aus dieser Woche, der nach allem, was bekannt ist, nicht als KI-Angriff belegt ist. Die französische CERT-FR warnte am 12. Oktober vor zahlreichen Kompromittierungen von Fernsteuerungen für Kühlanlagen der Danfoss-Serien AK-SM und AK-SC und ergänzte am 13. Oktober Copeland XWEB und Dixell XWEB. Laut dem französischen Finanzminister waren rund 700 der etwa 10.000 Supermärkte in Frankreich betroffen. Laut Danfoss sind überwiegend ältere Geräte betroffen, die keine Updates mehr erhalten. Daneben traf es einige aktuelle Steuerungen mit veralteter Firmware. Wie die Angreifer hineinkamen, war Mitte der Woche noch offen.

Die Empfehlungen der CERT-FR sind lehrbuchartig: Internetexposition entfernen, die komplette Konfiguration prüfen, insbesondere die Abtauzeiten, Zugriff nur noch über ein sicheres VPN oder ein geschütztes Netz, Firmware aktualisieren, Standardpasswörter ändern. Ein Filter auf Quell-IP-Adressen ist nur als Notlösung gedacht. Und bei kompromittierten Altgeräten reicht ein Werksreset nicht: Bleiben sie exponiert, werden sie mit hoher Wahrscheinlichkeit erneut kompromittiert. Die Brücke zur Laborstudie: Wer heute noch offene Verwaltungsoberflächen hat, hat weniger Zeit als früher, weil das Finden und Ausnutzen schneller wird.

Gegenmaßnahmen, die jetzt Priorität haben

Booz Allen, CERT-In, CERT-FR und die gemeinsame OT-Empfehlung von CISA, FBI, EPA und DOE aus dem Mai 2025 laufen auf dieselben Grundlagen hinaus. Ich ordne sie so, wie ich sie im Werk angehen würde.

1. Segmentierung entlang der Konsequenz

Teile das OT-Netz in Zonen mit kontrollierten Übergängen und große Zonen in kleinere Zellen. Entscheidend ist, wo ein Angriff physische Folgen haben kann. Booz Allen empfiehlt ausdrücklich, Systeme mit zwei Netzwerkanschlüssen in verschiedenen Zonen, gemeinsam genutzte Dienste und vorauthentifizierte Sitzungen über Zonengrenzen hinweg zu inventarisieren und abzubauen. Genau solche versteckten Brücken haben die Agenten im Test sofort als Abkürzung erkannt. Die Adressbereiche für neue Zonen und Zellen rechnest du mit dem OT Subnet Calculator.

2. Fernzugriff absichern

Nichts aus der OT gehört direkt ins Internet. Wenn Fernzugriff nötig ist, empfiehlt CISA ein VPN mit starkem Passwort und phishing-resistenter Mehr-Faktor-Authentifizierung, minimale Rechte je Nutzer und Aufgabe und das Deaktivieren ruhender Konten. Das gilt auch für Zugänge von Dienstleistern. Ein VPN ist aber kein Allheilmittel: Forscher der University of British Columbia haben mit ICS-Sniper gezeigt, dass ein Angreifer auf dem Übertragungsweg allein aus Größe, Richtung und Timing verschlüsselter VPN-Pakete kritische Zeitfenster zu einem Cloud-SCADA erkennen und gezielt Pakete verwerfen kann. In einer emulierten Wasseraufbereitungs-Testanlage verzögerte das den Pumpenstart um etwa 15 Minuten. Ein Proof of Concept ohne KI, aber ein Argument, Abhängigkeiten von Internetstrecken bewusst zu bewerten.

Phishing-resistente MFA setzt du zum Beispiel mit FIDO2-Sicherheitsschlüsseln wie dem YubiKey 5 NFC FIPS (Werbung) (USB-A) oder dem YubiKey 5C NFC FIPS (Werbung) (USB-C) um, sofern dein VPN- oder Fernzugriffssystem das unterstützt.

3. Secrets-Hygiene

Standardpasswörter ändern, keine wiederverwendeten Passwörter, eigene privilegierte Konten statt geteilter Logins, Servicekonten schützen. CERT-In empfiehlt zusätzlich, Quellcode, Repositories inklusive Commit-Historie, Konfigurationsdateien und Cloud-Speicher nach offenliegenden Zugangsdaten zu durchsuchen, gefundene Zugangsdaten zu rotieren und aus der Historie zu entfernen. In OT-Projekten denke ich dabei an Projektdateien, Skripte und Übergabedokumente mit Klartext-Passwörtern.

4. Monitoring auf Prozessebene

Signaturen allein reichen nicht, wenn ein Angreifer sich mit nativen Protokollen bewegt. Booz Allen empfiehlt, Moduswechsel von Steuerungen, Force-Operationen, Programm- und Konfigurationsschreibvorgänge, SCADA-Projektimporte, neue Verbindungen zwischen Zonen und ungewöhnliche Nutzung legitimer Schnittstellen zu überwachen. Dazu gehört eine Basislinie: Wer darf von wo und in welchem Betriebszustand Steuerbefehle senden? Das BSI hat dazu eine Empfehlung zu Monitoring und Anomalieerkennung in Produktionsnetzen veröffentlicht.

5. End-of-Life-Geräte isolieren und ersetzen

Geräte ohne Updates lassen sich nicht patchen, also musst du ihre Erreichbarkeit begrenzen. Booz Allen empfiehlt, Schwachstellen nicht nur nach Schweregrad zu bewerten, sondern danach, ob ein System erreichbar ist und welche Folgen eine Kompromittierung hätte. Wo Patchen nicht geht, helfen geprüfte kompensierende Maßnahmen. Parallel gehört der Ersatz ins Budget.

6. Wiederherstellung und lokale Sicherheit

Halte getestete Backups von Steuerungsprogrammen, Konfigurationen, Rezepturen, HMI-Projekten und Netzwerkgeräten bereit und übe die Wiederherstellung. CISA rät zusätzlich, den manuellen Betrieb der Anlage zu üben. Lokale Schutzfunktionen wie der Vor-Ort-Modus wirkten im Labor auch dann noch, als der Angreifer schon im Netz war.

Was du jetzt tun solltest

1. Exposition prüfen: Suche nach OT-Geräten und Verwaltungsoberflächen, die aus dem Internet erreichbar sind, und nimm sie vom Netz.
2. Brücken finden: Liste Systeme mit Verbindungen in mehrere Zonen, Jump-Hosts und dauerhaft angemeldete Sitzungen auf und baue ab, was nicht nötig ist.
3. Passwörter aufräumen: Standard- und geteilte Passwörter ersetzen, Fernzugänge mit Mehr-Faktor-Authentifizierung absichern, ruhende Konten deaktivieren.
4. Altgeräte kennzeichnen: End-of-Life-Geräte inventarisieren, eng abschotten und den Ersatz einplanen.
5. Kritische Änderungen sichtbar machen: Mindestens Programm-Downloads, Moduswechsel und neue Verbindungen zwischen Zonen protokollieren und auswerten.
6. Wiederherstellung üben: Backups prüfen, bekannte gute Stände ablegen, den manuellen Betrieb proben.

Nichts davon ist neu. Neu ist, dass ein Angreifer mit KI-Unterstützung weniger Zeit braucht. Für mich kein Grund zur Panik, sondern ein Argument, Bekanntes nicht weiter aufzuschieben.

Häufige Fragen zu KI-Angriffen auf OT

Quellen

• Booz Allen: Super Intelligence Reached OT Systems and Moved Equipment
• Booz Allen: From Digital to Physical – Frontier AI Models in OT Environments (Whitepaper, PDF, 6. Oktober 2026)
• SecurityWeek: AI Agents Navigate Unfamiliar OT Systems and Move Equipment in Minutes, Booz Allen Finds
• CERT-FR: CERTFR-2026-ALE-012 – Incident de sécurité ciblant les contrôleurs à distance des installations de réfrigération
• SecurityWeek: Supermarket Refrigeration Attack Widens to Copeland, Dixell Controllers
• CERT-In: Advisory CIAD-2026-0049 – AI Agents as Attack Vectors
• The Indian Express (Reuters): Rogue AI agents accessed confidential Indian business records, CERT-In says
• Mitra et al. (University of British Columbia): ICS-Sniper – A Targeted Blackhole Attack on Encrypted ICS Traffic
• SecurityWeek: In Other News – ICS-Sniper Attack, Hacking XWorm Malware Operators, $250k Chrome Exploit
• CISA, FBI, EPA, DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• BSI: Empfehlungen für Betreiber von ICS (Top 10 Bedrohungen, Monitoring, Fernwartung)

Stand: 18. Oktober 2026.

Werbung/Affiliate-Links: Wenn du über diesen Link kaufst, erhalte ich eine kleine Provision, für dich ändert sich am Preis nichts. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.