A Backup App Became a Skeleton Key: the ConnectWise Cloud Backup (SkyKick) Compromise of 100+ Microsoft 365 Tenants

On 16–17 October 2026, Huntress issued a rapid-response alert and ConnectWise disclosed a widespread incident: a threat actor abused the access obtained through ConnectWise Cloud Backup for Microsoft 365 — formerly SkyKick — to pivot into customers’ Microsoft 365 tenants. Huntress has confirmed over 100 compromised tenants. We are propagating this with full credit to the researchers; the facts and indicators below are theirs, and the authoritative source is the ConnectWise advisory.

The single detail that matters most: this is an application sign-in with a vendor credential, not a user sign-in. It never prompts for a user’s MFA, and it does not appear on the sign-in log most teams actually watch. That is the whole story of why a backup app became a skeleton key.

Do this now (Huntress guidance)

• ☐ Disable the app, don’t delete it. Entra Admin Center → Enterprise applications → find "SkyKick Backup" / "ConnectWise Cloud Backup" (or search the App ID) → Manage → Properties → set "Enabled for users to sign-in" = No. Leaving the app in place (disabled) means you can re-enable it later without re-consenting.
• ☐ Hunt on the right log. Entra → Monitoring → Sign-in logs → the Service principal sign-ins tab (the default User sign-ins tab will not show this), filter by the App ID, and flag any source IP outside Microsoft/Azure ranges — above all 144.172.64[.]128.
• ☐ Widen the search. Query the Microsoft 365 unified audit log for the App ID, the IP and the Python user agents; look for mailbox, Teams and SharePoint access and for any new app registrations, secrets or consent grants the actor may have added.
• ☐ Assume password spray. The same IP was seen spraying — review failed and successful interactive sign-ins from it, and reset exposed credentials.
• ☐ Mind the trade-off. Disabling the app stops your backups; plan for that. And per ConnectWise, the app’s mere presence confirms you are a customer, not that you were compromised — so hunt before you conclude.

The trend: vendor OAuth apps are the quiet way into Microsoft 365

Strip the brand names and this is an instance of a pattern that has been building for two years: attackers are increasingly walking into Microsoft 365 not through a user’s password and MFA, but through a consented third-party application and its service-principal (non-human) identity. A consented enterprise app holds standing, often broad permissions — here reportedly email, Teams and SharePoint (per ThreatLocker) — and it authenticates as itself, with its own secret, so:

• there is no interactive MFA to defeat;
• the activity lands on the service-principal sign-in log that most teams never review;
• and the permission grant survives a user’s password reset, because it is not the user’s credential.

When the compromised application is an MSP tool installed across hundreds of client tenants, the blast radius multiplies: one upstream compromise becomes a cross-tenant supply-chain event, which is exactly the "over 100 tenants" shape Huntress is describing. This is the same class of risk as consent-phishing and OAuth-token abuse campaigns — the difference here is that the app was a trusted, pre-installed vendor, so no user had to be tricked into consenting.

What a security leader should take from this

• ☐ Inventory your third-party enterprise apps and their permissions. Every consented app in Entra is a standing non-human identity with a key to some of your data. Know which ones can read mail, files and Teams, and who owns each.
• ☐ Watch service-principal sign-ins, not just user sign-ins. Build detections on app sign-ins from unexpected IPs/geographies and on anomalous volumes — the signal in this incident was on a tab most SOCs don’t monitor.
• ☐ Treat vendor credentials as privileged identities. Scope app permissions to least privilege, prefer short-lived credentials, and have a rehearsed path to kill a rogue vendor app across every tenant you manage.
• ☐ Have the third-party-breach muscle ready. When a vendor is the entry point, speed on notification, contract levers and blast-radius assessment is the job. Rehearse it in the free Vendor-Breach Board Response Lab → and work from the Third-Party Breach Playbook →.
• ☐ Score the identities. A consented app is an identity like any other — rate your human, service and app identities with the free Identity Risk Calculator →, and drill app-consent and conditional-access decisions in the OAuth Consent Phishing Lab →.

Credit & sources

This advisory is propagated from the work of others, to help it reach more defenders faster. Primary source and current guidance: the ConnectWise Trust advisories. Discovery, indicators and response steps: Huntress (@HuntressLabs)’ rapid-response thread. Corroborating coverage: ThreatLocker, Blumira and Coalition. Indicators and scope are from a fast-moving incident and may change — always confirm against the official ConnectWise advisory before acting.

Rehearse the vendor-breach decision in the Vendor-Breach Board Response Lab, work the Third-Party Breach Playbook, and score your app and service identities with the Identity Risk Calculator. Related reading: why non-human / agentic identity is the foundation control.