ConnectWise Cloud Backup: Vorfall und Microsoft 365

Mitte Oktober haben Huntress und Microsoft berichtet, dass Angreifer eine kompromittierte Anmeldeinformation auf Anbieterseite von ConnectWise Cloud Backup (früher SkyKick) missbraucht haben, um sich in Microsoft-365-Tenants von Kunden anzumelden. ConnectWise bestätigte unbefugten Zugriff auf seine Cloud-Backup-Anwendungsidentitäten und leitete Gegenmaßnahmen ein. Viele Managed Service Provider (MSPs) nutzen Cloud Backup, um E-Mails, Dateien und Teams-Daten ihrer Kunden zu sichern. Dafür kann der Dienst weitreichenden, dauerhaften Zugriff in jedem Tenant haben, in dem er installiert wurde und die nötigen Berechtigungen erhielt.

Der beobachtete Zugriff kam ohne Benutzerpasswort und ohne MFA-Abfrage aus, denn die Anmeldungen erfolgten als Anwendung und nicht als Person. Deshalb betrifft der Vorfall weit mehr Unternehmen als die Kunden von ConnectWise. Viele Organisationen betreiben ein Backup-, Monitoring- oder Verwaltungstool mit ähnlichen Rechten, und nur wenige prüfen diese Verbindungen so genau wie ihre Administratoren.

Dieser Beitrag ist deshalb weniger eine Nachricht als eine Lektion darüber, wie man Anwendungsidentitäten, Lieferantenzugriffe und Abhängigkeiten bei der Wiederherstellung steuert, mit ConnectWise als Beispiel. Alle Angaben gelten mit Stand 20. Oktober 2026 und können sich ändern.

Was bei ConnectWise Cloud Backup passiert ist

Nach eigenen Angaben hat ConnectWise am 14. Oktober unbefugten Zugriff auf Anwendungsidentitäten in seiner Cloud-Backup-Umgebung entdeckt. Huntress beschreibt die Aktivität in Phasen. Am 13. und 14. Oktober habe es von einer einzelnen Adresse eines Hosting-Anbieters, 144.172.64[.]128, Passwort-Spraying gegen vier Kanzlei-Tenants gegeben; zwei Konten seien gesperrt worden, und von dieser Adresse habe Huntress keine erfolgreiche Benutzeranmeldung gesehen. Ab 01:58 UTC am 15. Oktober hätten sich die Cloud-Management-Apps von ConnectWise in rund 50 von Huntress überwachten Tenants selbst Verzeichnisrollen zugewiesen, meist Exchange-Administrator. Huntress hält das für Automatisierung des Anbieters, hat es aber nicht mit ConnectWise bestätigt. Zwischen etwa 06:13 und 08:34 UTC am selben Morgen meldete sich die Cloud-Backup-Anwendung von derselben Adresse an, statt aus dem Microsoft-Cloud-Netz, das die App sonst nutzt.

Microsoft berichtet von einer breiten, erfolgreichen Authentifizierung eines Dienstprinzipals (Service Principal) von dieser Adresse, gefolgt von Aufklärung über die Microsoft Graph API und Versuchen, Anmeldeinformationen zur dauerhaften Absicherung des Zugangs hinzuzufügen, und bezeichnet den Vorfall als aktiven Lieferkettenangriff. Zum Zeitpunkt des Schreibens hat Huntress unbefugte Anmeldungen in mindestens 162 Tenants bestätigt (Stand 16. Oktober, 19:00 UTC). In der Telemetrie, die Huntress einsehen kann, fanden sich außerdem knapp 1.000 Tenants mit Anmeldeaktivität von derselben Adresse, mehr als 300 davon erfolgreich; wo die Backup-App nicht installiert war, schlugen die Versuche fehl. In zwei von Huntress untersuchten Tenants soll eine zweite ConnectWise-Anwendung, Cloud Management für Microsoft Teams, sich selbst zum Globalen Administrator gemacht und anschließend neue Anmeldeinformationen in anderen Anwendungen angelegt haben. Im ersten dieser Tenants seien die neuen Zugangsdaten bis 2028 gültig gewesen.

