Schadsoftware-Erkennung & -Analyse

Signaturbasierter Virenschutz übersieht neue, gepackte und verschleierte Schadsoftware, und manuelles Reverse Engineering lässt sich nicht auf Tausende Proben skalieren. Moderner Endpunktschutz nutzt ML- Klassifikatoren auf statischen und verhaltensbezogenen Merkmalen, während LLMs Analysten inzwischen dabei helfen, unbekannte Proben zu dekompilieren, zu entschleiern und in Minuten zusammenzufassen. Das Ergebnis sind schnellere Triage, bessere Abdeckung unbekannter Bedrohungen und weniger Stunden für Routineproben. Dieses Dokument bleibt auf der Ebene von Verteidigung, Richtlinien und Architektur.

Problem & Nutzen

• Heute: AV-/EDR-Signaturen und Reputationsabfragen fangen bekannte Bedrohungen ab; unbekannte Proben gehen an ein kleines Team von Reverse Engineers oder einen externen Incident-Response-Dienstleister. Polymorphe Schadsoftware, „Living-off-the-Land“-Skripte (PowerShell, JavaScript, Makros) und schädliche Installationsprogramme oder Pakete erzeugen einen dauerhaften Rückstau.
• KI-Nutzen: (1) ML-Klassifikatoren verallgemeinern auf bisher unbekannte Proben; (2) LLMs erklären Skripte und dekompilierten Code in allgemeinverständlicher Sprache, extrahieren IOCs und entwerfen Erkennungsregeln; (3) Agenten automatisieren die wiederkehrenden Analyseschritte (entpacken, detonieren, anreichern, berichten).
• Belege: VirusTotal berichtet, dass seine KI-basierte Analyse von Mach-O-Binärdateien echte Mac- und iOS-Schadsoftware aufdeckte, die zum Zeitpunkt der Einreichung von keinem Virenschutz erkannt wurde, und Code Insight deckt inzwischen Skripte, Dokumente, Pakete und Erweiterungen ab [1]. Der EMBER2024-Benchmark von Elastic bietet einen öffentlichen Maßstab für ML-Detektoren, einschließlich auf Umgehung ausgerichteter Testsätze [2]. Erwarten Sie nicht, dass sich Erkennungsraten aus Herstellerangaben ohne Test auf Ihre Umgebung übertragen lassen.

Varianten

• KMU / Managed Service: EDR/XDR mit ML-Prävention, betrieben von einem Managed-Detection-Anbieter (MDR).
• Unternehmens-SOC / CERT: automatisierte Sandbox plus LLM-Zusammenfassung für jeden verdächtigen Anhang und jede auf Endpunkten gesehene Datei; das Analyseteam für Schadsoftware nutzt KI-gestütztes Reverse Engineering.
• Öffentliche Hand / CERTs: gemeinsame Analyseplattformen (z. B. Repositorien im Stil von MWDB) und nationale Meldepflichten.
• Entwickler / DevSecOps: Scannen von Build-Artefakten, Containern und Paketen (siehe SEC-016).
• Mobil und macOS/Linux: plattformspezifische Klassifikatoren; Scannen von Browser-Erweiterungen und Plugins.
• Privatnutzung: Verbraucher-Virenschutz (Microsoft Defender, ESET, Bitdefender, G DATA, F-Secure) mit eingebautem ML; keine eigene Pipeline nötig.

So funktioniert es

1. Datei/Skript/Anhang oder Endpunkt-Ereignis
2. Vorfilter (Hash-Reputation, YARA, Allowlists, Dateityp-Erkennung)
3. statische Analyse (PE/ELF/Mach-O-Merkmale, Strings, Imports, Entropie, Packer-Erkennung)
4. ML-Klassifikator (Gradient-Boosted Trees / neuronales Netz auf Merkmalen oder Rohbytes)
5. Score
6. dynamische Analyse in isolierter Sandbox (Verhalten, Netzwerk, Persistenz), wenn der Score unsicher ist
7. LLM-Assistent: Skript / dekompilierten Code entschleiern
8. Verhaltenszusammenfassung, IOCs, ATT&CK-Zuordnung
9. Urteil + Belege
10. SOC-Ticket / automatische Eindämmung (Host isolieren, Hash blockieren)
11. Prüfung durch Analysten
12. Rückfluss in Labels und Regeln

