ConnectWise Cloud Backup: Angriff auf Microsoft-365-Tenants

Kategorien: Datenschutz und Security

Hacker nutzten ein Zugangsdatum der Backup-Anwendung eines Anbieters, um sich in Microsoft-365-Tenants anzumelden, und zwar ohne Benutzerkonto und ohne MFA-Abfrage. Belegt ist der Missbrauch der Anwendungsidentität. Offen sind die Ursache, der Umfang des Schadens und des Datenabflusses.

Seit dem 15. Oktober 2026 beschäftigt ein Vorfall rund um ConnectWise Cloud Backup viele IT-Abteilungen und IT-Dienstleister. Der Dienst, früher unter dem Namen SkyKick bekannt, wurde am 17. Oktober 2026 abgeschaltet und wird nach Angaben des Herstellers schrittweise wieder bereitgestellt. Die Lage entwickelt sich weiter. Beschrieben wird der Stand vom 22. Oktober 2026. Zahlen, Empfehlungen und Wiederherstellungsphasen können sich seitdem geändert haben.

Der Angriff auf ConnectWise Cloud Backup im Überblick

ConnectWise Cloud Backup ist ein Dienst zur Sicherung von Microsoft-365-Daten wie Postfächern, Dateien und Teams-Inhalten. Er ging aus dem Produkt SkyKick hervor, das ConnectWise übernommen hat. Eingerichtet wird ein solcher Dienst meist von einem IT-Dienstleister (englisch Managed Service Provider, kurz MSP) für dessen Kunden. Diese Einordnung ist eine allgemeine Beschreibung und keine belegte Statistik darüber, wer den Dienst tatsächlich nutzt.

Technisch funktioniert ein solcher Dienst als Anwendung, die sich mit einem Microsoft-365-Tenant verbindet. Ein Tenant ist die abgegrenzte Umgebung eines Unternehmens bei Microsoft, mit Benutzern, Postfächern, Dateien und Einstellungen. Damit die Backup-Anwendung Daten lesen darf, erteilt ein Administrator bei der Einrichtung eine Einwilligung (englisch Consent). Danach ist die Anwendung im Tenant als Unternehmensanwendung (Enterprise Application) hinterlegt.

Nach der Analyse der Sicherheitsfirma Huntress meldeten sich Angreifer mit der Identität genau dieser Anwendung in zahlreichen Kunden-Tenants an. Das Zugangsdatum, mit dem sich die Anwendung gegenüber Microsoft ausweist, gehörte dem Hersteller und lag nicht bei den Kunden. Ob der Dienst selbst „gehackt“ wurde, ist nicht belegt. Belegt ist der Missbrauch der Anwendungsidentität. ConnectWise schaltete den Dienst am 17. Oktober 2026 ab. Es handelt sich um einen sogenannten Lieferkettenangriff, ein Begriff, der weiter unten erklärt wird.

Quellen: Analyse von Huntress und Mitteilungen im Trust Center von ConnectWise.

Zeitleiste: Von den ersten Versuchen bis zur Abschaltung

Die folgende Übersicht fasst die Ereignisse zusammen, die Huntress und ConnectWise übereinstimmend oder jeweils für sich beschreiben. Uhrzeiten sind in UTC angegeben, alle Daten liegen im Jahr 2026.

Eine Einschränkung betrifft den Anfang. Huntress verknüpft die Password-Spray-Versuche gegen die Kanzleien zeitlich mit dem späteren Missbrauch des Anbieter-Zugangsdatums. Ein ursächlicher Zusammenhang ist damit nicht nachgewiesen. Es kann sich um dieselben Angreifer handeln, belegt ist das nicht.

Auffällig ist das Tempo. Huntress beschreibt die Abläufe als schnell und vermutet Automatisierung, bestätigt ist das nicht. Für die Verteidigung heißt das: Ein einzelner Tenant sah nur einen Bruchteil des Geschehens, und zwischen erstem Zugriff und Rollenzuweisung lagen teils nur Minuten.

Wie die Anmeldung ohne Benutzer und ohne MFA funktioniert

Im Alltag melden sich Menschen mit Benutzername, Passwort und einem zweiten Faktor an (Multi-Faktor-Authentifizierung, kurz MFA). Zusätzlich bewertet Microsoft über Conditional Access, also Zugriffsregeln, Faktoren wie Gerät, Standort und Risiko. Beides ist auf Benutzeranmeldungen ausgelegt.

