senn-techsenn-tech
Security
Security2026-10-24· By Franz Senn

ConnectWise Cloud Backup: Stolen App Identities Used Against 2,250 M365 Tenants

On 16 October 2026 ConnectWise confirmed that unauthorized parties had access to "application identities" of Cloud Backup, the former SkyKick product. Cloud Backup, SaaS Security and Cloud Management were taken offline. On 21 October Microsoft attributed the attack to the group Storm-0940. The headline figure of 2,250 tenants is correct, but it is easy to misread. This post separates what several sources confirm, what only a vendor claims and what we infer from it.

ConnectWise logo
ConnectWise is the vendor of Cloud Backup, formerly SkyKick. ConnectWise itself released the logo on Wikimedia Commons. (Quelle: Wikimedia Commons, file Connectwise-Logo.png, CC BY-SA 4.0, author ConnectWise)

What happened

Backup services for Microsoft 365 work through applications that the customer approves in their own Entra tenant. Later these apps read mailboxes, files and directories without a person being signed in. Those are the identities that were abused.

According to Huntress, the credential used sat on the vendor side, a so-called client assertion. It lives in the vendor's tenant, and nothing a customer did could have produced it. That classification comes from Huntress. Todyl spoke of a "secret", according to BleepingComputer, and Microsoft does not name the type. So the only confirmed point is that the credentials came from the vendor.

The attack in time lapse13-14 OctScripted attempts (Huntress)15 OctFirst successful app sign-in17 OctConnectWise disables 7 appidentities19 OctAll credentials reset21 OctMicrosoft: Storm-0940, ARTEX26 OctPlanned start ofreconnection
Sources: ConnectWise advisory (as of 24 Oct), Huntress, Microsoft. Depending on the source, the start is placed on 13, 14 or 15 October. (Quelle: ConnectWise, Huntress, Microsoft)

Reports from heise, Huntress and Microsoft, scripted attempts ran on 13 and 14 October, and on 15 October the first sign-in succeeded from the address 144.172.64.128. On 17 October ConnectWise blocked app access at 05:01 UTC, disabled seven app identities at 07:00 UTC and revoked certificates at 17:00 UTC. The full credential reset followed on 19 October.

The numbers and what they count

The reports use several figures that must not be compared with each other.

  • 2,250: tenants with sign-in attempts, per Microsoft. These are attempts, not break-ins.
  • 162 tenants with confirmed unauthorized sign-ins (Huntress, 16 October), almost 1,000 with sign-ins from the attacker IP and more than 300 successful (Huntress, 17 October).
  • 2 tenants with confirmed activity after the break-in, out of more than 10,000 checked tenants with ConnectWise apps (Huntress, 19 October).
  • "Hundreds of organizations" in aviation and defense, energy, finance and government (Microsoft). According to The Register, Microsoft has not disclosed how many of them were compromised.

The numbers keep changing because the unit changes: attempt, successful sign-in, activity afterwards. Anyone quoting a single number should say what it counts.

Affected tenants by way of countingSign-in attempts2250 · 2,250, MicrosoftSign-ins from attacker IP1000 · almost 1,000, Huntress 17 Octof those successful300 · more than 300, Huntress 17 OctConfirmed unauthorized sign-ins162 · 162, Huntress 16 OctActivity after break-in2 · 2, Huntress 19 Oct02500
Same unit, tenants, but a different measurement and a different cut-off date each time. The 1,000 is rounded, the 300 a minimum. The 2 come from more than 10,000 checked tenants with ConnectWise apps. (Quelle: Microsoft, 21 Oct 2026; Huntress, updates of 16 to 19 Oct 2026)
Steve Burke of CRN summarizes, per the video description, the scope and the responses from ConnectWise and Microsoft (5 minutes, 23 October 2026).

Storm-0940 and ARTEX

Microsoft traces the attack to Storm-0940, a Chinese state-linked group active since 2021. That is Microsoft's assessment; ConnectWise repeated it on 21 October with a reference to Microsoft.

The group is said to have used ARTEX, an open-source multi-agent framework for penetration testing that works with any AI model (Go and Next.js). According to Microsoft it has been in use as early as September 2026, including by other actors. The figures on speed come from Microsoft alone and are therefore vendor claims: in several cases the path from first target to privileged access took under three hours, with peaks above 2,900 failed logon events per minute (per Microsoft, in a password-spray campaign) and over 200 sign-ins in under four minutes using four app credentials. This has not been independently confirmed.

How the attackers stayed in the tenant

