MFA Didn't Stop the SkyKick Attackers. Your App Controls Can.
TL;DR
- In the October 2026 ConnectWise Cloud Backup (formerly SkyKick) incident, attackers authenticated to Microsoft 365 tenants with stolen application credentials, so user passwords and MFA never came into play.
- Microsoft attributed the campaign to Storm-0940 and said the attackers attempted to access more than 2,250 Microsoft 365 tenants, which does not mean every one was breached.
- Conditional Access for workload identities does not currently cover third-party multitenant applications, so the app's permissions and credentials are the controls that matter.
- Entra ID keeps sign-in logs for 7 days on the Free tier and 30 days on P1/P2, so spotting rarely used apps means exporting logs to Azure Log Analytics before you need them.
- The Block password addition application policy stops new client secrets from being added to covered apps, which cuts off the persistence technique used in this attack.
Picture a tenant with MFA enforced for every user and a tidy set of Conditional Access policies. Now picture an attacker walking straight past all of it, because they never signed in as a user at all. They signed in as an application the tenant already trusted.
That is the shape of the ConnectWise Cloud Backup (formerly SkyKick) incident. The attackers held application credentials, and those credentials let them authenticate into customer Microsoft 365 environments with no password to steal and no MFA prompt to beat. The initial access was bad. What they did with it afterward is the part every MSP should study.
What do we know about the ConnectWise Cloud Backup incident?
Huntress identified unauthorized activity involving ConnectWise Cloud Backup applications in October 2026. Microsoft attributed the campaign to Storm-0940, a China-state-aligned threat actor that used an AI framework called ARTEX to automate portions of the attack.
The confirmed details, as of late October 2026:
- Attackers attempted to access more than 2,250 Microsoft 365 tenants using compromised application credentials. Attempted is the key word; that figure doesn't mean every one of those tenants was successfully breached.
- In one instance, a ConnectWise Cloud Management application assigned itself Global Administrator.
- Investigators found credentials added to other trusted applications.
- Those extra credentials could keep the attackers inside even after the original compromised application was disabled.
Why does a stolen app credential beat MFA?
Backup platforms, security tools, and MSP management software all need Microsoft Graph permissions to do their jobs. Some of those permissions let the vendor's application read customer data and take administrative actions with no user signed in.
When an admin grants those permissions, the tenant is extending trust to the vendor's application. If the application's credentials leak, the attacker inherits that trust along with every permission attached to it. An over-privileged app goes further: it may be able to modify other applications, add credentials to them, or escalate its own access, which is exactly the persistence path seen here.
A lab recreation of a similar attack showed the whole chain: a compromised vendor application reading customer data, then opening an additional privileged access path through a second trusted application.
Conditional Access won't catch this
The user-focused controls most tenants rely on don't apply here. Traditional Conditional Access policies for users don't protect app-only authentication the way they protect interactive sign-ins. Microsoft does offer Conditional Access for workload identities, but those policies don't currently cover third-party multitenant applications.
In the lab, the compromised vendor application authenticated successfully and Conditional Access showed as not applied. So the defense has to sit on the application itself: who can add it, whether it still belongs, what credentials it can gain, and what permissions it holds.
Control 1: Make new apps earn their way in
Before you audit hundreds of existing applications, stop new ones from arriving without review. Two settings handle this.
Turn off user app registrations.
- Go to Entra ID → Users → User settings.
- Set Users can register applications to No.
Ordinary users can no longer create app registrations. Authorized administrators and users explicitly assigned application development privileges can still manage registrations as appropriate.
Turn off user consent and route requests to admins.
- Go to Entra ID → Enterprise apps → Consent and permissions → User consent settings.
- For a tightly controlled environment, select Do not allow user consent.
- Under Admin consent settings, enable the admin consent workflow and assign reviewers.
Users still get a path to request the integrations they need. What they lose is the ability to authorize an application against company data on their own. The rule we'd hold every tenant to: no application gets access until it passes an approval process.
Control 2: Retire the apps nobody is using
Shrinking the list of authorized apps is one of the cheapest ways to cut attack surface. Tenants collect applications for years: old vendor integrations, retired products, test apps, abandoned automations. Many stay authorized long after anyone needs them.
Find the candidates
- List what's authorized at Entra ID → Enterprise apps → All applications and flag anything you don't recognize or no longer need.
- Check activity at Entra ID → Monitoring & health → Usage & insights. The application activity and service principal activity reports help show when each app was last used.
- For apps that use app-only authentication, check Entra ID → Monitoring & health → Sign-in logs → Service principal sign-ins and look for apps with no recent successful authentication.
Know the limits of the logs
By default, Microsoft Entra ID keeps sign-in logs for a limited window:
- Entra ID Free: 7 days
- Entra ID P1 / P2: 30 days
To look further back than 30 days, configure diagnostic settings to export the logs to Azure Log Analytics, with retention set for the period you need. This has to be in place ahead of time, because logs that have already expired can't be recovered. We'd aim for 90 days of history or more where practical, since that gives a far better picture of apps that only run occasionally.
An empty sign-in history also doesn't prove an app is unused. Some integrations run only periodically, so confirm with the application owner before you act.
Disable first, delete second
Once you've confirmed an app isn't needed, you have two options:
- Disable it. Go to Enterprise apps → select the application → Properties and set Enabled for users to sign-in to No. This blocks new authentication through the service principal and keeps its configuration intact. It's the safer first move when you aren't sure what might break.
- Delete it. When you're certain the app isn't required, delete the Enterprise Application to remove its service principal and associated configuration from the tenant.
Our recommendation: disable anything questionable, confirm there are no dependencies, then retire it permanently.
Control 3: Cut off the persistence trick
The attackers in this incident stayed in by adding credentials to other trusted applications. Entra ID has a control aimed squarely at that move.
Go to Entra ID → Enterprise apps → Application policies and find two settings:
- Block password addition prevents new client secrets from being added to covered applications and service principals.
- Restrict max password lifetime limits how long newly created client secrets stay valid.
With the policy on, a Microsoft Graph addPassword request fails with a CredentialTypeNotAllowedAsPerAppPolicy error:
We'd evaluate Block password addition for every environment and grant justified exceptions where needed. Don't flip it on globally without homework, though. Existing automations may depend on adding or rotating client secrets, so find those dependencies first. For applications your own organization builds, move to certificate-based authentication, managed identities, or workload identity federation where they're supported.
Know where this control stops. Policies in your tenant don't govern credentials an external vendor creates on its own home-tenant app registration. They protect the applications and service principals your tenant's policies cover.
Control 4: Question every permission that remains
This is the slow step, and it's the one that most limits the damage a compromised app can do.
Go to Entra ID → Enterprise apps → All applications → select the application → Permissions, and review both the Admin consent and User consent tabs to see what has actually been granted.
These Microsoft Graph permissions deserve the closest look:
Mail.Read: at the application level, reads mailbox content across the tenant.Application.ReadWrite.All: manages applications, including their credentials.Directory.ReadWrite.All: broad rights to modify the directory.AppRoleAssignment.ReadWrite.All: grants application permissions to service principals.RoleManagement.ReadWrite.Directory: manages Microsoft Entra directory role assignments.
For every application, get answers to three questions:
- Do we still need this application?
- Why does it need each of these permissions?
- Who owns reviewing and approving its access?
When a vendor can't justify a permission, work with them to remove it. Keep in mind that changing the permissions an app registration requests doesn't necessarily revoke permissions that were already granted.
This is why we think application security belongs inside vendor onboarding and lifecycle management. Reviewing permissions on the day a vendor is onboarded is far easier than untangling years of accumulated consent decisions later.
We're automating this part at CloudCapsule: application inventory discovery and permission classification, so IT teams and MSPs can see which apps exist and prioritize the high-risk access across their environments.
Your own MSP apps are in scope too
Third-party vendors aren't the only ones holding keys. MSPs routinely build their own application registrations to automate work in downstream customer tenants, and those apps deserve the same scrutiny as any commercial integration:
- Evaluate their permissions.
- Review and retire the ones no longer in use.
- Protect their credentials.
- Keep an inventory of which customers have authorized them.
A single MSP-owned multitenant app can be trusted by dozens or hundreds of customers. That reach is what makes it worth an attacker's time, and what makes securing it a priority.
The takeaway: apps are identities
The ConnectWise / SkyKick incident is a reminder that Microsoft 365 security doesn't end at MFA, Conditional Access, and user accounts. Applications are identities too, and some of them hold extremely privileged access.
Work through it in order: control which apps get in, remove the ones you no longer need, block unauthorized credentials, and challenge the permissions on everything left.
References
Frequently asked questions
Does Conditional Access protect against a compromised vendor application?
Not reliably. Conditional Access policies for users don't govern app-only authentication the way they govern interactive sign-ins, and Conditional Access for workload identities doesn't currently cover third-party multitenant apps. In a lab recreation of this attack, the vendor app's service principal sign-in to Microsoft Graph showed Conditional Access as Not applied.
Should I disable or delete an enterprise application I think is unused?
Disable first. Setting Enabled for users to sign-in to No blocks new authentication through the service principal while keeping its configuration, so you can confirm nothing depends on it before deleting the enterprise application for good.
Can my tenant's app management policies stop a vendor from adding credentials to its own app?
No. Policies in your tenant don't control credentials a vendor creates on the app registration in its own home tenant. They protect the applications and service principals your tenant's policies cover.
See every app that can touch your tenants
CloudCapsule inventories enterprise applications across every tenant you manage and classifies their permissions, so the high-risk access surfaces first instead of after a vendor's bad week.
Run a free scan
Written by
Nick Ross
CEO · Microsoft MVP · Founder, T-Minus 365
Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.
Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.
Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.