• Klassifikatoren: merkmalsbasierte Modelle (im Stil von EMBER, LightGBM) bleiben das Arbeitspferd für die Erkennung vor der Ausführung; Verhaltensmodelle bewerten Prozess- und Sandbox-Spuren.
• LLM-Ebene: codefähige LLMs lesen Skripte, Dekompilier-Ausgaben (Ghidra, IDA) und Berichte zu Fähigkeiten (capa) und schreiben eine strukturierte Analyse. Sie sind Erklärer, nicht der primäre Detektor.
• Mensch-in-der-Schleife (Human-in-the-Loop): Analysten bestätigen Urteile bei folgenreichen Maßnahmen (Massen-Quarantäne, Blockieren geschäftskritischer Binärdateien) und prüfen jede erzeugte Erkennungsregel vor dem Einsatz. Proben werden nur in isolierten, zugriffsgeschützten Analyseumgebungen behandelt.

Datenaufbereitung

Kommerzielle Erkennung braucht kaum Vorbereitung. Eigene Analyse braucht Proben und Kontext: verdächtige Dateien und URLs, EDR-Telemetrie, Sandbox-Berichte, Hashes und Threat Intelligence. In einem KMU liegen diese in der EDR-Konsole, in Quarantäneordnern, Postfächern und im Helpdesk-Werkzeug.

Typische Lücken: Proben werden gelöscht, ohne archiviert zu werden, es gibt keine Namens- oder Fallkonvention, Sandbox-Berichte liegen in unterschiedlichen Formaten vor, es gibt keine Liste zugelassener Software, die Fehlalarme auslöst, und rechtliche Fragen zum Hochladen von Dateien mit personenbezogenem oder vertraulichem Inhalt auf öffentliche Dienste.

Vorbereitungsschritte: - Einen Probeneingangsprozess festlegen: isolierte Ablage, Hash, Fall-ID, Quelle (zur Verantwortung siehe PREP-004). - Eine Allowlist bekannter interner Werkzeuge und Makros pflegen, um Fehlalarme zu senken. - EDR- und Sandbox-Berichte in einem gemeinsamen Format exportieren (siehe PREP-005). - Einen kleinen gelabelten Satz bestätigt schädlicher und harmloser Dateien zum Testen aufbauen (siehe PREP-018, PREP-020). - Klassifizieren, was auf externe Analysedienste hochgeladen werden darf (siehe PREP-024).

Grober Aufwand: etwa 10 bis 20 Prozent. Das Training eines eigenen Modells (Weg D) würde dies erheblich erhöhen, da große gelabelte Korpora nötig sind; das ist außerhalb von Sicherheitsanbietern selten gerechtfertigt. Siehe GUIDE-003 für eine allgemeine Bereitschaftsprüfung.

Umsetzungswege

Welcher Weg für wen

