A supply-chain attack involving ConnectWise’s cloud services has exposed Microsoft 365 customers to unauthorized application access, with researchers reporting successful sign-ins across 173 partner and customer tenants. The incident centres on credentials associated with ConnectWise Cloud Backup, formerly SkyKick, and raises concerns about attackers exploiting permissions already entrusted to business software.
ConnectWise has confirmed unauthorized access to application identities within its Cloud Backup environment. In an October 17 update on itsservice-status page, the company said it was shutting off application access, interrupting customer backups while investigation and remediation continued.
The company said it had found no indicators that stored partner backup data had been compromised. That statement should be read within its stated scope: the security of backup archives is a separate question from what an attacker might have accessed inside connected Microsoft 365 tenants.
A Trusted Integration Becomes the Entry Point
The technical significance lies in the identity used to gain access. An application approved to perform business tasks can operate independently of the employees whose information it processes.
Microsoft’sdocumentation on application-only accessexplains that a service can authenticate using its own identity and request a Microsoft Graph access token. Administrators approve its application permissions in advance; subsequent token requests do not require another consent prompt.
This is essential for unattended services. A background application cannot wait for someone to approve a login every time it needs to perform an authorized operation. But it also creates a security dependency: whoever controls the application’s authentication material may be able to exercise the permissions granted to that identity.
The distinction helps explain why an organization can face cloud exposure without a new phishing email or an employee approving a malicious sign-in. An attacker may be using a relationship the organization approved long before the incident.
Why One Vendor Identity Can Affect Many Customers
Microsoft’sexplanation of applications and service principalsdescribes how a multi-tenant application establishes a local identity in each customer environment where it is used. That local identity, called a service principal, determines the application’s access within the tenant.
The application’s global identifier and its local service-principal object are related but distinct. For administrators, that means identifying the correct vendor application is only the beginning: they must also establish what permissions its local instance holds.
The wider implication is that a vendor credential incident can cross organizational boundaries through existing authorizations. Each customer may have a separate Microsoft 365 environment, yet those environments can depend on the same external application identity.
This makes application inventory a business-risk issue. Knowing which supplier provides a service is insufficient without knowing which identities connect that service to corporate data, what those identities can do, and who can disable them during an incident.
Investigation Expands Beyond Cloud Backup
In an October 17 update,Huntresssaid it had high confidence that attackers had also abused ConnectWise Cloud Management applications for Exchange Online, Microsoft Teams and SharePoint Online.
The following identifiers distinguish the applications:
Huntress advised disabling affected applications rather than deleting them, reviewing application secrets and certificates added since October 13, and removing unauthorized credentials and directory roles. It warned against re-enabling affected integrations before ConnectWise confirms credential resets.
The widening scope makes it important for customers to follow updated advisories rather than treating the first published application identifier as a complete inventory of risk.
Attacker-Added Credentials Complicate Recovery
In apublic investigation update, Huntress described a separate ConnectWise Teams management application granting itself Global Administrator and adding credentials to a partner-specific, single-tenant Huntress application.
That finding does not establish a breach of Huntress’s wider platform. It describes manipulation of an application identity within a particular partner’s environment.
Huntress also cautioned against attributing the activity from its logged private IPv6 address alone: legitimate ConnectWise traffic and unrelated customer traffic could appear from the same Microsoft cloud address range.
The underlying persistence mechanism is well established.MITRE ATT&CKdocuments how adversaries add credentials to existing cloud applications and service principals to retain access. A newly added password or certificate can give an attacker another means of authenticating as an already trusted identity.
The practical consequence is that recovery must examine changes made after entry. Closing the original access route does not automatically invalidate a credential attached to a different application.
For incident responders, this creates two connected tasks: contain the compromised vendor integration and identify any additional identities, credentials or permissions that could sustain access.
Data Exposure Remains Difficult to Measure
Todyl’s investigation, published by head of detection engineering Nicholas Koken, independently identified unauthorized application sign-ins in monitored tenants.
Todyl said the application’s permissions provided access to email and attachments, OneDrive and SharePoint files, and Teams chats. In its examined environments, it found no directory changes establishing persistence through the backup application.
Those findings do not contradict Huntress’s account of a different management application being abused in another tenant. They concern different observations and should not be combined into a claim that every affected organization experienced the same sequence.
Todyl also described a forensic limitation: where legitimate backups were active, data-read activity could not reliably be separated from attacker activity using the available records. Detailed Microsoft Graph activity logs had not been collected in those tenants.
Successful authentication, the ability to access data and confirmed exfiltration are therefore different findings. The published evidence establishes unauthorized access, but it does not support treating every accessible mailbox or file as proven stolen.
Why Employee MFA Does Not Resolve This Attack Path
Microsoft’sworkload-identity security documentationexplains that application identities cannot perform multifactor authentication in the way human users do.
That is why stronger employee authentication, while essential, does not by itself secure an application’s independent access. A user password reset addresses a different identity from the service principal used by an unattended integration.
There is also a consequential limitation in Conditional Access coverage. Microsoft states that its workload-identity policies apply to eligible single-tenant service principals registered in the organization’s tenant; third-party SaaS applications, including multi-tenant applications, are outside that policy coverage.
Security teams should therefore verify that a proposed control actually applies to the affected identity. Assuming that a location restriction or MFA policy for employees also governs a third-party application can leave a substantial gap.
The Logs Administrators Need to Examine
Microsoft maintains a separate category ofservice-principal sign-in logsfor application authentication. These events do not involve a user signing in.
That separation matters during an investigation: reviewing employee login activity alone can miss the relevant evidence. Microsoft also groups matching service-principal sign-in events into a single row, which investigators can expand to inspect individual timestamps.
ConnectWise’s guidance directs customers to this application-sign-in view and identifies 144.172.64[.]128 as a suspicious address requiring investigation. The vendor cautions that indicators alone do not establish compromise.
Authentication records answer only part of the question. Microsoft’sGraph activity logsprovide request-level information, including application identifiers, client IP addresses, request methods, target URIs and response codes.
These records can help correlate an application’s authentication with its subsequent API activity. Microsoft requires an Entra ID P1 or P2 tenant licence and appropriate Azure logging infrastructure to collect them.
For security leaders, the lesson is operational: logging must cover both the issuance of access and the actions performed with it. A successful-login alert cannot, on its own, establish which information was retrieved.
Backup Disruption Creates a Second Business Concern
Alongside the security investigation, customers must manage interrupted backup operations. ConnectWise said existing archives were unaffected by the service interruption and would be accessible once services were restored.
For affected organizations, that creates a recovery-planning question: how much new information is accumulating while normal backup activity is paused, and what would be recoverable if another incident occurred during that period?
This is a business-continuity assessment, rather than evidence that production Microsoft 365 data has been lost. Organizations should establish their last successful recovery point and confirm available restoration options with their provider.
Longer term, Microsoft’sservice-principal security guidancerecommends assessing application privileges, protecting credentials and reducing permissions to what the task requires.
Applied to supplier integrations, that means assigning clear ownership, reviewing access when services change or contracts end, and monitoring application authentication as a security-sensitive activity.
The investigation remains open. The immediate priority is to establish each tenant’s exposure, remove unauthorized access paths and verify remediation before restoring affected integrations. The broader issue is whether organizations can account for—and promptly control—the powerful application identities operating inside their cloud environments.
