ConnectWise: Für das App-Konto war keine MFA nötig

Der Angreifer meldete sich als Anwendung an

Ihre Benutzer bestanden die MFA-Prüfung. Der Angreifer meldete sich als Anwendung an. Das ist die Identitätsgrenze hinter dem ConnectWise-Cloud-Backup-Vorfall: Anwendungszugangsdaten wurden genutzt, um Zugriff mit bereits in Kundentenants erteilten Berechtigungen anzufordern. Eine Kontrolle für die Anmeldung eines Menschen war auf diesem Pfad nie die Schranke.

Das am 20. Oktober 2026 geprüfte ConnectWise-Advisory bestätigt unberechtigten Zugriff auf Anwendungsidentitäten und beschreibt die Eindämmung. Wie die ursprünglichen Zugangsdaten offengelegt wurden, wird weiterhin untersucht. Dieser Beitrag analysiert die Architektur anhand von Quellen; er ist keine Nachstellung in einem aktiven Tenant. Die bleibende Frage lautet, welchen Zugriff eine Integration behält, wenn die Zugangsdaten ihres Betreibers in fremde Hände geraten. [1][2]

Zustimmung schafft eine Identität mit dauerhaften Rechten

Anwendungsberechtigungen unterscheiden sich von delegierten Berechtigungen. Im Client-Credentials-Flow authentifiziert sich Software selbst, ohne angemeldeten Benutzer. Eine mandantenfähige Anwendung besitzt in jedem nutzenden Tenant einen Service Principal; Zustimmung und zugewiesene Rechte bestimmen dessen Möglichkeiten. Das Zurücksetzen eines Benutzerpassworts widerruft weder die Anwendungszugangsdaten noch diese Berechtigungen. [3][4]

Deshalb beginne ich ein Integrationsreview beim Berechtigungssatz statt beim Produktnamen. Sicherung und Wiederherstellung können breiten Datenzugriff begründen. Lesen, Schreiben und das Verändern von Identitäten haben dennoch unterschiedliche Folgen. Erfassen Sie die tatsächlichen Grants und Verzeichnisrollen in Ihrem Tenant. Gehen Sie weder von identischen Kundenberechtigungen aus noch davon, dass das Wort Backup die Anwendung auf Lesen beschränkt.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

Deckt Ihre Richtlinie diesen Anwendungstyp ab?

Microsofts Dokumentation zu Conditional Access für Workload-Identitäten schließt Drittanbieter-SaaS und mandantenfähige Anwendungen aus diesen Service-Principal-Richtlinien aus. Die passende Lizenz hebt diese Einschränkung nicht auf. Auch Workload Continuous Access Evaluation unterstützt laut Dokumentation nur im Tenant registrierte Single-Tenant-Service-Principals. Ein Funktionsname belegt nicht, dass eine bestimmte Identität abgedeckt ist. [5][6]

Die praktische Prüfung ordnet Zusammenhänge zu: Benennen Sie für jede Integration die Kontrolle bei der Token-Anforderung, die akzeptierende Ressource und die ausübbaren Rechte. Wo eine Richtlinie nicht greift, dokumentieren Sie die Lücke und mögliche kompensierende Einschränkungen. Benutzer-MFA bleibt wertvoll. Wer ihr auch Kontrolle über App-only-Zugangsdaten zuschreibt, lässt eine eigenständige Identität ungeprüft.

Eine App zu deaktivieren löst nur einen Teil der Eindämmung

Neue Token-Ausstellung zu stoppen und bestehenden Zugriff zu entwerten sind unterschiedliche Vorgänge. Microsoft dokumentiert eine Standardlaufzeit von 60 bis 90 Minuten, aber das ist kein allgemeiner Countdown für einen Vorfall. Token-Einstellungen, Ressourcenverhalten und unterstützte Widerrufsverfahren zählen. ConnectWise erklärt ausdrücklich, dass ausgestellte Tokens bis zum Ablauf oder einer anderen Invalidierung nutzbar bleiben können. Planen Sie damit, statt Deaktivieren mit sofortigem Abmelden gleichzusetzen. [1][7]

