Skip to content

Cybercrime

Attackers used stolen ConnectWise credentials to breach 173 Microsoft 365 tenants without passwords

The breach exploited app-only identities, bypassing multifactor authentication and conditional access, and attackers planted long-lived credentials for future access.

https://breach-signal.com/cybercrime/connectwise-credential-breach-173-m365-tenants/

Share

This is a new development in a story we reported earlier: ConnectWise suspends Cloud Backup after Microsoft 365 tenant compromise. Earlier in this story: Hackers used compromised ConnectWise credential to sign in to 173 Microsoft 365 tenants.

Key facts

  • Attackers used a stolen ConnectWise Cloud Backup credential to authenticate across at least 173 Microsoft 365 tenants on October 15, 2026.
  • The stolen credential was a client assertion, an API secret that lives entirely in ConnectWise's own tenant and proves the application's identity to Microsoft Entra without involving a user.
  • The attackers did not need to steal customer passwords, phish users, or exploit any software vulnerability to gain access to Microsoft 365 tenants.
  • ConnectWise discovered the incident on October 14, 2026 through internal monitoring and disabled the seven compromised application identities on October 17, 2026.

Attackers exploited a stolen ConnectWise Cloud Backup credential to gain access to at least 173 Microsoft 365 tenants on October 15, 2026, without needing customer passwords or phishing. Huntress telemetry showed the number of confirmed compromised tenants rose from 162 to 173 between October 17 and 18, though ConnectWise notes the total impact may be broader.

The stolen credential was a client assertion—a vendor-side API secret that authenticates ConnectWise’s applications directly with Microsoft Entra ID. Because it lived entirely in ConnectWise’s tenant, customer-side defenses like multifactor authentication and conditional access could not block it. The attack relied solely on a legitimate, pre-existing credential, used the same way the backup service does, with the only difference being the attacker’s source IP address.

The main wave of automated sign-ins occurred between 06:13 and 08:34 UTC on October 15, with the attacker systematically moving through tenants in sorted GUID order, a few seconds apart. The requests came from IP address 144.172.64.128, linked to hosting provider RouterHosting (AS14956), and targeted Microsoft Graph for access tokens as the ConnectWise Cloud Backup application.

Key figures, Scale of the ConnectWise Microsoft 365 breach. Compromised tenants: 173; Entra tenants with activity: 1,000; Successful sign-ins: 300; Targeted manual attacks: 16; Disabled application identities: 7.

Before the October 15 attack, the same IP address attempted password spraying against four law firm tenants on October 13 and 14, testing techniques before the broader campaign. On October 15, a second wave of manual attacks targeted 16 tenants in policy, national security, trade, and critical minerals sectors—but all 16 attempts failed.

In at least one Huntress partner tenant, the ConnectWise Cloud Management – MS Teams application escalated privileges to the Global Administrator role and planted new client secrets on two other trusted applications. These secrets were set to expire in 2028, creating a backdoor for future access even after the original credential was revoked.

In every tenant with ConnectWise applications installed, the attackers could have accessed mailboxes, SharePoint documents, Teams messages, OneDrive files, and directory data. ConnectWise’s applications held broad permissions to manage services and run backups, giving attackers potential access to Exchange mailboxes, SharePoint files, Teams chat history, and directory listings—all without triggering user-based security controls.

Affected organizations include managed service providers, law firms, national security and trade entities, critical infrastructure sectors, and technology firms. The attack pattern mirrors historical supply chain incidents like SolarWinds and Kaseya, where compromising a vendor credential granted broad access to downstream customers.

ConnectWise suspended Cloud Backup service by revoking certificates used for affected application connections across all users on October 17, 2026, making the shared credentials previously used for Cloud Backup no longer valid.

ConnectWise confirmed its Cloud Backup archives remain encrypted and isolated, with no evidence of attacker access. The service suspension halts scheduled backups, creating operational risks for dependent organizations. The company has engaged a third-party incident response firm to assist with its investigation and containment efforts.

Cyber Security News reports that impacted organizations should disable, but not delete, the ConnectWise Cloud Backup and Cloud Management – MS Teams service principals, and remove any unapproved directory roles or unknown app credentials. Organizations must also review application credentials, directory role assignments, consent grants, and audit logs for signs of unauthorized activity. Huntress recommends checking for sign-ins from IP address 144.172.64.128 starting October 13, as well as reviewing Entra audit logs for suspicious ConnectWise or SkyKick activity.

The ConnectWise incident is the tenth trust-through-defaults breach since September 26, 2026, and the first to shift the risk from the identity stack into the supply chain itself. Unlike previous incidents—which involved technical flaws in identity frameworks, libraries, or plugins—this attack exploited a compromised vendor credential, bypassing customer-side security entirely. No software vulnerability or CVE was assigned.

Managed service provider applications provide broad, cross-tenant access, meaning a compromised vendor credential can affect every tenant that trusts the application. Customer-side security controls—like multifactor authentication and conditional access—are irrelevant when the attack originates from a trusted application identity rather than a user account.

ConnectWise stated it has no indication that other products or services beyond the seven disabled application identities are impacted. However, full remediation requires the vendor to rotate the underlying credential—a step only ConnectWise can take. Customers cannot fix this issue alone, and previously issued access tokens may persist until they expire or are invalidated.

Was this helpful?

Join the discussion

Please read our Comment Policy before commenting. First-time comments are held for moderation. By posting a comment you agree to our Terms of Use and Privacy Policy, which explain how your name, email address and comment are used.

Your email address will not be published. Required fields are marked *