Sicherheitsrisiken durch KI digitale Infrastrukturen und vernetzte Systeme

Eine Sicherheitsfolge mit ungewöhnlich breitem Blickwinkel

Die 66. Ausgabe des Podcasts „Passwort“ von heise security widmet sich einer Reihe von Sicherheitsvorfällen und Forschungsergebnissen, die auf den ersten Blick nur wenig miteinander zu tun haben. Die Themen reichen von manipulierten CAPTCHA-Seiten über die Absicherung globaler Routing-Informationen bis hin zu Schwachstellen in KI-Programmierwerkzeugen und humanoiden Robotern.

Gemeinsam ist den Fällen jedoch ein grundlegendes Muster: Angreifer nutzen nicht nur einzelne technische Fehler aus. Sie greifen zunehmend auf Vertrauensbeziehungen, automatisierte Prozesse und zentrale Infrastrukturen zurück. Dadurch kann ein Vorfall deutlich größere Auswirkungen entfalten als ein klassischer Angriff auf ein einzelnes Benutzerkonto.

Für Unternehmen ist diese Entwicklung besonders relevant. In modernen IT-Umgebungen sind zahlreiche Systeme miteinander verbunden. Ein kompromittiertes Administrationswerkzeug kann deshalb Auswirkungen auf viele Kundensysteme haben. Eine manipulierte Routing-Information kann den Datenverkehr umleiten. Ein KI-Assistent kann schädliche Inhalte in einen Entwicklungsprozess einbringen. Und ein vernetzter Roboter kann unter bestimmten Bedingungen selbst zu einem Angriffspunkt innerhalb einer Geräteflotte werden.

Die Podcast-Folge ordnet diese Entwicklungen aus der Perspektive der technischen IT-Sicherheit ein. Für Verantwortliche in Unternehmen liefert sie damit vor allem einen Anlass, Sicherheitsmodelle nicht auf klassische Endgerätesicherheit und Zugangsschutz zu begrenzen.

ClickFix: Wenn der Nutzer den Angriff selbst ausführt

Das Grundprinzip manipulierten Vertrauens

Bei ClickFix handelt es sich um eine Angriffsmethode, die Elemente von Social Engineering, gefälschten Webseiten und lokalen Systembefehlen miteinander verbindet. Typischerweise wird dem Opfer eine scheinbar technische Störung angezeigt. Denkbar sind beispielsweise ein angeblich fehlerhaftes CAPTCHA, eine blockierte Browserfunktion oder eine Meldung, wonach eine bestimmte Tastenkombination beziehungsweise ein Systemschritt erforderlich sei.

Die Besonderheit besteht darin, dass die betroffene Person nicht lediglich auf einen schädlichen Link klickt. Sie wird dazu gebracht, selbst eine Aktion auszuführen, die von der Angriffsseite vorgegeben wird. Das kann etwa das Kopieren und Einfügen eines Befehls in ein Terminal oder eine andere Systemkomponente sein.

Aus Sicht der Angreifer ist dieses Vorgehen attraktiv, weil klassische technische Schutzmechanismen teilweise umgangen werden können. Ein Sicherheitsprodukt erkennt möglicherweise keinen schädlichen Download, wenn die Schadsoftware erst durch eine vom Nutzer ausgeführte Handlung nachgeladen wird. Auch der Browser muss nicht zwingend eine bekannte Malware-Datei blockieren, wenn der eigentliche Angriff über eine legitime Systemfunktion angestoßen wird.

Warum die Methode wirksam ist

ClickFix nutzt eine Schwäche aus, die in vielen Unternehmen unterschätzt wird: Nutzer interpretieren technische Anweisungen häufig als vertrauenswürdig, wenn sie in einer plausibel gestalteten Umgebung erscheinen. Ein nachgebildetes CAPTCHA, ein gefälschtes Supportfenster oder eine angebliche Fehlermeldung kann den Eindruck erwecken, dass die empfohlene Handlung vom Browser, vom Betriebssystem oder von einem bekannten Dienst stammt.

Hinzu kommt der Zeitdruck. Wenn eine Webseite behauptet, ein Sicherheitscheck müsse sofort abgeschlossen werden, eine Sitzung laufe ab oder ein Zugriff werde andernfalls verweigert, sinkt die Bereitschaft, die Anweisung kritisch zu prüfen. Genau diese Kombination aus Vertrautheit, Dringlichkeit und technischer Sprache bildet den Kern des Social-Engineering-Ansatzes.

Für die Bewertung eines Vorfalls ist deshalb nicht allein entscheidend, welche Schadsoftware eingesetzt wurde. Ebenso wichtig ist die Frage, wie das Opfer zu der Handlung bewegt wurde und warum bestehende Sicherheitskontrollen diese Handlung zugelassen haben.