• KMU: A - EDR/XDR-Produkte mit KI-basierter Schadsoftware-Erkennung sind ausgereift und von EU-Anbietern erhältlich, meist gebündelt mit Managed Services.
• Unternehmen: A - Endpunktschutz ist eine Standardfunktion; KI-gestützte Analyse lässt sich über den Anbieter aufsetzen, und die eigene Analyse bleibt beim CERT.
• Entwickler: C - Open-Source-Werkzeuge (YARA, Sandboxes, lokale Modelle als Hilfe beim Reverse Engineering) halten Proben im Haus und passen zur Forschung.
• Öffentliche Hand: B - Behörden können KI-gestützte Analyse über in der EU gehostete oder souveräne Cloud-APIs ergänzen und sensible Proben aus öffentlichen Sandboxes heraushalten.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• EDR/XDR mit ML-Prävention: Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity, Palo Alto Cortex XDR, Trend Micro Vision One, Sophos, Bitdefender GravityZone (RO), ESET PROTECT (SK, EU), WithSecure Elements (FI, EU), G DATA (DE, EU), Trellix, Cisco Secure Endpoint.
• Analyse- und Intelligence-Plattformen: Google Threat Intelligence / VirusTotal mit Code Insight [1], Hybrid Analysis (CrowdStrike), ANY.RUN, Joe Sandbox (CH), Intezer, VMRay (DE/US).
• MDR-Anbieter: viele EU-MDRs betreiben diese Werkzeuge für KMU.
• A wählen, wenn: keine eigenen Reverse Engineers vorhanden sind; Hosting in der EU und ein AVV mit dem Anbieter verfügbar sind.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Anreicherungs-Pipeline: Hash-/URL-Abfragen über die VirusTotal-API, Sandbox-APIs, dann ein führendes LLM (Claude, Gemini, GPT, Mistral — EU-Region oder EU-Anbieter, wo gefordert), um dekompilierte Funktionen zusammenzufassen, Skripte zu entschleiern und YARA-/Sigma-Regeln zu entwerfen.
• Orchestrierung: SOAR (Shuffle, Tines, Cortex XSOAR) oder n8n, mit strenger Schwärzung: Senden Sie nie Kundendaten oder in Proben eingebettete interne Dokumentinhalte ohne AVV an externe APIs.
• B wählen, wenn: Sie ein SOC haben und eine eigene Triage-Automatisierung auf einem EDR aufsetzen wollen.

Weg C — Selbst betreiben (Open Source)

• Statische/dynamische Analyse: Ghidra (NSA, Open Source) und Rizin/Cutter für Reverse Engineering, capa [3] zur Erkennung von Fähigkeiten, YARA [4], CAPEv2-Sandbox [5], MWDB-core (CERT Polska, EU) für Proben- Repositorien, ClamAV für Basis-Scans, Zeek/Suricata für Netzwerkspuren.
• ML: EMBER2024-Code und -Daten [2], um LightGBM-Basismodelle zu trainieren; Open-Weight-Codemodelle (Qwen-Coder, DeepSeek-Coder, Klasse Mistral/Codestral) über vLLM oder Ollama zur Erklärung.
• Hardware: HW2 genügt für ein quantisiertes Codemodell mit 14–32 Mrd. Parametern und einen Klassifikator-Dienst; Sandboxes brauchen separate, isolierte VM-Hosts (CPU/RAM, nicht GPU). Aufwand: ein bis zwei dedizierte Analysten.

Weg D — Eigenes Training

Lohnt sich für Anbieter, große CERTs oder Organisationen mit ungewöhnlichen Dateitypen oder proprietären Formaten. Erfordert einen großen, korrekt gelabelten und zeitlich getrennten Korpus (harmlose Software ist schwer zu sammeln), eine Merkmals-Pipeline und laufendes Nachtrainieren gegen Concept Drift. Rein akademische Genauigkeitswerte bei zufälliger Aufteilung sind irreführend; bewerten Sie an später datierten Proben [2].

Stand der Technik (2026)

• Öffentlicher Benchmark: EMBER2024 erweitert das ursprüngliche EMBER um weitere Dateitypen und Herausforderungs- Sätze schwer erkennbarer Schadsoftware, sodass Modelle gegen Umgehung und Drift getestet werden können [2].
• LLM-gestütztes Reverse Engineering: Code Insight und agentische Analyse-Pipelines fassen Skripte, Pakete und dekompilierte Binärdateien zusammen; das Threat-Intelligence-Team von Google dokumentiert zudem, dass Angreifer mit LLMs experimentieren, daher sollten Verteidiger KI-generierte und KI-abgefragte Schadsoftware erwarten [1][6].
• Agentische Analyse: Agenten rufen Dekompilierer, Sandboxes und Abfragen in Schleifen auf; Anbieter liefern dies innerhalb von SOC-Plattformen aus (siehe SEC-001).
• Grenzen und Fehlerbilder:
• Concept Drift: Modelle verschlechtern sich, wenn sich Schadsoftware und harmlose Software ändern.
• Adversariale Umgehung (Padding, Packing, Merkmalsmanipulation) senkt die Scores der Klassifikatoren.
• LLMs halluzinieren Verhalten, tun sich mit großen oder stark gepackten Binärdateien schwer und können durch in Proben platzierten Prompt-Injection-Text beeinflusst werden; behandeln Sie die Ausgabe als Hypothese und prüfen Sie sie mit Sandbox-Belegen.
• Fehlalarme bei legitimen Admin-Werkzeugen und hauseigener Software können den Betrieb stören.

