KI-Malware und LLM-Missbrauch: Die nächste Welle von Cyberbedrohungen

Bedrohungen auf KI-Basis werden voraussichtlich exponentiell wachsen. Die Hauptschwäche auf der Verteidigerseite besteht nicht mehr darin, gute Erkennungsideen zu entwickeln, sondern diese Ideen schnell genug und in ausreichendem Umfang in Produktivregeln umzusetzen.

KI-native Malware wird traditionelle SIEMs überholen ohne automatisierte Regelbereitstellung

Zukünftige Malware-Familien werden wahrscheinlich kleine LLMs oder ähnliche Modelle direkt in ihren Code einbetten. Dies ermöglicht ein Verhalten, das für traditionelle Abwehrmechanismen sehr schwer zu handhaben ist:

• Selbstmodifizierender Code, der sich ständig ändert, um Signaturen zu vermeiden.
• Kontextbewusste Umgehung, bei der die Malware „lokale“ Protokolle, laufende Prozesse und Sicherheitstools „betrachtet“ und ihre Taktik spontan anpasst.
• Autonome „KI-Ransomware-Agenten“, die externe Plattformen für Anweisungen anrufen, neue Nutzlasten abrufen, Lösegeld verhandeln und sich dann in einer anderen Form erneut bereitstellen.
  
  

Malware beginnt sich weniger wie ein statisches Binärprogramm zu verhalten und mehr wie ein flexibler Dienst, der in jeder Opferumgebung lernt und iteriert.

Die meisten SIEM-Setups sind für diese Welt nicht ausgelegt. Selbst führende Plattformen unterstützen in der Regel maximal ein paar Hundert Regeln. Das reicht nicht aus, um das Volumen und die Vielfalt der KI-gesteuerten Techniken in großen, komplexen Umgebungen abzudecken. In der Praxis bedeutet ernsthafte Abdeckung tausende von aktiven Regeln, die spezifischen Protokollquellen, Assets und Anwendungsfällen zugeordnet sind.

Hier liegt die harte Grenze bei der SOC-Kapazität. Jede Regel hat Kosten: Feinabstimmung, Behandlung von Fehlalarmen, Dokumentation und langfristige Wartung. Und um die Arbeitsbelastung im Griff zu behalten, deaktivieren Teams einen wesentlichen Teil des potenziellen Erkennungsinhalts oder nehmen ihn oft gar nicht erst auf.

Das Ausschalten einer Regel, die bereits überwacht wird, bedeutet ausdrücklich, die Verantwortung für die Entfernung einer Verteidigungsschicht zu übernehmen. Bei begrenzter Kapazität fühlt es sich oft sicherer an, neue Regeln zu blockieren, als bestehende zu entfernen.

Jahrelang war die Hauptsorge die Alarmmüdigkeit – wenn es zu viele Alarme für zu wenige Analysten gibt. In einer KI-nativen Bedrohungslandschaft wird ein weiteres Problem wichtiger: Abdeckungslücken. Der gefährlichste Angriff ist derjenige, der nie einen Alarm auslöst, weil die erforderliche Regel nie geschrieben, genehmigt oder bereitgestellt wurde.

Dies verändert die Rolle der SOC-Führung. Der Fokus verlagert sich vom Mikromanagement einzelner Regeln zum Management des gesamten Erkennungsportfolios:

• Welche Verhaltensweisen und Assets werden abgedeckt?
• Welche blinden Flecken werden akzeptiert und warum?
• Wie schnell kann sich das Regelset ändern, wenn eine neue Technik, ein Exploit oder eine Kampagne auftaucht?
  
  

Traditionelle Prozesse machen dies noch schwieriger. Manuelles QA, langsame Änderungssteuerung und ticketgesteuerte Bereitstellungen können die Zeitspanne von „Wir wissen, wie man das erkennt“ bis „Diese Regel ist in der Produktion live“ auf Tage oder Wochen ausdehnen. KI-gesteuerte Kampagnen können sich innerhalb von Stunden anpassen.

Um diese Lücke zu schließen, müssen die SOC-Operationen selbst KI-unterstützt werden:

• KI-gestützte Regelgenerierung und -konvertierung aus Bedrohungsberichten, Jagd-Anfragen und Forschungsarbeiten in einsatzbereite Regeln über mehrere Abfragesprachen hinweg.
• Automatisierte Abdeckungszuordnung gegen Frameworks wie MITRE ATT&CK und gegen reale Telemetrie (Streams, Themen, Indizes, Protokollquellen), um zu sehen, was tatsächlich überwacht wird.
• Intelligente Priorisierung, welche Regeln aktiviert, stummgeschaltet oder abgestimmt werden sollten, basierend auf Risiko, Geschäftskritikalität und beobachteten Auswirkungen.
• Enge Integration mit Echtzeit-Event-Streaming-Plattformen, damit neue Regeln sicher über sehr große Datenmengen hinweg getestet, eingeführt und zurückgerollt werden können.
  
  

