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

> Huntress and ConnectWise disclosed a widespread incident (16–17 Oct 2026): a threat actor abused access obtained through ConnectWise Cloud Backup — formerly SkyKick — to pivot into customers’ Microsoft 365 tenants. It is an application sign-in with a vendor credential, not a user login, so it sailed past user MFA. Over 100 tenants are compromised. Indicators: Entra app ID 506e08f9-6e9a-4da4-942b-a099a03644ae, source IP 144.172.64[.]128, Python user agents, and password spray from the same IP. The IoCs, the exact disable/hunt steps, credited to Huntress and ConnectWise — and why vendor OAuth apps are becoming the quiet skeleton key into M365.

Source: https://playciso.com/blog/connectwise-cloud-backup-skykick-m365-oauth-compromise · Published: 2026-10-17 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://www.connectwise.com/company/trust/advisories

---

On 16–17 October 2026, **[Huntress](https://x.com/HuntressLabs)** issued a rapid-response alert and **[ConnectWise](https://www.connectwise.com/company/trust/advisories)** 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. **Indicators of compromise** (published by Huntress — verify against the [ConnectWise advisory](https://www.connectwise.com/company/trust/advisories) for the current list): - Enterprise app name: "SkyKick Backup" or "ConnectWise Cloud Backup" - Entra App ID: 506e08f9-6e9a-4da4-942b-a099a03644ae - Attacker source IP: 144.172.64[.]128 (also the source of observed password-spray activity) - User agents: Python-urllib/3.12 and python-requests/2.31 - Normal egress: the app’s legitimate traffic is Azure private IPv6 — so any sign-in for this App ID from a non-Microsoft/Azure IP is suspect. ## 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](https://x.com/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](https://www.connectwise.com/company/trust/advisories). Discovery, indicators and response steps: [Huntress (@HuntressLabs)](https://x.com/HuntressLabs)’ rapid-response thread. Corroborating coverage: [ThreatLocker](https://x.com/ThreatLocker), [Blumira](https://www.blumira.com/blog/connectwise-cloud-backup-skykick-compromise) and [Coalition](https://www.coalitioninc.com/blog/security-labs/connectwise-unauthorized-access-to-cloud-backup-app). 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](/tools/vendor-breach-lab), work the [Third-Party Breach Playbook](/templates/third-party-breach-playbook), and score your app and service identities with the [Identity Risk Calculator](/tools/identity-risk). Related reading: [why non-human / agentic identity is the foundation control](/blog/google-project-cc-agentic-identity-security-lessons)._