Vergessene App mit Vollzugriff: So prüfst du, wer auf dein Microsoft 365 zugreift
Vergessene App mit Vollzugriff: App-Zugriffe in Microsoft 365 prüfen und aufräumen.
In diesem Beitrag: Was beim Angriff über ConnectWise Cloud Backup (früher SkyKick) passiert ist, warum Zwei-Faktor-Authentifizierung nicht geholfen hat, wie du in Microsoft 365 prüfst, welche Apps Zugriff haben, und wie du eigene KI-Anbindungen und Automationen von Anfang an schlank berechtigst.
Mitte Oktober 2026 haben Angreifer Microsoft-365-Umgebungen zahlreicher Unternehmen erreicht, ohne ein Passwort zu knacken. Sie meldeten sich als Backup-Software an, die dort längst zugelassen war und weitreichende Rechte auf Postfächer, Dateien und Verzeichnisdaten hatte.
Der Fall ist lehrreich, auch wenn du ConnectWise nie genutzt hast. Jede Automation, jeder KI-Assistent und jedes Backup-Tool, das du mit Outlook, SharePoint oder Teams verbindest, bekommt eine ähnliche App-Identität. Die Frage ist, ob du weißt, welche es sind und was sie dürfen.
Dieser Beitrag ist eine praktische Orientierung, keine Rechts- oder IT-Sicherheitsberatung. Bei konkretem Verdacht gehört die Prüfung in die Hände deiner IT oder eines Spezialisten.
Was beim ConnectWise-Vorfall passiert ist
ConnectWise Cloud Backup ist ein Backup-Dienst, den vor allem IT-Dienstleister (MSPs) für Microsoft 365 und Google Workspace einsetzen. In jedem Kunden-Tenant steht dafür eine App-Identität mit Berechtigungen in Microsoft Entra ID, ein sogenannter Service Principal. So beschreibt es BleepingComputer (17.10.2026).
Laut dem Sicherheitsanbieter Huntress ist ein Zugangsschlüssel (API-Secret) dieser App in fremde Hände geraten. Am 15. Oktober meldete sich die App von einer Hosting-Adresse aus bei Kunden-Tenants an und erhielt Zugriffstoken für Microsoft Graph. Die wichtigsten Punkte:
- Umfang: Huntress bestätigte bis zum 16. Oktober unberechtigte Anmeldungen in 162 Tenants. In einem späteren Update nennt Huntress fast 1.000 Entra-Tenants mit Anmeldeaktivität von der Angreifer-IP, davon über 300 erfolgreich.
- Microsoft: stellte laut BleepingComputer am 15. Oktober unberechtigte Anmeldeversuche fest und stuft den Vorfall als aktiven Lieferkettenangriff ein, bei dem wahrscheinlich bereits erteilte Rechte wie Directory.ReadWrite.All missbraucht wurden.
- Rollen: In rund 50 von Huntress überwachten Tenants wiesen sich ConnectWise-Apps selbst Verzeichnisrollen zu, meist Exchange-Administrator. Ob Angreifer oder Herstellerautomation dahinterstand, hat Huntress nicht bestätigt.
- Hintertür: In einem Tenant machte sich eine dieser Apps zum Globalen Administrator und hinterlegte in etwa fünf Minuten neue Secrets bei zwei anderen Apps, gültig bis 2028.
- Reaktion: ConnectWise schaltete am 17. Oktober den App-Zugriff für Cloud Backup ab und deaktivierte sieben App-Identitäten. Hinweise auf kompromittierte Backup-Archive sieht ConnectWise nach eigener Aussage bisher nicht.
Ein Detail macht den Fall zum Lehrstück: Laut BleepingComputer erhielt ein Administrator am 15. Oktober die Meldung, dass sich ein SkyKick-Service-Principal die Exchange-Administrator-Rolle zugewiesen habe. Die App hatte er seit Jahren nicht mehr genutzt. Sie war vergessen, ihre Rechte nicht.
Warum Zwei-Faktor hier nicht geholfen hat
Zwei-Faktor-Authentifizierung schützt Menschen, die sich anmelden. Hier meldete sich ein Skript direkt als Backup-App an und bekam genau die Rechte, die Kunden der App früher erteilt hatten. Laut Huntress kommen reine App-Anmeldungen ohne Benutzer, ohne Gerät und ohne MFA-Abfrage aus.
Drei Punkte zum Merken:
- Ein Secret ist ein Generalschlüssel: Wer es besitzt, meldet sich von überall als die App an, mit allen erteilten Rechten.
- Abschalten wirkt nicht rückwirkend: Laut ConnectWise stoppt das Deaktivieren neue Anmeldungen, ausgestellte Token können bis zum Ablauf gültig bleiben.
- Hintertüren bleiben: Secrets, die ein Angreifer bei anderen Apps hinterlegt hat, verschwinden nicht mit der ursprünglichen App. Huntress rät, die Anmeldeinformationen aller Apps zu prüfen.