ClickFix und TerminalFix im Unternehmensumfeld

Die in der Podcast-Folge angesprochenen Varianten werden teilweise als ClickFix oder TerminalFix bezeichnet. Die Begriffe beschreiben unterschiedliche Ausprägungen desselben übergeordneten Prinzips: Eine manipulierte Interaktion soll die betroffene Person dazu bringen, Anweisungen auszuführen, die sie normalerweise nicht selbst formuliert hätte.

Besonders kritisch ist dieses Vorgehen in Unternehmen mit einer großen Zahl privilegierter Nutzer, Entwicklerarbeitsplätzen oder technisch versierten Beschäftigten. Ein Terminalbefehl kann für Administratoren und Entwickler ein alltägliches Werkzeug sein. Gerade deshalb wirkt die Aufforderung zum Einfügen eines Befehls unter Umständen weniger verdächtig als eine klassische ausführbare Datei.

Unternehmen sollten daher nicht nur vor unbekannten Dateien und Phishing-Links warnen. Sicherheitsrichtlinien müssen auch den Umgang mit kopierten Befehlen, Browseraufforderungen und angeblichen Reparaturanweisungen abdecken.

Praktisch relevant sind unter anderem folgende Maßnahmen:

• Administratoren und Beschäftigte sollten keine Befehle aus unbekannten Webseiten in Terminals oder andere Systemwerkzeuge einfügen.
• Browser- und Betriebssystemmeldungen sollten nicht allein aufgrund ihrer Gestaltung als vertrauenswürdig gelten.
• Privilegierte Tätigkeiten sollten möglichst von gesonderten Administrationssystemen aus erfolgen.
• Endpoint-Security-Lösungen sollten verdächtige Prozessketten überwachen, insbesondere Browser-zu-Terminal- oder Browser-zu-Skriptausführungen.
• Unternehmen sollten Awareness-Trainings mit realistischen Beispielen für gefälschte CAPTCHA- und Support-Szenarien ergänzen.

Der Berlin-Hack und die Bedeutung von Social Engineering

Im Zusammenhang mit einem Angriff auf Netze Berliner Senatsverwaltungen wird in der Folge auch die Vorgehensweise der Angreifer thematisiert. Die verfügbaren Informationen verweisen dabei auf Social Engineering und auf die missbräuchliche Nutzung von Steganografie. Unter Steganografie versteht man das Verbergen von Informationen innerhalb scheinbar unverdächtiger Dateien oder Inhalte.

Die technische Raffinesse eines solchen Angriffs liegt nicht zwangsläufig in einem besonders komplexen Schadprogramm. Entscheidend kann vielmehr die Kombination verschiedener Täuschungselemente sein. Eine Nachricht kann beispielsweise glaubwürdig erscheinen, weil sie sich auf einen aktuellen Vorgang bezieht, von einem bekannten Kommunikationskanal stammt oder ein Dokument enthält, das äußerlich zu einem erwarteten Arbeitsprozess passt.

Für öffentliche Einrichtungen und Unternehmen mit zahlreichen externen Kontakten ist diese Entwicklung von hoher Bedeutung. Angreifer müssen nicht immer direkt in besonders geschützte Netze eindringen. Sie können versuchen, einzelne Personen, Dienstleister oder Kommunikationsprozesse zu kompromittieren und sich anschließend schrittweise weiterzubewegen.

Eine belastbare Abwehr setzt deshalb mehrere Ebenen voraus. Dazu gehören die Prüfung von Absendern und Anhängen, die Trennung von Benutzer- und Administrationsrechten, eine zentrale Protokollierung sowie Verfahren zur Erkennung ungewöhnlicher Aktivitäten. Auch die Krisenkommunikation spielt eine Rolle: Je schneller ein verdächtiger Kontakt gemeldet und bewertet wird, desto eher lässt sich eine Ausbreitung verhindern.

RPKI und BGP: Sicherheitsfragen im Fundament des Internets

Welche Aufgabe BGP erfüllt

Das Border Gateway Protocol, kurz BGP, steuert den Austausch von Routing-Informationen zwischen autonomen Systemen im Internet. Dabei handelt es sich beispielsweise um Netze von Internetprovidern, großen Unternehmen, Rechenzentren oder Content-Anbietern. BGP teilt den beteiligten Netzen mit, über welche Wege bestimmte IP-Adressbereiche erreichbar sind.

