A multi-tenant backup application walked into customer Microsoft 365 directories with a valid secret and nobody at the keyboard. According to BleepingComputer, attackers used a compromised ConnectWise Cloud Backup (formerly SkyKick) OAuth service-principal credential to perform application-only sign-ins, obtain Microsoft Graph access tokens, and inherit permissions tenants had already consented. Huntress reported unauthorized sign-ins in at least about 162 tenants in its environment, with later reporting citing roughly 173. Staff MFA never fired because there was no interactive workforce login to challenge, fatigue, or capture.
Why app-only Graph tokens never hit staff MFA
ConnectWise Cloud Backup is a multi-tenant Microsoft 365 application that MSPs and IT teams commonly consent into customer directories for backup and cloud management. Public reporting names primary application ID 506e08f9-6e9a-4da4-942b-a099a03644ae, with additional Cloud Management apps abused in the same wave.
Application-only client-credential authentication is not a person signing in. The client presents the application's own secret or certificate material and receives tokens as that service principal. When the secret is valid and the enterprise application is already trusted, no mailbox owner, helpdesk agent, push prompt, OTP, or passkey ceremony sits in the path.
According to coverage on BleepingComputer, malicious activity was observed from IP 144.172.64.128 on 15 October 2026, with scripted tooling. Huntress had already linked attacker infrastructure to scripted sign-in attempts around 13-14 October 2026, including a curl/7.88.1 user agent. Microsoft identified unauthorized authentication attempts against the application identities. How the app secret itself was obtained has not been publicly established. That gap matters: the visible blast was app-as-client access, not a documented password spray or phishing attack against staff.
Todyl described automated Graph token acquisition that used a separate sign-in for each tenant. In nine tenants it analyzed, there was no evidence of account creation, password changes, or added permissions performed through the backup app in those cases. The first move was colder: authenticate as the consented application, take the token, move on.
Because customers had already granted the backup stack broad Microsoft Graph rights, a successful app-only sign-in carried those rights with it. According to Todyl (via BleepingComputer), those sign-ins gave the attacker the technical ability to read and write mail and attachments, OneDrive and SharePoint files, and Teams chats. Directory-scoped permissions in the same class, including Directory.ReadWrite.All style grants called out in public reporting, sat in the same danger zone.
Huntress observed service principals self-assigning directory roles after access, most often Exchange Administrator. In one tenant, a Cloud Management - MS Teams principal granted itself Global Administrator and planted credentials on other apps in about five minutes. That is authorization abuse by a service principal that already held write rights into the directory. It is not a second human login ceremony that a stronger staff second factor could have blocked mid-stream.
| Control people expected | What actually ran | Why staff MFA stayed silent |
|---|---|---|
| User password plus MFA | App-only client credentials | No interactive user challenge |
| Kill user sessions | Graph tokens for the app | User revoke misses app tokens |
| Partner backup trust | Pre-granted Graph scopes | Consent already lived in each tenant |
| Password reset for staff | Valid service-principal secret | Wrong object authenticated |
ConnectWise stated it had recently identified unauthorized access to application identities within the ConnectWise Cloud Backup environment. The company also said it had no indicators to date that Cloud Backup partner backup data had been compromised, and that the existing cloud backup archive was not impacted by the service interruption. Those statements address archive integrity claims. They do not erase the Graph-token window inside live customer tenants while the secret worked. Confirmed bulk record-exfiltration totals across every affected tenant remain unreported. No named threat actor has been publicly attributed in the sources used here.
On 17 October 2026, ConnectWise shut down Cloud Backup application access at about 05:01 UTC, revoked certificates and shared credentials, and suspended the service during its investigation. Disabling the vendor application stops issuance of new tokens through that path. Existing Graph access tokens already issued remain valid until they expire. Revoking ordinary user sessions does not end application-based access. Vendor shutdown also does not automatically remove credentials already planted on other apps inside customer tenants where persistence landed.
Defenders who only reset staff passwords or force user MFA re-registration treated the wrong object. The object that authenticated was the service principal. Cleanup has to target enterprise applications, app registration secrets and certificates, role assignments created in the intrusion window, secondary credentials planted on other apps, and outstanding app-only tokens where the platform allows invalidation.
If you want the full attack-chain narrative, read the related post on legacymfa.sucks: how the ConnectWise SkyKick OAuth secret hit M365 tenants.
What phishing-proof MFA changes on this path
Workforce MFA protects interactive human authentication. It asks a person to prove something at sign-in: a password plus a code, a push approval, or a hardware-bound assertion. App-only client credentials skip that entire surface. The identity that authenticated was the service principal for ConnectWise Cloud Backup, not an employee account.
Phishing-proof device-bound authentication is built for human interactive login paths across the identity lifecycle. Private keys stay on enrolled hardware. There is no transferable password, OTP, SMS code, push approval, or recovery secret for an attacker to coach, relay, or fatigue at a fake page. That design closes workforce phishing, AiTM login kits, and helpdesk-coached transferable factors on paths where a person is the subject of authentication.
This ConnectWise SkyKick wave was not that path. MFA 2.0 does not gate application-only client-credential flows, and it does not protect a vendor-held multi-tenant app secret once that secret is already valid against an already-consented service principal. Auth completed as the application. Graph tokens issued under pre-granted permissions. Role self-assignment and secondary credential planting were post-auth authorization moves by a service principal. Interactive MFA, including phishing-proof device-bound MFA, does not sit on that request.
Removing phishable human factors stops attacks that complete a fake or proxied person login. Malware on a machine that already holds a legitimate human session is a different, harder problem. A stolen vendor app secret used for app-only Graph access is a third class: supply-chain credential material outside the workforce login ceremony entirely.
Passkeys and FIDO2 are phishing-resistant at the human login act. A device holds a key pair, the private key never leaves hardware, and signatures are bound to the real origin of an enterprise identity provider that issues only hardware-bound assertions. That stops remote relays of passwords and one-time codes when a person is signing in. In the ConnectWise Cloud Backup incident, the authenticating subject was the application using client credentials. No user ceremony ran, so origin-bound human passkeys were never asked to sign. Passkeys harden people. They do not rotate a vendor app secret or shrink Graph scopes already granted to a service principal.
FIDO2 and passkeys remain phishing-resistant at login only when enrollment or recovery still accepts email OTPs, SMS codes, or helpdesk-issued secrets. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. That lifecycle gap is real for workforce identity programs. It is not the failure mode documented here. Public reporting does not describe helpdesk re-enrollment, TAP issuance, or attacker device registration on employee accounts as the entry. The entry was a multi-tenant application credential. Closing human enrollment loopholes still matters for other campaigns. It would not have gated this app-only supply-chain path.
When human paths are in scope elsewhere in the estate, device-bound keys close transferable-factor replay on those paths. Keep that win. Do not pretend the same control revoked a service-principal secret it never saw.
Controls that bound vendor secrets and Graph consent
What actually bounds this class of failure is not a stronger staff push prompt. It is control of the application credential itself, least-privilege consent so a backup product does not inherit directory-wide write power by default, continuous review of multi-tenant enterprise applications, and monitoring for unusual app-only token issuance from unexpected hosting IPs and scripted user-agents. The prevention focus, not detection alone, still applies, but the object to prevent is secret sprawl and over-broad app consent, not a human typing a code.
One trusted multi-tenant app with directory-wide Graph scopes behaves like a skeleton key across mail, files, chat, and admin roles once its secret is live. That is blast radius even without a classic SAML cookie replay story. Classic SSO auto-login is a separate design liability for human sessions. Here the skeleton key was the consented application identity. Secure Explicit Sign-On thinking still helps architects reject shared replayable proofs where people are involved. It does not magically gate a vendor secret the IdP already trusts for client-credential flow.
Key Takeaways for Defenders
- Inventory every multi-tenant enterprise application with Graph directory or content write scopes, starting with backup and cloud-management stacks, and cut any grant that exceeds the job.
- Treat vendor app secrets and certificates as crown jewels: short lifetime, dual control, vaulted storage, and immediate rotation on vendor incident notices.
- Alert on app-only token issuance from unexpected IPs, scripted user-agents (python-requests, curl), and one-sign-in-per-tenant bursts across many customers.
- After a vendor app compromise, disable the enterprise app, rotate related secrets, hunt role self-assignments and planted credentials, and invalidate outstanding app-only tokens. User password resets alone are not enough.
- Keep phishing-proof device-bound MFA on every human interactive path so workforce phishing stays closed while you harden the separate app-only plane.
The next identity incident that looks like a “Microsoft 365 breach” may again be an application identity problem wearing a tenant costume. Design controls for the subject that actually authenticated.
FAQ
Would MFA 2.0 have stopped the ConnectWise SkyKick tenant sign-ins?
No. MFA 2.0 would not have stopped the ConnectWise Cloud Backup (SkyKick) app-only sign-ins into customer Microsoft 365 tenants. Public reporting describes authentication as the multi-tenant application using a compromised service-principal credential, not an interactive employee login. Phishing-proof device-bound MFA secures human login paths. It does not gate client-credential flows or protect a vendor-held app secret that the directory already trusts.
Why did user MFA fail to protect these Microsoft 365 tenants?
User MFA failed to protect tenants in the ConnectWise SkyKick incident because user MFA was never invoked. Application-only client-credential authentication presents the app’s own secret and receives Graph tokens as that service principal. There was no employee password step, push approval, OTP, or passkey assertion for staff MFA to approve or deny.
What should security teams do after a multi-tenant OAuth app secret is abused?
After multi-tenant OAuth app secret abuse like the ConnectWise Cloud Backup case, security teams should disable or remove the abused enterprise applications, rotate every related secret and certificate, hunt for directory role assignments and credentials planted on other apps during the window, and invalidate outstanding app-only Graph tokens where the platform allows. Revoking only user sessions leaves application-based access intact until app tokens expire or are revoked.
Did passkeys or FIDO2 change the outcome of this supply-chain path?
Passkeys and FIDO2 did not change the outcome of the ConnectWise SkyKick supply-chain path as reported. Those controls are phishing-resistant for human authentication ceremonies. The attackers authenticated as the backup application with a service-principal credential and used pre-consented Graph permissions. No human passkey ceremony was part of that request path.
How is this different from AiTM or helpdesk vishing against workforce logins?
The ConnectWise SkyKick incident differs from AiTM phishing and helpdesk vishing because those attacks target people and transferable human factors at login or recovery. This wave used a compromised multi-tenant OAuth application credential for app-only Graph access. Huntress-scale tenant impact came from consented app permissions and a live secret, not from coaching staff to type a code or approve a push on a spoofed page.
