In May 2025, security researchers confirmed that the DragonForce ransomware group had breached a managed service provider through its remote monitoring and management (RMM) platform, then used that single foothold to push a modified installer into the MSP's downstream customer environments. Some of those customers got lucky and their endpoint protection caught it. Others didn't, and ended up on the wrong end of a double-extortion demand.
If your organisation manages devices through Intune, or outsources any part of that to an MSP, the uncomfortable question is not "could this happen to my MSP." It's "does the tool my MSP — or my own RMM agent — uses to manage my devices already hold enough Microsoft Graph permission to rebuild my entire tenant from scratch if its credentials leak?" Most admins have never checked. This post shows you how.
DragonForce compromised an MSP's SimpleHelp RMM server via unpatched path-traversal flaws and used it to attack downstream client networks. That's a real, documented incident, not a hypothetical. RMM and MSP-platform service principals in your own tenant frequently hold Graph permissions like DeviceManagementConfiguration.ReadWrite.All, DeviceManagementManagedDevices.ReadWrite.All, or worse, RoleManagement.ReadWrite.Directory — permissions with the same blast radius as a compromised Intune Administrator or Global Administrator account. Entra ID has no built-in report that flags "this app is a remote-management tool and it holds admin-equivalent Graph scopes." This post gives you a PowerShell script that builds that report from scratch, and a walkthrough of the manual portal check behind it.
The problem: your RMM tool's identity in your tenant may outrank your own admin account
Let's start with what's actually documented, because this isn't a theoretical scare story. In May 2025, BleepingComputer, Sophos, and MSSP Alert independently reported that the DragonForce ransomware operation had breached a managed service provider by exploiting a chain of vulnerabilities in SimpleHelp, a remote monitoring and management platform widely used by MSPs to manage client endpoints. The specific flaws — CVE-2024-57727, CVE-2024-57728, and CVE-2024-57726 — were path-traversal and related issues in SimpleHelp versions 5.5.7 and earlier, disclosed and patched in January 2025. CVE-2024-57727 alone let an unauthenticated attacker pull arbitrary files off the SimpleHelp server, including configuration files containing secrets and hashed credentials. CISA added it to the Known Exploited Vulnerabilities catalog in February 2025 after confirming active ransomware exploitation.
According to Sophos's writeup, once inside the MSP's SimpleHelp instance, the attackers used it for exactly what an RMM tool is built to do — reconnaissance across every connected client machine, gathering device names, configuration details, users, and network topology — before attempting to push a modified installer and deploy ransomware across the MSP's downstream customer base. Results were mixed: one customer's endpoint protection blocked the attack outright, while others suffered both data theft and encryption in double-extortion attempts. The mechanism is the whole point: one compromised upstream tool, multiplied across every tenant it touches.
Here's the part that matters for your own tenant, whether or not you use SimpleHelp specifically. RMM and MSP-platform vendors — SimpleHelp, ConnectWise, Datto/Kaseya, NinjaOne, Atera, N-able, and others in the same category — don't just get local admin on endpoints anymore. Many now integrate directly with Microsoft Graph, registering an app registration and provisioning a matching service principal (an "enterprise application" object) inside your own Entra ID tenant, so they can manage Intune-enrolled devices, read directory data, or automate onboarding through the API instead of clicking through the portal. That service principal is a real identity in your tenant. If it's over-provisioned — holding application permissions far beyond what the integration genuinely uses — a breach of that vendor's infrastructure is functionally identical to an attacker stealing a Global Administrator's credentials in your own environment. The SimpleHelp incident shows the endpoint-agent side of this attack chain played out for real. The Graph-permission side is the one almost nobody has checked.
Why it happens: nobody reviews "the RMM tool" like they'd review a new admin
If a colleague asked to be added as a Global Administrator, most organisations would want a reason, a time limit, and probably a second approver. When the same level of access shows up wrapped in a vendor's Graph app registration during a procurement or onboarding call, it tends to sail through with nobody applying the same scrutiny. There are three structural reasons this keeps happening.
Application permissions run with no human in the loop
Microsoft Graph has two permission types: delegated, which only work while a specific signed-in user is active and are bounded by what that user can already do, and application, which give the app its own standing identity that can call Graph 24/7 with zero user involved. RMM and MSP tools almost always need application permissions — they have to manage devices whether or not an admin happens to be logged in. That means the permission, once granted, behaves exactly like a service account with no MFA, no conditional access enforcement by default, and no session timeout. If the vendor's infrastructure is compromised and its certificate or client secret leaks, the attacker inherits that access directly — no phishing an admin required.
"Which admin-equivalent scopes exist" is not obvious from a scope name
A permission name like DeviceManagementConfiguration.ReadWrite.All doesn't sound as alarming as "Intune Administrator," but functionally it's close. According to Microsoft's own Graph permissions reference, that scope lets an app read and write Intune device configuration and compliance policies and their group assignments — tenant-wide, for every managed device. DeviceManagementManagedDevices.ReadWrite.All lets an app read and write properties of every Intune-managed device in the tenant. And permissions like RoleManagement.ReadWrite.Directory, Directory.ReadWrite.All, and Application.ReadWrite.All go further still — the first lets an app add or remove members of Entra ID directory roles, including Global Administrator; the other two let it modify directory objects and other applications' credentials outright. None of these scope names say "administrator" anywhere in them, which is exactly why they don't get flagged in a five-minute procurement review.
| Graph permission scope (Application) | What it actually lets the holder do | Nearest Entra/Intune role equivalent |
|---|---|---|
RoleManagement.ReadWrite.Directory | Add or remove members of any Entra ID directory role, including Global Administrator | Privileged Role Administrator |
Directory.ReadWrite.All | Create, read, update and delete users, groups, and most directory objects tenant-wide | User Administrator / Groups Administrator (combined, and then some) |
Application.ReadWrite.All | Create, read, update and delete any app registration or service principal, including managing other apps' credentials | Cloud Application Administrator |
DeviceManagementConfiguration.ReadWrite.All | Read and write Intune device configuration and compliance policies and their assignments, tenant-wide | Intune Administrator (configuration scope) |
DeviceManagementManagedDevices.ReadWrite.All | Read and write properties of every Intune-managed device in the tenant | Intune Administrator (device scope) |
DeviceManagementApps.ReadWrite.All | Read and write Intune app deployments, including pushing new Win32 apps or scripts to managed devices | Intune Administrator (app deployment scope) |
Entra ID has no native "admin-equivalent app" report
Unlike role assignments — where the Entra admin centre has a dedicated Privileged Identity Management view showing exactly who holds which directory role — there is no equivalent built-in view that says "here are the enterprise applications whose Graph permissions are functionally equivalent to an administrator." You can see a single app's permissions one at a time on its Enterprise applications Permissions blade, but there is nothing that cross-references every service principal in the tenant against a defined list of high-privilege scopes in one pass. That gap is exactly what leaves RMM and MSP-platform service principals sitting unreviewed for years.
How to verify: checking a service principal's real Graph permissions
Before scripting anything, it's worth knowing how to check one app by hand — useful the moment a new RMM or MSP tool gets onboarded, or when someone finally asks "wait, what can that thing actually touch?"
- Sign in to the Entra admin centre as at least a Cloud Application Administrator
- Browse to Identity › Applications › Enterprise applications and search for the RMM or MSP tool by name
- Open the app, then select Permissions from the left-hand navigation
- Read every row under Admin consent, note whether each is Application or Delegated, and cross-reference each application-type scope against the table above
- Check the Properties blade for Publisher domain and whether the app shows a verified publisher badge — a legitimate RMM vendor should generally be verified
That check took under two minutes for one app. It's also exactly the check nobody does across every RMM, MSP-platform, and remote-access tool's service principal in a tenant that has accumulated dozens of integrations over several years — which is the scale problem the script below exists to solve.
The fix: Get-RMMServicePrincipalRiskReport.ps1
Get-RMMServicePrincipalRiskReport.ps1 uses the Microsoft Graph PowerShell SDK to run the check above across every enterprise application in the tenant, not just the one you already suspect. At a high level:
Get-MgServicePrincipal -Allenumerates every service principal in the tenant. Microsoft's own first-party apps are excluded by matching each app'sAppOwnerOrganizationIdagainst Microsoft's well-known services tenant ID- For each remaining service principal,
Get-MgServicePrincipalAppRoleAssignmentretrieves the application permissions it has actually been granted — not what it's coded to request, what it currently holds - Granted permissions are cross-referenced against a hashtable of Intune-administrator-equivalent and Entra-administrator-equivalent scopes — the six from the table above, plus a few close relatives — resolved dynamically to GUIDs from the Microsoft Graph service principal's own
AppRolescollection in your tenant, rather than hardcoded, so the script doesn't silently break if a GUID ever changes - Each flagged app is additionally checked for keywords commonly associated with RMM/MSP/remote-management tooling in its display name and publisher domain (rmm, remote, monitor, msp, agent, connectwise, kaseya, datto, ninjaone, atera, n-able, syncro, and similar), purely to help you triage the CSV faster — it does not change the severity score, since an over-permissioned custom internal app is just as dangerous as an over-permissioned vendor one
- Every finding also reports whether the app has a verified publisher and when its last sign-in occurred, via the Entra ID sign-in logs, so a permission nobody has used in a year gets flagged as a housekeeping item alongside the security one
Application.Read.All, Directory.Read.All, and AuditLog.Read.All and makes only Get-Mg* calls. It never modifies a permission grant. Removing an over-provisioned scope from a live RMM integration without confirming what it's actually used for can break device management for your entire estate — that decision belongs to a human, with the vendor's current minimum-permission documentation in hand.Here's the core of the scoring logic — resolving the high-risk scope catalog to GUIDs at runtime, then flagging any service principal that holds one:
# Resolve the high-risk permission catalog to GUIDs from the tenant's own Graph service # principal object, instead of hardcoding GUIDs that could drift between environments $graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" -Property Id,AppRoles $highRiskLookup = @{} foreach ($permName in $script:IntuneEntraAdminEquivalentScopes) { $role = $graphSp.AppRoles | Where-Object { $_.Value -eq $permName } if ($role) { $highRiskLookup[$role.Id.ToString()] = $permName } } # Heuristic only, never affects severity: does this look like an RMM/MSP-shaped app by name? $looksLikeRmm = $script:RmmNameHints | Where-Object { $sp.DisplayName -match $_ } $severity = if ($grantedHighRisk.Count -eq 0) { 'GREEN' } elseif ($daysSinceLastSignIn -gt 90 -or -not $isVerifiedPublisher) { 'RED' } else { 'AMBER' }
And a realistic run against a fictional tenant, mirroring the DragonForce/SimpleHelp scenario: an RMM agent connector holding two Intune-admin-equivalent scopes with no recent sign-in activity, an MSP ticketing integration holding one high-risk scope but actively used and verified, and 96 other service principals holding nothing on the list.
PS C:\Scripts> .\Get-RMMServicePrincipalRiskReport.ps1 [INFO] Connecting to Microsoft Graph... [INFO] Resolving Intune/Entra admin-equivalent scope catalog to GUIDs for this tenant... Resolved 9 application-permission GUIDs from the high-risk catalog. === RMM / Third-Party Service Principal Privilege Report === Tenant : contoso.onmicrosoft.com Enumerating service principals... found 118 total, 99 after excluding first-party Microsoft apps. [RED ] RMM Agent Connector Publisher: Verified Last sign-in: 132 days ago DeviceManagementManagedDevices.ReadWrite.All; DeviceManagementConfiguration.ReadWrite.All [AMBER] MSP Ticketing Sync Publisher: Verified Last sign-in: 2 days ago DeviceManagementApps.ReadWrite.All [GREEN] 97 other service principals - no admin-equivalent scopes found --- Summary --- Total service principals scanned : 99 RED (admin-equiv scope, stale/unverified) : 1 AMBER (admin-equiv scope, active+verified) : 1 GREEN (no admin-equivalent scopes) : 97 [INFO] Report complete. Run with -ExportCsv to save full findings.
The RED finding here is the one that matters most: an RMM connector holding two Intune-administrator-equivalent scopes that hasn't signed in for over four months. That combination — broad standing permission plus no recent legitimate use — is precisely the shape of risk the DragonForce/SimpleHelp incident turned into real ransomware deployments. A live, actively-used integration holding one scoped-down permission is a normal Tuesday. A dormant one holding two is a question that needs an answer today.
Remediation — turning findings into action
- Export the full findings with
-ExportCsvand start with every RED row. Confirm with the vendor or internal owner whether the flagged permissions are still genuinely required for the integration to function - For any MSP or RMM relationship, ask the vendor directly for their documented minimum required Graph permission set — most reputable RMM vendors publish one, and it is very often narrower than what got consented to during initial setup
- Where a permission isn't needed, remove it via Enterprise applications › [app] › Permissions › Review permissions in the portal, or programmatically with
Remove-MgServicePrincipalAppRoleAssignmentin a separate, deliberate write session — never in the same run as this read-only audit - Treat any RMM or MSP-platform service principal holding
RoleManagement.ReadWrite.Directoryas an immediate priority conversation, regardless of how long it's been in place — that single scope is Privileged Role Administrator-equivalent - Re-run this report on a recurring schedule, the same way you'd review PIM role assignments. A quarterly cadence is a reasonable baseline; run it immediately after onboarding any new MSP or RMM relationship, and again after any public disclosure of a vulnerability in a tool you use
Proof it worked: catching the finding before it's a headline
After the RED finding above, the fictional admin in this scenario contacted the RMM vendor, confirmed the device-configuration write scope was left over from a policy-deployment pilot that was never rolled out fully, and removed DeviceManagementConfiguration.ReadWrite.All from the service principal — leaving only the device read/write scope the integration actively uses. Re-running the script confirms the change immediately, since permissions are read live from Graph on every run.
PS C:\Scripts> .\Get-RMMServicePrincipalRiskReport.ps1 -ShowAllFindings [INFO] Connecting to Microsoft Graph... [INFO] Resolving Intune/Entra admin-equivalent scope catalog to GUIDs for this tenant... Resolved 9 application-permission GUIDs from the high-risk catalog. === RMM / Third-Party Service Principal Privilege Report === Tenant : contoso.onmicrosoft.com Enumerating service principals... found 118 total, 99 after excluding first-party Microsoft apps. [AMBER] RMM Agent Connector Publisher: Verified Last sign-in: 1 days ago DeviceManagementManagedDevices.ReadWrite.All [AMBER] MSP Ticketing Sync Publisher: Verified Last sign-in: 2 days ago DeviceManagementApps.ReadWrite.All [GREEN] 97 other service principals - no admin-equivalent scopes found --- Summary --- Total service principals scanned : 99 RED (admin-equiv scope, stale/unverified) : 0 AMBER (admin-equiv scope, active+verified) : 2 GREEN (no admin-equivalent scopes) : 97 [INFO] Report complete. Run with -ExportCsv to save full findings.
The RMM connector now shows sign-in activity from the last day and holds a single, narrower device-management scope it's actively using — that's an AMBER finding by design, not a failure. AMBER means "this app holds meaningful power and someone should be able to explain why, on demand" — it's the state every legitimate, actively-used integration with real device-management responsibilities should sit in permanently. RED means "nobody can currently explain this," and that's the state the DragonForce/SimpleHelp incident shows you don't want to discover after the fact.
Which service principal in your own tenant would come back RED right now? If you manage any devices through Intune, or work with an MSP, that's worth answering before your next patch Tuesday, not after the next RMM vendor makes headlines for the wrong reason.
Download Get-RMMServicePrincipalRiskReport.ps1 from Imran76Awan/Daily-Tasks on GitHub — no sign-in required. Read-only (report-only, Graph GET calls only) — validate in your own environment before relying on it.
References
- Microsoft Graph permissions reference — Microsoft Learn
- Get-MgServicePrincipalAppRoleAssignment — Microsoft Learn
- Understand user and admin consent — Microsoft Learn
- Microsoft Entra built-in roles reference — Microsoft Learn
- DragonForce ransomware abuses SimpleHelp in MSP supply chain attack — BleepingComputer
- DragonForce actors target SimpleHelp vulnerabilities to attack MSP customers — Sophos
- CISA Known Exploited Vulnerabilities Catalog
Microsoft MVP community deep-dives
| Author | Post | What it adds |
|---|---|---|
| Daniel Bradley (MVP) | Graph permission scopes and delegate access in Microsoft Entra | Explains why a Graph scope alone doesn't tell the whole access story, and how to decode a token's scp and wids claims to see what an app or service principal can genuinely reach |