Ein dritter Zustand betrifft Zugang über eine andere Identität. Huntress berichtet über unberechtigt hinzugefügte Zugangsdaten an anderen Anwendungen in betroffenen Tenants. Die ursprüngliche ConnectWise-Anwendung zu deaktivieren entfernt diese nicht. Mein Abschlussmodell hat daher drei getrennte Zeilen: Neuausstellung blockiert, früher ausgestellter Zugriff geklärt, unberechtigter Folgezugang entfernt. Neunzig Minuten Wartezeit können die dritte Zeile nicht belegen. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

Eine erfolgreiche Anmeldung belegt nicht jede mögliche Handlung

Eine erfolgreiche Service-Principal-Anmeldung beweist weniger als das Lesen sämtlicher Postfächer. Todyls Untersuchung beschreibt Anmeldungen ohne die gesuchten Persistenzänderungen in den untersuchten Tenants. Huntress beschreibt Folgeänderungen in anderen Umgebungen. Das sind unterschiedliche Beobachtungsmengen, kein Anlass, den schlimmsten beobachteten Ausgang allen Kunden zuzuschreiben. Berechtigungen belegen Fähigkeiten; Operationsdaten belegen beobachtete Nutzung. [2][8]

Auch der umgekehrte Kurzschluss ist gefährlich. Eine leere Benutzeranmeldungsansicht deckt die separat erfassten Service-Principal-Anmeldungen nicht ab. Fehlende Audit-Einträge beweisen ebenfalls nicht, dass jeder mögliche Lesezugriff protokolliert worden wäre. Begrenzen Sie Ihre Aussage: Welche Telemetrie lag vor, welche Identitäten und Ressourcen erfasste sie und welche Operationen zeigt sie tatsächlich? Ein unbekanntes Ergebnis ist nützlich, wenn es den nächsten Untersuchungsschritt offenhält. [2][9]

Verfolgen Sie Änderungen von der ursprünglichen App zu anderen Identitäten

Suchen Sie anhand der Application ID und korrelieren Sie Service-Principal-Anmeldungen mit Audit-Ereignissen im Vorfallszeitraum. Die unten stehende Cloud-Backup-ID ist ein erster Anker, kein vollständiges Inventar betroffener Anwendungen. Nutzen Sie für die weitere App-Familie die aktuelle Herstellerliste. Sichern Sie Initiator, Ziel, Ergebnis und Korrelationskennungen. Verfolgen Sie Änderungen der gelisteten Anwendung als Akteur ebenso wie Änderungen an ihr. [1]

Gleichen Sie unbekannte Zugangsdaten, Zustimmungen und Rollenzuweisungen mit freigegebenen Eigentümernachweisen ab, bevor Sie sie als bösartig einstufen. Gültigkeitsdaten eines Schlüssels belegen allein nicht seinen Anlagezeitpunkt. Dokumentieren Sie, was entfernt wurde, warum und welche weitere Identität dadurch nutzbar war. So entsteht eine nachvollziehbare Kette statt eines Screenshots mit einer deaktivierten Enterprise Application. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

Fragen Sie, was die Deaktivierung überlebt

Die Abnahmefrage für eine Drittanbieterintegration gehört vor den Vorfall: Welche kundenseitige Handlung stoppt neuen Zugang, wenn morgen ihre Zugangsdaten abfließen? Was passiert mit ausgestellten Tokens, und wie finden wir anderswo angelegte Rechte oder Schlüssel? Benennen Sie Verantwortliche für diese Antworten. Eine Integration ohne aktuellen Eigentümer behält jeden Zugriff, der nicht entfernt wurde.

Dieselben Fragen bestimmen eine sinnvolle Remediation-Verifikation nach einem Vorfall. Ich würde die Belege für jeden Eindämmungszustand prüfen und Änderungen weiterer Identitäten verfolgen, bevor ich die ursprüngliche Anwendung als das gesamte Problem behandle. Den Backup-Dienst wiederherzustellen und kontrollierten Tenant-Zugriff nachzuweisen sind verbundene Entscheidungen, die getrennte Belege benötigen.