So lief der ConnectWise-Angriff: Login mit App-Schlüssel, ohne Passwort und ohne MFA.
Delegiert oder Anwendungsberechtigung: der Unterschied, der zählt
Microsoft unterscheidet zwei Arten von App-Berechtigungen. Wer sie auseinanderhält, versteht jede Berechtigungsliste in Entra ID.
- Delegierte Berechtigungen: Die App handelt im Namen eines angemeldeten Benutzers und sieht nie mehr als er. Beispiel aus der Microsoft-Dokumentation: Mit der delegierten Berechtigung Files.Read.All liest eine App nur Dateien, auf die der Benutzer selbst Zugriff hat.
- Anwendungsberechtigungen (App-Rollen): Die App handelt ohne Benutzer, typisch für Automation und Backup. Dieselbe Berechtigung Files.Read.All als Anwendungsberechtigung erlaubt laut Microsoft, jede Datei im Tenant zu lesen.
- Wer zustimmt: Anwendungsberechtigungen kann nur ein Administrator erteilen. Delegierten Rechten können Benutzer standardmäßig für ihre eigenen Daten zustimmen, solange die Berechtigung keine Administratorzustimmung verlangt.
Als Faustregel: Eine Anwendungsberechtigung mit „.All“ im Namen bedeutet meist Zugriff auf alle Daten dieser Art im Unternehmen. Genau solche Rechte braucht ein Backup-Tool, und genau deshalb ist es ein lohnendes Ziel.