Mehrere Punkte sind nicht geklärt. ConnectWise hat nicht mitgeteilt, wie die Anmeldeinformation offengelegt wurde, ob eine Produktschwachstelle eine Rolle spielte oder wer hinter der Aktivität steckt, und eine endgültige Zahl betroffener Tenants liegt nicht vor. Huntress liegen außerdem Hinweise von außen auf ähnliche Aktivität vor, die das Unternehmen nicht unabhängig überprüft hat. Eine Anmeldung ist nicht dasselbe wie Datendiebstahl, und umgekehrt gilt das auch: Microsoft protokolliert nicht jeden Lesezugriff einer Anwendung über Graph, ein fehlender Lese-Eintrag beweist also nicht, dass nichts gelesen wurde. Todyl konnte in Tenants mit aktivem Backup-Abonnement Lesezugriffe der Angreifer nicht von normalen Backup-Zugriffen unterscheiden. ConnectWise selbst kann nicht in Kunden-Tenants hineinsehen und deshalb auch nicht sagen, welche betroffen waren.

Warum die Benutzer-MFA hier nicht griff

In Microsoft Entra ID hat Software, die in Ihrem Tenant arbeitet, eine eigene Identität. Die Anwendungsregistrierung des Anbieters steht für die Software, und der Dienstprinzipal ist das Objekt in Ihrem Tenant, über das sie dort arbeitet. Installiert ein Administrator eine Backup-App, erteilt er ihr einmalig Berechtigungen. Mit der Anmeldeinformation des Anbieters lassen sich dann in den Tenants, in denen die App installiert ist und zugestimmt wurde, reine Anwendungstoken anfordern. Wer sie besitzt, erbt alles, was Kunden zuvor genehmigt haben. Microsoft schätzt, dass der Angreifer wahrscheinlich früher erteilte Berechtigungen ausnutzte, darunter hochprivilegierte wie Directory.ReadWrite.All.

Eine reine Anwendungsanmeldung kennt weder Benutzer noch Gerät noch MFA-Abfrage für Benutzer, die Schutzmaßnahmen für Ihre Administratoren griffen also nicht. ConnectWises eigene Anleitung nennt den Ort, an dem die Spuren liegen: die Registerkarte „Dienstprinzipal-Anmeldungen“ (Service principal sign-ins) in den Entra-Anmeldeprotokollen, die die Standardansicht der Benutzeranmeldungen nicht anzeigt. Eine App abzuschalten beendet auch nicht jede Sitzung sofort. Laut Todyl konnten bereits ausgestellte Token bis zu 90 Minuten nutzbar bleiben. Das Verhalten von Token kann variieren, das Deaktivieren der Anwendung bleibt deshalb der erste Eindämmungsschritt.

Das zweite Problem: Backups, die sich nicht zurückspielen lassen

ConnectWise hat am 17. Oktober sieben seiner Anwendungsidentitäten deaktiviert und Cloud Backup sowie SaaS Security und Cloud Management ausgesetzt. Stand des Updates vom 20. Oktober (00:45 UTC): Geplante Backups laufen nicht, Archivzugriff und Wiederherstellungen sind nicht verfügbar, und ein Termin für die Wiederaufnahme steht nicht fest. ConnectWise gibt an, die gespeicherten Archive seien weiterhin verschlüsselt und isoliert, und es gebe keine Hinweise auf eine Kompromittierung. Seit Beginn der Gegenmaßnahmen am 17. Oktober habe man in den überwachten Umgebungen keine erfolgreiche Angreiferaktivität beobachtet. Das belegt nicht, dass einzelne Kunden-Tenants unberührt blieben, und die Prüfanleitung von ConnectWise sagt dasselbe.

