A per-tenant procedure for finding every app with a privileged role, checking what changed, and removing standing roles nobody can justify.
By Levi Rose, Senior Marketing Director, CyberQP. 29 October 2026.
In the ConnectWise Cloud Backup incident, the admin was an app. In a tenant Huntress monitors, a vendor app added itself to Global Administrator at 03:44 UTC on 15 October. Within about five minutes it had also added secrets to two other applications. No technician was signed in, because an app signs in with its own credential, so there was no user password or MFA prompt to get past. Every MSP with clients on Microsoft 365 now has the same question to answer: which apps in each tenant hold admin rights, and who last decided they should?
Microsoft's analysis of the campaign, published 21 October and updated 26 October, names the actor Storm-0940 and says it used an agentic AI framework called ARTEX. Its advice for defenders includes this sentence: "Apply least privilege to multi-tenant application permissions and consent grants." The steps below turn that advice, and Huntress's checks, into a procedure you can run in each client tenant.
This part is our reading, not Microsoft's or Huntress's. A role assigned to an app is standing privilege in the same way a permanent Global Administrator is. It is on all the time and nobody signs in to use it, so nobody notices when it is misused. It usually stays in place long after the person who approved it has left. The difference is that an app has no technician to ask, so the review has to be deliberate.
Microsoft's guidance is to contain without deleting: "Do not delete enterprise applications as the first response. Preserve configuration and evidence before making irreversible changes." It also says to find the apps by application ID rather than display name. Keep the Entra sign-in and audit logs, and any SIEM data, before you change anything. Then have an authorized responder remove confirmed unauthorized credentials, grants and assignments.
Run this in every client tenant, one at a time. Each tenant has its own copy of an app, called a service principal, with its own Object ID, so a clean result in one tenant says nothing about the next. Delegated partner access through GDAP (granular delegated admin privileges) is a separate route in, covered in What Is GDAP? Roles, Expiry and Its Limits.
Export the logs. Save the Entra sign-in logs and audit logs for the tenant before you touch anything. Microsoft recommends reviewing from 15 October and extending back to 1 October where the records allow.
List every non-human role holder. In the Entra admin center, open Roles & admins, then each privileged role, starting with Global Administrator and Privileged Role Administrator. Read the assignments for anything that is a service principal rather than a person. Huntress's specific check is whether any ConnectWise or SkyKick app holds a directory role, especially Global Administrator, and whether any role was granted that you did not intend.
List every app with high-privilege API permissions. Under Enterprise applications, open each app's Permissions and flag application permissions, not delegated ones, that reach all users' mail, all files or the whole directory. An app uses these when no user is signed in.
Check every credential. For each enterprise application and app registration, open Certificates & secrets and look for secrets or certificates nobody can account for. Huntress says to pay particular attention to anything added since 13 October, and to remove unexpected ones.
Read the audit log for changes the apps made to themselves. Look for service principals adding themselves to directory roles or modifying other applications. Microsoft lists what to review: credential additions, new applications, service principals and owners, app-role assignments and consent grants, privileged role assignments, and changes to users, groups, authentication methods or Conditional Access.
Check Conditional Access exclusions. Huntress recommends reviewing any exclusion that could leave an attacker's infrastructure unblocked.
Give every remaining role an owner and a reason. For each app that holds a role or a high-privilege permission, write down who approved it, what it does and when it last did it. If nobody can answer, remove the standing role once the evidence is preserved. Rotate credentials wherever you saw suspicious activity, and verify afterward, as Microsoft advises, that the rotation removed the unauthorized access.
Make it a recurring check. Microsoft recommends monitoring credential additions, privilege assignments and unusual app-only activity, especially for apps with high-privilege permissions. A quarterly pass per tenant is a reasonable starting point, and any vendor whose app holds a role, backup and PAM vendors included, belongs on the list.
For each Entra tenant you connect, Panthera's discovery finds non-human identities in Entra ID, including enterprise apps, service accounts and identities used by AI agents. That gives you a starting list for step 2 instead of a blank portal page. API keys, client secrets and tokens are outside what discovery covers, and each app's roles and permissions still come from Entra. Credentials like these can be stored in the Panthera vault, restricted to the technicians who need them, and logged. Panthera also sends privileged account auditing alerts.
The audit above works without Panthera. If you want to see what discovery finds, connect one client and compare its list of non-human identities against the one you built by hand.
Request a free trial at cyberqp.ai.