Nobody got phished. Nobody’s password was guessed. No MFA prompt was approved by a tired employee at midnight.
On October 15, an attacker signed in to customer Microsoft 365 tenants as a backup application. According to Huntress, a credential belonging to ConnectWise Cloud Backup (formerly SkyKick) was used to request Microsoft Graph access tokens across customer tenants, and by the next day Huntress had confirmed unauthorized sign-ins in 162 of them. Huntress later saw sign-in activity from the same infrastructure across almost 1,000 Entra tenants, with more than 300 of those sign-ins succeeding.
The detail that should keep every MSP up at night is how simple it was. As Huntress put it, the credential “lives in the vendor’s own tenant. Nothing a customer did in their environment could have produced it.” The access came from permissions customers had already granted.
This isn’t a story about one vendor. It’s a story about how every MSP stack is built.
What happened, and what we don’t know yet
The facts below come from the vendor and the researchers who investigated. The investigation is still open, so it’s worth separating what’s confirmed from what isn’t.
Confirmed:
The attacker authenticated as the application itself, not as a user. Sophos X-Ops found the sign-ins “required no user password and no MFA,” and the activity appeared to be scripted, working through a list of tenants in order.
The app’s existing permissions were broad by design. A backup service needs to read mail, files, and Teams data to back them up. Todyl’s head of detection engineering told The Hacker News that the inherited access included read/write access to mail and attachments, OneDrive and SharePoint files, and Teams chats.
In a small number of tenants, the attacker went further. Huntress observed a related ConnectWise Cloud Management app grant itself Global Administrator and then add new credentials to other applications in the tenant, including an MSP management tool and a Huntress app. That’s how a foothold survives after the original app is turned off.
ConnectWise moved to contain it. The company disabled seven application identities on October 17, suspended Cloud Backup, SaaS Security, and Cloud Management, and completed a full reset of accounts and credentials in the affected environment on October 19, according to its Trust Center advisory. It says existing backup archives remain encrypted and isolated, with no indication they were compromised.
Not yet known:
How the credential was obtained. ConnectWise says the exposure mechanism is still under analysis.
Whether any data was stolen. Huntress has not confirmed data theft, and Sophos says it’s unclear what the attacker did with the tokens.
Who did it. No group has been publicly identified or has claimed responsibility.
ConnectWise has also been clear about a limit of its own visibility: its findings about the backup archives do not establish whether individual Microsoft 365 environments were affected. That part is on each partner and tenant owner to check.
The finding that matters most for everyone else
One line in the Sophos write-up deserves more attention than it has gotten. The sweep included tenants with no active backup subscription, which Sophos said suggests the attacker worked from a full list of tenants that had consented to the app, including ones that were no longer customers.
In other words, some organizations stopped using the service but never removed the app’s access. The subscription ended. The permission didn’t.
That’s the real lesson, and it applies to every tool in your stack. When a client or MSP approves a multitenant app in Microsoft 365, the vendor’s application identity can request tokens in that tenant until someone removes the approval. Backup, email security, documentation, PSA and RMM integrations, security monitoring, compliance automation: they all work this way. They all need access to do their jobs. And very few MSPs have a process for reviewing that access after the day it was granted.
Why your usual controls don’t catch this
Most identity security is built around people. App sign-ins slip past it.
MFA doesn’t apply. Apps authenticate with a certificate or secret, not a phone. Microsoft describes service principal sign-ins as sign-ins where “the app or service provides its own credential.”
Conditional Access mostly doesn’t apply. Microsoft’s Conditional Access for workload identities can only be applied to single-tenant apps registered in your own tenant. Its documentation states that “Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies.”
Revoking user sessions doesn’t help. As Todyl noted in The Hacker News, “Revoking user sessions does not end this access.”
The default log view hides it. App sign-ins live on a separate Service principal sign-ins tab in Entra. As The Hacker News noted in its investigation steps, the default User sign-ins tab won’t show them.
If your monitoring is tuned for risky user logins, a vendor app signing in from a new hosting provider can look like nothing at all.
The fix: treat connected apps like privileged accounts
You would never leave a former employee’s Global Admin account active for three years. Connected apps deserve the same discipline. Here is a practical sequence MSPs can run across every client tenant.
1. Inventory every connected app
In each tenant, pull the full list of enterprise applications and the permissions granted to them. Microsoft’s guide to reviewing permissions granted to enterprise applications walks through the Admin consent and User consent tabs for each app. Record the app, the vendor, the permissions, who approved it, and which service it supports. An app nobody can explain is a finding.
2. Rank apps by what they can do
Not every app is a risk. A calendar add-on that reads one user’s profile is not the same as an app with tenant-wide mail access or directory write permissions. Flag the apps that can read or write all mail, all files, or the directory, and any that can assign roles. Those get the closest review and the shortest list of approved IP ranges and behaviors.
3. Remove approvals when the service ends
Add “remove app consent” to two checklists you probably already have: vendor offboarding and client offboarding. When a tool is retired, its approvals go with it. Microsoft notes that revoking a permission doesn’t stop users from consenting again if the app can still request it, so pair removal with a consent policy that routes new app requests to an admin.
One caution for anyone affected by the current incident: retiring an unused app is different from responding to an active compromise. ConnectWise and Huntress both advise customers to disable, not delete, the affected apps, because deleting them can interfere with restoring existing backups.
4. Watch app sign-ins and app changes
Set alerts for:
Service principal sign-ins from IP addresses outside the vendor’s normal range
New secrets or certificates added to any app
Any app assigned to a directory role
New admin consent grants
For deeper visibility, Microsoft Graph activity logs record the API requests apps make in a tenant, including “all transactions made by applications and other API clients you’ve consented to.” They require Entra ID P1 or P2 and an Azure log destination, and they only help if they were turned on before an incident. Sophos specifically recommended retrieving them to see how issued tokens were used. Huntress also warned that some access, such as directory reads through Graph, leaves no audit trail without them.
5. Plan for the vendor being down
The current incident has a second lesson. While the services are suspended, ConnectWise says scheduled backups, archive access, and restores are unavailable, with no confirmed restoration time as of its October 21 update. Containment was the right call, but it means clients need an answer to a simple question: if our backup or security vendor goes offline for a week, what do we do? Write that answer into the incident response plan before you need it.
Turning this into a service
Connected-app reviews fit naturally into the work MSPs already do. They’re an access review, a third-party risk review, and a recurring piece of evidence, all in one.
For each client, keep:
The current connected-app inventory, with owner and business purpose
The date of the last review and who signed off
A record of apps removed and permissions reduced
The alert rules in place for app sign-ins and credential changes
That record does double duty. It’s operational security, and it’s the kind of dated, owned evidence auditors, insurers, and vendor-review questionnaires increasingly ask for. In a QBR, it gives you a clear, non-technical story: here is every outside company that can reach your data, here is what each one can do, and here is what we removed this quarter.
That’s a security program outcome a business owner understands. And it closes the gap this incident exposed: access that was approved once, then forgotten.
If you use ConnectWise Cloud Backup or SkyKick today
Follow the ConnectWise technical investigation and remediation guidance for your own tenant and every client tenant you manage. In short:
Keep the affected apps disabled, not deleted, until ConnectWise provides re-enablement instructions.
Review service principal sign-ins for the affected app IDs during October 15 to 17, and audit logs for new credentials, consents, and role assignments since October 13, as Sophos recommends.
Check every app in the tenant for credentials added since October 13. Huntress warns that disabling the ConnectWise apps will not remove credentials that were already added to other apps.
Check for unauthorized mailbox forwarding, inbox rules, and delegated mailbox access, per the ConnectWise guidance summarized by Infosecurity Magazine.
Frequently asked questions
Q: What happened in the ConnectWise Cloud Backup incident?
A: An attacker obtained a credential belonging to the ConnectWise Cloud Backup application (formerly SkyKick) and used it to sign in to customer Microsoft 365 tenants as that app. Huntress confirmed unauthorized sign-ins in 162 tenants by October 16. ConnectWise suspended the affected services and reset credentials, and says backup archives show no indication of compromise. How the credential was obtained, and whether any data was stolen, had not been confirmed as of October 21.
Q: Why didn’t MFA stop the attack?
A: MFA protects people, not applications. The attacker authenticated with the app’s own credential, so no user sign-in or MFA prompt was involved. Sophos confirmed the sign-ins required no user password and no MFA.
Q: Can Conditional Access protect third-party apps in Microsoft 365?
A: Only partly. Microsoft’s Conditional Access for workload identities applies to single-tenant apps registered in your own tenant, and does not cover third-party or multitenant SaaS apps. For those apps, the main controls are limiting permissions, removing unused approvals, and monitoring app sign-ins and credential changes.
Q: How often should MSPs review connected apps in client tenants?
A: At minimum, review connected apps at each client’s regular access review, whenever a vendor or tool is retired, and when a client offboards. High-privilege apps, such as those with tenant-wide mail, file, or directory access, deserve alerting on new credentials, role assignments, and unusual sign-in locations rather than waiting for the next review.
Q: Does an unused app still have access after the subscription ends?
A: It can. Canceling a subscription doesn’t automatically remove the app’s permissions in Microsoft 365. In this incident, Sophos found the attacker’s sweep included tenants with no active backup subscription, which suggests the app was still approved in tenants that had stopped using it. Removing app consent should be part of every vendor and client offboarding checklist.