A stolen vendor application credential belonging to ConnectWise Cloud Backup let attackers sign into at least 173 Microsoft 365 tenants starting October 15, 2026, and no user password or MFA prompt was ever involved. According to Huntress and Todyl's joint research, the attacker authenticated directly as the backup application itself using a leaked client assertion, inheriting every permission customers had already granted it.
Jump to what we checked on our own vendor app grants if you run any MSP tooling against Microsoft 365.
What a Vendor Application Credential Actually Lets an Attacker Do
ConnectWise Cloud Backup, formerly SkyKick Backup, runs as an app-only identity inside every customer tenant that installs it, with no human attached to its sign-ins. The stolen credential was a client assertion, a type of secret that proves an application's identity to Microsoft Entra and lives entirely in the vendor's own tenant. Nothing a customer did locally could have produced or exposed it.
Between 06:13 and 08:34 UTC on October 15, the attacker requested Microsoft Graph access tokens as this application from a hosting-provider IP address, moving through tenant identifiers in sorted order a few seconds apart, a pattern that points to a script working from a prepared target list rather than a person at a keyboard.
Why MFA Never Saw This Attack Coming
A client-assertion sign-in is an app-only identity, not a user session, so multi-factor authentication has nothing to challenge. Standard containment playbooks assume a compromised human account: force a password reset, revoke sessions, require re-enrollment. None of that touches a stolen application secret, because the credential lives in the vendor's tenant, not the customer's.
Per Todyl's investigation, the inherited consent let the attacker read and write mail and attachments through Exchange, read OneDrive and SharePoint files directly, and pull Teams chat history, in every tenant where the app was already installed and trusted. In at least one tenant, a related ConnectWise application escalated itself to Global Administrator and planted new client secrets on two other trusted applications, including a security vendor's own platform, secrets set to expire in 2028.
What We Checked on Our Own Vendor Grants
We pulled the enterprise application list across every Krova Cloud Microsoft 365 tenant and checked each one for app-only grants with mailbox, file, or directory write access, the exact permission shape this incident abused. We found two legacy vendor integrations nobody had reviewed since onboarding, one tied to a billing tool we stopped using over a year ago. We revoked both the same afternoon and documented who owns the review going forward, since nobody currently does.
What to Check in Your Own Tenant
- Search Entra ID Enterprise Applications for application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, and disable rather than delete it if present, since deleting can remove the audit trail you need.
- Check sign-in logs for the published attacker IP ranges around 144.172.64.0/24 and the python-requests or python-urllib user agents named in the research.
- Review every vendor application with standing write access to mail, files, or directory data, not just this one, since the same app-only trust shape exists for any MSP tool you have installed and forgotten about.
- Audit for new Global Administrator role assignments and newly added client secrets on trusted applications in the last two weeks, the specific persistence technique Todyl documented.
The catch is that disabling the compromised app does not revoke tokens already issued. Per Todyl's writeup, those tokens can remain valid for up to 90 minutes after an app is disabled, and any tenant where the app stayed enabled during the window stays exposed until the vendor rotates the credential on its side, not yours. Customers cannot fix this alone, and that dependency is the real lesson, not just the specific application ID.
This is the same trust shape I wrote about when GhostAction hijacked GitHub Actions workflows: a credential with broad, pre-approved standing access is worth more to an attacker than almost any individual password, and it keeps being the actual foothold long after the headline vulnerability gets patched.
The Rule
An app-only credential inherits whatever access you consented to when you installed it, and that consent does not expire just because you forgot the app exists. If your tenant security review only asks "which users have risky permissions," you are checking half the attack surface, because a vendor application with standing Exchange, SharePoint, or directory access can do everything a compromised admin account can do, without ever triggering a single multi-factor prompt.
Frequently Asked Questions
How many Microsoft 365 tenants were affected by the ConnectWise breach?
Huntress confirmed unauthorized sign-ins in at least 173 Microsoft 365 partner and customer tenants as of October 17, 2026, up from 162 tenants reported a day earlier. ConnectWise says the figure may not represent the full global impact.
Why didn't multi-factor authentication stop this attack?
Because the sign-ins used an app-only identity, a client assertion credential that proves an application's identity rather than a human logging in. MFA only challenges user sessions, so an attacker holding the application's own secret bypasses it entirely.
Does disabling the ConnectWise application in my tenant fix the problem?
Not immediately. Disabling the app stops new token requests, but tokens already issued can stay valid for up to 90 minutes afterward. Full remediation depends on ConnectWise rotating the underlying credential, which only the vendor can do.
What should I check first if I use ConnectWise Cloud Backup or similar MSP tools?
Search your Entra ID Enterprise Applications for application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, review sign-in logs against the published attacker IP ranges, and audit for any new Global Administrator assignments or client secrets added to trusted applications in the last two weeks.
I'm Rohit, founder of Krova Cloud: disposable VMs with no standing vendor integrations and no app-only credential sitting around for two years waiting to be forgotten about. More debugging stories at debugly.dev.
