ConnectWise's Microsoft 365 incident is a reminder that a trusted backup integration is also a privileged identity. Turning off a compromised vendor connection is an important containment step, but it cannot undo permissions or credentials an intruder already added elsewhere in a customer tenant.
Source reporting: The Hacker News: ConnectWise suspends Cloud Backup after Microsoft 365 tenant compromises. This analysis also draws on ConnectWise's incident advisory and Huntress's technical investigation. Status reflects the advisories available on October 18, 2026; the investigation remains ongoing.
What the latest vendor update establishes
In its October 18, 01:00 UTC update, ConnectWise said it had disabled seven application identities at 07:00 UTC on October 17 and revoked certificates used for affected Cloud Backup connections. The service, formerly SkyKick, remains suspended. Scheduled backups are not running, and access to affected archives and restoration capabilities is unavailable. SaaS Security and Cloud Management were also taken offline as a precaution.
ConnectWise says existing backup archives remain encrypted, isolated, and preserved, with no evidence of archive access. That statement is not a clean bill of health for customers' live Microsoft 365 environments: the company says it does not have the downstream visibility to determine each tenant's exposure. Its latest update provides no restoration time.
Why revocation is only the first boundary
Huntress reports that attackers used a ConnectWise application identity to obtain access in customer environments. In one investigated tenant, the Cloud Management application for Microsoft Teams elevated itself to Global Administrator and added credentials to two other applications, including a tenant-specific Huntress application. Those are observations from a particular tenant, not evidence that the same sequence occurred everywhere.
The practical distinction is between closing the original entrance and removing access created after entry. A credential planted on a different trusted application can provide an independent return path. Previously issued tokens may also remain usable until expiry or invalidation. Changing a human administrator's password alone does not address application-only access.
A prioritized response for MSPs and customers
- Verify exposure by application ID. Inventory ConnectWise and legacy SkyKick connections in the MSP tenant and every managed customer tenant, including dormant integrations. Use the seven client IDs in the vendor advisory rather than relying on display names. Confirm affected connections are disabled locally and keep them disabled pending formal restoration instructions. Preserve their configuration instead of deleting applications as the first response.
- Preserve evidence while containing urgent threats. Export available Entra audit records, service-principal and user sign-ins, and Microsoft 365 audit data. Review October 13 through the present; extend to October 1 where retained evidence permits. Record actual coverage and gaps. Do not postpone urgent containment while waiting for a complete export.
- Follow changes into other identities. Review application and service-principal credentials, certificates, federation trusts, owners, consent grants, and privileged role assignments. Correlate changes with approved administration. Have authorized responders preserve and remove confirmed unauthorized entries, including those on unrelated management or security integrations.
- Investigate workload-level effects. Check mailbox forwarding, hidden inbox rules, transport rules, and delegated access. Correlate available SharePoint, OneDrive, and Teams activity with suspicious authentication and directory changes. Review policy changes that could weaken controls.
- Document recovery readiness separately. Confirm the last successful backup, assess the data-protection gap, and establish an approved contingency with the service owner. After vendor-authorized restoration, validate both connectivity and completed backup jobs. Do not treat a successful reconnection as proof that tenant persistence has been removed.
Use indicators to investigate, not to declare a breach
The published suspicious address is 144.172.64[.]128. Search for matching activity, but do not stop there: Huntress describes relevant application changes associated with private Azure address space as well. A familiar cloud address or common scripting user agent is not proof of legitimacy or compromise.
Keep attempted authentication, successful authentication, unauthorized configuration changes, and confirmed data access as separate findings. A successful sign-in is not automatically evidence of exfiltration. Conversely, a quiet audit trail cannot exclude reads that were never logged. The vendor advisory also cautions that workload-identity Conditional Access does not cover third-party multitenant SaaS applications in the same way it covers supported locally registered service principals; it is not a substitute for disabling affected connections.
Bulwark Black assessment
For SMBs and government contractors, this is both an identity-response problem and a continuity problem. Assign an accountable response owner, obtain tenant-specific evidence from your MSP, and track two independent outcomes: unauthorized access removed and dependable backup protection restored. Neither should be inferred from the other. Preserve the investigation record and assess applicable contractual reporting obligations against verified findings rather than treating vendor containment as the end of your response.