ConnectWise has disabled seven application identities tied to its Cloud Backup environment after attackers used compromised application credentials to access Microsoft 365 tenants.
Huntress confirmed unauthorized sign-ins across 162 tenants by Oct. 16, including one case where another ConnectWise application gained Global Administrator privileges and added new credentials to other apps.
The vendor-side access has been contained, but the incident isn't over for Microsoft 365 administrators. Disabling the affected applications doesn't undo role changes, credentials, mailbox rules, consent grants, or other persistence an attacker may already have created inside a tenant.
In its latest Cloud Backup security guidance, ConnectWise tells partners to investigate their own Microsoft 365 environments and every customer tenant they manage, including tenants with old or dormant SkyKick connections.
What ConnectWise has confirmed so far
As of ConnectWise's Oct. 19 status update, Cloud Backup, SaaS Security, and Cloud Management remained suspended while remediation and security validation continued. Scheduled backups, archive access, restores, security monitoring, and some management functions were still unavailable, with no confirmed restoration time.
ConnectWise says existing backup archives remain encrypted and isolated and that it has no evidence those archives were accessed. That's narrower than saying customer Microsoft 365 tenants weren't affected.
| Confirmed | Still unresolved |
|---|---|
| Unauthorized access involved ConnectWise application identities | How the original vendor credential was exposed |
| Seven affected application identities were disabled Oct. 17 | Full number of downstream tenants affected |
| Cloud Backup, SaaS Security, and Cloud Management were suspended | Whether data was accessed in individual customer tenants |
| ConnectWise has no evidence backup archives were accessed | Whether attackers established persistence in every successfully accessed tenant |
| Huntress confirmed unauthorized Microsoft 365 sign-ins | Threat actor identity and motive |
According to Huntress, the attacker authenticated using a credential belonging to the Cloud Backup application itself rather than stealing an end user's password. Microsoft sign-in logs recorded the authentication as a client assertion.
That changes what defenders need to look for. App-only authentication doesn't involve a user completing a normal sign-in, so user MFA isn't the control being challenged. The application authenticates with its own credential and receives whatever access its existing permissions allow.
Those permissions are part of the same OAuth authorization model organizations use to let third-party applications reach cloud resources without repeatedly asking a person to sign in.
Huntress also found a second wave of attempts against 16 organizations in policy, national security, trade, and critical-minerals sectors. Many didn't use the affected ConnectWise products, and attempts failed where the required service principal wasn't present.
What Microsoft 365 admins should check now
ConnectWise recommends reviewing activity from Oct. 13 onward and extending searches back to Oct. 1 where log retention allows.
Start with service principal sign-ins, not only the user sign-in view. Microsoft's service principal documentation explains that these records capture application authentication using credentials such as certificates and client secrets.
The Cloud Backup application ID to check is:
506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise has also published three IP addresses associated with the suspicious activity:
144.172.64[.]128144.172.64[.]99144.172.64[.]60
A match should trigger investigation, not an automatic conclusion that the tenant was compromised.
Administrators should also review:
- New or changed application credentials.
- Directory and administrator role assignments.
- Application owners and consent grants.
- Federation trusts and authentication changes.
- Recent Conditional Access or other policy changes.
- Mailbox forwarding, inbox rules, transport rules, and delegated access.
- Other user or application identities modified during the suspicious period.
Microsoft's own compromised-application playbook recommends checking service-principal sign-ins, unexpected credentials, privileged application roles, and unusual permission changes when an application identity may have been compromised.
That broader review is important because removing the original ConnectWise credential doesn't remove a second credential, role assignment, or access path an attacker created after getting inside.
Kasper Lindgaard, Vice President of Security Strategy at CoreView, said a successful sign-in should widen the response beyond simply checking whether the affected ConnectWise applications are disabled.
"If there are any indicators of a successful sign-in from the threat actor, the incident should be treated as a configuration-change incident. This means clearly mapping and reverting any non-confirmable changes performed between 1 October and 07:00 UTC on 17 October.
Lindgaard added:
“ConnectWise has stopped the attack. But businesses unfortunately have the responsibility and difficult task to ensure that the threat actor didn't change any Microsoft 365 configuration or establish any persistence within their tenant. More than a third of IT leaders wrongly believe that Microsoft automatically backs up their configuration, making recovery from such an attack all the more tricky.”
That means administrators need a before-and-after view of the tenant, not just a search for the published IP addresses. A successful app sign-in followed by a new secret, privileged role, mailbox rule, consent grant, or policy change can leave an access path behind after the original application is shut down.
Don't reconnect the apps yet
ConnectWise says affected connections should remain disabled until it publishes formal restoration and reauthorization instructions.
Admins should also preserve available logs before making unnecessary deletions. ConnectWise specifically advises keeping the enterprise applications in place during the initial investigation so their configuration and identifiers remain available as evidence.
The incident also exposes a broader weakness in long-lived application access. Organizations increasingly have to manage non-human identities such as service principals, application identities, API credentials, and automated agents alongside human accounts.
Those identities need named owners, least-privilege permissions, credential rotation, usable logging, and periodic reviews. The same controls should be part of routine third-party risk management for SaaS vendors that retain standing access to sensitive cloud environments.
For ConnectWise customers, the immediate work is narrower: preserve the evidence, find every relevant service-principal sign-in, investigate changes made during the exposure window, remove persistence, and keep the affected applications disabled until ConnectWise says it's safe to reconnect.
Also read: TeamFiltration hackers exploited forgotten Microsoft 365 service accounts, another example of non-human identities creating an overlooked path into cloud environments.