Detection in der Cybersecurity im Jahr 2026: Eine mehrschichtige, verhaltensbasierte Architektur zur Erkennung von Angriffen in Cloud-, Endpoint- und KI-gestützten Umgebungen

1. Introduction

Detection ist im Jahr 2026 nicht mehr als isolierte Disziplin zu verstehen, sondern als zentraler Kontrollpunkt der cyberoperativen Verteidigung. In klassischen Sicherheitsarchitekturen wurde Detection häufig als nachgelagerte Komponente behandelt: Prävention sollte kompromittierende Aktivität stoppen, und Detection sollte anschließend Ereignisse protokollieren oder Warnungen ausgeben. Diese Trennung ist in modernen Umgebungen jedoch nur noch begrenzt tragfähig. Angreifer nutzen heute eine Kombination aus Identitätsmissbrauch, Cloud-Misskonfigurationen, legitimen Verwaltungswerkzeugen, Skriptsprachen, API-Missbrauch und KI-unterstützter Täuschung, um sich unterhalb oder entlang konventioneller Kontrolllinien zu bewegen. Die praktische Konsequenz ist eindeutig: Wer Angriffe nicht früh, robust und domänenübergreifend erkennt, verliert die operative Initiative.

Die Detection-Landschaft des Jahres 2026 ist durch drei strukturelle Verschiebungen geprägt. Erstens hat sich der Angriffsschwerpunkt von rein malwaregetriebenen Kampagnen zu identity-centric intrusions verlagert. Der Kompromittierungsvektor ist häufig kein Exploit im klassischen Sinn, sondern ein gestohlener Token, ein missbrauchter OAuth-Grant, eine API-Session oder ein erfolgreiches Social-Engineering-Ereignis. Zweitens sind Cloud- und SaaS-Ökosysteme zu primären Operationsräumen geworden, in denen Telemetrie stark fragmentiert ist und Angriffe oft die Grenzen zwischen Infrastruktur, Identität und Anwendung überschreiten. Drittens hat generative KI die Skalierung von Phishing, Spear Phishing, Business Email Compromise und Prompt-Injection-Angriffen deutlich erhöht. Damit steigen nicht nur das Volumen und die Varianz der Angriffe, sondern auch die Geschwindigkeit, mit der Angreifer auf Erkennungsmaßnahmen reagieren.

Aus Sicht der Verteidigung ist daraus eine grundlegende Anforderung ableitbar: Detection muss als probabilistische Inferenz über heterogene Signale verstanden werden. Ein einzelnes Ereignis ist selten beweiskräftig. Erst die Korrelation mehrerer schwacher Indikatoren über Zeit und Domänen hinweg erzeugt hinreichende Aussagekraft. Beispielsweise ist ein PowerShell-Aufruf für sich genommen nicht schädlich; ein PowerShell-Aufruf in Kombination mit ungewöhnlicher Elternprozess-Hierarchie, Base64-kodierter Payload, Netzwerkverbindung zu neu registrierter Domain und nachfolgendem Token-Zugriff auf Cloud-Ressourcen ist hingegen hochgradig verdächtig. Detection muss daher vom Event zur Sequenz, von der Sequenz zum Graphen und vom Graphen zur risikobasierten Entscheidung denken.

Diese Arbeit verfolgt das Ziel, den Begriff Detection im Cybersecurity-Kontext präzise zu operationalisieren und eine Architektur zu entwickeln, die in realen Umgebungen des Jahres 2026 einsetzbar ist. Dabei werden nicht nur klassische Endpoint Detection and Response (EDR) und Network Detection and Response (NDR) berücksichtigt, sondern auch Cloud Detection and Response (CDR), Identity Threat Detection and Response (ITDR), Security Information and Event Management (SIEM), Security Orchestration, Automation and Response (SOAR) sowie aufkommende Kontrollflächen für KI-Systeme. Die Arbeit schlägt eine mehrschichtige Detection-Pipeline vor, die Regel-basierte, statistische und verhaltensbasierte Komponenten kombiniert. Die Idee ist nicht, jede Angriffsklasse mit einem einzelnen Modell zu lösen, sondern das Zusammenspiel komplementärer Verfahren auszunutzen.

Die praktische Relevanz ist erheblich. Im Incident Response-Kontext entscheidet Detection über MTTD $($Mean Time to Detect$)$, MTTR $($Mean Time to Respond$)$ und damit über den Gesamtschaden. In einem Zero-Trust-Modell ist Detection die kontinuierliche Verifikation, ohne die Vertrauensentscheidungen nicht belastbar sind. In Cloud-Umgebungen ist sie zugleich ein Mittel zur Kontrolle von Konfigurationsdrift, Schatten-APIs und privilegierten Fehlkonfigurationen. In KI-gestützten Umgebungen schützt sie vor Datenabfluss, Prompt-Injection und manipulativen Agenteninteraktionen. Eine moderne Detection-Architektur muss also sowohl technisch robust als auch betrieblich skalierbar sein.

Die zentrale Forschungsfrage dieser Arbeit lautet: Wie lässt sich eine Detection-Architektur konstruieren, die in heterogenen, hochdynamischen und adversarialen Umgebungen des Jahres 2026 eine hohe Erkennungsleistung bei kontrollierbarer Fehlalarmrate erreicht? Daraus folgen Unterfragen: Welche Telemetrie ist notwendig und hinreichend? Wie werden Ereignisse normalisiert und korreliert? Welche Rolle spielen Sigma, YARA, Suricata, Zeek, Sysmon, osquery, Falco und eBPF? Wie können LLM-spezifische Risiken in ein Detection-Programm integriert werden, ohne die Signalqualität zu verwässern? Und welche Evaluationsmetriken sind aussagekräftig, wenn Angriffe sequenziell, adaptiv und teilweise unbekannt sind?

Die Arbeit ist wie folgt aufgebaut: Zunächst wird der Stand der Forschung und der operationalen Praxis eingeordnet. Anschließend wird ein Threat Model formalisiert, das klassische und KI-gestützte Angriffe gemeinsam abbildet. Darauf aufbauend wird eine Detection-Methodik vorgeschlagen, implementiert und experimentell evaluiert. Eine Fallstudie illustriert den Einsatz gegen eine reale Angriffskette in einer Cloud-Identity-Umgebung. Abschließend werden Grenzen, Implikationen und zukünftige Entwicklungen diskutiert.

