Die unsichtbare Bedrohung: Von API-basierter zu embedded AI-Malware

Eine technische Analyse des aktuellen Stands und zukünftiger Entwicklungen

Von H.G.O. Dillenberg | 25 Jahre IT | Bridging IT, AI & Humanity

Einleitung: Das realistischere Szenario

Die letzten zwei Jahre haben eine bemerkenswerte Entwicklung in der AI-gestützten Cybersecurity gebracht. Während sich die Forschung auf "persistent autonomous agents" fokussiert, übersehen wir die praktischere Bedrohung: das Hit-and-Run-Modell.

Der Ablauf:

1. Kompromittierung via Phishing oder Exploit

2. LLM-Agent deployed – temporär, 15–60 Minuten aktiv

3. Adaptive Environment-Analyse

4. Custom Backdoor generiert und deployed

5. Optimales Persistence-Setup etabliert

6. LLM löscht sich selbst komplett

7. Maßgeschneiderter Backdoor bleibt

Warum ist das potenziell gefährlicher? Das Detection-Window beträgt 15–60 Minuten statt Tage. Keine persistente LLM-Presence, keine 1–2 GB Artifacts. Wichtig: Dieses Modell ist bisher technisch konzipiert, aber nicht in freier Wildbahn beobachtet worden.

Wo stehen wir heute? Stand und Einordnung

Was bereits existiert – und was nicht

Technisch demonstriert (PoC-Level):

• B42 Labs demonstrierte 2023 den ersten LLM-gesteuerten Malware-PoC [1] – ein PowerShell-basiertes Proof-of-Concept, nicht in operationellem Einsatz beobachtet

• Cornell Tech entwickelte 2024 den "Morris II" Worm [2] – ein akademischer PoC zur AI-Worm-Propagation

• MalTerminal zeigt GPT-4-gesteuerte Ransomware-Generierung [3] – ausschließlich als Proof-of-Concept; es existiert keine Evidence für In-the-Wild-Deployment

Operationell beobachtet (In-the-Wild):

• APT28 nutzte LameHug mit 284 HuggingFace API-Keys in realen Angriffen [4] – API-basiert, nicht embedded

• Anthropic dokumentierte im November 2025 einen chinesischen State Actor, der Claude Code für Cyber-Espionage einsetzte [5] – mit ~10% menschlicher Intervention, ~80–90% AI-autonom

Noch nicht beobachtet:

• Fully autonomous embedded LLM-Malware in freier Wildbahn

• Self-evolving, self-improving AI-Malware-Systeme

Consensus der Research-Community: Recorded Future (2025): "AI Malware shows mostly low maturity, with no verified fully autonomous attacks at scale." [6] SentinelOne bestätigt: "Proof-of-concepts exist, but not yet in widespread deployment." [7]

Netskope Threat Labs (November 2025) [8] bestätigt: "While technically feasible, reliability issues and provider guardrails currently constrain operational effectiveness."

BSI-Perspektive

Das BSI hat die Lage differenziert analysiert [9]: KI senkt die Einstiegshürden und erhöht Umfang und Geschwindigkeit bösartiger Handlungen. Vollständig autonome Agenten sind aktuell nicht verfügbar – aber das BSI erkennt auch die Möglichkeit lokaler, eingebetteter LLM-Modelle in zukünftigen Angriffstools.

Im September 2025 [10] warnte das BSI vor steigender Professionalisierung: Während vollständig autonome Agenten noch theoretisch sind, zeigen Entwicklungen wie LameHug, dass Teile der Angriffskette bereits automatisiert werden.

Faire Einordnung: Die BSI-Position "in naher Zukunft nicht verfügbar" bezieht sich auf vollständig autonome Systeme – gestützt durch aktuelle Research von Recorded Future [6] und SentinelOne [7].

Defense: Was bereits funktioniert

Die Offense-Perspektive ist nur die halbe Geschichte.

Moderne EDR-Systeme operieren in gestaffelten Reaktionszeiten. Die Detection anomaler Prozessaktivität erfolgt im Sekundenbereich: CrowdStrike Falcon erkennt Behavioral Indicators of Attack nahezu in Echtzeit [12]. Die Klassifizierung – ist die erkannte Anomalie tatsächlich malicious? – benötigt Sekunden bis Minuten, abhängig von Kontext und Telemetrie. Die Automated Response (Prozess-Isolation, Quarantäne) ist technisch in Sekunden möglich, wird in der Praxis aber häufig durch Policy-Konfigurationen verzögert: Viele Organisationen setzen auf "Alert-and-Review" statt vollautomatische Isolation, um False Positives zu vermeiden. SentinelOne's Singularity-Plattform bietet autonome Response-Capabilities, die verdächtige Prozesse automatisch isolieren können – ob sie es tun, hängt von der Konfiguration ab. Darktrace entwickelt selbstlernende Anomalie-Erkennung mit spezifischer LLM-Inference-Pattern-Detection [13].