Gemeinsame Bausteine & Kombinationen

• SEC-001 SOC-Alarmtriage: Schadsoftware-Urteile und Zusammenfassungen speisen den KI-Analysten.
• SEC-002 Phishing: Detonation von Anhängen und URLs ist dieselbe Pipeline.
• SEC-006 Erkennung von Netzwerkeinbrüchen und SEC-005 UEBA liefern zusätzliche Verhaltenssignale.
• SEC-008 Threat Intelligence: IOCs und YARA-Regeln werden in beide Richtungen ausgetauscht.
• SEC-016 Lieferketten-Sicherheit: schädliche Pakete und Modell-Artefakte nutzen dieselbe Kombination aus statischer Analyse und LLM; SEC-010 behandelt die Abwehr von Prompt Injection für die LLM-Ebene.
• Gemeinsamer Stack: Endpunkte für llm-code und llm-reasoning (HW2/HW3) können SEC-004, SEC-007 und SEC-016 bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für die Einführung eines EDR; Lizenz pro Endpunkt und Jahr.
• Weg B: 1–3 Monate für die SOAR-Integration; Kosten sind API-Nutzung plus Sandbox-Lizenzen.
• Weg C: 3–6 Monate und mindestens ein qualifizierter Analyst; die Hardware ist bescheiden, das Fachwissen ist der Kostenfaktor.
• Kennzahlen: Erkennungsrate auf einem festen, zeitlich getrennten Testsatz; Fehlalarmrate bei hauseigener Software; mittlere Zeit zur Triage einer Probe; Anteil korrekt automatisch geschlossener Proben; Analystenstunden pro Probe; Zeit von der ersten Sichtung bis zur ausgerollten Erkennung.

Menschen & Veränderung

Beziehen Sie IT-Sicherheit und IT für Einführung, Ausnahmen und Isolationsregeln ein; das Management für die Entscheidung zur automatischen Eindämmung; Legal-Compliance und die oder den Datenschutzbeauftragte(n), weil analysierte Dateien und Endpunkt-Telemetrie personenbezogene und vertrauliche Daten enthalten können und an den Anbieter weitergegeben werden dürfen (AVV, Verarbeitungsort; siehe GUIDE-005).

Betriebsrat: kommt darauf an. Reine Datei- und Prozessanalyse auf Bedrohungen ist weniger eingriffsintensiv, aber EDR-Produkte protokollieren meist Nutzer- und Geräteaktivität und sind objektiv geeignet, das Verhalten zu überwachen, daher greift oft § 87 Abs. 1 Nr. 6 BetrVG. Vereinbaren Sie Zweckbindung, keine Leistungsbewertung und wer die Telemetrie einsehen darf (siehe GUIDE-004). Öffentliche Stellen beziehen den Personalrat ein.

