ConnectWise Cloud Backup Security Incident: How to Check Microsoft 365

Disabling ConnectWise Cloud Backup did not automatically make every connected Microsoft 365 tenant safe. After unauthorized access to application identities used by the backup service, ConnectWise suspended the service, while security firm Huntress reported suspicious sign-ins across at least 162 customer tenants as of October 16, 2026. The incident matters because attackers appear to have authenticated as trusted software rather than breaking into each organization through a conventional user account. Administrators need to investigate what those application identities did, not simply wait for the vendor to restore backups.

The October incident reached beyond the backup service itself

ConnectWise disclosed unauthorized access involving application identities associated with Cloud Backup, formerly known as SkyKick, on October 16. The company said it identified the issue on October 14 and began incident response measures. By October 17, it had suspended the service and revoked certificates used for affected application connections. Its October 18 advisory confirmed that the investigation was continuing and that no restoration time was available.

The disruption affects more than a dashboard or a scheduled task. Cloud Backup connects to customer Microsoft 365 environments so it can protect business email and files, and that connection requires permissions within each customer's tenant. An attacker who can misuse the application's credentials may be able to exercise some of those permissions directly against live services. The backup archives and the Microsoft 365 accounts being backed up are separate security boundaries, so evidence about one cannot settle the status of the other.

ConnectWise says its existing backup archives remain encrypted, isolated and preserved, and that it has no evidence those archives were accessed. That is a meaningful distinction, but it is not a declaration that every connected Microsoft 365 tenant remained untouched. The vendor also says it cannot independently see all activity inside downstream customer environments. Each organization therefore needs to check its own identity and audit records.

Why a trusted application can bypass familiar login protections

Microsoft Entra ID, the identity service used to manage access to Microsoft 365, supports both human users and applications. An application can be represented in a customer tenant by a service principal, which is the local identity through which that software receives permissions and accesses resources. When an organization authorizes a backup application to read mailboxes or files, it grants the software access so that it can perform its job without asking an employee to sign in for every operation.

That arrangement is useful for automation, but it creates a different risk from a stolen employee password. Huntress reported that the suspicious activity involved the vendor application's own authentication credentials, with sign-ins observed from the internet address 144.172.64.128 on October 15. Because the application was authenticating as software, the usual multi-factor authentication prompt for a person was not necessarily part of that authentication path. Multi-factor authentication remains essential for human accounts, but it cannot by itself neutralize a compromised application credential.

Application permissions also explain why a single compromised integration can have consequences across multiple organizations. Managed service providers (MSPs) use centralized tools to administer technology for many customers, and a vendor application may have been authorized in numerous separate Microsoft 365 tenants. If an attacker obtains the credential that proves the application's identity, the attacker can attempt to use the permissions already granted in those tenants. This is the supply-chain risk: the access path trusted by customers becomes the path an intruder tries to abuse.

The reported tenant count is evidence of access, not a final damage total

Huntress said it had confirmed unauthorized sign-ins in 162 tenants by 19:00 UTC on October 16. That figure describes what the company had established in the environments it monitors at that time; it should not be treated as a final worldwide victim count. Other reporting has cited different totals, which can reflect different observation times and sources. The number of tenants involved may change as more organizations review their logs and investigators establish the scope.

Researchers also reported different outcomes across the environments they examined. Todyl's analysis of nine tenants found suspicious sign-in activity but did not identify evidence that the attacker used the backup application to create accounts, add permissions, change passwords or establish persistence in those particular tenants. Huntress, meanwhile, observed more concerning activity in other environments, including application identities assigning themselves directory roles. Microsoft also observed attempts to add credentials after successful application authentication.

These findings are not contradictory: a successful sign-in does not guarantee that an attacker performed every action the permissions would have allowed. Equally, a lack of obvious account changes does not prove that no information was read. Investigators must distinguish attempted authentication, successful authentication, permission changes, resource access and confirmed data theft. As of the latest vendor advisory on October 18, the full scope remained under investigation.

Start the investigation in service-principal sign-in logs

Administrators should examine both their own Microsoft 365 tenant and every customer tenant managed by their organization. Begin in the Microsoft Entra admin center and open Monitoring and health, then Sign-in logs. Select the Service principal sign-ins tab rather than relying only on the standard user sign-in view, because the activity at issue involved an application identity.

Search for the ConnectWise Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae and review activity from October 13, 2026, onward. ConnectWise has also published six related Cloud Management application identities for investigation, so teams should use the complete list in its current advisory rather than checking the backup identity alone. Older deployments may display SkyKick names, making the application ID a more reliable identifier than the visible label.