Eine Backup-Anwendung arbeitet anders. Sie ist als Multi-Tenant-App angelegt, das heißt, dieselbe Anwendung ist in vielen fremden Tenants zugelassen. Jeder Kunde erteilt ihr einmal per Consent bestimmte Rechte. Später holt die Anwendung sich selbst Zugriffstoken, also zeitlich begrenzte digitale Berechtigungsnachweise, für Microsoft Graph, die zentrale Programmierschnittstelle von Microsoft 365. Dazu weist sie sich mit einem Zertifikat oder Geheimnis aus, einer sogenannten Client Assertion nach dem Standard OAuth. Dieses Zertifikat liegt im Tenant des Herstellers. Die Anmeldung gilt in Microsoft-Begriffen für einen Dienstprinzipal (Service Principal), das ist die Identität der Anwendung im jeweiligen Tenant.

Wer dieses Zugangsdatum besitzt, kann sich in allen Tenants anmelden, in denen die Anwendung zugelassen ist. Für Microsoft sieht das aus wie der legitime Dienst. Es gibt keinen Benutzer, der einen zweiten Faktor bestätigen könnte, und kein Gerät, das geprüft würde. Heise, BleepingComputer und Huntress beschreiben diesen Punkt übereinstimmend: MFA hilft an dieser Stelle nicht. Ob und wie Microsoft Zugriffsregeln für solche Anwendungsidentitäten anbietet, ist ein eigenes Thema und hier nicht geprüft.

Als Lieferkettenangriff auf Microsoft 365 gilt ein Angriff, der nicht das eigentliche Ziel direkt angeht, sondern einen Dienstleister oder Softwareanbieter, dem das Ziel vertraut. Nach Angaben von BleepingComputer bezeichnet auch Microsoft den Vorfall als Supply-Chain-Angriff. Die Kunden hatten nicht zwingend etwas falsch gemacht. Sie hatten einer Anwendung vertraut, deren Zugangsdatum außerhalb ihrer Kontrolle lag.

Ungeklärt ist, wie die Angreifer an dieses Zugangsdatum gelangten. Heise, Huntress und BleepingComputer sprechen von vermutlich gestohlenen Anbieter-Zugangsdaten. Das ist eine Annahme, keine veröffentlichte Feststellung. Details zur Ausnutzung, etwa konkrete Abfragen, werden hier bewusst nicht beschrieben.

Was zu den Zahlen belegt ist und was nicht

In den Berichten kursieren mehrere Zahlen, die auf den ersten Blick nicht zusammenpassen. Sie beschreiben Verschiedenes, teils zu unterschiedlichen Stichtagen.

Die tatsächliche Gesamtzahl ist ungesichert. Nach Angaben von heise hat ConnectWise keinen Zugriff auf Kundenumgebungen, und Huntress sieht nur die Tenants, die es selbst beobachtet. Die Unterscheidung zwischen 162 und 173 bleibt deshalb offen und wird hier als ungeklärt geführt.

Wichtig ist die Bedeutung der Begriffe. Eine Anmeldeaktivität ist nicht gleichbedeutend mit einem Datenabfluss, und eine erfolgreiche Anmeldung bedeutet nicht, dass Daten gelesen wurden. Huntress fand in den ausgewerteten Tenants keine Manipulation von Postfächern, Dateien, Benutzern oder Richtlinien. Die Firma weist aber selbst darauf hin, dass lesende Zugriffe über Microsoft Graph nicht protokolliert werden und das Bild daher unvollständig ist. Nach Angaben von BleepingComputer fand die Firma Todyl in neun untersuchten Tenants ebenfalls nur Anmeldeaktivität. Diese Aussage stammt aus zweiter Hand.

Eine zweite, gezielte Welle richtete sich laut Huntress gegen 16 Tenants in den Bereichen Politik, nationale Sicherheit, Handel und kritische Rohstoffe. Die Zugriffe scheiterten nach Darstellung von Huntress, und die meisten dieser Ziele nutzten keine ConnectWise-Produkte. Für kleine und mittlere Unternehmen ist das eine Einordnung, kein Grund zur Sorge: Die Mehrzahl der Betroffenen gehört nicht zu solchen Zielgruppen.

Auch inaktive Registrierungen sind ein Risiko

Nach den Angaben von heise konnte ein Zugriff bestehen, solange die Registrierung der Anwendung im Tenant vorhanden war. Es spielt dabei keine Rolle, ob der Dienst noch aktiv genutzt wird. Wer vor Jahren eine Backup-Lösung testete, den Anbieter wechselte oder einen Dienstleister mit der Einrichtung beauftragte, kann also eine Altlast im Tenant haben, ohne davon zu wissen.