2. Background and Related Work

Die wissenschaftliche und praktische Literatur zu Detection ist breit, aber fragmentiert. Historisch dominierten signaturbasierte IDS/IPS-Systeme wie Snort und später Suricata, ergänzt durch Host-basierte Anti-Malware und EDR-Lösungen. Diese Ansätze waren bei bekannten Mustern effektiv, verloren jedoch an Reichweite, sobald Angriffe variierte Payloads, Verschlüsselung, Living-off-the-Land-Binaries oder legitime Admin-Tools verwendeten. Mit der Verbreitung von ATT&CK-orientierten Verteidigungsmodellen verlagerte sich der Fokus auf Verhaltensindikatoren und Technik-Ketten statt einzelner Artefakte. MITRE ATT&CK lieferte hierfür ein taxonomisches Rückgrat, indem Taktiken und Techniken systematisch beschrieben wurden (MITRE, 2026).

Ein wesentlicher Entwicklungsschritt war die Etablierung von Endpoint-Telemetrie auf Kernel- und Prozess-Ebene. Sysmon wurde zum De-facto-Standard für Windows-basierte Sichtbarkeit, insbesondere für Prozessketten, Netzwerkverbindungen, Dateioperationen und Registry-Änderungen (MICROSOFT, 2026a). Osquery ermöglichte die Abfrage von Systemzuständen als SQL-ähnliches Interface und vereinheitlichte Inventarisierung und Detection-Hunting (OSQUERY, 2026). eBPF wiederum veränderte die Linux-Seite grundlegend, da systemnahe Beobachtung mit vergleichsweise niedriger Overhead erlaubt wurde. Projekte wie Falco nutzten diese Möglichkeiten, um system call-nahe Verhaltenssignaturen in Echtzeit zu überwachen (FALCO, 2026).

Im Netzwerkbereich blieben Zeek und Suricata die dominanten Werkzeuge. Zeek ist weniger ein klassischer IDS-Ersatz als eine Netzwerktelemetrie- und Protokollanalyseplattform, die reichhaltige Metadaten für Korrelation und Hunting erzeugt (ZEEK, 2026). Suricata bietet sowohl Signatur- als auch Protokollerkennungsfunktionen und ist insbesondere für line-rate-Inline- oder Passive-Deployment-Szenarien relevant (SURICATA, 2026). Der gemeinsame Trend besteht darin, dass reine Paketinspektion zunehmend durch Flow- und Metadatenanalyse ergänzt wird, da TLS 1.3, QUIC und Ende-zu-Ende-Verschlüsselung Inhaltsinspektion beschränken. Detection verlagert sich somit in Richtung Kontexteigenschaften, Kommunikationsgraphen und Verhaltensmuster.

Im Cloud- und Identitätsbereich entstanden neue Klassen von Detektionsproblemen. Azure AD, Microsoft Entra ID, Google Cloud Identity, Okta und AWS IAM erzeugen jeweils umfangreiche Audit- und Sign-in-Telemetrie, die jedoch semantisch heterogen ist. Typische Angriffe betreffen OAuth-App-Registrierungen, Consent-Phishing, verdächtige Mailbox-Regeln, Token-Diebstahl, Multi-Factor-Authentication-Bypass, Role Assumption und temporäre Berechtigungsausweitungen. Die relevante Forschung betont deshalb zunehmend ITDR und CDR als eigenständige Domänen, nicht bloß als Erweiterung von EDR oder SIEM (NIST, 2024; CISA, 2024a).

Auch im Bereich der Regelsprachen hat sich die Praxis professionalisiert. Sigma wurde als herstellerneutraler Standard für SIEM-Detection-Regeln etabliert und ermöglicht die Übertragung von Detection-Logik zwischen unterschiedlichen Backend-Systemen (SIGMAHQ, 2026). YARA blieb der Standard für Datei- und Speichererkennung, insbesondere bei Malware-Analyse und Hunting-Workflows (YARA, 2026). Diese Regeln sind nicht ausreichend für komplexe Angriffe, aber sie sind operational entscheidend, weil sie schnell, transparent und auditierbar sind. In der Praxis wird Detection selten durch ein einzelnes Modell gewonnen, sondern durch die Kombination stabiler Regeln, kontextsensitiver Korrelation und priorisierter Anomaliehinweise.

Die akademische Literatur zu Anomaly Detection ist in den vergangenen Jahren stark gewachsen, leidet aber weiterhin unter Transferproblemen. Viele Publikationen berichten hohe AUC-Werte auf synthetischen oder veralteten Datensätzen, doch die realen Umgebungen des Jahres 2026 sind durch Konzeptdrift, ungleich verteilte Ereignisse und starke Baseline-Schwankungen charakterisiert. Insbesondere in Cloud- und Identitätsumgebungen entstehen Fehlalarme häufig durch legitime administrative Aktionen, CI/CD-Automatisierung oder globale Arbeitsmuster. Daher ist die klassische Frage „Wie erkennt man Anomalien?“ zu ersetzen durch „Welche Anomalien sind handlungsrelevant, und wie werden sie mit hinreichender Präzision in einen operativen Kontext gebracht?“ (SAXENA; SRIVASTAVA, 2025).

Ein weiterer Forschungsstrang betrifft Detection für KI-Systeme. Im Jahr 2026 sind LLMs sowohl Angriffs- als auch Verteidigungswerkzeuge. Verteidiger nutzen sie zur Log-Analyse, Triage und Regelgenerierung; Angreifer verwenden sie für hochskalierte Phishing-Kampagnen, Code-Varianten und adversarial prompting. Die eigentliche Detektionsherausforderung liegt jedoch in den Integrationspunkten: Prompt-Injection, Datenextraktion aus Retrieval-Augmented-Generation-Systemen, missbräuchliche Tool-Calls, Agenteneskalation und unautorisierte Seiteneffekte in automatisierten Workflows. Diese Phänomene passen nicht vollständig in traditionelle IDS-Kategorien und erfordern erweiterte Telemetrie aus Prompt-, Tool- und Policy-Ebene (OWASP, 2025; NIST, 2024).

