ConnectWise Cloud Backup (formerly SkyKick): the vendor's Microsoft 365 application credential was used to sign in to customer tenants, with directory-role self-assignments in about 50 tenants and added credentials in one
ConnectWise SkyKick app credential used in 162+ Microsoft 365 tenants; disabling it does not undo planted access
Defender actions
- In every Entra tenant you or your MSP administer, find the seven ConnectWise application identities by client ID (Cloud Backup is 506e08f9-6e9a-4da4-942b-a099a03644ae; the other six are in ConnectWise's advisory), dormant SkyKick connections included, and disable them without deleting, then keep them disabled until ConnectWise gives restoration instructions; preserve the sign-in and audit logs promptly without delaying containment, because Entra ID Free keeps only 7 days.
- In the same tenants review every enterprise application and app registration, MSP management and security tools first, for client secrets, certificates and federated credentials added since 2026-10-13 and remove any you did not create; also check the directory roles, owners and consent grants held by ConnectWise and SkyKick service principals, Conditional Access exclusions for them, and mailbox forwarding, inbox and transport rules and delegated access, because disabling the vendor applications does not remove access planted through them.
Analysis
ConnectWise says it identified unauthorized access to application identities within its Cloud Backup (formerly SkyKick) environment; on 2026-10-17 it disabled seven application identities, suspended the service, says the shared Cloud Backup credentials are no longer valid, and warns that disabling does not reverse changes already made in a tenant (ConnectWise, 2026-10-18). Huntress and Todyl report that on 2026-10-15 the app's identity signed in to customer Microsoft 365 tenants from one hosting-provider address and received app-only Microsoft Graph tokens; the credential sits in the vendor's own tenant, so no user, MFA prompt or user Conditional Access was involved, and the app's consent covers read and write access to mail, files and Teams chats (Huntress, 2026-10-16; Todyl, 2026-10-15). Huntress confirmed unauthorized sign-ins in 162 tenants by 2026-10-16 and later counted almost 1,000 tenants with sign-in activity from that address, over 300 successful, after password spraying against four law-firm tenants on 13 and 14 October, and a separate failed wave targeted 16 tenants in policy and national-security sectors (Huntress, 2026-10-16). In about 50 of its tenants, ConnectWise Cloud Management apps assigned themselves directory roles, mostly Exchange Administrator; in one the Teams app added itself to Global Administrator and client secrets were added to an MSP management application and to Huntress's own application within about five minutes, the credential additions from private Azure space (Huntress, 2026-10-16). Microsoft Threat Intelligence, as BleepingComputer relays it, called it an active supply-chain attack and assessed likely abuse of existing permissions including Directory.ReadWrite.All (BleepingComputer, 2026-10-17). How the credential was obtained, who is behind it and what was read remain unknown (ConnectWise, 2026-10-18; BleepingComputer, 2026-10-17).
Triage: the vendor's apps sign in from Azure addresses with a .NET SDK user agent, while the credential additions used a Python user agent; Python and curl are common in administration, so Huntress says the combination of actor, operation and user agent is the signal (Huntress, 2026-10-16). Role self-assignments carrying the vendor's own user agent are not proven benign, since Huntress has not confirmed vendor automation (Huntress, 2026-10-16).
Cited evidence
We recently identified unauthorized access to application identities within the ConnectWise Cloud Backup environment.
Disabling the affected connections prevents new authentication through those connections; it does not reverse changes previously made inside a tenant.
Whether a product vulnerability contributed has not been established.
As of 19:00 UTC on October 16, Huntress has confirmed unauthorized sign-ins in 162 tenants.
The credential type was a client assertion, which means the credential lives in the vendor's own tenant.
These tenants are in the policy, national security, trade, and critical mineral sectors.
Because the application already held broad, previously granted permissions in each tenant, those sign-ins gave the attacker the technical ability to read and write mail and attachments, OneDrive and SharePoint files, and Teams chats.
Revoking user sessions does not end this access.
Sources4
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.