TL;DR
- 01What happened
In October 2026, credentials for ConnectWise applications, including Cloud Backup (formerly SkyKick), were abused to sign in to customers’ Microsoft 365 tenants. Huntress reported sign-in activity from the attacker’s IP in about 1,000 tenants, more than 300 of them successful. On the same day, in two customer tenants, the identity of another ConnectWise app made itself Global Administrator (Huntress does not tie this to the same attacker as the sign-ins). How the credential was exposed is unknown, and the incident is ongoing.
- 02Why it was hard to tell
The attacker used no customer password; it authenticated as an app the customer’s administrator had consented to. At authentication, the app’s own action and another party’s action using its credential look the same.
- 03The missing layer
ConnectWise discovered the unauthorised access on 14 October, yet on the 15th, before the app identities were disabled on the 17th, the self-granted administrator rights went through. What did not work was a layer that checks independently, before it runs, whether an action by a consented app identity is one the vendor intended.
What happened
- Scope of products
- ConnectWise’s Cloud Backup (formerly SkyKick) and Cloud Management Microsoft 365 apps, installed with administrator consent in MSP and customer tenants.
- Credential abuse
- the Cloud Backup app identity’s credential was used to sign in to customer tenants (Huntress). No customer password was needed; tokens were obtained as the app.
- Scale
- on 17 October Huntress reported attacker-IP sign-in activity in about 1,000 tenants, with more than 300 succeeding (162 tenants were confirmed as of the 16th). The credential works wherever the app is consented, so real exposure may be larger.
- Self-granted admin rights
- on 15 October, in two customer tenants, the identity of Cloud Management’s Microsoft Teams app made itself Global Administrator and added credentials to other apps.
- ConnectWise response
- on 17 October it disabled seven app identities, revoked related certificates and suspended three services including Cloud Backup. Disabling does not reverse changes already made, and issued tokens may remain usable until they expire (company advisory).
- Route in
- unknown. A product vulnerability “has not been established” (ConnectWise).
Glossary
Tenant — An organisation's own environment in Microsoft 365 (Entra ID). Users, apps and permissions are managed per tenant.
App identity (service principal) — An identity that lets an app, not a person, sign in to a tenant. It holds the permissions an administrator consented to, and whoever holds its credential can act with them.
Token — A time-limited pass issued after authentication. Disabling an app may not stop tokens already issued until they expire.
③ and ④ are actions by different apps, and Huntress does not tie them to the same attacker. Both went through on the basis of the consent at ①, unchecked.
Installed in MSP and customer tenants.
Route unknown.
In two customer tenants, adds credentials to other apps.
Obtains tokens.
Timeline — disclosure and response
- ConnectWise discovered the unauthorised access (company advisory).
- at about 03:44 UTC, in one customer tenant, Cloud Management’s Teams app made itself Global Administrator and added credentials to two apps. From 06:13 to 08:34 UTC, the attacker’s IP authenticated as the Cloud Backup app.
- Huntress published (162 tenants). ConnectWise published its advisory.
- ConnectWise disabled seven app identities and suspended Cloud Backup. Microsoft Threat Intelligence posted a warning on X. Huntress reported about 1,000 tenants with activity.
- Huntress confirmed the same self-granting of admin rights in a second customer tenant. Updates continued into 10-20; as of 00:45 UTC on 20 October, all three services remained suspended.
Facts here rest on Huntress, a researcher publishing its own findings, and ConnectWise’s official advisory. Unconfirmed: how the credential was exposed, whether a product vulnerability contributed, and whether the self-granted admin rights and the sign-ins were the same attacker. Huntress also monitors affected tenants, and its own app was targeted.
After disclosure
- Huntress: recommended disabling the apps and reviewing credentials, roles and audit logs.
- Todyl: reported that tokens already issued can stay valid for up to 90 minutes after an app is disabled.
Why it wasn’t stopped
The failure is neither weak customer passwords nor a mistake. An app credential gives its holder the app’s permissions as they stand, and role assignment and credential additions went through with no check before they ran that they were operations the vendor intended.
Consent given once at install was used as the basis for later administrative actions, without being checked each time they ran.
Proof acts before an action runs; detection acts after an anomaly surfaces. In between, the app identity's actions are treated as legitimate, as consented.
The app identity is still live
Detection worked: Huntress told the self-elevation apart using clues such as an unusual user agent. But it came after the action, and administrator grants went through until the apps were disabled. “The app was consented to” and “this action is one the vendor intends” are different facts: the first is recorded at install, the second must be checked each time. That distance is the gap between detection and proof, and it is a structural gap.
The same structure appears in Vercel/Context.ai (an “allow all” OAuth grant to an AI tool as the entry point) and Salesloft Drift (stolen OAuth tokens used to query over 700 Salesforce environments).
How to counter this
Even if a vendor app’s credential gets out, the customer side can narrow what it lets through. Even without knowing how the credential was exposed, decide at install which actions each app identity may take, and hold actions that change permissions, such as role assignment or adding credentials, for a check before they run. Keep what was held and what was let through somewhere separate from the app.
Industries and operations to watch
- IndustryProcurement & supply chain
- MSPs, and organisations that hand Microsoft 365 backup or management to an outside service. Backup and management SaaS often ask for tenant-wide permissions.
- OperationAccounts & permissions
- Managing the apps installed in a tenant and the permissions they hold. The actions here came not from a user but from a consented app identity.
Do today’s controls close it?
| Control | Here | Why |
|---|---|---|
| User multi-factor authentication (MFA) | Not relevant | The attacker used no user password; it authenticated as the app and obtained tokens. |
| Reviewing consent at install | Partial | Can narrow how broad the app’s permissions are. Within them, any action passes for whoever holds the credential. |
| Monitoring sign-ins and audit logs | Partial | Huntress used a differing user agent as a clue, but that alone is not conclusive. It comes after the action, and directory reads leave no audit record. |
| Vendor disabling the app identities | Partial | Stops further authentication. Changes already made are not reversed, and issued tokens may remain usable until they expire. |
- Decide at install which actions an app identity may take. For example, reading backup data is allowed; self-assigning directory roles or adding credentials to other apps is not. Decide by kind of action: the breadth of consented permissions alone does not draw this line.
- Hold permission-changing actions for a check before they run. Check role assignments and credential additions from an app identity against the decided scope, and refuse those outside it. Also check, separately from the credential, that they came from the registered execution environment.
- Record which permission each action relied on, separately from the app. Keep what was held and what was let through in a form you can later show a third party — that is, as proof.
Three things to confirm in your organisation about apps consented in your tenant
- Do you regularly review for apps no longer in use, or permissions broader than needed?
- When an app identity assigns itself a role or adds credentials to another app, who is notified?
- When a vendor discloses a compromise, is there a set procedure and owner for disabling that app and checking issued tokens, added credentials and assigned roles?
Note: this still fails if the registered execution environment itself is compromised, or if an action within the decided scope is misused, and a loosely decided scope passes loosely. Holding permission-changing actions for a check also delays the vendor’s legitimate ones. How the credential was exposed has not yet been disclosed; this Brief will be revised if follow-up reports reveal it.
Sources
- Primary, company advisoryConnectWise “Cloud Backup (formerly known as SkyKick) Service Interruption”
- Primary, post on XMicrosoft Threat Intelligence Post on the compromise of the ConnectWise Cloud Backup OAuth app
- Primary, researcher’s own publicationHuntress “Vendor credential enables unauthorized access”
3 more (reporting, analysis)
- Independent reportingThe Hacker News “Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants”
- Independent reportingThe Hacker News “ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants”
- Independent analysisTodyl “Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App”
References: why after-the-fact detection is not proof is covered in the last layer left in AI-era cyber defense.