Microsofts Forschungsprojekt "Project Ire" (August 2025) [11] – ein Prototyp zur autonomen Malware-Klassifizierung, entwickelt von Microsoft Research, Defender und Discovery & Quantum – erreichte auf einem Public Dataset eine Precision von 0.98 (wenn es etwas als Malware flaggte, lag es zu 98% richtig) bei einem Recall von 0.83. Einschränkung: In einem Real-World-Test auf ~4.000 unklassifizierten Files sank der Recall auf ca. 26% – Project Ire ist ein vielversprechender Forschungsansatz, kein ausgerolltes Produkt-Feature. SentinelLabs hat YARA-Rules für LLM-Model-Files entwickelt – Erkennung von GGUF/Safetensors-Headers und API-Key-Patterns [14].

Das bedeutet: Das 15–60-Minuten-Window des Hit-and-Run-Modells ist nicht so unsichtbar, wie es auf den ersten Blick erscheint. Detection erfolgt im Sekundenbereich, Klassifizierung in Sekunden bis Minuten. Die eigentliche Lücke liegt in der Response-Kette: Zwischen "Alert erkannt" und "Prozess isoliert" vergeht in vielen Organisationen wertvolle Zeit – nicht wegen technischer Limitierungen, sondern wegen organisatorischer Prozesse und der Angst vor False Positives. Die zusätzliche Herausforderung liegt in der Interpretation: Ist die beobachtete Aktivität ein legitimer lokaler LLM-Prozess oder malicious?

Die Defense entwickelt sich parallel zur Offense – und hat in vielen Bereichen einen Vorsprung.

Teil 2: Das Hit-and-Run-Modell – Technical Deep Dive

Warum "Persistent Agent" suboptimal ist

Das theoretische Persistent-Agent-Modell – LLM bleibt permanent auf dem System, trifft autonome Entscheidungen über Wochen – scheitert an praktischen Problemen: 1–2 GB sind auffällig, die kontinuierliche CPU/RAM-Last detektierbar, LLM-Hallucinations in Production unzuverlässig, und das langfristige Detection-Window gibt Verteidigern Zeit.

LLM als temporärer Adaptive Configurator

Das Hit-and-Run-Modell ist konzeptionell überlegen – bisher allerdings rein theoretisch: Der LLM wird nicht als Agent eingesetzt, sondern als Adaptive Configurator. Er kommt, analysiert, konfiguriert und verschwindet.

Phase 1 – Deep Environment Analysis (15–30 min): OS, Patches, laufende AV/EDR-Tools, Network-Topologie, Egress-Filtering, User-Privileges, Domain-Membership, High-Value-Targets.

Phase 2 – Adaptive Infrastructure Setup: Custom Backdoor on-the-fly generiert und compiled, optimaler Persistence-Mechanismus (Registry, Service, DLL-Sideloading), C2-Channel passend zum erlaubten Traffic, Lateral-Movement-Tools vorbereitet.

Phase 3 – Testing, Verification, Self-Destruct: Backdoor-Connectivity getestet, Persistence verifiziert, AV/EDR-Detection geprüft. Dann: Model-Files überschrieben, Logs bereinigt, LLM komplett entfernt.

Was bleibt: Ein klassischer Backdoor – aber maßgeschneidert für genau diese Umgebung.

Gegenargument EDR: Moderne Endpoint-Detection erkennt bereits Phase 1 – allerdings gestaffelt. Ein unbekannter Prozess, der Netzwerk-Scans ausführt, OS-Informationen sammelt und AV-Tools enumeriert, erzeugt in CrowdStrike Falcon oder Microsoft Defender for Endpoint innerhalb von Sekunden Alerts. Ob diese Alerts zu einer automatischen Isolation führen oder erst manuell bewertet werden, hängt von der jeweiligen Konfiguration ab. Das Hit-and-Run-Modell müsste also nicht nur schnell sein, sondern auch die EDR-Evasion vor der Environment-Analyse lösen – ein Henne-Ei-Problem, das die praktische Umsetzung erheblich erschwert.

Wahrscheinlichste Szenarien

Hybrid-Systeme mit API + embedded Fallback (70%) und Hit-and-Run Configurators (60%) sind die wahrscheinlichsten theoretischen Entwicklungen. Mainstream-Verbreitung wie bei heutigen Banking-Trojanern bleibt unwahrscheinlich (20%) – benötigt signifikante Durchbrüche in Effectiveness.

Realistischer Zeitrahmen: 2–4 Jahre für erste in-the-wild Samples – mit der Einschränkung, dass Detection-Methoden sich parallel weiterentwickeln und den Zeitrahmen nach hinten verschieben könnten.

Wichtig: Hit-and-Run ist wahrscheinlicher als persistente Agents, da technisch praktikabler und schwerer zu erkennen – aber "wahrscheinlicher" bedeutet nicht "imminent".

Was können wir tun?

