ConnectWise Cloud Backup: Angriff trifft M365-Tenants

Ein Backup-Dienst als Einfallstor: Angreifer haben sich mit gestohlenen Application-Identities von ConnectWise Cloud Backup (früher SkyKick) als vertrauenswürdige Anwendung bei Microsoft 365 angemeldet – ohne Nutzerpasswort, ohne MFA-Wirkung. Bestätigt sind bislang 173 kompromittierte Tenants, doch diese Zahl markiert eher die Unterkante. Wer den Dienst einsetzt, hat jetzt wenige Tage Zeit, Spuren zu sichern, bevor sie verfallen.

ConnectWise Cloud Backup: Der Angriff nutzt App-Credentials, keine Passwörter

Der Kern des Vorfalls ist kein geklautes Kennwort, sondern ein Satz von Anmeldedaten, der für Maschine-zu-Maschine-Kommunikation gedacht war. Die Backup-Anwendung meldet sich per OAuth-Client-Assertion bei Microsoft Entra ID an und erhält Access Tokens mit exakt den Berechtigungen, die ihr zuvor erteilt wurden. Wer diese Credentials kontrolliert, ist für Microsoft 365 keine fremde Person, sondern die Anwendung selbst.

Sieben Application Identities waren betroffen. Die Anmeldungen liefen über die App-ID 506e08f9-6e9a-4da4-942b-a099a03644ae und die IP-Adresse 144.172.64.128. In den Protokollen tauchen User-Agents wie curl/7.88.1, python-urllib/3.12 und python-requests/2.31 auf – Werkzeuge, die ein Backup-Dienst im Regelbetrieb nicht verwendet.

Warum MFA nicht greift – und was Application Identity bedeutet

MFA schützt die interaktive Anmeldung eines Menschen. Hier findet keine statt. Der Angreifer authentifiziert sich als registrierte Anwendung, nicht als Benutzer – damit läuft der gesamte Mechanismus an jedem MFA-Prompt vorbei. Der Vorfall wird als aktiver Lieferkettenangriff eingestuft, und bestehende Berechtigungen wurden missbraucht, darunter Directory.ReadWrite.All. Übersetzt: Verzeichnisdaten lesen und schreiben.

Für die Bewertung ist ein Unterschied zentral: Eine erfolgreiche Anmeldung ist noch kein Datenzugriff. Möglich war der Zugriff auf Exchange Online samt Mailboxen und Anhängen, auf OneDrive, SharePoint, Teams-Chats und Verzeichnisdaten. Wie viel davon tatsächlich abgeflossen ist, weiß niemand – Graph-Lesezugriffe auf das Verzeichnis hinterlassen teils keine Audit-Spur.

Wer bis hierhin glaubt, das betreffe nur große Konzerne, übersieht die Rolle von Managed Service Providern. Der Dienst sitzt typischerweise eine Ebene über dem eigentlichen Kunden, und genau diese Position macht ihn als Sprungbrett wertvoll.

173 bestätigte Tenants, über 300 erfolgreiche Anmeldungen

Fast 1.000 Entra-Tenants zeigten Anmeldeaktivität von der Angreifer-IP, über 300 davon erfolgreich. Die bestätigten Kompromittierungen lagen zunächst bei 162 Tenants und wurden später auf 173 korrigiert. Die tatsächliche Zahl bleibt offen, weil niemand außerhalb der Kundenumgebungen vollständigen Einblick hat.

Zeitlich zog sich das so: erste, erfolglose Anmeldeversuche ab dem 13. Oktober 2026, erfolgreiche unbefugte Anmeldungen ab dem 15. Oktober. Die letzte beobachtete bösartige Anmeldung von der Original-Adresse erfolgte am 15. Oktober um 08:45 UTC. Am selben Tag gab es eine zweite, gezielte Welle gegen 16 Tenants aus den Bereichen Politik, nationale Sicherheit, Handel und kritische Mineralien, die nach derzeitigem Stand scheiterte.

