Eine Untersuchung, die mehr als 25 Millionen Sicherheitsalarme in realen Unternehmensumgebungen umfasste, hat ein strukturelles Problem offengelegt: Fast 1 % der bestätigten Vorfälle ging auf Benachrichtigungen zurück, die ursprünglich als niedrig priorisiert oder rein informativ eingestuft waren. Auf Endpoints lag dieser Wert bei 2 %. Bei einem durchschnittlichen Volumen von 450 000 Alarmen pro Organisation und Jahr bedeutet das rund 54 echte Bedrohungen jährlich – etwa eine pro Woche –, die im traditionellen SOC- oder MDR-Modell nie untersucht werden. Die Daten deuten darauf hin, dass das Problem nicht in der Detektion liegt, sondern in der Ökonomie des Triage-Prozesses: Die Ressourcen der Analysten sind erschöpft, bevor der Strom an Benachrichtigungen abreißt.

Umfang der Untersuchung

Dem Bericht zufolge umfasste der Datensatz Telemetrie von 10 Millionen Endpunkten und Konten, 82 000 Forensik-Untersuchungen mit Analyse des Arbeitsspeichers, 180 Millionen analysierten Dateien sowie Daten zu 7 Millionen IP-Adressen, 3 Millionen Domains und URLs und mehr als 550 000 Phishing-E-Mails. Wichtig ist, dass der ursprüngliche Bericht (2026 AI SOC Report von Intezer) nicht zur unabhängigen Verifizierung vorgelegt wurde. Konkrete Zahlen sollten daher mit dem Vorbehalt ihrer Quelle betrachtet werden.

EDR: trügerisches Sicherheitsgefühl

Die beunruhigendste Erkenntnis betrifft die Zuverlässigkeit von EDR-Lösungen. Von 82 000 Alarmen, die einer forensischen Analyse des Arbeitsspeichers unterzogen wurden, wiesen 2 600 Hosts eine aktive Infektion auf. Gleichzeitig waren, wie berichtet wird, 51 % dieser bestätigten kompromittierten Systeme vom EDR-Anbieter bereits als „behoben“ markiert. De facto blieb also mehr als die Hälfte der realen Infektionen unsichtbar, weil das Schutzwerkzeug das Ticket schloss und die Bedrohung für beseitigt erklärte.

Unter den Malware-Familien, die bei den Speicherscans entdeckt wurden, finden sich:

• Mimikatz – Tool zum Auslesen von Zugangsdaten
• Cobalt Strike – Framework für Post-Exploitation
• Meterpreter – Metasploit-Komponente für Remote-Steuerung
• StrelaStealer – Stealer für Zugangsdaten von E-Mail-Clients

Dabei handelt es sich nicht um experimentelle Samples, sondern um produktiv eingesetzte Werkzeuge in kriminellen und staatlichen Operationen.

Phishing: vertrauenswürdige Plattformen als Waffe

Weniger als 6 % der bestätigten bösartigen Phishing-E-Mails enthielten Anhänge. Die überwältigende Mehrheit basierte auf Links und Social Engineering. Angreifer haben der Untersuchung zufolge ihre Infrastruktur auf Plattformen verlagert, denen standardmäßig vertraut wird: Vercel, CodePen, OneDrive und das Abrechnungssystem von PayPal.

Eine der dokumentierten Kampagnen nutzte die legitime PayPal-Funktion zur Zahlungsanforderung zum Versand von Phishing-E-Mails. Rückrufnummern wurden in den Anmerkungen zur Zahlung platziert, und Unicode-Homoglyphen kamen zum Einsatz, um signaturbasierte Erkennung zu umgehen. Die E-Mail bestand alle Standardprüfungen zur Authentifizierung, da sie tatsächlich von den PayPal-Servern gesendet wurde.

