A Vendor Backup Secret Opened Over 300 Microsoft 365 Tenants

TL;DR

• ConnectWise Cloud Backup is a hosted backup service, formerly sold as SkyKick, that managed service providers connect to their customers' Microsoft 365 tenants so that mail, files and Teams data are copied somewhere outside the tenant.
• A secret belonging to that application was compromised and used to sign in to customer tenants as the backup service itself, and Huntress confirmed unauthorized sign-ins in 162 tenants on 16 October 2026, then counted almost 1,000 Entra tenants with sign-in activity from the attacker's address on 17 October, over 300 of them successful.
• The abuse reached further than the backup app: service principals for ConnectWise Cloud Management applications assigned themselves directory roles, mostly Exchange Administrator, and in one tenant an application granted itself Global Administrator and added credentials to two other applications.
• Multi-factor authentication had no bearing on these sign-ins, because no user was authenticating; the application presented its own secret and used permissions the customer had already granted.
• ConnectWise shut down application access to Cloud Backup and stated it has no indicators that partner backup data was compromised; Microsoft described the activity as an active supply-chain attack.
• Disabling the named applications stops new use, and the credentials those applications added stay valid, so containment runs through an audit of every secret on every enterprise application in the tenant.

What a backup application holds inside a tenant

An application that backs up Microsoft 365 has to read what it backs up. To do that it is registered in the customer's tenant as a service principal and granted Microsoft Graph and Exchange permissions that allow it to read mail, files and chat, and in many deployments to write them back during a restore. The grant is made once, by an administrator, during onboarding.

That grant is not a session. It does not expire with a working day, it does not ask for approval when the application authenticates, and it does not depend on any person being present. The application authenticates with its own secret, held on the vendor's side, and the tenant accepts the request because the permissions were granted months or years earlier.

Every backup, ticketing, monitoring, HR or signature product onboarded this way carries the same property. The vendor's secret becomes a standing key to the customer's tenant, and the customer's only view of it is a row in the enterprise applications list, usually with the consent screen nobody re-reads.

How the intrusion reached over 300 tenants

The activity was visible to administrators before it was public. A user on Reddit reported a Microsoft Privileged Identity Management notification on 15 October that a SkyKick service principal had assigned itself the Exchange Administrator role, in a tenant that had not used the application for years. Microsoft later confirmed unauthorized authentication attempts on 15 October, and ConnectWise stated in its advisory that it had "recently identified unauthorized access to application identities within the ConnectWise Cloud Backup environment", then shut down application access for partners and clients.

Huntress, which monitors customer tenants, attributed the sign-ins to the legitimate Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and confirmed unauthorized sign-ins in 162 tenants as of 19:00 UTC on 16 October. Its update of 17 October raised the scale: almost 1,000 Entra tenants showed sign-in activity from the attacker's address, and over 300 of those succeeded. The Hacker News put the figure at 173 tenants on the same day. Both accounts trace the authentication to the address 144.172.64.128, and Huntress linked that address to scripted sign-in attempts on 13 and 14 October using the curl user agent 7.88.1, alongside python-urllib and python-requests agents.

The escalation moved beyond the backup application. Huntress reported that service principals for the Cloud Management applications covering Exchange Online, Teams and Microsoft Graph assigned themselves directory roles, mostly Exchange Administrator, across nearly fifty of the tenants it monitors. In one partner tenant the Cloud Management - MS Teams application, ID 24205314-2b89-4e07-a2a4-579e898a5640, granted itself Global Administrator and then added new credentials to two other applications, including a single-tenant Huntress application. Todyl, analysing intrusions on nine tenants, found only sign-in activity and no evidence of created accounts, changed passwords or persistence through the backup app. Other responders saw persistence. Microsoft observed a backdoor after successful service principal authentication, followed by Microsoft Graph API reconnaissance and attempts to add additional credentials, and in the tenant where the Teams application became Global Administrator, Huntress recorded a Python script making nine changes to the two other applications, six of them successful, with the new secrets set to expire in 2028.

Why multi-factor authentication covered nothing here

Multi-factor authentication verifies a person. The sign-ins in this incident presented a client secret, so there was no person to verify and no prompt to approve. Todyl's account is explicit: the attacker authenticated directly to Microsoft 365 as the backup application using its secret, and because the requests did not involve a user login, protections such as MFA were ineffective.

The permissions already granted did the rest. Directory.ReadWrite.All, which Microsoft's threat intelligence assessed as one of the permissions likely abused, is a directory-wide write permission; in our reading, an application holding it reaches well beyond the mail and files a backup service exists to copy.

Conditional access policies that gate interactive sign-ins therefore leave this path open, and a policy written to require compliant devices for administrators does not touch an application token. The control that covers it is narrower and less comfortable: know which applications hold which grants, and rotate their secrets on a schedule that assumes the vendor's side will eventually be compromised.

The containment sequence the responders published

Huntress's guidance orders the work in a way worth copying. Affected organisations should disable two application IDs immediately, Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae and Cloud Management - MS Teams 24205314-2b89-4e07-a2a4-579e898a5640, and consider disabling the other Cloud Management IDs for the duration. The instruction is to disable the applications and keep them: deleting an application removes its consent, so service can only come back through re-consent, and disabling pauses backups while leaving the backups already stored in place.

Disabling stops new use and removes nothing that already happened. Huntress states the consequence plainly: disabling the applications does not remove credentials that were already added, so every credential on every Microsoft 365 application in the tenant has to be reviewed. That review is the part most likely to be skipped under pressure, and it is the part that decides whether the incident ends.

