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. The Cloud Backup service, formerly SkyKick, remains suspended. 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.
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–19, 2026; accessed October 19, 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.
