Stand: 18. Oktober 2026.

Mitte Oktober machte in der Admin-Community eine Nachricht die Runde: Angreifer hatten sich in über 300 Microsoft-365-Tenants angemeldet. Ohne gestohlenes Passwort, ohne MFA-Prompt und ohne dass eine einzige Conditional-Access-Policy angeschlagen hätte. Sie mussten kein Benutzerkonto kapern. Stattdessen hatten sie das Credential einer App, der die Betroffenen selbst Zugriff auf ihre Postfächer und Dateien gegeben hatten.

Der Vorfall zeigt etwas Unbequemes: Wir haben viel Aufwand investiert, die Anmeldung von Benutzern abzusichern und ihre Berechtigungen sauber zu halten. Mit den Apps, die wir im Tenant registrieren, reißen wir das alles wieder ein.

Ein Credential, über 300 Tenants

Die ausgenutzte App ist ConnectWise Cloud Backup, früher SkyKick, ein Backup-Dienst für Microsoft 365. Damit er sichern kann, hat er in jedem Kunden-Tenant weitreichende Rechte. Der Sicherheitsanbieter Todyl, der den Vorfall bei seinen Kunden untersucht hat, beschreibt sie als tenantweiten Lese- und Schreibzugriff auf Mails, OneDrive- und SharePoint-Dateien und Teams-Chats.

Das Backup meldet sich dabei nicht als Benutzer an, sondern als Enterprise App im Tenant, mit einem Credential des Herstellers. Da tippt niemand ein Passwort, kein Smartphone fragt nach einem zweiten Faktor und keine Gerätekonformität wird geprüft. Genau so haben sich auch die Angreifer angemeldet: als die App selbst. Deshalb griffen MFA und Conditional Access für Benutzer schlicht nicht. Der IT-Sicherheitsdienstleister Huntress zählte bis zum 17. Oktober fast 1.000 Tenants mit solchen Anmeldeversuchen, in über 300 davon waren sie erfolgreich.

Die betroffenen Organisationen trifft keine Schuld. Das Credential ist mutmaßlich beim Hersteller ConnectWise abhandengekommen, nicht durch einen Fehler auf ihrer Seite. Es liegt im Tenant des Herstellers, kein Kunde hätte es schützen können. ConnectWise hat die missbrauchten App-Identitäten inzwischen deaktiviert und den Dienst ausgesetzt.

Ein Drucker mit Generalschlüssel

Neu ist das alles nicht. Eigentlich kennen wir das Problem, wir haben nur alle die Augen davor verschlossen. Ich auch. Mir hat es ausgerechnet ein Drucker vorgeführt.

Ich habe einen neuen Drucker eingerichtet. Scans per SMTP mit Basic Auth kamen nicht mehr in Frage, weil Microsoft das Verfahren als unsicher abkündigt: Ende Dezember 2026 schaltet Microsoft es in bestehenden Tenants standardmäßig ab. Der Druckerhersteller hatte eine Lösung: Ich registrierte seine Enterprise App in meinem Tenant. Die forderte unter anderem zwei Anwendungsberechtigungen an, Mail.Send und Mail.ReadWrite. Ich stimmte zu, der Drucker scannte wieder.

Was ich da freigegeben habe, steht in der Microsoft-Doku. Mail.Send heißt dort Send mail as any user: Die App darf ohne angemeldeten Benutzer als jede beliebige Adresse im Tenant Mails verschicken. Das ist schlimm genug. Mail.ReadWrite ist viel gefährlicher. Die App darf damit Mails in allen Postfächern lesen, ändern, löschen und neue anlegen. Mail.Send ist ein Postbote, der in deinem Namen Briefe verschickt. Mail.ReadWrite ist ein Postbote, der jeden Brief in jedem Briefkasten öffnen, lesen, umschreiben und wegwerfen darf, Verträge, Rechnungen und Passwort-Reset-Links inklusive. Und er darf Briefe hineinlegen, die nie jemand geschickt hat.

Ich habe ein Security-Problem gelöst und ein viel größeres geschaffen. Für ein paar Scans hätte ein einziges Postfach gereicht.

Least Privilege endet am Zustimmen-Button

Bei Benutzern sind wir längst anders unterwegs. Rechte gibt es nur bei Bedarf und nur so viele wie nötig. Admin-Rollen aktiviert man über PIM auf Zeit, Zugriffe kommen regelmäßig in Access Reviews auf den Prüfstand. Über Authentifizierung denken wir in Phishing-Resistance, Gerätekonformität und Standorten nach. Wer einem Benutzer Vollzugriff auf alle Postfächer geben wollte, müsste das sehr gut begründen.

Auf Apps überträgt sich davon fast nichts. Eine Anwendungsberechtigung gilt ab dem Klick auf Zustimmen für den ganzen Tenant, bis jemand sie wieder entzieht. Es gibt keine Aktivierung auf Zeit und keinen zweiten Faktor. Ablaufen kann höchstens das Secret der App, die Berechtigung bleibt. Und die Werkzeuge, die es gibt, nutzen die wenigsten. Wer grenzt Mail.Send wirklich auf ein Postfach ein? Ich wusste lange Zeit nicht einmal, dass das geht, obwohl Microsoft die Funktion seit Ende 2022 anbietet. Und wer setzt Conditional Access für Workload Identities tatsächlich ein?

Wohin das führt, zeigt der Backup-Fall. Todyl fand unter den angegriffenen Tenants neun, die gar kein aktives Backup-Abo mehr hatten. Die App hatte dort keinen Zweck mehr, aber noch alle Rechte. Die Angreifer bekamen auch dort ein Token. Ein Benutzerkonto, das seit Monaten niemand braucht, hätte das nächste Access Review nicht überlebt.

Was hilft und wo es aufhört