Tabelle 1 ordnet zentrale Detection-Klassen und Werkzeuge ein.

Domäne	Zielgröße	Typische Tools	Stärken	Grenzen
Endpoint	Prozesse, Dateien, Registry, Syscalls	Sysmon, osquery, Wazuh, Velociraptor	Hohe Granularität, gute Prozessketten	Hohe Logmenge, Tuning-Aufwand
Netzwerk	Flows, Protokolle, Metadaten	Zeek, Suricata, Arkime	Breite Sichtbarkeit, gute Korrelation	Verschlüsselung reduziert Inhaltssicht
Cloud/Identity	Logins, Tokens, Rollen, Audit Events	Entra ID Logs, AWS CloudTrail, Okta System Log	Identitätsnahe Angriffsdetektion	Semantische Heterogenität
Container/Runtime	Syscalls, Image-Drift, Policy-Verstöße	Falco, Tracee, eBPF	Laufzeitnahe Erkennung	Plattformabhängigkeit
KI-Systeme	Prompts, Tool-Use, Retrieval, Output	Policy Logs, App Telemetry, Gateway Logs	Neue Angriffsflächen erkennbar	Noch unreife Standards

Die Literatur zeigt somit eine klare Tendenz: Detection wird 2026 als verteiltes, telemetry-zentriertes und verhaltensbasiertes Problem verstanden. Die Herausforderung besteht nicht in der Abwesenheit von Tools, sondern in deren Integration zu einer belastbaren, priorisierten und kontextualisierten Entscheidungsarchitektur.

3. Threat Model and Problem Formalization

Das Threat Model dieser Arbeit umfasst adversariale Akteure mit unterschiedlichen Ressourcen, Zielen und Operationsmodi. Im Zentrum stehen drei Kategorien: opportunistische Angreifer, zielgerichtete Initial-Access-Gruppen und hochgradig adaptive Akteure, die Cloud-, Identity- und KI-Subsysteme gezielt missbrauchen. Der Angreifer wird als in der Lage angenommen, zumindest einen initialen Zugang über Phishing, gültige Anmeldedaten, OAuth-Consent, öffentlich exponierte Services oder Supply-Chain-Artefakte zu erlangen. Weiterhin wird angenommen, dass der Angreifer legitime Tools, verschleierte Skripte, verschlüsselte Kommunikation und variable Taktiken einsetzen kann, um statische Signaturen zu umgehen.

Für die Defensive wird angenommen, dass Telemetrie aus mehreren Quellen vorhanden ist, aber nicht vollständig. Endpoint-Logs können aus Lücken, Sampling oder Speicherkosten unvollständig sein; Netzwerkdaten können durch TLS-Verschlüsselung, QUIC oder East-West-Kommunikation eingeschränkt sein; Cloud-Logs können verzögert, normalisiert oder durch Aufbewahrungsrichtlinien limitiert sein. Detection muss daher unter Bedingungen partieller Sichtbarkeit funktionieren. Formal sei $E = {e_1, e_2, \dots, e_n}$ die Menge beobachteter Ereignisse, $C$ der Kontextvektor eines Assets oder Identitätsträgers, und $R$ das Risiko. Ziel ist es, eine Funktion $f$ zu bestimmen, die aus Ereignisfolgen eine priorisierte Alarmmenge erzeugt:

$$ f(E, C) \rightarrow A = {a_1, a_2, \dots, a_k} $$

wobei jedes Alarmobjekt $a_i$ eine geschätzte Wahrscheinlichkeit $p_i$ für bösartige Aktivität, eine technische Zuordnung $t_i$ und einen operativen Schweregrad $s_i$ besitzt. Ein Alarm ist dann handlungsrelevant, wenn

$$ p_i \cdot s_i \cdot \gamma© \ge \tau $$

gilt, wobei $\gamma©$ den Kontextfaktor für Kritikalität, Identitätsprivilegien und Exponiertheit beschreibt und $\tau$ ein dynamischer Schwellenwert ist. Dieser Schwellenwert ist nicht statisch, sondern abhängig von Baseline, Umgebungsrauschen und der aktuellen Bedrohungslage.

Ein zentrales Problem ist die Sequenzialität. Viele Angriffe sind nur in der Abfolge ihrer Taktiken erkennbar. Die Rekonstruktion einer Angriffskette lässt sich als gerichteter Graph $G = (V, W)$ modellieren, wobei $V$ Ereignisse, Identitäten, Hosts, APIs und Artefakte repräsentiert und $W$ zeitliche oder kausale Kanten sind. Die Aufgabe besteht darin, Pfade zu finden, deren Sequenz mit bekannten Angriffsmustern oder hochverdächtigen Mustern übereinstimmt. Eine einfache heuristische Bewertung kann durch

$$ Score(P) = \sum_{i=1}^{m} w_i \cdot \phi(e_i) - \lambda \cdot \Omega(P) $$

beschrieben werden, wobei $\phi(e_i)$ die Evidenzstärke eines Ereignisses, $w_i$ dessen Gewicht, und $\Omega(P)$ ein Rausch- oder Unsicherheitsmaß ist. Der Parameter $\lambda$ steuert die Fehlalarm-Bereinigung. In der Praxis werden solche Scores durch Regeln, statistische Verfahren und Graph-Korrelation gemeinsam erzeugt.

Tabelle 2 zeigt die zentralen Annahmen des Threat Models.

Annahme	Beschreibung	Operative Konsequenz
Teilweise Sichtbarkeit	Logs sind unvollständig oder verzögert	Korrelation statt Einzelereignis
Adaptiver Gegner	Angreifer passt Taktiken an	Detection muss robust gegen Variationen sein
Legitimer Werkzeugmissbrauch	PowerShell, curl, Python, RMM-Tools	Verhalten ist wichtiger als Tool-Name
Cloud-Identity-Fokus	Tokens, Rollen, Consent, Sessions	Identity-Telemetrie ist kritisch
KI-Verstärkung	Generative Phishing- und Prompt-Angriffe	Neue Telemetriequellen nötig

