ConnectWise's Backup App Signed Into 173 Microsoft 365 Tenants With No Password. Then the Backups Stopped.

Every incident has a version that fits neatly in a headline. This one's is easy: a vendor credential was stolen, a few hundred Microsoft 365 tenants were signed into, and every administrator should now go audit their OAuth grants. All of that is true.

The part that does not fit is what happened next. ConnectWise's response was to turn Cloud Backup off. Not degrade it, not rate-limit it. Off. As of the company's 01:00 UTC update on 18 October, scheduled backups are not running, access to backup archives and restoration capability is unavailable, and there is no date for when any of it comes back.

Sit with that for a second. The product exists to be the answer on the day everything else fails. This week it became the thing that failed, and the customers who bought it as their recovery plan are currently operating without one. ConnectWise says the archives themselves remain encrypted, isolated and preserved, and that it has no evidence they were accessed. That is a genuinely reassuring sentence about the data at rest. It says nothing about the gap opening in front of it, because every day the service is down is a day of new mail, new files and new Teams messages sitting outside any recovery point.

No password was ever in play

ConnectWise Cloud Backup, formerly SkyKick, is the kind of product that has to be trusted with almost everything to do its job. It is a multi-tenant Entra application, consented once into each customer tenant, and from that point it holds broad read and write access to mailboxes, OneDrive and SharePoint files, Teams conversations and directory data. Backup needs to read all of it. Restore needs to write all of it.

The attack did not need to phish anyone to reach that. Huntress, which confirmed the activity from Microsoft's own sign-in logs, described the credential type as a client assertion, and was blunt about what that means. "The credential type was a client assertion, which means the credential lives in the vendor's own tenant. Nothing a customer did in their environment could have produced it."

Because the sign-in was application-only, there was no user to challenge. No device posture check, no MFA prompt, no risky sign-in for Entra ID Protection to flag in the usual way. Nicholas Koken, Todyl's head of detection engineering, put the consequence plainly: the access inherited the app's existing consent, which included reading and writing mail and attachments, OneDrive and SharePoint files and Teams chats, plus the ability to restore data. Revoking user sessions does not end it. Disabling the app stops new tokens being issued, but tokens already issued stay valid for up to 90 minutes.

That last detail is the one that makes the timeline uncomfortable. The attacker did not need to stay logged in. They needed four hours.

One address, a sorted list, and four hours

Huntress's reconstruction is unusually precise, and the precision is the point.

On 13 and 14 October, the same IP address, 144.172.64.128, ran password spraying against four law firm tenants using a curl user agent. Two accounts were locked out by smart lockout. Huntress saw no successful user sign-ins from that address in its telemetry, which suggests the spraying was not the plan but the reconnaissance.

Then, from 01:58 UTC on 15 October, service principals for ConnectWise's Cloud Management applications assigned themselves directory roles in roughly fifty tenants Huntress monitors, mostly Exchange Administrator. The user agent on those events was kiota-dotnet, the .NET SDK ConnectWise's own applications use. Huntress says that points to vendor automation but has not confirmed it with ConnectWise, and the distinction matters enormously to anyone deciding whether that half of the activity was malicious or routine.

At 03:44 UTC, in one partner tenant, the Cloud Management application for Microsoft Teams added itself to the Global Administrator role. It did so again four minutes later. Between 03:44 and 03:49, a Python script made nine changes to two other applications in that tenant: an MSP management application, and Huntress's own security platform application. Six changes succeeded and three failed. A certificate credential was rejected on a thumbprint mismatch. The client secrets that followed were accepted, with expiry dates in 2028.

Five minutes of work produced credentials on two privileged tools that the vendor's shutdown would not touch. An MSP management application is often consented into that MSP's customers' tenants, so a secret on it potentially reaches beyond the one tenant it was planted in. A secret on a security vendor's application inherits whatever that platform is permitted to do.

The mass sign-ins came later that morning, between 06:13 and 08:34 UTC, all from 144.172.64.128, moving through tenants in sorted GUID order a few seconds apart. Huntress's Jonathan Semon: "The actor moved through tenants in sorted GUID order, a few seconds apart, which points to a script working from a target list."

