Das Backup als Hintertür: Was der ConnectWise-Vorfall über App-Berechtigungen in Microsoft 365 lehrt

Ein Backup-Dienst muss alles lesen können, was er sichern soll: Postfächer, OneDrive, SharePoint, Teams, das Verzeichnis. Genau diese Rechte sind seit dem 15. Oktober 2026 in fremden Händen. Unbekannte haben ein Zugangsdatum der Microsoft-365-App von ConnectWise Cloud Backup (früher SkyKick) erbeutet und sich damit in die Tenants von Kunden angemeldet – mit allen Rechten, die diese Kunden der App einmal erteilt hatten. Microsoft spricht von einem aktiven Lieferkettenangriff.

Der Fall betrifft nur die Kunden eines Herstellers. Die Frage dahinter betrifft jede Organisation mit Microsoft 365: Welche Apps haben in unserem Tenant welche Rechte – und würden wir es merken, wenn jemand anderes sie benutzt?

Was passiert ist

Warum der Fall mehr ist als ein Herstellerproblem

Die App ist das Konto. Bei diesem Angriff wurde kein Benutzer übernommen – die Angreifer haben sich als die App angemeldet. Benutzer abmelden, Passwörter zurücksetzen oder MFA verschärfen hilft deshalb nicht. Ein Deaktivieren der App stoppt neue Tokens, bereits ausgestellte bleiben aber bis zu 90 Minuten gültig.

Die Rechte wurden einmal erteilt und dann vergessen. Einer Backup-App erteilt man bei der Einrichtung Rechte wie das Lesen und Schreiben aller Postfächer und Dateien, oft auch Verzeichnisrechte wie Directory.ReadWrite.All. Danach taucht die App in keiner Benutzerliste und keiner MFA-Auswertung mehr auf. Sie läuft einfach.

Vertrauen wird weitergereicht. Der gefährlichste Befund ist der zweite Schritt: Eine App mit Administratorrechten hängt neue Zugangsdaten an andere vertrauenswürdige Apps. Eine MSP-Verwaltungs-App ist oft in vielen Kunden-Tenants freigegeben. Wer dort ein eigenes Secret hinterlegt, kommt potenziell über den einen Tenant hinaus.

Manches hinterlässt keine Spur. Lesende Verzeichniszugriffe über Microsoft Graph tauchen im normalen Audit-Log nicht auf. Ohne aktivierte Graph-Aktivitätsprotokolle lässt sich im Nachhinein nicht klären, was die Angreifer gelesen haben.

Was jede Organisation mit Microsoft 365 jetzt prüfen sollte

1. Enterprise Apps inventarisieren: Im Entra Admin Center unter „Enterprise-Anwendungen“ alle Apps mit Anwendungsberechtigungen auflisten. Zu jeder App sollte klar sein, wer sie braucht, wer sie freigegeben hat und ob sie noch genutzt wird. Was niemand erklären kann, wird entfernt.
2. Kritische Berechtigungen gezielt suchen: Besonders heikel sind Rechte, mit denen eine App andere Rechte vergeben oder Apps verändern kann (RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All), dazu Directory.ReadWrite.All sowie Vollzugriff auf Mail und Dateien. Exchange-Vollzugriff über EWS (full_access_as_app) steht nicht bei Microsoft Graph, sondern bei der App „Office 365 Exchange Online“ und muss dort separat geprüft werden.
3. Anmeldungen von Apps auswerten: Unter „Überwachung → Anmeldeprotokolle“ den Reiter „Anmeldungen von Dienstprinzipalen“ öffnen – der Standardreiter zeigt nur Benutzeranmeldungen. Auffällig sind Anmeldungen von IP-Adressen außerhalb der erwarteten Microsoft- und Azure-Bereiche.
4. Neue Zugangsdaten an Apps finden: Prüfen, ob seit dem 13. Oktober an Apps oder Dienstprinzipalen neue Secrets oder Zertifikate hinterlegt wurden und ob sich Apps selbst einer Verzeichnisrolle hinzugefügt haben.
5. Graph-Aktivitätsprotokolle einschalten: Sie kosten Speicher, sind aber die einzige Möglichkeit, lesende Zugriffe von Apps nachzuvollziehen. Ohne sie bleibt nach einem Vorfall wie diesem nur die Vermutung.

Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All','AuditLog.Read.All'

$cwApps = @(
  '506e08f9-6e9a-4da4-942b-a099a03644ae', # Cloud Backup
  '2399d300-6fca-4e6a-a686-399fefe75b83', # Cloud Management
  '24205314-2b89-4e07-a2a4-579e898a5640', # Cloud Management - MS Teams
  'b78f6a77-d4e5-46fb-87e5-d1648bd02519', # Cloud Management - Exchange Online
  '0de14c77-b9b0-4137-9360-34878a929827', # Cloud Management - MS Graph
  '412dcf96-176d-4b3a-a1b0-4981ad66971e', # Cloud Management - Partner Center
  'b2b55f5b-7758-4719-8d8f-88ae172e6bdb'  # Cloud Management - SharePoint Online
)
Get-MgServicePrincipal -All | Where-Object { $cwApps -contains $_.AppId } |
  Select-Object DisplayName, AppId, AccountEnabled

