Phishing-Vorfall: Playbook für die Erstreaktion

Ein Phishing-Vorfall ist der häufigste Vorfall, den ein Blue Team bearbeitet, und derjenige mit der größten Spannweite: von der gemeldeten Mail, die niemand geöffnet hat, bis zum Konto, mit dem der Angreifer seit drei Tagen die Rechnungen der Firma umleitet. Das Playbook muss beides abdecken, und es muss in den ersten dreißig Minuten die richtige Abzweigung nehmen. Dieser Beitrag beschreibt die Erstreaktion in drei Fällen, die Kampagnensicht, die aus einer Meldung eine Welle macht, und eine Checkliste, die sich ausdrucken lässt.

Drei Ausgänge, ein Playbook

Die erste Frage an den Meldenden entscheidet über alles Weitere: Hast du etwas angeklickt, geöffnet oder eingegeben? Daraus ergeben sich drei Fälle mit sehr unterschiedlichem Aufwand. Fall A: gemeldet, nicht interagiert. Fall B: Anhang geöffnet oder Link geklickt, aber keine Zugangsdaten eingegeben. Fall C: Zugangsdaten auf einer gefälschten Seite eingegeben oder eine MFA-Anfrage bestätigt, die man nicht selbst ausgelöst hat. Fall C ist kein Phishing-Vorfall mehr, sondern ein kompromittiertes Konto, und wird auch so behandelt. Alle drei beginnen mit demselben Schritt.

Schritt 0: Die Meldung richtig entgegennehmen

Die Mail wird nicht weitergeleitet, sondern als Anhang übermittelt oder über den Melde-Button des Mailsystems eingereicht; beim Weiterleiten gehen die Kopfzeilen verloren, aus denen Absenderweg und Authentifizierungsergebnis hervorgehen. Der Meldende beantwortet drei Fragen: Wann kam die Mail, was hast du damit gemacht, und wer hat sie noch bekommen, soweit bekannt? Der Zeitpunkt der Meldung wird notiert, und der Meldende bekommt sofort eine Rückmeldung, dass die Meldung richtig war. Diese Rückmeldung ist keine Höflichkeit, sondern der Grund, warum die nächste Mail auch gemeldet wird. Wie ein Meldeweg gebaut sein muss, damit er benutzt wird, steht im eigenen Beitrag.

Fall A: Gemeldet, nicht interagiert

1. Analysieren. Kopfzeilen: Absenderdomain, Return-Path, SPF-, DKIM- und DMARC-Ergebnis, sendende Infrastruktur. Inhalt: Links (per Hover oder in einer isolierten Umgebung, nie direkt), Anhänge (Hash prüfen, in der Sandbox öffnen), Vorwand (Rechnung, Paket, Passwort abgelaufen, Chef braucht dringend Gutscheine).
2. Kampagne suchen. Im Mail-Gateway nach Absender, Betreff, Link-Domain und Anhang-Hash suchen. Eine gemeldete Mail ist fast nie die einzige.
3. Entfernen und blockieren. Alle Exemplare aus den Postfächern löschen, bevor jemand anderes klickt. Absender, Domain und Link-Ziel im Gateway, Web-Filter und DNS-Filter sperren.
4. Klicks prüfen. Wenn das Gateway Links umschreibt, zeigen seine Logs, wer geklickt hat. Jeder Klick wird zu Fall B, jede Anmeldung zu Fall C.
5. Dokumentieren. Indikatoren in die eigene Threat-Intelligence-Ablage, Ticket schließen, Meldenden informieren.

Fall B: Anhang geöffnet oder Link geklickt

Der Endpunkt steht jetzt im Mittelpunkt. Wenn das EDR bereits einen Alarm gemeldet hat, wird das Gerät isoliert, bevor irgendetwas anderes passiert. Wenn nicht, wird geprüft, was nach dem Klick geschehen ist: die Prozesskette ab dem Mailclient oder Browser, Dateien, die im Zeitraum entstanden sind, ausgehende Verbindungen des Geräts, neue geplante Aufgaben oder Autostart-Einträge. Sysmon Event 1 und 3 und die Windows-Ereignisse 4688 und 4698 liefern die Antworten. Ein Office-Dokument, das eine PowerShell gestartet hat, oder ein Download, der ausgeführt wurde, macht aus dem Klick einen Schadsoftware-Vorfall: Gerät isolieren, Zugangsdaten des Benutzers vorsorglich zurücksetzen, Gerät neu aufsetzen statt bereinigen, Persistenz im Netz prüfen, und ab hier gilt der Incident-Response-Prozess mit Beweissicherung. Ein Link, der nur auf eine inzwischen abgeschaltete Seite führte, ohne Download und ohne Eingabe, bleibt Fall B mit einem Eintrag im Ticket.

Fall C: Zugangsdaten eingegeben

Ab jetzt gilt das Konto als übernommen, bis das Gegenteil bewiesen ist, und zwar auch dann, wenn MFA aktiv war: Moderne Phishing-Seiten schalten sich als Proxy zwischen Benutzer und echtem Login und stehlen das Sitzungstoken nach erfolgreicher MFA; wie sich dieser AiTM-Token-Diebstahl erkennen lässt, steht im eigenen Beitrag. Steckt der Link in einem QR-Code statt im Text, ist es Quishing. Die Reihenfolge ist entscheidend, weil ein Passwort-Reset allein den Angreifer nicht aussperrt.