Inspect the source address, timestamp, authentication result, resource accessed and any available correlation details for each relevant event. The address 144.172.64.128 is a published indicator associated with the incident, but a matching event is a reason to investigate, not proof by itself that data was stolen. Also look for unfamiliar source addresses and unusual activity outside the application's expected Azure-based traffic patterns. Preserve the original records and record the time zone used so events from different systems can be compared accurately.

Check whether the application changed other identities or permissions

Sign-in records show how an identity authenticated; audit logs help explain what happened afterward. In Microsoft Entra, review directory audit events from October 13 onward for application credential additions, new application owners, permission grants, consent changes and role assignments. Pay particular attention to changes initiated by a ConnectWise or SkyKick identity, but follow any related activity into other applications or accounts. A suspicious application may attempt to create an alternative route that survives after the original connection is disabled.

Next, examine the credentials and trust settings of applications that were changed during the investigation period. Look for unexpected client secrets, certificates or federated credentials, and compare their identifiers and creation events against approved configuration records. Review privileged directory roles, new or modified enterprise applications, and changes to conditional access policies. An attacker who adds a credential to another identity may leave a path that is independent of the original backup application.

Exchange Online and other Microsoft 365 services need their own checks as well. Investigate unexpected mailbox forwarding, inbox rules, transport rules and delegated mailbox access. Review available Microsoft 365 audit events for unusual reads or changes involving mail, OneDrive, SharePoint and Teams. These checks help establish whether the activity remained at the authentication stage or progressed into data access, persistence or changes to business services.

Disable the affected connection without destroying the evidence

ConnectWise says it disabled seven related application identities on October 17 and revoked certificates associated with affected connections. Those vendor-side measures do not guarantee that every local enterprise-application setting has been verified, or that any additional access established inside a customer's tenant has been removed. Administrators should confirm the status of each listed application in their own tenant and keep affected connections disabled until the vendor provides confirmed restoration and reauthorization instructions.

Preserve sign-in and audit records before they expire, and export the available evidence to an approved security repository. Microsoft Entra log retention varies by license and log type; ConnectWise specifically warns that default sign-in and audit retention can be as short as seven days for Free tenants, compared with 30 days for P1 and P2 tenants. Do not delay urgent containment while collecting evidence, but do capture what is available as early as possible. If an investigation confirms unauthorized credential changes or other persistence, remove or rotate those items through a coordinated response and verify that the attacker no longer has a working route back in.

Disabling an application prevents new authentication through that connection, but previously issued access tokens may remain usable until they expire or are otherwise invalidated. Separate credentials or permissions created during the intrusion also require separate remediation. For that reason, turning off the integration is containment, not a complete incident response. Organizations with suspicious successful sign-ins, unexpected role assignments or evidence of data access should involve their incident-response team or managed security provider and follow Microsoft's current procedures for investigating compromised applications.

Keep backup availability separate from the security decision

During the interruption, ConnectWise says scheduled Cloud Backup jobs are not running and access to affected archives and restoration capabilities is unavailable. That creates an operational gap even though the vendor reports no evidence that stored archives were accessed. Organizations should identify which Microsoft 365 workloads are no longer being protected, record the last successful backup time and determine what other independently managed recovery options are available. Do not assume that a backup is current simply because its historical archive still exists.

At the same time, do not reconnect the affected integration solely to resume scheduled jobs. Reauthorization should follow a confirmed vendor recovery process and a local review of application permissions, credentials and audit findings. Once service returns, verify the integration's identity and granted permissions, confirm that backup jobs complete successfully, and test restoration through an approved procedure. A restored schedule is evidence that the service works again; it is not evidence that every security concern has been resolved.

Use the incident to reduce permanent application access

After the immediate investigation, review every third-party application with access to mail, files, collaboration tools or directory administration. Remove integrations that are no longer used, reduce permissions that exceed the software's current job and assign an accountable owner to each remaining application identity. Keep an inventory of client IDs, granted permissions, owners and expected authentication patterns so future investigations have a baseline for comparison. For MSPs, repeat that review across every managed tenant rather than assuming a central vendor action has changed every customer's local configuration.

Monitoring should cover application sign-ins as well as employee logins, with alerts for unexpected source addresses, new application credentials, privilege changes and unusual access to business data. Organizations should also establish a process for quickly revoking a vendor connection and validating alternative recovery arrangements when a supplier has an incident. The immediate task is to check the tenant records and preserve evidence while they remain available; the next is to make sure a trusted integration cannot retain broader access than the business needs.