Die Protokolle, die Sie zur Untersuchung eines Phishing-Vorfalls benötigen

Früher war Phishing der einfache Alarm. Schlechte Grammatik. Ein Link zu „Amazon.com“. Eine um ein Zeichen falsche Absenderadresse. Analysten machten Witze darüber. Man hatte fast Mitleid mit dem Angreifer.

Diese Ära ist vorbei. KI hat dem ein Ende gesetzt.

Die heutige Phishing-E-Mail ist grammatikalisch einwandfrei, personalisiert mit Daten, die von LinkedIn abgezweigt wurden, wird so getimt, dass sie genau nach dem Fälligkeitsdatum einer echten Rechnung eintrifft, und manchmal folgt ihr eine geklonte Stimme in einem „Rückruf zur Verifizierung“. Die Warnsignale, die wir einer ganzen Generation von Mitarbeitern beigebracht haben zu erkennen – wie Tippfehler, allgemeine Begrüßungen und ungewöhnliche Formatierungen – sind verschwunden, weil der Angreifer dieselben Sprachmodelle verwendet wie Sie.

Prävention konnte hier niemals gewinnen

Security-Awareness-Schulungen sind nach wie vor wichtig. E-Mail-Filterung ist nach wie vor wichtig. Aber seien wir ehrlich, was die Zahlen angeht: Angreifer brauchen nur einen Klick, und KI hat diesen Klick deutlich wahrscheinlicher gemacht. Der alte Plan, Phishing-Angriffe zu 100 % am Gateway zu stoppen, war nie realistisch und wird mit jedem Quartal unrealistischer.

Anstatt zu fragen: „Wie können wir jede Phishing-E-Mail stoppen?“ Wir müssen herausfinden, wie schnell wir ermitteln können, was genau passiert ist, wenn jemand klickt.

Das ist ein Problem der Untersuchung, kein Problem der Prävention, und es steht und fällt damit, ob die richtigen Protokolle vor dem Auftreten des Vorfalls am richtigen Ort vorhanden sind.

Die Protokolle, die wirklich zählen

Nicht alle dieser Punkte treffen auf jede Umgebung zu, aber wenn mehr als einer fehlt, basieren Ihre Phishing-Untersuchungen auf Vermutungen.

• E-Mail-Gateway- und Mail-Flow-Protokolle. Header, SPF/DKIM/DMARC-Ergebnisse, Ergebnisse von Attachment- und URL-Rewrite-Prüfungen sowie Zustellungsstatus. Hier wird überprüft, was der Benutzer tatsächlich erhalten hat, nicht das, was der Screenshot der Sicherheitsschulung suggeriert. Integrationen von Tools wie Abnormal Security, Proofpoint und Gmail-Trace-Protokollen speisen diese Daten alle.
• Identitäts- und Authentifizierungsprotokolle. Genehmigte oder abgelehnte MFA-Aufforderungen, Anmeldungen mit neuen Geräten sowie Entscheidungen zu „unmöglichen Reisen“ und bedingtem Zugriff. Falls es sich bei der Phishing-Kampagne um Credential Harvesting handelte, erfahren Sie hier, ob sie erfolgreich war.
• EDR- und Prozessausführungsprotokolle. Diese zeigen, was nach dem Klick ausgeführt wurde. Achten Sie auf Makroausführung, erzeugte Kindprozesse und jegliche Versuche, eine Domain zu erreichen, die vor einer Woche noch nicht existierte.
• DNS- und Proxy-Protokolle. Konnte der Rechner des Benutzers die schädliche Domain tatsächlich auflösen oder eine Verbindung zu ihr herstellen, oder wurde der Klick vorgelagert abgefangen? Neu registrierte Domains gehören nach wie vor zu den besten Signalen, die Sie haben.
• SaaS- und Mailbox-Audit-Protokolle. OAuth-Zustimmungserteilungen und Änderungen der Postfachregeln sind der stille Teil der Kompromittierung von geschäftlichen E-Mails. Ein Angreifer, der erst einmal eingedrungen ist, benötigt keine Schadsoftware. Er braucht einfach nur eine Weiterleitungsregel, die niemand beobachtet.

Jeder dieser Punkte gibt Ihnen einzeln ein Fragment wieder. Ein E-Mail-Flussprotokoll zeigt an, dass eine Phishing-E-Mail zugestellt wurde. Ein Identitätsprotokoll zeigt Ihnen an, dass sich drei Minuten später jemand von einem neuen Standort aus eingeloggt hat. Keiner von beiden erzählt Ihnen die Geschichte. Zusammen tun sie es.

Fünf Tabs sind keine Untersuchung

Das ist der Teil, den niemand zugeben will: Die meisten Phishing-Untersuchungen verlaufen nicht langsam, weil die Protokolle nicht existieren. Die Bearbeitung ist langsam, weil die Protokolle auf fünf verschiedene Konsolen verteilt sind und Ihr Analyst sie unter Zeitdruck manuell zusammenfügt, während der CISO ein Update anfordert.

Das ist der eigentliche Flaschenhals. Nicht Sichtbarkeit. Korrelationsgeschwindigkeit.

Genau dafür wurde Cloud SIEM entwickelt. Es fasst E-Mail-, Identitäts-, EDR-, DNS- und SaaS-Auditdaten in einer einzigen Zeitleiste zusammen, anstatt sie auf fünf Browser-Tabs zu verteilen. Wenn ein Insight ausgelöst wird, erklärt der Summary Agent in einfacher Sprache, was ihn ausgelöst hat, anstatt einer Wand aus Rohdatenfeldern. Von dort aus kann der SOC Analyst Agent selbstständig Untersuchungen durchführen, die Ergebnisse mit Bedrohungsdaten korrelieren, sie MITRE ATT&CK zuordnen und Ihrem Analysten ein Schweregradurteil mit der bereits gesammelten Beweiskette liefern, nicht eine Blackbox mit der Aussage „Hoher Schweregrad, vertrauen Sie mir.“

Wenn die automatische Überprüfung nicht ausreicht und Ihr Analyst eine konkrete Frage stellen muss, wie zum Beispiel „Wurden für dieses Postfach in den letzten 30 Tagen Weiterleitungsregeln hinzugefügt?“, dann kommt der neue Mobot zum Einsatz. Sie können ihm eine mehrstufige Frage stellen, und es ermittelt, welche Datenquellen abgerufen werden sollen, welcher Zeitraum sinnvoll ist und wertet die Ergebnisse aus, anstatt dass Ihr Analyst manuell zwischen fünf Abfragen wechseln muss.

Letztes Wort

Phishing ist nicht schwieriger zu stoppen geworden, weil die Angreifer schlauer geworden sind. Es wurde schwieriger, sie zu stoppen, weil sie Zugang zu denselben Werkzeugen erhielten wie Sie, und jetzt sind sie einfach schneller als Ihr alter Prozess. Mit Filtern kann man einen LLM nicht übertreffen. Man kann ihn bei der Untersuchung zwar übertreffen, aber nur, wenn die Protokolle bereits vor dem ersten Klick korreliert sind.

Neugierig, wie schnell Ihr Team die Frage „Was geschah nach dem Klick?“ tatsächlich beantworten könnte? Fordern Sie eine Demo von Sumo Logic Cloud SIEM an.