Microsoft Threat Intelligence, in a post on X quoted by The Hacker News, called it an active supply chain attack and said it observed broad successful service principal authentication from that address on 15 October, followed by Graph API reconnaissance and attempts to add credentials to the service principal as a backdoor. Its assessment was that permissions customers had already granted, including Directory.ReadWrite.All, were likely abused.

The number in the headline measures who was watching

The count has moved around, and the way it has moved is more informative than any single figure.

Huntress confirmed unauthorised sign-ins in 162 tenants as of 19:00 UTC on 16 October. The Hacker News reported 173, attributing that to Huntress. Both numbers describe one company's monitored fleet, not the population of affected organisations, and neither is a ceiling. The credential works in every tenant where the app was ever consented.

Huntress's own update on 17 October widened the frame considerably: almost 1,000 Entra tenants showed sign-in activity from 144.172.64.128, and more than 300 of those succeeded. Many of the successes carried no access at all, because the application had no service principal in that tenant. Microsoft Graph will still issue a token for an app the tenant never installed or has since removed. It just arrives with no permissions attached, logged as a success with an all-zeros service principal ID.

That single quirk explains both the panic and the confusion in the count. Inforcer, which analysed its own managed estate, found that of 28 tenants contacted from the rented server, only seven actually had the app installed. The other 21 got tokens that could read nothing. A successful sign-in is not proof of access. A burst of blank successes and missing-service-principal failures across many tenants at once is a strong sign that someone is working through a list.

And the exposure was always larger than the activity. Inforcer's inventory before the incident covered 3,790 tenants with the backup app installed across 663 MSPs. Of those, 1,359 had been actively used in the preceding three days. Another 1,890 had last been used during a low-volume token wave back in early July, 436 before late August, and 94 had never signed in at all. Roughly 2,400 tenants were carrying a backup application with broad read access to mail and files that nobody was using and nobody had removed.

Consent does not expire when a subscription does. That is the whole mechanism by which hundreds of dormant connections turned into a target list. Inforcer also found tenants on the list that had no ConnectWise presence whatsoever, including several MSPs' own internal tenants, which suggests the list lived somewhere other than the tenants themselves, covering organisations that had connected to the service at some point and then moved on without cleaning up.

The second wave is the detail worth losing sleep over. On the same day, the same address made a second, narrower pass at 16 tenants in the policy, national security, trade and critical minerals sectors. Most of them did not use ConnectWise products at all, so the attempts failed for want of a service principal. Those are not the customers of a mid-market backup vendor. They are a different target set entirely, and nobody has publicly explained the connection.

Huntress also floated something stranger: what might be an affinity for alphabetical targeting, noting that its most interesting victims began with the letter A. It offered that as a prioritisation hint rather than a finding, which is the right weight to give it. But if the list was assembled by someone with a sector interest, the tenant count stops being the interesting metric.

What the vendor cannot tell you

Here is the sentence that should be read slowly, from ConnectWise's own advisory. By design, the configuration of Cloud Backup does not provide the company with visibility or access to downstream partner and customer environments, so it "cannot determine through our investigation alone whether a particular customer's Microsoft 365 environment experienced unauthorized activity."

The vendor cannot answer the only question its customers are asking. Not through incompetence, but through architecture. Cloud Backup was built to copy data out of tenants, not to observe what else touched them.

The logging picture makes that worse. Directory reads through Microsoft Graph leave no audit trail, and audit entries for application-only actions carry no source IP. Microsoft does not record what an application read. Graph activity logs, the one place that would show it, are off by default. Entra keeps sign-in and audit records for seven days on the free tier and thirty on P1 or P2, which means the evidence window for a 15 October event is already narrowing for anyone who has not exported it.

Conditional Access does not close this either. Policies for workload identities cover service principals registered in your own tenant, not a third party's multi-tenant application, so the location-based block that protects your users was never going to apply here.

