Microsoft 365 Pentest: Die ultimative Checkliste

Ein Microsoft-365-Pentest untersucht, ob Angreifer durch kompromittierte Benutzerkonten, übermäßige Berechtigungen oder unsichere Freigaben auf geschäftskritische Daten zugreifen könnten. Im Mittelpunkt stehen nicht die Server von Microsoft, sondern die Sicherheitskonfiguration und die erlaubten Angriffspfade innerhalb der eigenen Organisation: Microsoft Entra ID, Exchange Online, SharePoint, OneDrive, Teams und angebundene Anwendungen.

Für IT-Leiter und CISOs ist das eine wichtige Unterscheidung. Denn auch wenn die Cloud-Plattform technisch betrieben und abgesichert wird, bleiben Identitäten, Zugriffsregeln, Freigaben und viele Integrationen in der Verantwortung des Unternehmens. Die folgende Checkliste zeigt, welche sieben Prüfbereiche besonders relevant sind, was ein realistischer Test leisten kann und wie sich ein Microsoft-365-Pentest sinnvoll beauftragen lässt.

Was ist ein Microsoft-365-Pentest?

Ein Microsoft-365-Pentest ist eine autorisierte Sicherheitsprüfung der eigenen Microsoft-365-Umgebung. Er untersucht, ob ein Angreifer innerhalb des vereinbarten Scopes Sicherheitskontrollen umgehen, Berechtigungen missbrauchen oder sensible Informationen erreichen könnte. Dazu gehören kontrollierte technische Nachweise und die Bewertung möglicher Angriffsketten.

Ein Pentest ist nicht gleichbedeutend mit einem Angriff auf Microsofts gemeinsam genutzte Cloud-Infrastruktur. Er unterscheidet sich außerdem von einem reinen Konfigurationsaudit: Ein Audit bewertet Einstellungen gegen Anforderungen und Best Practices; ein Pentest überprüft, wo zulässig und sinnvoll, zusätzlich die praktische Ausnutzbarkeit. In einem guten Projekt ergänzen sich beide Ansätze.

Die ultimative Checkliste: 7 Prüfbereiche für Microsoft 365

1. Identitäten, MFA und Conditional Access

Der Zugang zu Microsoft 365 beginnt bei der Identität. Deshalb werden Anmeldeverfahren, Mehrfaktor-Authentifizierung (MFA), Ausnahmen für bestimmte Konten und die Wirkung von Conditional-Access-Richtlinien geprüft. Eine Richtlinie kann korrekt aussehen und dennoch relevante Benutzer, Geräte oder Anwendungen nicht erfassen.

Besonders wichtig sind privilegierte Konten, Notfallzugänge und Altanwendungen. Bei einem kontrollierten Test wird beispielsweise mit bereitgestellten Testkonten untersucht, ob eine vorgesehene MFA-Anforderung tatsächlich greift. Der Report-only-Modus von Conditional Access unterstützt die Bewertung neuer Regeln, erzwingt sie aber nicht. Die tatsächliche Durchsetzung muss deshalb separat beurteilt werden.

2. Administrative Rollen und Berechtigungsketten

Globale Administratorrechte sind nicht die einzige kritische Berechtigung. Auch spezialisierte Rollen, delegierte Verwaltungsrechte, Gruppenmitgliedschaften und Dienstkonten können weitreichende Auswirkungen haben. Entscheidend ist, ob die Rechte für die jeweilige Aufgabe erforderlich und angemessen begrenzt sind.

Im Pentest wird analysiert, welche Aktionen ein gewöhnlicher Benutzer oder ein weniger privilegiertes Administrationskonto tatsächlich ausführen darf. Wo technisch möglich und ausdrücklich freigegeben, lassen sich Berechtigungsgrenzen mit Testkonten überprüfen. Ziel ist nicht die maximale Zahl an Administratoren zu zählen, sondern riskante Kombinationen und ungewollte Eskalationspfade zu erkennen.

3. OAuth-Anwendungen und Microsoft-Graph-Berechtigungen

Drittanbieter-Apps greifen häufig über OAuth und Microsoft Graph auf E-Mails, Dateien oder Verzeichnisinformationen zu. Dabei ist zwischen delegierten Berechtigungen im Kontext eines Benutzers und Anwendungsberechtigungen ohne angemeldeten Benutzer zu unterscheiden. Beide können erhebliche Reichweite besitzen.