Ohne dieses Maß an Automatisierung und Gestaltung, die auf das Streaming zuerst ausgelegt ist, wird SIEM zu einem Engpass. KI-native Bedrohungen werden nicht auf wöchentliche Änderungsfenster warten; Erkennungsintelligenz und Regelbereitstellung müssen mit Streaming-Geschwindigkeit betrieben werden.

KI-native Erkennungsintelligenz wird zum neuen Standard

Bis 2026 werden Cybersicherheitsanbieter danach beurteilt, wie tief KI in deren Erkennungslifecycle eingebettet ist, nicht danach, ob sie KI einfach nur als Marketingbegriff verwenden. Unternehmens-Käufer, insbesondere im Maßstab von Fortune 100, werden KI-native Erkennungsintelligenz als Anforderung betrachten.

Konkret werden große Kunden verlangen:

• Selbstverwaltete, private LLMs, die keine firmeneigene Telemetrie oder Logik an öffentliche Clouds weitergeben.
• GPU-effiziente Modelle, die speziell für Erkennungsintelligenz-Workloads optimiert sind, nicht für generische Chat- oder Inhaltsaufgaben.
• Klare Garantien, dass Daten innerhalb gut definierter Vertrauensgrenzen bleiben.
  
  

Auf Produktsseite wird KI jeden Teil des Erkennungsstapels berühren:

• KI-generierte Erkennungsregeln, die mit Frameworks wie MITRE ATT&CK abgestimmt sind (bereits bei SOC Prime in Kraft).
• Allein bei SOC Prime wächst das Volumen an KI-generierten Erkennungsregeln derzeit monatlich um etwa 2x, von etwa 60 Regeln im Juni 2025 auf fast 1.000 im Oktober 2025. Dieses Wachstum wird sowohl durch die schnellere Bereitstellung neuer Regeln als auch durch aufkommende KI-gestützte Malware, die KI gegen KI benötigt.
• KI-gesteuerte Anreicherung, Abstimmung und Anpassung an Log-Quellen, damit Regeln relevant bleiben, wenn sich die Telemetrie ändert.
• KI-unterstützte nachträgliche Untersuchungen, die automatisch neue Logik über historische Daten abspielen können.
• KI-basierte Priorisierung von Bedrohungsinhalten basierend auf Kundenstack, Geografie, Sektor und Risikoprofil.

Mit anderen Worten, KI wird Teil der Erkennungs-„Fabrik“: wie Regeln erstellt, verwaltet und über viele Umgebungen hinweg abgeschaltet werden. Bis 2026 wird KI-unterstützte Erkennungsintelligenz nicht mehr ein Mehrwertmerkmal sein; es wird die Grundvoraussetzung für ernsthafte Sicherheitsplattformen sein.

Anbieter von Foundation-Modellen werden eine neue Sicherheitsschicht besitzen – und LLM-Firewalls benötigen

Da große Sprachmodelle Teil der Kerninfrastruktur für Softwareentwicklung, Betrieb und Support werden, treten Foundation-Modell-Anbieter zwangsläufig in die Verantwortungskette der Cybersicherheit ein. Wenn ihre Modelle verwendet werden, um Phishing-Kampagnen, Malware oder Exploit-Code in großem Maßstab zu generieren, ist es nicht mehr realistisch, die gesamte Verantwortung auf Endnutzerorganisationen abzuwälzen.

Von Foundation-Modell-Anbietern wird erwartet, dass sie klar böswillige Anwendungsfälle erkennen und einschränken und kontrollieren, wie ihre APIs genutzt werden, während sie dennoch legitime Sicherheitstests und Forschung ermöglichen. Dies beinhaltet:

• Abfragen auf offensichtliche Anzeichen böswilliger Absicht, wie Schritt-für-Schritt-Anleitungen zum Erlangen von anfänglichem Zugriff, Eskalation von Privilegien, seitliche Bewegung oder Datenexfiltration, überprüfen.
• Verdächtige Nutzungsmuster über Mandanten hinweg beobachten, wie automatisierte Schleifen, Infrastruktur-ähnliches Verhalten oder wiederholte Generierung von offensivem Sicherheitsinhalt.
• Anwendung abgestufter Antworten: Ratenbegrenzung, zusätzliche Verifizierung, menschliche Überprüfung oder endgültige Blockierung bei offensichtlichem Missbrauch.
  
  

Generische „Helfen Sie nicht beim Hacking“-Filter sind nicht genug. Eine dedizierte Sicherheitsschicht für LLM-Verkehr wird benötigt – eine LLM-Firewall.