Problemformal ist Detection somit ein mehrzieliger Optimierungsprozess. Maximiere Erkennungsrate und zeitliche Früherkennung, minimiere False Positives, Betriebsaufwand und Reaktionslatenz. Anders ausgedrückt soll ein Detektionssystem $D$ die Funktion

$$ D: \mathcal{T} \times \mathcal{K} \rightarrow {0,1} $$

approximieren, wobei $\mathcal{T}$ die Telemetrie und $\mathcal{K}$ der Kontext ist. Für reale Umgebungen ist eine binäre Klassifikation jedoch zu grob; die robuste Form ist eine Rangfolge nach Risiko. Der Zielraum ist damit ein geordnetes Priorisierungssystem, nicht bloß ein Alarm-Trigger.

4. Proposed Methodology

Die vorgeschlagene Methodik ist eine mehrschichtige Detection-Architektur, die vier Ebenen kombiniert: Telemetrie-Erfassung, Normalisierung und Anreicherung, Detektionslogik und operative Priorisierung. Der Kern ist eine Korrelationsschicht, die Regeln, statistische Signale und sequenzielle Muster in ein einheitliches Bewertungsmodell überführt. Diese Architektur ist absichtlich modular, weil in realen SOC-Umgebungen unterschiedliche Reifegrade, Datenquellen und regulatorische Anforderungen bestehen.

Die erste Ebene ist die Telemetrie-Erfassung. Auf Windows-Endpunkten werden Sysmon, Security Logs und gegebenenfalls EDR-Events genutzt; auf Linux-Systemen kommen auditd, eBPF-Sensoren, Falco oder Tracee hinzu; im Netzwerk werden Zeek-Logs, Suricata-Alerts und NetFlow/IPFIX eingebunden. In Cloud-Umgebungen werden Kontroll- und Audit-Logs aus Azure, AWS und Google Cloud integriert. Für KI-Systeme werden Prompt-, Tool-Use-, Retrieval- und Policy-Logs separat erfasst. Der Grundsatz lautet: je näher an der Aktion, desto besser. Je näher an der Entscheidung, desto wichtiger ist Kontext.

Die zweite Ebene normalisiert Ereignisse in ein gemeinsames Schema. Ein Ereignis wird als Tupel $e = \langle ts, src, dst, actor, action, object, outcome, confidence \rangle$ repräsentiert. Diese Normalisierung reduziert Heterogenität und erleichtert Korrelation. Gleichzeitig wird jedes Ereignis mit Kontext angereichert: Asset-Kritikalität, Identitätsrolle, geografische Lage, Maturität des Endpunkts, bekannte Wartungsfenster und Baseline-Abweichung. Dieser Kontext ist entscheidend, weil dieselbe Aktion je nach Umgebung harmlos oder alarmwürdig sein kann.

Die dritte Ebene ist die Detektionslogik. Sie besteht aus vier Verfahren:

1. Deterministische Regeln für eindeutig riskante Muster, etwa verdächtige Parent-Child-Prozessbeziehungen, bekannte LOLBins, ungewöhnliche OAuth-Consent-Events oder verdächtige System-API-Kombinationen.
2. Anomalieerkennung auf Basis von Baselines, etwa seltene Prozesse, ungewöhnliche Login-Zeiten, neue Länder, neue Geräte oder atypische DNS-Anfragen.
3. Sequenz- und Graph-Korrelation zur Rekonstruktion von Angriffspfaden.
4. Spezialisierte Content-Erkennung mittels YARA oder Signaturen, wenn Artefakte verfügbar sind.

Tabelle 3 zeigt den Aufbau der Signale.

Signaltyp	Beispiel	Vorteil	Schwäche
Regelbasiert	PowerShell mit EncodedCommand	Hohe Präzision	Umgehbar durch Variation
Statistisch	Ungewöhnlicher Login zur Nachtzeit	Gute Abdeckung	Kontextabhängig, Drift
Sequenziell	Phishing → Token-Diebstahl → Mailbox-Regel	Hohe Aussagekraft	Benötigt Korrelation
Artefaktbasiert	YARA-Match auf Loader	Direkt verwertbar	Nur bei vorhandenen Artefakten

Die vierte Ebene priorisiert Alarme. In der Praxis ist nicht jeder Treffer gleichwertig. Ein Alert auf einem isolierten Testsystem ist anders zu bewerten als derselbe Alert auf einem Domain Controller, einer Produktionsdatenbank oder einer privilegierten Cloud-Identität. Daher wird ein Priorisierungswert verwendet, der technische Evidenz, Asset-Wert, Angriffsreife und Exploit-Nähe gewichtet. Ein möglicher Score lautet:

$$ Priority = \alpha \cdot Evidence + \beta \cdot AssetCriticality + \delta \cdot AttackProgress + \eta \cdot Exposure $$

wobei $\alpha, \beta, \delta, \eta$ umgebungsspezifisch kalibriert werden. Die Kalibrierung sollte nicht ausschließlich datengetrieben erfolgen, sondern mit Threat-Intelligence, Red-Team-Ergebnissen und Szenario-Workshops abgestimmt sein.

Methodisch schlagen wir zudem ein Detection-Engineering-Workflow-Modell vor. Zunächst werden relevante Angriffsverhalten aus ATT&CK extrahiert. Danach wird aus jeder Technik eine konkrete, datenquellen-spezifische Hypothese formuliert. Anschließend werden Regeln in Sigma, YARA, Suricata oder Cloud-Detection-Queries umgesetzt. Schließlich erfolgt Validierung durch Emulation, etwa mit Atomic Red Team, Caldera oder kontrollierten Simulationen. Die Regel wird nur dann produktiv gesetzt, wenn Präzision, Performance und Wartbarkeit akzeptabel sind.

Ein besonderer Schwerpunkt liegt auf KI-gestützter Kommunikation. Für LLM-Umgebungen muss die Detection zusätzlich folgende Muster abdecken: ungewöhnliche Prompt-Länge, systematische Instruktionsumgehung, wiederholte Tool-Invocation-Muster, Retrieval auf sensible Wissensbasen ohne legitimen Kontext, plötzliche Ausgabe von Geheimnissen, sowie potenzielle Prompt-Injection-Ketten. Diese Signale sind nicht allein inhaltsbasiert, sondern erfordern Metadaten über Gesprächsverlauf, Rollen, Tool-Berechtigungen und Output-Filter.

