ConnectWise: How One Stolen Credential Can Expose Hundreds of Entra Tenants
A compromised vendor credential can give attackers tenant-wide access to Microsoft Entra while bypassing user-focused controls such as MFA—making every multi-tenant app a risk you need to identify, rank, and regularly reassess.
In case you haven’t heard by now, there was quite the buzz recently in the Entra community when the ConnectWise backup application was the source of a supply-chain attack. Huntress reported that attackers obtained the ConnectWise app credentials. They used those credentials to authenticate to more than 170 Microsoft Entra tenants.
Every multi-tenant app has standing access to your Entra tenant, secured by a credential you don’t hold and can’t see. You need to inventory these apps and rank them by the application permissions you granted at consent. Remove what you don’t need and hold vendors accountable for the application credentials that only they control.
This post focuses on the model that thousands of multi-tenant applications rely on and the threat it may pose to your Entra tenant.
Service principals and credentials: The Entra multi-tenant model
Applications like ConnectWise are common among Entra tenants.
Service principals
These multi-tenant apps are owned and controlled in the vendor tenant but represented in your tenant as a service principal. A service principal is the app’s identity and access record inside your tenant. You control whether it exists and what permissions it has. When an administrator adds a multi-tenant app, they grant admin consent to the application permissions it requests. That consent (or its scripted equivalent) creates the service principal in your tenant and assigns those permissions to it.
The vendor can’t add application permissions on its own; new permissions require a fresh admin consent in your tenant.
Credentials
Credentials work the opposite way. A credential can be the secret, certificate, or federated trust the vendor uses to prove it controls the app. The vendor controls it, not you. Changes to the vendor’s app credentials affect every tenant that has granted consent. They take effect almost at once and you cannot see any of them. A stolen vendor credential can work in every tenant that trusts it.
Attackers can use credentials to issue a token with the application permissions granted in that tenant. Even worse, app-only access requires no user, no MFA enforcement, and no device compliance. It bypasses nearly every security control built around users.
Inventory your Entra applications
The first step in evaluating your risk is to inventory your service principals. Check the app owner. Check appOwnerOrganizationId. It distinguishes third-party multi-tenant apps from Microsoft-owned apps and single-tenant apps in your tenant.
Third-party multi-tenant apps vs Microsoft-owned and single-tenant apps
Single-tenant apps carry your own tenant ID. Microsoft first-party apps carry a Microsoft tenant ID. Common IDs are f8cdef31-a31e-4b4a-93e4-5f571e91255a and 72f988bf-86f1-41af-91ab-2d7cd011db47. Third-party multi-tenant apps carry the tenant ID of the vendor’s tenant.
Record the application permissions granted to each app, as well as its membership in directory roles. Beyond what an application can do, there’s also the risk of old apps that are no longer in use. Even if the application is not being used, the permissions remain unless explicitly removed.
Finally, vendors often rename their apps. But the underlying application ID remains consistent, so it is more reliable than the display name alone.
Limiting the blast radius
Prioritization is an exercise in blast radius assessment. A focus on highest risk, instead of recognizable names, is the best starting point. Some application permissions pose the highest risk to your tenant. Four stand out:
- RoleManagement.ReadWrite.Directory
- Application.ReadWrite.All
- AppRoleAssignment.ReadWrite.All
- Directory.ReadWrite.All.
Tenant-wide data access is another major risk. Mail.ReadWrite, Files.ReadWrite.All, and Sites.FullControl.All can provide unrestricted access to Exchange, OneDrive, and SharePoint resources. A service principal assigned a highly privileged role grants the full permission set associated with the role.
Entra apps don’t follow the same rules as user identities
As previously mentioned, Entra application identities don’t follow the same rules as user identities. So, let’s briefly review what works and what doesn’t.
| Doesn’t apply to app identities | Does apply to app identities |
| MFA and user Conditional Access policies.Revoking user sessions or resetting passwords.Workload identity Conditional Access and continuous access evaluation; these controls cover only single-tenant apps registered in your own tenant. | Disabling the service principal, which stops new tokens in your tenant. Tokens already issued remain valid until they expire, typically 60–90 minutes.Removing the application permissions granted at consent and any directory role assignments. |
Questions to ask your app vendors
For each service principal granted elevated access, start by asking yourself what could happen if the application turned hostile. Then put these questions to your vendor:
- What credential type does your app use (secret, certificate, or federated credential), and how is it stored and rotated?
- Why does the app need each application permission and directory role it requests? Is there a least-privilege option?
- Are capabilities split across separate apps, so customers can consent only to what they use?
- What are your notification commitments if your app credentials are compromised?
- What are the documented steps to fully remove the app and its permissions when we offboard?
Trust in app vendors is paramount
Multi-tenant applications introduce a risk to your tenant. Period. A third-party app’s application permissions work like a standing credential that someone else holds. Trust in your vendors is paramount to the risk posture of your Entra tenant.
Your control point is the service principal: what it’s permitted to do and whether it exists at all. Scrutinize permissions and role memberships service principals have in your tenant. Most of the risk is set at consent time. I would treat every admin consent as a decision to hand over standing access. That access relies on a credential you’ll never see. So, revisit those decisions regularly.
Brandon Colley is a Senior Security Consultant at TrustedSec, specialising in Active Directory and Microsoft cloud security. With more than 15 years of experience administering and securing enterprise IT environments, he brings a practitioner’s per...