Das Protokoll wurde in einer Zeit entwickelt, in der das Internet wesentlich kleiner war und Vertrauen zwischen den beteiligten Organisationen eine größere Rolle spielte. Die ursprüngliche Architektur sieht nur begrenzte Möglichkeiten vor, zu überprüfen, ob eine Route tatsächlich von der Organisation angekündigt wird, die dazu berechtigt ist.

Fehlerhafte oder absichtlich manipulierte Routen können zu verschiedenen Problemen führen. Datenverkehr kann umgeleitet, blockiert oder über eine unerwünschte Infrastruktur geführt werden. In bestimmten Szenarien kann ein Angreifer dadurch auch versuchen, Inhalte abzufangen oder Nutzer auf manipulierte Dienste zu lenken.

RPKI als technischer Schutzmechanismus

Die Resource Public Key Infrastructure soll eine zusätzliche Vertrauensebene für BGP schaffen. Netzbetreiber können kryptografisch signierte Informationen hinterlegen, die festlegen, welche autonomen Systeme bestimmte IP-Adressbereiche ankündigen dürfen. Diese Angaben werden als Route Origin Authorizations bezeichnet.

Router und Netzwerkbetreiber können eingehende Routen anhand dieser Informationen bewerten. Eine Route kann als gültig, ungültig oder nicht überprüfbar eingestuft werden. Dadurch lässt sich zumindest ein Teil der Manipulationen erkennen, die auf eine falsche Herkunft einer Route abzielen.

RPKI ist jedoch kein vollständiger Schutz für sämtliche BGP-Probleme. Das Verfahren konzentriert sich vor allem auf die Frage, ob ein bestimmtes autonomes System berechtigt ist, einen Adressbereich anzukündigen. Andere Aspekte der Routing-Sicherheit, etwa die vollständige Pfadvalidierung oder die korrekte Konfiguration der beteiligten Systeme, bleiben davon unberührt.

Warum technische Schutzmechanismen nicht automatisch genügen

Die Folge thematisiert einen Fall, in dem Angreifer Sicherheitsmechanismen im Umfeld von Routing und RPKI überwinden konnten, um einen Anbieter von Serververwaltungssoftware zu kompromittieren. Der Vorgang verdeutlicht, dass kryptografische Verfahren und Validierungsinfrastrukturen nur so zuverlässig sind wie ihre Implementierung, Konfiguration und betriebliche Einbettung.

In komplexen Vertrauensketten kann ein Angriff an mehreren Stellen ansetzen. Dazu gehören etwa kompromittierte Zugangsdaten, fehlerhafte Berechtigungen, manipulierte Systeme eines Dienstleisters oder Schwachstellen in der Verwaltung signierter Informationen. Auch eine korrekte technische Prüfung schützt nicht vor jedem Szenario, wenn vorgelagerte Prozesse bereits kompromittiert wurden.

Für Unternehmen, die auf externe Cloud-, Hosting- oder Netzwerkdienstleister angewiesen sind, entsteht daraus eine wichtige Konsequenz: Die Sicherheitsbewertung darf nicht bei der eigenen Firewall enden. Entscheidend ist auch, welche Anbieter zentrale Verwaltungsfunktionen übernehmen, wie deren Zugänge geschützt werden und ob sicherheitsrelevante Änderungen nachvollziehbar protokolliert sind.

Zu den relevanten Prüfungsfragen zählen:

• Welche externen Anbieter können Routing, DNS, Server oder zentrale Administrationssysteme beeinflussen?
• Wie werden Änderungen an RPKI-Objekten, Netzwerkankündigungen und privilegierten Konten freigegeben?
• Gibt es unabhängige Kontrollmechanismen für besonders kritische Konfigurationsänderungen?
• Wie schnell würde das Unternehmen eine fehlerhafte oder manipulierte Route erkennen?
• Welche Notfallwege bestehen, wenn ein zentraler Dienstleister nicht mehr vertrauenswürdig oder erreichbar ist?

Der Angriff auf Serververwaltungssoftware als Lieferkettenrisiko

Serververwaltungssoftware nimmt in vielen IT-Umgebungen eine besonders privilegierte Position ein. Sie kann zur Einrichtung von Systemen, zur Verwaltung von Webseiten, zur Konfiguration von Datenbanken, zur Steuerung von Benutzerkonten oder zur automatisierten Ausführung administrativer Aufgaben eingesetzt werden.

Wird ein Anbieter solcher Software kompromittiert, unterscheidet sich das Risiko deutlich von einem Angriff auf einen einzelnen Server. Die Angreifer erhalten möglicherweise Zugriff auf eine Plattform, die von zahlreichen Kunden verwendet wird. Dadurch kann eine Kompromittierung potenziell skaliert werden.

