The ConnectWise SkyKick Compromise: Who Else Has Access to Your Microsoft 365 Tenant?

Most organizations can tell you who their administrators are. Ask which applications can read every mailbox, access company files, or change directory permissions, and the answer often takes a little longer.

The recent ConnectWise Cloud Backup incident, involving the service formerly known as SkyKick, shows why that second question deserves more attention.

Attackers used a compromised application credential to access multiple Microsoft 365 tenants through an integration those organizations had already approved. Huntress initially confirmed unauthorized sign-ins in 162 tenants. Its subsequent investigation also identified activity in two tenants where an application assigned itself Global Administrator and added credentials to other applications to maintain access. Those findings should not be read as evidence that every affected tenant experienced the same activity.

For anyone responsible for Microsoft 365 security, this deserves a closer look than simply checking whether the company uses SkyKick.

How a backup integration became a way in

Backup services need access to the information they protect. In Microsoft 365, that access often comes through an application identity in Microsoft Entra ID.

A vendor can operate a multitenant application, with a local representation called a service principal in each customer’s tenant. That service principal carries the permissions granted to the application. The vendor’s application registration and the customer’s enterprise application are related, but they are separate objects. This is why reviewing only your own App registrations misses part of the picture.

Sophos observed attackers authenticating as the ConnectWise Cloud Backup application and requesting Microsoft Graph access tokens across customer tenants. Its researchers assessed the activity as an automated sweep using a compromised vendor-held credential. The precise method used to obtain that credential remained unclear.

Once the attacker could authenticate as the application, the permissions customers had already granted became available to that attacker.

That is a substantial amount of trust sitting behind a credential the customer does not directly control.

Why MFA did not stop it

There was no employee login to approve.

These were application sign-ins using the application’s own identity. Sophos confirmed that the observed token requests required neither a user password nor an MFA challenge. User MFA could be working exactly as intended while this access occurred.

That distinction matters when reviewing security coverage. A report showing that every employee has MFA enabled tells you something useful about employee authentication. It does not establish that your application identities are adequately protected or monitored.

Disabling the original application is only part of the response

The persistence findings are especially concerning. A credential added to another application can provide a separate route back into the tenant. Disabling the application used for the initial access does not remove that new credential.

Huntress advised affected organizations to disable the identified applications, preserve them rather than delete them during containment, and review credentials across their applications. Its investigation guidance includes checking for unauthorized additions dating back to October 13.

ConnectWise’s October 20 update said it had completed an account and credential reset in the affected environment and was preparing for phased restoration. Cloud Backup, SaaS Security, and Cloud Management remained suspended. The company instructed customers to keep affected connections disabled until formal re-enablement instructions were issued and to continue investigating individual tenants. A vendor reset does not establish that a customer’s tenant is clean.

For administrators investigating exposure, service principal sign-in logs deserve specific attention. Looking only at user sign-ins is insufficient. Review application authentication alongside audit events for new credentials, consent grants, applications, and directory role assignments. Where available, Microsoft Graph activity logs can help determine what happened after tokens were issued.

Application access needs an owner and a reason

The broader problem is familiar. Someone approves an integration because a project needs it. The project ends, the vendor changes, or the subscription expires. Nobody circles back to remove access.

Sophos observed this incident’s sweep reaching tenants without active backup subscriptions. Previously granted consent still mattered. Canceling a service and removing its access are separate tasks.

Start with Enterprise applications in the Entra admin center. For each application, review Permissions, including both Admin consent and User consent. Microsoft provides portal, Graph, and PowerShell methods for reviewing and revoking grants, although some user consent changes require Graph or PowerShell.

For every integration, I would want clear answers to five questions:

• Who owns this application internally?

• What business function still requires it?

• What data and administrative functions can it access?

• Why does it need each permission?

• Who will remove its access when we stop using it?

Pay particular attention to whether access is delegated or application-based. Delegated permissions allow an application to act on behalf of a user. Application permissions allow it to operate without a signed-in user. Microsoft specifically recommends understanding that difference before approving consent and questioning permissions that do not fit the application’s purpose.

A backup product may legitimately need broad data access. That should lead to closer scrutiny of its permissions, credential handling, and monitoring.

A quarterly review cannot catch everything

I would use quarterly reviews to confirm ownership and business need, with more frequent reviews for highly privileged integrations. But a calendar reminder cannot substitute for monitoring changes as they happen.

Establish an approved baseline and alert on changes that could expand access:

• New application credentials or certificates.

• New consent grants or API permissions.

• Directory roles assigned to service principals.

• Changes to application ownership.

• Application sign-ins that depart from expected behavior.

These alerts need someone responsible for investigating them. Ask your SOC or managed service provider directly whether application identities are included in its monitoring, which events it collects, and how long the underlying logs remain available.

Also make application removal part of vendor offboarding. Record the affected application IDs, confirm dependencies, revoke access, and verify completion. Treat the cancellation email as the start of that process.

We already expect administrators to justify privileged access. Applications deserve the same scrutiny. If an integration can read company data or change the tenant, someone should be able to explain why it still needs that access and show that its activity is being watched.