Das Konto ist gesperrt, das Passwort neu, die manipulierte Rechnung gestoppt. Nach einem Phishing-Vorfall ist das der Punkt, an dem im Betrieb die Spannung abfällt und alle zurück an die Arbeit gehen. Security nach einem Phishing-Vorfall besteht aber vor allem aus den zwei Wochen, die jetzt kommen, und für die ist in keinem Terminkalender Platz vorgesehen.
Was in diesen zwei Wochen passiert, sieht meistens gleich aus: Die Geschäftsleitung fragt eine Awareness-Schulung an, und irgendwer bringt ein zusätzliches Werkzeug ins Gespräch. Beides ist vertretbar und beantwortet die Frage nicht, die der Vorfall gestellt hat.
Die wertvollste Arbeit nach einem Phishing-Vorfall ist die Rekonstruktion: wer sich wann von wo angemeldet hat, was im Postfach verändert wurde und wie viele Tage zwischen dem ersten erfolgreichen Zugriff und dem Moment lagen, in dem jemand hingeschaut hat. Die Daten dafür verfallen, und zwar ungleich schnell. Die Anmeldeprotokolle in Microsoft Entra ID halten mit Business Premium 30 Tage, das Überwachungsprotokoll in Microsoft 365 standardmässig 180 Tage. Wer erst zwei Monate später nachsieht, hat die halbe Antwort verloren.
Was solltest du nach einem Phishing-Vorfall zuerst klären?
Zwei Fragen, und keine davon betrifft ein Produkt. Wie lange hatte der Angreifer Zugriff, bevor es jemand bemerkt hat? Und wer hätte es bemerken sollen, womit und in welcher Frist? Die erste Frage beantworten die Protokolle in deinem Tenant, solange sie noch existieren. Die zweite beantwortet eine Zuständigkeit, die in vielen KMU nie jemand vergeben hat.
Die Dauer zwischen dem ersten erfolgreichen Zugriff und der Entdeckung ist die einzige Zahl aus dem Vorfall, die etwas über deinen Betrieb aussagt. Alles andere, wie die Mail aussah, wer geklickt hat, wie gut die Fälschung gemacht war, sagt etwas über den Angreifer aus. Den kannst du nicht beeinflussen, die Dauer schon.
Deshalb lohnt sich die Aufarbeitung in dieser Reihenfolge: erst die Chronologie, dann die Entscheide. Wer mit den Entscheiden anfängt, kauft etwas ein, bevor er weiss, was gefehlt hat.
Die Protokolle in Microsoft 365 haben zwei Verfallsdaten
Microsoft 365 führt zwei getrennte Protokollwelten, und sie halten unterschiedlich lang. In der Hektik nach einem Vorfall geht dieser Unterschied regelmässig unter.
Die Anmeldeprotokolle in Microsoft Entra ID beantworten, wer sich wann von welcher Adresse und mit welchem Client angemeldet hat. Mit Microsoft Entra ID Free bleiben sie sieben Tage verfügbar, mit Entra ID P1 oder P2 dreissig Tage. Microsoft 365 Business Premium enthält Entra ID P1, dein Fenster ist also in der Regel 30 Tage breit. Microsoft dokumentiert die Fristen in der Übersicht zur Datenaufbewahrung in Microsoft Entra, samt dem Hinweis, dass eine Lizenzänderung nicht rückwirkend gilt. Abgelaufene Daten kommen nicht zurück.
Das Überwachungsprotokoll in Microsoft 365 beantwortet die andere Hälfte: welche Postfachregel erstellt wurde, welche Weiterleitung gesetzt, welche Datei heruntergeladen, welche App eine Zustimmung erhalten hat. Microsoft hat die Standardaufbewahrung hier am 17. Oktober 2023 von 90 auf 180 Tage erhöht; längere Fristen hängen an E5-Lizenzen und an eigenen Aufbewahrungsrichtlinien für Überwachungsprotokolle. Dass die Entra-Protokolle und dieses Überwachungsprotokoll zwei verschiedene Systeme mit zwei verschiedenen Fristen sind, hält Microsoft in der Entra-Dokumentation ausdrücklich fest.
Praktisch heisst das: Die Frage, von wo die Anmeldung kam, verfällt zuerst. Die Frage, was im Postfach verändert wurde, lebt länger. Will sechs Wochen nach dem Vorfall jemand wissen, ob der Zugriff aus dem Ausland erfolgte, lautet die Antwort dann nicht mehr nein, sondern: Wir wissen es nicht.
Welche Frage liegt in welchem Protokoll?
Vier Fragen tauchen nach einem Vorfall regelmässig auf, und jede hat ihren eigenen Ort und ihre eigene Frist. Die Übersicht hilft beim Entscheid, was in der ersten Woche gesichert werden muss und was warten kann.
| Frage nach dem Vorfall | Wo die Antwort liegt | Wie lange verfügbar |
|---|---|---|
| Wer hat sich wann von wo angemeldet? | Anmeldeprotokoll in Microsoft Entra ID | 7 Tage mit Entra ID Free, 30 Tage mit P1 oder P2 |
| Wurde die Anmeldung als riskant erkannt? | Bericht zu riskanten Anmeldungen in Entra ID | 30 Tage mit P1, 90 Tage mit P2 |
| Welche Postfachregel, Weiterleitung oder App-Zustimmung kam dazu? | Überwachungsprotokoll in Microsoft 365 | 180 Tage als Standard |
| Wie werden die Spuren länger haltbar? | Archivierung der Entra-Protokolle, eigene Aufbewahrungsrichtlinie im Überwachungsprotokoll | bis zu 10 Jahre, lizenzabhängig |
Die letzte Zeile wirkt unspektakulär und entscheidet am meisten, weil Aufbewahrung eine Entscheidung ist, die vor dem Vorfall getroffen wird. Nach dem Vorfall ist sie nur noch eine Feststellung.
Die Lücke sitzt selten im Werkzeug
In den Vorfällen, die wir aufarbeiten, hatte Defender vorher meistens etwas gemeldet. Eine Anmeldung aus einem untypischen Land oder eine frisch erstellte Postfachregel. Die Warnung lag im Portal. Gelesen hat sie niemand, weil niemand den Auftrag hatte, sie zu lesen.
Das ist kein Vorwurf an den IT-Verantwortlichen. Ein Allrounder in einer Teilzeit-Doppelrolle, der Drucker, Lizenzen, Onboarding und den Serverraum trägt, kann nicht zusätzlich jeden Arbeitstag ein Sicherheitsportal triagieren. Es war nie Teil der Rolle, und im Vertrag mit dem IT-Partner steht dazu meistens keine Frist. Wie dieses Muster entsteht, haben wir im Beitrag zu Defender-Warnungen, die niemand liest, beschrieben.
Ein Phishing-Vorfall ist in den meisten KMU kein Technikversagen. Er ist eine offene Zuständigkeit mit technischer Spur. Darum ändert ein zusätzliches Werkzeug an der Ausgangslage wenig: Es produziert Warnungen in einem zweiten Portal, in das ebenfalls niemand schaut.
Reicht eine Awareness-Schulung nach dem Vorfall nicht?
Eine Schulung senkt die Zahl der Klicks, in unserer Erfahrung deutlich, und ist ihr Geld wert. Sie schliesst die Lücke nicht, die der Vorfall gezeigt hat. Auch in geschulten Betrieben klickt irgendwann jemand, meist unter Zeitdruck und auf eine Mail, die aus dem echten Postfach eines echten Lieferanten kommt. Die offene Frage ist deshalb, wie viele Stunden danach jemand hinschaut.
Wir betreiben ein SOC, lies den Absatz also mit dem entsprechenden Abzug. Der Punkt hält trotzdem: Schulung wirkt auf die Wahrscheinlichkeit, Monitoring wirkt auf die Dauer. Nach einem Vorfall ist die Dauer das, was weh getan hat.
Beides zu beschliessen ist der üblichere und auch der vernünftigere Weg. Die Reihenfolge ist dabei nicht beliebig: Die Schulung verhindert den nächsten Klick vielleicht, das Monitoring begrenzt, was aus ihm folgt.
Ein Beispiel, wie die Woche danach aussieht
Ein Elektroinstallationsbetrieb mit 35 Mitarbeitenden, vollständig auf Microsoft 365 mit Business Premium. Die IT betreut ein interner Allrounder in einer Teilzeit-Doppelrolle, den laufenden Support macht ein externer Partner.
Eine Mail kommt aus dem Postfach eines echten Lieferanten, weil dort vorher jemand Zugriff erhalten hat. Der Link führt auf eine nachgebaute Microsoft-Anmeldeseite. Eine Sachbearbeiterin gibt ihre Zugangsdaten ein und bestätigt die MFA-Abfrage, weil sie sie in diesem Moment erwartet. Danach läuft der Zugriff im eigenen Haus: Eine Postfachregel verschiebt alle Mails mit "Rechnung" und "Zahlung" in einen selten geöffneten Ordner, und aus dem Konto gehen Nachrichten an eigene Kunden mit geänderten Bankdaten. Aufgefallen ist es, als ein Kunde telefonisch nachfragt, warum die Kontonummer gewechselt hat.
Der akute Teil ist an einem Tag erledigt: Konto gesperrt, Sitzungen beendet, Zugangsdaten und MFA neu, Regel entfernt, Kunden informiert. Was in dieser Phase zählt, steht im Beitrag zum kompromittierten Konto in Microsoft 365.
Dann beginnt die Woche danach, und mit ihr die Fragen, die im Haus niemand beantworten kann. Seit wann lief der Zugriff, waren andere Konten betroffen, und wurden Kundendaten aus dem Postfach heruntergeladen? Der IT-Verantwortliche findet die Antworten in den Protokollen, und er findet sie nur, weil er in derselben Woche nachsieht. Das Anmeldeprotokoll zeigt Zugriffe über elf Tage aus einer untypischen Region. Das Überwachungsprotokoll zeigt, dass die Postfachregel am ersten Tag erstellt wurde. Defender hatte die Anmeldung am ersten Tag als riskant markiert; die Warnung stand ungelesen im Portal.
Am Ende hat der Betrieb eine Seite Text: Zeitpunkt des ersten Zugriffs, was der Angreifer berührt hat, Zeitpunkt der Entdeckung, getroffene Massnahmen. Diese Seite ist, was die Versicherung, ein Auditor und die Geschäftsleitung sehen wollen. Sie ist auch der Grund, warum die Diskussion danach nicht mehr um Schulungen kreist, sondern um die elf Tage.
Was kostet es, die Lücke dauerhaft zu schliessen?
Der Einstieg ist ein M365 Tenant Review für CHF 990, der den Ist-Zustand aufnimmt und das Risikolevel bestimmt. Der laufende Betrieb beginnt bei CHF 1'850 pro Monat, risikolevelbasiert, mit 12 Monaten Mindestlaufzeit. Zu Bürozeiten gelten vertragliche Reaktionszeiten: 30 Minuten bei kritischen Vorfällen, 2 Stunden bei hohen, 4 Stunden bei mittleren. Die Preise und Risikolevel stehen auf der Startseite.
Die Vergleichsgrösse ist nicht null. Ein eigener Security-Spezialist kostet einen Jahreslohn und arbeitet trotzdem nur zu Bürozeiten. Ein klassisches 24/7-MDR bringt ein Enterprise-Preismodell für ein Bedürfnis mit, das ein Büro-KMU nicht hat.
Dazu die ehrliche Grenze: Die Automatisierung in Defender und Sentinel läuft rund um die Uhr und unterbricht kritische Angriffe auch um drei Uhr nachts. Unsere Analysten bewerten und reagieren Mo bis Fr von 08:00 bis 17:30. Wenn dein Betrieb rund um die Uhr produziert oder regulatorisch echte Reaktion in der Nacht braucht, ist dieses Modell das falsche. Das sagen wir vor dem Angebot und nicht danach.
Häufige Fragen
Lohnt sich die Aufarbeitung, wenn kein Geld weggekommen ist?
Ja, weil die Zahlung der sichtbare Teil ist und der Zugriff die offene Frage. Eine Postfachregel, eine gesetzte Weiterleitung oder eine erteilte App-Zustimmung überlebt den Passwortwechsel und arbeitet leise weiter. Dazu kommt der praktische Grund: Die Cyberversicherung fragt bei der nächsten Erneuerung nach dem Vorfall, und dann zählt, was dokumentiert ist.
Wer sollte die Chronologie schreiben?
Wer die Protokolle lesen kann und in derselben Woche Zeit dafür hat. Beides trifft im KMU selten auf dieselbe Person zu. Der interne IT-Verantwortliche käme an die Daten, hat aber die Stunden nicht. Der externe Support-Partner hat die Stunden, aber keinen Auftrag für die Aufarbeitung. Deshalb bleibt die Chronologie meistens ungeschrieben, und das ist eine Frage des Auftrags, nicht des Könnens.
Was, wenn der Vorfall ein halbes Jahr zurückliegt?
Dann ist das Fenster für die Anmeldedaten zu und die Frage verschiebt sich von damals auf heute. Steht die Weiterleitung noch, sind alte Sitzungen und App-Zustimmungen weiterhin gültig, und liest heute jemand die Warnungen, die beim nächsten Mal auflaufen? Das lässt sich in jedem Tenant prüfen, unabhängig davon, wie lange der Vorfall her ist.
Wenn bei dir ein Phishing-Vorfall nachhallt und niemand sagen kann, wie lange er gelaufen ist, dann ist die Chronologie der Teil, der noch offen ist. Nachholen lässt sie sich, solange die Daten da sind. Und danach ist die Frage nach der passenden Grösse an Überwachung eine andere, weil sie auf einer Zahl steht statt auf einem Gefühl.