How to Check If the ConnectWise Breach Touched Your Microsoft 365 Tenant

The ConnectWise Cloud Backup breach put every Microsoft 365 tenant with the app installed in the blast zone. Attackers used one stolen application credential to sign into 173 tenants on October 15, 2026, and in at least one case planted backdoor credentials in other apps. If you administer a Microsoft 365 tenant, here is how to check whether yours was touched and how to close the doors.

You will need Global Reader or Security Reader access at minimum to read sign-in logs, and Application Administrator or Global Administrator rights to disable apps and rotate secrets. Give yourself about 30 minutes.

Step 1: Find the ConnectWise app in your tenant

Open the Microsoft Entra admin center and go to Identity, then Applications, then Enterprise applications. Search for "ConnectWise" or "SkyKick" (ConnectWise Cloud Backup was formerly called SkyKick Backup, and older consents may carry the old name).

The application ID to look for is 506e08f9-6e9a-4da4-942b-a099a03644ae. If you find it, your tenant had the compromised app installed and consented, which means it was technically reachable by the attacker. That does not prove anyone got in; it proves the door existed. Also check for a second ConnectWise application called Cloud Management for Teams, which played a role in the privilege escalation seen in one tenant.

If neither app is present, your tenant was almost certainly not affected by this specific campaign, though the rest of this guide is still worth reading as a hygiene exercise.

Step 2: Hunt the known indicators

Go to Monitoring and health, then Sign-in logs, and switch to the "Service principal sign-ins" tab. This is the log type most admins never look at, and it is exactly where this attack shows up, because the attacker authenticated as the app, not as a user.

Filter the logs for the ConnectWise application ID above. Look specifically at October 15, 2026 between 06:13 and 08:34 UTC, the window Huntress confirmed. Also look for sign-ins from the IP address 144.172.64.128, a rented hosting address the attacker used. Security researchers recommend preserving audit logs from October 13 onward, since the same IP was seen password-spraying law firm tenants on October 13 and 14.

Any service principal sign-in for the ConnectWise app from that IP, or from any IP that is not part of the vendor's documented infrastructure, is evidence of compromise. Export what you find; you may need it for incident response and for any reporting obligations.

Step 3: Disable the affected applications

Until ConnectWise completes its remediation, researchers recommend disabling the affected ConnectWise applications in your tenant. In Enterprise applications, select the app, go to Properties, and toggle "Enabled for users to sign-in" to No. This stops the app's service principal from authenticating.

Disabling is reversible and safer than deleting outright while the vendor investigation is ongoing, since ConnectWise has said the existing cloud backup archives will be accessible once services are restored. Coordinate with your backup team before you flip the switch so nobody is surprised when backup jobs stop.

Step 4: Look for backdoors in other apps

This is the step most tenants will skip, and it is the most important one. In at least one compromised tenant, the attacker used a ConnectWise application to elevate itself to Global Administrator, then added new client secrets to an MSP management application and to the Huntress security platform's application. Those planted credentials are designed to survive the revocation of the original ConnectWise credential.

Go to Identity, then Applications, then App registrations, and review every application's credentials: client secrets and certificates. Sort by creation date and examine everything added since October 13, 2026. For anything you do not recognize, or that appeared during the attack window with a generic name, investigate before deleting. Check the audit log for who or what created it.

Also review role assignments: go to Roles and administrators and check whether any service principal was granted privileged roles, such as Global Administrator or Application Administrator, around the attack dates. In the known escalation case, the Cloud Management for Teams app granted itself Global Administrator. If you see a service principal holding a role it should not have, remove it and treat the tenant as compromised.

Step 5: Harden for next time

A few durable changes come out of this incident. First, inventory every third-party application consented in your tenant and record what permissions each one holds; most tenants have far more app consents than anyone remembers. Second, restrict who can consent to applications and who can administer service principals, since application consent is effectively a standing grant of privilege. Third, rotate application secrets on a schedule instead of waiting for a breach. Fourth, look into conditional access policies for workload identities, Microsoft's newer framework for controlling how service principals authenticate.

Finally, add service principal sign-in logs to your regular monitoring. Attackers have learned that the app's credential is often the softest target in a tenant. The ConnectWise breach is unlikely to be the last time that lesson is taught.

Frequently Asked Questions

How do I know if my tenant was affected by the ConnectWise breach?

Check Microsoft Entra's service principal sign-in logs for the ConnectWise Cloud Backup application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, especially on October 15, 2026 between 06:13 and 08:34 UTC, and look for sign-ins from 144.172.64.128. Any match is evidence of compromise.

Should I delete or disable the ConnectWise app?

Disable it for now by toggling "Enabled for users to sign-in" to No in the app's Properties. Deletion can wait until ConnectWise finishes remediation, since backup archives are expected to be accessible once services are restored.

What are workload identities?

Workload identities is Microsoft's term for non-human identities in Entra ID, including service principals and managed identities. They authenticate with credentials rather than interactive sign-in, which is why they cannot use multifactor authentication and need policies of their own.