$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
$kritisch = 'Directory.ReadWrite.All','RoleManagement.ReadWrite.Directory',
            'Application.ReadWrite.All','AppRoleAssignment.ReadWrite.All',
            'Mail.ReadWrite','Files.ReadWrite.All','Sites.FullControl.All'
$rollen = $graph.AppRoles | Where-Object { $kritisch -contains $_.Value }

Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graph.Id -All |
  Where-Object { $rollen.Id -contains $_.AppRoleId } |
  Select-Object PrincipalDisplayName,
    @{ n = 'Berechtigung'; e = { $id = $_.AppRoleId; ($rollen | Where-Object Id -eq $id).Value } } |
  Sort-Object PrincipalDisplayName

$seit = Get-Date '2026-10-13'
$props = 'Id','DisplayName','AppId','PasswordCredentials','KeyCredentials'

$objekte  = Get-MgServicePrincipal -All -Property $props
$objekte += Get-MgApplication      -All -Property $props

foreach ($o in $objekte) {
  foreach ($c in @($o.PasswordCredentials) + @($o.KeyCredentials)) {
    if ($c -and $c.StartDateTime -ge $seit) {
      [pscustomobject]@{ App = $o.DisplayName; AppId = $o.AppId; Seit = $c.StartDateTime; Typ = $c.GetType().Name }
    }
  }
}

Get-MgAuditLogDirectoryAudit -All -Filter "activityDisplayName eq 'Add member to role' and activityDateTime ge 2026-10-13T00:00:00Z" |
  Where-Object { $_.InitiatedBy.App.DisplayName } |
  Select-Object ActivityDateTime,
    @{ n = 'Ausgeloest von'; e = { $_.InitiatedBy.App.DisplayName } },
    @{ n = 'Ziel'; e = { ($_.TargetResources | Select-Object -First 1).DisplayName } }

Was wir daraus ableiten

Benutzerkonten werden heute in den meisten Umgebungen gut überwacht: Anmeldeorte, MFA, riskante Anmeldungen. App-Identitäten fallen dagegen fast überall durch das Raster, obwohl sie oft mehr dürfen als jeder Administrator. Der ConnectWise-Fall zeigt, wie schnell sich das ausnutzen lässt.

Genau hier setzen wir an: Wir planen eine Überwachung für App-Identitäten in Microsoft 365, die die Muster aus diesem Vorfall erkennen soll – neue Secrets oder Zertifikate an bestehenden Apps, Apps, die sich selbst Rollen zuweisen, neu erteilte kritische Berechtigungen und App-Anmeldungen von ungewohnten Adressen. Bis dahin bleibt die regelmäßige Prüfung mit den oben gezeigten Schritten der wichtigste Schutz.

Einordnung

• Apps sind privilegierte Identitäten. Sie gehören in dieselbe Prüfung wie Administratorkonten: regelmäßige Rezertifizierung, minimale Rechte, Überwachung der Anmeldungen.
• Der Lieferant ist Teil der eigenen Angriffsfläche. Wer einer App Tenant-weite Rechte gibt, vertraut nicht nur dem Produkt, sondern auch der Sicherheit des Herstellers. Das gilt für Backup-Dienste ebenso wie für jedes andere Werkzeug mit Zugriff auf den Tenant.
• Ein Backup ohne Wiederherstellung ist kein Backup. Wer sein einziges M365-Backup bei einem Anbieter hat, der nun auf unbestimmte Zeit ausgesetzt ist, hat derzeit keines. Eine zweite, unabhängige Sicherung gehört zur 3-2-1-1-0-Regel, die wir im Beitrag zur Backup-Strategie mit Veeam beschrieben haben.
• Kein Einzelfall. Wie Angreifer Fernwartungswerkzeuge als Generalschlüssel nutzen, zeigt auch der BeyondTrust-Zero-Day.

Quellen & weiterführende Links

• Huntress

  Vendor credential enables unauthorized access
• Todyl

  Investigation: Unauthorized access through the ConnectWise Cloud Backup Microsoft 365 app
• ConnectWise

  Trust Center – Security Advisories
• The Hacker News

  Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants (17.10.2026)
• Borns IT- und Windows-Blog

  Cyberangriff auf abc Bank; die CDU; ConnectWise Cloud Backup-Kompromittierung (18.10.2026)

Recherchestand: 19. Oktober 2026. Die Untersuchung durch ConnectWise läuft noch.