What happened
ConnectWise says it discovered the issue on October 14, 2026 and began internal and external incident response.
Huntress observed the main application-identity activity on October 15, 2026, including targeted sweeps between 09:25:04 and 14:20:24 UTC.
Huntress identified almost 1,000 Entra tenants with sign-in activity from 144.172.64[.]128 and more than 300 successful sign-ins; success did not always mean tenant access because some tenants lacked the service principal.
Huntress reported a second wave against 16 protected tenants in policy, national security, trade and critical-mineral sectors, most without ConnectWise products. The target set matters because it indicates discovery or targeting activity beyond tenants that normally use the affected applications, although Huntress said those attempts generally failed where the relevant service principal was absent and did not independently verify external reports of hands-on activity outside its fleet.On October 16, 2026, Huntress removed an unauthorised credential that had been added to its application in one customer tenant. Huntress said the credential had been used for seven rapid sign-ins and that access used to add credentials to two applications came from private Azure IPv6 space rather than the published 144.172.64[.]128 address, making indicator-only review insufficient.At 07:00 UTC on October 17, 2026, ConnectWise disabled seven application identities and revoked affected certificates. That supplier-side action does not prove that each customer tenant disabled its local enterprise application, removed unauthorised credentials or preserved the relevant object identifiers. Tenant administrators still need to verify local state, application permissions, role assignments, credentials, mailbox changes and other persistence paths.ConnectWise identified seven application client IDs requiring tenant verification: 506e08f9-6e9a-4da4-942b-a099a03644ae, 2399d300-6fca-4e6a-a686-399fefe75b83, 24205314-2b89-4e07-a2a4-579e898a5640, b78f6a77-d4e5-46fb-87e5-d1648bd02519, 0de14c77-b9b0-4137-9360-34878a929827, 412dcf96-176d-4b3a-a1b0-4981ad66971e and b2b55f5b-7758-4719-8d8f-88ae172e6bdb.ConnectWise currently lists 144.172.64[.]99, 144.172.64[.]60 and 144.172.64[.]128, plus Python-urllib/3.12 and python-requests/2.31, as investigation indicators that require context.At 21:28 EDT on October 18, 2026, ConnectWise reported that Cloud Backup, SaaS Security and Cloud Management remained suspended, with backups, archives and restores unavailable. SaaS Security monitoring and alerting and Cloud Management user and licence administration were also unavailable, creating a control and recovery gap while customers investigate the identity event.ConnectWise says it has no indication that partner backup data was accessed and has not confirmed downstream customer compromise. It also states that absence of confirmed compromise is not assurance that unauthorised activity did not occur in customer environments, which ConnectWise cannot directly observe.Attribution posture: ConnectWise has not named a threat actor, and responsibility remains unresolved.
Why this matters now
The weekend moved this beyond a vendor advisory. The same supplier identity layer that granted backup access also created a route into downstream Microsoft 365 tenants, while containment removed backup, restore, SaaS monitoring and licence-management functions. Identity, incident response, continuity and supplier-management teams therefore need one decision room. Waiting for ConnectWise to finish attribution or restoration leaves both compromise risk and recovery exposure unmanaged.
User MFA does not resolve an application-identity compromise because the service principal authenticates as the application and inherits consented permissions. Successful sign-ins, cross-application credential additions and role changes therefore require tenant evidence, not reassurance that user accounts were protected. MSP operating models are particularly exposed because application trust can cross many customer environments while evidence ownership, administrative authority and log retention remain fragmented.
The added IP addresses and Huntress’s weekend expansion of observed activity widen the investigative set, but they are not proof of compromise on their own. Leadership must move quickly without treating every match as a confirmed incident, while avoiding the opposite error of accepting a clean vendor status update as tenant-level clearance. Each tenant needs a documented evidence trail and an explicit continuity disposition.
The decision for security leaders
Assign one accountable incident owner across cloud identity, the MSP channel, legal, supplier risk and continuity. Require a tenant-by-tenant matrix that distinguishes application presence, successful authentication, authorised administrative activity, suspicious changes and unresolved log gaps. A fleet-level or vendor-level assurance cannot close individual customer environments because ConnectWise cannot directly observe downstream tenants.
Make the recovery decision separately from the containment decision. Disabling the affected identities may be necessary, but Cloud Backup archives, restores and scheduled jobs remain unavailable. Business-service owners should identify priority Microsoft 365 workloads, compare the age of the last recoverable copy with approved recovery-point objectives, and approve an alternate recovery path or a time-bound risk exception.
Demand scoped supplier assurance before reconnection. ConnectWise should identify which identities, if any, show evidence of unauthorised access, how credentials were exposed, which permissions are being reduced, whether customers must reauthorise applications, what evidence supports safe restoration and what monitoring remains unavailable. Re-enablement should require local validation of permissions, credentials and backup scheduling rather than automatic acceptance of a vendor service-restoration notice.
Evidence of closure
- A retained Entra export covering service-principal sign-ins, audit changes and Graph activity across the review window.
- A tenant-by-tenant disposition of all seven application IDs, including local object IDs and authorised owners.
- Validated restore evidence from an independent recovery path for priority Microsoft 365 workloads.
- An incident record resolving every successful indicator match and every added credential.
The Security.io assessment
The evidence supports a high-confidence conclusion that vendor-held application identities were abused and that ConnectWise services remain unavailable, but it does not establish that every successful sign-in resulted in data access. Huntress also states that external hands-on-activity reports were not independently verified. Security.io therefore treats indicator matches as investigation triggers, not automatic breach determinations.
The central risk is persistence outside the originally abused identity. Huntress observed a credential added to its own application and another application in one tenant, while the associated access came from infrastructure other than the principal published IP address. A review limited to ConnectWise sign-ins can therefore miss credentials, permissions, roles or mailbox changes created through the initial access path.
The cited sources did not publish malware hashes, filenames or attacker-controlled domains for this incident. Investigations must prioritise service-principal behaviour, credential additions, directory-role changes, consent grants, Graph activity and mailbox or SharePoint access rather than wait for endpoint-style indicators.
Attribution posture: ConnectWise has not named a threat actor, and responsibility remains unresolved.
Questions for the morning meeting
- Which tenants granted these applications access to regulated, privileged or board-sensitive data?
- Can critical Microsoft 365 workloads be restored without the suspended ConnectWise service?
- Who can authorise application disablement across MSP-managed and customer-managed tenants today?