Eine LLM-Firewall sitzt zwischen Anwendungen und dem Modell und konzentriert sich auf Cyberrisiken:

• Sie führt eine semantische Inspektion von Abfragen und Ausgaben auf Indikatoren für Angriffsplanung und -ausführung durch.
• Sie setzt Richtlinien durch: was erlaubt ist, was maskiert oder transformiert werden muss und was vollständig blockiert werden muss.
• Sie produziert Sicherheitstelemetrie, die in SIEM, SOAR und Streaming-Analysen zur Untersuchung und Korrelation mit anderen Signalen eingespeist werden kann.
  
  

Produkte wie AI DR Bastion sind mit dieser Rolle im Sinn entworfen: eine Schutzschicht um die Nutzung von LLM, die sich auf die Erkennung und Verhinderung von offensivem Cybergebrauch spezialisiert.

Diese Art der Kontrolle kann helfen:

• Unternehmen, die LLM verbrauchen, indem sie das Risiko verringern, dass interne Benutzer oder Anwendungen Modelle leicht zu Waffen machen können.
• Modell- und Plattformanbieter, indem es ihnen einen konkreten Mechanismus bietet, um zu zeigen, dass sie den Missbrauch ihrer APIs aktiv kontrollieren.
  
  

Da LLMs in CI/CD-Pipelines, Entwicklerassistenten, Kundensupportabläufen, Incident-Response-Tools und sogar in Malware selbst eingebettet werden, verschwindet die Grenze zwischen „KI-Sicherheit“ und „Anwendungssicherheit“. Modellanbieter, Plattformteams und Sicherheitsorganisationen werden die Verantwortung für die Nutzung dieser Systeme teilen.

In dieser Architektur werden LLM-Firewalls zu einer Standardschicht, ähnlich wie WAFs und API-Gateways heute – arbeiten zusammen mit SIEM und Echtzeit-Streaming-Analysen, um sicherzustellen, dass dieselben KI-Fähigkeiten, die Geschäftsergebnisse beschleunigen, nicht zu einem Verstärker für Angreifer werden.

Das „Shift-Left Detection“-Zeitalter beginnt

Bis 2026 werden viele Unternehmenssicherheitsprogramme erkennen, dass es sowohl finanziell untragbar als auch operationell zu langsam ist, die gesamte Telemetrie zuerst in ein SIEM zu schieben und dann erst die Erkennung laufen zu lassen.

Der nächste generationsübergreifende Stack wird die Erkennungslogik näher an den Ort bringen, an dem Daten erzeugt und transportiert werden:

• Direkt in Ereignisbrokern, ETL-Pipelines und Streaming-Plattformen wie Confluent Kafka.
• Als Teil des Datengewebes, nicht nur am Ende der Pipeline.
  
  

Das Ergebnis ist ein „Shift-Left Detection“-Modell:

• Mehr als die Hälfte der großen Unternehmen wird voraussichtlich beginnen, Architekturen zu evaluieren oder zu testen, bei denen die Echtzeiterkennung in der Streaming-Schicht ausgeführt wird.
• Das SIEM entwickelt sich zu einer Schicht für Compliance, Untersuchung und Aufbewahrung, während die Erkennungslogik erster Linie auf den sich bewegenden Daten ausgeführt wird.
• Vendor-neutrale, hochleistungsfähige Erkennungsregeln, die im Streaming-Maßstab laufen können, werden zu einem entscheidenden Unterscheidungsmerkmal.
  
  

In diesem Modell ist Bedrohungserkennungsinhalt nicht mehr an einen einzelnen SIEM-Motor gebunden. Regeln und Analysen müssen sein:

• In Formaten ausgedrückt, die auf Streaming-Plattformen und in mehreren Backends ausgeführt werden können.
• Verwaltet als gemeinsamer Katalog, der „vor dem SIEM“ bereitgestellt werden kann und dennoch im Lauf der Zeit nachverfolgt, geprüft und abgestimmt werden kann.
  
  

Die Produktstrategie von SOC Prime für 2026 ist auf diesen Wandel abgestimmt: Aufbau einer Leitungsgeschwindigkeits-Pipeline die vor dem SIEM läuft und sich direkt in Streaming-Plattformen integriert. Dies ermöglicht die Kombination von:

• KI-nativer Erkennungsintelligenz im großen Maßstab,
• Echtzeitausführung auf Ereignisströmen, und
• Nachgelagerter Korrelation, Aufbewahrung und Compliance in SIEM- und Datenplattformen.
  
  

Insgesamt definieren KI-native Malware, LLM-Missbrauch, KI-gesteuerte Erkennungsintelligenz und Shift-Left-Erkennungsarchitekturen die nächste Welle von Cyber-Bedrohungen – und die Form der Verteidigungen, die benötigt werden, um ihnen zu begegnen.