Für ein Unternehmen, das sich auf den Dienst verlassen hat, ist das ein zweites Problem zusätzlich zum ersten. Das Werkzeug, das bei einem Vorfall die Wiederherstellung ermöglichen sollte, ist ein möglicher Einstiegspunkt und im Moment offline. Lag Ihre einzige nutzbare Kopie der Microsoft-365-Daten bei einem einzelnen Anbieter, war Ihr Weg zur Wiederherstellung seit dem 17. Oktober unterbrochen. Es lohnt sich, heute zu klären, wie Ihr letzter brauchbarer Wiederherstellungspunkt aussieht und ob es eine zweite, unabhängige Kopie gibt.

Was Sie diese Woche prüfen sollten

Für diese Prüfungen brauchen Sie passende Berechtigungen in Microsoft Entra und Exchange. Beginnen Sie mit Ihrem eigenen Microsoft-365-Tenant. Wenn ein MSP ihn verwaltet, lassen Sie sich seine Prüfung belegen, statt anzunehmen, dass seine eigene Untersuchung Ihren Tenant abdeckt: Laut ConnectWises Anleitung deckt die Prüfung des MSP-Tenants den Kunden-Tenant nicht ab.

Jetzt. Klären Sie, ob in Ihrem Tenant die ConnectWise- oder SkyKick-Anwendungen vorhanden sind. Suchen Sie bei den Unternehmensanwendungen nach der Anwendungs-ID, denn ältere Installationen zeigen teils SkyKick-Namen. Die ID von Cloud Backup lautet 506e08f9-6e9a-4da4-942b-a099a03644ae, und ConnectWise nennt in seinem Advisory sechs weitere für Cloud Management. ConnectWise und Huntress raten beide, die Anwendungen zu deaktivieren, aber nicht zu löschen, und sie deaktiviert zu lassen, bis ConnectWise offizielle Anweisungen zur Wiederinbetriebnahme gibt. Beim Löschen geht die Zustimmung verloren, und die spätere Prüfung wird schwieriger. Sichern Sie die Anmelde- und Audit-Protokolle, bevor Sie etwas ändern. Fragen Sie Ihren MSP schriftlich, ob er diese Anwendungen nutzt, ob er Ihren Tenant geprüft hat und wann Ihr letztes erfolgreiches Backup lief, und klären Sie Ihren letzten brauchbaren Wiederherstellungspunkt.

Danach. Prüfen Sie die Dienstprinzipal-Anmeldungen ab dem 13. Oktober für die Cloud-Backup-Anwendungs-ID und achten Sie auf Quelladressen außerhalb der erwarteten Microsoft-Bereiche. ConnectWise, Huntress und Microsoft nennen übereinstimmend die Adresse 144.172.64[.]128. ConnectWise führt außerdem 144.172.64[.]99 und 144.172.64[.]60 auf, die Huntress fehlgeschlagenen Passwort-Spraying- und Anmeldeversuchen von Benutzern zuordnet, nicht Anwendungsanmeldungen. Suchen Sie sie deshalb auch in den Benutzeranmeldeprotokollen und bewerten Sie ein Ereignis nicht allein nach der IP-Adresse. Ein unauffälliges Ergebnis beweist nicht, dass nichts passiert ist, denn manche Lesezugriffe von Anwendungen hinterlassen keinen Audit-Eintrag.

Suchen Sie dann nach möglicher Persistenz. Wie Huntress betont, entfernt das Deaktivieren der ConnectWise-Apps keine Zugangsdaten, die schon anderswo hinzugefügt wurden. Prüfen Sie bei Ihren Anwendungen die geheimen Clientschlüssel, Zertifikate und Verbundanmeldeinformationen (federated credentials) auf Einträge seit dem 13. Oktober, die Sie nicht zuordnen können, und beginnen Sie bei Verwaltungs- und Sicherheitswerkzeugen. Registrierungen von Anbietern erscheinen in Ihrem Tenant oft nicht unter „App-Registrierungen“, sehen Sie deshalb auch bei der zugehörigen Unternehmensanwendung (dem Dienstprinzipal) nach. Kontrollieren Sie, ob eine ConnectWise- oder SkyKick-Anwendung eine Verzeichnisrolle hat, vor allem Globaler Administrator, und suchen Sie nach neuer Postfachweiterleitung, Posteingangs- oder Transportregeln und delegiertem Postfachzugriff. Gleichen Sie jede Rollenzuweisung mit dem Audit-Ereignis und der genehmigten Konfiguration ab und sichern Sie die Belege, bevor Sie etwas entfernen.

