At a Glance

Risk: Very high for any organization with this application present and enabled in a Microsoft 365 tenant.

Who is affected: Any Microsoft 365 tenant where ConnectWise Cloud Backup (formerly SkyKick Backup) was ever deployed, including tenants that stopped using it years ago.

What to do now: Disable the service principal with Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae in every tenant you manage, then investigate what it accessed.

What Blumira is doing: Notifying customers where this application is present in a connected Microsoft 365 tenant.

What happened

On October 16, 2026, at 1:47 p.m. ET (17:47 UTC), ConnectWise published an advisory saying it is investigating attempts at unauthorized access associated with the ConnectWise Cloud Backup environment. ConnectWise Cloud Backup is the product formerly sold as SkyKick Cloud Backup, which ConnectWise acquired in September 2024.

MSPs posting in the r/msp community reported that the Cloud Backup application was being used to connect to customer Microsoft 365 tenants and remove data. One MSP’s investigation described rapid connections to client tenants and exfiltration of client email, Teams and SharePoint data. A third-party security vendor has publicly said it confirmed compromise across its own customer base, published the Application ID, and recommended disabling the application.

Are you affected?

You need to act if you manage Microsoft 365 tenants and any of these were ever deployed in one of them: SkyKick Cloud Backup, SkyKick Cloud Manager, SkyKick Partner Portal or ConnectWise Cloud Backup.

If you are not sure, search using the methods mentioned below. Tenants inherited through an acquisition or onboarded from another provider often carry applications that nobody currently working there deployed. You can stop here only if a search for Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae across all your tenants returns no results.

What to do now

Disabling the application is reversible and takes about two minutes per tenant. It stops the application from getting new access and keeps the object in place as evidence.

Disable the application in one tenant

Repeat these steps in each customer tenant. If you manage many tenants, use the CIPP method below instead.

1. Sign in to the customer tenant at https://entra.microsoft.com/ as a Global Administrator, Cloud Application Administrator or Application Administrator.
2. Go to Identity > Applications > Enterprise applications.
3. Set the Application type filter to All applications. The default filter hides this application.
4. Search for 506e08f9-6e9a-4da4-942b-a099a03644ae. Search by Application ID, not by name.
5. Open the application and confirm that the Application ID matches and the publisher is ConnectWise S-K LLC (verified publisher: ConnectWise LLC).
6. Go to Manage > Properties.
7. Set Enabled for users to sign-in? to No, then select Save. Microsoft’s guide to disabling sign-in for an application explains that this stops all new tokens for the application.

Disable the application across all tenants with CIPP

1. Set the tenant selector at the top of CIPP to All Tenants.
2. Go to Tenant Administration > Administration > Applications.
3. Paste 506e08f9-6e9a-4da4-942b-a099a03644ae into the table search. It matches the App ID column.
4. Check the Account Enabled column. Rows showing false are already disabled.
5. Select every matching row where Account Enabled is true.
6. From the bulk actions menu, choose Disable Service Principal and confirm.
7. Refresh with the table’s own refresh button, not the browser’s, because CIPP caches results. Directory changes can take one to two minutes to appear.

This requires the Tenant.Application.ReadWrite permission in CIPP, and the action only appears for applications that are currently enabled. If the action fails in a tenant, CIPP’s permissions there usually lack application write access.

Remove its permissions for a harder stop

App-only access tokens issued before you disabled the application stay valid until they expire. Microsoft sets a default lifetime of 60 to 90 minutes, and tokens cannot be revoked one by one. Treat the first 90 minutes after disabling as still active.

To cut access sooner, also remove the application’s admin-consented permissions from the application’s Permissions page. Screenshot or export the permission list first, because it is evidence.

If you no longer use the product, delete the enterprise application, but only after you have exported the evidence described below.

A firewall block will not stop this

The application reads data directly from Microsoft’s cloud, so blocking the reported IP at your firewall has no effect on it. Conditional Access for workload identities does not cover multi-tenant third-party applications like this one either.

What ConnectWise has said

The advisory says that containment measures are in place and that there is no indication partner backup data has been accessed. It lists the source IP and two user agents and recommends no partner actions. It does not mention an enterprise application, an Application ID or Microsoft 365, and it had not been updated as of this writing.

Separately, a comment in the r/msp thread by a claimed ConnectWise representative, said that ConnectWise has not independently confirmed downstream impact to partners or received direct partner reports of suspicious activity. It is not clear whether the commenter works for ConnectWise or was relaying a statement they received. ConnectWise asks partners, security vendors and researchers to send findings to SecurityIncident@ConnectWise.com.

Both accounts can be accurate. The advisory describes ConnectWise’s own environment, and the reported attack path never touches that environment. Data would be read directly from Microsoft using the application’s identity inside each customer tenant. If you find activity tied to this application, report it to ConnectWise directly, as well as discussing it publicly, so the vendor can establish the scope.

Why this is severe

A cloud backup product for Microsoft 365 does not sign in with a password. It holds a consented application identity inside every tenant it protects, with standing permission to read mail, Teams messages, files and sites. An attacker who controls that identity needs no user credentials, no MFA and no interactive sign-in.

The same properties make the activity hard to notice:

• Consent does not expire with a session. It lasts until an administrator removes it.
• The application authenticates as itself (as a service principal), so its activity appears under service principal sign-ins, not in the interactive sign-in logs most teams review.
• Conditional Access policies written for users do not apply to app-only tokens.

This is the same structural problem behind this year’s RMM compromises, with a different mechanism. An RMM compromise gives an attacker SYSTEM access on managed endpoints; this one gives an attacker a consented token in managed tenants.

Indicators of compromise

