In vielen Microsoft-365-Umgebungen, die ich betreue, stoße ich immer wieder auf dieselben Altlasten: vergessene Test-Tenants, Accounts ohne Multi-Faktor-Authentifizierung und App-Registrierungen mit weitreichenden Berechtigungen, die niemand mehr nutzt. Was Microsoft in den letzten Tagen über den Angriff von Midnight Blizzard auf die eigenen Systeme veröffentlicht hat, wirkt auf mich deshalb überhaupt nicht exotisch – genau so etwas könnte in jedem beliebigen Tenant passieren. Aufschlussreich finde ich vor allem, welche Bausteine die Angreifer kombinierten, um hineinzukommen und ihren Zugriff auszubauen: einen schwachen, nicht mehr überwachten Test-Account ohne MFA, eine alte OAuth-Anwendung mit hohen Exchange-Online-Rechten und das gezielte Ausnutzen von Consent-Mechanismen.

Midnight Blizzard nutzte altbekannte Schwachstellen aus

Die veröffentlichte Beschreibung liest sich wie ein Lehrbuchbeispiel für Schwachstellen, die im Alltag gern übersehen werden. Per Password Spraying übernahmen die Angreifer einen Test-Account, der offenbar außerhalb der Produktivumgebung lag und nicht per MFA geschützt war. Danach griff Midnight Blizzard auf eine bereits vorhandene, veraltete OAuth-App zurück, die in Exchange Online die Berechtigung full_access_as_app besaß. Mit weiteren, neu angelegten bösartigen OAuth-Apps und einem frisch erstellten Benutzer bauten die Angreifer ihren Zugang aus und holten sich zusätzliche Zustimmungen.

Bemerkenswert ist auch, dass sie die klassische IP-basierte Erkennung umgingen, indem sie eine verteilte Proxy-Infrastruktur nutzten. Regeln für „Impossible Travel“ oder GeoIP-Filter laufen damit schnell ins Leere. Alle Details stehen im offiziellen Microsoft Security Blog.

Vergessene Tenants und Schatten-Apps gibt es in fast jeder Cloud

Die zentralen Schwachstellen aus dem Vorfall um Midnight Blizzard und die OAuth-Apps begegnen mir in Kundenprojekten ständig:

  • Alte Test- und Demo-Tenants wartet kaum jemand
  • Einzelne Service- oder Automatisierungs-Accounts sind nicht mit MFA geschützt
  • Bei App-Registrierungen und Unternehmensanwendungen haben Admins den Überblick verloren
  • User Consent ist zu großzügig konfiguriert
  • Credential-Änderungen an Apps überwacht niemand

Gerade „vergessene“ Tenants und Umgebungen, die irgendwann mal zum Testen angelegt wurden, unterschätzen viele. Dort liegen alte App-Registrierungen und Konten mit Standardeinstellungen herum, nicht selten mit schwachen Passwörtern oder ohne MFA – es war ja „nur zu Testzwecken“. Im schlimmsten Fall stecken in diesen Altbereichen noch echte Daten oder Schnittstellen zu produktiven Ressourcen. Wer seine Cloud-Strategie ernst nimmt, muss auch aufräumen können.

Jeder Tenant braucht feste Checks für MFA, App-Inventar und Consent-Regeln

Für mich gehört zu jedem Tenant eine feste Hygieneroutine. Am Anfang steht der konsequente Einsatz von MFA. Für jeden Benutzer sollte das längst selbstverständlich sein, flächendeckend eingerichtet ist es aber noch lange nicht überall. Vor allem bei alten Service-Accounts und Break-Glass-Konten lohnt es sich, noch einmal ins Audit-Log zu schauen. Bei Test- und „Legacy“-Accounts sollte man die Passwortanmeldung spätestens jetzt abschalten oder konsequent mit MFA absichern.