Eine Sicherheitsprüfung untersucht, welche Enterprise Applications registriert sind, welche Zustimmungen erteilt wurden und ob Berechtigungen über das notwendige Maß hinausgehen. Ein häufiger Prüfpunkt ist die Frage, ob eine nicht mehr benötigte Integration weiterhin Zugriff besitzt. Die Microsoft-Dokumentation zur Überprüfung von App-Berechtigungen beschreibt dafür geeignete Verwaltungswege.

4. SharePoint und OneDrive: Externe Freigaben

Dokumente verlassen nicht nur durch Malware das Unternehmen. Auch zu großzügige Freigabelinks, falsch konfigurierte Sites und unübersichtliche Gastberechtigungen können vertrauliche Informationen offenlegen. Besonders kritisch sind Vertragsunterlagen, Personalinformationen, Entwicklungsdokumente und Daten aus regulierten Geschäftsprozessen.

Im Test werden Freigaberegeln, Vererbungen und Zugriffsrechte aus unterschiedlichen Rollenperspektiven betrachtet. Mit eigens angelegten Testdateien kann kontrolliert nachgewiesen werden, ob ein externer oder eingeschränkter Benutzer Inhalte abrufen kann, die für ihn nicht bestimmt sind. Produktive vertrauliche Dokumente müssen dafür nicht massenhaft heruntergeladen werden.

5. Exchange Online: Postfachzugriff und Weiterleitungen

E-Mail ist ein zentraler Kommunikationskanal und damit ein attraktives Angriffsziel. Relevant sind Postfachdelegationen, administrative Zugriffe, Weiterleitungsregeln und die Anbindung von Anwendungen an Exchange Online. Auch veraltete Authentifizierungswege und unzureichend eingeschränkte Servicekonten gehören in die Betrachtung, soweit sie in der jeweiligen Umgebung vorhanden sind.

Ein Pentest kann prüfen, ob die vergebenen Rechte zu den vorgesehenen Rollen passen und ob sich unzulässige Weiterleitungen oder Zugriffe mit Testkonten nachweisen lassen. Ob zusätzlich Phishing-Simulationen oder die Reaktion auf verdächtige Anmeldungen geprüft werden, muss ausdrücklich vereinbart werden.

6. Teams, Gäste und externe Zusammenarbeit

Viele Organisationen arbeiten täglich mit Dienstleistern, Partnern und Kunden in Teams zusammen. Das ist geschäftlich sinnvoll, vergrößert aber die Zahl der Vertrauensbeziehungen. Gastkonten, Team-Mitgliedschaften, Dateifreigaben und externe Kommunikationsrichtlinien sollten deshalb zum Schutzbedarf der jeweiligen Informationen passen.

Die Prüfung betrachtet unter anderem, welche Informationen Gäste tatsächlich sehen, wie lange Berechtigungen bestehen bleiben und ob das Entfernen eines Zugangs alle relevanten Zugriffswege beendet. Auch hier sind definierte Testidentitäten und Testinhalte sinnvoll, um unbeabsichtigte Einsicht in echte Kundendaten zu vermeiden.

7. Protokollierung, Erkennung und Reaktion

Ein Angriff kann trotz guter Prävention erfolgreich sein. Dann ist entscheidend, ob ungewöhnliche Vorgänge erkannt und nachvollzogen werden können. Zu den relevanten Signalen zählen beispielsweise auffällige Anmeldungen, Änderungen privilegierter Rollen, neue App-Zustimmungen oder unerwartete Datenfreigaben.

In einem abgestimmten Szenario lässt sich überprüfen, ob ausgewählte Testereignisse in den vorgesehenen Protokollen erscheinen und ob die Sicherheitsüberwachung angemessen reagiert. Die verfügbaren Funktionen hängen von Lizenzen und Konfiguration ab. Ein solcher Detection-Test sollte daher als eigener Teil des Auftrags definiert werden, statt ihn stillschweigend vorauszusetzen.

Wie sieht ein realistischer Angriffspfad aus?

Stellen Sie sich ein Unternehmen vor, in dem ein Standardkonto kompromittiert wurde. Dieses Konto besitzt selbst keine Administratorrechte. Dennoch kann es möglicherweise auf zu breit freigegebene Dokumente zugreifen oder eine zuvor autorisierte Drittanbieteranwendung mit umfangreichen Rechten nutzen. Aus mehreren einzeln unscheinbaren Berechtigungen kann so ein erheblicher Datenzugriff entstehen.