The Application ID is the reliable indicator. It is identical in every tenant, while the display name changed when the product was renamed.

Investigate what the application accessed

Sign-in logs show that the application authenticated, when and from where. Only audit logs show what it did, so check both.

Investigate in Blumira

Option 1: With Hearth (NEW!)

Hearth searches your entire connected stack from one place. You ask a question in plain language, and Hearth looks across every Microsoft 365 tenant, endpoint, RMM, backup platform, firewall, and PSA you have connected, then returns a written investigation you can save, share, or hand to a customer.

For this incident, here are three questions worth asking:

1. Where is this application consented, and is it enabled?
2. What did it access?
3. Has 144.172.64[.]128 appeared anywhere in our environment?

Hearth answers across every connected tenant at once. It also lists every other third-party application holding standing access, which is how you find the ones nobody remembers installing.

Option 2: In Blumira Report Builder

If your Microsoft 365 and Entra logs are flowing into Blumira, Report Builder answers the same questions from retained data. This matters once Microsoft retention expires, and it covers every tenant you send to Blumira.

• Load saved report “SkyKick / ConnectWise's Cloud Backup compromise”

Log type: azure_signin

Filter: subtype = ServicePrincipalSignInLogs, app = CW Cloud Backup Service Provider

Search client_ip, not device_address. In azure_signin records device_address holds the collector name, not the source address.

• Load saved report “SkyKick / ConnectWise's Cloud Backup compromise - App ID”

Log type: azure_signin

Filter: subtype = ServicePrincipalSignInLogs, app_id_str = 506e08f9-6e9a-4da4-942b-a099a03644ae

Search client_ip, not device_address. In azure_signin records device_address holds the collector name, not the source address.

• Load saved report “Microsoft 365 - Application Consents Granted Previous 30 Days”

Log type: office365_aad

Filter: operation contains Consent to application

Fields: Timestamp, user, app_id_str, targets.id, result, tenant_id

• Load saved report “Microsoft 365 - Principal Service Updates”

Log type: azure_directory_audit

Filter: operation_name in Add service principal, Update service principal, Add app role assignment to service principal, Add member to role, Add member to role in PIM completed (permanent)

Fields: Timestamp, initiator, object, object_name, object_type, agent, status

This is the search that surfaces the privilege escalation described earlier. The initiator field shows what performed the change, which is how you tell a service principal granting itself a role from an administrator doing it.

• Load saved report “Microsoft 365 - Sharepoint Actions”, add a filter for the application ID or source IP

Log type: office365_sharepoint

Filter: operation in FileDownloaded, FileSyncDownloadedFull, FileAccessed, FileCopied, AnonymousLinkUsed; and app_id_str = the Application ID, or client_ip = the source IP

Fields: Timestamp, user, app, file_name, file_path, url, site, object

• Load saved report “Microsoft 365 - Exchange: Mail Items Accessed - Other Than Owner”

Log type: office365_exchange

Filter: operation = MailItemsAccessed. Also check New-InboxRule and Add-MailboxPermission for persistence left behind.

Fields: Timestamp, user, user_principal_name, client_ip, object, operation, result

MailItemsAccessed depends on the tenant audit configuration. If it returns nothing, confirm it is being generated before concluding that mail was not touched.

Investigate in the Microsoft portals

Pull Entra data first. Entra keeps sign-in and directory audit logs for 7 days on Entra ID Free, which includes Business Basic and Business Standard, and for 30 days with Entra ID P1 or P2. The Microsoft 365 unified audit log, where file and mail access is recorded, keeps 180 days on Audit (Standard). If Microsoft Graph activity logs were turned on before the incident (Entra ID P1 or P2), they record every Graph request the application made, which is the most direct record of what it read.

1. In Entra, open Sign-in logs and select the Service principal sign-ins tab. Filter for the Application ID and for 144.172.64[.]128.
2. In the Entra audit logs, look for consent grants, role assignments and changes to the service principal.
3. Search the Microsoft 365 unified audit log for activity tied to the Application ID or the source IP: mailbox access (MailItemsAccessed), SharePoint and OneDrive file downloads, Teams data access, and new inbox rules or mailbox permissions.
4. Review every other OAuth consent grant and service principal in the tenant, especially anything consented in the last 30 days. Microsoft’s app consent incident response playbook walks through the review.

Clean up other SkyKick applications

One MSP on r/msp published the full set of SkyKick service principals it removed from its tenant. Only the first is tied to the reported compromise; the rest are a dormant-application cleanup list and have not been reported as malicious.

An unconfirmed, possibly related report

On October 15, 2026, at 02:04 UTC, about 40 hours before the ConnectWise advisory, an MSP on r/msp that had not used SkyKick in several years received a Microsoft Privileged Identity Management (PIM) notification. The dormant service principal SkyKick Cloud Manager - Exchange Online had assigned itself the Exchange Administrator role, outside PIM, with itself listed as the assigner. This has not been confirmed as related to the Cloud Backup activity, and it involves a different application. To check your own tenants, search the directory audit log for role assignments and look at who initiated each one. That shows whether a service principal assigned itself a role.

Offboarding a SaaS vendor and cancelling its invoice are two different actions. Most organizations only do the second.

How Blumira can help

Blumira continues to monitor this issue and is notifying customers where this application is present in a connected Microsoft 365 tenant.

Hearth’s overnight change digest reports new, removed and changed posture across connected tenants each day, and stays silent when nothing changes. A new application consent or a new privileged role assignment would appear in it.

Hearth’s response actions, including revoke OAuth grant, revoke sessions, disable user and reset MFA methods, sit behind a propose-confirm gate. Hearth proposes the action, an administrator confirms it, and both steps are written to the audit log. Actions never run automatically.