Ein solches Szenario ist ein Beispiel für ein Lieferkettenrisiko. Unternehmen vertrauen nicht nur ihren direkten Lieferanten, sondern auch deren Entwicklungs-, Update- und Administrationsprozessen. Ein Sicherheitsvorfall beim Anbieter kann deshalb Auswirkungen auf Kunden haben, selbst wenn deren eigene Systeme zum Zeitpunkt des Angriffs aktuell gepatcht und korrekt konfiguriert waren.

Welche Kontrollmechanismen Unternehmen benötigen

Die Absicherung zentraler Verwaltungssoftware erfordert eine Kombination aus technischen und organisatorischen Maßnahmen. Dazu gehören eine strenge Segmentierung, eine Begrenzung der Berechtigungen und eine unabhängige Überwachung administrativer Aktionen.

Updates und Erweiterungen sollten nicht ungeprüft in produktive Umgebungen übernommen werden. Je nach Kritikalität können gestufte Rollouts, Testsysteme und Integritätsprüfungen sinnvoll sein. Auch die Frage, ob ein Anbieter Softwarepakete reproduzierbar baut und kryptografisch signiert, gewinnt an Bedeutung.

Ein Unternehmen sollte außerdem wissen, welche Systeme von einer bestimmten Administrationsplattform abhängig sind. Nur wenn diese Abhängigkeiten dokumentiert sind, lässt sich im Krisenfall schnell entscheiden, welche Zugänge gesperrt, welche Systeme isoliert und welche Wiederherstellungsmaßnahmen eingeleitet werden müssen.

Für die Praxis bietet sich eine Bewertung in mehreren Bereichen an:

• Identifikation aller zentralen Verwaltungs- und Orchestrierungswerkzeuge
• Dokumentation ihrer Berechtigungen und technischen Abhängigkeiten
• Multi-Faktor-Authentifizierung für Anbieter- und Administrationszugänge
• Netzwerksegmentierung zwischen Management-, Produktions- und Backup-Systemen
• Überwachung ungewöhnlicher Änderungen an Konfigurationen, Skripten und Softwarepaketen
• Regelmäßige Notfallübungen für den Ausfall oder die Kompromittierung eines Dienstleisters

Claude Code und die Angriffsfläche von KI-Programmierassistenten

Wenn KI-Agenten mit Dateien und Befehlen arbeiten

KI-gestützte Programmierassistenten können Quellcode analysieren, Dateien verändern, Abhängigkeiten bewerten und in bestimmten Konfigurationen auch Befehle ausführen. Diese Funktionen erhöhen den praktischen Nutzen, erweitern aber gleichzeitig die Angriffsfläche.

Ein Assistent, der ausschließlich Textvorschläge liefert, hat andere Risiken als ein agentisches System, das auf ein Projektverzeichnis zugreift, externe Inhalte verarbeitet oder Aktionen in einer Entwicklungsumgebung ausführt. Je mehr Handlungsmöglichkeiten ein Modell besitzt, desto wichtiger werden technische Grenzen und eine klare Trennung zwischen Analyse und Ausführung.

In der Podcast-Folge wird beschrieben, dass sich Claude Code durch geschickt platzierte Malware beziehungsweise manipulierte Inhalte überlisten lässt. Der Kern des Problems liegt dabei nicht zwingend in einer klassischen Schwachstelle des Modells. Vielmehr kann ein Angreifer versuchen, die Verarbeitungskette zu beeinflussen. Schädliche Anweisungen können beispielsweise in Dateien, Kommentaren, Dokumentationen oder Abhängigkeiten verborgen werden, die der Assistent im Rahmen seiner Aufgabe untersucht.

Prompt-Injection als Sicherheitsproblem im Entwicklungsprozess

Solche Angriffe werden häufig unter dem Begriff Prompt Injection zusammengefasst. Dabei enthalten externe Inhalte Anweisungen, die ein KI-System dazu bringen sollen, seine ursprüngliche Aufgabe zu verlassen oder unerwünschte Aktionen auszuführen.

Die Herausforderung besteht darin, dass ein Sprachmodell zwischen vertrauenswürdigen Anweisungen und unzuverlässigen Daten nicht automatisch so unterscheidet wie ein klassisches Zugriffskontrollsystem. Für das Modell können beide als Text erscheinen. Eine Datei im Projektverzeichnis kann somit nicht nur Quellcode enthalten, sondern auch eine manipulierte Aufforderung an den Assistenten.

Besonders kritisch wird dies, wenn der KI-Agent über weitreichende Rechte verfügt. Dazu zählen etwa der Zugriff auf Umgebungsvariablen, private Schlüssel, interne Repositories, Produktionssysteme oder lokale Shell-Befehle. Ein manipuliertes Dokument könnte dann versuchen, den Assistenten zur Preisgabe von Geheimnissen oder zur Ausführung schädlicher Aktionen zu bewegen.