Das ist ein hypothetisches Prüfszenario, kein Bericht über einen konkreten Kundenfall. Ein guter Pentest untersucht, ob eine solche Kette in der tatsächlich geprüften Umgebung möglich ist. Die Bewertung richtet sich nach nachgewiesenen Berechtigungen, Datenklassen, möglichen Auswirkungen und den wirksamen Schutzkontrollen.

Wie läuft ein Microsoft-365-Pentest ab?

Schritt 1: Scope und Testregeln festlegen

Vorab werden Tenant, betroffene Dienste, Testidentitäten, zulässige Methoden, Ansprechpartner und Abbruchkriterien schriftlich vereinbart. Wichtig: Die Microsoft-Regeln für Penetrationstests müssen beachtet werden. Die Aussage, dass für eigene Azure-Ressourcen keine Vorabgenehmigung nötig ist, darf nicht pauschal auf alle Microsoft-Cloud-Dienste übertragen werden. Tests gegen fremde Tenants, Denial-of-Service-Angriffe und andere untersagte Aktivitäten sind ausgeschlossen.

Schritt 2: Rollen und Konfigurationen erfassen

Je nach Freigabe werden Richtlinien, Rollen, Anwendungen, Freigaben und Protokolle mit möglichst gering privilegierten Lesezugängen untersucht. Für aktive Prüfungen werden getrennte Testkonten und klar begrenzte Testdaten bereitgestellt. Das reduziert Risiken und macht Ergebnisse reproduzierbar.

Schritt 3: Technische Nachweise durchführen

Verdächtige Berechtigungen und Zugriffspfade werden gezielt überprüft. Dabei sollte jeder Nachweis eine konkrete Sicherheitsfrage beantworten. Umfangreiche Datenexporte, unkontrollierte Passwortangriffe oder disruptive Aktionen sind weder erforderlich noch ohne gesonderte Erlaubnis angemessen.

Schritt 4: Risiken priorisieren und nachtesten

Der Bericht dokumentiert geprüfte Bereiche, Einschränkungen, reproduzierbare Findings und umsetzbare Maßnahmen. Nach der Behebung kann ein Retest bestätigen, ob die ursprüngliche Zugriffsmöglichkeit geschlossen wurde. Eine reine Erhöhung des Microsoft Secure Score ersetzt diesen Nachweis nicht: Der Score liefert nützliche Empfehlungen, deckt aber nicht alle Angriffsflächen ab.

Was muss ein Unternehmen vor dem Test vorbereiten?

• Den zu prüfenden Microsoft-365-Tenant und die relevanten Dienste eindeutig benennen.
• Testkonten für Standardbenutzer, Gäste und gegebenenfalls privilegierte Rollen bereitstellen.
• Verantwortliche für Entra ID, Exchange, SharePoint und Teams einbeziehen.
• Den Umgang mit produktiven Daten, Logdateien und kritischen Änderungen festlegen.
• Schriftliche Autorisierung, Microsoft-Regeln und Kommunikationswege abstimmen.

Wie umfangreich der Test wird, hängt unter anderem von der Anzahl der Identitäten, Anwendungen, Rollen, Gastzugänge und gewünschten Angriffsszenarien ab. Informationen zur allgemeinen Kalkulation bietet yatesh unter Penetrationstest-Kosten.

Fazit: Cloud-Sicherheit muss praktisch überprüfbar sein

Ein Microsoft-365-Pentest macht sichtbar, ob Identitäten, Rollen, Anwendungen und Datenfreigaben auch aus Angreifersicht ausreichend geschützt sind. Entscheidend ist nicht die Zahl der Konfigurationsempfehlungen, sondern welche unerlaubten Zugriffe unter realistischen Bedingungen tatsächlich möglich wären.

Sie möchten Ihre Microsoft-365-Umgebung gezielt prüfen lassen? yatesh unterstützt Unternehmen bei der Definition eines sinnvollen Prüfumfangs und der technischen Bewertung relevanter Angriffspfade. Informieren Sie sich über unsere Penetrationstest-Leistungen und sprechen Sie mit uns über Ihre Anforderungen.