ConnectWise hat sieben mit seiner Cloud-Backup-Umgebung verknüpfte App-Identitäten deaktiviert, nachdem Angreifer kompromittierte Anmeldedaten von Anwendungen genutzt hatten, um auf Microsoft-365-Tenants zuzugreifen.
Huntress bestätigte bis zum 16. Okt. unbefugte Anmeldungen in 162 Tenants, darunter einen Fall, in dem eine andere ConnectWise-Anwendung globale Administratorrechte erlangte und neue Anmeldedaten zu anderen Apps hinzufügte.
Der Zugriff auf Anbieterseite ist eingedämmt, aber für Microsoft-365-Administratoren ist der Vorfall noch nicht beendet. Die Deaktivierung der betroffenen Anwendungen macht keine bereits vorgenommenen Rollenänderungen, Anmeldedaten, Postfachregeln, Einwilligungen oder andere Persistenz rückgängig, die ein Angreifer möglicherweise bereits innerhalb eines Tenants eingerichtet hat.
In seiner aktuellen Sicherheitsanleitung für Cloud Backupfordert ConnectWise Partner dazu auf, ihre eigenen Microsoft-365-Umgebungen sowie jeden von ihnen verwalteten Kundentenant zu untersuchen – einschließlich Tenants mit alten oder inaktiven SkyKick-Verbindungen.
Was ConnectWise bisher bestätigt hat
Laut dem Status-Update von ConnectWise vom 19. Okt. blieben Cloud Backup, SaaS Security und Cloud Management ausgesetzt, während die Behebung und Sicherheitsvalidierung fortgesetzt wurden. Geplante Backups, Archivzugriff, Wiederherstellungen, Sicherheitsüberwachung und einige Verwaltungsfunktionen waren weiterhin nicht verfügbar; ein bestätigter Zeitpunkt für die Wiederherstellung lag nicht vor.
ConnectWise zufolge bleiben vorhandene Backup-Archive verschlüsselt und isoliert, und es gebe keine Hinweise darauf, dass auf diese Archive zugegriffen wurde. Das ist eine engere Aussage, als zu sagen, dass Microsoft-365-Tenants von Kunden nicht betroffen waren.
| Bestätigt | Noch ungeklärt |
|---|---|
| Der unbefugte Zugriff betraf ConnectWise-App-Identitäten | Wie die ursprünglichen Anmeldedaten des Anbieters offengelegt wurden |
| Sieben betroffene App-Identitäten wurden am 17. Okt. deaktiviert | Die vollständige Zahl der betroffenen nachgelagerten Tenants |
| Cloud Backup, SaaS Security und Cloud Management wurden ausgesetzt | Ob auf Daten in einzelnen Kundentenants zugegriffen wurde |
| ConnectWise hat keine Hinweise darauf, dass auf Backup-Archive zugegriffen wurde | Ob Angreifer in jedem erfolgreich aufgerufenen Tenant Persistenz eingerichtet haben |
| Huntress bestätigte unbefugte Microsoft-365-Anmeldungen | Identität und Motiv des Angreifers |
Laut Huntressauthentifizierte sich der Angreifer mit einem Anmeldedatum, das zur Cloud-Backup-Anwendung selbst gehörte, statt das Passwort eines Endbenutzers zu stehlen. Microsoft-Anmeldeprotokolle erfassten die Authentifizierung als Client Assertion.
Das verändert, wonach Verteidiger suchen müssen. Bei der reinen App-Authentifizierung führt kein Benutzer eine normale Anmeldung durch, daher wird nicht die MFA des Benutzers auf die Probe gestellt. Die Anwendung authentifiziert sich mit ihren eigenen Anmeldedaten und erhält den Zugriff, den ihre bestehenden Berechtigungen erlauben.
Diese Berechtigungen sind Teil desselben OAuth-Autorisierungsmodells, das Organisationen nutzen, um Drittanbieteranwendungen den Zugriff auf Cloud-Ressourcen zu ermöglichen, ohne wiederholt eine Person zur Anmeldung aufzufordern.
Huntress stellte außerdem eine zweite Welle von Versuchen gegen 16 Organisationen aus den Bereichen Politik, nationale Sicherheit, Handel und kritische Mineralien fest. Viele von ihnen nutzten die betroffenen ConnectWise-Produkte nicht, und die Versuche scheiterten, wenn der erforderliche Dienstprinzipal nicht vorhanden war.
Was Microsoft-365-Admins jetzt prüfen sollten
ConnectWise empfiehlt, Aktivitäten ab dem 13. Okt. zu überprüfen und die Suche, soweit es die Protokollaufbewahrung erlaubt, bis zum 1. Okt. zurück auszudehnen.
Beginnen Sie mit Anmeldungen von Dienstprinzipalen und nicht nur mit der Ansicht für Benutzeranmeldungen. Die Dokumentation zu Dienstprinzipalen von Microsoft erklärt, dass diese Datensätze die Authentifizierung von Anwendungen mit Anmeldedaten wie Zertifikaten und Clientgeheimnissen erfassen.
Die zu prüfende Anwendungs-ID von Cloud Backup lautet:
506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise hat außerdem drei mit der verdächtigen Aktivität verbundene IP-Adressen veröffentlicht:
144.172.64[.]128144.172.64[.]99144.172.64[.]60
Ein Treffer sollte eine Untersuchung auslösen, nicht automatisch zu dem Schluss führen, dass der Tenant kompromittiert wurde.
Administratoren sollten außerdem Folgendes überprüfen:
- Neue oder geänderte Anwendungsanmeldedaten.
- Verzeichnis- und Administratorrollenzuweisungen.
- Anwendungsbesitzer und erteilte Einwilligungen.
- Föderationsvertrauensstellungen und Authentifizierungsänderungen.
- Aktuelle Änderungen an Conditional Access oder anderen Richtlinien.
- Postfachweiterleitungen, Posteingangsregeln, Transportregeln und delegierte Zugriffe.
- Andere Benutzer- oder App-Identitäten, die während des verdächtigen Zeitraums geändert wurden.
Das eigene Playbook für kompromittierte Anwendungen von Microsoft empfiehlt, bei einer möglicherweise kompromittierten App-Identität die Anmeldungen von Dienstprinzipalen, unerwartete Anmeldedaten, privilegierte Anwendungsrollen und ungewöhnliche Berechtigungsänderungen zu prüfen.
Diese umfassendere Prüfung ist wichtig, weil das Entfernen der ursprünglichen ConnectWise-Anmeldedaten keine zweite Anmeldemöglichkeit, Rollenzuweisung oder Zugriffsmöglichkeit entfernt, die ein Angreifer nach dem Eindringen eingerichtet hat.
Kasper Lindgaard, Vice President of Security Strategy bei CoreView, erklärte, eine erfolgreiche Anmeldung sollte die Reaktion über die bloße Prüfung hinaus erweitern, ob die betroffenen ConnectWise-Anwendungen deaktiviert sind.
„Wenn es Hinweise auf eine erfolgreiche Anmeldung durch den Angreifer gibt, sollte der Vorfall als Vorfall mit Konfigurationsänderung behandelt werden. Das bedeutet, alle nicht bestätigbaren Änderungen, die zwischen dem 1. Oktober und dem 17. Oktober um 07:00 UTC vorgenommen wurden, eindeutig zu erfassen und rückgängig zu machen.
Lindgaard fügte hinzu:
„ConnectWise hat den Angriff gestoppt. Doch Unternehmen tragen leider die Verantwortung und die schwierige Aufgabe sicherzustellen, dass der Angreifer keine Microsoft-365-Konfiguration geändert und keine Persistenz in ihrem Tenant eingerichtet hat. Mehr als ein Drittel der IT-Führungskräfte glaubt fälschlicherweise, dass Microsoft ihre Konfiguration automatisch sichert, was die Wiederherstellung nach einem solchen Angriff noch schwieriger macht.“
Das bedeutet, dass Administratoren eine Vorher-Nachher-Ansicht des Tenants benötigen und nicht nur nach den veröffentlichten IP-Adressen suchen sollten. Auf eine erfolgreiche App-Anmeldung können ein neues Secret, eine privilegierte Rolle, eine Postfachregel, eine Einwilligung oder eine Richtlinienänderung folgen – und so einen Zugriffspfad hinterlassen, nachdem die ursprüngliche Anwendung abgeschaltet wurde.
Apps noch nicht wieder verbinden
ConnectWise zufolge sollten betroffene Verbindungen deaktiviert bleiben, bis das Unternehmen formelle Anweisungen zur Wiederherstellung und erneuten Autorisierung veröffentlicht.
Admins sollten außerdem verfügbare Protokolle sichern, bevor sie unnötige Löschungen vornehmen. ConnectWise rät ausdrücklich, die Unternehmensanwendungen während der ersten Untersuchung bestehen zu lassen, damit ihre Konfiguration und Identifikatoren weiterhin als Beweismittel verfügbar sind.
Der Vorfall legt außerdem eine grundsätzliche Schwachstelle bei langlebigen Anwendungszugriffen offen. Organisationen müssen zunehmend nichtmenschliche Identitäten wie Dienstprinzipale, Anwendungsidentitäten, API-Anmeldedaten und automatisierte Agenten neben menschlichen Konten verwalten.
Diese Identitäten benötigen benannte Verantwortliche, Berechtigungen nach dem Prinzip der geringsten Privilegien, eine regelmäßige Erneuerung der Anmeldedaten, nutzbare Protokollierung und regelmäßige Überprüfungen. Dieselben Kontrollen sollten auch zum routinemäßigen Risikomanagement für Drittanbieter bei SaaS-Anbietern gehören, die dauerhaft Zugriff auf sensible Cloud-Umgebungen behalten.
Für ConnectWise-Kunden ist die unmittelbare Aufgabe enger umrissen: Beweise sichern, jede relevante Anmeldung eines Dienstprinzipals finden, während des Zeitfensters der Gefährdung vorgenommene Änderungen untersuchen, Persistenz entfernen und die betroffenen Anwendungen deaktiviert lassen, bis ConnectWise erklärt, dass eine erneute Verbindung sicher ist.
Außerdem lesen: TeamFiltration-Hacker nutzten vergessene Microsoft-365-Dienstkonten aus, ein weiteres Beispiel dafür, wie nichtmenschliche Identitäten einen übersehenen Zugang zu Cloud-Umgebungen schaffen.