Most organisations think they know where their front doors are. There is the login page, the password policy, the authenticator app that buzzes at 2 a.m. and the Conditional Access rule that blocks a suspicious country. Security teams spend years tightening all of it.
Then a backup service walks in through a door that was never in the floor plan.
Between 06:13 and 08:34 UTC on 15 October 2026, an unknown actor used a compromised vendor credential belonging to ConnectWise Cloud Backup, formerly SkyKick, to obtain Microsoft Graph tokens inside Microsoft 365 tenants that had installed the app. Huntress confirmed unauthorised sign-ins in 173 partner and customer tenants. Its wider telemetry showed sign-in activity from the same address against close to 1,000 Entra tenants, with more than 300 successful. The traffic moved in sorted GUID order, a few seconds per tenant, which is what a script walking through a target list looks like, not a human.
Nobody typed a password. Nobody approved a push notification. The app did exactly what it was built to do.
What the attacker inherited
ConnectWise Cloud Backup exists to protect data in Microsoft 365 and Google Workspace for managed service providers and their clients. To do that job it is granted broad, standing consent: read and write across mailboxes, OneDrive, SharePoint, Teams chats, and directory information, including restore rights.
An attacker holding that app's credential does not need to escalate. They inherit all of it. According to Todyl's analysis, the access carried full mailbox rights through Exchange Web Services, file access across OneDrive and SharePoint, Teams messages and directory reads, with the ability to restore data. That is not a foothold. That is the estate.
The sign-in came from 144.172.64[.]128, an address in the RouterHosting range. Microsoft's own service principal sign-ins for this application normally egress from Azure private IPv6 space, so the anomaly was visible to anyone filtering on it. The key phrase there is "anyone filtering on it": service principal sign-ins live on a separate tab in Entra. If your monitoring watches user sign-ins only, this event generated no noise in your world.
Why MFA and Conditional Access never fired
This is the part that should sit with every CIO for a while.
Multi-factor authentication authenticates humans. Conditional Access policies in most tenants are written against users and groups. An application authenticating with its own client secret or certificate is neither. It is a service principal, and its token is issued because the credential matches, not because a person satisfied a challenge.
So the standard controls we all lean on were not bypassed. They were out of scope. The perimeter in this incident was not identity verification. It was consent: every tenant where the app had been approved was reachable with a single credential. Revoking user sessions does not help either. Disabling the app stops new tokens, but tokens already issued stay valid for up to 90 minutes, which is ample for a scripted sweep.
The second wound: an app that crowned itself
In at least two tenants, the post-compromise behaviour went beyond reading. Around 03:45 UTC, within two minutes of each other, the ConnectWise Cloud Management app for Microsoft Teams self-assigned the Global Administrator role, then ran a script (Python-urllib/3.12) that planted new client secrets on a small number of other registered applications in the tenant. In one case that included a Huntress application, and separately an MSP management application.
Think about the shape of that. A management app is the kind of tool MSPs consent into their clients' tenants. A credential added to it is not a credential for one tenant. It is a key that may work in every tenant where that tool is trusted. Huntress removed the unauthorised credential from its own application on 16 October, and has since enabled App Instance Property Lock to stop fast property changes on its app registrations.
Huntress also noted what it did not see: no mailbox or file manipulation, no user or policy changes in the two tenants it examined. And a warning that matters more than the absence of evidence. Graph directory reads usually leave no audit record at all. You cannot prove the data was untouched when the reads were never logged.
The rest of the day
The same address was used in a second, narrower wave on 15 October, between 09:25 and 12:35 UTC and again from 13:54 to 14:20 UTC, aimed at 16 Huntress-protected tenants in the policy, national security, trade and critical minerals sectors. Most of those did not use ConnectWise products, so the attempts failed because the app was not present. That detail is the whole argument for least privilege in one line: absence of the app was the control that saved them.
The same infrastructure had also been password spraying four law firm tenants on 13 and 14 October. ConnectWise has disabled Cloud Backup application access until further notice and says it has found no evidence that partner backup data was compromised.
What to do this week, not next quarter
- Open the service principal sign-in logs. In the Microsoft Entra admin centre go to Monitoring, then Sign-in logs, then the Service principal sign-ins tab. Filter on Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and review 15 October. Repeat for the Cloud Management apps: Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519, Teams 24205314-2b89-4e07-a2a4-579e898a5640, SharePoint b2b55f5b-7758-4719-8d8f-88ae172e6bdb.
- Hunt the out-of-place address. Any authentication from outside expected Microsoft ranges is a finding. 144.172.64[.]128 is the primary indicator, and 144.172.64[.]99, .60 and 144.172.94[.]243 appear in related failed attempts.
- Disable the apps, do not delete them. Deleting loses the audit trail you are about to need. Keep them disabled until ConnectWise confirms the credential rotation.
- Audit every new secret and certificate added to any app registration since 13 October, including federated credentials. An unexpected expiry date in 2027 or 2028 is a persistence marker, not a mistake.
- Review directory role assignments for applications, and check privileged identity management history for grants you did not approve.
- Turn on Graph activity logs and unified audit logging now. You cannot investigate reads that were never recorded. If you are not collecting them, start before the next incident, not after.
- Assume the readable data was read. For the app's scope that means mail, files, Teams, and directory. Check for new inbox rules and forwarding, review sharing links, and brief whoever owns client confidentiality.
- Shrink standing consent. Least-privilege scopes, app instance property lock, restricted user consent, and a periodic review of every third-party app in every tenant you own. Your vendors' convenience is not a security architecture.
The takeaway for growing businesses
If you run a 40-person company on Microsoft 365, you almost certainly have a handful of apps that were approved years ago by someone who has since left, each holding broad standing access. That is the same exposure, just at a smaller scale.
The uncomfortable lesson from 15 October is not that ConnectWise was careless. It is that our mental model of identity security stops at the human. Service principals, consent grants and app credentials are the actual perimeter of a modern tenant, and in most organisations nobody owns them.
One credential. One hundred and seventy-three tenants. No MFA prompt anywhere. Fix the inventory before the inventory fixes you.