From vendor credential to persistence in the tenantCredential at thevendorClient assertion inConnectWise tenant(Huntress)Sign-in as appNo user sign-in, MFA doesnot apply (Todyl)Existing consentApp already held thepermissions (Microsoft)PersistenceNew credentials and roles(Microsoft, Huntress)
Simplified from the sources named. The credential type is Huntress's classification, the missing MFA is Todyl's, as reported by BleepingComputer. (Quelle: Huntress, Microsoft, BleepingComputer)

The apps already held permissions, and the attack used "the already established trust by these apps within a tenant", as Microsoft puts it. BleepingComputer suspects that existing permissions such as Directory.ReadWrite.All were abused, but that is not confirmed. Huntress saw one tenant where a cloud management app made itself Global Administrator and added credentials to other apps. Microsoft lists these observed actions: added app credentials, app role assignments, changes to privileged roles and Key Vault reads in large numbers.

ConnectWise says the stored backup archives are encrypted and isolated, with no indication of compromise (vendor claim). That does not show whether individual customer tenants were affected. heise writes that the data was neither exfiltrated nor manipulated. Huntress, on the other hand, cautions that Microsoft does not log everything an application reads.

Andrew Brandt of Huntress explains, per the video description, why the backup app's permissions were so risky (7 minutes, 20 October 2026). Huntress is itself part of the investigation, so this is the vendor view.

What to check in your tenant

This applies even if you do not use ConnectWise, because every backup, migration or security app in a tenant has the same attack surface. The steps come from the matching recommendations of Microsoft, Huntress and ConnectWise.

  1. Search enterprise apps by app ID, because the display name is not enough. Cloud Backup has the ID 506e08f9-6e9a-4da4-942b-a099a03644ae; older tenants sometimes show the app as "SkyKick Cloud Manager". Disable suspicious apps, do not delete them.
  2. Look at the sign-in logs under "Service principal sign-ins". Huntress warns that the default tab "User sign-ins" does not show this data. Cover the period from 15 October, or from 1 October if available.
  3. Check credentials and role assignments added since 13 October, and go through the holders of directory roles.
  4. Save the logs before anything else. According to heise, Entra sign-in logs are kept for seven days without extended logging and thirty days with P1 or P2; that retention period is a heise figure and was not cross-checked with Microsoft.
  5. Remove permissions you do not need, name one owner per backup app for its credential, and set an alert on "Add service principal credentials" in the audit log (our inference from the reports).

As of 24 October, ConnectWise says reconnection is under controlled management and certificate rotation is in progress. The phased reconnection of partners is targeted for Monday, 26 October, subject to completed checks. Until ConnectWise gives instructions for the service in question, affected app connections should stay disabled. Scheduled backups did not run in the meantime, and restores were not possible (BleepingComputer, 18 October). Anyone who relied on this backup currently has no restore from this service.

Our own backup stack

For this post we looked at what runs on our side, read-only, on 24 October 2026. Our Microsoft 365 backup is our own fork of an open-source project on a host we operate ourselves: container m365-console, image m365-console:1.5.0-cbpx, started 29 hours ago and reported healthy. A case-insensitive search for "connectwise" and "skykick" in /opt/m365-backup and /etc on that host returned no match, and neither did our notes. So no ConnectWise component runs on the host.

We did not check the Entra tenant itself, and the app IDs above were not queried there. We therefore make no statement about the tenant. Our backup also works with app permissions: according to our runbook there is an Exchange management scope with the application roles Mail.ReadWrite and MailboxItem.ImportExport. The lesson from this incident applies to us as it does to anyone else. We measured nothing about the state of our secrets or certificates and therefore say nothing about them.

Further sources

Questions?
How many tenants were actually compromised?+

Nobody knows yet. The figure 2,250 comes from Microsoft and counts sign-in attempts. Microsoft says most of the access attempts failed but gives no number of successful break-ins. On 17 October Huntress counted almost 1,000 Entra tenants with sign-ins from the attacker IP, more than 300 of them successful.

Does multi-factor authentication help against this attack?+

According to Todyl, as reported by BleepingComputer, it does not: these were sign-ins by applications, not by users, so MFA never comes into play. What can help is restricted app permissions, monitored credentials and a disabled application.

Should I delete the ConnectWise apps in my tenant?+

No, disable them first. Microsoft explicitly advises against deleting enterprise applications as the first step, and Huntress points out that deleting removes the granted consent. Save the logs first and keep the connections disabled until ConnectWise gives instructions for the service in question.