ConnectWise Pulls Cloud Backup Offline After Attackers Hijack Microsoft 365 Tenants
ConnectWise has killed off seven of its own application identities and suspended its Cloud Backup service after unknown attackers compromised the credentials those applications use to access customers' Microsoft 365 environments. The company confirmed the action on Saturday, saying it revoked certificates tied to the affected app connections across all users at 07:00 UTC on October 17, 2026.
The disabled identities cover ConnectWise Cloud Backup and a range of Cloud Management applications spanning MS Teams, Exchange Online, MS Graph, Partner Center, and SharePoint Online.
As a result, scheduled backups are not running, and access to backup archives and restoration is currently unavailable. ConnectWise was quick to stress that the archives themselves remain encrypted and intact, with no evidence attackers actually got into them. Cold comfort if you needed a restore this week, but at least the data appears safe.
The company says it first detected the problem on October 14 through internal monitoring, triggering an incident response. SaaS Security and Cloud Management have also been taken offline pending a full review. What remains unknown is how the application credentials were exposed in the first place. ConnectWise has not confirmed whether a product vulnerability was involved.
Why This Is Worse Than a Straight Password Theft
This type of attack is nastier than it might initially appear. Rather than stealing individual customer passwords, the attacker obtained the application credentials ConnectWise uses to authenticate into customer tenants. From there, they could request access tokens from Microsoft Entra ID under the application's existing identity, no per-customer credentials required.
Given that ConnectWise's apps carry broad permissions to perform backup and management functions, a stolen app credential hands an attacker a significant set of keys. They can authenticate as the application, escalate by adding it to the Global Administrator role, inject client secrets into other trusted apps within the tenant, or spin up entirely new applications with whatever permissions they choose. Those client secrets then act as a secondary foothold, one that persists even if the original stolen credential is eventually revoked.
A Second Wave, and a Narrow Target List
Huntress has been tracking the activity closely. According to Principal Security Operations Analyst Jon Semon, malicious sign-ins from the original source address were last seen on October 15 at 08:45 UTC, with what appeared to be deliberate, manual activity continuing until around 14:20 UTC that day.
Huntress also identified a second, targeted sweep from the IP address 144.172.64[.]128 on October 15, aimed at just 16 tenants operating in policy, national security, trade, and critical minerals sectors. The first pass targeted Graph tokens from the SkyKick app between 09:25 and 12:35 UTC. A second, apparently manual sweep hit the same tenants a few hours later, probing Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and the Office 365 Management APIs.
In total, Huntress has identified nearly 1,000 Entra tenants with sign-in activity from the IP address in question, of which around 300 succeeded. That said, the absence of a service principal in some tenants appears to have blocked the attacker from doing anything useful after logging in.
Huntress noted that the Cloud Management apps for Exchange Online, Teams, and SharePoint do not appear to have been disabled by ConnectWise, meaning further malicious activity through those channels remains possible. They are actively investigating.
What You Should Be Doing Right Now
If you are a ConnectWise partner, the recommended steps are straightforward but time-sensitive. Review your own Microsoft 365 tenant and every managed customer tenant, paying attention to any dormant SkyKick connections. Check sign-in logs from October 13 onwards, specifically for the IP address 144.172.64[.]128. Preserve audit records before you start making changes, or you risk losing the trail.
Beyond that, look for any new application credentials or federation trusts, changes to directory roles or consent grants, unauthorised mailbox forwarding rules, and any identities modified during the window of suspicious activity.
Huntress also pointed out some structural controls worth having in place regardless of this incident. Application management policies can cap credential lifetimes and restrict who can add client secrets. Keeping the Application Administrator and Cloud Application Administrator roles tightly controlled limits the blast radius if an app credential is stolen. Conditional Access for workload identities can restrict where an application is permitted to sign in from, and Entra ID Protection can flag risky service principal behaviour. None of it replaces actually auditing your credentials, but it makes a planted secret harder to exploit and easier to spot.