Lieferantenzugriff ist eine Governance-Frage

Frühere MSP-Vorfälle zeigten, wie Angreifer Fernwartungsinfrastruktur missbrauchen. CISA und FBI reagierten 2021 auf den Kaseya-VSA-Angriff auf MSPs und deren Kunden, und im August 2026 berichtete Sophos, ein Angreifer habe in einem Fall über einen kompromittierten N-able-N-central-Server einen Backup-Server und Domänencontroller erreicht. Hier läuft der Weg anders: ConnectWise spricht von kompromittierten Anwendungsidentitäten, nicht von einer bestätigten Produktschwachstelle, und der Zugriff lief über Berechtigungen, die Kunden bereits erteilt hatten. Eine einzige Anmeldeinformation auf Anbieterseite kann einem Angreifer Zugang zu vielen Kunden verschaffen, ohne dass er bei jedem einzeln einbrechen muss.

NIS2 und die deutsche Umsetzung erwarten, dass Organisationen Risiken in der Lieferkette steuern; den Hintergrund dazu liefert unser Beitrag zu den Cyber-Abhängigkeiten laut ENISA. Ob dieser Vorfall für Sie eine Meldepflicht auslöst, hängt von Ihrem Status nach dem Gesetz, Ihrer Branche und den tatsächlichen Auswirkungen ab, und das klären Sie am besten mit Ihrer Rechtsberatung. Für Organisationen im Anwendungsbereich gehört das Lieferantenrisiko in Zugriffsinventare, Sicherheitsprüfungen, Vorfallverfahren und die Wiederherstellungsplanung, nicht nur in den Einkauf. Praktisch stellt sich eine konkrete Frage: Welche Lieferanten-Anwendungen haben dauerhafte Berechtigungen in Ihrem Tenant, wer hat sie genehmigt, und wer prüft sie? Huntress empfiehlt, die Zahl derer zu begrenzen, die Anwendungen Zugangsdaten hinzufügen dürfen, und mit passender Lizenz einzuschränken, von wo sich Anwendungen anmelden dürfen.

Fazit

Die Untersuchung von ConnectWise ist mit Stand 20. Oktober noch offen, und die fehlenden Fakten können Teile dieses Bildes verändern. Die Lehre hängt nicht von der endgültigen Tenant-Zahl ab: Eine Backup- oder Verwaltungs-App mit weitreichendem, dauerhaftem Zugriff auf Ihren Microsoft-365-Tenant ist eine privilegierte Identität, auch wenn sich nie eine Person damit anmeldet, und ihre Zugangsdaten liegen bei einem Dritten. Behandeln Sie sie wie ein Administratorkonto. Führen Sie sie in einem Inventar, halten Sie fest, wer sie genehmigt hat, begrenzen Sie ihre Rechte, beobachten Sie ihre Anmeldungen und testen Sie einen unabhängigen Weg zur Wiederherstellung. Die Untersuchung des Lieferanten und die Prüfung Ihres eigenen Tenants ergänzen einander und ersetzen sich nicht, denn Spuren und Persistenz können in Ihrer Umgebung liegen.

Wenn Sie Ihre Microsoft-365-Anwendungsberechtigungen oder die Überwachung von Lieferantenzugriffen einmal von außen prüfen lassen möchten, erreichen Sie uns über die Kontaktseite.

Sources: Huntress: ConnectWise (SkyKick) vendor credentials abused in M365 attacks, ConnectWise Trust Center advisory, ConnectWise technical investigation and remediation guide (PDF), Microsoft Threat Intelligence, Todyl investigation, Help Net Security, CISA: Kaseya ransomware attack guidance.

Kontaktieren Sie uns für weitere Informationen.

Dieser Beitrag kann KI-generierte Bilder, Grafiken und/oder Fotos enthalten.