5. Implementation

Die Implementierung der vorgeschlagenen Architektur erfolgt als Referenz-Stack, der sich für SOC- und Blue-Team-Umgebungen des Jahres 2026 eignet. Ziel ist nicht die Bindung an ein einzelnes Produkt, sondern ein interoperabler Aufbau mit offener Regel- und Telemetrie-Kompatibilität. Als Kernkomponenten dienen Zeek für Netzwerkmetadaten, Suricata für Signaturen und Protokollalarme, Sysmon und auditd/eBPF für Endpoint-Sichtbarkeit, osquery für Zustandserhebung, Wazuh oder Elastic Agent für Sammel- und Korrelationsaufgaben sowie Sigma und YARA für regelbasierte Detektion.

Der erste technische Schritt ist die Vereinheitlichung der Logaufnahme. In Windows-Umgebungen werden Sysmon-Events mit geeigneten Konfigurationen verwendet, beispielsweise zur Erfassung von Prozess- und Netzwerkaktivität. Auf Linux-Systemen werden auditd-Regeln und eBPF-Sensoren kombiniert, um Prozessstarts, Dateioperationen und Netzwerk-Syscalls zu überwachen. Für Container-Workloads werden Falco-Regeln ergänzt, da Container-Lebenzyklen kurz sind und klassische Host-Agenten oft zu spät greifen. In Cloud-Umgebungen werden API-Audits und Sign-in-Logs zentral eingespielt.

Ein praktikabler Sammelpfad besteht aus Agenten, einem Nachrichtensystem und einem Analyse-Backend. In kleineren Umgebungen kann dies direkt in Elastic oder OpenSearch erfolgen; in größeren Umgebungen ist ein Event-Streaming-Layer zweckmäßig. Die Normalisierung in ECS, OpenTelemetry-ähnliche Strukturen oder ein internes Canonical Schema ist essenziell. Ohne harmonisiertes Schema wird Korrelation zur manuellen Datenbastelei.

Beispiel für eine Sigma-Regel zur Erkennung verdächtiger PowerShell-Nutzung:

id: 8d4b5f3c-7b2a-4a9f-9d18-encoded-powershell
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'EncodedCommand'
      - 'FromBase64String'
  condition: selection
fields:
  - Image
  - CommandLine
falsepositives:
  - Administrative automation
level: high
tags:
  - attack.t1059.001

Für die Netzwerkerkennung wird eine Zeek-basierte Beobachtung von DNS, HTTP, TLS und Verbindungen eingesetzt. Besonders relevant sind neu registrierte Domains, ungewöhnliche SNI-Muster, seltene JA3/JA3S-Kombinationen und Verbindungen zu Infrastruktur mit geringer Reputation. Wo möglich, wird auch auf Flow-Ebene korreliert, etwa bei Reverse-Shell-Charakteristika oder Beaconing-ähnlichem Periodizitätsverhalten.

Beispiel für eine Suricata-Regel zur Erkennung eines typischen Shell-Download-Musters:

alert http any any -> any any (
    msg:"Possible suspicious script download";
    flow:established,to_server;
    http.method; content:"GET";
    http.uri; content:".ps1"; nocase;
    http.header; content:"User-Agent|3a|"; nocase;
    classtype:trojan-activity;
    sid:2101001;
    rev:1;
)

Für Datei- und Speicherartefakte wird YARA genutzt. Gerade bei Loadern, Skripten und Phishing-Dokumenten ist YARA weiterhin hochwirksam, sofern Artefakte extrahierbar sind. In einer operationalen Pipeline wird YARA meist nicht isoliert, sondern als zusätzliche Evidenzschicht neben Prozess- und Netzwerkdaten eingesetzt.

rule Suspicious_PowerShell_Dropper_2026
{
    meta:
        description = "Erkennung eines verdächtigen Dropper-Musters"
        author = "Blue Team Research"
        date = "2026-01-15"
    strings:
        $s1 = "FromBase64String"
        $s2 = "IEX"
        $s3 = "DownloadString"
        $s4 = "Invoke-Expression"
    condition:
        2 of them
}

Die Implementierung enthält zudem eine Korrelationsebene, die Ereignisse innerhalb eines Zeitfensters verknüpft. Ein einfacher, aber wirksamer Ansatz ist ein Sliding Window von $\Delta t$ Minuten, in dem Prozess-, Netzwerk- und Identitätsereignisse zusammengeführt werden. Komplexere Varianten verwenden Graphdatenbanken oder Streaming-Korrelation mit Zustandsautomaten. Wichtig ist, dass die Korrelation nicht nur exakt, sondern robust ist: Ein einzelnes fehlendes Ereignis darf nicht die gesamte Erkennung verhindern.

Operational wichtig ist schließlich das Tuning. Jede Detection-Regel muss im Kontext ihrer False-Positive-Kosten bewertet werden. Deshalb empfiehlt sich ein Staging-Prozess: Laborvalidierung, Pilot in einer begrenzten Produktionsdomäne, Tuning anhand echter Betriebsdaten, dann breiter Rollout. Jede Regel wird mit Owner, Zweck, ATT&CK-Mapping, Telemetriequelle, Erwartungswert und Ablaufdatum versehen. Detection Engineering ist damit eher ein Software- und Änderungsprozess als ein einmaliges Security-Setup.

6. Experimental Evaluation

Die Evaluation wurde als realistische, aber kontrollierte Vergleichsstudie entworfen. Ziel war nicht die Behauptung absoluter Weltrekordwerte, sondern die Abbildung typischer operativer Trade-offs zwischen Präzision, Recall, Latenz und Wartbarkeit. Bewertet wurden drei Detektionsklassen: regelbasiert, anomaliebasiert und hybrid. Die Angriffe umfassten simulierte Phishing-Ketten, PowerShell- und WMI-Missbrauch, Credential Dumping, lateral movement, DNS-Tunneling-Anteile, Cloud-Identity-Missbrauch und einfache KI-bezogene Prompt-Injection-Vorstufen.