Noch wichtiger ist es, den Wildwuchs bei App-Registrierungen und Berechtigungen einzudämmen. Im Azure-Portal (Entra ID) erkennt man über die Bereiche „App-Registrierungen“ und „Unternehmensanwendungen“ recht gut, welche Anwendungen hohe Berechtigungen haben. Besonders heikel sind Application Permissions wie full_access_as_app in Exchange Online oder globale Leserechte auf das Verzeichnis. Mit PowerShell lassen sich solche Rechte ziemlich schnell aufspüren:

Get-AzureADServicePrincipal -All $true | Where-Object {
  $_.AppRoles -match 'full_access_as_app'
}

In größeren Umgebungen bieten zusätzlich Werkzeuge wie Defender for Cloud Apps ein zentrales App-Governance-Dashboard.

Mein Tipp: Conditional-Access-Richtlinien (siehe auch /blog/conditional-access-entra-id-best-practices), ein restriktiver User Consent und der Admin-Consent-Workflow halten gemeinsam viele Angriffe mit bösartigen Apps ab. Das funktioniert allerdings nur, wenn diese Maßnahmen tatsächlich im ganzen Unternehmen greifen.

User Consent und Admin Consent brauchen klare Regeln

Der Angriff zeigt deutlich, wie leicht sich über User Consent und schlecht überwachte Anwendungen hohe Berechtigungen erschleichen lassen. In vielen Tenants ist der User Consent für Unternehmensanwendungen noch immer zu offen eingestellt. Mindestens sollte man ihn auf geprüfte Berechtigungen und vertrauenswürdige Herausgeber beschränken, wie in der Microsoft-Dokumentation beschrieben. Apps mit hohen Rechten müssen zwingend über den Admin-Consent-Workflow laufen, und auch diesen Workflow sollte man regelmäßig überprüfen.

Das folgende Mermaid-Diagramm zeigt, wie ein sauberer App-Consent-Prozess im Tenant typischerweise ablaufen sollte:

flowchart TD
    User["Benutzer beantragt App Consent"]
    App["OAuth App fordert Rechte an"]
    Consent["Admin Consent Workflow"]
    Admin["Admin prüft & genehmigt"]
    Grant["Rechte erteilt"]
    User --> App --> Consent --> Admin --> Grant

Abbildung: Admin-Consent-Workflow für OAuth-Apps in Entra ID

Bei bestehenden Anwendungen empfehle ich, alle aktiven Consents regelmäßig durchzugehen. Abgelaufene oder nicht mehr genutzte Apps gehören entfernt, ihre Credentials gelöscht oder rotiert.

Bei Erkennung und Monitoring bleibt ein Restrisiko

Ungelöst bleibt die Frage, wie man Angriffe überwacht und erkennt, die wie bei Midnight Blizzard über eine verteilte Proxy-Infrastruktur laufen. Die klassische Geo- oder Impossible-Travel-Erkennung kommt hier an ihre Grenzen. Wer tiefer einsteigen möchte, sucht im Sign-in-Log zum Beispiel nach ungewöhnlichen Consent-Grants, neuen Service Principals oder Credential-Änderungen. In größeren Umgebungen lohnt es sich, ein zentrales SIEM anzubinden oder Defender for Cloud Apps einzusetzen, um Auffälligkeiten bei Consents und Apps zu erkennen.

Für Schatten-IT ist im Tenant kein Platz mehr

Der Vorfall um Midnight Blizzard und die OAuth-Apps erinnert mich wieder daran, dass die größte Schwachstelle nicht immer ein raffinierter Zero-Day ist. Häufig ist es der vergessene Test-Account oder eine übersehene alte App. MFA, kontrollierte Consent-Prozesse und ein aufgeräumtes App-Inventar bilden die Grundlage, laufen aber nicht von allein. Wer hier gründlich nacharbeitet, senkt das Risiko spürbar und sorgt dafür, dass der eigene Tenant Angreifern keine Steilvorlage liefert. Höchste Zeit also für einen Frühjahrsputz in Entra ID, bevor ihn andere übernehmen.