Schutzmaßnahmen für Unternehmen und Entwicklungsteams

Der Einsatz von KI-Programmierassistenten sollte daher nach dem Prinzip der geringstmöglichen Rechte erfolgen. Ein Assistent benötigt nicht automatisch Zugriff auf alle Dateien und Systeme, nur weil er in einem Entwicklungsprojekt eingesetzt wird.

• KI-Agenten sollten in isolierten Entwicklungsumgebungen oder Containern ausgeführt werden.
• Zugriffe auf Geheimnisse, Produktionssysteme und private Schlüssel sollten standardmäßig untersagt sein.
• Jede externe Datei sollte als potenziell nicht vertrauenswürdig gelten, auch wenn sie aus einem bekannten Repository stammt.
• Aktionen mit Nebenwirkungen, insbesondere Installationen, Netzwerkzugriffe und Änderungen an sicherheitsrelevanten Dateien, sollten eine menschliche Freigabe erfordern.
• Ausgaben und ausgeführte Befehle des Assistenten sollten revisionssicher protokolliert werden.
• Entwicklungsteams sollten KI-generierten Code weiterhin durch Tests, Code-Reviews und Sicherheitsanalysen prüfen.

Für die Governance ist zudem eine klare Zuständigkeit erforderlich. Unternehmen sollten festlegen, welche KI-Werkzeuge zugelassen sind, welche Daten verarbeitet werden dürfen und wie mit Vorfällen umzugehen ist. Das gilt insbesondere für Organisationen, die KI über zentrale Plattformen in mehrere Entwicklungs- oder Fachbereiche integrieren.

Vernetzte humanoide Roboter als neue Sicherheitsdomäne

Von der Software-Schwachstelle zum physischen Risiko

Ein weiterer Themenblock der Folge befasst sich mit Sicherheitsproblemen in humanoiden Robotern des Herstellers Unitree. Die Geräte können sich selbstständig bewegen, sind mit Sensorik und Steuerungssystemen ausgestattet und lassen sich je nach Modell oder Konfiguration auch aus der Ferne kontrollieren.

Eine Schwachstelle in einem solchen System ist nicht nur unter dem Gesichtspunkt des Datenschutzes oder der Verfügbarkeit relevant. Wenn ein Angreifer die Kontrolle über Bewegungsfunktionen, Kommunikationsschnittstellen oder administrative Komponenten übernimmt, kann daraus ein physisches Sicherheitsrisiko entstehen.

Besonders aufmerksamkeitsstark ist die Möglichkeit, dass ein kompromittierter Roboter weitere Geräte erreichen oder beeinflussen könnte. In Analogie zu einem Computerwurm wäre ein Szenario denkbar, in dem sich ein Angriff innerhalb eines gemeinsam betriebenen Netzwerks ausbreitet. Ob und unter welchen Bedingungen eine solche Ausbreitung praktisch möglich ist, hängt von der konkreten Architektur, den verwendeten Protokollen und den vorhandenen Authentifizierungsmechanismen ab.

Warum Roboterflotten anders abgesichert werden müssen

Roboter werden zunehmend in Forschung, Ausbildung, Logistik, Produktion und Demonstrationsumgebungen eingesetzt. Dabei entstehen neue Anforderungen an die IT-Sicherheit. Ein klassischer Server lässt sich bei einem Verdacht vergleichsweise einfach vom Netzwerk trennen. Bei einem beweglichen Gerät muss zusätzlich berücksichtigt werden, ob es gerade in einer Umgebung mit Menschen, Maschinen oder sensiblen Materialien eingesetzt wird.

Eine umfassende Sicherheitsstrategie für Roboterflotten sollte deshalb mindestens folgende Bereiche abdecken:

• Starke Authentifizierung für lokale und entfernte Steuerungsverbindungen
• Strikte Trennung von Betriebs-, Wartungs- und Verwaltungsnetzwerken
• Regelmäßige Aktualisierung der Firmware und der Steuerungssoftware
• Individuelle Geräteidentitäten anstelle gemeinsamer Standardzugänge
• Überwachung ungewöhnlicher Bewegungs-, Netzwerk- und Administrationsmuster
• Sichere Notabschaltung bei Anzeichen einer Kompromittierung
• Dokumentierte Wiederherstellungsprozesse nach einem Sicherheitsvorfall