Ältere Tenants führen die Anwendung eventuell noch unter dem früheren Namen „SkyKick Cloud Manager“, wie BleepingComputer berichtet. Außerdem wurden laut Huntress weitere ConnectWise-Anwendungen aus dem Bereich Cloud-Management missbraucht, die auf Exchange, Teams, SharePoint, Graph und das Partner Center zugreifen. Die Cloud-Backup-Anwendung hatte nach Angaben von Microsoft, wiedergegeben von BleepingComputer, vermutlich weitreichende Rechte wie Directory.ReadWrite.All. Das ist ein sehr umfassendes Verzeichnisrecht und ein Beispiel dafür, wie viel Vertrauen bei einer Einwilligung eingeräumt wird.

Der praktische Schluss ist eine regelmäßige Inventur. In der Verwaltung von Microsoft Entra ID, dem Verzeichnisdienst von Microsoft 365, sind die Unternehmensanwendungen und App-Registrierungen einsehbar. Dort sollten Einträge ehemaliger Dienstleister und nicht mehr benötigter Dienste auffallen und nach Klärung entfernt werden. Während eines laufenden Vorfalls gilt jedoch eine andere Reihenfolge: erst deaktivieren, nicht löschen (siehe nächster Abschnitt). Außerdem gehört in die Dokumentation, wer die Anwendung eingerichtet hat, ob Kunde, MSP oder ein Vorgänger. Ohne diese Information bleibt oft unklar, wer überhaupt zuständig ist.

Was Admins jetzt prüfen: Registrierung, Rollen, Secrets, Logs

Die folgenden Schritte geben die Empfehlungen von Huntress und ConnectWise in Alltagssprache wieder. Maßgeblich bleibt der technische Leitfaden von ConnectWise. Nach Angaben von heise dient dieser der Eindämmung, nicht der vollständigen Behebung. Anwendungs-Kennungen und IP-Adressen werden hier nicht abgetippt, weil Tippfehler bei Prüfungen zu falschen Ergebnissen führen. Sie sind in den genannten Primärquellen zu entnehmen.

1. Prüfen, ob ConnectWise Cloud Backup, SkyKick und weitere ConnectWise-Anwendungen aus dem Cloud-Management im Tenant vorhanden sind. Die Kennungen werden aus dem Leitfaden von ConnectWise und der Analyse von Huntress übernommen.
2. Betroffene Anwendungen deaktivieren statt löschen. Huntress empfiehlt, die Option zur Anmeldung für Benutzer auf „Nein“ zu stellen, denn beim Löschen geht die Einwilligung verloren und der Dienst müsste neu autorisiert werden. ConnectWise bittet Partner, die Verbindungen bis zu formellen Anweisungen deaktiviert zu lassen. Folge: Backups pausieren. Vorhandene Archive bleiben laut ConnectWise erhalten. Die Lücke bei der Datensicherung sollte bewusst abgewogen und gegebenenfalls anders überbrückt werden.
3. Die Grenze des Deaktivierens kennen. Es stoppt neue Token-Anfragen, bereits ausgestellte Token können laut ConnectWise bis zu ihrem Ablauf gültig bleiben. Nach Angaben von Todyl, wiedergegeben von BleepingComputer, beendet auch das Abmelden von Benutzersitzungen den anwendungsbasierten Zugriff nicht. Das ist eine Sekundärangabe. Nach Huntress entfernt das Deaktivieren außerdem keine Zugangsdaten, die bereits hinzugefügt wurden.
4. Secrets und Zertifikate aller Unternehmensanwendungen und App-Registrierungen auf unbekannte Einträge prüfen, besonders solche, die seit dem 13. Oktober 2026 hinzugekommen sind. Huntress beobachtete neue Secrets auf anderen Anwendungen mit Gültigkeit bis ins Jahr 2028.
5. Die Verzeichnisrollen der betroffenen Anwendungen prüfen, vor allem Global Administrator, Exchange Administrator und Privileged Authentication Administrator. Nicht beabsichtigte Rollen entfernen. Postfachweiterleitungen und Posteingangsregeln gehören laut ConnectWise ebenfalls auf die Liste.
6. Protokolle lesen. In den Anmeldeprotokollen von Entra ID (Sign-in-Logs) ist der Reiter für Anmeldungen von Dienstprinzipalen zuständig, nicht der Standardreiter für Benutzeranmeldungen. Die Audit-Protokolle zeigen Rollen- und Credential-Änderungen. Der Zeitraum 15. bis 16. Oktober 2026 ist besonders relevant. Die IP-Adressen aus den Mitteilungen von Huntress und ConnectWise dienen als Prüfhinweis, nicht als Beweis. Ein unauffälliges Ergebnis schließt einen Zugriff nach beiden Quellen nicht aus.
7. Protokolle sichern, bevor sie gelöscht werden (siehe nächster Abschnitt).