ConnectWise's remediation has been substantial. It disabled seven application identities at 07:00 UTC on 17 October, revoked the certificates behind the affected connections, suspended Cloud Backup, and took SaaS Security and Cloud Management offline as a precaution. It has engaged a third-party forensics firm and says it has seen no successful threat activity since its mitigations went in.

But rotation is necessary and not sufficient, which is the lesson the five-minute persistence sequence was designed to teach. The vendor can rotate its own credential. It cannot reach into a customer tenant and delete a client secret that was planted on a different application in the middle of the night. That work belongs to the tenant owner, and it starts with a review of every credential added since 13 October.

There is a bitter operational trade-off buried in all of this, and MSPs had to make it in a single afternoon. Disabling the app stops the exposure. It also stops the backups. Some chose to disable and accept the coverage gap. Others went further and removed every SkyKick application from their customer tenants using management tooling, which is faster and more decisive and considerably harder to undo. Neither choice was wrong. Both were made without the logs needed to know which tenants had actually been reached.

This is not ConnectWise's first difficult week in the MSP ecosystem. Its ScreenConnect product carried CVE-2024-1709 in February 2024, a CVSS 10 authentication bypass that landed on CISA's known exploited vulnerabilities list and saw ransomware use. No source connects that flaw to this incident, and it should not be read as one. It is context for a structural problem: the tooling that MSPs use to administer hundreds of tenants concentrates privilege at exactly the layer attackers most want.

The trust boundary moved to the consent screen

The instinct after a week like this is to ask which vendor to trust. That is the wrong question, because the answer will keep changing and the consent will keep outliving the answer.

The better question is what your tenant is still carrying. Every tool an organisation has ever evaluated, piloted, migrated away from or acquired through a rebrand is potentially still sitting in the enterprise applications list with standing permissions and no owner. SkyKick's products now appear under both SkyKick and ConnectWise names, plus Cloud Manager variants, migration tools and Partner Center integrations. One rebrand and an acquisition can double the number of identities with keys to the same mailboxes. Inforcer found one MSP with SkyKick-family applications in 207 of its 895 tenants, roughly 190 of which had not used any of them in thirty days.

Consent sprawl is not unique to managed service providers, and it is not purely a software problem. Hardware companies shipping connected products accumulate the same shape of risk: a cloud backend, an integration or two per product line, a telemetry vendor, a support platform, an analytics tool, each consented once during a pilot and never revisited. Those identities hold standing access to customer data for the life of the product, and they frequently survive the vendor relationship that created them. The questions that decide how much exposure a product carries into year five are design and lifecycle questions, not detection questions. Who owns this integration, when was it last used, and what removes it when the contract ends.

ConnectWise is still investigating, still has no restoration date, and still cannot tell individual customers whether their tenant was touched. What it has published is a procedure: review the seven application IDs, export your logs before retention eats them, check every credential added since 13 October, enable Graph activity logs so the next incident has a trail, and do not re-enable anything until the vendor confirms rotation.

None of that is exotic. It is consent hygiene, done once, properly, across every tenant you are responsible for. The uncomfortable finding of this week is how few organisations can currently say when their third-party applications last signed in.

That problem has a hardware twin, and it shows up in connected product estates rather than IT departments. At DMC we work with hardware and electronics teams on the architecture, cost modelling and lifecycle planning behind cloud-connected products, including the standing integrations that quietly accumulate around a device fleet and outlive the pilot that created them. If your product roadmap is adding consents faster than it is retiring them, let's talk.

Sources: Huntress, "ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks," Jonathan Semon, 16 October 2026 with updates through 17 October; ConnectWise Trust Center advisory, "Cloud Backup (formerly known as SkyKick) Service Interruption," first published 16 October, updated 18 October 01:00 UTC; The Hacker News, Ravie Lakshmanan, 17 October 2026; BleepingComputer, Ionut Ilascu, 17 October 2026, including Todyl's analysis; Inforcer, Dan Harris, 17 October 2026; Microsoft Security Intelligence post of 15 October 2026 as quoted by The Hacker News.