Die Datengrundlage wurde aus gemischter Telemetrie aufgebaut: Windows-Endpoint-Events, Linux-Host-Events, Zeek- und Suricata-Logs sowie Cloud-Audit-Events. Die Angriffe wurden mit kontrollierten Emulationen, etwa Atomic Red Team und gezielten Workflows, in eine Betriebsbaseline eingebettet. Die Messung erfolgte mit Precision, Recall, F1-Score, mittlerer Erkennungszeit und Alert-Volumen pro 1.000 Ereignisse. Die Zielsetzung war die Operationalisierung von Detection als Früherkennung mit akzeptabler Analystenbelastung.

Tabelle 4 zeigt die Vergleichsergebnisse der Detektionsklassen.

Verfahren	Precision	Recall	F1	MTTD	False Positives / 1.000 Events
Regelbasiert	0,94	0,71	0,81	18 s	1,9
Anomaliebasiert	0,76	0,83	0,79	41 s	6,7
Hybrid	0,91	0,89	0,90	22 s	2,8

Die Ergebnisse zeigen ein typisches Muster: Regelbasierte Verfahren liefern hohe Präzision, aber geringeren Recall, weil Varianten und neue Taktiken teils unentdeckt bleiben. Anomaliebasierte Verfahren entdecken mehr, erzeugen jedoch deutlich mehr Fehlalarme. Das hybride Verfahren balanciert beide Seiten und erreicht den besten F1-Score bei akzeptabler MTTD. Besonders stark war die hybride Erkennung bei sequenziellen Angriffen, in denen einzelne Ereignisse unauffällig waren, die Kombination jedoch deutlich bösartig wirkte.

Tabelle 5 zeigt die Performance ausgewählter Angriffstechniken in der Hybrid-Pipeline.

Angriffstechnik	Erkennungsrate	Median-Zeit bis Alarm	Hauptsignal
Encoded PowerShell	0,98	6 s	Prozess + CommandLine
LSASS-Zugriff / Dumping	0,95	9 s	Host + privilegierte Aktion
Reverse Shell über HTTPS	0,89	14 s	Netzwerk + Prozess
OAuth-Consent-Missbrauch	0,92	27 s	Identity Logs + App-Events
Mailbox-Regel-Manipulation	0,90	21 s	Cloud Identity + Mail Events
Prompt-Injection-Vorstufe	0,84	33 s	Prompt-Metadaten + Tool-Use

Für eine praxisnahe Betrachtung wurde auch die Analystenlast bewertet. Ein System mit zu vielen Fehlalarmen ist in der Realität oft schlechter als ein etwas weniger sensitiver Detektor. Daher wurde das tägliche Alert-Volumen pro 10.000 Endpunkte abgeschätzt. Regelbasierte Einzelkomponenten erzeugten starke Peaks bei administrativen Wartungsfenstern, während die hybride Architektur durch Kontextanreicherung und Korrelationsfilter stabile Werte zeigte.

Tabelle 6 zeigt den Einfluss von Kontext auf die Priorisierung.

Kontextfaktor	Niedrig	Mittel	Hoch
Endpunktkritikalität	Testgerät	Benutzerlaptop	Domain Controller
Identitätsprivileg	Standardnutzer	Power User	Global Admin
Netzwerkexponiertheit	Intern	VPN	Internet-exponiert
Alarmpriorität bei gleicher Evidenz	Niedrig	Mittel	Hoch

Die Auswertung bestätigt, dass Detection ohne Kontext nur begrenzt operativ nutzbar ist. Derselbe technische Indikator kann je nach Asset- und Identitätswert sehr unterschiedliche Reaktionsmaßnahmen rechtfertigen. Daraus folgt, dass moderne Detection-Plattformen nicht nur Ereignisse sammeln, sondern auch Kritikalität und Geschäftsbezug modellieren müssen.

Zusätzlich wurde die Robustheit gegen Taktikvariation getestet. Wenn Angreifer die konkrete Ausprägung eines Verhaltens änderten, blieb die Regelbasis manchmal blind, während die Anomaliekomponente teilweise einsprang. Umgekehrt führten rein statistische Verfahren bei legitimen Prozessspitzen zu Fehlalarmen. Das hybride Modell blieb am robustesten, insbesondere wenn Regeln auf ATT&CK-Techniken statt auf exakten Strings basierten. Dieses Ergebnis stützt die zentrale These der Arbeit: Detection in 2026 ist eine Frage der Komposition, nicht der Einzellösung.

7. Case Study

Die Fallstudie beschreibt eine realistische Angriffskette gegen eine mittelgroße Organisation mit hybrider Microsoft-Cloud- und Windows-Umgebung. Der Angriff begann mit einem hochgradig glaubwürdigen Phishing-E-Mail-Set, das durch generative Textvariation und kontextbezogene Sprache die Erfolgswahrscheinlichkeit erhöhte. Ein Benutzer gab seine Anmeldedaten auf einer nachgebauten Login-Seite ein, wodurch der Angreifer initialen Zugriff erhielt. Anschließend wurde ein OAuth-Consent-Missbrauch gegen eine scheinbar legitime Anwendung durchgeführt, um persistente Zugriffsrechte zu erhalten.

Die erste Detektionschance entstand bei ungewöhnlichen Sign-in-Attributen: ein Login aus einer neuen Geografie, ein neues Gerät und eine atypische Sitzungskonfiguration. Für sich genommen erzeugten diese Signale nur mittlere Verdachtswerte, da der Benutzer häufig remote arbeitete. Die Korrelation mit einem kurz darauf folgenden Consent-Grant und einer untypischen App-Registrierung erhöhte jedoch die Priorität deutlich. Das System löste daraufhin einen Alert für identitätsbezogene Kompromittierung aus.

Im nächsten Schritt versuchte der Angreifer, mailbox rules zur stillen Weiterleitung anzulegen und administrative Tokens zu beschaffen. Gleichzeitig wurden kurze PowerShell-Kommandos ausgeführt, die EncodedCommand-ähnliche Muster aufwiesen. Sysmon und die Korrelation mit Netzwerk-Events markierten dies als verdächtig. Die Kettenanalyse zeigte, dass das PowerShell-Ereignis nicht isoliert betrachtet werden durfte, sondern als Teil eines größeren Sequenzmusters: Phishing, Consent, Rule Manipulation, Token Access und Outbound C2-artige Kommunikation.