Aus Unternehmenssicht ist auch die Beschaffung relevant. Sicherheitsanforderungen sollten bereits in Ausschreibungen und Lieferverträge aufgenommen werden. Dazu gehören Angaben zur Update-Versorgung, zur Dauer des Sicherheits-Supports, zur Meldung von Schwachstellen und zur Verantwortlichkeit bei Vorfällen.

Was die Themen miteinander verbindet

ClickFix, RPKI-Angriffe, kompromittierte Verwaltungssoftware, manipulierte KI-Assistenten und verwundbare Roboter wirken wie getrennte Sicherheitsfelder. Bei genauerer Betrachtung zeigen sie jedoch mehrere gemeinsame Risikofaktoren.

Vertrauen wird zum Angriffsziel

Beim ClickFix-Angriff wird das Vertrauen in eine Benutzeroberfläche ausgenutzt. Bei RPKI und BGP geht es um das Vertrauen in kryptografisch abgesicherte Routing-Informationen. Bei Serververwaltungssoftware vertrauen Kunden auf den Anbieter und dessen Update-Prozess. Bei KI-Assistenten müssen Systeme zwischen Anweisungen und Daten unterscheiden. In Robotern basiert die Kommunikation häufig auf der Annahme, dass angeschlossene Geräte und Steuerungskomponenten legitim sind.

In allen Fällen reicht es nicht aus, einzelne technische Komponenten isoliert zu betrachten. Sicherheitsverantwortliche müssen die Vertrauensannahmen einer gesamten Prozesskette analysieren. Dazu gehört die Frage, wer Informationen liefert, wer sie prüft, wer daraus Aktionen ableitet und welche Rechte dabei zur Verfügung stehen.

Automatisierung vergrößert Wirkung und Geschwindigkeit

Automatisierte Systeme können Abläufe beschleunigen und Betriebskosten senken. Gleichzeitig können sie einen Fehler oder einen Angriff schneller und großflächiger verbreiten. Ein manipuliertes Softwarepaket kann an viele Kunden verteilt werden. Eine fehlerhafte Routing-Information kann zahlreiche Netze betreffen. Ein KI-Agent kann schädliche Inhalte in mehrere Dateien übertragen. Eine zentral verwaltete Roboterflotte kann ein einheitliches Fehlverhalten zeigen.

Die zentrale Frage lautet daher nicht, ob Automatisierung grundsätzlich sicher oder unsicher ist. Entscheidend ist, an welchen Stellen sie kontrolliert, begrenzt und überwacht wird. Unternehmen benötigen technische und organisatorische Stopppunkte, an denen ungewöhnliche Vorgänge erkannt und vor einer weiteren Ausbreitung angehalten werden können.

Die Trennung zwischen digitaler und physischer Sicherheit verschwindet

Die Beispiele aus der Folge zeigen außerdem, dass Cybersecurity nicht mehr ausschließlich eine Frage von Daten, Konten und Netzwerken ist. Wenn KI-Agenten Entwicklungsprozesse steuern oder Roboter Bewegungen ausführen, können digitale Manipulationen direkte Auswirkungen auf reale Abläufe haben.

Für Unternehmen bedeutet das, dass IT-Sicherheit, Informationssicherheit, Datenschutz, Betriebssicherheit und gegebenenfalls Arbeitsschutz stärker zusammenarbeiten müssen. Zuständigkeiten, die früher getrennt waren, überschneiden sich zunehmend.

Einordnung für den Einsatz von KI in Unternehmen

Für Unternehmen, die KI-Anwendungen einsetzen oder in ihre Prozesse integrieren, ist insbesondere der Abschnitt zu KI-Programmierassistenten relevant. Die Risiken beschränken sich nicht auf fehlerhafte Antworten oder sogenannte Halluzinationen. Ein KI-System kann auch zum Bestandteil einer Angriffskette werden, wenn es externe Inhalte verarbeitet und gleichzeitig über operative Rechte verfügt.

Eine belastbare KI-Sicherheitsstrategie sollte deshalb mehrere Fragen beantworten:

• Welche Daten darf das System lesen und verarbeiten?
• Welche Aktionen darf es selbstständig ausführen?
• Welche Inhalte gelten als vertrauenswürdige Anweisungen und welche ausschließlich als Daten?
• Wie werden externe Dokumente, Webseiten, Repository-Dateien und Abhängigkeiten geprüft?
• Welche Protokolle ermöglichen eine nachträgliche Untersuchung?
• Wie kann ein Unternehmen einen KI-Agenten kurzfristig deaktivieren?