KI-Kompetenz: Sagen Sie den Beschäftigten, was der Agent sieht und blockiert, wie sie einen Fehlalarm melden und dass ein KI-Urteil falsch sein kann; die KI-Verordnung (AI Act) verlangt von Arbeitgebern, die KI-Kompetenz der Beschäftigten zu fördern (siehe GUIDE-006). Führen Sie das System zuerst bei einer Pilotgruppe IT-naher Nutzer ein, betreiben Sie es im reinen Erkennungsmodus und schalten Sie dann auf Blockieren um. Typische Sorgen: Unterbrechung der Arbeit durch Fehlalarme und Überwachungsängste - begegnen Sie ihnen mit einem schnellen Ausnahmeverfahren und transparenten Protokollregeln. Menschen entscheiden über das Löschen oder Isolieren von Geräten und über das Einreichen von Proben nach extern (siehe GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko — Sicherheitswerkzeuge sind keine Kategorie nach Anhang III, und es ist keine Praxis nach Art. 5 betroffen; die KI-Kompetenz (Art. 4) gilt. Die Cybersicherheit der KI-Systeme selbst wird von Art. 15 nur erfasst, wenn sie Hochrisiko-Systeme sind [7]. Wird ein Detektor auch zur Überwachung des Verhaltens von Beschäftigten eingesetzt, ist neu zu bewerten (arbeitsrechtliche und betriebsratsbezogene Fragen).
• DSGVO: Proben und Telemetrie können personenbezogene Daten enthalten (Dokumente, Benutzernamen, Pfade, E-Mails). Sicherheitsverarbeitung kann auf berechtigtem Interesse beruhen (Art. 6 Abs. 1 Buchst. f, Erwägungsgrund 49), braucht aber einen AVV, Hosting in der EU oder Garantien für Übermittlungen sowie Datenminimierung vor dem Senden an Cloud-LLMs.
• NIS2 / DORA: wesentliche und wichtige Einrichtungen müssen Cyberrisiken steuern und Vorfälle melden (NIS2-Richtlinie (EU) 2022/2555 [8]); Schadsoftware-Erkennung unterstützt diese Pflichten, ersetzt sie aber nicht. Finanzunternehmen fallen zudem unter DORA.
• Betriebliche Risiken: versehentliche Ausführung aktiver Schadsoftware (isolierte Labore, kein Produktiv- netz), Abfluss vertraulicher Dateien durch Uploads auf öffentliche Scanner (privates Scannen nutzen) und zu weitgehendes Blockieren. Gegenmaßnahmen: Sandbox ohne Netzanbindung (Air Gap), Upload-Richtlinie, gestufte Regel-Einführung, menschliche Freigabe für weitreichende Maßnahmen.
• Doppelter Verwendungszweck: Halten Sie die Werkzeuge auf die Verteidigung ausgerichtet; bauen oder teilen Sie keine funktionsfähigen Schadsoftware-Generatoren.

Erste Schritte

1. Die aktuelle Abdeckung erfassen: EDR auf allen Endpunkten, Sandboxing von Mail-Anhängen, Patch-Stand.
2. Einen 30-tägigen Test von zwei EDR-/MDR-Optionen auf Pilotgeräten durchführen und Alarme, Fehlalarme und Erklärbarkeit vergleichen.
3. Eine Richtlinie für private Uploads von Proben festlegen (keine vertraulichen Dateien an öffentliche Scanner).
4. Automatische Sandbox-Detonation und eine LLM-erzeugte Zusammenfassung im SOC-Ticket für verdächtige Dateien ergänzen; die eingesparte Analystenzeit messen.
5. Aus eigenen Vorfällen einen kleinen zeitlich getrennten Testsatz aufbauen, um Werkzeuge objektiv zu vergleichen.

Quellen

1. VirusTotal Blog — Reversing at Scale: AI-Powered Malware Detection for Apple's Binaries — https://blog.virustotal.com/2025/11/reversing-at-scale-ai-powered-malware.html
2. Elastic — EMBER2024 malware benchmark — https://github.com/FutureComputing4AI/EMBER2024
3. Mandiant FLARE — capa — https://github.com/mandiant/capa
4. VirusTotal — YARA — https://github.com/VirusTotal/yara
5. CAPEv2 sandbox — https://github.com/kevoreilly/CAPEv2
6. Google Threat Intelligence — Adversaries leverage AI for vulnerability exploitation, augmented operations and initial access — https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
9. VirusTotal Threat Intelligence docs, changelog Feb 2026 (Code Insight) — https://gtidocs.virustotal.com/changelog/february-9th-2026-code-insight-openclaw-skill-packages-private-scanning-livehunt-rules-and-more
10. CERT Polska — MWDB-core — https://github.com/CERT-Polska/mwdb-core