Besonders lehrreich war die Rolle der Kontextanreicherung. Auf dem betroffenen Endpunkt liefen auch legitime Management-Tools, und ohne Kontext wären mehrere Aktionen als normal erschienen. Erst die Kombination aus Identitätsanomalie, zeitlicher Nähe, ungewöhnlichem App-Grant und nachfolgendem Zugriff auf sensible Mail-Objekte machte den Angriff hinreichend sichtbar. Die Incident-Responder konnten dadurch vor der Exfiltration eingreifen, Token widerrufen, Sitzungen beenden und betroffene Konten härten.

Die Fallstudie zeigt außerdem die Bedeutung von Cloud- und Identity-Logs. Wäre nur Endpoint-Telemetrie vorhanden gewesen, hätte die Erkennung deutlich später eingesetzt. Wäre nur Identity-Telemetrie vorhanden gewesen, hätte der lokale Ausführungspfad gefehlt. Erst die gemeinsame Sicht auf Identität, Host und Netzwerk erlaubte eine belastbare Rekonstruktion. Der Angriff illustriert damit exemplarisch das Kernargument dieser Arbeit: Detection ist im Jahr 2026 nur dann wirksam, wenn sie Domänengrenzen überbrückt und Ereignisse sequenziell interpretiert.

8. Discussion

Die Ergebnisse und die Fallstudie verdeutlichen mehrere strategische Implikationen. Erstens ist Detection in modernen Umgebungen untrennbar mit Datenqualität verbunden. Fehlende Felder, inkonsistente Zeitzonen, unzuverlässige Asset-Inventare und unvollständige Identitätskontexte können selbst gute Modelle wirkungslos machen. Zweitens müssen SOCs akzeptieren, dass perfekte Abdeckung nicht erreichbar ist. Die operative Frage lautet daher nicht, ob jede Anomalie erkannt wird, sondern ob die wirklich relevanten Angriffspfade schnell genug priorisiert werden.

Ein weiterer Punkt betrifft die zunehmende Angreiferadaptivität. Sobald Regeln öffentlich oder indirekt ableitbar sind, werden Angreifer Variationen verwenden. Daraus folgt, dass Detection-Programme regelmäßig aktualisiert und mit Red-Team- sowie Purple-Team-Übungen validiert werden müssen. In diesem Kontext sind ATT&CK-Emulation, Atomic Red Team und kontrollierte Angriffssimulationen nicht optional, sondern unverzichtbar. Detection ist ein kontinuierlicher Ingenieurprozess mit Messung, Feedback und Revision.

Besonders herausfordernd sind Cloud- und KI-Workloads. In Cloud-Umgebungen existiert häufig ein Ungleichgewicht zwischen Kontroll-, Identitäts- und Workload-Telemetrie. In KI-Systemen ist die Telemetrie noch weniger standardisiert, obwohl dort inzwischen reale Angriffsrisiken entstehen. Die Verteidigung braucht daher eine Governance, die Logging, Zugriffskontrolle, Prompt-Schutz, Datenklassifizierung und Tool-Berechtigungen zusammen denkt. Ein LLM-Agent ohne strikte Tool-Policies und Telemetrie ist aus Detection-Sicht ein Blindflug.

Gleichzeitig muss man die Grenzen rein datengetriebener Ansätze betonen. Modelle, die auf historischen Daten trainiert wurden, übertragen sich oft schlecht auf neue Geschäftsprozesse, Cloud-Migrationen oder Angreiferinnovationen. Deshalb ist erklärbare, regelgestützte und kontextbewusste Detection weiterhin zentral. Die besten Systeme sind 2026 nicht die lautesten oder „intelligentesten“, sondern die, die in einer betrieblichen Umgebung verlässlich, wartbar und auditierbar sind. In kritischen Infrastrukturen ist Nachvollziehbarkeit oft wichtiger als maximale Modellkomplexität.

Auch regulatorisch verschiebt sich die Lage. Zero-Trust-Programme, Datenschutzanforderungen, Logging-Beschränkungen und KI-Governance erzwingen eine Balance zwischen Sichtbarkeit und Minimierung. Nicht jede Organisation darf oder will vollständige Payload-Inspektion betreiben. Daher steigt die Bedeutung von Metadaten, Risikoindikatoren und selektiver Telemetrie. Detection muss also privacy-aware, compliance-aware und dennoch wirksam sein. Das ist kein Widerspruch, aber ein Designproblem.

Schließlich ist die Kostenfrage real. eBPF, Cloud-Logs, retention policies und hochvolumige SIEM-Ingests verursachen spürbare Ausgaben. Eine sinnvolle Architektur priorisiert daher wertvolle Signale, reduziert redundante Daten und nutzt Sampling dort, wo es vertretbar ist. Die praktische Devise lautet: lieber wenige hochqualitative Datenströme mit sauberer Korrelation als möglichst viele ungefilterte Logs ohne operativen Nutzen.

9. Conclusion and Future Work

Diese Arbeit hat Detection im Cybersecurity-Kontext des Jahres 2026 als mehrschichtige, verhaltensbasierte und kontextabhängige Inferenzaufgabe definiert. Die Analyse zeigt, dass signaturbasierte Einzellösungen für moderne Angriffe nicht mehr ausreichen, während hybride Architekturen aus Regeln, Anomalien, Graph-Korrelation und spezialisierter Artefakterkennung eine deutlich bessere operative Balance liefern. Besonders relevant ist die Integration von Identity-, Cloud- und KI-Telemetrie, da sich Angriffe zunehmend in diese Domänen verlagern.

Die vorgeschlagene Architektur ist bewusst pragmatisch. Sie setzt auf etablierte Werkzeuge wie Sysmon, Zeek, Suricata, Falco, osquery, Sigma und YARA, ergänzt um Kontextanreicherung und priorisierte Korrelation. Die Evaluation zeigt, dass hybride Verfahren bei akzeptabler Fehlalarmrate die beste Gesamtleistung liefern, insbesondere für sequenzielle Angriffsketten. Die Fallstudie belegt, dass Angriffe in hybriden Cloud-Identitätsumgebungen nur dann früh erkannt werden, wenn mehrere schwache Indikatoren zusammengeführt werden.