Delegiert oder Anwendungsberechtigung: Wie weit die Rechte einer App wirklich reichen.
Jede KI-Anbindung bringt eine neue App mit
Verbindest du Make, n8n oder Zapier mit Outlook, lässt einen KI-Assistenten auf SharePoint zugreifen oder richtest ein Copilot-Plugin oder Backup-Tool ein, bestätigst du meist einen Einwilligungsdialog. Danach steht eine weitere App in deinem Tenant, oft mit mehr Rechten als nötig.
Ein Beispiel aus der n8n-Dokumentation: Die Outlook-Anmeldung fordert standardmäßig unter anderem Mail.ReadWrite, Mail.Send und Calendars.ReadWrite an, über „Custom Scopes“ lässt sich das einschränken. Das ist keine Kritik an n8n, zeigt aber, wie schnell aus „kurz testen“ ein dauerhafter Schreibzugriff auf Postfächer wird.
Das Problem ist selten die einzelne Anbindung, sondern die Summe: das alte Testprojekt, das Tool eines früheren Dienstleisters, der Assistent, den jemand einmal ausprobiert hat.
So prüfst du App-Zugriffe in Microsoft 365
Die Schritte stützen sich auf Microsoft Learn sowie Empfehlungen von Huntress und ConnectWise. Je nach Sprache kann die Oberfläche leicht andere Bezeichnungen zeigen.
Schritt 1: Liste aller Unternehmensanwendungen ziehen
Melde dich im Microsoft Entra Admin Center mindestens als Cloudanwendungsadministrator an und öffne Entra ID > Enterprise-Apps > Alle Anwendungen. Notiere für jede App Hersteller, Zweck und eine verantwortliche Person. Was keinen erkennbaren Zweck hat, kommt auf die Prüfliste.
Schritt 2: Berechtigungen jeder App ansehen
Öffne eine App und wähle Berechtigungen. Laut der Microsoft-Anleitung zum Überprüfen von Berechtigungen siehst du dort getrennt, was per Administratorzustimmung für die ganze Organisation gilt und was einzelne Benutzer erteilt haben. Achte besonders auf Anwendungsberechtigungen mit Schreibrechten und „.All“, etwa für Mail, Dateien oder das Verzeichnis. Von Administratoren erteilte Rechte kannst du dort widerrufen.
Schritt 3: Anmeldungen der Apps prüfen
Im Monitoring-Bereich unter Sign-in logs gibt es laut Huntress und ConnectWise eine eigene Registerkarte für Service-Principal-Anmeldungen, die Standardansicht zeigt nur Benutzeranmeldungen. Ungewöhnliche IP-Adressen oder Anmeldungen von Apps, die niemand mehr nutzt, sind Warnsignale. Laut ConnectWise bewahrt Entra diese Protokolle je nach Lizenz nur etwa 7 oder 30 Tage auf.
Schritt 4: Alte Apps deaktivieren statt sofort löschen
Unter Eigenschaften setzt du „Aktiviert für die Anmeldung von Benutzern?“ auf Nein. Laut Microsoft werden dann keine Token mehr für diese App ausgestellt. Im Verdachtsfall rät Huntress zum Deaktivieren statt Löschen, damit Konfiguration und Spuren erhalten bleiben. Verwaiste Apps räumst du nach einer Wartefrist und Rücksprache auf.
Schritt 5: Benutzereinwilligung einschränken
Standardmäßig dürfen Benutzer Apps Zugriff auf ihre eigenen Daten geben, etwa auf ihr Postfach. Microsoft empfiehlt in der Dokumentation zur Benutzereinwilligung, das nur für Apps verifizierter Herausgeber zu erlauben. Die Einstellung liegt unter Enterprise-Apps > Zustimmung und Berechtigungen > Einstellungen zur Benutzerzustimmung. Über einen Workflow können Mitarbeitende stattdessen eine Administratorzustimmung anfragen. Neue Einstellungen gelten nur für künftige Einwilligungen, bestehende Freigaben bleiben.
Schritt 6: Secrets, Zertifikate und Rollen kontrollieren
Prüfe bei Unternehmensanwendungen und App-Registrierungen, welche Secrets und Zertifikate hinterlegt sind. Huntress empfiehlt, alles zu entfernen, was niemand bewusst angelegt hat. Hält eine App eine Administratorrolle, vor allem Globaler Administrator, muss jemand erklären können, warum.