Für Content-, Recherche- und Produktivitätssysteme gilt ein vergleichbares Prinzip. Auch wenn ein System keine Shell-Befehle ausführt, können manipulierte Inhalte die Ergebnisse beeinflussen, vertrauliche Informationen in Prompts einschleusen oder Nutzer zu riskanten Folgeaktionen bewegen. Anbieter und Anwender sollten deshalb Datenquellen, Rollen und Freigabestufen transparent definieren.

Bei Plattformen, die KI mit Text, Bildern, Recherche und weiteren Funktionen verbinden, gewinnt die Trennung von Datenzugriffen besondere Bedeutung. Ein Modell sollte nur auf die Informationen zugreifen, die für die konkrete Aufgabe erforderlich sind. Gleichzeitig müssen Nutzer erkennen können, aus welchen Quellen ein Ergebnis stammt und ob Inhalte automatisch verarbeitet oder von Menschen geprüft wurden.

Konkrete Prioritäten für IT- und Sicherheitsverantwortliche

Die in der Folge angesprochenen Themen lassen sich in einen praxisorientierten Prüfplan übersetzen. Unternehmen müssen nicht alle Maßnahmen gleichzeitig umsetzen. Eine Priorisierung nach möglicher Schadenswirkung und vorhandener Abhängigkeit kann jedoch helfen, schnell belastbare Verbesserungen zu erreichen.

Erste Priorität: privilegierte Zugänge und zentrale Werkzeuge

Am Anfang sollte eine Bestandsaufnahme aller Systeme stehen, die weitreichende administrative Rechte besitzen. Dazu zählen Serververwaltungsplattformen, Cloud-Konsolen, Identitätsdienste, Softwareverteilung, CI/CD-Systeme und zentrale Netzwerkkomponenten.

Für jeden dieser Dienste sollte dokumentiert sein, welche Personen, Dienstleister und technischen Konten Zugriff haben. Nicht mehr benötigte Berechtigungen sollten entfernt werden. Für besonders kritische Vorgänge sind eine zusätzliche Freigabe und eine nachvollziehbare Protokollierung sinnvoll.

Zweite Priorität: Erkennung von Social Engineering

Awareness-Maßnahmen sollten über traditionelle Phishing-Beispiele hinausgehen. Beschäftigte müssen wissen, dass auch eine scheinbare Sicherheitsprüfung oder eine Supportanweisung manipuliert sein kann. Besonders wichtig ist eine klare Regel: Kein Nutzer sollte auf einer unbekannten Webseite aufgefordert werden, Befehle in ein Terminal oder ein anderes privilegiertes Systemwerkzeug einzufügen.

Darüber hinaus sollten Meldewege einfach und bekannt sein. Wenn eine verdächtige Handlung ohne Angst vor Sanktionen gemeldet werden kann, steigt die Wahrscheinlichkeit, dass ein Angriff frühzeitig entdeckt wird.

Dritte Priorität: Lieferketten und Updates

Unternehmen sollten ihre wichtigsten Anbieter nach dem möglichen Einfluss auf die eigene Infrastruktur bewerten. Die Frage lautet nicht nur, ob ein Dienstleister personenbezogene Daten verarbeitet. Ebenso relevant ist, ob er Software verteilt, Systeme administriert, Netzwerkdienste bereitstellt oder Zugang zu Produktionsumgebungen besitzt.

Verträge und Sicherheitsvereinbarungen sollten Anforderungen an Schwachstellenmeldungen, Update-Signaturen, Protokollierung, Notfallkommunikation und die Unterstützung bei forensischen Untersuchungen enthalten. Für besonders kritische Anbieter sind regelmäßige Sicherheitsnachweise und technische Prüfungen angebracht.

Vierte Priorität: KI-Governance und Agentenrechte

Vor der Einführung eines KI-Agenten sollte geklärt werden, welche Aufgaben automatisiert werden dürfen und welche ausdrücklich menschlicher Freigabe bedürfen. Die Rechte des Systems sollten auf das notwendige Minimum beschränkt sein. Für Entwicklungsumgebungen empfiehlt sich eine isolierte Ausführung ohne direkten Zugriff auf produktive Geheimnisse.

Auch die Qualitätssicherung muss angepasst werden. Code, Konfigurationen und Dokumente, die durch KI bearbeitet wurden, sollten denselben Sicherheitsprüfungen unterliegen wie menschlich erstellte Inhalte. Eine KI-Ausgabe darf nicht allein deshalb als vertrauenswürdig gelten, weil sie plausibel formuliert oder technisch detailliert ist.

Grenzen der verfügbaren Informationen

Die Folge ist ein journalistisches und analytisches Format, das mehrere Sicherheitsmeldungen zusammenführt. Die öffentlich verfügbaren Kurzbeschreibungen liefern einen Überblick über die Themen, enthalten jedoch nicht zu jedem angesprochenen Fall technische Detaildaten. Dazu zählen beispielsweise vollständige Angriffsketten, konkrete betroffene Versionen, Indikatoren zur Kompromittierung oder der genaue Umfang möglicher Auswirkungen.