Ganz ohne Werkzeuge stehen wir bei Apps nicht da. Es sind nur weniger als bei Benutzern, sie setzen an anderen Stellen an und jedes hat eine harte Grenze. Vier davon tragen, in dieser Reihenfolge.

Ausmisten, was niemand mehr braucht

Was du nicht mehr brauchst, räumst du weg. Das kostet nichts. In den neun Tenants ohne Backup-Abo hätte es den Angreifern die Tür verschlossen. Eine App, die nicht mehr im Tenant ist, kann niemand missbrauchen und du musst sie nie wieder prüfen. Welche Apps sich überhaupt noch anmelden, zeigt der Bericht Service principal sign-in activity unter Usage & insights, mit Entra ID P1 oder P2.

Leichter wird das Aufräumen, seit sich Apps deaktivieren lassen. Eine deaktivierte App bekommt keine neuen Tokens mehr, Konfiguration und Berechtigungen bleiben aber erhalten. Meldet sich niemand, löschst du sie später. Beschwert sich jemand, ist sie mit einem Klick zurück. Das gilt für Apps, die in deinem eigenen Tenant registriert sind. Bei Hersteller-Apps wie dem Backup-Dienst deaktivierst du stattdessen die Anmeldung der Enterprise App in deinem Tenant.

Für neue Apps gilt dasselbe, nur früher. Benutzern die Zustimmung zu Apps zu verbieten, ist sehr sinnvoll. Gegen Anwendungsberechtigungen wie beim Drucker hilft es aber nicht, denn die kann ohnehin nur ein Admin freigeben. Die Kontrolle bist du als Admin im Zustimmungsdialog. Frag den Hersteller, warum seine App ein Recht für alle Postfächer braucht und ob sie mit eingeschränktem Zugriff funktioniert. Die Branchenorganisation Cloud Security Alliance rät außerdem, nachzufragen, wie der Hersteller seine Secrets erzeugt, speichert und rotiert. Und ob ein einziges Secret für alle Kunden gilt.

Die Grenze: Ausmisten schützt nicht vor den Apps, die du wirklich brauchst. Ein Backup-Dienst muss alles lesen können.

Mail-Rechte auf einzelne Postfächer begrenzen

Für Mail gibt es in Exchange Online RBAC for Applications. Du weist dem Service Principal der App eine Rolle wie Application Mail.Send zu und begrenzt sie auf einen Management Scope oder eine Administrative Unit, etwa auf das eine Scan-Postfach. Für Application Mail.ReadWrite funktioniert das genauso. Das Blog Office 365 for IT Pros zeigt die Einrichtung Schritt für Schritt.

Der Haken: Die Rechte aus Entra und aus Exchange addieren sich. Solange die tenantweite Zustimmung für Mail.Send in Entra besteht, schränkt die neue Rolle nichts ein. Du musst die Berechtigung in Entra entfernen.

Die Grenzen: RBAC for Applications wirkt nur auf Daten in Exchange Online und nur über Microsoft Graph und EWS. Für meine Drucker-App, die über Graph sendet, passt das. Für Dateien in SharePoint oder OneDrive hilft es nicht. Und einen Backup-Dienst, der jedes Postfach sichern soll, kannst du damit nicht sinnvoll einschränken.

Conditional Access für Workload Identities

Conditional Access für Workload Identities gibt es, aber es deckt nur Single-Tenant-Service-Principals ab, die in deinem eigenen Tenant registriert sind. Multi-Tenant-Apps von Drittanbietern wie der Backup-Dienst sind ausdrücklich ausgenommen. Auch Managed Identities fallen nicht darunter. Steuern lässt sich nur eines: Blockieren, wenn die Anmeldung von außerhalb bekannter IP-Bereiche kommt oder ID Protection ein Risiko meldet. Dafür brauchst du Lizenzen für Workload Identities Premium.

Lohnend ist das für die Apps, die in deinem Tenant registriert sind: Automatisierungen, Skripte und Integrationen wie meine Drucker-App. Melden die sich von festen Adressen an, ist ein gestohlenes Secret anderswo wertlos. Für Multi-Tenant-Apps wie den Backup-Dienst bringt es nichts.

Hinschauen

App-Anmeldungen stehen in Entra auf einem eigenen Reiter, Service principal sign-ins. Wer nur die Benutzer-Anmeldungen durchsieht, bekommt sie nie zu Gesicht. ID Protection erkennt Risiken auch bei Workload Identities, ausdrücklich auch bei Multi-Tenant-Apps. Die Erkennung Suspicious Sign-ins schlägt etwa an, wenn eine App sich plötzlich von einer ungewohnten IP-Adresse anmeldet. Die Erkennungen siehst du ohne Zusatzlizenz, dafür genügt die Rolle Security Reader. Volle Details und Richtlinien auf Basis des Risikos gibt es nur mit Workload Identities Premium.

Die Grenze ist dieselbe wie oben: Bei Multi-Tenant-Apps von Herstellern kann Microsoft das Risiko erkennen, aber keine Richtlinie blockiert die Anmeldung. Hinschauen ersetzt kein Ausmisten. Es sagt dir nur schneller, dass ein Schlüssel weg ist.

Schlüssel zählen

Die Angreifer mussten bei ConnectWise keinen einzigen Benutzer überlisten. Die Rechte hatten die Betroffenen der App selbst gegeben, den Schlüssel dazu hat der Hersteller verloren. Einem Benutzerkonto würden wir nie Zugriff auf alle Postfächer geben. Meinem Drucker habe ich ihn gegeben.

Wir haben Jahre gebraucht, Benutzern den Generalschlüssel abzunehmen. Apps bekommen ihn bis heute mit einem Klick.

Titelbild: fotoblend auf Pixabay, Pixabay Content License.