ConnectWise Cloud Backup Incident: What the SkyKick Breach Means for Microsoft 365 Security

Cyber Security Microsoft 365 Cloud Backup Incident Response

ConnectWise Cloud Backup Incident: What the SkyKick Breach Means for Microsoft 365 Security

Attackers used trusted application identities to enter customer Microsoft 365 tenants without a customer password or an MFA prompt. UK businesses now need to identify affected connections, review application sign-ins and understand the gap in backup cover.

Written by Jordan Stewart Status: Incident ongoing
ConnectWise Cloud Backup Incident: What the SkyKick Breach Means for Microsoft 365 Security
The short answer

ConnectWise has confirmed unauthorised access to application identities linked to ConnectWise Cloud Backup, formerly SkyKick. Security researchers observed the Cloud Backup application using its existing Microsoft 365 permissions to request app-only Microsoft Graph tokens in customer tenants. Because the application authenticated as itself, no employee password was stolen, and no user received an MFA prompt.

ConnectWise Cloud Backup, formerly SkyKick, has been taken offline while ConnectWise investigates unauthorised access to the application identities used by the service. According to the ConnectWise Trust Center, Cloud Backup, SaaS Security and Cloud Management remained suspended at the time of writing. Scheduled backups, archive access and restores were unavailable, although ConnectWise said existing backup archives remained encrypted, isolated and preserved, with no indication that those archives had been compromised.

ConnectWise's statement covers stored backup archives. Researchers also observed activity inside live Microsoft 365 environments. Sophos X-Ops observed a threat actor authenticating as the Cloud Backup application and requesting app-only Microsoft Graph tokens from customer tenants. Huntress also confirmed unauthorised sign-ins and, in one tenant it examined, found a related ConnectWise application assigning itself Global Administrator and adding credentials to other trusted applications.

The access didn't use a conventional account takeover, which is perhaps the most worrying thing. Attackers abused a trusted machine identity that already had permission to work across Microsoft 365.

What happened in the ConnectWise Cloud Backup incident

On the 15th of October 2026, researchers saw the ConnectWise Cloud Backup application authenticating into customer Microsoft 365 tenants from suspicious infrastructure. Huntress reported that the application received Microsoft Graph access tokens and that the requests moved through tenants in a scripted pattern. ConnectWise said it discovered the problem on the 14th of October and later confirmed unauthorised access to application identities associated with Cloud Backup.

ConnectWise disabled seven affected application identities and revoked their associated credentials two days later, while its technical investigation and remediation guide warns that vendor-side containment doesn't alter the status of enterprise applications within each customer tenant. It also doesn't undo changes that may already have been made or remove any separate credentials, permissions or identities created for persistence.

At the time of writing, ConnectWise said it had seen no successful threat activity in the environments it monitors since its mitigations began on the 17th of October. ConnectWise also stressed that this doesn't establish whether individual partner or customer Microsoft 365 tenants were affected. Each tenant still needs to be reviewed.

Why was there no password or MFA prompt?

A service principal is the identity an application uses inside Microsoft Entra ID. Microsoft explains that these sign-ins don't involve a user. The application presents its own credentials, such as a certificate or client secret, and requests access to the resources to which it has already been granted access.

The thing with cloud backup services is that they work in the background, and don't wait for somebody in finance to approve an MFA notification at 2am before copying a mailbox. An administrator consents to the application once, and the application then operates with those permissions.

An attacker with the application's credentials can then authenticate as the application and inherit its granted permissions. User-focused MFA isn't bypassed in the usual sense; it simply isn't part of an app-only sign-in.

MFA remains essential for user accounts and would still stop many ordinary account takeover attempts. An organisation can have strong MFA coverage for people while still carrying a separate identity risk through applications, integrations and automation.

What's confirmed and what remains uncertain

Confirmed Not yet established
Unauthorised access to application identities associated with Cloud Backup. The full route by which the vendor-held credential was obtained.
Successful app-only authentication into customer Microsoft 365 tenants was observed by security researchers. The final number of tenants affected or the precise activity in every tenant.
Cloud Backup, SaaS Security and Cloud Management were suspended while remediation continued. Whether data was copied from a particular tenant. A successful sign-in alone doesn't prove exfiltration.
ConnectWise reported no indication that stored backup archives were compromised. A restoration time for the suspended services at the time this draft was prepared.

A clean search can't rule out activity that wasn't captured in the available logs. Huntress found that some Microsoft Graph reads leave little or no useful audit trail, so administrators shouldn't claim a tenant is clear simply because the first search found nothing.

Why this matters to UK SMEs and mid-market organisations

A supplier identity can become part of your security boundary

Most organisations use trusted applications to back up data, manage users, connect security tools and automate routine work. Those applications often need broad permissions because their job crosses multiple mailboxes, files, Teams, SharePoint and directory data. The business may outsource the service, but the access still exists inside its tenant.

Old integrations don't always leave when the contract does

ConnectWise has told partners to review tenants with dormant SkyKick connections, as well as those with active deployments. Businesses should apply the same checks in principle to applications installed for a migration, trial or former supplier, as they may retain consent long after everybody assumes the relationship has ended.

The usual sign in view may miss the important activity