Eine weitere Beobachtung: Webseiten mit Cloudflare Turnstile CAPTCHA korrelierten im analysierten Datensatz deutlich mit Phishing-Seiten, während Google reCAPTCHA eher mit legitimer Infrastruktur assoziiert war. Angreifer nutzen Bot-Schutzmechanismen gezielt, um automatische Sicherheitsscanner zu blockieren.

Vier in den Daten identifizierte Techniken zum Umgehen von E-Mail-Gateways:

1. Payload im Base64-Format, verborgen in SVG-Dateien
2. Links, eingebettet in die Annotations-Metadaten von PDFs, die für oberflächliche Scanner unsichtbar bleiben
3. Dynamisch geladene Phishing-Seiten über legitime, freigegebene OneDrive-Ordner
4. DOCX-Dateien mit archiviertem HTML, das QR-Codes enthält

Cloud-Infrastruktur: stille Fehlkonfigurationen

Bei den Cloud-Alarmen in der Untersuchung lag der Schwerpunkt auf Taktiken zur Umgehung von Erkennung und zur Etablierung von Persistenz in der Umgebung. Laterale Bewegung und Privilegienerweiterung wurden deutlich seltener beobachtet. Angreifer agieren dem Bericht zufolge geduldig: Manipulation von Tokens, Missbrauch legitimer Funktionen von Cloud-Services und Obfuskation, um High-Priority-Detektionen zu vermeiden.

AWS S3 machte rund 70 % aller Verstöße gegen Cloud-Sicherheitsrichtlinien im Datensatz aus. Die Hauptprobleme: Zugriffsverwaltung, Server-Logging und Beschränkung der Interaktion zwischen Accounts. Solche Findings werden in der Regel als niedrig priorisiert eingestuft und erzeugen selten Alarme, sind aber genau die Schwachstellen, die nach dem initialen Zugriff wiederholt ausgenutzt werden.

Praktische Empfehlungen

• Vertrauen Sie dem EDR-Status „mitigated“ nicht ohne Verifizierung. Führen Sie regelmäßige Speicherscans auf kritischen Hosts durch – insbesondere auf solchen, auf denen der EDR eine Bedrohung erkannt und als „mitigated“ markiert hat.
• Überarbeiten Sie die Richtlinie zum Ignorieren von Low-Priority-Alarmen. Stellen Sie Ressourcen für die stichprobenartige Untersuchung informativer Benachrichtigungen bereit, insbesondere auf Endpoints.
• Aktualisieren Sie Ihre Phishing-Filterregeln im Hinblick auf den Missbrauch vertrauenswürdiger Plattformen. Ergänzen Sie Prüfungen von Links zu Vercel, CodePen und OneDrive im Kontext eingehender E-Mails.
• Führen Sie ein Audit der S3-Bucket-Konfigurationen durch mit Fokus auf Zugriffsverwaltung, Logging und Richtlinien für Interaktionen zwischen Accounts. Erhöhen Sie die Priorität dieser Findings in Ihren Vulnerability-Management-Prozessen.
• Schließen Sie den Feedback-Loop: Die Ergebnisse aus der Untersuchung von Low-Priority-Alarmen müssen in die Anpassung der Erkennungsregeln zurückfließen. Ohne diesen Schritt kann sich das System nicht selbst verbessern.

Die zentrale Erkenntnis aus diesen Daten liegt nicht in den konkreten Zahlen (die einer unabhängigen Verifizierung bedürfen), sondern in einem systemischen Muster: Ein Triage-Modell, das auf Kritikalitätsstufen basiert, erzeugt vorhersehbare blinde Flecken – und Angreifer nutzen diese gezielt aus. Ein erster konkreter Schritt ist eine retrospektive Analyse der Alarme, die der EDR in den letzten 90 Tagen als „mitigated“ geschlossen hat, unter Einsatz eines unabhängigen Forensik-Tools zur Überprüfung des Arbeitsspeichers, zumindest auf einer Stichprobe von 5–10 % der Hosts.