Re-enabling waits on the vendor. Huntress advises keeping the applications disabled until ConnectWise confirms that all credentials have been reset. On 17 October at 5:15 PM ET, ConnectWise communicated that it had disabled the relevant apps, and the vendor's advisory says it has no indicators to date that partner backup data was compromised and that the existing cloud backup archive is not impacted by the service interruption. Its update of 18 October at 01:00 UTC, reported by BleepingComputer, states that scheduled backups are not running and that access to affected backup archives and restoration capabilities remains unavailable, and adds that the existing archives remain encrypted and isolated, with no indication that they have been compromised. For a small organisation, that means no restore from this service until access returns.

A second wave is worth noting for anyone who reads the first one as solved. Huntress identified further attempts from the same address on 15 October against 16 of its protected tenants in the policy, national security, trade and critical mineral sectors, and most of those tenants did not use ConnectWise products, so the attempts failed because the application was not present. Huntress's update of 19 October adds the rest of the picture so far: across more than 10,000 tenants with ConnectWise applications, only 144.172.64.128 and Microsoft-internal ranges produced application sign-ins, while 144.172.64.99, 144.172.64.60 and 144.172.94.243 showed password spraying or failed logins. It found post-compromise changes in a second tenant, made around 03:45 UTC on 15 October like those in the first, placed the last successful sign-in at 08:44 UTC that day, and limited containment to tenants with confirmed unauthorized sign-ins, on the evidence that the activity had stopped.

What a small organisation can check in its own tenant

The first check is an inventory, and it is short. Open the enterprise applications list in the Microsoft 365 admin centre and export it, then for each third-party application look at the permissions it holds and the date consent was granted. Applications that no longer serve a purpose are the cheapest finding on the list, and the Reddit report of a service principal still active in a tenant that had stopped using the product years earlier is the reason to look.

The second check is the sign-in log. Searching for the address 144.172.64.128 and for the user agents python-urllib, python-requests and curl/7.88.1 over the exposure window costs a few minutes and gives a first answer for the tenant in question. Huntress warns that these user agents are low fidelity on their own and need the address beside them, and that the directory role assignments of 15 October carried kiota-dotnet, an agent ConnectWise's own applications also use. It also notes that Microsoft's audit logs record no source address for app-only actions and that directory reads through Microsoft Graph leave no audit trail, so an empty search proves little; Microsoft recommends reviewing application credential changes, OAuth grants and related Graph activity as well.

The third is secret hygiene on the applications that remain. A vendor application's credentials should have an owner, a rotation date and a record of who can read them on the vendor side, and none of the three is standard practice in small organisations. Where a provider offers certificate-based authentication with a client certificate stored in a managed vault, that is a materially better arrangement than a shared secret.

The fourth is a written answer to a question most vendors never hear: if your environment were compromised tomorrow, which of our credentials would the attacker hold, and how quickly would you tell us. The tenants opened in this incident, more than 300 by Huntress's count of 17 October, were reached through a service the customers had chosen to trust, and the trust was expressed as a permission grant they had not looked at since onboarding.

Netics runs security audit and hardening engagements that can include this inventory and the app-consent review that goes with it.

Sources

Source: ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks — Huntress, published 16 October 2026, updated 17 and 19 October 2026, retrieved 2026-10-22 (the compromised API secret of ConnectWise Cloud Backup, the abuse of Cloud Management applications for Exchange Online, Teams, SharePoint Online, Cloud Backup, MS Graph and Partner Center, application ID 24205314-2b89-4e07-a2a4-579e898a5640 granting itself Global Administrator and adding credentials to two other applications, application ID 506e08f9-6e9a-4da4-942b-a099a03644ae as the Cloud Backup application, the private IPv6 ULA fde4:8dba:2600:37ce:6d26:200:a76:*, the instruction to disable rather than delete and to review credentials on every application, the 17 October update that ConnectWise disabled the relevant apps, the second wave against 16 Huntress-protected tenants in the policy, national security, trade and critical mineral sectors, the Python script's nine changes, six successful, with secrets expiring in 2028, and the 19 October update covering the review of more than 10,000 tenants with ConnectWise applications, the addresses 144.172.64.99, 144.172.64.60 and 144.172.94.243, the second tenant with post-compromise changes around 03:45 UTC, the last confirmed successful sign-in at 08:44 UTC on 15 October and the targeted containment scope).

Source: Hackers breach Microsoft 365 tenants via ConnectWise supply-chain attack — BleepingComputer, 17 October 2026, retrieved 2026-10-18 (at least 162 compromised tenants reported by Huntress, Microsoft's confirmation of unauthorized authentication attempts on 15 October, ConnectWise's advisory language on unauthorized access to application identities and on having no indicators that partner backup data was compromised, the source address, the Reddit account of the Privileged Identity Management alert, Todyl's finding that the attacker authenticated as the backup application so multi-factor authentication was ineffective and that nine analysed tenants showed no persistence through the backup app, Huntress's observation of directory role assignments across nearly fifty tenants, Microsoft's observation of persistence after successful service principal authentication, with Microsoft Graph API reconnaissance and attempts to add credentials, ConnectWise's statement that the existing archive is not impacted and its 18 October update on stopped backups and unavailable restoration, and Microsoft's characterization as an active supply-chain attack likely abusing Directory.ReadWrite.All).

Source: Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants — The Hacker News, 17 October 2026, retrieved 2026-10-18 (the 173-tenant count for the same activity and the same source address).

Source: Huntress's investigation of 16 October 2026 with its 17 and 19 October updates, BleepingComputer's report of 17 October and The Hacker News report of the same day — the tenant counts, application IDs, timestamps and containment steps above trace to those pages. Images are captures of ConnectWise's trust advisories page and Huntress's investigation page, plus two Netics editorial diagrams. More security analysis is published on neticslabs.com.