ConnectWise’s backup connection became a way into customers’ live Microsoft 365 environments—and, in one investigated tenant, a route to leave fresh credentials in other trusted applications. In its October 22, 13:00 UTC update, ConnectWise says Cloud Backup, formerly SkyKick, is returning in phases subject to security validation. Affected connections must remain disabled until formal instructions apply to the specific service. The practical response goes beyond waiting for backups to restart: administrators need to inspect application access, including old SkyKick connections that may have outlived the subscription.
Huntress and Todyl published their investigations on October 16, describing activity on October 15. ConnectWise’s October 18 update added two IP indicators; its October 19, 01:15 UTC update still reported no confirmed restoration time. The provider says stored backup archives remain encrypted and isolated, with no indication of compromise. That finding concerns the archives, not a clean bill of health for each customer’s live tenant.[1]
The attacker signed in as the backup application
A backup service needs permission to copy data and restore it. In Microsoft 365, a customer administrator can grant those permissions to an application; its local identity is called a service principal. The service then authenticates with its own credential rather than asking an employee to log in for every backup.
Todyl found an unauthorized party using the already-approved ConnectWise Cloud Backup identity to obtain Microsoft Graph tokens. Requests moved through tenant IDs in ascending order, roughly one to six minutes apart. Several investigated tenants no longer had an active backup subscription. An unused subscription therefore did not mean the old application access had disappeared.[2]
This distinction explains the MFA problem. There was no employee approving a push notification or typing a password: the application authenticated on its own. Resetting a user password or revoking that user’s sessions does not remove an application’s credentials or consent. The separate Microsoft 365 passkey phishing case targets a person’s authentication; this incident crosses a different trust boundary.
The useful part of the screenshot is the selected Service principal sign-ins tab. An administrator searching only interactive user logins can miss this activity. Huntress’s example shows successful Cloud Backup sign-ins to Microsoft Graph from 144.172.64[.]128.[3]
Five minutes created another way back in
Huntress described a second, more consequential sequence in one customer tenant on October 15, between 03:44 and 03:49 UTC. The ConnectWise Cloud Management application for Microsoft Teams assigned itself Global Administrator, then added client secrets to two other applications: an MSP management tool and that tenant’s Huntress application. A certificate addition failed; secret additions succeeded, with expiry dates in 2028.
A new client secret is another working way to authenticate as its application. It can survive the disabling of the original ConnectWise connection because the credential belongs to a different identity. Huntress later found seven sign-ins using the credential planted on its application and removed that credential on October 16.
The timing also limits the reconstruction. The credential additions preceded the later public-IP backup sign-ins; Huntress did not establish that both phases had the same operator. A private Azure IPv6 range appeared in the earlier activity, but legitimate traffic also uses that range. Neither a private address nor a Python user agent alone identifies an attacker.
October 21 update: Microsoft separates failed spraying from application access
Microsoft now assesses that the China-state-aligned actor Storm-0940 was responsible for the ConnectWise supply-chain compromise and used the ARTEX agentic-AI framework to accelerate activity. Its October 21 investigation describes attempts to sign in to more than 2,250 customer tenants through compromised application identities. That is attempted reach, not a count of tenants proven breached or data proven stolen.[4]
The report also separates an earlier password-spray campaign on October 10–14: 151,000-plus failed logons against 327 accounts across eight organizations, with no observed successful authentication, token issuance, Graph call or directory change in that activity. In the subsequent application-credential phase, Microsoft did observe authentication and follow-on Graph and directory activity in multiple environments. AI increased the speed; the access still depended on credentials and permissions that the applications already held.
Microsoft warns that unauthorized credentials planted on other identities can remain after the original ConnectWise access is contained. Preserve evidence, keep affected connections disabled pending the provider’s restoration instructions, and correlate service-principal sign-ins with credential additions, owners, grants and privileged-role changes. Review from at least October 15; where records exist, extend service-principal review to October 1. Have an authorized responder remove confirmed unauthorized changes after preserving the evidence. Successful authentication alone still does not establish data access or exfiltration.
Successful access is established; the data-loss total is not
Huntress’s dated counts changed as the investigation expanded: 162 tenants with confirmed unauthorized sign-ins at 19:00 UTC on October 16; its October 17 update reported activity across almost 1,000 tenants, with successful sign-ins in more than 300. Those are authentication observations—not a count of organizations proven to have had files stolen.
Todyl did not find persistence through the backup app in its investigated tenants. In tenants with active backups, legitimate and malicious requests could share the same application identity, making read activity difficult to attribute without the relevant Graph request logs. These findings describe different observed samples; they do not cancel Huntress’s separate credential-addition case. Enabling additional logging now also cannot reconstruct records that were never collected.
Review every connection, then the identities it changed
ConnectWise says it disabled seven affected application identities on October 17. Administrators should keep affected connections disabled until formal restoration instructions arrive, preserve available records, and review their own tenant as well as every managed customer tenant. Disable rather than delete the applications while investigating, so evidence and consent details remain available.
- Find the exact app. In Entra Enterprise applications, search for Cloud Backup application ID
506e08f9-6e9a-4da4-942b-a099a03644ae, including the SkyKick name. Also review the wider Cloud Management family listed in the vendor guidance. - Search the right logs. Use Service principal sign-ins and correlate application IDs, times, source addresses and operations. The October 18 vendor update lists
144.172.64[.]99and144.172.64[.]60alongside144.172.64[.]128. An IP-only search cannot cover the earlier private-address activity. - Inspect the changes. Review application secrets and certificates, directory-role assignments, owners, consent grants, federation trusts, and mailbox forwarding or rules. Investigate other identities modified during suspicious activity; removing access from the original app does not remove credentials planted elsewhere.
- Track the recovery gap. Confirm backup and restore availability with the provider and maintain an authorized continuity plan while services are paused. An intact archive and an available restore service are different things.
This is a cloud identity incident. A local malware scan cannot revoke application secrets, undo tenant permissions, or determine what Graph data was read. Recovery depends on reviewing the access that was granted—and every additional identity that access may have changed.
References
- ConnectWise. “Cloud Backup (formerly known as SkyKick) Service Interruption.” Trust Center, October 16–22, 2026; updated October 22, 13:00 UTC; accessed October 22, 2026. Incident updates and administrator guidance.
- Nicholas Koken. “Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App.” Todyl, October 16, 2026. Investigation findings.
- Jonathan Semon. “ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks.” Huntress, October 16, 2026; updated October 17; accessed October 19, 2026. Authentication and credential-addition investigation.
- Microsoft Security Research and Microsoft Threat Intelligence. “AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise.” Microsoft Security Blog, October 21, 2026; accessed October 22, 2026. Attribution, observations and response guidance.