Sofort (0–6 Monate): AI-Tools inventarisieren, EDR mit AI-Detection evaluieren (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint bieten bereits LLM-Inference-Pattern-Detection), Security-Teams trainieren, Incident-Response-Playbooks aktualisieren. Vendors sollten LLM-Inference-Detection in EDR integrieren und YARA-Rules für Model-Files weiterentwickeln.

Mittelfristig (6–18 Monate): Detection-Standards entwickeln, Open-Source Detection-Tools publizieren, Integration in SIEM/EDR/XDR vorantreiben, Accessibility für KMUs sicherstellen.

Langfristig (18+ Monate): Policy-Frameworks für AI-Security, Meldepflichten für AI-Security-Incidents, University-Curricula erweitern, professionelle Certifications etablieren.

Realistische Erwartungen

Was wir erreichen können: Frühere Detection, bessere Attribution, schnellere Response, resilientere Systeme. Was wir nicht erreichen können: 100% Prevention, Zero-Day-Immunity, perfekte Forensics.

Security ist ein kontinuierlicher Prozess, kein Endzustand.

Fazit: Hit-and-Run ist die potenzielle Bedrohung

Die nüchterne Bilanz: Embedded AI-Malware im Hit-and-Run-Modell ist technisch machbar, aber bisher nicht operationell beobachtet. Alle existierenden AI-Malware-Implementierungen – von B42 Labs' PoC bis APT28's LameHug – sind entweder reine Proof-of-Concepts oder nutzen externe APIs.

Das Detection-Window von 15–60 Minuten ist eine Herausforderung, aber moderne EDR-Lösungen detektieren im Sekundenbereich – die Lücke liegt weniger in der Erkennung als in der organisatorischen Response-Geschwindigkeit.

History zeigt: Defense adaptiert. Polymorphe Viren, Rootkits, APTs – alle schienen unlösbar. Alle wurden lösbar. Hit-and-Run AI-Malware wäre schwieriger als persistente Agents, aber nicht unlösbar.

Es braucht: Realisierung der Bedrohung, Tool-Development, Training, Standards, Research – und Zeit. Wir haben noch etwas davon.

Nicht Panik. Preparation.

Fragen an die Community

Für Security-Praktiker: Wie würden Sie ein 15–60-Minuten-Window detektieren? Welche EDR-Capabilities nutzen Sie bereits für Real-Time-Response gegen unbekannte Prozesse?

Für Forscher: Welche Detection-Methoden sind vielversprechend? Wie können wir ethisch PoCs entwickeln?

Für Vendors: Ist LLM-Inference-Detection in Ihrer Roadmap? Wie steht es um Real-Time-Automated-Response?

Quellen & Referenzen

[1] B42 Labs: "LLM meets Malware" (Juni 2023) – PoC, nicht in-the-wild[2] Cornell Tech: "Morris II Worm" (2024) – akademischer PoC[3] SentinelLabs: "MalTerminal Analysis" (2025) – PoC, keine Evidence für operationellen Einsatz[4] Multiple Sources: "APT28 LameHug Campaign" (2025) – in-the-wild, API-basiert[5] Anthropic: "Disrupting the first reported AI-orchestrated cyber espionage campaign" (November 2025) – in-the-wild, API-basiert via Claude Code[6] Recorded Future: "AI Malware: Hype vs. Reality" (2025) [7] SentinelOne: "AI Worms Explained" (November 2025) [8] Netskope: "AI Language Models and Autonomous Malware" (November 2025) [9] BSI: "Einfluss von KI auf die Cyberbedrohungslandschaft" (April 2024) [10] BSI: "KI und gegenwärtige Cyberbedrohungen" (September 2025) [11] Microsoft Research: "Project Ire – Autonomously Identifies Malware at Scale" (August 2025) – Forschungsprototyp, Precision 0.98 / Recall 0.83 (Public Dataset), ~26% Recall im Real-World-Test[12] CrowdStrike Threat Intelligence (2025) [13] Darktrace AI Research (2025) [14] SentinelLabs: "Hunting LLM-Enabled Malware" (2025) [15] CISA/BSI et al.: "Principles for the Secure Integration of AI in Operational Technology" (Dezember 2025) – Joint Guidance zu AI-Sicherheit in OT-Umgebungen

#CyberSecurity #AISecurity #ThreatIntelligence #EmbeddedAI #HitAndRun #MLSecurity #DefensiveAI

Transparenzhinweis: Dieser Artikel differenziert bewusst zwischen "technisch demonstriert (PoC)" und "operationell beobachtet (in-the-wild)". Korrekturen gegenüber früheren Versionen umfassen: Anthropic-Datum (korrigiert auf November 2025), Präzisierung der Microsoft Project Ire-Metriken (Precision vs. Accuracy, inkl. Real-World-Einschränkungen), Differenzierung der EDR-Reaktionszeiten (Detection/Klassifizierung/Response), Entfernung einer nicht verifizierbaren CISA/BSI-Quelle, sowie durchgängige Kennzeichnung von PoC vs. In-the-Wild-Status aller Quellen.