Bei Unsicherheit empfiehlt sich der Rückgriff auf den IT-Dienstleister oder auf einen externen Incident-Response-Dienst. Eine Prüfung von außen, wie sie bei Websites möglich ist, funktioniert für Tenant-Konfigurationen nicht. Die Einstellungen sind nur innerhalb des Tenants sichtbar.

Entra-Protokolle: 7 oder 30 Tage und dann weg

Die wichtigste Frist ist keine rechtliche, sondern eine technische. Nach der Dokumentation von Microsoft Learn (Stand der Seite: 25. März 2026) werden Anmelde- und Audit-Protokolle in Entra ID Free sieben Tage aufbewahrt, mit den Lizenzen P1 und P2 dreißig Tage. Änderungen gelten nicht rückwirkend, abgelaufene Daten sind nicht wiederherstellbar. Längere Aufbewahrung gelingt über einen Export, etwa nach Azure Monitor, oder bei bestimmten Lizenzen über Microsoft Purview Audit (Premium). Das Unified Audit Log von Microsoft 365 ist davon getrennt und hat eigene Aufbewahrungsfristen. Die Lizenzangaben sollten vor einer Entscheidung noch einmal gegen die aktuelle Microsoft-Seite geprüft werden.

Die Folge ist unbequem. Der Angriff vom 15. Oktober 2026 liegt am 22. Oktober 2026 genau sieben Tage zurück. In Tenants ohne Premium-Lizenz sind die Einträge von damals deshalb bereits gelöscht oder stehen kurz davor. Mit P1 oder P2 bleibt Zeit bis etwa Mitte November. Deshalb gilt: Sicherungen der relevanten Protokolle jetzt anlegen, am besten als Export in den Rohdaten. Screenshots sind ein schwacher Ersatz, weil sie weder vollständig noch prüfbar sind.

Ungesichert ist, ob alle Aktionen der Angreifer überhaupt protokolliert wurden. Heise berichtet, manche Aktionen seien eventuell nicht erfasst. Huntress betont, dass lesende Graph-Zugriffe keine Audit-Einträge erzeugen. Fehlende Protokolle sind kein Entwarnungssignal, sondern selbst ein Befund. Wer die Lage später gegenüber Aufsicht oder Kunden erklären muss, sollte genau diese Lücke dokumentieren. Mittelfristig lohnt ein dauerhafter Export der Protokolle, bei dem Kosten und Lizenz abzuwägen sind.

DSGVO: Wann Art. 33 und Art. 34 greifen

Keine Rechtsberatung: Datenschutzbeauftragte und Rechtsberatung einbeziehen.

Eine Verletzung des Schutzes personenbezogener Daten muss nach Art. 33 an die Aufsichtsbehörde gemeldet werden, möglichst binnen 72 Stunden, nachdem sie bekannt wurde. Das gilt nicht, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der betroffenen Personen führt. Bei voraussichtlich hohem Risiko sind zusätzlich die Betroffenen selbst zu benachrichtigen (Art. 34). Entscheidend ist also zweierlei: ob personenbezogene Daten betroffen sein können und ob Anhaltspunkte für einen Zugriff bestehen.

Bloße Anmeldeaktivität im Protokoll ohne weitere Hinweise löst keine automatische Meldung aus. Die Abwägung und ihre Begründung sollten aber schriftlich festgehalten werden. Art. 33 Abs. 5 verlangt eine Dokumentation von Verletzungen, was auch den Fall einschließt, dass nicht gemeldet wird. Anders liegt es bei Treffern: Eine erfolgreiche Anmeldung mit der Identität des Dienstes, unbekannte Rollen oder neue Secrets sind Anhaltspunkte, bei denen eine Meldung wahrscheinlich zu prüfen ist.

Wann genau die Frist beginnt, hängt davon ab, wann der Verantwortliche „Kenntnis“ erlangt. Die Leitlinien 9/2022 des Europäischen Datenschutzausschusses, abrufbar auf der Seite des EDSA, behandeln diese Frage und den Begriff der hinreichenden Gewissheit. Im Zweifel ist dort nachzulesen, weil der Zeitpunkt über die Rechtzeitigkeit der Meldung entscheiden kann. Zuständig ist die Aufsichtsbehörde des jeweiligen Landes. Wer sich fragt, ob eine Meldepflicht bei einer Datenpanne besteht, muss diese Prüfung also auch ohne sicheren Datenabfluss vornehmen.

Eine Registrierung im Tenant allein ist also noch keine Verletzung. Sie verlangt aber eine Prüfung, und diese Prüfung ist ohne gesicherte Protokolle kaum möglich. Damit schließt sich der Kreis zum vorigen Abschnitt.

