Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App

An unauthorized actor exploited a compromised client secret for the ConnectWise Cloud Backup application to gain access to various Microsoft 365 tenants. By using the OAuth 2.0 client credentials flow, the attacker bypassed user-level security controls like MFA and conditional access, inheriting broad administrative permissions already granted to the backup app. This provided the technical ability to read and write sensitive data across mailboxes, SharePoint, and Teams.
The attack followed a highly automated pattern, crawling tenants in ascending GUID order. While successful sign-ins were confirmed, the extent of data exfiltration remains uncertain. In tenants without active backup subscriptions, no subsequent data reads were detected. In tenants with active subscriptions, read activity occurred, but existing logs cannot distinguish between legitimate backup operations and malicious actor activity. Remediation requires disabling the application in Entra ID until ConnectWise confirms a rotation of the compromised credentials.

An unauthorized party used the ConnectWise Cloud Backup application (App ID 506e08f9-6e9a-4da4-942b-a099a03644ae) to authenticate to Microsoft 365 tenants.
Sign-ins occurred on October 15, 2026, between 07:11 and 08:47 UTC.
The actor used a valid client secret via the OAuth 2.0 client credentials flow.
The activity originated from a single IPv4 address: 144.172.64.128.
The actor used a Python-urllib/3.12 user agent.
Authentications occurred in strictly ascending tenant-GUID order.
The application had previously granted read/write access to mail, attachments, OneDrive, SharePoint files, and Teams chats.
No directory changes, new secrets, or new role assignments were created by the actor.
ConnectWise published an advisory on October 16 acknowledging unauthorized access attempts from the same source IP.
Todyl identified the geolocation of the activity as Cheyenne, WY, US (via Entra) and Sydney, AU (via Todyl enrichment).

The strongest version of this narrative is a technical post-mortem of a supply-chain credential leak. It provides precise indicators and actionable remediation steps to mitigate immediate data exposure.
However, the framing follows a specific vendor-driven pattern. By positioning the discovery through its "Cloud Anomaly Framework" and "MXDR" services, Todyl creates a narrative where the vendor's proprietary tooling is the primary shield against a sophisticated, automated "crawl." The persistence of the "exposed" status—emphasizing that data should be treated as compromised despite a lack of evidence for bulk exfiltration—serves to heighten the perceived necessity of high-visibility monitoring tools.
Patterns detected: ARC-0032 Authority Game, ARC-0012 Fear Appeal
The root cause is the inherent risk of multi-tenant OAuth applications. The "trust once, access everywhere" paradigm of vendor-published apps creates a single point of failure where one leaked secret grants keys to thousands of kingdoms. This echoes the historical pattern of SolarWinds or Kaseya, where the trusted management tool becomes the primary vector.
The implication is a steady erosion of the "perimeter" concept. Human agency is diminished as administrators grant broad permissions to third-party apps they cannot monitor internally. The benefit flows to security vendors who sell the visibility that Microsoft's default logging lacks.
Bridge Questions: If the actor had the secret, why did they stop at sign-ins for some tenants rather than proceeding to bulk exfiltration? Would a "least-privilege" consent model for backup apps be technically feasible without breaking the service?
Counterstrike Scan: A coordinated campaign would use this incident to trigger a mass panic regarding all third-party M365 integrations to drive migrations toward a specific "secure" alternative. The current content is a standard vendor threat-intel report; it aligns more with customer retention and marketing than a coordinated influence operation.