Unbekannte Angreifer haben kompromittierte Anmeldeinformationen von ConnectWise Cloud Backup genutzt, um auf mindestens 173 Microsoft-365-Tenants zuzugreifen. Nach Erkenntnissen des Sicherheitsanbieters Huntress wurden am 15. Oktober 2026 zwischen 06:13 und 08:34 Uhr UTC automatisiert Microsoft-Graph-Token für Kundenumgebungen bezogen. ConnectWise hat den Zugriff der Cloud-Backup-Anwendung inzwischen bis auf Weiteres geschlossen.
Betroffen sind Organisationen, in deren Microsoft-365-Umgebung die Anwendung installiert und mit entsprechenden Berechtigungen ausgestattet war. Die Zahl 173 bezeichnet bestätigte unautorisierte Anmeldungen, nicht den gesamten potenziell exponierten Kundenkreis. ConnectWise Cloud Backup hieß früher SkyKick und richtet sich vor allem an Managed Service Provider, die damit Daten ihrer Kunden sichern.
Bei dem Vorfall wurde nach bisherigem Stand keine klassische Softwarelücke ausgenutzt. Es gibt deshalb weder eine CVE noch betroffene oder gepatchte Programmversionen. Der Angriff lief über eine legitime Anwendungsidentität: Wer deren Zugang kontrolliert, kann dieselben Rechte anfordern, die der Backup-Dienst zuvor von den jeweiligen Kunden erhalten hat.
Ein App-Zugang statt eines kompromittierten Benutzerkontos
Cloud Backup benötigt für seine Arbeit weitreichenden Zugriff auf Microsoft 365. Je nach Einwilligung im jeweiligen Tenant kann die Anwendung E-Mails und Anhänge, OneDrive- und SharePoint-Dateien, Teams-Chats sowie Verzeichnisdaten lesen oder bearbeiten. Die Angreifer authentifizierten sich laut Huntress mit eigener Software gegenüber der Anwendung und ließen sich auf Grundlage der bereits erteilten Berechtigungen Microsoft-Graph-Token ausstellen.
Wie der kompromittierte App-Zugang wirkte
Die Grafik zeigt den beobachteten Weg vom kompromittierten ConnectWise-Zugang über Microsoft-Graph-Token zu 173 bestätigten Tenant-Anmeldungen und den möglichen Folgen.
Die kompromittierte Client Assertion lag im Tenant des Anbieters. Kunden konnten den Diebstahl dieser Anbieteridentität daher nicht durch einen Passwortwechsel oder zusätzliche Mehrfaktor-Authentifizierung für ihre eigenen Benutzer verhindern. Genau darin liegt der operative Unterschied zu einem gewöhnlichen Kontoangriff: Die Vertrauensbeziehung war auf Anwendungsebene bereits eingerichtet.
Huntress zufolge arbeitete das Angriffsskript die Tenants in sortierter GUID-Reihenfolge mit nur wenigen Sekunden Abstand ab. Die Token-Anfragen kamen von der IP-Adresse 144.172.64[.]128. Dieselbe Adresse war am 13. und 14. Oktober außerdem an Password-Spraying-Versuchen gegen vier Anwaltskanzleien beteiligt. Erfolgreiche Benutzeranmeldungen wurden dabei in der ausgewerteten Telemetrie nicht festgestellt.
In einem Tenant wurden weitere privilegierte Zugänge angelegt
Der beobachtete Zugriff blieb nicht in jedem Fall auf das Auslesen von Daten beschränkt. In mindestens einem Partner-Tenant stattete sich eine separate ConnectWise Cloud Management App für Microsoft Teams mit der Rolle Global Administrator aus. Ihre Anwendungs-ID lautet 24205314-2b89-4e07-a2a4-579e898a5640.
Anschließend führte die Anwendung nach Angaben von Huntress ein Python-Skript aus, das zwei weiteren vertrauenswürdigen Anwendungen neue Client Secrets hinzufügte: einer MSP-Management-Anwendung und der Huntress Security Platform. Damit entstand ein möglicher Zugang, der nicht mehr allein am kompromittierten Cloud-Backup-Berechtigungsnachweis hing.
Dieser Befund ist besonders relevant, weil privilegierte MSP-Anwendungen häufig in mehrere Kunden-Tenants eingebunden sind. Ein zusätzliches Geheimnis für eine solche Anwendung kann den Zugriffsweg über die unmittelbar betroffene Umgebung hinaus verlängern. Wie weit dies im konkreten Vorfall tatsächlich gelang, ist bislang nicht beziffert. Bestätigt ist die Manipulation in mindestens einem Partner-Tenant.
Benutzer abzumelden beendet den Zugriff nicht
Das Zurückziehen von Benutzersitzungen reicht bei diesem Angriff nicht aus. Die Tokens wurden für einen Service Principal und nicht für ein kompromittiertes Benutzerkonto ausgestellt. Nach Angaben von Todyl verhindert das Deaktivieren der Anwendung zwar die Ausgabe neuer Tokens im jeweiligen Tenant; bereits ausgestellte Tokens können jedoch noch bis zu 90 Minuten gültig bleiben.
ConnectWise erklärte, bislang keine Hinweise auf eine Kompromittierung der bei Partnern gesicherten Backup-Daten gefunden zu haben. Diese Aussage schließt einen Zugriff auf Microsoft-365-Produktivdaten nicht aus. Die bestätigten Anmeldungen erfolgten gerade über die Berechtigungen, mit denen der Dienst auf Postfächer, Dateien, Teams-Inhalte und Verzeichnisinformationen der Kunden zugreifen sollte.
Hinzu kommt eine begrenzte Nachweisbarkeit: Huntress weist darauf hin, dass bestimmte Zugriffe, darunter einige Verzeichnisabfragen über Microsoft Graph, keine verwertbare Audit-Spur hinterlassen können. Das Fehlen eines Protokolleintrags ist deshalb nicht automatisch ein Beleg dafür, dass keine Daten abgerufen wurden.
Was Betreiber jetzt in Entra prüfen sollten
Organisationen mit ConnectWise Cloud Backup sollten die Anwendung deaktiviert lassen, bis ConnectWise die Rotation aller betroffenen Zugangsdaten bestätigt. Die Cloud-Backup-Anwendung lässt sich über die Anwendungs-ID 506e08f9-6e9a-4da4-942b-a099a03644ae identifizieren.
Für die Suche nach verdächtigen Anmeldungen muss im Microsoft Entra Admin Center unter Monitoring → Sign-in logs ausdrücklich die Ansicht Service principal sign-ins verwendet werden. Die übliche Ansicht für Benutzeranmeldungen zeigt die relevanten Ereignisse nicht. Dort sollten Betreiber nach der Anwendungs-ID filtern und Zugriffe von 144.172.64[.]128 sowie von anderen unerwarteten Adressen prüfen. Reguläre Verbindungen der Anwendung wurden als privater Azure-IPv6-Verkehr beschrieben.
Zusätzlich sollten Microsoft-Graph-Aktivitätsprotokolle aktiviert und die Entra-Audit-Logs ab dem 13. Oktober ausgewertet werden. Gesucht werden sollte nach neu hinzugefügten Client Secrets, Veränderungen an vertrauenswürdigen Anwendungen sowie ConnectWise- oder SkyKick-Anwendungen, die sich selbst Verzeichnisrollen zugewiesen haben. Werden solche Änderungen gefunden, genügt es nicht, nur Cloud Backup abzuschalten: Die neu angelegten Zugangsdaten müssen entfernt und die betroffenen Anwendungsidentitäten separat untersucht und erneuert werden.
Der Vertrauensbereich eines Backup-Dienstes ist der eigentliche Hebel
Der Vorfall ist ein aktiv beobachteter Identitätsangriff und keine lediglich theoretische Schwachstelle. Seine Reichweite entsteht aus der Kombination zweier legitimer Eigenschaften: Ein zentraler Backup-Dienst muss viele Daten lesen können, und MSP-Werkzeuge werden häufig über zahlreiche Kundenumgebungen hinweg eingesetzt. Wird die Identität des Anbieters kompromittiert, skaliert dieser bereits erteilte Zugriff mit.
Für Betreiber verschiebt sich damit auch die Kontrolle. Entscheidend sind nicht nur Benutzerkonten und deren Mehrfaktor-Authentifizierung, sondern Service Principals, App-Berechtigungen, neu angelegte Geheimnisse und Anwendungsanmeldungen. Wer ausschließlich die normalen Benutzer-Logs überwacht, kann einen Angriff mit gültigen App-Zugangsdaten übersehen – obwohl er technisch mit genau den Rechten stattfindet, die der Tenant zuvor ausdrücklich genehmigt hat.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
