Nach einer Phishing-Welle will man irgendwann genau wissen, wer welche Mails aus den Postfächern entfernt hat. Für diese Remediation gibt es in Microsoft Defender for Office 365 seit Oktober 2026 das Feld ApproverUpn, mit dem sich jede einzelne Aktion auditieren lässt. Ich zeige dir, wie ich es in der Praxis nutze.

Das Wichtigste vorweg: In der Erweiterten Suche von Microsoft Defender XDR enthält die Tabelle EmailPostDeliveryEvents jetzt das Feld ApproverUpn. Darin steht, wer eine Remediation-Aktion freigegeben hat, zum Beispiel das Verschieben einer Mail in die Quarantäne nach einer automatisierten Untersuchung. Freigaben kannst du damit belegen, ohne dir Protokolle mühsam von Hand zusammenzusuchen.

Bei Remediation-Freigaben muss klar sein, wer entschieden hat

In vielen kleinen und mittleren Tenants kümmern sich mehrere Leute um den Postfachschutz. Einer löscht im Threat Explorer eine Kampagne, eine Kollegin bestätigt eine Aktion aus der automatisierten Untersuchung und Reaktion (AIR). Kommt es dann zu einem Vorfall oder einer Revision, will jemand wissen, wer wann was entschieden hat.

Bislang ging aus den Daten nur hervor, dass ein Administrator die Aktion ausgelöst hatte. Wer konkret zugestimmt hatte, musste ich auf anderen Wegen herausfinden. Diese Lücke schließt das neue Feld. Aufgeführt ist es in den Neuigkeiten zu Defender for Office 365 für Oktober 2026.

EmailPostDeliveryEvents protokolliert alles nach der Zustellung

In dieser Tabelle landen Aktionen, die erst nach der Zustellung einer Mail stattfinden. Darunter fallen manuelle Remediation und die Zero-hour Auto Purge (ZAP) für Phishing und Schadsoftware. In der Schemadokumentation zur Tabelle sind unter anderem die Felder ActionType, ActionTrigger, ActionResult und DeliveryLocation beschrieben.

ApproverUpn taucht in der Erweiterten Suche auf

Das Feld steht dir in der Erweiterten Suche im Microsoft-Defender-Portal (security.microsoft.com) zur Verfügung. Als ich diesen Artikel geschrieben habe, fehlte es in der Schemaübersicht der Tabellendokumentation noch, obwohl die Neuigkeiten es bereits erwähnten. Deshalb sehe ich im Schema-Reiter meines Tenants nach, ob es dort schon ausgerollt ist.

Aktion, Freigabe und Protokoll greifen ineinander

Am Anfang jeder Remediation steht eine Erkennung, sei es über den Threat Explorer oder eine automatisierte Untersuchung. Danach schlägt das System eine Aktion vor oder führt sie direkt aus. Muss eine Aktion freigegeben werden, bestätigt das ein Administrator im Aktionscenter. Das Ergebnis wird in EmailPostDeliveryEvents geschrieben, und zwar jetzt samt Freigeber.

flowchart LR
    A["Erkennung"] --> B["Untersuchung (AIR)"]
    B --> C["Freigabe durch Admin"]
    C --> D["Aktion auf Mail"]
    D --> E["Eintrag mit ApproverUpn"]

Von der Erkennung bis zum auditierbaren Eintrag in der Erweiterten Suche.

Achte dabei auf den ActionType. Unter „Manual remediation“ fallen sowohl Aktionen im Threat Explorer als auch freigegebene AIR-Aktionen. ZAP-Einträge entstehen hingegen automatisch, eine zustimmende Person gibt es dort schlicht nicht. Wenn du ApproverUpn auswertest, filterst du deshalb am besten gezielt auf manuelle Aktionen.

Plan 1 oder Plan 2 und Zugriff auf die Erweiterte Suche genügen für die Auswertung

Voraussetzung ist Microsoft Defender for Office 365 Plan 1 oder Plan 2 sowie Zugriff auf die Erweiterte Suche. Für reine Abfragen genügt die Rolle „Sicherheitsleseberechtigter“, solange Advanced Hunting für deine Rolle freigeschaltet ist. Wer im Threat Explorer selbst Aktionen ausführen will, braucht weitere Berechtigungen. Welche das sind, steht in der Dokumentation zu automatisierter Untersuchung und Reaktion.