App-Zugriffe in Microsoft 365 prüfen: sechs Schritte vom Inventar bis zu den Secrets.
Eigene Automationen nach dem Minimalprinzip bauen
Wenn du selbst Automationen oder KI-Agenten an Microsoft 365 anbindest oder anbinden lässt, helfen einfache Regeln:
- Eine App pro Zweck: Lieber getrennte App-Registrierungen für Rechnungs-Workflow und Support-Assistent als eine Sammel-App mit allen Rechten.
- Nur nötige Scopes: Wer nur Kalender liest, braucht kein Mail.Send. Wo ein Benutzerkontext reicht, delegierte Rechte nutzen.
- Eigenes Dienstkonto: Delegierte Automationen laufen über ein eigenes, dokumentiertes Konto, nicht über das Postfach der Geschäftsführung.
- Zertifikat statt Secret: Microsoft empfiehlt für produktive Apps Zertifikate oder föderierte Anmeldeinformationen statt Client-Secrets.
- Ablauf setzen: Client-Secrets gelten höchstens 24 Monate, Microsoft empfiehlt unter 12 Monaten. Ablaufdatum in den Kalender.
- Besitzer eintragen: Jede App hat eine verantwortliche Person und einen dokumentierten Zweck.
Google Workspace: dieselbe Frage, anderes Menü
Laut Google-Hilfe findest du die Übersicht in der Admin-Konsole unter Sicherheit > Zugriffs- und Datenkontrolle > API-Steuerung > App-Zugriff verwalten. Die Liste „Apps, auf die zugegriffen wurde“ zeigt Nutzerzahl und angeforderte Google-Dienste. Apps lassen sich unter anderem als vertrauenswürdig, eingeschränkt oder blockiert einstufen. Außerdem kannst du die Anmeldung bei nicht konfigurierten Drittanbieter-Apps begrenzen und riskante Bereiche in Gmail und Drive gezielt sperren.
Quartals-Check und klare Verantwortung
Weil ständig neue Anbindungen dazukommen, reicht einmal Aufräumen nicht. Ein Termin pro Quartal genügt für die meisten KMU:
- Neue Apps erfassen: Zweck und Besitzer ergänzen.
- Rechte vergleichen: Mehr Berechtigungen als beim letzten Mal?
- Secrets und Rollen: Was läuft ab, was ist neu, welche App ist Admin?
- Ungenutzte Apps: Seit Monaten keine Anmeldung? Deaktivieren.
- Protokoll: Datum, Name, Ergebnis.
Die Verantwortung gehört zu einer konkreten Person, nicht zu „der IT“. Betreut ein Dienstleister deinen Tenant, frag direkt: Welche Apps hast du eingerichtet, mit welchen Rechten, und wer prüft sie?
Fazit
Beim ConnectWise-Vorfall war nicht ein Passwort die Schwachstelle, sondern eine App mit weitreichenden Rechten. Zwei-Faktor half nicht, weil sich Software anmeldete. Für KMU heißt das: Inventar ziehen, Anwendungsberechtigungen kritisch ansehen, verwaiste Apps abschalten, Benutzereinwilligung begrenzen und neue KI-Anbindungen mit so wenigen Rechten wie möglich bauen. Ein fester Quartalstermin verhindert die nächste vergessene App mit Vollzugriff.
Häufige Fragen
Betrifft mich der Vorfall, wenn ich ConnectWise nicht nutze?
Direkt nur, wenn ConnectWise- oder SkyKick-Apps in deinem Tenant stehen, in älteren Tenants laut Huntress auch als „SkyKick Cloud Manager“. Frag im Zweifel deinen IT-Dienstleister. Die Lehre gilt für jede App mit weitreichenden Rechten.
Hilft es, alle Passwörter zu ändern?
Gegen eine missbrauchte App-Identität kaum, denn ein Passwortwechsel betrifft Benutzerkonten, nicht die Secrets von Apps. Laut BleepingComputer beendet auch das Widerrufen von Benutzersitzungen keinen app-basierten Zugriff.
Was ist der Unterschied zwischen Deaktivieren und Löschen?
Deaktivieren stoppt neue Token, die App und ihre Einstellungen bleiben erhalten. Löschen entfernt laut Huntress auch die Einwilligung, die App müsste später neu zugelassen werden. Im Verdachtsfall deshalb zuerst deaktivieren.
Kann ich verhindern, dass Mitarbeitende Apps selbst verbinden?
Ja. Du kannst die Benutzereinwilligung deaktivieren oder auf verifizierte Herausgeber begrenzen und über den Admin-Workflow einen Antragsweg anbieten. Halte ihn kurz, sonst weichen Mitarbeitende auf private Tools aus.
Über den Autor: Moritz-Tim Schiller ist Gründer von Taveno Solutions in Oberhausen, einer Digitalagentur für KMU mit Fokus auf Websites, KI-Agenten und Automatisierung. Wer KI-Anbindungen an Microsoft 365 plant und die Rechte von Anfang an schlank halten will, kann über das Agenturmarkt-Profil ein kostenloses 30-Minuten-Erstgespräch vereinbaren.