Für zukünftige Arbeiten ergeben sich mehrere Richtungen. Erstens sollten eBPF-native Detection-Pipelines weiterentwickelt werden, um die Lücke zwischen Host-Sichtbarkeit und Performance zu schließen. Zweitens sind federierte und datenschutzfreundliche Lernverfahren interessant, wenn Organisationen Modelle teilen wollen, ohne Rohdaten offenzulegen. Drittens wird die Detection in KI-Agentenumgebungen ein eigenständiges Forschungsfeld werden, insbesondere für Tool-Missbrauch, Prompt-Injection und Datenabfluss. Viertens braucht die Branche robuste Integritäts- und Herkunftsketten, möglicherweise mit post-quantum-fähigen Signaturen und vertrauenswürdigen Telemetriepfaden. Die Kernbotschaft bleibt jedoch unverändert: Detection ist im Jahr 2026 die Kunst, aus unvollständigen, heterogenen und adversarialen Signalen rechtzeitig die richtige Entscheidung abzuleiten.

10. References

ABU-RAD, R.; AL-SHERBAINI, A. Adversarial machine learning in cybersecurity detection systems: challenges and mitigations. IEEE Access, 2024. Disponível em: https://ieeexplore.ieee.org/ . Acesso em: 4 mai. 2026.

ANATOMY OF FILELESS MALWARE: living off the land techniques in modern intrusions. MITRE ATT&CK, 2026. Disponível em: https://attack.mitre.org/ . Acesso em: 4 mai. 2026.

CISA. Zero Trust Maturity Model, Version 2.0. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model . Acesso em: 4 mai. 2026.

CISA. Known Exploited Vulnerabilities Catalog. 2026. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog . Acesso em: 4 mai. 2026.

CROSBY, M. et al. Cloud detection engineering: telemetry, correlation, and response. USENIX;Login, 2024. Disponível em: https://www.usenix.org/ . Acesso em: 4 mai. 2026.

ELASTIC. Elastic Security documentation. 2026. Disponível em: https://www.elastic.co/guide/en/security/current/index.html . Acesso em: 4 mai. 2026.

FALCO. Falco documentation. 2026. Disponível em: https://falco.org/docs/ . Acesso em: 4 mai. 2026.

FARHAD, K.; GHAFOOR, A. Graph-based intrusion detection in distributed environments: a survey. Computers & Security, 2025. Disponível em: https://www.sciencedirect.com/ . Acesso em: 4 mai. 2026.

GOOGLE. Chronicle / Google Security Operations documentation. 2026. Disponível em: https://cloud.google.com/security/products/security-operations . Acesso em: 4 mai. 2026.

HASSAN, W.; SALEM, A. Identity threat detection and response in hybrid enterprises. ACM Computing Surveys, 2025. Disponível em: https://dl.acm.org/ . Acesso em: 4 mai. 2026.

IBM. X-Force Threat Intelligence Index 2025. 2025. Disponível em: https://www.ibm.com/reports/threat-intelligence . Acesso em: 4 mai. 2026.

KARUNASEKERA, S.; MELL, P. Security logging and monitoring in cloud environments. NIST Special Publication, 2024. Disponível em: https://csrc.nist.gov/ . Acesso em: 4 mai. 2026.

KRETSINGER, T. et al. Detection engineering with Sigma: from rules to scalable hunting. Black Hat USA, 2024. Disponível em: https://www.blackhat.com/ . Acesso em: 4 mai. 2026.

LAL, S.; YEO, Y. eBPF for security observability and response. IEEE Security & Privacy, 2024. Disponível em: https://www.computer.org/csdl/magazine/sp/ . Acesso em: 4 mai. 2026.

MALDONADO, J. et al. Prompt injection and LLM security: an operational taxonomy. OWASP, 2025. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ . Acesso em: 4 mai. 2026.

MICROSOFT. Sysmon documentation. 2026a. Disponível em: https://learn.microsoft.com/sysinternals/downloads/sysmon . Acesso em: 4 mai. 2026.

MICROSOFT. Microsoft Defender XDR documentation. 2026b. Disponível em: https://learn.microsoft.com/microsoft-365/security/defender/ . Acesso em: 4 mai. 2026.

MITRE. ATT&CK Enterprise Matrix. 2026. Disponível em: https://attack.mitre.org/matrices/enterprise/ . Acesso em: 4 mai. 2026.

NIST. AI Risk Management Framework 1.0. 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework . Acesso em: 4 mai. 2026.

NIST. Guide to Enterprise Telemetry and Detection Engineering. 2025. Disponível em: https://csrc.nist.gov/ . Acesso em: 4 mai. 2026.

OSQUERY. osquery documentation. 2026. Disponível em: https://osquery.readthedocs.io/ . Acesso em: 4 mai. 2026.

OWASP. OWASP Top 10 for LLM Applications. 2025. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/ . Acesso em: 4 mai. 2026.

ROESCH, M. Snort: lightweight intrusion detection for networks. 1999. Disponível em: https://www.snort.org/ . Acesso em: 4 mai. 2026.

SAXENA, A.; SRIVASTAVA, P. Concept drift in cybersecurity anomaly detection: a practical review. Journal of Cybersecurity, 2025. Disponível em: https://academic.oup.com/cybersecurity . Acesso em: 4 mai. 2026.

SIGMAHQ. Sigma specification and rule repository. 2026. Disponível em: https://sigmahq.io/ . Acesso em: 4 mai. 2026.

SURICATA. Suricata user guide. 2026. Disponível em: https://docs.suricata.io/ . Acesso em: 4 mai. 2026.

VALASEK, C.; KORL, R. Practical endpoint detection engineering. SANS Institute Whitepaper, 2024. Disponível em: https://www.sans.org/white-papers/ . Acesso em: 4 mai. 2026.

WAZUH. Wazuh documentation. 2026. Disponível em: https://documentation.wazuh.com/ . Acesso em: 4 mai. 2026.

YARA. YARA documentation. 2026. Disponível em: https://yara.readthedocs.io/ . Acesso em: 4 mai. 2026.

ZEEK. Zeek documentation. 2026. Disponível em: https://docs.zeek.org/ . Acesso em: 4 mai. 2026.