Eine KQL-Abfrage zeigt die Freigaben der letzten 30 Tage

Die folgende Abfrage startest du im Microsoft-Defender-Portal unter Untersuchung und Reaktion → Suche → Erweiterte Suche. KQL wird dort ausdrücklich unterstützt. Ausgegeben werden manuelle Remediation-Aktionen mit dem jeweiligen Freigeber, gezählt pro Person.

EmailPostDeliveryEvents
| where Timestamp > ago(30d)
| where ActionType == "Manual remediation"
| summarize Aktionen = count(),
            Postfaecher = dcount(RecipientEmailAddress),
            LetzteAktion = max(Timestamp)
    by ApproverUpn, Action, ActionResult
| order by Aktionen desc

Meldet die Abfrage einen Fehler bei ApproverUpn, ist das Feld in deinem Tenant noch nicht angekommen. In dem Fall nehme ich die Spalte heraus und versuche es ein paar Tage später noch einmal. Wie die Abfragesprache grundsätzlich funktioniert, erklärt die Übersicht zu Advanced Hunting.

Ein leeres ApproverUpn deutet auf eine automatische Aktion hin

Ist das Feld leer, hat meistens niemand zugestimmt, etwa weil die Aktion automatisch lief. Auch manuelle Einträge, die vor der Einführung des Feldes entstanden sind, bleiben leer.

ApproverUpn allein ersetzt keine vollständige Beweiskette

Das Feld ist nur ein Teil des Nachweises. Für eine lückenlose Beweiskette ziehe ich zusätzlich die Daten zur Mail heran, also etwa NetworkMessageId und DeliveryLocation, und schaue mir den Verlauf im Aktionscenter an.

Tipp: Läuft die Abfrage bei dir stabil, speichere sie im Defender-Portal unter Erweiterte Suche → Abfrage speichern → Als Erkennungsregel erstellen. Dafür brauchst du die Berechtigung, benutzerdefinierte Erkennungen zu verwalten. Fallen dann ungewöhnliche Freigabemuster auf, zum Beispiel viele Freigaben außerhalb der Arbeitszeit, erscheint ein Alarm im Incident-Posteingang.

Die Auswertung gehört in den regulären Sicherheitsbetrieb

Schaut sich niemand die Ergebnisse regelmäßig an, bringt auch die beste Abfrage wenig. Plane die Auswertung deshalb fest ein, zum Beispiel einmal im Monat beim Sicherheitsreview. Wie sich Benachrichtigungen zu Vorfällen auch in kleinen Teams vernünftig steuern lassen, beschreibe ich im Beitrag Defender-XDR-Incident-Benachrichtigungen im kleinen Team.

Dazu kommen die Grundlagen im Postfachschutz. Ist der Impersonation-Schutz ordentlich eingerichtet, fällt weniger manuelle Remediation an. Die nötigen Schritte findest du in meinem Beitrag Impersonation-Schutz in Defender gegen CEO-Fraud einstellen.

Nicht jeder Admin muss Aktionen selbst freigeben

Das ist keine Pflicht. Ich bestimme, welche Rollen Freigaben erteilen dürfen, und halte diesen Personenkreis bewusst klein. Je weniger Leute freigeben, desto mehr sagt ApproverUpn bei der Auswertung aus.

In den nächsten Wochen gehe ich in drei Schritten vor

Zuerst sehe ich im Schema der Erweiterten Suche nach, ob ApproverUpn schon verfügbar ist. Danach lasse ich die Abfrage über die letzten 30 Tage laufen und vergleiche das Ergebnis mit den Vorfällen, die ich kenne. Am Schluss entscheide ich, ob sich eine Erkennungsregel lohnt.

Besonders interessant ist das für Kunden mit Revisionspflicht, denn sie können Freigaben belegen, ohne ein weiteres Werkzeug einzuführen. In kleineren Umgebungen reicht häufig ein monatlicher Blick auf die Daten. Sobald die Spalte in der offiziellen Schemaübersicht auftaucht, passe ich meine gespeicherten Abfragen an.