Unternehmen sollten aus allgemeinen Berichten daher keine unmittelbaren Rückschlüsse auf die eigene Betroffenheit ziehen. Stattdessen ist eine Abfrage bei den jeweiligen Herstellern, Dienstleistern und zuständigen Sicherheitsstellen erforderlich. Besonders bei Serververwaltungssoftware, Netzwerkdiensten und Robotiksystemen muss geprüft werden, ob konkrete Produkte, Versionen oder Konfigurationen betroffen sind.

Auch bei der Bewertung von KI-Sicherheitsproblemen ist eine differenzierte Betrachtung notwendig. Dass ein Modell durch manipulierte Inhalte beeinflusst werden kann, bedeutet nicht automatisch, dass jeder Einsatz unsicher ist. Das Risiko hängt wesentlich von den Zugriffsrechten, den Datenquellen, den Freigabemechanismen und der technischen Isolation ab.

Fazit: Sicherheit beginnt bei den Vertrauensketten

Die 66. Folge von „Passwort“ zeigt, wie vielfältig die aktuelle Sicherheitslandschaft ist. Social Engineering richtet sich gegen menschliche Erwartungen, RPKI soll Schwächen im Internet-Routing begrenzen, kompromittierte Verwaltungssoftware macht Lieferketten zum Angriffsziel, KI-Programmierassistenten erweitern die Angriffsfläche von Entwicklungsprozessen und Roboter übertragen digitale Risiken in die physische Welt.

Der gemeinsame Nenner ist die Abhängigkeit von Vertrauensketten. Unternehmen verlassen sich auf Nutzer, Dienstleister, Softwareanbieter, Netzwerkprotokolle, KI-Systeme und vernetzte Geräte. Jede dieser Beziehungen kann sicher gestaltet werden, benötigt dafür aber klare Zuständigkeiten, begrenzte Rechte und überprüfbare Prozesse.

Für die Unternehmenspraxis bedeutet das: Sicherheitsmaßnahmen sollten nicht ausschließlich auf bekannte Schadsoftware oder einzelne Schwachstellennummern ausgerichtet sein. Ebenso wichtig sind die Fragen, welche Systeme zentrale Kontrolle ausüben, welche automatisierten Entscheidungen getroffen werden und wie sich ein Angriff innerhalb einer Umgebung ausbreiten könnte.

Gerade im Zusammenspiel von KI und IT-Sicherheit ist eine nüchterne Bewertung entscheidend. KI kann Analyse, Entwicklung und Recherche unterstützen, ersetzt aber weder Zugriffskontrollen noch Sicherheitsprüfungen. Wenn Unternehmen diese Grenze beachten und KI-Systeme mit klar definierten Rechten, geprüften Datenquellen und menschlichen Freigaben einsetzen, lassen sich die Vorteile der Technologie mit einem kontrollierbaren Risikoprofil verbinden.

Bibliografie heise online: „Passwort“ Folge 66: News mit Clickfix, RPKI, Roboterhacks und KI-Überlistung. Autor: Dr. Christopher Kunz. Veröffentlichung: 16. September 2026. https://www.heise.de/news/Passwort-Folge-66-News-mit-Clickfix-RPKI-Roboterhacks-und-KI-Ueberlistung-11445887.html heise online: Podcast-Übersicht. https://www.heise.de/thema/Podcast heise security: Alerts, Newsticker, Hintergrund und Events. https://www.heise.de/security Passwort – der Podcast von heise security: Episodenübersicht und Shownotes zur Folge „News mit Clickfix, RPKI und KI-Überlistung“. https://passwort.podigee.io/episodes brandaktuell: „Passwort 66: Clickfix, RPKI und KI-Überlistung im Fokus“. Autor: Tobias Marek. Veröffentlichung: 16. September 2026. https://brandaktuell.at/passwort-66-clickfix-rpki-und-ki-ueberlistung-im-fokus/ Pasquale Pillitteri: „ClickFix, das gefälschte CAPTCHA, das dich die Malware selbst installieren lässt“. Veröffentlichung: 15. September 2026. https://pasqualepillitteri.it/de/news/16347/clickfix-gefaelschtes-captcha-malware heise online: „Passwort“ Folge 65: Wasserzeichen, Schlüsselprüfungen und langsame Logs. https://www.heise.de/news/Passwort-Folge-65-Wasserzeichen-Schluesselpruefungen-und-langsame-Logs-11414909.html