Ein Mitarbeiter meldet sich: "Ich glaube, ich habe auf einen falschen Link geklickt." Oder Kunden bekommen plötzlich Rechnungen mit fremder IBAN aus eurem Postfach. Ab diesem Moment zählt nicht, wie es passiert ist – sondern wie schnell ihr den Zugriff beendet und feststellt, was der Angreifer tatsächlich getan hat.
Dieser Leitfaden beschreibt die Schritte in der Reihenfolge, in der sie sinnvoll sind: erst den Zugang schließen, dann Spuren sichern, dann bewerten, ob eine Meldepflicht besteht. Gedacht für kleine Teams ohne eigenes Security-Team – mit den Handgriffen, die im Microsoft-365-Admin-Center und in PowerShell tatsächlich nötig sind.
Warum die erste Stunde über den Schaden entscheidet
Kompromittierte Microsoft-365-Konten werden selten sofort für einen lauten Angriff genutzt. Der typische Ablauf ist leiser: Der Angreifer liest mit, legt eine Weiterleitung an, sucht nach Rechnungen und wartet auf eine passende Gelegenheit. Zwischen Erstzugriff und sichtbarem Schaden liegen oft Wochen.
Das hat zwei Konsequenzen:
- Ein Passwortwechsel allein reicht nicht. Bestehende Sitzungen und Refresh-Tokens bleiben gültig – der Angreifer ist weiterhin drin.
- Der Vorfall ist älter, als er wirkt. Der Zeitpunkt, an dem etwas auffällt, ist fast nie der Zeitpunkt des Erstzugriffs.
Vorab wichtig: Löscht nichts voreilig. Postfachregeln, Anmeldeprotokolle und Nachrichten sind eure Beweismittel – und die Grundlage dafür, ob ihr eine DSGVO-Meldung abgeben müsst. Erst dokumentieren, dann aufräumen.
1. Zugriff beenden: Passwort und Sitzungen
Der erste Handgriff ist immer derselbe: Passwort zurücksetzen und alle aktiven Sitzungen ungültig machen. Der zweite Teil wird häufig vergessen und ist genau der, auf den es ankommt – ein gestohlenes Token funktioniert sonst weiter, obwohl das Passwort längst neu ist.
Im Microsoft 365 Admin Center findet ihr das beim Benutzer unter Zeichen aus allen Sitzungen ab (englisch: Sign out of all sessions). Per Microsoft Graph PowerShell geht es schneller und ist dokumentierbar:
# Verbinden (einmalig Modul installieren: Install-Module Microsoft.Graph)
Connect-MgGraph -Scopes "User.ReadWrite.All","AuditLog.Read.All","Directory.Read.All"
# Alle Refresh-Tokens und Sitzungen des Kontos ungueltig machen
Revoke-MgUserSignInSession -UserId "mitarbeiter@beispielkunde.at"
# Konto voruebergehend sperren, solange die Analyse laeuft
Update-MgUser -UserId "mitarbeiter@beispielkunde.at" -AccountEnabled:$falseDas Sperren ist bewusst als Zwischenschritt gedacht: Solange ihr nicht wisst, was passiert ist, ist ein deaktiviertes Konto sicherer als ein Konto mit neuem Passwort. Für die betroffene Person heißt das ein paar Stunden ohne Zugriff – deutlich billiger als ein zweiter Vorfall am selben Tag.
2. MFA-Methoden prüfen und zurücksetzen
Ein häufiges Muster: Der Angreifer registriert nach dem Erstzugriff eine eigene MFA-Methode – meist eine Authenticator-App oder eine Telefonnummer. Damit kommt er auch nach dem Passwortwechsel wieder hinein, völlig legitim aus Sicht des Systems.
Prüft deshalb in Entra ID unter Benutzer → Authentifizierungsmethoden, welche Methoden hinterlegt sind, und entfernt alles, was die betroffene Person nicht selbst eingerichtet hat. Danach die MFA-Registrierung erneut anfordern.
# Registrierte Authentifizierungsmethoden des Kontos auflisten
Get-MgUserAuthenticationMethod -UserId "mitarbeiter@beispielkunde.at" |
Select-Object Id, AdditionalPropertiesAchtet auf den Zeitstempel: Eine MFA-Methode, die kurz nach dem verdächtigen Anmeldevorgang registriert wurde, ist ein starkes Indiz dafür, dass der Zugriff erfolgreich war – und nicht nur ein Anmeldeversuch.
3. Postfachregeln und Weiterleitungen kontrollieren
Das ist der Klassiker bei Business-E-Mail-Compromise: eine unauffällige Regel, die eingehende Mails mit Stichworten wie "Rechnung", "IBAN" oder "Zahlung" in einen selten benutzten Ordner verschiebt oder als gelesen markiert. Das Opfer sieht die Antworten seiner Kunden nicht mehr, der Angreifer schon.
# Exchange Online verbinden
Connect-ExchangeOnline -UserPrincipalName admin@beispielkunde.at
# Postfachregeln des betroffenen Kontos pruefen
Get-InboxRule -Mailbox "mitarbeiter@beispielkunde.at" |
Select-Object Name, Enabled, Description
# Externe Weiterleitung am Postfach pruefen
Get-Mailbox "mitarbeiter@beispielkunde.at" |
Select-Object ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward
# Organisationsweit: alle Postfaecher mit externer Weiterleitung
Get-Mailbox -ResultSize Unlimited |
Where-Object { $_.ForwardingSmtpAddress -ne $null } |
Select-Object DisplayName, ForwardingSmtpAddressDen letzten Befehl solltet ihr immer mitlaufen lassen, auch wenn nur ein Konto betroffen scheint. Wenn der Angreifer intern weitergegangen ist, findet ihr ihn oft genau hier.
4. Audit-Log auswerten: Was ist tatsächlich passiert?
Jetzt geht es um die Frage, die später zählt: Wurde nur zugegriffen – oder wurden Daten gelesen und heruntergeladen? Die Antwort steht im einheitlichen Überwachungsprotokoll (Microsoft Purview, Audit). Wichtig ist, dass es aktiviert war; ist es das nicht, könnt ihr rückwirkend nichts rekonstruieren.
# Alle protokollierten Aktivitaeten des Kontos im Zeitraum
Search-UnifiedAuditLog `
-StartDate (Get-Date).AddDays(-30) `
-EndDate (Get-Date) `
-UserIds "mitarbeiter@beispielkunde.at" `
-ResultSize 5000 |
Export-Csv . orfall-audit.csv -NoTypeInformation -Encoding UTF8
# Gezielt: Zugriffe auf Dateien in SharePoint/OneDrive
Search-UnifiedAuditLog `
-StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
-UserIds "mitarbeiter@beispielkunde.at" `
-Operations FileDownloaded,FileAccessed,FileSyncDownloadedFullParallel dazu die Anmeldeprotokolle in Entra ID: Von welchen IP-Adressen und Ländern kamen erfolgreiche Anmeldungen? Ein erfolgreicher Login aus einem Land, in dem ihr keine Standorte habt, grenzt den Zeitraum meist sauber ein. Exportiert die Ergebnisse – die CSV ist eure Dokumentation.
5. App-Registrierungen und OAuth-Zustimmungen prüfen
Der unangenehmste Fall: Der Angreifer braucht das Konto gar nicht mehr, weil er sich per OAuth-Zustimmung dauerhaften Zugriff verschafft hat. Die betroffene Person hat dabei eine harmlos aussehende Anwendung bestätigt, die anschließend Mails lesen darf – unabhängig von Passwort und MFA.
Schaut in Entra ID unter Unternehmensanwendungen nach kürzlich hinzugekommenen Einträgen und prüft deren Berechtigungen. Alles, was ihr nicht zuordnen könnt und was Postfach- oder Dateizugriff verlangt, gehört entfernt.
Praxishinweis: Wenn eine solche Zustimmung existiert, reicht das Zurücksetzen des Kontos nicht. Erst das Entfernen der Anwendung beendet den Zugriff wirklich.
6. Datenabfluss bewerten und Meldepflicht klären
Sobald klar ist, worauf zugegriffen wurde, wird es eine rechtliche Frage. Nach Art. 33 DSGVO muss eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde binnen 72 Stunden gemeldet werden, sofern ein Risiko für die Betroffenen besteht. In Österreich ist das die Datenschutzbehörde. Bei hohem Risiko kommt nach Art. 34 zusätzlich die Information der Betroffenen dazu.
Für die Einschätzung braucht ihr drei Angaben, die aus den vorherigen Schritten kommen:
- Zeitraum des unberechtigten Zugriffs (Anmeldeprotokolle)
- Umfang: welche Postfächer, Dateien, Ordner (Audit-Log)
- Datenkategorien: waren personenbezogene oder besonders schützenswerte Daten dabei?
Die 72 Stunden laufen ab Kenntnis des Vorfalls, nicht ab dessen Abschluss. Eine Meldung mit noch unvollständigem Sachverhalt und Nachreichung ist ausdrücklich vorgesehen – zu spät melden ist das größere Problem. Ob im konkreten Fall eine Meldepflicht besteht, gehört mit eurem Datenschutzbeauftragten oder juristischer Beratung geklärt; dieser Artikel ersetzt das nicht.
7. Aufräumen und kontrolliert wieder öffnen
Erst wenn die Analyse steht, wird bereinigt und das Konto wieder freigegeben:
- Fremde Postfachregeln und Weiterleitungen entfernen – nachdem sie dokumentiert sind
- Unbekannte OAuth-Anwendungen und App-Kennwörter löschen
- MFA neu registrieren lassen, idealerweise am Gerät und im Beisein der Person
- Prüfen, ob dasselbe Passwort anderswo verwendet wurde – Passwortwechsel dort ebenfalls
- Delegierte Postfachzugriffe und Kalenderfreigaben kontrollieren
- Kunden und Partner informieren, wenn aus dem Postfach heraus geschrieben wurde
Den letzten Punkt lassen viele aus, weil er unangenehm ist. Er ist trotzdem richtig: Wenn im Namen eures Betriebs gefälschte Rechnungen verschickt wurden, erfahren es eure Kunden ohnehin – besser von euch.
Was danach dauerhaft anders laufen sollte
Ein Vorfall ist der einzige Zeitpunkt, an dem Security-Maßnahmen intern unstrittig sind. Diese Gelegenheit sollte man nutzen:
- MFA für alle Konten, ohne Ausnahme für Geschäftsführung oder Servicekonten. Phishing-resistente Verfahren wie FIDO2-Schlüssel sind der deutlich stärkere Schritt gegenüber SMS-Codes.
- Legacy-Authentifizierung blockieren – alte Protokolle wie IMAP oder POP umgehen MFA vollständig.
- Conditional Access mit Länder- und Geräteeinschränkungen, wo es zum Betrieb passt.
- Externe Weiterleitungen unterbinden oder zumindest zentral melden lassen.
- Audit-Log aktiviert lassen und die Aufbewahrungsdauer prüfen. Ohne Protokoll gibt es keine Analyse.
- Vorgehen aufschreiben, solange es frisch ist: Wer wird informiert, wer sperrt Konten, wer entscheidet über die Meldung.
Wie ein solcher Ablaufplan konkret aussieht, habe ich in Incident Response für kleine IT-Teams beschrieben. Zur allgemeinen Absicherung von Microsoft 365 passt außerdem die IT-Betreuung für KMU.
Fazit
Die Reihenfolge ist entscheidender als das Tempo: Sitzungen beenden, bevor ihr das Passwort ändert. Dokumentieren, bevor ihr aufräumt. Bewerten, bevor ihr entwarnt. Wer diese vier Schritte in der richtigen Reihenfolge geht, hat den Vorfall meist an einem Vormittag im Griff.
Was danach bleibt, ist die unangenehmere Frage: Warum hat es funktioniert? In den allermeisten Fällen lautet die Antwort fehlende oder umgehbare MFA. Das lässt sich an einem Nachmittag ändern – und verhindert die Wiederholung zuverlässiger als jede Awareness-Schulung.
Ich unterstütze KMU in Oberösterreich und im DACH-Raum bei IT-Automatisierung, Infrastruktur und pragmatischer IT-Betreuung — praxisnah und DSGVO-konform.