Ein Unternehmen schützt seine Microsoft-365-Konten mit Mehrfaktor-Authentifizierung und sichert E-Mails sowie Dokumente über einen Dienstleister. Trotzdem kann ein Angreifer Zugang erhalten, ohne einen Mitarbeiter anzumelden: Er verwendet die Identität der Sicherungsanwendung. Der aktuelle Vorfall bei ConnectWise Cloud Backup, ehemals SkyKick, zeigt diese andere Seite der Cloud-Sicherheit. Nicht das Benutzerkonto, sondern eine bereits autorisierte Anwendung wird zum Vertrauensproblem.
Der neue operative Anlass sind die Hersteller-Updates vom 18. Oktober 2026: Cloud Backup bleibt ausgesetzt; auch SaaS Security und Cloud Management wurden vorsorglich angehalten. Damit treffen Sicherheitsprüfung und Wiederherstellungsfähigkeit unmittelbar aufeinander. Dieser Artikel berücksichtigt den Informationsstand vom 19. Oktober, 02:30 Uhr MESZ. Die ursprünglichen verdächtigen Anmeldungen stammen vom 15. Oktober. [1][2]
Was der Hersteller inzwischen bestätigt
ConnectWise erklärt, am 17. Oktober um 07:00 UTC sieben Anwendungsidentitäten deaktiviert und Zertifikate betroffener Verbindungen widerrufen zu haben. Die betroffenen gemeinsamen Cloud-Backup-Zugangsdaten seien nicht mehr gültig. Bereits ausgestellte Zugriffstokens könnten jedoch bis zu ihrem Ablauf oder einer anderweitigen Ungültigmachung weiter nutzbar bleiben. [1]
Zum ausgewerteten Stand liefen weder geplante Backups noch Archivzugriff und Wiederherstellungen. Für vorhandene Sicherungsarchive meldet der Hersteller Verschlüsselung und Isolation sowie keine Hinweise auf eine Kompromittierung. Das ist keine Entwarnung für die produktiven Microsoft-365-Mandanten: ConnectWise trennt ausdrücklich zwischen gespeicherten Archiven und möglicher Aktivität in den angeschlossenen Kundenumgebungen. Einen bestätigten Wiederanlaufzeitpunkt nennt das Unternehmen nicht. [1]
Die sonntäglichen Aktualisierungen sind deshalb mehr als eine Wiederholung der ersten Warnung: Sie präzisieren die Betriebsunterbrechung, die Eindämmung und die weiterhin erforderliche Prüfung jedes einzelnen Mandanten.
Der technische Mechanismus: Anmeldung ohne Mitarbeiter
Todyl beschreibt den Missbrauch einer legitimen mandantenfähigen Anwendung. Kunden hatten dieser Anwendung zuvor Berechtigungen erteilt. Wer ihre gültigen Anmeldemittel besitzt, kann im OAuth-Client-Credentials-Verfahren als Anwendung Tokens anfordern und damit die bereits genehmigten Rechte nutzen. Es braucht dafür keine neue Zustimmung eines Mitarbeiters. [3]
Der Unterschied zu einem gestohlenen Benutzerpasswort ist wesentlich: Eine solche App-only-Anmeldung löst keinen gewöhnlichen MFA-Dialog für einen Menschen aus. Das Zurücksetzen eines Mitarbeiterpassworts oder das Beenden seiner Sitzungen unterbindet diesen Zugriff daher nicht. Welche Daten und Verwaltungsoperationen erreichbar sind, hängt von den tatsächlich vergebenen Anwendungsberechtigungen ab. [3][4]
Für die Bestandsaufnahme ist die Cloud-Backup-Anwendungs-ID 506e08f9-6e9a-4da4-942b-a099a03644ae aussagekräftiger als der Anzeigename. Ältere Installationen können noch SkyKick heißen. Die vom Hersteller veröffentlichte Liste umfasst außerdem mehrere Cloud-Management-Anwendungen; eine Suche ausschließlich nach „Backup“ wäre zu eng. [1][4]
Warum das Abschalten nicht alle Zugänge beseitigt
Huntress berichtet für einen untersuchten Kundenmandanten einen weitergehenden Ablauf: Eine Cloud-Management-Anwendung für Microsoft Teams habe sich die Rolle Global Administrator zugewiesen und anschließend neue Zugangsdaten zu zwei anderen Anwendungen hinzugefügt. Darunter war eine mandantenspezifische Huntress-Anwendung. [2]
Damit verändert sich das Ziel der Untersuchung. Ein Angreifer muss nicht an der ursprünglich missbrauchten Identität festhalten. Ein neu hinzugefügtes Secret einer anderen vertrauenswürdigen Anwendung kann einen separaten Rückweg schaffen. Die Sperrung der ursprünglichen App entfernt dieses Secret nicht. [2]
Die Zahlen müssen zeitlich eingeordnet werden: Huntress nannte zunächst 162 Mandanten mit bestätigten unautorisierten Anmeldungen. Im Update vom 17. Oktober meldete das Unternehmen fast 1.000 Mandanten mit Anmeldeaktivität von der zugeordneten IP-Adresse, davon mehr als 300 mit erfolgreichen Anmeldungen. Diese Angaben sind weder ein abgeschlossener weltweiter Opferstand noch ein Nachweis für Datenabfluss bei jeder erfolgreichen Anmeldung. [2]
Sichtbarkeit ist eine eigene Sicherheitsgrenze
Todyl fand in seinen untersuchten Mandanten keine entsprechenden Änderungen an Verzeichnisrechten oder Anwendungszugängen. Das widerspricht dem detaillierteren Huntress-Befund nicht zwangsläufig: Die Unternehmen untersuchten unterschiedliche Umgebungen und Beobachtungszeiträume. [2][3]
Auch bei Datenzugriffen bleibt die Beweislage begrenzt. Todyl beschreibt, dass legitimer Sicherungsbetrieb und unerlaubte Zugriffe dieselbe Anwendungsidentität verwenden können. Ohne zusätzlich erhobene Graph-Aktivitätsprotokolle ließ sich vorhandene Leseaktivität dort nicht zuverlässig dem Angreifer oder dem Sicherungsdienst zuordnen. [3]
Die sinnvolle Schlussfolgerung lautet deshalb nicht „alles wurde kopiert“, aber ebenso wenig „keine sichtbare Exfiltration bedeutet keine Exfiltration“. Incident-Teams sollten erfolgreiche Authentifizierung, Rechteänderung, Persistenz und nachgewiesenen Datenzugriff getrennt dokumentieren.
Was Unternehmen jetzt konkret organisieren sollten
Erstens: Alle betroffenen Mandanten zuordnen. Die Prüfung sollte den eigenen MSP-Mandanten und sämtliche verwalteten Kundenumgebungen umfassen. Verantwortliche sollten auch stillgelegte Verträge und geerbte SkyKick-Verbindungen berücksichtigen. Entscheidend ist, ob eine autorisierte Anwendung noch existiert, nicht ob die Rechnung aktuell bezahlt wird. [1][3]
Zweitens: Eindämmung lokal verifizieren. ConnectWise verlangt, die betroffenen Verbindungen deaktiviert zu halten und lokale Einstellungen zu prüfen. Die herstellerseitige Maßnahme ist nicht dasselbe wie eine dokumentierte Prüfung jedes Kundenmandanten. Anwendungen sollten nicht vorschnell gelöscht werden; zunächst sind Konfiguration und Beweismittel zu erhalten. [1]
Drittens: Andere Identitäten mit untersuchen. Die Überprüfung sollte neue Secrets, Zertifikate, Eigentümer, Rollenzuweisungen und Zustimmungen einschließen. Zusätzlich nennt die Herstelleranleitung Postfachweiterleitungen, Posteingangs- und Transportregeln sowie delegierten Postfachzugriff. Ein Suchlauf ausschließlich nach der ursprünglichen Backup-App reicht nicht. [1][2]
Viertens: Protokolle sichern, ohne Eindämmung aufzuschieben. Service-Principal-Anmeldungen gehören ausdrücklich in die Untersuchung; die Standardansicht für Benutzeranmeldungen genügt nicht. ConnectWise empfiehlt die Prüfung ab dem 13. Oktober und für eine breitere Eingrenzung ab dem 1. Oktober, soweit Daten vorhanden sind. Fehlende Aufbewahrung sollte als Erkenntnisgrenze dokumentiert werden. [1]
Fünftens: Die Sicherungslücke als Betriebsrisiko behandeln. Unsere Empfehlung: Verantwortliche sollten den letzten verifizierten Wiederherstellungspunkt, die geschäftlich tolerierbare Sicherungslücke und alternative Wiederherstellungswege schriftlich festhalten. Eine vorschnelle Reaktivierung nur zur Wiederaufnahme des Backupplans wäre die falsche Abkürzung. Sicherheitsfreigabe und Wiederanlaufplanung brauchen gemeinsame Entscheidungskriterien.
Branchenkontext: Dienstleisterzugänge sind privilegierte Infrastruktur
Der Fall spricht für eine Architekturprüfung jenseits dieses Produkts. Backup-, Verwaltungs- und Security-Anwendungen sollten im Risikoinventar nicht als harmlose Integrationen geführt werden. Empfehlenswert sind benannte Verantwortliche, dokumentierte Berechtigungen, regelmäßige Stilllegungsprüfungen und eine nachvollziehbare Überwachung von Identitätsänderungen.
Das gilt als abgeleitetes Architekturprinzip ebenso für KI-Agenten und deren Cloud-Werkzeuge: Die Sicherheit eines Benutzerkontos begrenzt nicht automatisch die Rechte einer separat autorisierten Maschinenidentität. Wer einem Agenten einen Connector bereitstellt, sollte dessen tatsächliche Berechtigungen, Credential-Verwaltung und Abschaltmöglichkeiten unabhängig vom Modell bewerten. Der aktuelle Vorfall ist allerdings kein Beleg für eine Beteiligung von KI-Agenten.
Grenzen und Fazit
Die ausgewerteten Quellen klären weder abschließend die Herkunft des kompromittierten Anmeldemittels noch den gesamten möglichen Datenabfluss. Private Cloud-Adressen oder gebräuchliche Skript-Clients sind allein kein belastbarer Täternachweis. Ebenso wenig bedeutet ein unauffälliger Protokollsuchlauf automatisch einen unverletzten Mandanten. [1][2]
Für Unternehmen stehen deshalb drei Aufgaben nebeneinander: betroffene Anwendungen deaktiviert halten, unabhängige Persistenzpfade untersuchen und die ausgefallene Wiederherstellungsfähigkeit beherrschbar machen. Die zentrale Lehre ist konkret: Eine vertrauenswürdige Sicherungsanwendung bleibt eine privilegierte Identität. Ihre Zugangsdaten und Folgerechte verdienen dieselbe Aufmerksamkeit wie administrative Benutzerkonten.
Quellen
[1] ConnectWise Trust Center: laufendes Incident-Advisory, insbesondere Updates vom 18. Oktober 2026 und technische Untersuchungsanleitung. https://www.connectwise.com/company/trust/advisories
[2] Huntress: ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks, einschließlich Update vom 17. Oktober 2026. https://www.huntress.com/blog/vendor-credential-enables-unauthorized-access
[3] Todyl: Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App, 16. Oktober 2026. https://www.todyl.com/blog/investigation-unauthorized-access-through-the-connectwise-cloud-backup-microsoft-365-app
[4] SpecterOps: ConnectWise SkyKick Breach: How to Check Your Microsoft 365 Tenant, 17. Oktober 2026. https://specterops.io/blog/2026/10/17/connectwise-skykick-breach-microsoft-365/