If an Attacker Owns Your MSP’s Tenant, How Far Can They Walk Into Yours?

The attacker never touched your tenant’s password. They didn’t need to. They walked in through a relationship you set up on purpose, the one that lets your managed service provider administer your Entra ID.

That’s the uncomfortable center of the campaign Cybersecurity Dive reported: an intrusion into an MSP’s Entra ID tenant, used as a launch point to reach the MSP’s downstream clients. No exotic Entra vulnerability. No CVE. Just trust, configured once and never re-examined, being used exactly as designed by the wrong person.

Hour zero: the MSP tenant falls

Everything after this is downstream of one fact, the provider’s directory is compromised. From there, two pre-existing bridges carry the attacker into client tenants.

The first is B2B. MSP staff are frequently invited into client tenants as guest accounts. Compromise the MSP identity, and the guest object it owns elsewhere comes along for free. The second is GDAP, Granular Delegated Admin Privileges, the mechanism that lets partner-tenant roles map onto your directory without a separate account living in it.

Neither is a flaw. Both are the product working. That’s what makes this ugly.

The DAP hangover

GDAP exists because its predecessor, DAP (Delegated Admin Privileges), was a loaded gun pointed at every client at once. A single DAP relationship granted the partner Global Administrator-equivalent control over the customer tenant. One MSP breach, one tenant-wide keys-to-everything.

Microsoft has been migrating partners off DAP to GDAP’s scoped, time-bound role model for exactly this reason. GDAP lets a relationship carry, say, Helpdesk Administrator or Directory Readers instead of god mode. Good. But two things bite in practice: plenty of GDAP relationships were created by cloning the old DAP scope, meaning they still carry high-privilege roles like Global Administrator, and nobody reviews them after signing. Least privilege you configured once and forgot is just privilege.

What to pull today

If you’re the client, you can see the partner side without the MSP’s cooperation. Check External Identities > Cross-tenant access settings in the Entra admin center for inbound trust and which external tenants it names. Then review Partner relationships / delegated admin for active GDAP relationships and the roles each one actually carries.

In the logs, two reads matter. In sign-in logs, filter for guest activity and cross-tenant sign-ins, an MSP identity authenticating into your tenant from an unfamiliar location or at an odd hour is the tell. In audit logs, look at guest-user additions, role assignments handed to external identities, and any changes to GDAP relationships. A new high-privilege role appearing on a delegated relationship is not routine maintenance until proven otherwise.

A read-only pull to get the sign-in side onto your screen, nothing here changes state:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
​
try {
    # Read-only. Review the output; do not pipe it into anything that writes.
    $guestSignIns = Get-MgAuditLogSignIn -Filter "userType eq 'guest'" -All -ErrorAction Stop
    $guestSignIns |
        Select-Object createdDateTime, userPrincipalName,
            @{n='ResourceTenant';e={$_.ResourceTenantId}},
            @{n='HomeTenant';e={$_.HomeTenantId}},
            ipAddress, @{n='City';e={$_.Location.City}} |
        Sort-Object createdDateTime -Descending |
        Format-Table -AutoSize
}
catch {
    Write-Error "Sign-in query failed: $($_.Exception.Message)"
}

-All handles pagination so you don’t review the first page and declare victory. Resist the urge to feed its output straight into a remediation loop, eyeball the results, confirm which identities are genuinely your provider, then act on a reviewed list.

The remediation nobody loves but everybody owes

Separate admin accounts for MSP staff, the account that does privileged work is not the account that reads email. Enforce MFA, including on guest access. Put Conditional Access in front of B2B guests instead of waving them through. And scope every GDAP relationship down to the roles the work actually requires, with an expiry.

The next dated beat on this calendar isn’t Microsoft’s. It’s yours: the day your next access review runs. If that date doesn’t exist, that’s the finding.