ConnectWise Cloud Backup hit by Microsoft 365 supply-chain attack: what Huntress and Todyl found

ConnectWise has switched off customer access to its Cloud Backup service, formerly SkyKick, after an unauthorised party signed in to Microsoft 365 tenants using the service's own application identity. The incident matters well beyond one backup product: the attacker did not steal a user's password or beat multi-factor authentication. They authenticated as the app, using a vendor-held credential, so none of the usual user-facing defences applied. Security firms Huntress and Todyl, which both published detailed findings, say the exposure is wide, while ConnectWise says its backup archives show no sign of compromise so far.

Key points

• Huntress confirmed unauthorised sign-ins in 162 tenants as of 19:00 UTC on 16 October, and says almost 1,000 Entra tenants saw sign-in activity from the attacker's IP address, 144.172.64.128, with more than 300 of those sign-ins succeeding.
• Todyl found the attacker authenticated as the ConnectWise Cloud Backup app (app ID 506e08f9-6e9a-4da4-942b-a099a03644ae) using a valid client secret, which is why MFA and user Conditional Access never applied.
• Huntress saw ConnectWise Cloud Management service principals assign themselves directory roles, mostly Exchange Administrator, in about 50 of its monitored tenants; in one, an app made itself Global Administrator and added credentials to two other applications.
• ConnectWise disabled seven application identities on 17 October and, per BleepingComputer, said on 18 October that scheduled backups were not running and the service remained unavailable.
• It is still unknown how the attacker obtained the vendor credentials, how many tenants were affected in total, and whether any data was taken.

What happened

According to Huntress's timeline, the first signs were a password-spray against four law-firm tenants on 13 and 14 October from a single hosting-provider address, 144.172.64.128, using the curl/7.88.1 user agent. Two accounts were locked out and Huntress saw no successful user sign-ins from that address.

The real activity began on 15 October. Starting around 01:58 UTC, service principals belonging to ConnectWise's Cloud Management apps began assigning themselves directory roles in about 50 tenants Huntress monitors, mostly Exchange Administrator. In one customer tenant between 03:44 and 03:49 UTC, the Cloud Management app for Teams added itself to the Global Administrator role and then made nine changes to two other applications (six succeeded, three failed). The targets were an MSP management tool and Huntress's own security platform app, and the new client secrets were set to expire in 2028. Adding credentials to an existing application is a known persistence technique, catalogued by MITRE as T1098.001.

Todyl, watching different tenants, recorded a separate pattern on the same day. Between 07:11 and 08:47 UTC, an automated script from the same IP signed in once per tenant as the ConnectWise Cloud Backup app, working through tenants in ascending order of tenant ID about one to six minutes apart. Todyl concluded that a tool was crawling a sorted list of tenants that had consented to the app. The user agent was Python-urllib/3.12, the credential type was a client assertion, and Conditional Access was recorded as not applied.

Huntress described a second wave later on 15 October against 16 of its protected tenants. Those attempts failed, mostly because the ConnectWise service principal was not present, and most of those tenants do not use ConnectWise products at all. That detail suggests the operator was probing broadly rather than only hitting known customers.

ConnectWise announced a service interruption at 05:01 UTC on 17 October, per BleepingComputer. The company disabled seven application identities that day. On 18 October, at 01:00 UTC, it said scheduled backups were not running and that the service remained unavailable. BleepingComputer also reports that ConnectWise's SaaS Security and Cloud Management products were taken offline as a precaution. We could not open ConnectWise's advisory page ourselves (it returned an access error), so statements attributed to ConnectWise here come from BleepingComputer, Huntress and Todyl.

Background

SkyKick built cloud-to-cloud backup and migration tools for Microsoft 365 partners, and ConnectWise bought the company in 2024 (a deal announced alongside its Axcient acquisition). Managed service providers use such products to back up their customers' Exchange Online, OneDrive, SharePoint and Teams data. To do that, the backup app is granted wide, tenant-wide permissions when a customer consents to it.

That design is the heart of the problem. Todyl notes that the Cloud Backup app's existing consent allows tenant-wide read and write access to mail and attachments, OneDrive and SharePoint files and Teams chats, plus data restore. A multi-tenant app like this has one identity and one set of credentials held by the vendor, but it exists inside every customer's directory. Whoever holds the credential can authenticate into every consenting tenant, without any customer-side user ever being involved.

Conditional Access policies, which many organisations rely on to enforce MFA and device rules, do not govern third-party multi-tenant apps in the same way. Todyl's seventh recommendation says as much: least-privilege consent and removing unused apps are the main controls available to customers.

How the attack worked

The access path is the key technical detail. In OAuth 2.0's client credentials flow, an application proves its identity with a secret or certificate and receives an app-only token. No person signs in, so there is nothing to phish and no second factor to prompt. Huntress and Todyl both say the credential was a client assertion that lived in the vendor's environment, which points to the problem sitting with the vendor rather than with any individual customer.

