goSecurity BLOG

Selbsterklärend gilt es in einem ersten Schritt alles zu unternehmen, damit Information Security Incidents gar nicht auftreten. Eine 100% Sicherheit gibt es jedoch nie. Ein Lehrer von mir hat mir einmal beigebracht, dass sich der sicherste Windowsrechner in der Arktis unter einer drei Meter dicken Betondecke befindet und weder am Internet noch am Strom angeschlossen ist. Der sicherste Mac übrigens liegt auf dem beschriebenen Windowscomputer

Da wir also nie 100% sicher sein können, muss sich jedes Unternehmen auf die Situation vorbereiten, was zu tun ist, wenn ein Sicherheitsparameter fehlschlägt. In einer solchen Situation gibt es einige Fragen zu klären, damit der Vorfall schnell wieder unter Kontrolle gebracht werden kann. Einige davon wären:

Diese Fragen führen zwangsläufig zu einer weiteren: Wie kann ich diese Fragen beantworten?

Um die Fragen zu beantworten, ist das Loggen aller Aktivitäten sicher ein Anfang, aber es muss auch ein Umgang mit der Flut an Informationen gefunden werden. Microsoft hat im Jahr 2022 auf dieses Problem reagiert und ein Tool geschaffen, mit welchem alle Logs aus den bekannten Microsoft Services Exchange Online, SharePoint Online, EntraID (ehemals: AzureAD), etc. zusammengeführt und intelligent durchsucht werden können. Das Wundertool heisst Microsoft Purview Audit und ist einerseits via Purview Portal (https://purview.microsoft.com/audit/auditsearch), und neu auch via Security Portal (https://security.microsoft.com/auditlogsearch) erreichbar.

Lizenzierung

Zuerst das lästige Thema: Lizenzen. Wie immer bei der Microsoft sind die benötigten Lizenzen ein Mysterium. Was ich bei meinen Recherchen (Juli 2025) gefunden habe, ist die Aussage, dass die Funktion grundsätzlich jeder benutzen kann, der ein Microsoft Service (Exchange Online, SharePoint Online, EntraID (ehemals: AzureAD), etc.) verwendet.

Unterschiede gibt es bei der Aufbewahrung der Logs. Im Standardmodel werden die Logs 180 Tage, früher 90 Tage, gespeichert. Mit folgenden Lizenzen wird die Premium Funktion freigeschaltet, was eine Aufbewahrungszeit von einem Jahr bedeutet (Quelle: https://www.alifconsulting.com/post/microsoft-purview-audit-solution):

• Microsoft 365 Enterprise E5 subscription

• Microsoft 365 E5 Compliance add-on

• Microsoft 365 E5 eDiscovery and Audit add-on

• Microsoft 365 Frontline F5 Compliance or F5 Security & Compliance add-on

• Office 365 Enterprise A5/E5 subscriptions

Dies gilt jedoch gemäss Microsoft (Quelle: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies) nur für bestimmte Services.

Zitat von Microsoft:

“This default policy retains audit records that contain the value of AzureActiveDirectory, Exchange, OneDrive, and SharePoint for the Workload property (which is the service in which the activity occurred). Audit records for all other activities are retained for 180 days by default or you can change the retention to a different duration using a custom retention policy.“

Danke Microsoft für die “Klarstellung” 😆

Bei meinen Tests habe ich mit der Microsoft 365 Business Premium Lizenz gearbeitet, was Ihnen hoffentlich als Information dient.

Aktivierung

In einem ersten Schritt muss Microsoft Purview Audit aktiviert werden, zumindest bei neuen Tenants. Bei unserem Maintenant wurde die Funktion automatisch aktiviert.

Beim Aufrufen des Portals wird man auch mittels blauem Balken “Start Recording user and admin activitiy“ darüber informiert. Über den Balken kann die Funktion direkt aktiviert werden oder Sie verwenden den PowerShell-Befehl dazu:

Die Aktivierung kann einige Zeit in Anspruch nehmen – in meinem Fall musste ich 24h warten. Wichtig zu beachten ist, dass auch wenn die Logs in den Microsoft Services bereits aktiv sind (wie die Audit logs und Sign-in logs im EntraID), können keine Logs vor der Aktivierung von Microsoft Purview Audit mittels dieses Tools durchsucht werden. Daher gilt hier klar unsere Empfehlung: Pausieren Sie das Lesen dieses Blogs und aktivieren Sie das Microsoft Purview Audit, damit Sie ab sofort auf Information Security Incidents vorbereitet sind.

Ob das Microsoft Purview Audit aktiviert ist und ab welchem Zeitpunkt dies geschehen ist, kann mit folgendem PowerShell-Befehl abgerufen werden:

Handhabung

Das Handling einer neuen Suchanfrage ist ziemlich einfach. Es muss ein Zeitrahmen definiert werden, nach der Zeitzone UTC. Im Fall der DACH-Region müssen also je nach Sommer-/Winterzeit 1 bis 2 Stunden dazu abgezogen werden. Bei einem Vorfall in unserer Zeitzone zur Sommerzeit zwischen 13:00 und 14:00 Uhr müsste also zwischen 11:00 und 12:00 Uhr nach UTC durchsucht werden.

Der Zeitraum ist der einzige Pflichtfilter für die Suche. Dabei gibt es die Limite, dass nur eine ungefilterte Suchanfrage auf einmal gemacht werden kann. Wenn die Suchanfrage weiter spezifiziert wird, können bis zu 10 gleichzeitige Anfragen getätigt werden.

Wenn die Anfrage gestartet wurde, resetted sich der Filter (was mich am Anfang in den Wahnsinn getrieben hat) und die Suche wird zur Warteschlange (Queued) hinzugefügt.

In einem zweiten Schritt werden alle Logs durchsucht, da wir keinen Filter gesetzt haben und der Status wird mittels Progressbar angezeigt. Zu diesem Zeitpunkt können die bereits gefundenen Logs schon angezeigt werden.

Wenn die Suche abgeschlossen ist, wird der Status Completed angezeigt und das Hunting kann beginnen. Selbsterklärend gilt natürlich auch hier die Tatsache, dass je mehr Filter gesetzt wurden, desto genauer sind die Ergebnisse. Bei einem Fall bei einem Kunden wussten wir, von welchem Account aus der Incident stattgefunden hat, was die Suche stark vereinfachte.

Allgemein habe ich bis anhin ausschliesslich den Users Filter verwenden, da ich als Beispiel nie den Fall gehabt habe, dass wir genau wussten nach welchen Aktivitäten (Activities – friendly names) in den einzelnen Logs wir suchen müssen. Das einzige was ich noch vermisse, ist ein Filter für die IP-Adresse. Die IP beim Filter “Keyword Search“ mitzugeben, ist keine Lösung, da Tests gezeigt haben, dass dann nicht alle Events angezeigt werden.

Etwas Wichtiges zu beachten bei der Durchsuche ist, dass Microsoft sich auf keine bestimmte Zeit festlegt, ab wann die Logs bei einer Anfrage miteinbezogen werden. Im Schnitt geht Microsoft davon aus, dass diese in den Core-Services (Exchange, SharePoint, OneDrive, and Teams) nach 60 bis 90 Minuten ersichtlich sind. Bei anderen Services kann es länger dauern (Quelle: https://learn.microsoft.com/en-us/purview/audit-search).

Zitat Microsoft:

“For core services (such as Exchange, SharePoint, OneDrive, and Teams), audit record availability is typically 60 to 90 minutes after an event occurs. For other services, audit record availability might be longer. <…SNIP…> For this reason, Microsoft doesn’t commit to a specific time.“

Grundsätzlich führt das in den meisten Fällen zu keinen Problemen, da die Erkennung eines Information Security Incidents meistens mehr als eine Stunde in Anspruch nimmt.

Auswertung

Wenn nun die abgeschlossene Suchanfrage angeklickt wird, erscheint eine Übersicht mit allen Events.

Die einzelnen Events können danach ebenfalls angeklickt werden, um mehr Details zu erhalten.

Dabei muss ich an diesem Punkt klar betonen, dass ich Ihnen in diesem Blog nicht alle Events im Detail erklären kann. Dazu gibt es eindeutig zu viele Services mit zu vielen Eingaben. Aber aus meinen bisherigen Erfahrungen mit Microsoft Purview Audit kann ich sagen, dass aus den Details vieles klar ersichtlich ist. Als Beispiel, auf welchen Ordner im Exchange Postfach hat ein Account zugegriffen oder welche Datei wurde auf SharePoint hochgeladen.

Vorführung

In einem kleinen Beispiel möchte ich Ihnen nun einmal aufzeigen, wie eine Aufarbeitung eines Information Security Incidents aussehen könnte. Dadurch werden vielleicht nicht gleich alle Fragen (Was, Wo, Wann, Wie) beantwortet, aber es sollte eine gute Übersicht geben, was Microsoft Purview Audit kann.

Bei meinem Vorfall hat sich Fritz Lang bei der IT gemeldet, dass auf seinem persönlichen OneDrive ein PDF (Rechnung_Dringend.pdf) hochgeladen wurde, jedoch nicht durch ihn. Gemäss Zeitstempel der Datei ist dies am 14.08.2025 um 12:41 UTC+2 geschehen.

Mit diesen Informationen durchsuchen wir nun also alle Logs vom 14.08.2025, zwischen 05:00 und 13:00 Uhr (Da das Tool nach UTC läuft ist der Zeitraum 03:00 bis 11:00). Dadurch erhoffen wir uns, dass wir eine eventuelle Anmeldung sehen.

In den Events sehen wir eine Anmeldung (User logged in) von einer IP-Adresse (92.107.253.92), welche nicht zum Unternehmen gehört. Nun haben wir den ersten Anhaltspunkt.

Leider sehen wir in Microsoft Purview Audit nicht alle Details zur Anmeldung (z.B. welche Methode für die Anmeldung verwendet wurde). Dies ist jedoch eine relevante Information für die Aufarbeitung des Falls. Hat der Angreifer die Zugangsdaten von Fritz Lang oder hat er den Mitarbeitenden nur dazu bringen können sich anzumelden und ab diesem Punkt arbeitet der Angreifer nur noch mit den Sessioncookies. Ebenfalls eine beliebte Methode der Angreifer ist der Device Code, wie sie mein Kollege Jan Freymuth bereits in einem Blog (https://www.gosecurity.ch/mehrstufige-authentifizierung-umgangen-so-funktioniert-microsoft-device-code-phishing/) beschrieben hat. Um solche Details ausfindig zu machen, muss nun der selbe Event im Sign-In Log von EntraID (Achtung! Name kann wechseln ) gesucht werden. Hier unser Beispiel, wo wir erkennen, dass sich der ungebetene Gast von der IP-Addresse 92.107.253.92 aus mit Anmeldedaten inkl. MFA angemeldet hat.

Ob als Beispiel ein Device Code verwendet wird, ist weiter unten beim Punkt Authentication Protocol ersichtlich.

Nun wissen wir also, wann und von welcher IP aus sich der Angreifer angemeldet hat und dass dieser nicht nur im Besitz der Anmeldedaten von Fritz Lang ist, sondern auch von dessen Mehrfaktor. An diesem Punkt müsste natürlich umgehend das Passwort zurückgesetzt und alle Sessions terminiert werden.

Weiter kann aus den Events ausgelesen werden, wann die Datei hochgeladen wurde.

Und es ist ersichtlich, dass die hochgeladene Datei mittels Link geteilt wurde. Nun ist es natürlich wichtig zu wissen, wer auf die Datei zugegriffen hat, um eine Ausweitung des Angriffes zu verhindern.

Aus den Events ist ersichtlich, dass von der IP-Adresse 91.228.60.2 aus anonym auf die Datei zugegriffen und diese heruntergeladen wurde. In weiteren Schritten müsste nun nachvollzogen werden, wem diese IP gehört, um entsprechend darauf zu reagieren. Aber hier ende ich mit meinem Beispiel, da die Handhabung nun klar sein sollte.

Schlussbemerkung

Abschliessend muss noch gesagt werden, dass bei der ganzen Sache der Datenschutz natürlich nicht ausser Acht gelassen werden darf. Über Microsoft Purview Audit kann jeder Schritt eines jeden Mitarbeitenden nachvollzogen werden, was rechtlich gegenüber den Mitarbeitenden geregelt werden muss. Auch muss klar geregelt sein, wann die IT-Administratoren eine Suche starten und aus welchem Grund, um Missbrauch zu verhindern. Die Suchanfragen selbst werden übrigens auch angezeigt.

Weiter gibt es auch Aspekte, auf welche ich in diesem Blog aufgrund der Länge nicht eingegangen bin. Als Beispiel können mittels Audit retention policies die Aufbewahrung der Events bis zu 10 Jahre erweitert werden, vorausgesetzt es sind die richtigen Lizenzen vorhanden. Dies kann helfen, um mögliche rechtliche Regulationen zu erfüllen.

Ebenfalls können die Events auch mittels PowerShell (Search-UnifiedAuditLog) durchsucht werden, was eine Automatisierung vereinfachen kann (Quelle: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/search-unifiedauditlog?view=exchange-ps). Über PowerShell ist auch ein Filter nach der IP-Adresse möglich, was ich beim GUI vermisse.

Unglücklicherweise werden Anfragen über PowerShell selbst nicht geloggt, somit besteht keine Kontrolle über diese.