Die meisten Unternehmen glauben zu wissen, wo ihre Türen stehen. Da ist die Login-Seite, die Passwortrichtlinie, die Authenticator-App, die um zwei Uhr nachts vibriert, und die Conditional-Access-Regel, die ein verdächtiges Land blockiert. Sicherheitsteams feilen jahrelang daran.
Dann kommt ein Backup-Dienst durch eine Tür, die nie im Grundriss stand.
Zwischen 06:13 und 08:34 UTC am 15. Oktober 2026 nutzte ein unbekannter Akteur einen kompromittierten Vendor-Zugang von ConnectWise Cloud Backup, früher SkyKick, um Microsoft-Graph-Tokens in Microsoft-365-Mandanten zu erhalten, in denen die App installiert war. Huntress bestätigte unbefugte Anmeldungen in 173 Partner- und Kundenmandanten. Die weitere Telemetrie zeigte Anmeldeaktivität von derselben Adresse gegen fast 1.000 Entra-Mandanten, über 300 davon erfolgreich. Der Verkehr lief in sortierter GUID-Reihenfolge, wenige Sekunden pro Mandant. So sieht ein Skript aus, das eine Zielliste abarbeitet, nicht ein Mensch.
Niemand tippte ein Passwort. Niemand bestätigte eine Push-Nachricht. Die App tat genau, wofür sie gebaut wurde.
Was der Angreifer geerbt hat
ConnectWise Cloud Backup schützt Daten in Microsoft 365 und Google Workspace für Managed Service Provider und deren Kunden. Dafür erhält sie eine breite, dauerhafte Zustimmung: Lesen und Schreiben in Postfächern, OneDrive, SharePoint, Teams-Chats und Verzeichnisinformationen, inklusive Wiederherstellungsrechten.
Wer diese Zugangsdaten hat, muss nichts eskalieren. Er erbt alles. Laut der Analyse von Todyl umfasste der Zugriff volle Postfachrechte über Exchange Web Services, Dateizugriff in OneDrive und SharePoint, Teams-Nachrichten und Verzeichnislesezugriff, samt Wiederherstellung. Das ist kein Standbein. Das ist das ganze Netz.
Die Anmeldung kam von 144.172.64[.]128 aus dem RouterHosting-Bereich. Legitime Service-Principal-Anmeldungen dieser Anwendung laufen normalerweise aus dem privaten IPv6-Raum von Azure. Der Fehler war also für jeden sichtbar, der danach filterte. Der entscheidende Halbsatz ist „der danach filterte“: Service-Principal-Anmeldungen liegen in einem eigenen Tab in Entra. Wer nur Benutzeranmeldungen überwacht, hat dieses Ereignis nie gesehen.
Warum MFA und Conditional Access nie ausgelöst wurden
MFA authentifiziert Menschen. Conditional-Access-Richtlinien werden gegen Benutzer und Gruppen geschrieben. Eine Anwendung, die sich mit eigenem Secret oder Zertifikat anmeldet, ist keins von beidem. Sie ist ein Service Principal, und ihr Token wird ausgestellt, weil die Zugangsdaten passen, nicht weil jemand eine Challenge bestanden hat.
Die üblichen Kontrollen wurden also nicht umgangen. Sie waren schlicht nicht zuständig. Der Perimeter war hier keine Identitätsprüfung, sondern Zustimmung: Jeder Mandant, in dem die App genehmigt war, war mit einem einzigen Zugang erreichbar. Auch das Zurücksetzen von Benutzersitzungen hilft nicht. Deaktivieren stoppt neue Tokens, aber bereits ausgestellte bleiben bis zu 90 Minuten gültig, genug für einen automatisierten Durchlauf.
Die zweite Wunde: eine App, die sich selbst krönte
In mindestens zwei Mandanten ging das Verhalten über Lesen hinaus. Gegen 03:45 UTC, innerhalb von zwei Minuten, vergab die ConnectWise Cloud Management App für Microsoft Teams sich selbst die Rolle des globalen Administrators und führte ein Skript (Python-urllib/3.12) aus, das neue Client-Secrets bei anderen registrierten Anwendungen hinterlegte. In einem Fall betraf das eine Huntress-Anwendung, separat auch eine MSP-Management-Anwendung.
Denken Sie an die Form. Eine Management-App ist genau die Art Werkzeug, die MSPs in die Mandanten ihrer Kunden zulassen. Ein dort hinterlegtes Secret gilt nicht für einen Mandanten, sondern ist ein Schlüssel, der in jedem Mandanten funktionieren kann, der diesem Werkzeug vertraut. Huntress entfernte den unbefugten Zugang am 16. Oktober aus der eigenen Anwendung und aktivierte App Instance Property Lock.
Huntress hielt auch fest, was nicht beobachtet wurde: keine Manipulation von Postfächern oder Dateien, keine Benutzer- oder Richtlinienänderungen in den zwei geprüften Mandanten. Und eine Warnung, die mehr wiegt als die Abwesenheit von Beweisen: Graph-Verzeichnisabfragen hinterlassen meist gar keinen Prüfeintrag. Man kann nicht beweisen, dass Daten unberührt blieben, wenn die Abfragen nie protokolliert wurden.
Der Rest des Tages
Dieselbe Adresse wurde am 15. Oktober in einer zweiten, engeren Welle genutzt, zwischen 09:25 und 12:35 UTC und erneut von 13:54 bis 14:20 UTC, gegen 16 von Huntress geschützte Mandanten aus Politik, nationaler Sicherheit, Handel und kritischen Rohstoffen. Die meisten nutzten keine ConnectWise-Produkte, die Versuche scheiterten also, weil die App nicht vorhanden war. Genau das ist das Argument für minimale Rechte in einem Satz: Die Abwesenheit der App war die Kontrolle, die sie gerettet hat.
Dieselbe Infrastruktur hatte am 13. und 14. Oktober bereits Password Spraying gegen vier Anwaltskanzleien gefahren. ConnectWise hat den Cloud-Backup-Zugang bis auf Weiteres deaktiviert und erklärt, es gebe keine Hinweise auf kompromittierte Partner-Backups.
Was diese Woche zu tun ist, nicht nächstes Quartal
- Öffnen Sie die Service-Principal-Anmeldeprotokolle. Im Microsoft-Entra-Admincenter unter Überwachung, Anmeldeprotokolle, Tab „Service-Principal-Anmeldungen“. Filtern Sie auf die Anwendungs-ID 506e08f9-6e9a-4da4-942b-a099a03644ae und prüfen Sie den 15. Oktober. Wiederholen Sie das für Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519, Teams 24205314-2b89-4e07-a2a4-579e898a5640 und SharePoint b2b55f5b-7758-4719-8d8f-88ae172e6bdb.
- Suchen Sie die fehlplatzierte Adresse. Jede Authentifizierung außerhalb der erwarteten Microsoft-Bereiche ist ein Befund. 144.172.64[.]128 ist der Hauptindikator, 144.172.64[.]99, .60 und 144.172.94[.]243 tauchen in verwandten Fehlversuchen auf.
- Deaktivieren statt löschen. Löschen zerstört die Prüfspur, die Sie gleich brauchen. Lassen Sie die Apps deaktiviert, bis ConnectWise die Rotation bestätigt.
- Prüfen Sie jedes neue Secret und Zertifikat, das seit dem 13. Oktober bei einer App-Registrierung hinzugefügt wurde, inklusive föderierter Anmeldedaten. Ein unerwartetes Ablaufdatum 2027 oder 2028 ist ein Persistenzmerkmal.
- Prüfen Sie Verzeichnisrollenzuweisungen für Anwendungen und den Verlauf der Privileged Identity Management-Vergaben.
- Aktivieren Sie Graph-Aktivitätsprotokolle und Unified Audit Logging jetzt. Abfragen, die nie aufgezeichnet wurden, lassen sich nicht untersuchen.
- Gehen Sie davon aus, dass lesbare Daten gelesen wurden. Prüfen Sie Postfachregeln und Weiterleitungen, Freigabelinks, und informieren Sie die Verantwortlichen für Vertraulichkeit.
- Reduzieren Sie dauerhafte Zustimmungen. Minimale Bereiche, App Instance Property Lock, eingeschränkte Benutzerzustimmung und eine regelmäßige Prüfung jeder Drittanbieter-App in jedem Mandanten.
Die Lehre für wachsende Unternehmen
Wer ein Unternehmen mit 40 Mitarbeitenden auf Microsoft 365 betreibt, hat fast sicher einige Apps, die vor Jahren von jemandem genehmigt wurden, der nicht mehr da ist, jede mit breitem Dauerzugriff. Das ist dieselbe Exposition, nur kleiner.
Die unbequeme Lehre des 15. Oktober ist nicht, dass ConnectWise nachlässig war. Sie ist, dass unser Denkmodell von Identitätssicherheit beim Menschen endet. Service Principals, Zustimmungen und App-Zugangsdaten sind der eigentliche Perimeter eines modernen Mandanten, und in den meisten Organisationen gehört er niemandem.
Ein Zugang. Einhundertdreiundsiebzig Mandanten. Nirgends eine MFA-Abfrage. Bringen Sie das Inventar in Ordnung, bevor das Inventar Sie in Ordnung bringt.