Erkannt wurde der Vorfall am 14. Oktober, abgeschaltet am 17. Oktober um 07:00 UTC – die Zertifikate der betroffenen Applikationsverbindungen wurden für alle Nutzer widerrufen. Ebenfalls offline sind SaaS Security und Cloud Management. Für betroffene Umgebungen heißt das konkret: Es laufen keine geplanten Backups, und Wiederherstellungen aus den betroffenen Archiven sind derzeit nicht möglich.

Persistenz prüfen: Directory Roles, Client Secrets, Mailbox-Forwarding

In mindestens einem Tenant hat sich die App „Cloud Management – MS Teams" (24205314-2b89-4e07-a2a4-579e898a5640) selbst die Global-Administrator-Rolle zugewiesen und per Python-Skript neue Client Secrets auf eine MSP-Management-Anwendung und auf eine Huntress-Anwendung gesetzt. In knapp 50 überwachten Tenants wiesen sich Service Principals der Cloud-Management-Apps für Exchange Online, Teams und Microsoft Graph Verzeichnisrollen zu, überwiegend „Exchange Administrator".

Es gibt allerdings auch Gegenläufiges: In neun genauer untersuchten Tenants fand sich ausschließlich Anmeldeaktivität, keine Spur von Persistenz. Der Umfang der Eskalation ist also umstritten – was nichts daran ändert, dass jeder Betreiber selbst nachsehen muss.

Die Deaktivierung verhindert nur neue Authentifizierungen und macht keine bereits im Tenant vorgenommenen Änderungen rückgängig. Bereits ausgestellte Tokens bleiben bis zu 90 Minuten gültig – die Abschaltung stoppt lediglich die Neuausstellung. Wer jetzt nur auf das Ende des Dienstes wartet, wartet zu lange.

Zu prüfen sind: Application Credentials und neu gesetzte Client Secrets, Directory Roles und Global-Administrator-Zuweisungen, Consent Grants, Conditional Access Policies sowie Mailbox-Forwarding-Regeln. Vor jeder Bereinigung gehören die Logs exportiert.

Sieben Tage: Die Log-Aufbewahrung ist die eigentliche Deadline

Ohne erweitertes Logging löscht Microsoft Entra ID Anmeldeprotokolle nach sieben Tagen, mit Entra ID P1 oder P2 nach 30 Tagen. Bei einem Vorfall, der am 13. Oktober begann und erst Tage später öffentlich wurde, ist das ein enges Fenster. Wer die Protokolle nicht sofort sichert, verliert den Nachweis darüber, ob die eigene Umgebung betroffen war.

Der praktische Ablauf: in den Entra Sign-in Logs auf „Service principal sign-ins" wechseln, auf die App-ID 506e08f9-6e9a-4da4-942b-a099a03644ae filtern und nach der IP 144.172.64.128 sowie nach ungewöhnlichen User-Agents suchen. Zusätzlich gibt es eine PDF-Prüfanleitung.

Fazit: Prüfen, rotieren, dokumentieren

Der Fall zeigt eine Lücke, die viele Teams unterschätzen: Workload-Identities haben oft mehr Rechte als jeder Mensch im Tenant und werden deutlich seltener kontrolliert. Ein Passwort-Reset hilft hier nicht, weil kein Benutzerkonto kompromittiert wurde. Wer nach dem Vorfall nur Passwörter wechselt, hat nichts gewonnen.

Offen bleibt, wie die Angreifer an die Credentials gelangten und ob eine Produktschwachstelle ursächlich war – dazu laufen Untersuchungen. Ebenso unbekannt ist der Urheber. Zu den Backup-Archiven selbst gibt es bislang keine Hinweise auf eine Kompromittierung; sie sollen verschlüsselt, isoliert und unverändert geblieben sein, eine unabhängige Bestätigung dafür fehlt jedoch.

Bis dahin gilt: Service-Principal-Anmeldungen der letzten Wochen auswerten, verdächtige Client Secrets rotieren, Rollenzuweisungen gegen den Soll-Zustand abgleichen und die Logs sichern, bevor die Retention sie löscht.

Quellen