From there, two behaviours were observed:

1. Sign-in sweeps. The Cloud Backup app authenticated across many tenants and obtained Microsoft Graph tokens. In tenants with no backup subscription, Todyl saw a token issued but no mailbox or file reads afterwards, which it reads as reconnaissance.
2. Privilege escalation and persistence. Separate Cloud Management apps assigned themselves directory roles and, in at least one tenant, planted credentials on other applications. BleepingComputer reports Microsoft Threat Intelligence also observed backdoor persistence, Graph reconnaissance and attempts to add credentials, and assessed that the attacker likely abused existing permissions such as Directory.ReadWrite.All.

Neither firm claims the two behaviours are definitely one operator. Huntress says the private IPv6 address seen in the second phase is also used by legitimate ConnectWise traffic and unrelated customer traffic, and that it has not tied the phases to one actor. It also notes that the kiota-dotnet user agent matches ConnectWise's own apps, while the Python user agents are common and low-fidelity indicators.

The numbers

The scale figures come from different vantage points and should not be added together: they overlap and measure different things.

type: bar
title: How far the activity reached (different counting bases, not additive)
unit: tenants
source: Huntress, vendor credential enables unauthorized access
Entra tenants with sign-in activity from the IP | 1000
Successful sign-ins (more than) | 300
Tenants with confirmed unauthorised sign-ins | 162
Huntress tenants with self-assigned directory roles | 50

Huntress's "almost 1,000" is an approximation as published, so the chart shows it as 1,000 and the sign-in count as "more than 300". The 162 figure was confirmed as of 19:00 UTC on 16 October and the roughly 50 figure refers to tenants Huntress itself monitors.

What it means

For IT teams and MSPs. The immediate advice from Huntress and Todyl is nearly identical. Disable, rather than delete, the affected enterprise applications in Entra (set "Enabled for users to sign-in" to No) so that consent is kept and the app can be re-enabled later. Huntress lists the seven application IDs and says not to re-enable them until ConnectWise confirms all credentials were reset. Backups stop while the apps are disabled, but email, files, Teams and user sign-ins keep working and existing backups are not deleted.

Next, hunt. Review service principal sign-ins (not user sign-ins) for these apps from around 01:00 UTC on 15 October, look for non-Microsoft IP addresses and 144.172.64.128, and check for client secrets or certificates added since 13 October that nobody on your team created. Todyl advises going back to 1 October if logs allow, and exporting logs now on Entra ID Free, which keeps only seven days. Microsoft Graph activity logs (Entra ID P1 or P2) are not retroactive, but without them legitimate and malicious use of the same app cannot be told apart.

Disabling an app stops new tokens only. Todyl says tokens already issued stay valid for up to 90 minutes, and revoking user sessions does not end application-based access.

For the industry. This is a fresh reminder that the weakest link in a Microsoft 365 tenant can be a trusted vendor's single credential. It also shows a visibility gap: for tenants that had an active backup subscription, Todyl says reads by the attacker and reads by the real service share one app identity and appear to come from Microsoft's infrastructure, so telling them apart needs per-request logs many customers never turned on. Todyl calls the absence of confirmed data theft "partly a visibility limit rather than a clean result" and recommends treating affected data as exposed. That is Todyl's advice, not a confirmed finding of theft.

Huntress also suggests longer-term hardening: application management policies that restrict or cap client secrets, fewer holders of Application Administrator and Cloud Application Administrator roles, and workload-identity Conditional Access where licensing allows.

What we don't know yet

• How the credentials were obtained. No source says how the attacker got the vendor-held secret or assertion material.
• The final victim count and any data theft. Huntress reviewed an audit log in detail in one tenant and saw no mail or file access, but notes that directory reads through Graph leave no audit trail. Its summary: tokens issued, nothing visible taken.
• Whether other ConnectWise apps are safe. Huntress says it cannot verify the remaining ConnectWise applications are secure.
• Whether the two activity patterns are one actor. See above.
• Backup data. BleepingComputer reports that ConnectWise said partner backup data showed no indicators of compromise to date and that archives are encrypted and isolated; that is the company's statement and we have not been able to verify it independently.

What to watch next

Watch for ConnectWise to confirm credential rotation and to say when Cloud Backup and Cloud Management come back; for Microsoft to publish its own guidance on the affected app IDs; and for any disclosure of how the vendor credentials were exposed. Huntress and Todyl are both updating their posts as they learn more, and customers of other backup and management vendors with tenant-wide Microsoft 365 permissions should use this week to review exactly what those apps are allowed to do.

Sources

• BleepingComputer: Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack
• Huntress: Vendor credential enables unauthorized access
• Todyl: Investigation of unauthorised access through the ConnectWise Cloud Backup Microsoft 365 app
• ConnectWise trust centre advisories (cited by the sources above; page not openable for us)