ConnectWise / SkyKick Breach: How to Secure Third-Party Applications in Microsoft 365
Nick Ross · · Video and write-up
What happens when attackers compromise a trusted Microsoft 365 application instead of a user account?
That's exactly the risk exposed by the recent ConnectWise Cloud Backup (formerly SkyKick) security incident.
Attackers obtained application credentials that allowed them to authenticate into customer Microsoft 365 environments without stealing user passwords or dealing with MFA.
But the most concerning part wasn't the initial access. It was what happened next.
What Happened?
In October 2026, Huntress identified unauthorized activity involving ConnectWise Cloud Backup applications.
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.
According to Microsoft, attackers attempted to access more than 2,250 Microsoft 365 tenants using compromised application credentials. That doesn't mean all those tenants were successfully breached.
Investigators also identified an instance where a ConnectWise Cloud Management application assigned itself Global Administrator, along with credential additions to other trusted applications.
Those additional credentials could provide continued access even after the original compromised application was disabled.
How Did the Attack Work?
Third-party applications frequently require Microsoft Graph permissions to perform legitimate functions.
Backup solutions, security platforms, and MSP management tools are good examples. Some have permissions allowing them to access customer data and perform administrative actions without a user signing in.
When an administrator grants these permissions, they're establishing trust between the vendor's application and their Microsoft 365 environment.
If those application credentials are compromised, attackers can potentially inherit those permissions. And if the application has excessive privileges, they may be able to modify other applications, add credentials, or escalate access.
I recreated a similar attack in my own Microsoft 365 lab, demonstrating how a compromised vendor application can access customer data and create an additional privileged access path through another trusted application.
So how do we reduce this risk?
4 Steps to Secure Third-Party Applications in Microsoft 365
1. Restrict Who Can Add Applications to Your Tenant
Before auditing hundreds of existing applications, we first need to stop unnecessary ones from being added.
There are two settings I'd review immediately.
Restrict application registrations
Navigate to Entra ID → Users → User settings.
Set Users can register applications to No.
This prevents ordinary users from creating application registrations. Authorized administrators and users explicitly assigned application development privileges can still manage registrations as appropriate.
Restrict user consent
Navigate to Entra ID → Enterprise apps → Consent and permissions → User consent settings.
For a tightly controlled environment, select Do not allow user consent.
Next, under Admin consent settings, enable the admin consent workflow and assign reviewers.
This gives users a process to request new integrations without allowing them to independently authorize applications to access company data.
The goal is simple: new applications should go through an approval process before receiving access to your environment.
2. Audit Existing Applications and Remove Inactive Ones
This is one of the easiest ways to reduce your attack surface.
Most Microsoft 365 tenants accumulate applications over time. Old vendor integrations, retired products, testing applications, and abandoned automations often remain authorized long after they're needed.
Start here:
Entra ID → Enterprise apps → All applications
Review the applications currently authorized in your tenant and identify the ones you don't recognize or no longer need.
Next, check their usage.
Entra ID → Monitoring & health → Usage & insights
Microsoft provides application activity and service principal activity reports that can help identify when applications were last used.
For applications using app-only authentication, also check:
Entra ID → Monitoring & health → Sign-in logs → Service principal sign-ins
Look for applications with no recent successful authentication.
Important limitation: Microsoft Entra ID only retains sign-in logs for a limited period by default:
- Entra ID Free: 7 days
- Entra ID P1 / P2: 30 days
If you want to investigate sign-in activity beyond 30 days, you'll need to configure diagnostic settings to export the logs to Azure Log Analytics, with retention configured for the period you need. This must be set up in advance; historical logs that have already expired cannot be recovered.
I'd recommend targeting 90 days of history or longer where practical. This provides a better picture of applications that run infrequently.
Also, no sign-ins during the available period doesn't automatically mean an application is unused. Some integrations run only periodically, so validate with the application owner before taking action.
Once you've confirmed an application is no longer needed, you have two options.
Option A — Disable it
Navigate to Enterprise apps → Select application → Properties.
Set Enabled for users to sign-in to No.
This prevents new authentication through that service principal while preserving its configuration. It's my preferred first step if you're unsure whether something might break.
Option B — Delete it
If you've confirmed the application is no longer required, delete the Enterprise Application to remove its service principal and associated configuration from your tenant.
My recommendation: Disable questionable applications first, validate there are no dependencies, and then permanently retire them.
📚 I've put together a free Application Inventory template in the T-Minus365 Skool community (opens in new tab)to help document and track this process.
3. Block Unauthorized Application Credentials
Remember how the attackers established persistence by adding credentials to other trusted applications?
Microsoft provides a security control that can restrict this behavior.
Navigate to:
Entra ID → Enterprise apps → Application policies
Look for two settings:
- Block password addition: Prevents new client secrets from being added to covered applications and service principals.
- Restrict max password lifetime: Limits the lifetime of newly created client secrets.
I'd recommend evaluating Block password addition for your environment and using justified exceptions where necessary.
Be careful before enabling this globally. Existing automations may depend on adding or rotating client secrets, so identify those dependencies first.
For applications your organization develops, consider certificate-based authentication, managed identities, or workload identity federation where supported.
One important limitation: policies configured in your tenant don't control credentials that an external vendor creates on its own home-tenant app registration. They do help protect applications and service principals covered by your tenant's policies.
4. Review Application Permissions
This is probably the most tedious step, but it's also where you can significantly reduce the impact of a compromised application.
Navigate to:
Entra ID → Enterprise apps → All applications → Select application → Permissions
Review both the Admin consent and User consent tabs to understand the permissions actually granted.
I'd pay particular attention to these Microsoft Graph permissions:
Mail.Read: Application-level access can read mailbox content across the tenant.Application.ReadWrite.All: Can manage applications, including credentials.Directory.ReadWrite.All: Broad directory modification capabilities.AppRoleAssignment.ReadWrite.All: Can grant application permissions to service principals.RoleManagement.ReadWrite.Directory: Can manage Microsoft Entra directory role assignments.
For each application, answer three questions:
- Do we still need this application?
- Why does it require each of these permissions?
- Who is responsible for reviewing and approving its access?
If the vendor can't justify a permission, work with them to remove it. Remember that changing permissions requested by an app registration doesn't necessarily revoke permissions already granted.
This is also why I think application security needs to become part of your vendor onboarding and lifecycle management process. It's far easier to review permissions when a vendor is first onboarded than to untangle years of historical consent decisions.
📚 I've included a free Vendor Application Permissions Review checklist in the T-Minus365 Skool community (opens in new tab).
🔒 CloudCapsule (opens in new tab): We're also automating application inventory discovery and permission classification, making it easier for IT teams and MSPs to identify applications and prioritize high-risk access across their environments.
Why Conditional Access Won't Necessarily Protect You
One important limitation is worth highlighting.
Traditional Conditional Access policies for users don't protect app-only authentication the same way they protect interactive user sign-ins.
Microsoft does support Conditional Access for workload identities, but those policies don't currently cover third-party multitenant applications.
In my lab, the compromised vendor application successfully authenticated, and Conditional Access wasn't applied.
That's why we need to focus on the application itself, its permissions, and the credentials used to authenticate.
MSPs Have an Important Responsibility Here Too
This isn't just a problem with third-party vendors.
MSPs frequently create their own application registrations to automate tasks in downstream customer environments.
Those applications deserve the same level of scrutiny as any commercial vendor integration.
MSPs should be evaluating permissions, reviewing unused applications, protecting credentials, and maintaining an inventory of which customers have authorized their applications.
In some cases, one MSP-owned multitenant application may be trusted across dozens or hundreds of customers, making its security particularly important.
I'll unpack the cross-tenant risks, GDAP relationships, and vendor lifecycle management recommendations in a separate article.
Final Thoughts
The biggest lesson from the ConnectWise / SkyKick incident is that Microsoft 365 security goes beyond MFA, Conditional Access, and user accounts.
Your applications are identities too, and some have extremely privileged access.
Start by controlling which applications enter your environment, removing the ones you no longer need, restricting unauthorized credentials, and reviewing the permissions that remain.
For more resources, check out my free Application Inventory and Vendor Permissions Review templates in the T-Minus365 Skool community.
I'll also be publishing companion guides covering Vendor Lifecycle Management and Microsoft 365 Application Compromise Incident Response.
References
Harden it once, then know it stays that way.
CloudCapsule scans 300+ Microsoft 365 security controls in about a minute, shows what to fix first, fixes findings at scale, and flags drift the day a setting changes.
No credit card required. Results in < 2 minutes.
Keep reading
How to Set Up Claude SSO with Microsoft Entra ID (10-Minute Guide)
TLDR: You can set up Claude single sign-on (SSO) with Microsoft Entra ID in about 10 minutes on a paid Claude Team or Enterprise plan. The process has three parts: verify your company domain in Claude, connect Claude to Entra through Claude’s guided setup, and control access by assigning users or groups in Entra. Once […]
How to secure Claude AI for your Business
An employee opens Claude on their laptop. It is free, it is fast, and within ten minutes they have pasted in a contract, a financial summary, and a list of customer records, all because they are trying to get their job done. No audit trail. No admin visibility. And depending on their account settings, that […]
How Attackers wiped 80,000 Devices in Microsoft 365
On March 11th, 2026, employees at Stryker began their day to blank screens. Within three hours, roughly 80,000 devices had been wiped across the company’s 61-country footprint. Not encrypted. Not ransomed. Erased. No malware was involved. An Iran-linked hacktivist group compromised an admin account and used Microsoft’s own Intune remote wipe capability to erase the […]