MSP und Auftragsverarbeitung: Wer muss wen informieren

In einem typischen Szenario hat ein IT-Dienstleister die Backup-Lösung für den Kunden eingerichtet. Der Kunde ist dann Verantwortlicher im Sinne des Datenschutzrechts, der Dienstleister Auftragsverarbeiter, und der Backup-Anbieter gegebenenfalls Unterauftragsverarbeiter. Das ist ein übliches Modell, aber keine Gewissheit, denn die Einordnung hängt vom Vertrag und der tatsächlichen Ausgestaltung ab.

Aus dem Gesetz folgt: Ein Auftragsverarbeiter meldet Verletzungen dem Verantwortlichen unverzüglich (Art. 33 Abs. 2) und unterstützt ihn bei dessen Meldepflichten (Art. 28 Abs. 3 Buchstabe f). Für die Meldung an die Aufsicht bleibt der Verantwortliche zuständig. Wie sich die Kenntnis des Auftragsverarbeiters auf die Frist des Verantwortlichen auswirkt, regeln die EDSA-Leitlinien. Sie sollten vor einer Entscheidung im Wortlaut gelesen werden.

Für Kunden ergeben sich praktische Fragen. Hat der Dienstleister bereits informiert? Ist die Anwendung im Auftragsverarbeitungsvertrag oder in der Liste der Unterauftragnehmer genannt? Sind Meldewege und Fristen vertraglich geregelt? Wer diese Antworten nicht kennt, sollte sie jetzt einholen und die Anfrage dokumentieren.

Für Dienstleister gilt die Empfehlung von ConnectWise: den eigenen Tenant und alle verwalteten Kunden-Tenants anhand des Leitfadens prüfen, Kunden informieren und alles dokumentieren. ConnectWise betont nach Angaben von BleepingComputer, die Abschaltung des Dienstes sei kein Beleg für eine Kompromittierung einzelner Partner oder Kunden.

Die Täterfrage ist offen. ConnectWise nennt eine staatsnahe Gruppe unter Berufung auf Microsoft, eine unabhängige Bestätigung fehlt. Für die Maßnahmen spielt sie keine Rolle.

Was noch offen ist und was langfristig bleibt

Offen sind derzeit mehrere Punkte:

• Wie die Angreifer an das Zugangsdatum kamen (Huntress, heise).
• Die Gesamtzahl betroffener Tenants, also 162, 173 oder eine deutlich höhere Zahl.
• Ob und wo Daten gelesen oder abgezogen wurden.
• Ob von den Angreifern angelegte Zugänge und Rollen überall bereinigt sind. Heise nennt dies unklar.
• Wann die Dienste zurückkehren. ConnectWise nennt keine verlässliche Zeitangabe.
• Die Zuordnung zu bestimmten Tätern, bisher nur eine Herstellerangabe.

Nach Angaben von ConnectWise sind die Backup-Archive verschlüsselt und isoliert, es gebe keine Hinweise auf eine Kompromittierung der gespeicherten Backups, und andere Produkte seien nicht betroffen. Auch das ist eine Herstellerangabe, die hier nicht unabhängig geprüft werden konnte.

Langfristig lassen sich aus dem Fall nüchterne Punkte ableiten. Eine regelmäßige Inventur der Anwendungen im Tenant gehört dazu, ebenso das Prinzip, Rechte nur im nötigen Umfang zu vergeben. Anwendungen von Dienstleistern sollten in Verträgen und Unterauftragnehmerlisten auftauchen. Ein dauerhafter Export der Protokolle sorgt dafür, dass im Ernstfall Material vorliegt. Und ein Notfallplan für den Ausfall des Backup-Anbieters sollte eine zweite Kopie der Daten enthalten, die nicht vom selben Anbieter abhängt. Allgemeine Hinweise zum Umgang mit Anmeldedaten bietet der Beitrag zur Phishing-Erkennung für Mitarbeiter, auch wenn dieser Angriff kein Phishing war. Zum Thema Reaktionszeit passt ein Beitrag über Notfallpläne bei Angriffen, der sich zwar auf Websites bezieht, aber den Gedanken der schnellen Reaktion teilt.

Fazit in Kürze

Der Angriff nutzte eine Anwendungsidentität, bei der MFA nicht greift. Belegt ist der Missbrauch, offen sind Ursache, Umfang und Datenabfluss. Jetzt zählen Deaktivieren statt Löschen, Rollen und Secrets prüfen, Protokolle sichern und die Abwägung zur Meldepflicht dokumentieren.