Service-principal events live in a different part of the Entra sign-in logs from ordinary user sign-ins, so a team checking only failed user logins could - very easily - miss the activity entirely. Monitoring needs to cover workload identities as well as employees and administrators.

The incident also creates a recovery gap

ConnectWise's containment suspended new backup jobs, archive access and restores. Existing archives may be preserved, but a preserved backup that can't currently be restored is still an operational constraint. Businesses should record the last successful recovery point, understand what data isn't being protected and decide how long that gap is acceptable.

What organisations should do now

An administrator or incident-response specialist should lead the review. Businesses that use ConnectWise Cloud Backup, previously used SkyKick, or receive the service through an MSP, reseller or marketplace should confirm who's reviewing each Microsoft 365 tenant and ask for a written status.

Identify every active and dormant ConnectWise or SkyKick connection. Search by the application IDs in ConnectWise's guide, not only by display name, because older installations may still carry SkyKick names.

Keep the affected enterprise applications disabled until ConnectWise gives formal restoration instructions. You don’t need to delete them at the start of the investigation; turning them off does enough to preserve their configurations and retain evidence.

Preserve that same available evidence as soon as possible. Export service-principal, user and managed-identity sign-in records, Entra audit logs, Microsoft Purview audit data and any relevant SIEM records before retention periods remove useful history.

Review service-principal sign-ins and directory changes. ConnectWise recommends checking activity from the 13th of October onwards, and extending back to the 1st of October where records permit. Its current guide lists three suspicious IP addresses: 144.172.64[.]128, 144.172.64[.]99 and 144.172.64[.]60.

Look for persistence beyond the original application. Review new application credentials, owners, consent grants, directory-role assignments, federation trusts, Conditional Access changes, new users, authentication-method changes and mailbox forwarding or transport rules.

Assess the backup interruption as a business continuity issue. Record the most recent completed backups, identify systems that are accumulating an unprotected data gap, and then confirm how restores will be handled while the service remains unavailable.

Escalate suspicious findings to your security provider and ConnectWise. Don't treat an IP address or Python user agent alone as proof of compromise; correlate the sign-in result, application, action and follow-on changes.

Trusted applications need the same governance as privileged users

Start with ConnectWise and SkyKick, then widen the review to other third-party applications in Microsoft 365. Many tenants accumulate enterprise applications faster than they retire them, and permission reviews often occur only when a new tool is approved.

Microsoft provides a route to review and revoke permissions granted to enterprise applications. For most organisations, a sensible governance cycle includes a named owner, a business purpose, the permissions granted, the publisher, the last use, credential controls where relevant and a clear removal process when the service is retired.

Monitoring should cover successful service principal sign-ins, new app credentials, and unexpected role assignments. Security teams are generally good at noticing a senior employee signing in from an unusual country. The equivalent event for a trusted application deserves the same attention.

Frequently asked questions

Was Microsoft 365 itself breached?

The evidence points to abuse of trusted ConnectWise application identities used to access customer Microsoft 365 tenants, but it isn't evidence of a vulnerability in Microsoft 365 authentication itself. Microsoft Entra issued tokens because the application presented a valid credential, and the customer tenant had already granted permissions to that application.

Does MFA protect against this type of attack?

Normal user MFA doesn't apply to an app-only service principal sign-in because there's no person completing the authentication. MFA remains important for user accounts, but organisations also need controls and monitoring for workload identities.

Were ConnectWise Cloud Backup archives compromised?

ConnectWise says existing backup archives remain encrypted and isolated, and that it has no indication they were compromised. The statement applies to stored archives and doesn't determine whether an individual's live Microsoft 365 tenant experienced unauthorised activity.

What if we used SkyKick years ago?

Check the tenant. ConnectWise specifically advises that you review dormant connections, as older installations may still use SkyKick display names. Match the application ID in the official guide rather than relying on the name alone.

Should we delete the affected enterprise applications?

Not immediately, no. It shouldn’t be the first response. ConnectWise's guidance actually recommends disabling affected applications and preserving their configuration and evidence. Deleting can remove information needed for the investigation and complicate any controlled reconnection later.

Treat application identities as privileged accounts

If you’re impacted, start by investigating affected tenants and managing the backup interruption first, then apply the same ongoing scrutiny to application identities as to other privileged accounts.

If you don’t already know, ask (or find out) which applications can read company data, which can change it, who still needs them, and whether anyone would notice if they signed in from somewhere unexpected. The review itself won't eliminate third-party risk, but it will show which suppliers can access the tenant and provide the business with a faster route to containment when something goes wrong.

If your organisation uses ConnectWise Cloud Backup or previously used SkyKick and you're unsure whether the tenant review has been completed, speak to your IT or security provider now. Fifosys can help organisations assess Microsoft 365 application access, preserve the right evidence and turn the findings into practical next steps.

Jordan Stewart
Jordan Stewart Fifosys insights, news and practical technology guidance for UK business leaders.
Talk to Fifosys

Know who and what has access to your Microsoft 365 environment

From application permissions and identity security to incident response and business continuity, Fifosys helps organisations understand their exposure and take practical steps to strengthen resilience.

Next
Next

What’s Changed in AI This Week? Microsoft Copilot Agents, Meta Muse Wonder, and the Governance Shift