1. Sitzungen widerrufen und Anmeldung sperren. Alle aktiven Sitzungen und Token des Kontos ungültig machen, Anmeldung vorübergehend blockieren. Das wirft den Angreifer hinaus, auch wenn er ein gültiges Token hat.
2. Passwort zurücksetzen. Durch den Administrator, nicht durch den Benutzer, und nicht über den Kanal, den der Angreifer mitlesen könnte.
3. MFA-Methoden prüfen. Angreifer registrieren eine eigene Authenticator-App oder Telefonnummer als Hintertür. Alles entfernen, was der Benutzer nicht kennt, und die Registrierung neu durchführen.
4. Postfachregeln und Weiterleitungen. Der Klassiker: eine Regel, die Antworten der Bank oder des Chefs in einen unauffälligen Ordner verschiebt oder an eine externe Adresse weiterleitet. Alle Regeln und Weiterleitungen prüfen, verdächtige löschen, Screenshots als Beweis.
5. App-Berechtigungen und Delegationen. Vom Konto erteilte Zustimmungen für Drittanwendungen, Postfach-Delegationen und neu registrierte Geräte prüfen. Jede davon ist ein Weg zurück, der einen Passwortwechsel überlebt.
6. Anmeldeprotokolle auswerten. Seit wann, von wo, mit welchem Gerät hat sich der Angreifer angemeldet? Auf welche Dateien, Ordner und Teams-Chats wurde zugegriffen? Das ist der Umfang des Vorfalls und die Grundlage für die Frage, ob personenbezogene Daten betroffen sind und die Meldepflichten greifen.
7. Gesendete Elemente prüfen. Hat der Angreifer vom Konto aus Mails verschickt? Dann sind die Empfänger zu warnen, intern wie extern, und aus einem Vorfall werden mehrere Meldungen.
8. Zahlungsbezug klären. Wenn das Konto Rechnungen, Bankverbindungen oder Zahlungsfreigaben berührt, sofort die Buchhaltung informieren und die letzten Tage auf geänderte Bankverbindungen prüfen. Business Email Compromise ist die Variante, die richtig Geld kostet. Kommt die Anweisung nicht per Mail, sondern als Anruf mit vertrauter Stimme, ist es Deepfake-Vishing.

Microsoft beschreibt für Microsoft-365-Umgebungen in einer eigenen Anleitung zum Umgang mit kompromittierten E-Mail-Konten dieselben Schritte mit den konkreten Stellen im Portal und den Warnzeichen, an denen sich ein übernommenes Postfach erkennen lässt. Für andere Plattformen gelten die Schritte sinngemäß.

Die Kampagnensicht

Der Fehler, der aus einer beherrschbaren Meldung einen großen Vorfall macht, ist die Einzelfallbearbeitung. Eine Phishing-Welle trifft dreißig Postfächer, einer meldet, drei klicken, einer gibt Zugangsdaten ein. Wer nur die Meldung bearbeitet, findet den einen, der eingegeben hat, drei Wochen später über die umgeleitete Rechnung. Deshalb gehört in jedes Playbook die Kampagnensuche: Gateway-Logs nach Absender, Betreff-Mustern, Link-Domain und Anhang-Hash im SIEM durchsuchen, Empfängerliste ziehen, Klicks aus der Link-Umschreibung auswerten, Anmeldeprotokolle aller Empfänger für den Zeitraum nach Zustellung prüfen. Aus der Liste ergibt sich, wer Fall A, B oder C ist, und die Belegschaft bekommt eine kurze Warnung mit Betreff und Vorwand, ohne den Link.

Die Checkliste

1. Meldung mit Kopfzeilen sichern, Zeitpunkt notieren, Meldenden fragen: geklickt, geöffnet, eingegeben?
2. Mail analysieren, Indikatoren extrahieren.
3. Kampagne im Gateway suchen, alle Exemplare entfernen, Indikatoren sperren.
4. Klicks und Anmeldungen aller Empfänger prüfen, Fälle B und C identifizieren.
5. Fall B: Endpunkt prüfen, bei Ausführung isolieren und in den IR-Prozess übergeben.
6. Fall C: Sitzungen widerrufen, Passwort, MFA, Regeln, Berechtigungen, Protokolle, gesendete Mails, Zahlungsbezug.
7. Meldepflichten prüfen, Betroffene und Empfänger informieren.
8. Belegschaft warnen, Meldenden loben, dokumentieren.

Nachbereitung

Zwei Fragen nach jedem Phishing-Vorfall. Warum kam die Mail durch das Gateway? Fehlende Authentifizierungsprüfung, eine zu weiche Regel, ein neu registrierter Absender, den der Filter noch nicht kannte: die Antwort wird zur Regel. Wie SPF, DKIM und DMARC das Vortäuschen der Absenderdomain unterbinden, steht im eigenen Beitrag. Und warum hat der Klick funktioniert? Nicht als Vorwurf an den Benutzer, sondern als Frage an die Kontrollen: Makros erlaubt, kein Link-Umschreiben, MFA ohne Phishing-Resistenz. In der Cyber Kill Chain ist Phishing die Delivery-Phase, und jede Antwort auf diese Fragen bricht die Kette beim nächsten Mal früher. Die Kennzahlen dafür sind die Meldequote, also der Anteil der Empfänger, die gemeldet haben, und die Klickquote. Steigt die erste und sinkt die zweite, funktioniert das Zusammenspiel von Technik und Belegschaft.

Fazit

Ein Phishing-Vorfall wird in den ersten dreißig Minuten entschieden: durch die Frage, ob interagiert wurde, durch die Kampagnensuche, die aus einer Meldung alle Betroffenen macht, und im Fall C durch die richtige Reihenfolge, bei der Sitzungen vor dem Passwort und Postfachregeln vor der Entwarnung kommen. Wer dieses Playbook als Anhang seines Incident-Response-Plans hat und die Kampagnensuche im SIEM vorbereitet, verwandelt den häufigsten Vorfall des Blue Teams in Routine.