ConnectWise Cloud Backup Lost One App Secret. We Ran the Checklist on Our Own Microsoft 365 Tenant and Found Our Own Version of the Problem
If you manage Microsoft 365 tenants and any of them use ConnectWise Cloud Backup, formerly SkyKick Backup, disable that app in every tenant now and keep it disabled until ConnectWise says the credential has been rotated. Someone stole the app's credential and, from about October 15, used it to get Microsoft Graph tokens inside customer tenants. In affected tenants a ConnectWise app gave itself Global Administrator and added new secrets to other apps. ConnectWise shut off the app's access on October 17, so backups are down until further notice.
We don't use ConnectWise. We ran the checklist on our own tenant anyway, and it found our own version of the same problem.
What happened, from the people who saw it
ConnectWise's advisory says it found unauthorized access to application identities in its Cloud Backup environment, has contained it, and has no indication so far that partner backup data was accessed. It names one source address, 144.172.64.128, and two user agents, Python-urllib/3.12 and python-requests/2.31. The app normally signs in from Microsoft's own private address space, so a sign-in from anywhere else is the thing to look for.
Huntress, Guardz and Blumira published the rest. The abused app is "CW Cloud Backup Service Provider" with application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, which is the same in every tenant even though the display name changed with the rebrand. Guardz lists three more attacker addresses on the same hosting provider, RouterHosting (AS14956): 144.172.94.243, 2602:fa59:13:5f::1 and 2602:fa59:2:3559::1. Guardz also reports a ConnectWise Cloud Management app assigning itself Global Administrator. Huntress found secrets the attacker added that do not expire until 2028, which means access can outlive the fix to ConnectWise's own credential. An MSP on r/msp reported mail, Teams and SharePoint data being pulled. Data theft is not yet confirmed by the vendors, and ConnectWise has not said the credential was rotated.
What to do, in Microsoft's own tools
Everything below is in the Microsoft Entra admin center and the Microsoft Purview audit log. No third-party tool is required.
First, find the app. In Entra, open Enterprise applications, set the application type filter to All applications, and search for 506e08f9-6e9a-4da4-942b-a099a03644ae. Guardz lists six more ConnectWise app IDs worth checking: 2399d300-6fca-4e6a-a686-399fefe75b83, 24205314-2b89-4e07-a2a4-579e898a5640, b78f6a77-d4e5-46fb-87e5-d1648bd02519, 0de14c77-b9b0-4137-9360-34878a929827, 412dcf96-176d-4b3a-a1b0-4981ad66971e and b2b55f5b-7758-4719-8d8f-88ae172e6bdb.
Second, disable it, don't delete it. In the app's Properties, set "Enabled for users to sign-in?" to No. Deleting removes consent and evidence. Tokens already issued keep working for roughly 60 to 90 minutes after you disable, per Blumira.
Third, export your logs from October 13 now. The service principal sign-ins are on their own tab in Entra sign-in logs, not the default user tab, and free-tier retention can be as short as seven days. Look for sign-ins by these app IDs from outside Microsoft address space.
Fourth, check what the attacker would have changed. Review who holds Global Administrator, Privileged Role Administrator, Application Administrator, Cloud Application Administrator and Exchange Administrator, and remove any service principal you did not put there. On every app registration, look for client secrets or certificates added since October 13. In Exchange, look for new inbox rules, forwarding and mailbox permissions.
Fifth, report what you find to ConnectWise at [email protected], and do not re-enable the app until ConnectWise confirms rotation.
What our corpus adds
The four attacker addresses are in our feed as of today, credited to ConnectWise and Guardz, under the source manual-batch-connectwise-cloud-backup-2026-10. Their main use is hunting in your sign-in logs. Blocking them at a firewall does not stop this kind of abuse, because the stolen credential works from Microsoft's own cloud, not through your network.
The neighborhood is worth knowing. In the same RouterHosting ranges, our corpus already held fake ScreenConnect installers, ScreenConnect.ClientSetup.exe served from 144.172.94.235 on June 1, from 144.172.94.21 on June 24 and from 144.172.64.22 on October 10, five days before this incident. ScreenConnect is ConnectWise's own remote-access product. The same ranges carry Remcos and Interlock command servers and an address from Elastic's ClickFix infostealer report. That is context about a hosting provider, not attribution. It does say where to look next.
We ran it on ourselves
We do not ask readers to run a check we have not run. So we ran this one, read-only, against our own Microsoft 365 tenant with Microsoft Graph and the Azure CLI.
On the incident's own terms we were clean. None of the seven ConnectWise or SkyKick apps is in our tenant. No app or service-principal secret was added since October 13. The only new service principals were two Microsoft first-party apps that Microsoft provisions on its own.
The same lens found two things of ours.
The first is our own feed-to-Exchange app. We push our high-confidence indicators into Exchange Online's Tenant Allow/Block List every day, so our own mail is filtered by our own feed. The app that does it held Exchange Administrator across the whole tenant to run nine commands. That is the same shape that hurt ConnectWise: one stolen secret, tenant-wide standing power. We are moving it to a custom Exchange role group that holds only the roles containing those nine commands, then removing Exchange Administrator. Microsoft's "RBAC for Applications" does not cover these commands, because they live in Exchange Online PowerShell, not Graph, so the role group is the right tool here.
The second is older. In February 2025, before this company existed, a cloud-security platform trial was onboarded to this tenant. Its policy was still assigned at the tenant root, asking for Owner on every subscription so it could create its own resource group in each one. It held no role and its target subscription was disabled, so it was inert. But for twenty months nobody had looked. The platform's scanners were still trying to sign in every couple of minutes, about 97 percent of all service-principal sign-ins we saw this week, failing every time because the app no longer exists on our side. We exported the policy as evidence and deleted it. Only the vendor can stop the retries. We also removed three expired app secrets that were still registered.
What we ask of you, by comparison
None of our products asks for consent in your tenant. Our feed and package checks are pulls over HTTPS, read-only, and our edge shield is a worker you deploy in your own Cloudflare account with a key you set yourself. We never sign in to anything of yours, so there is no standing app of ours for anyone to steal. That is a design choice we would rather explain than have tested.
The pattern
This is the second time in a week that the problem was standing power held by something people stopped looking at. Yesterday it was an AI coding agent's toolchain, today it is a backup app. Our package checks, the free GitHub Action and the MCP servers exist for the first case. For the second, the check is the one above.
Read ConnectWise's advisory in its Trust Center, and the Huntress, Guardz and Blumira write-ups, for their full detail. All analysis of the incident is theirs. Our own tenant evidence is dated and kept with our compliance records.
We checked the claims in this post against the vendor advisories and our own tenant output before publishing. At least 5% of what remains is still wrong, and we don't know which.
If this was useful, or if it wasn't, rate it at the bottom of the page. It is the only direct signal we get.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=connectwise-cloud-backup-lost-one-app-secret-we-ran-the-checklist-on-our-own-microsoft-365-tenant-a
Comments