ConnectWise Application Identities Compromised: What MSPs and Partners Should Check in Microsoft 365

If you use ConnectWise Cloud Backup or Cloud Management, or you manage Microsoft 365 tenants for customers through any MSP tooling, this one needs your attention now. Stolen application credentials skip the usual defenses. No password gets phished, and no MFA prompt gets triggered.

Here is what has been reported, followed by my own read on it.

What the sources report

According to The Hacker News, ConnectWise disabled seven application identities on October 17, 2026, at 07:00 UTC. Unknown threat actors had gained unauthorized access to those identities and used them to compromise Microsoft 365 tenants. The disabled identities are ConnectWise Cloud Backup and six ConnectWise Cloud Management identities: the main app plus the MS Teams, Exchange Online, MS Graph, Partner Center, and SharePoint Online connections.

ConnectWise also suspended the Cloud Backup service by revoking certificates used for the affected application connections across all users. Scheduled backups are not running, and access to backup archives and restores is unavailable. The company says existing archives remain encrypted, isolated, and preserved, and that there is no evidence the attackers accessed them. It has also taken SaaS Security and Cloud Management offline as a precaution.

ConnectWise says it identified the issue on October 14, 2026. It has not yet said how the credentials were exposed, and it is unclear whether a product vulnerability played a part. That analysis is ongoing.

Two statements from ConnectWise stand out:

• Disabling the connections stops new authentication through them, but it does not reverse changes already made inside a tenant.
• Previously issued access tokens may stay usable until they expire or are invalidated, and any unauthorized access set up through separate identities needs its own review.

ConnectWise also said it has not seen successful threat activity in the environments it monitors, but that this says nothing about downstream customer environments, which it cannot directly observe.

Why a stolen app credential is worse than a stolen password

The article explains the mechanics well. An attacker holding the application’s credential can authenticate as that application and request tokens from Microsoft Entra ID based on the permissions it already has. Backup and management tools tend to have broad permissions, so depending on the grant, that can mean mailboxes, SharePoint documents, Teams messages, and directory information.

The attacker does not need to steal credentials one customer at a time. One shared credential opens many doors.

The persistence angle matters most. The report says an attacker with this access can add the app to the Global Administrator role, add client secrets to other trusted applications in the tenant, and create new applications with their own permissions. Those planted secrets let the attacker back in even after the original credential is revoked.

This is why ConnectWise’s note that disabling connections does not undo prior changes carries so much weight.

What Huntress observed

Huntress told The Hacker News that it last saw malicious sign-ins from the original address on October 15 at 08:45 UTC, with targeted, manual activity continuing until about 14:20 UTC that day. It has not identified new malicious activity since, though it says there is no evidence the lull was caused by public disclosure.

Huntress also said it has high confidence the attacker targeted the Cloud Management apps for Exchange Online, Teams, and SharePoint, and confirmed abuse of the Teams app in one tenant. Those apps did not appear to have been disabled by ConnectWise at the time, so Huntress was still investigating possible further activity from them.

Other details from Huntress:

• A second, targeted wave came from 144.172.64[.]128 on October 15. It singled out 16 tenants in the policy, national security, trade, and critical mineral sectors. These attempts were unsuccessful.
• The first sweep went after Graph tokens from the SkyKick app. The second looked manual and hit Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and the Office 365 Management APIs.
• Overall, Huntress saw almost 1,000 Entra tenants with sign-in activity from that IP, and about 300 of those sign-ins succeeded. In some tenants, the lack of a service principal kept the attacker from getting access.

ConnectWise later shared two more IPs linked to the activity: 144.172.64[.]99 and 144.172.64[.]60. Cloud Backup, SaaS Security, and Cloud Management remain suspended.

What partners are told to do

The source lists these recommended actions:

• Review your own Microsoft 365 tenant and every managed customer tenant, including ones with dormant SkyKick connections.
• Verify the status of the listed application connections and keep them disabled until further notice.
• Review sign-ins from October 13, 2026, to now, looking for the IP addresses above.
• Preserve sign-in and audit records before you start containment.
• Review app and user authentication, app credentials, federation trusts, directory roles, owners, consent grants, and recent policy changes.
• Check for unauthorized mailbox forwarding, inbox or transport rules, and delegated mailbox access.
• Investigate any other identities changed or used during suspicious activity.

My take

This section is my analysis, not something the sources state.

The lesson I take from this is that your Microsoft 365 security depends on every third party holding a service principal in your tenant. You can have solid MFA and Conditional Access for users and still be exposed through an app that sits outside those controls. Worse, when the tool is down or suspended, the monitoring and backup it provided are gone at the exact moment you need them. Here, SaaS Security monitoring and alerting is offline along with Cloud Backup.

The order of operations also matters. Revoking the vendor’s credential is the easy part. The hard part is finding what the attacker did with the access before the revocation: new client secrets, new apps, role changes, mail rules. Hunting only for the known IPs would miss anything done from different infrastructure, so I would work from the changes in the tenant and use the IPs as one lead among several.

One more thing. The 16 targeted tenants were in sensitive sectors, and that part looked manual. Sweeps across a thousand tenants with a narrow set of hand-worked targets suggest the attacker was choosing victims, not just collecting access. If you serve clients in government-adjacent or strategic industries, treat your review as higher priority.

Practical takeaways

1. Preserve logs first. Export sign-in and audit data before you change anything.
2. Hunt for persistence, not just access. Look at Global Administrator membership, app registrations, and any client secrets you did not create.
3. Check mail. Forwarding rules, transport rules, and delegated access are classic follow-on steps.
4. Use the Entra controls Huntress points to. Application management policies can restrict or block client secrets and cap credential lifetimes. Limiting who holds the Application Administrator and Cloud Application Administrator roles reduces who can add credentials to apps.
5. Consider workload identity controls. Conditional Access for workload identities can restrict where an app signs in from, though it needs extra licensing. Entra ID Protection can flag risky service principals. Huntress notes none of this replaces reviewing credentials, but it makes a planted secret harder to use or easier to spot.
6. Inventory your third-party apps. Know which vendors hold permissions in your tenants and what those permissions are. Remove dormant connections.

The investigation is still open, and ConnectWise has not said how the credentials leaked. Watch for updates, and check your tenants now instead of waiting for the root cause.

Sources

• ConnectWise Suspends Cloud Backup After Attackers Compromise Microsoft 365 Tenants — The Hacker News, 2026-10-18